IT Service Management Best Practises for the Support Desk and Network Operations Center by Sanjay Gupta

A PROJECT REPORT ON

IT Service Management Best Practises

for the Support Desk and Network Operations Center

FOR ICICI OneSource Limited

Company Profile

Fact Sheet ICICI OneSource is a Business Process Outsourcing services provider. They offer offshore transaction processing and contact center services. Their offshore business model, with an in-market team in the US (Virginia) and the UK (London), and delivery centers in India enables them to offer clients enhanced quality and cost reduction. Ownership ICICI OneSource is owned by the ICICI Group, the largest private sector financial services group in India, which manages assets of over US $20 Billion and WestBridge Capital Partners. Capitalization Capitalized for US $50 Million, which makes them one of the best-capitalized companies in the offshore BPO space from India. Service Offerings Financial services transaction processing (FSTP), BPO and contact center / call center services across sectors. Capacity Current capacity of 3000 seats across five centers, which are located in Mumbai and Bangalore. Proven Delivery Handled over 30 Million transactions across multiple channels since inception. Points of Presence Global points of presence in Santa Clara, New Jersey and Virginia in the US and London in the UK, to connect to their client networks. In-market Teams In-market teams in the US (New York) and the UK (London), with significant experience in the BPO space. Clients 14 strategic growth accounts including Fortune 500 and FTSE 100 companies. Quality Focus Certified by COPC and to the BS 7799 IT security standard.

ICICI Group Overview ICICI OneSource is a member company of the ICICI Group, with ICICI Bank (NYSE: IBN) and ICICI Ventures being joint investors in ICICI OneSource. The ICICI Group is India's largest private sector financial services group and manages assets of over US $20 Billion. The Group has a technology driven business model, enabling it to offer world-class services to customers in a cost-effective manner. 

Track record of profitability and dividends since 1956



Only issuer in India whose foreign currency bonds have been rated Baa3 the investment grade rating for long-term international debt



Customer base of over 8 million retail customers and 4,000 leading enterprises



First Indian company to list on the NYSE



US GAAP and ongoing SEC compliance



ICICI Bank chosen the " Bank of the Year " by The Banker Magazine, UK



Best Retail bank in India from Asian Banker Magazine for 2 successive years



In 2001, rated among the Top 5 Indian employers by Business Today Magazine

Leadership position ICICI has a tradition of creating a leadership position in every business that it enters. Company/Product ICICI Bank Prudential ICICI AMC ICICI Prudential Life Car Loans ICICI Web Trade ICICI Venture Funds ICICI Securities

Business Market position Term lending and retail Largest private sector bank in banking India Mutual funds Largest private sector mutual fund Life insurance Largest private sector insurance company Car loans Largest player Online trading Largest player Venture capital First venture capitalist in India Investment banking Leading player

ICICI OneSource Organization Structure

IT SERVICE MANAGEMENT (ITSM)

IT: Technology provider or strategic business enabler? Today, the effectiveness, reliability, and flexibility of IT services are the critical success factors behind business initiatives. Yet according to Gartner, many IT organizations are not equipped to meet sophisticated and time-sensitive IT service demands. Evolved as cost structures and structured around functional or architectural component lines, nearly 70 percent of IT departments still function as tactical, reactive technology providers rather than as strategic service providers and business enablers. Moreover, despite massive technology investments during the 1990s, many IT departments continue to use outdated organizational structures, management systems, processes, and tools that make it difficult to provide what businesses need most: high-quality solutions and support delivered in real time. Given the almost total dependence of business operations on information technology today, this lack of IT service readiness can have significant business consequences. During the early mainframe computing years, business innovation was not necessarily dependent on information technology, but rather was driven by the long cycle times required to build a new infrastructure and produce traditional goods and services. As customers and industries evolved - in part due to new information technology advancements that allowed large-scale business process integration - traditional goods and services were replaced with information-enabled services. Organizations learned that new business models—and the supporting IT infrastructure - must be flexible enough to allow growth. Without a flexible, reliable IT infrastructure, innovation was stifled, resulting in decreased revenue and lost market share. As the pace of business continues to accelerate, enterprises must become adaptive in order to survive. As they grow ever more dependent on IT, IT organizations and the underlying infrastructures must be agile, flexible, and responsive. Meeting critical business needs IT agility and operational excellence may be difficult goals for IT departments to reach, but they are key to supporting long-term business growth. The disparity between today’s business needs and internal IT abilities constitutes a significant business risk. An IT organization that cannot handle growing demands can contribute to dysfunctional operations. This soon becomes problematic, because when IT is unable to deliver business value, innovation is hindered, and IT is threatened with a loss of trust and decreases in budget. Given this situation, it is not surprising that for the past five years, “business to IT alignment” has rated high among the top five CIO concerns. Gartner believes that IT departments are gradually “losing their franchise to deliver IT solutions” to a variety of specialized consulting and outsourcing firms - a situation in which no one wins except the vendor. Businesses are forced to seek assistance from outside vendors and to pay more for services that their own IT departments

could potentially deliver more cheaply. Costly inefficiencies grow as organizational silos act alone, without central IT leadership to identify tools, disciplines, and best practices that can be applied across services. Profitability drops as IT costs increase, opportunities are lost, and dissatisfied customers take their business elsewhere. In such an environment, IT departments are no longer able to implement the new processes, organizational structures, and other changes that, together, can transform them into strategic business enablers. More than a budget issue Solving the problem does not necessarily require a larger IT budget. Quite recently, companies, governments, and even educational institutions focused on growth, spending millions of dollars on expanding IT infrastructure and staff. While these costly, often poorly coordinated investments provided greater flexibility and enabled dramatic business innovation, they did little to prepare IT organizations to meet today’s service needs. If anything, businesses learned that a tough economic climate and growing demand could quickly outpace an IT organization’s ability to deliver high-quality services. Cutting costs, reducing headcount, and consolidating infrastructure are also unlikely to be effective, though they can help a business survive an economic downturn. Increasingly, however, IT executives understand that the immediate financial benefits of these activities are short-lived and cannot prepare their enterprises to compete effectively when the economy improves. Instead, IT organizations must strive to become strategic solution providers, committed to enabling key business initiatives with reliable, cost-efficient services. Transforming IT into a service provider IT executives who have cultivated a broader business-IT perspective realize that achieving IT agility and operational excellence requires not only cutting costs but also transforming IT so it focuses on service rather than technology management, on customers instead of users, and on integrating people, process, and technology. At the same time, IT departments must reassess their core competencies, changing them to enable the delivery of new services. The process may require rethinking and restructuring services and underlying support to position their organization for the future. Simply put, transforming an IT organization into a service provider requires a return to the basics. From an internal customer’s perspective, transforming IT into a strategic service provider means aligning the IT organization with business goals, focusing on the value-added services that businesses want, and delivering them. It means that IT becomes a trusted, respected advisor who develops innovative solutions to business problems. And it means that IT is run as a business function.

Only recently has it been possible to combine the components essential to a successful IT transformation—people, process, and technology—and use them to implement the organizational changes required to make this vision a reality. Highquality IT service solutions require a strong bond between these components because services are the outcome of IT processes and infrastructure. They are executed and controlled by people working in an organizational structure, and they are supported by management technology. A successful IT transformation can contribute to sustained business success, an experience shared by companies that have balanced the ability to expand market share and revenues with the ability to deliver profits and increase customer satisfaction. Making IT transformation real IT transformation is achievable, but it requires significant and potentially risky changes. Globally and across industries, IT organizations are seeking answers to critical questions such as the following:    

How do we refocus our IT organization on the basics? How can we move toward managing services? How can we evolve to enable the Adaptive Enterprise? Where do we start?

Many IT organizations are turning to IT Service Management (ITSM) and the ITIL Reference Model for answers.

ITSM: Enhancing IT Service Management for business success A brief history ITSM began as a project undertaken by the government of the United Kingdom (U.K.) in the early 1980s. In the midst of a serious economic downturn, the government was forced to lower costs and better manage IT service delivery. The government knew it needed to develop innovative ways to improve IT service efficiency. The government put the British Central Computer and Telecommunications Agency (CCTA) in charge of the project. The CCTA knew it could increase efficiency quickly by focusing on improving IT processes. The team recruited consultants, vendors, and users to design a set of best practice–based IT processes, which were then documented using a common glossary of terms and published in an integrated series of 40 books. This series, recently updated and repackaged as seven books, is now referred to as the IT Infrastructure Library (ITIL). ITIL is the most comprehensive and respected source of information about IT processes ever written for organizations seeking to implement IT service management. Successful companies and governments worldwide have adopted ITIL. Organizations such as the IT Service Management Forum (ITSMF), an independent, international ITIL users group, help to share ITIL best practices. And many consulting and educational firms around the world now offer ITIL training and certification programs for IT professionals. Defining ITSM According to ITIL, “IT Service Management is concerned with delivering and supporting IT services that are appropriate to the business requirements of the organization. ITIL provides a comprehensive, consistent, and coherent set of best practices for IT Service Management processes, promoting a quality approach to achieving business effectiveness and efficiency in the use of information systems.” The ITIL definition of ITSM can be taken a step further by defining ITSM as a business-driven approach that IT organizations can use to design, build, manage, and evolve quality IT services that:   

Are customer-focused and process-driven Meet quality, agility, and cost targets Enable the achievement of service-level targets as defined in service-level agreements (SLAs)

Both definitions imply that implementing ITSM provides an IT organization with service delivery capabilities that are stable and cost-effective, yet agile. In addition, IT service quality is measured and improved, providing greater value to the

business. These types of impacts make ITSM a crucial factor in achieving sustained business success. Focusing on the basics One of the first questions an IT organization must ask when beginning its transformation into a service provider is, “What do we need to have in place in order to support our business objectives?” This question refers to the idea that IT organizations must adapt in order to succeed - an idea that is aligned with the business goals of the Adaptive Enterprise. Attempting to answer the question generates next-level people, process, and technology questions, such as the following:   

What type of IT structure enables efficient delivery of IT services? What IT processes are required to deliver high quality IT services? What inter-process relationships and business linkages are required? What are the appropriate, available technologies for enabling processes and providing tight process integration?

Tactical considerations Answering these conceptual, strategic questions naturally leads to tactical questions such as:    

How should we design and implement processes that facilitate high-quality IT service delivery and support for our customers? How do we implement process-enabling technologies quickly and costeffectively? How should we identify which IT functions, if any, to outsource? Where should we start?

Knowing when to start planning for IT Service Management is perhaps the easiest question to answer - you should start now. However, answering other tactical questions can be quite challenging, in part because the ITIL is a set of guidelines that only focus on what you should do, and do not explain how to implement a process or adapt it for a particular organization. For this reason, many organizations turn to consulting firms to help them implement ITIL processes. It is important to note that different firms use different methodologies to implement ITIL processes. HP, for example, combines proven methods, such as process management, with forward-thinking concepts, such as running IT as a business, rather than running IT within a business. Organizations interested in implementing ITIL processes should carefully evaluate the experience, capabilities, and methodologies of different firms to determine which one is right for their needs.

ITIL and IT Service Management ITIL is a set of best practices for IT Service Management that has been evolving since 1989. It began as a set of processes for use by the UK government to improve IT service management and has been adopted by the industry as a basis for successful IT service management. In 1989 the first elements of what was to be known as the IT Infrastructure Library were published by the CCTA (Central Computer und Telecommunication Agency), which is now part of the OGC (Office of Government Commerce). ITIL has been developed in recognition of organizations' growing dependency on IT and embodies Best Practices for IT Service Management. Since then ITIL methodology has been widely adopted on a worldwide basis by commercial and non-proprietary organizations alike. Microsoft has chosen ITIL as the foundation for the Microsoft Operations Framework (MOF). The OGC, together with the BSi (British Standards Institute) and the itSMF (IT Service Management Forum) continuously review and consolidate the original ITIL publications to form a consistent and comprehensive set of guidance. More recently, the ITIL guidelines have been adopted as the basis for a new formal standard for IT Service Management: the BS15000 standard now specifies required practice for organizations and offers a recognized accreditation scheme. It is gaining worldwide acceptance as the standard for IT service management. At the core of the library are two volumes on the service management discipline, service support and service delivery, which were rewritten in 2000-2001. Security is covered in the security management volume written in 1999. ITIL describes best practices that can be utilized to best suit an organization. The Service Management disciplines at the center of the IT Infrastructure Library fall into two distinct groups - Service Support & Service Delivery.

The Service Support & Service Delivery disciplines combine to provide the Service Management capability of an organization. There are complex interrelationships among all 10 of the service management disciplines as they interact to support the overall objective of ensuring that the IT infrastructure delivers high levels of service to the business.

This group focuses on the day-to-day operation and support of IT services. Service support includes five disciplines that provide the flexibility and stability for delivering IT services to the business. They are: 

ITIL Service Desk The Service Desk function is the face of IT to its users and therefore of vital importance in any organization. Service Desk staff log, resolve or escalate and close all incidents. They also increasingly provide more high-level first line support as well as initiatives for service improvement and cost reduction.



ITIL Incident Management Incident Management records, classifies, tracks and closes all incidents in a controlled and consistent manner. This allows operational service levels to be restored as quickly as possible and helps to reduce the number of new incidents.



ITIL Problem Management The identification, investigation and classification of problems is a key role in IT Service Management. It pro-actively reduces incident volumes and continually improves the underlying IT infrastructure.



ITIL Asset and Configuration Management This provides the crucial foundation for Incident, Problem and Change Management. It records, audits and tracks all configuration items in the IT infrastructure and their relationships from purchase to obsolescence.



ITIL Change Management The role of Change Management is to provide a consistent approach to evaluating and implementing any change to the IT infrastructure. It allows you to assess the impact, risk, and resource requirements associated with proposed changes.



ITIL Release Management Release Management offers a systematic framework for large or critical hardware rollouts, major software rollouts or bundled sets of changes. It takes into account all technical and non-technical aspects of a release from initial

release policy and planning through to development, testing and controlled implementation.

These processes consider the long-term planning and improvement of IT service provision. Service Delivery includes five disciplines that support quality, costeffective IT services to the business. They are: 

ITIL Service Level Management This aims to ensure a satisfactory quality of IT service provision by setting realistic and agreed targets between provider and customer. A process of monitoring, reporting and reviewing of actual service levels highlights any problem areas and facilitates continuous service improvement.



ITIL Financial Management of IT Services Also known as Cost Management, this process provides essential management information on IT asset and service costs. Through a process of budgeting and accounting true costs are revealed and the value of IT to the business can be demonstrated.



ITIL Capacity Management This process aims at aligning IT service level provision to the current and future business needs. It is concerned with optimizing the usage of existing IT resources as well as ensuring new resources are made available in a timely and efficient manner.



ITIL Availability Management Availability Management ensures that all IT systems and services are functioning as required and that availability is sustained in a reliable and costeffective way. With the supply and provision of information companies need to consider security management as well to prevent unauthorized use of information.



ITIL IT Service Continuity Management This process ensures that major failures of technical equipment or facilities associated with IT Service provision are managed efficiently and service levels are restored back to an acceptable level within agreed



Aligns IT services to present and future needs of the business and its customers.



Better accessibility to services for users through a single point of contact.



Speedy responses to customer enquiries and complaints.



Improved teamwork and communication.



Better identification of areas for improvement.



Pro-active approach to service provision.



More favorable perception of services provided.



Improved quality of IT-related information for optimal management and decision-making.



Reduced impact on the company's business activities.



Better management and control over the IT system's infrastructure.



More effective and efficient usage of resources related to service provision and subsequent cost reduction potential.



Higher IT system users' productivity due to reduced down times.



Improved first line resolution rates.



Enhanced customer care and higher customer satisfaction.



Improved control of SLA performance.



Strengthened IT infrastructure.



Eradicate loss and inconsistent records of information, incidents and customer enquiries.



Reduced number of incidents.



Discovery and implementation of permanent solutions.



Systematic and consistent approach to all processes.

The importance of process in IT transformation The high cost of process problems While technology management has been the traditional mainstay of IT, most IT organizations are realizing that poor service delivery has little to do with technology and much to do with poorly designed or missing IT processes. For instance, the best technology is not helpful if a service offering fails because of process-related problems, such as the following: 

Unscheduled changes Unscheduled - and therefore uncontrolled - changes occur to the production environment because of unclear, undocumented IT processes. Change management process problems lead to false starts, multiple reworks, duplicate efforts, periodic work stoppages, lengthy time-to-repair intervals, and increased customer anxiety and frustration. For a service provider, these problems can be catastrophic. Customers demand predictability for service delivery time, quality, and performance, but IT organizations cannot deliver it if the service delivery environment is unreliable.



Vague process triggers Triggers for IT processes—for example, software distribution—are poorly defined. As a result, IT staff inadvertently begins a process at different points, leading to inconsistent, unreliable service delivery. This type of process problem can seriously impact customer satisfaction and prevent repeat business—and it communicates that IT cannot commit to meeting service levels. For an IT organization attempting to function as a true service provider, customer satisfaction is critical. A dissatisfied business unit customer can be forced to obtain reliable, efficient IT services from outside the organization.



Undefined or nonexistent process links Linkages between IT processes are undefined or nonexistent, making it impossible to capture information and share it among multiple related processes in support of increased business agility, flexibility, and responsiveness. Linkage problems can result in delays to already tight production schedules, low customer satisfaction, missed customer commitments, and, ultimately, loss of revenue.

Customers today expect a rapid response to their business transactions, whether or not an online delivery mechanism is used. Meeting their needs requires IT to be able to capture information and share it among related, linked processes. These linkages enable the business agility and flexibility customers demand. 

Unclear roles and responsibilities IT employees responsible for a process - such as incident management or problem management - are unclear about their roles and are not evaluated regularly, contributing to difficulties in assigning accountability when problems occur. IT must be prepared to restore services as quickly as possible when problems occur. Well-defined roles and responsibilities are critical during service interruptions. Everyone involved in service delivery and support must perform without confusion or delay. This ability can be the critical difference between success and failure for an IT organization attempting to establish credibility as a service provider.

These situations are all examples of process problems. Sustained business success is very difficult to achieve until they are addressed. Characteristics of successful IT processes Effective IT processes, whether they support service development, delivery, or support teams, must be clearly identified, well-defined, documented, and communicated to all affected personnel. In addition, IT processes must be measurable in order to facilitate improvements. Measuring a well-defined process provides an IT organization with the ability to predict performance over time. This capability is basic to any continuous process improvement effort. With proper metrics, IT can gauge performance and proactively make adjustments, often before service failure occurs. It is also important to remember that no IT process stands alone. Defining and measuring an individual process must be done in the context of the greater whole which means understanding and defining interrelationships and dependencies between the target process and other processes in the IT environment. Unclear or undefined process relationships can lead to both false assumptions about reliability and frustration when processes that have presumably been repaired negatively impact other processes. Process reengineering and the people factor Transforming IT requires that organizations reengineer IT processes—but too often, reengineering results in frustration and failure.

In most cases, IT organizations implement new processes and tools without considering the impact of changes on the organizational structure and the people involved. Designing and implementing new IT processes is true process reengineering. Process reengineering is the essential bridge that connects people and technology to process (see Figure 1 below). And to be successful, process reengineering must address all aspects of process management.

Figure 1. Reengineering: aligning people, technology, and process for continuous improvement

People and process management Process management effectively integrates people, information, tools, and procedural structures with the goal of meeting performance and quality objectives. When process management is applied to one or more target processes as part of an ITSM-based process reengineering effort, these processes should exhibit the following characteristics: 1. Process ownership: assigned accountability 2. Process measurement: measurable conformance to user requirements 3. Process control: verification that work outputs meet specifications

4. Continuous process improvement: increased productivity and efficiency, as well as defect removal 5. Process definition: a clear understanding of the value of the process and the steps required to perform it Note that none of these characteristics is possible to achieve without affecting IT staff. A well-defined process is one that has been documented in flow diagrams and contains clear definitions of each step and its accountabilities. Assigning accountability through process ownership can also have a dramatic and immediate impact on an IT organization because it directly affects organizational structure. For example, after identifying the processes performed by an organization during a reengineering effort, the next step is to assign process owners to those processes. For most companies, process owner is a new role that must be clearly defined and understood by the entire IT organization and integrated into its overall hierarchy. Similarly, implementing process measurement, process control, and process improvement can have further implications for IT staff. For example, many of the IT processes currently in place globally are measured poorly or not at all, do not have clearly defined output specifications, and were not designed for continuous process improvement. For such organizations, implementing comprehensive process management usually results in significant changes in job responsibilities and daily activities for some employees. These employees may also need to develop new skills and use new technologies, which requires skills assessments and strategic education investments.

The importance of people to IT transformation Clearly, improved processes are useless without people. But the people component of IT refers to more than a simple understanding of how process reengineering and process management affects IT staff. It also refers to skill sets, attitudes, and the new roles and responsibilities staff must assume to be successful. Each of these people aspects must be transformed in order for IT organizations to evolve from technology to service providers. Skill and attitude transformation IT staff skills must change in support of new or modified jobs that result from process engineering – and changing or improving skills requires education and training. However, proper performance of new skills alone does not necessarily result in successful IT transformation. Attitudes must also be transformed so that the entire IT department becomes more customer-focused, service-oriented, and aligned with the business goals of the organization (see Figure 2 below). Figure 2. New skills and attitudes required for successful IT transformation

In practical terms, this means IT organizations must:   

View consumers of their services as customers Temper their traditional inward perspective and start looking outward Expand their focus on technology to include a focus on service solutions

      

Move away from isolated, ad hoc processes and develop business-justified, streamlined IT processes Implement measurable, accountable processes Balance in-house solution development with outsourcing Develop and implement integrated, end-to-end IT processes, avoiding process silos Utilize new process improvements to support a proactive approach Define and develop service-oriented organizational structures, roles, and responsibilities Enhance traditional IT system skills with customer-focused skills

Making these skill and attitude changes throughout an IT organization requires a well-defined educational curriculum that addresses process and technology. In most cases, organizations benefit by hiring a consultant who understands these needs and can develop a tailored plan. Typically, once new processes are implemented and there are measurable, reportable results, people’s attitudes shift to a service and customer orientation. However, the tone set by IT leadership also significantly impacts the attitudes of staff. Transformation of roles and responsibilities Reengineered IT processes also require new roles and responsibilities. Attempting to introduce new or significantly improved IT processes without addressing underlying roles, responsibilities, metrics, and job descriptions can lead to poor performance, frustrated staff, and possible failure. For IT transformation to be successful, roles and responsibilities must change to reflect the new processes and service priorities, and these changes should affect the entire IT organization. The role of the process owner One of the most important new roles in a transformed IT organization is that of process owner. Essentially, a process owner has end-to-end accountability for a specific process. As many IT processes are cross-functional - they span the organization - it is imperative that accountability matches the process owner’s organizational responsibility. It is next to impossible for a process owner to manage a process without the requisite authority. While many people may actually be responsible for carrying out different aspects of a specific process, it is always the process owner who is ultimately accountable for success or failure. Change management - production change control - is an excellent example of a cross-functional IT process that requires a process owner or change manager with the authority to manage a process end-to-end. For instance, when rolling out a new application to a business unit or conducting enterprise-wide server consolidations, the change manager must be able to control changes regardless of location or organizational structure.

Since process owners must be empowered by IT management to manage their specific processes regardless of organizational boundaries, the CIO and direct reports must provide both sponsorship and support. Additional process owner responsibilities include the following:    

Providing leadership for a specific process and its sub-processes Understanding the effect the environment has on the process - and the effect the process has on the business Understanding the process end-to-end Maintaining good relationships with key managers and stakeholders in IT and business domains

As process owners are also relationship managers who span business and technical arenas, they should be visionaries who are respected by their peers and skilled in navigating corporate politics. Barriers to process owner success While the concept of a process owner is sound, implementing the role can be extremely difficult, and succeeding in it may be unachievable without CIO sponsorship. Functional managers may view process owners as a threat to their authority. These issues are serious but not insurmountable when the process owner role has strong CIO sponsorship and the organization closely monitors and addresses management of change (MOC) issues during the process reengineering effort. Similarly, when IT organizations are primarily structured around functional or architectural component silos, process owners are set up to fail. Silo-based IT organizations are not designed to deliver end-to-end, cross-functional process management, primarily because functional managers are traditionally not focused on cooperating to deliver IT services. To overcome these potential barriers to success, IT organizations must be restructured around the services they provide to the business. Gartner describes this as “service-based organizational design,” which focuses on quality service creation, delivery and operations. Implementing new roles in service provider organizations Other process roles may be implemented to enable reengineered processes. Each role must be reviewed for its potential impact on the organization, as well as for risks, benefits, and consequences. Again, it is not possible to realize the benefits of reengineered processes without adapting the organizational structure to support them. How new roles are implemented - and the scope of these roles - varies from company to company because of differences in corporate culture, organizational

structure, and size. In larger companies with more complex organizational structures, process owners are typically assigned only one process, and even then, they may delegate management of continuous process improvement to third-party service-quality experts. In smaller companies, process owners may be responsible for more than one process and may also assume the task of leading continuous process improvement efforts. As organizations identify new roles, responsibilities, job definitions, and lines of reporting during IT transformation, it is natural that those involved may resist change. In such cases, upper management must be actively engaged in the IT process transformation effort.

The importance of technology to IT transformation Making new or improved IT processes function smoothly often requires significant changes to existing technologies as well as incorporating new technologies into the existing IT environment. IT also needs process-enabling technologies - special tools to automate processes and simplify the inter-process integration and communications for managing IT services enterprise-wide. In addition to process-enabling technologies, other tools may be required for an overall ITSM solution, such as tools that:    

Allow companies to view their Internet infrastructure, simulate, and monitor business activity Monitor the performance of Web sites and improve the customer experience Monitor and analyze telecom service impact and quality Provide timely and accurate service reporting, or create portal views that provide customers with visibility into their services

Selecting process automation tools Proper tool selection is critical to successful IT transformation. However, IT organizations can no longer afford to spend months and thousands of dollars evaluating tools. They must quickly select and implement process-automating tools. The following criteria are helpful in choosing which tools to use: 

Out-of-the-box integration with other process automation tools To simplify implementation, reduce cost, and improve processes, IT organizations must identify tools that require minimal customization. For example, consider the benefits of purchasing a change management system that is already integrated with configuration management, incident management—a help desk process—and service-level management systems. As change orders are processed, past, current, and future IT infrastructure data can be automatically retrieved from configuration management and updated. Past incident data can be gathered immediately, dramatically shortening the review and approval time for a specific change. The same data, when also made available to problem management, allows specialists to analyze trends and avoid future service outages. At the same time, change management and incident management personnel can access problem data to enhance support quality and decision-making. Help desk staff can quickly determine applied service levels and escalation parameters for callers, enhancing customer satisfaction. At its best, process automation offers these capabilities in a single, integrated platform, using a single database that can be easily distributed across the enterprise. One example is the HP OpenView Service Desk solution, which is

ITIL-based, designed specifically for ITSM, and fully integrated out of the box. When evaluating technologies, you will want to carefully compare the out-ofbox capabilities of each option. 

Easy integration into the larger IT environment It is also important to consider the ease with which process-enabling technologies can be integrated into the larger enterprise IT environment. Integration can range from inserting an entry on a menu bar to full-scale data exchange between applications. IT organizations must determine their needs and select a product that both enables the desired level of integration and meets cost criteria.



Tools that address real business needs A common pitfall when selecting a process automation tool is failing to properly evaluate and prioritize business needs before beginning the selection process. For example, IT organizations may need to implement a world-class help desk and also improve IT process integration. Many companies attempt to evaluate technology options with both needs in mind, comparing a mix of help desk point solutions with IT process integration solutions. Unfortunately, few, if any, integrated IT process tools have a help desk component that can compete one-on-one with a world-class help desk vendor point solution. On the other hand, choosing a less feature-rich help desk solution can be easily offset by the various advantages offered by an integrated IT Service Management solution - which will facilitate IT process transformation on many levels.

The levels of enterprise ITSM The previous sections have examined the importance of three key variables— people, process, and technology—as IT organizations evolve from technology providers into service providers. However, there are many issues to address before beginning the IT transformation:    

Should organizations transform everything at once? Are there stages of IT transformation that enable businesses to evolve safely and systematically? How do these stages affect people, process, and technology? Where should an organization start?

Stages of IT evolution Evolutionary models help IT organizations address these issues by providing a framework to assess current and desired states, identify and prioritize gaps, and develop a plan for change. We can use an essentials-based, three-stage approach that describes how enterprise IT management evolves and the benefits that ITSM can bring to the business (see Figure 3 below).

Figure 3. The levels of enterprise IT management

It is important to note that each evolutionary stage builds upon the others, beginning with managing the infrastructure. Following is a detailed description of each stage, as well as a discussion of how IT organizations create increased business value as they evolve. Stage One: Managing the infrastructure Initially, IT organizations evolving from technology providers into service providers focus on improving the management of the enterprise infrastructure. Effective infrastructure management means maximizing return on computing assets and taking control of the infrastructure, the devices it contains, and the data it generates. Achieving this goal begins with an understanding of all computing elements. The desired outcome is a highly available enterprise IT infrastructure. Tactically, the emphasis during this stage is on implementing technology, such as HP OpenView, which plays a critical role in helping an IT organization become a reliable infrastructure provider. This technology discovers, monitors, and manages all computing elements that critical business applications depend upon - regardless of where they are located—and displays linkages and topology. In global businesses, IT management technology usually supports “follow the sun” management, allowing a seamless shift in responsibility from one geographic center to the next. Comprehensive monitoring and management of computing elements is critical to ITSM success. For example, IT management technology automatically detects status changes, such as a failure or subtle performance degradation that might lead to service failure. When problems arise, automated, corrective actions can repair routine problems—such as deleting temporary files on an overloaded disk drive without interrupting operators. When staff does need to be involved, IT management technology makes their jobs easier with features such as one-click troubleshooting, predefined fixes, and integrated application toolboxes. But IT management technology must go beyond monitoring to actively managing performance. Distributed agents, which are sophisticated programs that run on managed devices, constantly scan hundreds of performance indicators. This allows IT to achieve greater performance from existing computing assets - a high priority for most businesses today—and proactively address problems before users are impacted. Effective infrastructure management also establishes preset policies to help make bandwidth available for business-critical applications, even during peak network traffic periods. Work may be prioritized, for example, so that less-important jobs are postponed and executed during non-peak periods. Infrastructure management also requires intelligent filtering and incoming message correlation to prevent operations staff from becoming overloaded with low-level notifications, thereby allowing them to focus on high-priority matters.

Ideally, during this stage, all infrastructure information can be accessed through a single, intuitive console that dramatically simplifies enterprise-wide infrastructure management. For larger enterprises with many operators, console views are usually specific to an operator’s area of responsibility or specialty. Stage Two: Managing the services An IT organization that evolves through stage two—managing the services—is actively identifying the services its customers need and focusing on planning and delivering those services to meet availability, performance, and security requirements. In addition, IT is managing service-level agreements (SLAs), both internally and externally, to meet agreed-upon quality and cost targets. These activities are central to running IT as a business. When a service is disrupted or performance degrades, the IT organization not only knows the devices involved but, more importantly, understands the business implications of the problem and takes effective action. For example, if a winter storm disrupts data traffic through Chicago, operators immediately know the network links and devices that are affected. IT also knows the business impact and who is responsible for taking action. Though the source of the problem may be a server, network router, or storage device, IT understands that the failed device is one of many essential links in a chain that supports a business-critical service, such as order entry. Given this new, business-focused perspective, IT can base its actions on broader business priorities rather than pressure from end-users. When implemented properly, an ITSM solution combining people, process, and technology will tightly associate every network device with the services it supports. As a result, IT organizations can proactively manage that device as part of strategic business services. For example, if operators have been alerted to an imminent response-time delay on an order entry application, they will move quickly to ensure that incoming orders are processed. With ITSM-based infrastructure management, operators can be automatically informed of the status of every computing element that affects order entry. Such rapid root cause analysis keeps the business moving and protects the bottom line. By measuring the results of these daily activities, an IT organization can manage IT services to meet business expectations for reliability, availability, and performance. It also positions the IT organization to deliver and support service offerings that provide real business value. Stage Three: Managing the business value of IT Ultimately, ITSM helps IT organizations evolve as true strategic business partners, enabling new business opportunities. As efforts produce measurable results, ITSMbased technologies track and report resource utilization and monitor user satisfaction. Out-of-the-box, customizable reports allow line-of-business managers to

see that they are receiving positive returns on IT investments. And over time, IT develops a reputation for delivering as promised and supporting cost-reduction initiatives and business goals. One of the most significant characteristics of this evolutionary stage is IT processes that are fully integrated with the complete lifecycle of business processes. Full integration, which is enabled by IT management technology and IT-to-business process design, reduces risk and cost while improving service quality and business agility. Simultaneously, automated service activation promotes high-quality service delivery, full service usage, and accurate billing. As IT organizations at this stage have full infrastructure data and can provide services at agreed upon cost and quality targets, they can also sell and bill for services internally and externally, generating revenue. For example, a well-known truck rental company recently announced interest in extending its logistics expertise to external clients through an e-services model. Similarly, a large amusement park now offers mobile “never lost” units that can help families quickly reunite with lost children. In such instances, IT becomes a revenue-generating, strategic partner to the business. ITSM solutions at this evolutionary stage also provide sophisticated reporting that allows IT to present an accurate picture of its accomplishments and build its reputation within the larger organization. Data reporting includes more than just device-specific metrics, throughput, and traffic patterns. It also includes measurements of user experiences that are aggregated and related to specific IT services. Achievements can be easily communicated to important IT constituents via clear, understandable Web-based reports. This detailed information also helps increase the effectiveness of IT staff by enabling IT managers, for example, to appropriately reallocate human and infrastructure resources. By publishing data about service quality, reliability, cost savings, and business impact, IT can make a case for incremental technology investments and be viewed as a trusted advisor.

Phase I

Study and Evaluation of Present Functioning and Resources of Central Support Desk

Phase I Highlights Key Deliverables: 1. Observations on the present operations and resources of the Central Support Desk. 2. Calculate staffing requirements and resource utilization. 3. Suggest changes in operations to increase efficiency. Limitations: 1. Observations have been restricted to interactions with the Agents and Team Leaders of the Central Support Desk, and my visits on the Central Support Desk floor over the past few days. 2. Staffing calculations have done using the calls received on the Central Support Desk IPLC extension data available from Nortel Symposium for April 2004.

Phase I Information Central Support Desk Functioning: 1. Impact incidents for users in every process (campaign) as well as Corporate users are first reported to the Support Desk via an IPLC telephone number for Operations and Clients and a local telephone number for Corporate departments. 2. The Support Desk Executive raises a trouble ticket for the incident on the existing Customer Leverage system and then informs the respective team (technical, telecom, etc.) to resolve the issue, giving them the corresponding trouble ticket number. 3. There are different escalation matrices to be followed based on case priorities:   

Critical Case: When more than 30% of production is affected. Non-critical Case: When less than 30% of production is affected. Non-production Case: When the cases are from the Corporate Departments such as HR, Administration, or Training.

4. The respective team, on resolution of the issue, informs the Support Desk Executive about the resolution of the issue and asks them to close the corresponding trouble ticket. 5. Reports are prepared manually in Microsoft® Excel® on weekly as well as monthly bases for all the ticketing done by the Support Desk Team. The Customer Leverage system also provides automated reports that are usually generated by the clients or for quality checks. Central Support Desk Resources: 

No. Of Seats: 3 (Fixed Agent Seats) + 1 (Team Leader Seat)



Staffing: 13 Agents + 2 Team Leaders



No. Of IPLC Phones: 3 (Agent Extensions) + 1 (TL Extensions)



No. Of Desktops: 3 (Agent Workstations) + 1 (TL Workstation)



No. Of Local Phones: 3 Local Extensions

Central Support Desk Agent Key Responsibilities and Activities: 1. Agents are supposed to answer user calls for the issues they face, tag these cases into Customer Leverage, and escalate the cases as per the escalation matrix. 2. They also follow up with the technical teams for updates on cases escalated and inform the user of the same. 3. Agents in the night shift prepare internal reports, one for each center, as well as client-specific reports. 4. Agents in the day shift verify the reports prepared by the night shift agents and upload the same to the Customer Leverage Reports intranet web site.

Phase I Observations Central Support Desk Agent Activity Time (in hours per week): 

Total time per agent per week: 45 hours



Time spent per agent on handovers and logins per week: 1.6 hours



Time spent per agent on breaks per week: 3.4 hours



Time spent per agent on reports per week: 20 hours



Balance time available per agent for call handling: 20 hours

Positive Observations about Central Support Desk Agents: 

Most agents are dynamic and respond to user issues at their best effort as per operation procedures and available resources.



There is a good sense of team bonding amongst the agents that proves to be very helpful.

Negative Observations about Central Support Desk Agents: 

Most agents do not tag the cases while on call; they usually write down the case details on paper and then update the same in CL. This results in incorrect information (relating to time) stored in CL as well wastage of effort.



Agents receive personal calls on their mobile phones as well as make personal calls from the local extensions. This causes disruption in the workflow of the agents.



Agents are very reactive to change and are not ready to accept the idea of call center parameters being implemented for them.

Phase I Achievements Staffing Requirements in Central Support Desk: The Service Level Agreements (SLAs) defined for this purpose are listed below: 1. 85 % of incoming calls to be answered in 10 seconds. 2. Time for a call to be abandoned is 10 seconds. 3. Average Handle Time (AHT) per call is 11 min. This only includes call receiving, call tagging, and first-level escalations; time taken for updates and higher-level escalations not included. Based upon the above SLAs, I have used an Erlang Calculator (Easy Erlang) to generate a staffing table as shown below: Calls Intensity Agents Service Received per (Erlangs) Required Level hour 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

0.2 0.4 0.6 0.7 0.9 1.1 1.3 1.5 1.7 1.8 2 2.2 2.4 2.6 2.8 2.9 3.1 3.3 3.5 3.7 3.9 4 4.2

2 2 2 3 3 3 4 4 4 4 5 5 5 5 6 6 6 6 7 7 7 7 8

98.50% 94.30% 88.10% 95.80% 92.60% 88.40% 95.40% 93% 89.90% 86.20% 93.80% 91.50% 88.80% 85.50% 92.90% 90.80% 88.40% 85.50% 92.50% 90.60% 88.40% 85.80% 92.30%

Percentage Calls Abandoned

Percentage Utilization

1.60% 5.70% 11.90% 4.30% 7.40% 11.60% 4.60% 7% 10.10% 13.80% 6.20% 8.50% 11.20% 14.50% 7.10% 9.20% 11.60% 14.50% 7.50% 9.40% 11.60% 14.2 7.70%

9.20% 18.30% 27.50% 24.40% 30.60% 36.70% 32.10% 36.70% 41.30% 45.80% 40.30% 44% 47.70% 51.30% 45.80% 48.90% 51.90% 55% 49.80% 52.40% 55% 57.60% 52.70%

24 25 26 27 28 29 30

4.4 4.6 4.8 5 5.1 5.3 5.5

8 8 8 9 9 9 9

90.60% 88.60% 86.30% 92.30% 90.70% 88.90% 86.90%

9.40% 11.40% 13.70% 7.70% 9.30% 11.10% 13.10%

55% 57.30% 59.60% 55% 57% 59.10% 61.10%

For details please refer the Annexure, ‘Call Center Traffic Modeling and Resource Allocation’. Recommendations to improve Central Support Desk operations: 1. Increase number of agent seats to 5 seats with desktops, IPLC extensions, and local extensions on all seats. 2. Staffing should be increased from present strength of 13 Agents and 2 Team Leaders to 16 agents and 3 Team Leaders to handle present call flows & accommodate for people taking leaves so that the Central Support Desk can successfully operate on a 24x7 basis. 3. Call center features should be enabled on all the agent IPLC extensions. These include ACD-In (to indicate that they are ready to accept calls), ACW (After Call Work, to complete case tagging and escalations), AUX (Auxiliary Work, to account for breaks taken by agents and logout times), & Q-Calls (to indicate to the agents that there are calls in queue). 4. Direct incoming calls to be barred on individual agent IPLC extensions. Only calls made to the Central Support Desk IPLC extension should land on the agent IPLC extensions. 5. Multiple call appearances should be disabled on the IPLC extensions. 6. Incoming calls to be barred on all agent local extensions except the local extension reserved for Corporate department calls. 7. All reporting activities should be taken off the agents and should be passed over to the Process Analysts’ team. This will enable agents to dedicate their full time and effort to handle user calls. 8. Agent KPIs (Key Performance Indicators) should include AHT (Average Handle Time), Total Calls Handled, and Monthly Average Quality Score. 9. Quality checking to be done by Team Leaders only and not by other agents.

10. Team Leaders should have proper shifts with shift rotations, instead of the general shifts they presently do. 11. Agents should be advised to switch off their mobile phones while on the Support Desk floor and making of personal calls from local extensions should be discouraged. 12. Schedules for agent trainings and briefings should be made so that all agents are updated with respect to processes and other technicalities.

Phase II

Suggest Changes to be made in Customer Leverage Software for Central Support Desk

Phase II Highlights Key Deliverables: 1. To understand the requirements of all processes at ICICI OneSource and list the changes for the existing Customer Leverage System. 2. To redesign the workflow from raising the ticket to optimize staff utilization. 3. To have all existing reports generated automatically from Customer Leverage and exported into Microsoft® Excel®.

Limitations: 1. The existing Customer Leverage System was not originally designed to operate as a call-management software and therefore has some inherent constraints. 2. It may not be possible to implement all the recommendations. 3. Implementation timelines would be set by the Software Team after the go ahead has been received.

Phase II Information Customer Leverage Software: 1. The Customer Leverage software is an in-house contact-management application developed by the Software Team at ICICI OneSource Bangalore. 2. The Central Support Desk Agents use this software to record the down times of various clients and support teams on a day-to-day basis. 3. The Customer Leverage software was not originally designed to operate as a call-management software and therefore has some inherent constraints.

Phase II Achievements Suggested Changes in Customer Leverage Software: 1. Workflow Changes: Changes suggested in the existing call tagging process to optimize staff performance 2. Database Updates: The CL-CSD Database needs to be updated with entries for existing processes and new processes. 3. Client Updates: New clients to be created for the second center at Mumbai, the Corporate headquarters at both Mumbai and Bangalore, and the First Ring center at Bangalore. 4. Report Generation: Changes suggested to automate generation of existing reports from CL-CSD and export the same to Microsoft® Excel®.

Phase III

Requirements Analysis for Synergy between

Central Support Desk and Network Operations Center (NOC)

Phase III Highlights Key Deliverables: To generate requirements list for integration of CSD and NOC operations. Limitations: There is no ticketing system in place for the NOC team and therefore all calls are tagged manually into different Microsoft® Excel® Spreadsheets.

Phase III Information NOC Objectives: 1. To Monitor, Control Access and obtain Devices/Applications for the Existing Projects.

Performance

Inputs

2. To Monitor, Control Access and obtain Performance Devices/Applications for the New (Proposed) Projects.

Inputs

3. To have Process Maps across all Devices/Applications of Technology Function. 4. To have Escalation Charts across all Devices/Applications. 5. To have Database Models for NOC, Intelligence Reporting, and Capacity Planning. NOC Monitored Devices and Parameters:

Servers

Routers:

1) Access Control (Authorized / Un-Authorized Access) 2) If the Memory Utilization is above the Threshold Limit 3) If the CPU Utilization is above the Threshold Limit 4) If the Server is Down / Outage.

1) RMON Alarms (Authorized / Un-Authorized Access) 2) If the Memory Utilization is above the Threshold Limit 3) If the CPU Utilization is above the Threshold Limit 4) If the Router is Down / Outage.

IPLC Links:

Firewalls:

1) If the IPLC link is Down / Outage 2) If the Shelf Card is Faulty or Not-Responding 3) If the Port is Down / Outage 4) If the IPLC is fluctuating 5) If the Voice Circuit is Down / Outage

1) If the Firewall is Down / Outage.

Issues with current operational setup: 1. No trouble-ticketing system for NOC. 2. No mechanism to map outage incidents to production (impact). 3. Reports for both the NOC & the Central Support Desk are yet to be automated. 4. All reports need to be customized as per client/user requirements. 5. All processes for both NOC & Central Support Desk result in inefficient consumption of man-hours.

Phase III Achievements Recommendations for Synergy between Central Support Desk and NOC: 1. Introduce a common ticketing system for NOC & Support Desk. 2. Introduce mechanisms to map outage incidents to production (impact). 3. Introduce mechanisms to link the alerts triggered in NOC to the Business Aspect. 4. Reduce person-dependency & decrease training requirements by means of documented Standard Operating Procedures. 5. Automation of all reports for both the NOC & Central Support Desk. 6. Increase efficiency of present processes resulting in proper utilization of available resources.

Phase IV

Recommend an ITIL Compliant Incident Management Tool for Central Support Desk and Network Operations Center (NOC)

Phase IV Highlights Key Deliverables: 1. To generate requirements list for Incident Management System for CSD and NOC. 2. To review different ITIL Certified Service Support Tools for use as an Incident Management System. 3. To obtain quotes from different software vendors for the various ITSM tools and recommend a tool to ICICI OneSource.

Limitations: 1. Only demos of the various ITSM tools would be taken. It is not possible to see live implementations of the same. 2. My role would be limited to recommending the ITSM tool for Incident Management. Implementation, integration and testing of the same would be overseen by Mr. Abhijeet Upponi, Manager - NOC Design, Mumbai.

Phase IV Information ITIL Service Desk: 1. The Service/Help Desk plays an important part in the provision of IT Services. It is very often the first contact the business users have in their use of IT Services when something does not work as expected. 2. The Service/Help Desk is a single point of contact for end users who need help. Without this, an organization could certainly face losses due to inefficiencies. 3. The two main focuses of the Service Desk are Incident Control and Communication. 4. There are different types of Help Desk, the selection of which is dependant upon what the business requires. 5. Some Help Desks provide a simple call logging function, and escalate calls to more experienced and trained staff. Others provide a high degree of business and technical knowledge with the ability to solve most incidents at the time that the business user reports them. ITIL Compliant Tools: The maturity of the market place means that all the ITIL compliant products do the job more than adequately. They all have web interfaces, and link into all the main alerting tools, and they are all capable of similar things. Increasingly, the choice of tool is becoming dependent less upon functionality and more upon individual perceptions and ancillary issues such as look and feel, support levels and, not least, costs. I recommend that people considering purchasing any of the present ITIL compliant tools should take additional time to get each of the companies to give a day’s demonstration of the products they have on offer, as ultimately the choice made will come down to the cost of the product and any personal preferences which a company may have. I have not considered the cost of these products when producing these details, and recommend that people considering purchasing such products contact the companies involved to negotiate costs.

PinkVerify™ - Certified Toolsets http://www.pinkelephant.com/consulting/toolsets

These software producers (listed alphabetically) have products that are verified as meeting the mandatory functional requirements for ITIL compatibility identified within this service. PinkVerify™ indicates that a tool meets Pink Elephant’s mandatory and integration criteria for ITIL compatibility for all four of the following ITIL IT Service Support processes: Incident Management, Problem Management, Change Management and Configuration Management.

Vendor

Tool

Version

assyst

4.6

Incident*

Problem*

Change*

Configuration*

Availability

Release

SLM

Status

ITIL Service Support

Datawatch International

AllFusion Harvest CM

5.1.1

Unicenter Service Desk

6.0

QSM

2.0

Heat

7.0

OpenView Service Desk

4.5

Infra Enterprise

7.0

Magic Service Desk

7.5

ITIL Service Support

ITIL Service Support Enhanced

ITIL Service Support

ExpertDesk

4.05

Service Center

5.0 5.1

Remedy IT Service Management suite

5.5

ITIL Service Support Enhanced

ChangeMan ALM®

HelpDesk Suite**

ViaTIL

2.5

ITIL Service Support Enhanced

1. PinkVerify certification is based upon an implementation according to customization guidance obtained directly from the vendor. 2. PinkVerify certification is based upon an implementation according to customization guidance obtained directly from the vendor. This functionality is anticipated to be available "out-of-the-box" in the next release. ** Consists of HelpDesk version 5.1.2 and Change Manager version 5.1. Verification based on using an ITIL compatible database available from the vendor.

Phase IV Achievements Requirements from Incident Management System: 1. Automation of most tasks that are presently performed manually. 2. Automated logging of trouble tickets for outage of devices monitored by NMS. 3. Analysis of effects of outage on rest of the network. 4. Automated mapping of outage incidents to production (impact). 5. Automated escalation of trouble tickets to the respective teams as per escalation matrices. 6. Automated follow-up for escalations via E-mail. 7. Service Level Management with link service providers. 8. Mapping of link-outages on a DLCI basis. 9. Automated report generation with the ability to export the data to Microsoft® Excel®. 10. Integration with SMS gateways to send SMS alerts for escalations in future.

Review of Axios Assyst: 1. Axios Systems is a medium-sized company based in Edinburgh, Scotland with a medium-sized customer base. 2. Assyst includes modules for Incident Management, Problem Management, Change Management, and Configuration Management. 3. Assyst is a reasonably strong tool. The Graphical User Interface (GUI) looks a bit unattractive, but does the job well enough. 4. Assyst has a reasonable amount of customisation allowing administrators to re-label fields and add new fields, but does not allow individual users to tailor the product. 5. Assyst interfaces to all the major alerting tools and can generate incidents from alerts received. It uses a traffic light arrangement to alert the user of possible or existing SLA breaches.

6. A web front end is available that works well with the main product, providing some of the functionality seen in the main client. 7. Overall, Assyst is a solid product that is capable of doing the job well.

Review of Peregrine Service Centre: 1. Peregrine is a medium-sized company operating out of Richmond, Surrey. In India, CMS is the reseller for Peregrine products. 2. Service Centre includes modules for Incident Management, Problem Management, Change Management, & Configuration Management. 3. Service Centre is highly customisable and as such allows the users to decide the best way to make use of the product. However, this is not as easy as in some products, and can require a fair amount of consultancy. 4. Service Centre is strictly based around ITIL and tries to stick to these guidelines as best as possible. Therefore, the product is fully integrated and all the modules link together very effectively, with the linking of incidents to problems as well as changes. 5. Service Centre interfaces to most monitoring tools and can raise incidents via any alerts that are received. 6. Service Centre has a good front end, which works well with the product, and the web front end also relates well to the main client. 7. Overall, Peregrine Service Centre is a fairly good tool capable of doing the job well. Review of HP OpenView Service Desk: 1. HP Service Desk is only sold through resellers and not through HP. We contacted Network Solutions, one of HP resellers for details of Service Desk. 2. Service Desk seems a particularly strong tool. The GUI takes its look and feel from Microsoft Outlook, and as such it feels familiar the moment it is out of the box, and this can help to reduce training costs.

3. Service Desk consists of Incident Management, Problem Management, Change Management, Service Level Management, and Configuration Management. Each of these modules is highly customisable to meet individuals and the organisation’s needs. 4. Service Desk will only run on Windows NT or Windows 2000. There is a Windows 98 version, but that it is not very reliable. 5. Service Desk is sold with either an Oracle or SQL server database (neither licence price is included), which makes support for the database much easier due to most companies having in house SQL or Oracle DBAs already in place. 6. The Help Desk module is neat and compact, and works well out of the box, and once some tailoring has been completed it can be made to meet the organisation’s needs exactly. 7. Escalation is controlled via the Service Level Management module, with alerts of breaches, or potential breaches, reaching the user by a variety of means; e-mail, on screen alerts, pages, SMS text messages or other formats. 8. Problem Management interfaces to the Help Desk module to allow multiple incidents to be associated with problems, as well as allowing incidents to resolve problems or cause problems. 9. The Change Management module is well ordered and a project can be generated to show multiple, dependent changes, simplifying the process of tracking these changes. 10. Service Desk interfaces to HP OpenView NNM and all the other major monitoring packages such as BMC Patrol and can generate incidents from alerts received from these packages. 11. The one area where Service Desk is weak is the lack of a ready-made Known Error database. This means that it is not completely ITIL compliant and could be a problem for some organisations. 12. However, with the level of customisation that is available, this should not be a problem as an organisation can create it’s own Known Error database through the utilisation of custom-made fields.

13. There is not enough ‘out of the box’ definition of escalation paths, which would lead to more initial customization than desirable. 14. A web front-end is available, which has a lot of the functionality of the main client. 15. Overall, Service Desk is a sound product with some excellent features.

Annexure

Call Center Traffic Modeling and Resource Allocation

Introduction Traffic, whether cars, customer lines or telephone calls, share similar characteristics. Traffic may be very busy and move slowly, or stop and wait, or it may be light and experience no delays. Highways, toll booths, telephone lines and bank tellers may be either underutilized, causing costly idle times, or overloaded, generating long delays and providing poor service. Analysts must find the right number of resources - toll booths, bank tellers, support agents and telephone lines - to provide adequate service at reasonable costs. Traffic modeling analyzes traffic patterns and determines the necessary resources to handle that traffic. Traffic modeling originated in the telephone industry, and many of the theories still in use today were developed between 1909 and 1917 by the Danish mathematician Agner Krarup Erlang.

Traffic Models Basic Definitions Sources and Servers Traffic modeling involves sources generating service requests and servers that fulfill these requests. In a telephone switch, sources are callers and the servers are the telephone company's resources that provide the dial tone and rout calls to their destination. In a bank, customers are sources, and tellers are the servers. Traffic modeling assumes that there is very large number of sources R requesting service, and a limited number of servers N. The number of sources is significantly larger than the available servers, so that virtually R--> infinity. In addition, we assume that: The sources generate random service requests independently of each other. 

The average number of service requests per time unit from all sources is constant.



Service requests arrive at intervals that follow a Poisson distribution (see below).



The time required to service a request is distributed exponentially (see below), and is independent of the arrival rate.



Service is provided on a first-in, first-out (FIFO) basis; that is, service requests are honored in the order in which they arrive.

Traffic Volume and Intensity The volume of traffic is determined by the number of service requests per time unit and the time that each service request consumes. For instance, with an arrival rate of 100 calls per hour, with each call requiring 9 minutes (0.15 hour) of service, the traffic volume in an 8-hour day is: 100 * 0.15 * 8 = 120 Call Hours (Ch) Erlang units represent traffic intensity or load as traffic volume per time unit. One Erlang equals one Ch/hour, so the traffic load in the previous example is 120 / 8 = 15E. An Erlang may be defined thus as: one telephone line carrying traffic for one hour carries one Erlang of traffic. How Calls Arrive in a Call Center A naive approach to figuring out the number of agents needed in a call center is to divide the number of calls expected to arrive in an hour by the average length of the calls. For example, if 100 calls arrive in one hour, and each call takes, on the average, 15 minutes to service, then each agent can take 4 calls per hour. Therefore, it appears that 25 agents and 25 telephone lines should be able to service the anticipated call load. The flaw in this logic is that service requests do not arrive in an orderly fashion one right after the other. Like customers at a bank, telephone calls arrive at random times and independent of each other. The average arrival rate in the example above is 15 minutes, but the actual arrival time is distributed randomly: some calls will arrive at the same time, some will come in while other calls are still being served, and during periods of the day no calls will arrive at all. The probability of call arrival is approximated by a Poisson process:

A Poisson probability distribution (Figure 1) is similar to a normal, bell-shaped distribution skewed to the right, with the peak of the curve before the mean arrival time. This means that more calls arrive during a period that is shorter than the average call length, and few take much longer than the average time to arrive. The duration of service requests is not uniform either. Call lengths are distributed exponentially, and as Figure 2 shows, most calls are shorter than the average call, but some are much longer than the average. 58

Once the phone lines have filled to capacity and all servers are busy, there is an equal probability of a call ending and a new call starting, reaching a Stochastic Equilibrium - the statistical theory that is the basis for traffic modeling. Erlang B model Erlang B is a "blocked calls lost" model, in which, when servers are unavailable, the service requestor is denied service and must retry the request. This is the situation in a telephone switch, where when all resources (telephone trunks) are exhausted, the caller receives a busy signal and must hang up and redial repeatedly until a server becomes available. Erlang B calculates the blocked call probability (loss probability) for a given traffic load and a number of servers. P B(N,A) is the probability that a caller will receive a busy signal with a traffic load of A Erlangs and N telephone trunks.

Calculating blocking probability is straightforward using Erlang B tables. Table 1 shows traffic loads that 15 to 25 servers can support with loss probabilities of 1%, 2%, 5% and 10%. For instance, if the anticipated load is 15 Erlangs, and the desired blocking probability is 2% or better, the number of telephone lines (and agents) to support it is 23. If resources are at a premium and degradation in service to blocking probability of 10% is acceptable, the number of servers can be reduced to 18. Erlang B tables are also available in a different arrangement, giving the blocking probabilities for different traffic load and server combinations. For instance, using Table 2, we can determine that for the given load of 15 Erlangs, a staff of 20 will provide service with a blocking probability of 0.0456 - slightly better than 5%.

Erlang C Model Unlike the Erlang B model, in which blocked service requests are considered lost, in the Erlang C model, requests that cannot be satisfied immediately are delayed until a server is available. The model defines the probability P C(N,A) that a service request will have to wait for service if N agents are assigned to handle traffic of A Erlangs:

Call Center Metrics Call Load The volume and intensity of incoming service requests are the key parameters in determining the call center's resource requirements. Call load is measured in Erlang units, as described earlier. Peak Hour Traffic (PHT), Busy Hour Traffic (BHT) Peak hour is the busiest one-hour period of the day, when incoming service requests are most likely to be delayed or blocked and turned away. This is the load for which resources are calculated. While sufficient resources need to be available to handle peak traffic, it is a good practice to establish traffic arrival and duration patterns during the course of the entire day and each day of the week. Daily traffic should be sampled at half-hour or even 15-minute intervals, because the peak time is unlikely to correspond with the sampling interval and therefore will not be measured correctly. Analyzing resource requirements during different times of the day and all days of the week will allow more specific optimization of daily staff schedules. Average Handling Time (AHT) Average handling time (AHT) defines how long an agent is busy providing service to a single customer call. AHT is the time the agent provides service (talk time) plus wrap-up time - additional activities to complete a call and prepare for the next one.

Average Speed of Answer (ASA) Average speed of answer (ASA) is a commonly used call center metric that defines the average time it takes to answer all telephone calls. In general, averages are acceptable for estimations and trending, but as we saw earlier they cannot described traffic patterns accurately because of the natural distribution of call arrival and duration as explained in the previous section, and many callers will experience delays significantly longer than the average. For instance, a staff of 12 taking 80 calls per hour with AHT of 7 minutes can deliver an average speed of answer of 50 seconds. However, as we will see later, this average figure applies to only 78% of the calls; 22% of the callers will experience longer delays, and some are likely to abandon the queue before their turn arrives. Grade of Service (GoS) Instead of targeting the speed of answer as a single figure of merit, a more appropriate and precise method is to set a desired grade of service, which is the percentage of calls that will be answered within a target threshold. For example, a target grade of service may be for 80% of the calls to be answered within 20 seconds, and for the remaining 20% that will end up waiting, the delay will be no longer than 2 minutes. The model should establish the staffing level and telephone lines that are required to support that grade of service. As importantly, it should ascertain how many callers will miss the 20 second target and what will their experience be: how long they will have to wait to receive service and how many are likely to abandon the call prematurely. Putting it Together: Determining Resource Levels In call centers, designers must establish the right number of agents and allocate the right number of telephone lines, balancing the desired level of service against the availability and operational costs of these resources.

Telephone Lines The computation of the required telephone trunks is based on the Erlang B model. The target blocking probability depends on the service model employed in the call center. If the call center is designed for a "loss" model, where calls that cannot be serviced immediately are diverted to a voice-mail service or simply receive a busy signal, use Erlang B tables to find out the number of telephone trunks that will provide an acceptable level of service. A blocking probability of 5% or better is usually adequate. But few call centers can afford the staff (and telephone lines) to operate in a "blocked calls lost" mode without periodically turning away customers, and therefore must employ a queuing system and enough telephone trunks to allow callers to hold

for as long as they wish. In practice, it is impossible to place an infinite number of calls on hold, so the number of lines is set so that only in rare cases will callers be denied the opportunity to wait for service and receive a busy signal. Use Erlang B tables to find the number of lines that provide a sufficiently low blocking probability. The examples in the following discussion were calculated to deliver a loss probability of 0.001 (0.1%), although 1% should suffice in most cases.

Staffing Since in the Erlang C model some calls are always queued, the first step in determining staffing levels is to establish a target grade of service. Calculating staffing levels to support that target is an iterative process and is most easily carried out using an Erlang C software program or spreadsheet. Fig 3 shows output of an Erlang C calculator. The GoS is defined as 80% of calls should be answered within 60 seconds. The maximum allowed wait time is 120 seconds, after which we assume callers will abandon the queue. The expected call volume is 100 calls/hour, and the Average Handling Time is 540 seconds. Using the Erlang C formula, the software calculates the GoS for ten different phone line and staff combinations and shows in row 10 that the minimum staff that meets or exceeds the specified GoS is 19. This staff, equipped with 29 telephone trunks, will be able answer 86% of the calls within 60 seconds, with an average speed to answer of 33 seconds. As staff is an expensive resource, slightly degraded GoS can be provided with a staff of 18, answering 76% of the calls within the target of 60 seconds, but at a significantly worse ASA of 65 seconds (see row 8). Notice that a mere 5% saving in manpower has doubled the ASA.

In addition, the Erlang calculator shows the following parameters: % Abandoned - the percentage of callers expected to abandon the call while waiting in the queue. This number is calculated based on Queue Time. Queue Time - the average waiting time callers will have to wait in the queue to receive service. % Queued - the percentage of calls that will not be answered within the target speed of answer and will be queued. Queue Depth - average number of calls waiting in queue. Utilization - percentage of agent's time spent servicing calls. If Erlang software is unavailable, similar results, albeit not as detailed, can be computed using Erlang C tables similar to the one shown in Table 3. We will use the same GoS that targets 80% of the calls to be answered within 60 seconds, maximum wait time of 120 seconds, and traffic intensity of 15 Erlangs. 1. Calculate the Queue Factor (QF), which is the maximum time a call can spend in the queue and still meet the maximum wait target: QF = MaxWait / AHT QF = 120 / 540 = 0.222 2. Locate the section in the table for traffic load of 15 Erlangs. 3. Locate the row that has the same or higher QF to find staffing level. The nearest higher QF is 0.25. Looking across the row, the required staff is 19. 4. Use the selected QF (0.25) and the percentage of queued calls (Q), which in this case is 0.244, to calculate the ASA: ASA = AHT * Q * QF ASA = 540 * 0.244 * 0.25 = 33 seconds Non-Linearity A critical factor many back-of-the-envelope analysts miss is that due to the statistical nature of calls arrival and queuing discussed above, changes in resources have a non-linear effect on staffing levels and GoS. For example, a change of 10% in staffing will not result in 10% change in ASA, wait time, or the number of required telephone lines. We

have already seen evidence of this effect earlier when a reduction of 5% in staff doubled the ASA. Figure 4 shows the non-linear relationships between staffing level and ASA. The more agents the call center employs the better average speed of answer it can provide, but at the cost of decreased utilization. The call center designer may have to compromise the level of service in order to manage with limited resources and maintain reasonable utilization. Increasing staffing also improves the service given to callers who do not receive immediate service and have to spend time in a queue. As more staff is available to take calls, the number of calls in the queue decreases (Figure 5), as does the average queue wait time (Figure 6). Analysis of waiting times and call abandonment patterns shows that the average time that callers spend in queue is exponentially distributed around the average queue time. Because queue time is critical in controlling the abandonment rate, resources can be allocated to minimize queue wait time. Telephone trunk requirements are also non-linear, but behave more like the step function shown in Figure 6. Once sufficient trunks are available to support the desired grade of service, adding trunks has no impact, as the level of service becomes gated by the availability of agents. Number of Queues It is a common practice in call centers to split incoming calls and route them to specialized groups or individuals, where they queue separately. However, despite what may be intuitively logical, this practice is usually less efficient. With a smaller number of calls and servers per queue, the statistical distribution of service traffic decreases the efficiencies in each queue, thereby decreasing the overall efficiency. Table 4 compares the anticipated staffing and utilization rates for a one, two and three queue help desk. Limitations of Erlang Models The standard Erlang C model assumes certain capabilities and behaviors that are not always met in the real world. For example, the model assumes that callers will be willing to wait forever to be answered by an agent. In practice, however, some callers will hang up the phone as soon as they are put on hold, and others will

abandon the call after waiting in the queue for some time. Some callers will redial right away in hope to beat the system. These human behavior patterns will change the actual call statistics and the performance of the call center overall. The standard model also assumes that the call center has unlimited queuing capability. In practice, queuing resources are limited and when the system is overloaded, exceeding its queuing resources, callers will receive a busy signal or be connected to a voice-mail service. Automatic Call Distribution (ACD) systems can employ various strategies to lower the probability of this happening by overflowing calls to another agent group, or implementing a ring delay where the number of rings before the ACD picks up the line increases proportionally to the number of queued calls. Other considerations that have a significant impact on resources are the call center's call flow management and its problem resolution capabilities. Employing a dispatching strategy in which a clerk logs the call and a subject matter analyst later returns it, changes many of the assumptions made by the basic Erlang models. This approach shortens the duration of inbound calls and evens their distribution, and at the same time generates a significant number of outbound calls. The Erlang model treats all servers as non-human resources. It assumes that they are always available and work at maximum capacity. While this is adequate for telephone lines, a reliable call center model must account for vacation and sick time as well as for training, meetings and other work, which may decrease utilization by 15% or more. Various adaptations of the standard Erlang method exist to account for some of these issues, especially the infinite queuing problem. However, because of the complexity of the subject and the lack of a wide theoretical and practical base, these special versions should to be used sensibly. In very large call centers, where approximations and rounding errors may result in significant numbers, simulation can offer a good substitute or a complementary analysis method.

Bibliography 1. Gartner Research Note, Adopting an ESP Business Model, C. Young, April 27, 2001. 2. Gartner Research Note, Key Competencies for Service-Based Organizations, M. Gerrard and B. Gomolski, Sept. 10, 2001.

3. HP IT Service Management White Paper, Transforming IT organizations into service providers, June 30, 2003. 4. Axios Systems White Paper, Do you speak ITIL?, March 31, 2004. 5. IT Service Management Forum Website http://www.itsm.info 6. ITIL Official Website http://www.itil.co.uk 7. Axios Systems Website http://www.axiossystems.com 8. ITIL People Website http://www.itil-people.com 9. HP OpenView Website http://www.hp.com/open 10. Peregrine Website http://www.peregrine.com 11. Pink Elephant Website http://www.pinkelephant.com 12. Diagnostic Strategies Website http://www.diagnosticstrategies.com