Support Center – Managing and Analyzing
Contents INTRODUCTION ....................................................................................................................... 7 WHAT IS ITIL? .......................................................................................................................... 7 REASONS FOR IMPLEMENTATION....................................................................................... 8 IMPLEMENTING ITIL ................................................................................................................ 9 IMPLEMENTATION OF SERVICE STRATEGY .................................................................... 10 IMPLEMENTING SERVICE DESIGN ..................................................................................... 11 IMPLEMENTING SERVICE TRANSITION ............................................................................. 15 IMPLEMENTING SERVICE OPERATION ............................................................................. 18 IMPLEMENTATION OF CSI ................................................................................................... 23 CASE STUDIES ...................................................................................................................... 26 THE IT SERVICE MANAGEMENT ITIL V3 BENCHMARK CHECKLIST ............................. 27 SERVICE STRATEGY - THE PRACTICE OF SERVICE MANAGEMENT ........................... 28 SERVICE DESIGN - SERVICE MANAGEMENT AS A PRACTICE ...................................... 34 SERVICE TRANSITION - SERVICE MANAGEMENT AS A PRACTICE ............................. 43 SERVICE OPERATION - SERVICE MANAGEMENT AS A PRACTICE .............................. 51 CONTINUAL SERVICE IMPROVEMENT- SERVICE MANAGEMENT AS A PRACTICE ... 60 CONCLUSION ......................................................................................................................... 66 CUSTOMER SERVICE ........................................................................................................... 68 INSTANT FEEDBACK .......................................................................................................................... 69 SETTING THE RIGHT KPIS ................................................................................................................ 69 CUSTOMER SERVICE - AN IMPERATIVE ........................................................................... 69 GOLDEN RULE #1: PUT THE CUSTOMER FIRST .............................................................................. 70 GOLDEN RULE #2: STAY CLOSE TO YOUR CUSTOMERS ............................................................... 70 GOLDEN RULE #3: PAY ATTENTION TO THE LITTLE DETAILS ........................................................ 71 CONCLUSION..................................................................................................................................... 71 FIVE RULES OF CUSTOMER CARE .................................................................................... 71 CHOOSING THE RIGHT CUSTOMER SERVICE REPRESENTATIVES ............................. 72 SIGNIFICANT POINTS ........................................................................................................................ 73 NATURE OF THE W ORK .................................................................................................................... 73 WORK ENVIRONMENT. ...................................................................................................................... 75 TRAINING, OTHER QUALIFICATIONS, AND ADVANCEMENT ............................................................. 75 Education and training. .............................................................................................................. 76
Page 1
Support Center – Managing and Analyzing Other qualifications. .................................................................................................................... 76 Advancement. .............................................................................................................................. 77 EMPLOYMENT.................................................................................................................................... 77 JOB OUTLOOK ................................................................................................................................... 77 Employment Change. ................................................................................................................. 77 Job prospects. ............................................................................................................................. 78 PROJECTIONS DATA ......................................................................................................................... 79 EARNINGS ......................................................................................................................................... 79 RELATED OCCUPATIONS .................................................................................................................. 80 DIFFERENTIATING YOUR ORGANIZATION THROUGH CUSTOMER FOCUS ................ 80 THE CUSTOMER FOCUS MODEL ........................................................................................ 83 THE CUSTOMER FOCUS APPROACH ................................................................................ 84 CONCLUSION..................................................................................................................................... 85 HIRING THE BEST CUSTOMER SERVICE REPRESENTATIVES ...................................... 85 THE INTERVIEW AND SELECTION PROCESS ................................................................... 85 SAMPLE CUSTOMER SERVICE FOCUSED INTERVIEW QUESTIONS ............................ 92 INTERVIEWING....................................................................................................................... 95 TIPS ON INTERVIEWING ....................................................................................................... 96 CHECKING REFERENCES .................................................................................................... 99 RECORDING A PROFILE OF IMPRESSIONS .................................................................... 101 RECRUITING ......................................................................................................................... 101 ASSESSING YOUR RECRUITMENT AND SELECTION PRACTICES .............................. 104 APPENDIX SAMPLE CUSTOMER SERVICE PLAN .......................................................... 106 ACME CUSTOMER SERVICE PLAN................................................................................................ 106 BACKGROUND ............................................................................................................................ 106 EXECUTIVE ORDER ................................................................................................................... 106 PRINCIPLES ................................................................................................................................. 107 APPROACH/SCOPE ................................................................................................................... 108 OUR CUSTOMERS...................................................................................................................... 108 STANDARDS ................................................................................................................................ 108 Process Attributes ..................................................................................................................... 109 Quality Attributes ....................................................................................................................... 109 ORGANIZATION-WIDE STANDARDS ..................................................................................... 110 FUTURE EFFORTS ..................................................................................................................... 111 INCIDENT MANAGEMENT INTRODUCTION ROADMAP ................................................. 112 INCIDENT MANAGEMENT PRESENTATION ..................................................................... 113 SUPPORTING DOCUMENTS ............................................................................................... 130
Page 2
Support Center – Managing and Analyzing BUSINESS JUSTIFICATION DOCUMENT .............................................................................. 130 OBJECTIVES AND GOALS ........................................................................................................ 133 POLICIES OBJECTIVES AND GOALS ..................................................................................... 136 INCIDENT CATEGORY DEFINITION ....................................................................................... 138 COMMUNICATION PLAN ........................................................................................................... 152 INCIDENT MANAGEMENT PROCESS FLOW ........................................................................ 156 REPORTS KPI‘S AND METRICS ............................................................................................... 156 INCIDENT TICKET TEMPLATE ................................................................................................. 160 INCIDENT MANAGEMENT PROCESS .................................................................................... 168 IMPLEMENTATION AND PROJECT PLAN ............................................................................. 170 INTRODUCTION ................................................................................................................... 178 INTRODUCTION TO SERVICE DESK ................................................................................................ 197 INTRODUCTION TO INCIDENT MANAGEMENT ................................................................................. 200 INTRODUCTION TO PROBLEM MANAGEMENT ................................................................................ 202 SUPPORT AND RESTORE .................................................................................................. 205 SERVICE DESK ................................................................................................................................ 205 INCIDENT MANAGEMENT ................................................................................................................ 230 PROBLEM MANAGEMENT................................................................................................................ 247 SERVICE DESK – REVIEW .................................................................................................. 270 INCIDENT MANAGEMENT – REVIEW ................................................................................ 273 PROBLEM MANAGEMENT – REVIEW ............................................................................... 278 ASSIGNMENTS ..................................................................................................................... 284 ASSIGNMENT 1 – SERVICE DESK................................................................................................... 284 ASSIGNMENT 2 – INCIDENT MANAGEMENT ................................................................................... 284 ASSIGNMENT 3 – PROBLEM MANAGEMENT .................................................................................. 285 ASSIGNMENT RESOURCES ............................................................................................... 287 CASE STUDY – RECE SHOE COMPANY ....................................................................................... 287 EXAM PREPARATION ......................................................................................................... 297 FURTHER READING ............................................................................................................ 308 SERVICE DESK INTRODUCTION ROADMAP ................................................................... 308 SERVICE DESK PRESENTATION ...................................................................................... 310 SUPPORTING DOCUMENTS ............................................................................................... 320 SERVICE DESK FACTSHEET ................................................................................................... 321 BUSINESS JUSTIFICATION DOCUMENT .............................................................................. 324 POLICIES OBJECTIVES AND SCOPE..................................................................................... 327 OBJECTIVES AND GOALS ........................................................................................................ 330 SERVICE DESK MANAGER ROLE ........................................................................................... 332
Page 3
Support Center – Managing and Analyzing EMAIL TEXT .................................................................................................................................. 334 BUSINESS AND IT FLYERS....................................................................................................... 336 OUTSOURCING TEMPLATE ..................................................................................................... 336 COMMUNICATION PLAN ........................................................................................................... 349 REPORTS KPI‘S AND METRICS ............................................................................................... 353 SERVICE DESK TECHNOLOGY ............................................................................................... 358 IMPLENTATION AND PROJECT PLAN .............................................................................. 371 SERVICE DESK INTRODUCTION ROADMAP ................................................................... 379 SERVICE DESK ITIL V3 PRESENTATION ......................................................................... 382 SUPPORTING DOCUMENTS ............................................................................................... 393 SERVICE DESK ROLE AND RESPONSIBILITIES .............................................................................. 393 SERVICE DESK TECHNOLOGY........................................................................................................ 395 SERVICE DESK OUTSOURCING TEMPLATE ................................................................................... 411 SERVICE DESK METRICS................................................................................................................ 427 COMMUNICATION PLAN .................................................................................................................. 429 BUSINESS FLYERS .......................................................................................................................... 434 SERVICE DESK OBJECTIVES AND GOALS ..................................................................... 436 POLICIES OBJECTIVES AND SCOPE ............................................................................... 440 IMPLEMENTATION PLAN AND PROJECT PLAN ............................................................. 444 BUSINESS JUSTIFICATION DOCUMENT .......................................................................... 454 SERVICE LEVEL MANAGEMENT INTRODUCTION ROADMAP ...................................... 458 SERVICE DESIGN ................................................................................................................ 460 CONTINUAL SERVICE IMPROVEMENT ............................................................................ 479 SUPPORTING DOCUMENTS ............................................................................................... 486 OBJECTIVES AND GOALS ............................................................................................................... 486 POLICIES OBJECTIVES AND GOALS ............................................................................................... 490 SLM SCOPE .................................................................................................................................... 493 BUSINESS JUSTIFICATION DOCUMENT .......................................................................................... 498 ORGANIZING FOR SERVICE DESIGN – ROLES & RESPONSIBILITIES ............................................ 501 SLM PROCESS MANAGER ............................................................................................................. 506 CUSTOMER BASED SLA ................................................................................................................. 508 SERVICE BASED SLA ..................................................................................................................... 514 MULTI LEVEL SLA‘S ....................................................................................................................... 520 BUSINESS AND IT SERVICE MAPPING ........................................................................................... 526 OPERATIONAL LEVEL AGREEMENT................................................................................................ 537 SERVICE LEVEL REQUIREMENTS ................................................................................................... 541 SERVICE OPTIONS .......................................................................................................................... 547 UNDERPINNING CONTRACTS ......................................................................................................... 551
Page 4
Support Center – Managing and Analyzing FUNCTIONAL SPECIFICATION ......................................................................................................... 554 TECHNICAL SPECIFICATION............................................................................................................ 560 PRICE LIST ...................................................................................................................................... 565 COMMUNICATION PLAN .................................................................................................................. 567 REPORTS KPI‘S OTHER METRICS ................................................................................................. 574 SLM IMPLEMENTATION & PROJECT PLAN ..................................................................... 577 FURTHER INFORMATION ................................................................................................... 585
Notice of rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Notice of Liability The information in this book is distributed on an ―as is‖ basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it. Trademarks Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book.
Page 5
Support Center – Managing and Analyzing
Write a review to receive any free eBook from our Catalogue $99 Value! If you recently bought this book, we would love to hear from you! Benefit from receiving a free eBook from our catalogue at http://www.emereo.org/ if you write a review on Amazon (or the online store where you purchased this book) about your last purchase! How does it work? To post a review on Amazon, just log in to your account and click on the Create your own review button (under Customer Reviews) of the relevant product page. You can find examples of product reviews in Amazon. If you purchased from another online store, simply follow their procedures. What happens when I submit my review? Once you have submitted your review, send us an email at
[email protected] with the link to your review, and the eBook you would like as our thank you from http://www.emereo.org/. Pick any book you like from the catalogue, up to $99 RRP. You will receive an email with your eBook as download link. It is that simple!
Page 6
Support Center – Managing and Analyzing
Introduction Even after 13 years in IT Service Management consultancy, I still get questions from clients about the duration of ITIL®i implementation projects. It seems that a lot of people ‗out there‘ still seem to think that an ITIL implementation project is similar to the rollout of Microsoft Visio in the entire office, or a server upgrade. Many people – even project managers and IT directors, seem to compare ITIL Service Management implementation with the implementation of ‗off the shelf‘ software. This Guide is created to make you – the reader – think about different reasons why implementing ITIL Service Management can NOT be successful with an ‗out of the box‘ approach and mindset. ITIL Service Management only touches on technology, and it is not a piece of software. ITIL Service Management implementation – when performed successfully – will structurally change your organisation, your staff performance, your customer satisfaction and overall delivery capability. But before we go into that... let‘s start at the beginning: What exactly is ITIL?
What is ITIL? Since its inception in the late 1980‘s ITIL® has been the framework of choice for many IT organisations across the world. In fact, it has been so popular that ITIL certification is a stated requirement in most Job Advertisements for IT related roles and the framework is taught at Universities as part of their Post-graduate and MBA programs. As a result of industry involvement and the rapidly growing maturity of the IT industry at large, ITIL is now in its 3rd version.
The ITIL V3 framework consists of a library of books that cover the 5 phases of the Service Lifecycle:
Book title
Content – main focus of this phase in the lifecycle
Service Strategy
Discusses the reason WHY the IT service is needed, and to what extent the service would be needed by the customers.
Service Design
Design consideration and Quality criteria for the Service that is to be created AND the environment that is required to support the service to the
Page 7
Support Center – Managing and Analyzing customer‘s needs. Service Transition
Control and risk mitigation strategies while the new – or changed – service is moved into the Production environment.
Service Operations
Activities and departments that are needed to support the IT Services on an ongoing basis to the standards that have been agreed upon with the customer.
Continual Service Improvement
Methodologies for the ongoing improvement of the services, the IT environment and its processes.
One important thing to remember is that ITIL is a FRAMEWORK, it is not a prescriptive set of checklists, nor is it a standard. The ITIL books provide the reader with guidelines on what is generally considered to be good practice (based on 20+ years of experience). The processes described in the books are aimed at the management of activities in an IT organization, irrespective of company size and technology use. The processes are completely independent of any type of hardware or software that is (or will be) available on the market. In 2005, the International Standards Organisation (ISO) published an independent standard for IT Service Management, called ISO/IEC 20000. This standard consists of BEST PRACTICE requirements (part I) and guidance (part II) for the control and management of Service Management processes in an IT organisation. This standard is mostly based on the ITIL Framework.
Reasons for implementation The reason for the implementation of ITIL Service Management is varied, but most of the companies seem to have the desire to formalize their IT Service Management practices to achieve one or more of the following benefits: • • • • • •
Improve the quality and efficiency of IT Services Comply with management or business requirements Follow global standards Reduce IT Costs Achieve regulatory compliance, or standards certification Address a specific IT Operational issue
The top benefit gained from ITIL implementation is improved customer satisfaction. Other benefits include delivery of IT services in accordance with agreed service levels and improved IT service reliability.ii
Page 8
Support Center – Managing and Analyzing When organisations are implementing ITIL Service Management they usually have a team of 1 – 5 internal staff working on the project on a fulltime basis. Approx. 1/3 of organisations also use 1 – 5 external consultants to support with process design and tool implementation. Factors that contribute to the success of ITIL implementation are:
Senior Management commitment Sufficient Funding Effective Change Management Existence of an ITSM champion Sufficient allocation and provision of ITIL training to IT staff Team commitment
HOWEVER, as visualised in figure 1 below, ITIL is only a small component of IT Service Management. The books only cover guidance on the processes, the activities and some of the associated tools and metrics. The other components of IT Service Management are only briefly touched upon in the ITIL core guidance publications. The other components of IT Service Management (technology, people and organisation) are a crucial part in the successful achievement of the desired deliverables and should be planned for.
Figure 1
Implementing ITIL As mentioned in the previous paragraph, ITIL Service Management is a framework. It is not a software application or generic tool. This in itself brings some implementation challenges to the project organisation... In general, products are easier to implement than frameworks. However, when you begin to implement the ITIL framework, you‘re suddenly faced with decisions about how to fit your existing process model into the ITIL view. Given that your existing processes are embedded inside existing applications, you will be challenged to wire them together. This will take time and a lot of workshops, discussions and heated debates!
Page 9
Support Center – Managing and Analyzing Don‘t expect to find a single best answer. You must use your training to articulate the tradeoffs of different approaches and the limits of the tools you might employ to automate ITIL-based processes. But perhaps, most importantly, you must move stakeholders to commit to their decisions. Because ITIL doesn‘t tell people to work in just one way, people may want to hold their options open as long as possible. If you find yourself in this situation, remind your stakeholders that each project is just a step in a long journey. You may revisit a decision in a future phase. Most companies contemplating an ITIL implementation have developed a methodology to execute projects. Fewer companies have mechanisms for managing groups of related projects over multiple years (and don‘t forget that your key people might actually change company during the time that you are working on the implementation project). You will have to engage in ongoing awareness campaigns and education programs. Given that ITIL implementations very often span years and projects typically have shorter durations, you may want to create a team that exists beyond the lifespan of an individual project--a program group. The program group's responsibility is to ensure continuity of vision during the course of the entire implementation and to arbitrate conflicts between projects running parallel.
Implementation of Service Strategy Strategic positions are converted into plans with goals and objectives for execution through the Service Lifecycle. Figure A outlines the process whereby positions are driven by the Market space service specific customers need to Customer and market spaces and are influenced by strategic perspectives as a service provider. Plans are the positions. They Service Pipeline, delivery schedules, and ensure that each phase in capabilities and resources positions. Clarity and these is provided by the
means of achieving those include the Service Catalogue, Contract Portfolio, financial budgets, improvement programs. Plans will Strategic positions the Service Lifecycle has the necessary to reach strategic Feedback context for the development of Service management Service Lifecycle. plans
Strategic perspective (Depending on Type I, II, III)
Feedback The intent of strategy into action through Service Design, Patterns of execution Service Transition, Service Operation and Service through service life-cycle Improvement is translated through plans. Service Strategy provides input to each phase of the Service Lifecycle and Continual Service Improvement provides the feedback and learning mechanism by which the execution of strategy is controlled.
Page 10
Support Center – Managing and Analyzing
Top Down Within any given market space, Service Strategy defines the portfolio of services to be offered and the customers to be supported (see Figure 3). This, in turn, determines the Contract Portfolio that needs to be supported with design, transition and operation capabilities. The systems, processes, knowledge, skills and experience required at each phase define the lifecycle capabilities. Interactions between service management capabilities are clearly defined and managed for an integrated and systematic approach to service management. The type of transition capabilities required is determined by Service Desk and Operation capabilities. They also determine the portfolio of service design and the operating range of the service provider in terms of models and capacities. Figure 2
Transition capabilities determine the costs and risks managed by a service provider. The capabilities of the service transition phase determine how quickly a service is transitioned from design to operations. Transition capabilities reduce the costs and risks for customers and service providers throughout the lifecycle by maintaining visibility and control over all service management systems and processes. Not only acting as filters, transition capabilities act as amplifiers that increase the effectiveness of design and operation. Transition capabilities interact with service designs to provide new and improved service models. They also interact with operation models and capacity to increase the operational effectiveness of plans and schedules. The net effect is the service levels delivered to customers in fulfilment of contracts. Service providers and customers each face strategic risks from uncertainties. It is impossible to either control or predict all the factors in a business environment. The risks may translate into opportunities or challenges depending on the alignment between service management capabilities and the emergent needs of customers. Continual Service Improvement is required for Service Strategy to drive feedback through the Lifecycle elements to ensure that challenges and opportunities are not mismanaged (Figure 4). Figure 3
New strategic positions are adopted based on patterns that emerge from executing the Service Lifecycle. In order to form a closed-loop planning and control system for service strategies, bottom-up development of Service Strategy is combined with the traditional topdown approach (Figure 5). Such feedback and learning is critical to the success factor for service management to drive changes and innovation. Figure 4
Implementing Service Design This section considers the task of implementing the Service Design processes and covers issues such as: • Where do we start?
Page 11
Support Center – Managing and Analyzing • How do we improve? • How do we know we are making progress? The activities of implementing and improving Service Design need to be focused on the needs and requirements of the customer and the business. These activities should be prioritized by: • Business needs and business impacts • Risks to the services and processes. The activities will be dictated by the requirements documented in the Service Level Requirements and the Service Level Agreements. Business Impact Analysis The BIA is an ongoing source of valuable input when trying to establish business needs, impacts and risks. It is an essential tool used by the overall Business Continuity process and will dictate the strategy for risk reduction and disaster recovery. The BIA will show which parts of the organization will be effected by a major incident and what effect that will have on the company as a whole. This in turn identifies the most critical business functions on which the company‘s survival depends. In addition, data from the BIA can provide valuable input in to a number of other areas as well and enables a greater understanding of the service that would have otherwise been available. The BIA can be divided into two areas: •
•
Business Management; which has to investigate the impact of the loss of a business process or a business function. This would also include the knowledge of manual workarounds and the associated costs. Service Management; it is essential to break down the effects of service loss to the business. This element of the BIA shows the impact of service disruption to the business. The services can be managed and influenced by Service Management. Other aspects also covered in ‗Business BIA‘ cannot be influenced by Service Management.
As part of the design phase of a new or changed service, a BIA should be conducted to help define the business continuity strategy and to enable a greater understanding about the function and importance of the service. This will enable the organization to define: • Which are the critical services, what constitutes a major incident on these services, and the subsequent impact and disruption caused to the business – important in deciding when and how to implement changes • Acceptable levels and times of service outage levels – also important in the consideration of change and implementation schedules • Critical business and service periods – important periods to avoid • Cost of loss of service – important for Financial Management • Potential security implications of a loss of service – important consideration in the management of risk.
Page 12
Support Center – Managing and Analyzing Service Level Requirements (SLR’s) SLR‘s for all services will be identified and the ability to deliver against these requirements assessed and finally agreed in a formal Service Level Agreement. For new services, the requirements must be identified at the beginning of the development process, not after completion. Building a service with the SLR‘s leading the way is an essential factor from a Service Design perspective. Risks to the Service and Processes When implementing the Service Design phase and ITSM processes, business-as-usual practices must not be adversely affected. This aspect must be considered during the production and selection of the preferred solution to ensure that disruption to operational services is minimized. The assessment of risk should then be considered in detail during the Service Transition phase activities as part of the implementation process. Implementing Service Design The process, policy and architecture for the design of services outlined in this publication will need to be documented and utilized to ensure the appropriate innovative IT services can be designed and implemented to meet current and future agreed business requirements. The question often asked is ‗which process do I implement first?‘ The most correct answer is all of them, as the true value of implementing all of the Service Management processes is far greater than the sum of the individual processes. All of the processes are interrelated, and in some cases are totally dependent on others. What is ultimately required is a single, integrated set of processes, providing management control of a set of IT services throughout their entire lifecycle. However, in reality it is unlikely that organizations can do everything at once. In this situation it is recommended that the areas of greatest need are addressed first. A detailed assessment needs to be undertaken to ascertain the strengths and weaknesses of IT service provision. This should be undertaken by performing customer satisfaction surveys, talking to customers, talking to IT staff and analyzing the processes in action. From this assessment, short to medium and long term strategies can be developed. It may be that ‗quick wins‘ need to be implemented in the short term to improve the current situation, but these improved processes may have to be discarded or amended as part of the medium to long term strategies. If ‗quick wins‘ are implemented, it is important that they are not done at the expense of the long-term objectives, so these must be considered at all times. However, every organization will have to start somewhere, and the starting point will be wherever the organization is now in terms of IT Service Management maturity. Implementation priorities should be set against the goals of a Service Improvement Plan (SIP). Throughout the implementation process, key players must be involved in the decision making process. There can be a tendency, when analyzing the areas of greatest need, to go straight for tools to improve the situation. Workshops or focus groups will be beneficial in understanding the requirements and the most suitable process for implementation that will include people, processes, products and partners.
Page 13
Support Center – Managing and Analyzing Step one is to establish a formal process, method of implementation and improvement of Service Design, with the appropriate governance in place. This formal process should be based around the six stage process of the Continual Service Improvement cycle. It is important that when implementing or improving processes a structured Project Management method is used. The improvement process can be summarized as understanding the vision by ascertaining the high-level business objectives. The ‗visionsetting‘ should set and align business and IT strategies and assess the current situation to identify strengths that can be built on weaknesses that need to be addressed. The following are key elements for successful alignment of IT with business objectives: • • • • • • • •
Vision and leadership is setting and maintaining strategic direction, clear goals, and measurement of goal realization in terms of strategic direction Acceptance of innovation and new ways of working Thorough understanding of the business, its stakeholders and its environment IT staff understanding the needs of the business The business understanding the potential Informational and communication available and accessible to everyone who needs it Separately allocated time to familiarize with the material Continuous tracking of technologies to identify opportunities for the business.
The implementation/improvement cycle is useful in checking the alignment between the business and IT.
Measurement of Service Design The success of the Service Design phase and the success of the improvement to the processes around Service Design must be measured; the data must be analyzed and reported on. Where the design or process does not meet the requirements of the business as a whole, changes to the process may be required and the results of the changes must also be measured. Continuous measurement, analysis and reporting are mandatory requirements for both the Service Design process and the ITSM processes. There are measurement methods available that enable the analysis of service improvement. The Balanced Scorecard is a method developed by Robert Kaplan and David Norton as a concept for measuring company activities in terms of its vision and strategies. It gives a comprehensive view of the performance of the business. The system forces managers to focus on the important performance metrics that drive success. It balances a financial perspective with customers, internal process and learning and growth perspectives. More information can be found on the Balanced Scorecard at www.scorecardsupport.com Six Sigma is a methodology developed by Bill Smith at Motorola Inc. in 1986. It was originally designed to manage process variations that cause defects, defined as unacceptable deviation from the mean or target, and to systematically work towards managing variation to eliminate those defects. Six Sigma has now grown beyond defect
Page 14
Support Center – Managing and Analyzing control and is often used to measure improvement in IT process execution. More information can be found on Six Sigma at http://www.isixsigma.com Six Sigma (DMADV) is an improvement system used to develop new processes at Six Sigma quality levels and is defined as: Define – formally define the goals of the design activity that are consistent with customer demands and organization strategy Measure – identify Critical Success Factors, capabilities, process capability and risk assessment Analyze – develop and design alternatives, create high level design and evaluate capability to select the best design Design – develop detailed design, optimize design and plan for design verification Verify – set up pilot runs, implement production process and hand over to process owners. This process is an improvement system for existing processes falling below specification and looking for incremental improvement.
Prerequisites for Success There are several prerequisites needed for the Service Design phase and the successful introduction of new or revised processes. Often these prerequisites for success are elements of one process required by another. For example, fully completed and up-to-date Business Service Catalogue and Technical Service Catalogue are required before Service Level Management can design the SLA and supporting agreement structure, and before SLM can set up and agree the SLA‘s. Problem Management will depend on a mature Incident Management process. The prerequisites for success can be much wider than just ITSM process interdependencies. For example, the design of availability and capacity for a new service cannot be achieved without details of the business plan for the utilization of the new service. The design of service will be impossible without the Service Portfolio and Service Transition pack. There are more examples of these prerequisites for success that need to be considered and planned before high process maturity levels can be achieved. Low maturity in one process will mean that high levels of maturity will not be achievable in other processes.
Implementing Service Transition Implementing Service Transition in an organization when this has not existed before is only likely if a new service provider is being established. Therefore, the task for most service provider organizations will be one of service improvement, a matter of assessing their current approach to the Service Transition processes and establishing the most effective and efficient improvements to make, prioritized according to the business benefit that can be achieved.
Page 15
Support Center – Managing and Analyzing Implementing new or improved Service Transition processes will be a significant organizational change and an introduction of improved services delivered by the service provider. From that context, much of the guidance in this publication on delivering new or changed services is directly applicable to introducing Service Transition itself. In doing so, is in itself, a Service Transition exercise, since it is changing the services delivered by the service provider. Stages of Introducing Service Transition These stages will match those of other services, requiring a justification for the introduction, designing of the Service Transition components and then their introduction to the organization (transitioning) before they can run in normal mode. Justifying Service Transition Service Transition is a key contributor to the service provider‘s ability to deliver quality services to the business. It is the delivery mechanism between the work of design, and the day-to-day care delivered by operations. However, Service Transition processes are not always visible to customers, and this can make financial justification difficult. When setting up Service Transition, attention needs to be paid to ways of quantifying and measuring the benefits, typically as a balance between impact to the business (negative and positive) and cost (in terms of money/staff resources) and in terms of what would be prevented by applying resources to any specific transition, such as delivering staff resources or delaying implementation. Gathering of evidence on the cost of current inadequate Service Transition is a valid and useful exercise, addressing issues such as: • • •
Cost of failed changes Extra cost of actual transition compared with budgeted costs Errors found in live running that could have been detected during test transition.
Designing Service Transition Useful factors to consider when designing Service Transition are: Applicable standards and policies Consider how agreed policies, standards and legislation will constrain the design of Service Transition. Considerations might include requirements for independence and visible accountability. Relationships Other internal support services: there are many situations when Service Transition must work together with other areas that are transitioning other elements of a business change, such as HR, facilities management, production control, education and training. The processes will be designed to facilitate these relationships. The aim should be to ensure that ownership for each component of the overall service package is defined and subsequently management responsibility is clear.
Page 16
Support Center – Managing and Analyzing Program and project management Major transition may be managed as programs or projects, and Service Transition will deliver their role within the appropriate umbrella. To ensure appropriate transition is delivered, staff will be involved in agreeing key program and project milestones and timelines and Service Transition should be set up to adopt this role. To be effective, Service Transition needs to take a broader view across projects, combining transitions and releases to make the best use of available resources. Internal development teams and external suppliers Communication channels will need to deal with defects, risks and issues discovered during the transition process. Channels to both internal teams and external suppliers will need to be identified and maintained. Customers/user Communication with customers and users is important to ensure that the transitioned service will remain focused on current business requirements. The requirements at actual transition may evolve from the needs identified at design stage and communication channels with the customer will be the source of identifying those changes. Effective communication will benefit from an agreed strategic stakeholder contact map. In many circumstances this communication will be routed through service or account management or Service Level Management, but these channels need to be identified and designed into the Service Transition processes also. Other stakeholders Other stakeholders will need to interface with Service Transition and these should be identified for all foreseeable circumstances, including in disaster recovery scenarios, and so liaison with ITSCM should be created for. Other possible considerations might include: • • •
IT e.g. networks, IT security, data management Outside of IT but within the organization e.g. facilities management, HR physical security Outside of the organization e.g. landlords, police and regulatory bodies.
Budget and resources Funding approach A mechanism for controlling the funding of the transition infrastructure needs to be established, this will need to include: • •
Testing environments SCM and Service Knowledge Management Systems
The costing of transition objectives needs to be an essential inclusion of design. Often the transition options will be costed and a business risk-based decision reached.
Page 17
Support Center – Managing and Analyzing Resources Similar to the issues and options identified in the funding area, supply and control of other resources will need to be addressed within the Service Transition such as: • Staff • Central Infrastructure Test environment management is a major item of expenditure and a significant resource element in many organizations. Under funding/resourcing can cause very expensive errors and problems in supporting live services, and have severe detrimental effects on an organization‘s overall business capability. Risk & Value As with all transitions, decisions around transitioning the transition service should not be made without adequate understanding of the expected risks and benefits. Risks may include: • • •
Alienation of support staff Excessive costs to the business Unacceptable delays to business benefits.
The risks and beneficial values require a baseline of the current situation, if the changes are to be measureable. Measures of the added value from Service Transition might include: • •
•
Customer and user satisfaction Reduced incident and failure rates for transitioned services Reduced cost of transitioning.
Implementing Service Operation This section focuses on generic implementation guidance for Service Operation as a whole. Managing Change in Service Operation The purpose of Service Operation is to achieve stability. Service Operation staff must ensure that changes are absorbed without adverse impact upon the stability of the IT services. Change Triggers There are many things that can trigger a change in the Service Operation environment. They include: • • • •
New or upgraded hardware or network components New or upgraded applications software New or upgraded system software (operating system, utilities, middleware etc. including patches and bug fixes) Legislative, conformance or governance changes
Page 18
Support Center – Managing and Analyzing • •
• • •
Obsolescence – some components may become obsolete and require replacement or cease to be supported by the supplier/maintainer Business imperative – you have to be flexible to work in ITSM, particularly during Service Operation, and there will be many occasions when the business needs IT changes to meet dynamic business requirements Enhancements to processes, procedures and/or underpinning tools to improve IT delivery or reduce financial costs Changes of management or personnel (ranging from loss or transfer of individuals right through to major take-over‘s or acquisitions) Change of service levels or in service provision – outsourcing, in-sourcing, partnerships, etc.
Change Assessment In order to ensure that operational issues are taken into account, Service Operation staff must be involved in the assessment of all changes. This involvement should commence as soon as possible to ensure that they have influence over fundamental decisions. The Change Manager must inform all affected parties of the change being assessed in order for input to be prepared and available prior to Change Advisory Board meetings. It is important that Service Operation staff are involved in the latter stages of the process, as they may be involved in the implementation and wish to ensure that careful scheduling takes place to avoid potential contentions or particularly sensitive periods. Measurement of Successful Change The ultimate measure of the success of changes made to Service Operation is that customers and users do not experience any variation or outage of service. The effects of change should be invisible where possible, aside from any enhanced functionality, quality or financial savings resulting from the change. Service Operation and Project Management Service Operation is often viewed as ‗business as usual‘ and focused on executing defined procedures in a standard way. Because of this, there is a tendency not to use Project Management processes when they would be appropriate. For example, major infrastructure upgrades, or the deployment of new or changed procedures, are significant tasks that should utilize formal Project Management to improve control and manage costs/resources. Using Project Management to manage these types of activity would have the following benefits: • •
• •
The project benefits are clearly stated and agreed There is more visibility of what is being done and how it is being managed, which makes it easier for other IT groups and the business to quantify the contributions made by operational teams This in turn makes it easier to obtain funding for projects that have traditionally been difficult to cost justify Greater consistency and improved quality
Page 19
Support Center – Managing and Analyzing •
Achievement of objectives results in higher credibility for operational groups.
Assessing and Managing Risk in Service Operation There are a number of occasions where it is imperative that risk assessment to Service Operation is undertaken and acted upon quickly. Assessing the risk of potential changes or Known Errors is the most obvious area. Service Operation staff may also need to be involved in assessing the risk and impact of: •
• •
• • •
Failures, or potential failures – either reported by Event Management or Incident/Problem Management, or warnings raised by manufacturers, suppliers or contractors New projects that will ultimately result in delivery into the live environment Environmental risk (encompassing IT Service Continuity-type risks to the physical environment and locale as well as political, commercial or industrial-relations related risks) Suppliers, particularly where new suppliers are involved or where key service components are under the control of third parties Security risks – both theoretical or actual arising from security related incidents or events New customers/services to be supported.
Operational Staff in Service Design and Transition All IT groups will be involved during Service Design and Service Transition to ensure that new components of service are designed, tested and implemented to provide the correct levels of functionality, usability, availability, capacity, etc. During the early stages of Service Design and Service Transition, Service Operation staff must be involved to ensure that when new services reach the live environment, they are fit for purpose and are ‗supportable‘ in the future. In this context, ‗supportable‘ means: • • • • •
Capable of being supported from a technical and operational viewpoint from within existing, or pre-agreed additional resources and skills levels Without adverse impact on other existing technical or operational working practices, processes or schedules Without any unexpected operational costs or ongoing or escalating support expenditure Without any unexpected contractual or legal complications No complex support paths between multiple support departments of third-party organizations.
Note: Change is not just about technology. It also requires training, awareness, cultural change, motivational issues and more. Planning and Implementing Service Management Technologies
Page 20
Support Center – Managing and Analyzing In order to plan for in readiness for, and during deployment and implementation of, ITSM support tools, organizations need to consider the following factors. Licences The overall cost of ITSM tools is usually determined by the number and type of user licences required. Often sold in modular format, the exact functionality of each module needs to be well understood. Initial sizing must be conducted to determine the number and type of users that will need to access each module. Licences are often available in the following types: Dedicated Licences Staff that require frequent and prolonged use of the module will use dedicated licences. For example, Service Desk staff will need a dedicated licence to use an Incident Management module. Shared Licences For staff that make fairly regular use of the module, but not on a day-to-day basis, a shared licence will usually suffice. For example, third-line support staff may need regular access to an Incident Management module, but only when an incident record is being updated. It is important to estimate the ratio of required licences depending on the number of potential users, the length of periods of use and the expected frequency between usages. The cost of a shared licence is usually more expensive than that of a dedicated licence. However, due to the nature of a shared licence, fewer are required and therefore the cost will be less. Web Licences Web licences allow some form of ‗light interface‘ via web access to the tool capabilities. They are usually suitable for staff requiring remote access, occasional access or usage of just a small subset of functionality. For example, engineering staff may wish to log details of actions taken on incidents. The cost of a web licence is usually a lot less than other licences, as the ratio of use is often much lower. It is important to note that some staff may require access to multiple licences. For example, support staff may require a dedicated or shared licence during the day, but may require a web licence for out of hours support. Service on Demand There is a trend within the IT industry for suppliers to offer IT applications ‗on demand‘, where access is given to the application for a period of demand and then severed when it is
Page 21
Support Center – Managing and Analyzing no longer required. This may be useful either for smaller organizations or if the tools in question are very specialized and used infrequently. Alternately, the use of a tool can be offered as part of a specific consultancy assignment. For example, a specialist Capacity management consultancy may offer a regular but relatively infrequent Capacity Planning consultancy package and provide use of the tools for the duration of the assignment. Licence fees are likely to be included as part of, or as an addendum to, the consultancy fee. A further variation is where software is licensed and charged on an agent/activity basis. An example of this is interrogation/monitoring and/or simulation software. For example, agent software that can simulate pre-defined customer paths through an organization‘s website to assess and report upon performance and availability. This type of software is typically charged based on the number of agents, their location and/or the amount of activity generated. Full investigations of the licensing structure must be investigated and well understood before the tools are deployed. Deployment Before many ITSM tools can be used, particularly Discovery and Event Monitoring tools, they require some client/agent software deploying to all target locations. This needs careful planning and execution, and should be handled through formal Release and Deployment Management. Careful scheduling and testing is needed even where network deployment is possible. Records must be maintained throughout the rollout so that support staff have knowledge of who has been upgraded and who has not. Interim Change Management may be necessary and the CMS should be updated as the rollout progresses. The reboot of the devices for the client software to be recognized is often necessary and needs to be arranged in advance. Long delays can occur if staff do not generally switch off their desktops overnights. Further arrangements may also be necessary for staff to log on and receive new software. Capacity Checks In order to ensure that all of the target locations have sufficient storage and processing capacity to host and run the new software, Capacity Management may be needed in advance. Those that cannot will need upgrading or renewal and lead times for this must be included in the plans. The capacity of the network should also be checked to establish whether it can handle the transmission of management information, log files and the distribution of clients and possibly software and configuration files. Timing of Technology Department
Page 22
Support Center – Managing and Analyzing Care is needed in order to ensure that tools are deployed at the appropriate time in relation to the organization‘s level of ITSM sophistication and knowledge. It may be seen as an immediate panacea if tools are deployed too soon and any necessary action to change processes, working practices or attitudes may be hindered or overlooked. The organization must first examine the processes that the tool is seeking to address and also ensure that staff are ‗brought in‘ to the new processes and way of working and have adopted a ‗service culture‘. However, tools are tangible and can, and often do, make things a reality for many people. Technical staff can immediately see how the new processes can work and the benefits they may provide. Without adequate tooling, some processes simply cannot be done. There must be a careful balance to ensure that tools are introduced when they are needed and not before. Care is also needed to ensure that training in any tools is provided at the correct point. If the training is too early, knowledge will be diminished or be lost. However, staff will need to be formally trained and fully familiarized with the operations of the tools well in advance of live deployment. Additional training should be planned as needed once the tools go live. Type of Introduction A decision is needed on what type of introduction is needed – whether to go for a ‗Big Bang‘ introduction or some sort of phased approach. A phased approach is more likely to be necessary as most organizations will not start from a ‗green field‘ situation and will have live services to keep running during the introduction. In most cases, a new tool will be replacing an older, less sophisticated tool. Therefore the changeover between the two must be considered. This often involves deciding what data needs to be carried forward from the old to the new tool and may require significant reformatting to achieve the required results. Ideally this transfer should be done electronically. However, a small amount of re-keying of live data may be inevitable and should be factored into the plans. Older tools generally rely on more manual entry and maintenance of data. For this reason, an audit should be performed to verify data quality when electronic data migration is being used. Where data transfer is complicated or time consuming to achieve, an alternative might be to allow a period of parallel running. This involves the old tool being available for an initial period alongside the new one. It is advised that the old tool be made ‗read-only‘ in order to ensure that no mistakes can be made logging new data into the old tool.
Implementation of CSI Critical consideration for implementing CSI Before implementing CSI it is important to have identified and filled the critical roles that are required within this phase, such as CSI Manager, Service Owner and Reporting Analyst. A Service Level Manager is also needed to be the liaison between IT and the business.
Page 23
Support Center – Managing and Analyzing Where to start? One approach is to start looking at the handoff of output from the different lifecycle domains. The Service Design phase needs to monitor and report on their activities and by using trend analysis, identify relevant improvement opportunities. This needs to be done during every phase of the service lifecycle, especially during Service Design, Transition and Operation. The Continual Service Improvement phase is engaged in this activity. Communication strategy and plan Timely and effective communication forms an important part of any service improvement project. In an effort to transform an organization from performing CSI activities on an ad hoc basis to a more formal and ongoing CSI activities, it is crucial that staff, users and stakeholders are kept up to date of all changes to the processes, activities, roles and responsibilities. The goal of the communications plan is to build and maintain awareness, understanding, enthusiasm and support among key influential stakeholders for the CSI program. When developing a communication plan, it is important to note that effective communication is not just based on a one-way flow of information, and it is more than just meetings. A communications plan must incorporate the ability to deal with responses and feedback from the targeted audiences. The plan should include a role to: • • • • • • • • •
Design and deliver communications to the different CSI roles, stakeholders such as other ITSM process roles and identified target audiences Identify forums for customer and user feedback Receive and deliver responses and feedback to the project manager and/or process team members. Key activities for the communication plan include: Identifying stakeholders and target audiences Developing communication strategies and tactics Identifying communication methods and techniques Developing the communications plan Identifying the project milestones and related communications requirements.
When developing the communication plan it is important to take into consideration the culture around communication within the business. In some organizations there are strict guidelines on who can communicate with the business. Often times this is through the Service Level Management and Business Relationship Management processes. No matter what the method, communicating with the business should be the key communication activity. CSI & Organizational Change Figure 5
Many organizational change programs fail to achieve the desired results. People generally do not like change, so it is essential that benefits are explained to all parties to obtain and
Page 24
Support Center – Managing and Analyzing retain support as the change occurs. Communication is key to ensuring a smooth transition from old working practices to new ones. Those responsible for managing and steering the CSI program should consciously address these softer issues. Using an approach such as John P. Kotter‘s Eight Steps to Transforming your Organization, together with formalized project management skills and practices, will significantly increase the chance of success. Kotter, Professor of Leadership at Harvard Business School, investigated more than 100 businesses that were involved with or had attempted a complete change program. From this research he identified the ‗Eight main reasons why transformation efforts fail‘ these reasons apply equally to ITSM implementation programs.
1. Create a sense of urgency Half of all transformations fail to realize their goals due to the lack of adequate attention to this step. Not enough people buy into the fact that change is a must. It is essential that all parties understand the repercussions of not making the change as this will help to gain commitment and provide input to a business justification for investing in CSI. 2. Forming a guiding coalition Experience shows a need for assembling a group with sufficient power to lead the change effort and work together as a team. Power means more than simply formal authority but also experience, respect, trust and credibility. This team is the guiding coalition for the CSI phase. 3. Creating a vision This guiding coalition should be responsible for ensuring that a vision is produced describing the aim and purpose of CSI. A good vision statement can service four essential purposes: • Clarify the direction of the program • Motivate people to take action in the right direction • Coordinate the actions of many different people • Outline the aims of senior management. 4. Communicating the vision Although the vision provides a powerful tool in helping guide and coordinate change, the real power is unleashed when the vision is effectively communicated to the stakeholders. Every stakeholder should understand the vision. 5. Empowering other to act on the vision Establishing urgency, creating a guiding coalition, creating and communicating a vision are all aimed at creating and communicating a vision are all aimed at creating energy, enthusiasm, buy-in and commitment to enable successful change. In the empowering phase, two important aspects need to be stressed: enabling and removing barriers.
Page 25
Support Center – Managing and Analyzing 6. Planning for and creating short-term wins Implementing service management improvements can be a lengthy program of change. It is important that during the program, short term wins are realized and are communicated. Short-term wins help to keep a change effort on track and help keep the energy and commitment levels high. Real transformation takes time. Without short-term wins, too many people give up or join the ranks of those opposed to change.
7. Consolidating improvements and producing more change The success of short-term wins keeps the momentum going and creates more change. In CSI it is important to recognize short to medium and long term wins. Changes should sink deeply into the new culture or the new approaches will be fragile and subject to regression: • Short-term wins – have the characteristics of convincing, motivating and showing immediate benefits and gains • Medium-term wins – have the characteristics of confidence and capability, and having a set of working processes in place. • Long-term wins – have the characteristics of self learning and expertise, and fully integrated processes that have self-learning and improvement built into them. 8. Institutionalizing the change Change needs to be institutionalized within the organization. Many changes fail because they are not consolidated into everyday practices. Institutionalizing change means showing how new working practices have produced real gain and benefits, and ensuring that the improvements are embedded in all organizational practices. Often the CSI team is disbanded before the working practices are institutionalized; there is danger that people may revert to old working practices, but this cannot be allowed to happen. CSI must be a way of life, not a reaction to a failure of some description.
Case Studies 1. The German Air Traffic Control Real life feedback from The German Air Traffic Controliii who implemented Service Level Management in 2005 as part of their ITIL Service Management process implementation: ―Today the most critical factor for IT-organization or service provider is the “full-life-support” of the business processes. The ITIL standard is best practice method for reorganization into a customer oriented service provider. It is recommend realizing the ITIL processes via organization project. Therefore it is necessary to work out a detail project plan.
Page 26
Support Center – Managing and Analyzing The implementation time for the ITIL processes depends on the complexity of ITorganization and on the ITIL process itself. The experience for complex companies shows the following time periods. -
Incident Management 6-18 months, Configuration Management 3-9 months, Problem Management 5-8 months, Change Management 3-4 months, Release Management 2-3 months, Availability Management 4-8 months, Financial Management 6-12 months, Service Level Management 6-9 months.
After the implementation of ITIL it is necessary to define the services and service modules of the IT-organization; to describe them in detail and to calculate the costs and prices for every service as well as to provide the service via Service Level Agreement.” 2. Telecom company An international telecom companyiv with more than 6,500 employees and annual revenue of $4 billion in the US has the following experience: “Since the ITIL work was done in an ivory tower, the IT staff had not been on board since the project's inception. Communication problems were rampant as both the ITIL team and the IT organization struggled to create a common set of terminology and understand basic ITIL methodologies. Actual workflows and roles proved incompatible with the ideal. Meanwhile, the organization continued to grow, adding new lines of business for VoIP and acquiring another company. Finally, the ITIL initiative was pulled back and assigned to IT architects for overhaul...” The total project took approx. 2 years. 3. State Revenue Office of Victoria The Sate Revenue office of Victoria (AUS) started an ITIL implementation projectv when they decided to in-source their IT Services. SRO has approx. 450 staff, and the ITIL implementation project happened between May 2003 and June 2005. Some of the benefits stated are:
Documented IT policies and procedures to an external standard (AS8018) Greater visibility of changes Better reporting Better maintenance of in-sourced environment leading to on-going cost savings and reduced risk
The IT Service Management ITIL V3 BENCHMARK CHECKLIST Page 27
Support Center – Managing and Analyzing Here you will find a checklist of ALL activities any IT environment performs or needs to perform in Service Strategy, Design, transition, Operation and improvement. Many of which touch your role direct – and even more of those can be used by YOU to help grow your organization by pointing out their necessity and benefits. Go through this checklist, check of the ones you and your organization are not doing yet – and prioritize them.
Service Strategy - The Practice of Service Management 1. Service Management is clearly defined 2. We know what our services are 3. We have decided upon a strategy to serve our customers 4. We know which services we should offer to whom 5. We know how we differentiate ourselves from competing alternatives 6. We know how we truly create value for our customers 7. We know how we capture value for our stakeholders 8. We know how we can make a case for strategic investments 9. Financial management provides visibility and control over value-creation 10. We have defined service quality 11. We know how to choose between different paths for improving service quality 12. We know how to efficiently allocate resources across a portfolio of services 13. We know how to resolve conflicting demands for shared resources Service Strategy Principles 1. The outcomes that matter are identified and ranked in terms of customer perceptions and preferences 2. We know what our business is 3. We know who our customer is 4. We know what our customer values 5. We know who depends on our services 6. We know how our customers use our services 7. We know why our services are valuable to our customers 8. We know who all the participants in the service are
Page 28
Support Center – Managing and Analyzing 9. We know the overall patterns of exchange or transactions 10. We know the impacts or deliverables of each transaction on each participant. 11. We know what the best way is to generate value 12. Our strategy captures a more timeless essence of our organization‘s distinctiveness instead of just the next few years 13. Our strategy is clear and memorable 14. Our strategy has the ability to promote and guide action 15. Our strategy sets boundaries within which people are free to experiment 16. Our positioning guides the organization in making decisions between competing resources and capability investments 17. Our positioning help managers test the appropriateness of a particular course of action 18. Our positioning sets clear boundaries within which staff should and should not operate 19. Our positioning allows freedom to experiment within these constraints Service Strategy 1. Our service providers have the capabilities to support business activities 2. We know the recurring patterns of activity in the customer‘s business 3. We know if our customers activity varies based on the time of the year, location, or around specific events 4. There are enough resources to fulfill the demand from the customer's business activity as it occurs 5. We are aware of potential scheduling conflicts that may lead to situations with inadequate capacity 6. We know if the customer‘s business is subject to regulations 7. Our Service Providers have knowledge and experience with regulatory compliance 8. If services come in direct contact with the customers of customers, we have additional policies and guidelines required to handle user interactions and user information 9. We know who our customers are 10. We know who our customer's customers are 11. We know how we create value for our customers and how they create value 12. We know what assets we deploy to provide value, and which of our clients assets receive value
Page 29
Support Center – Managing and Analyzing 13. We know which assets we should invest in and which of our assets our clients value most 14. How should we deploy our assets? How do they deploy their assets? 15. We know what services we provide, and what outcomes we support 16. We know what constraints our customers face 17. We know which customer assets we support and what assets we deploy to provide value 18. We know how we deploy our assets 19. We know who the users of our services are 20. We know what type of activity we support and how we create value for them 21. We know how we track performance and what assurances we provide 22. We know our market space 23. We know what our market space wants 24. We are offering unique products/services in our market space 25. Our Market space is not already saturated with good solutions 26. We have the right portfolio of services developed for a given market space 27. We have the right catalogue of services offered to a given customer 28. Every service is designed to support the required outcomes 29. Every service is operated to support the required outcomes 30. We have the right models and structures to be a service provider 31. We know which of our services or service varieties are the most distinctive 32. There are services that the business or customer cannot easily substitute 33. We know which of our services or service varieties are the most profitable 34. We know which customers, channels or purchase occasions are the most profitable 35. We know what makes us special to our business or customers 36. We have measurements that tell us when we are successful and know when that must be achieved. 37. We are not vulnerable to substitution 38. There are means to outperform competing alternatives
Page 30
Support Center – Managing and Analyzing 39. We know what task or activity the service needs to carry out and what job the customer is seeking to execute 40. We know what outcomes the customer is attempting to obtain and what the desired outcome is 41. We know what constraints may prevent the customer from achieving the desired outcome, and how we can remove these constraints Service Economics 1. Our differentiation strategy is resulting in higher profits or revenues, lower costs, or greater service adoption 2. The Financial Management process is defined 3. We know which services cost us the most, and why 4. We know our volumes and types of consumed services, and the correlating budget requirement 5. We know how efficient our service provisioning models are relative to alternatives 6. Our strategic approach to service design results in services that can be offered at a competitive market price, substantially reduced risk, or offers superior value 7. We know where our greatest service inefficiencies are 8. We know which functional areas represent the highest priority opportunities for us to focus on as we generate a continual service improvement strategy 9. We know how to select On-shore, Off-shore or Near-Shore services 10. We have defined if we follow Cost Recovery, Value Centre or Accounting Centre principles 11. We know for financial management what deliverable we expect from the implementation 12. We know if the business or IT expects a chargeback system 13. There is currently a Service Catalogue implemented and awaiting pricing 14. We know what our discount rates are 15. Service Portfolio Management is defined 16. We know why a customer should buy our services 17. We know why a customer should buy those services from us 18. We know what the pricing or chargeback models are 19. We know our strengths and weaknesses, priorities and risks
Page 31
Support Center – Managing and Analyzing 20. We know how our resources and capabilities are to be allocated 21. We know what the long-term goals of the service organization are 22. We know services are required to meet our long term goals 23. We know what capabilities and resources are required for the organization to achieve those services 24. We know how we will get to offer the services that are required to meet our long term goals Strategy and Organization 1. We have clearly defined where centralized and decentralized management takes place of our services 2. We know if our strategy is based on reducing costs or improving quality 3. We know if our organization has adopted a product or geographic structure 4. We know what obstacles are anticipated for organizational change 5. We have identified the Terminal and instrumental values of the organization 6. We have determined whether the goals, norms and rules of our organization are properly transmitting the value of the organizational culture to staff members and if there are areas for improvement 7. We have assessed the methods we use to introduce new staff and know if these practices help newcomers learn the organizations culture 8. We know if extra value generated from performing an activity inside the organization outweighs the cost of managing it. 9. When deciding to outsource we know if the candidate services improve the business‘s resources and capabilities 10. When deciding to outsource we know how closely the candidate services are connected to the business's competitive and strategic resources and capabilities 11. When deciding to outsource we know if the candidate services require extensive interactions between the service providers and the business's competitive and strategic resources and capabilities 12. When deciding to outsource we know if the customer or market space expect us to do this activity 13. The customer or market space will give us credit for performing an outsourcing activity exceptionally well Strategy to Tactics and Operations
Page 32
Support Center – Managing and Analyzing 1. We get input from service transition on what the implications are with each strategic choice in terms of costs, time, and risks 2. Regarding our strategic options we know under what scenarios one path is preferable over the other 3. Regarding our strategic options we know what the likelihoods are of those scenarios 4. Regarding our strategic options we know if existing assets can support a transition path 5. Regarding our strategic options we know if there are contingency plans to contain the adverse impact changes 6. Regarding our strategic options we know if a particular change can be implemented fast enough to support the strategy Technology and Strategy 1. We have service analytics in place to understand how incidents affect services, how the business is impacted and how we respond 2. Our customer encounters are designed considering if customer employees are technical or non-technical 3. We know what the implications are in customer interactions of the technology encounter to the customer 4. With customer encounters we know what the customer expectations and perceptions are 5. We know how we agree on the definition of service levels with respect to a given level of user satisfaction 6. We know how much a customer should agree to pay for a given service level 7. We know what a reasonable timeframe is for a service request to be approved 8. We know what service levels we can impose on an internal function or service group 9. We know how multiple service providers cooperate as an alliance in serving a common customer 10. We know what the delay and the business impact is on the supply chain due to an IT problem 11. We know how long it takes to process procurement orders, and where the worst delays are 12. We know when more than a substantial amount of orders is waiting to go through the distribution systems 13. We know how to ensure good returns from investments made in service assets
Page 33
Support Center – Managing and Analyzing 14. We know how to find new opportunities for our assets to be deployed in service of new customers
Service Design - Service Management as a Practice 1. Service Management is clearly defined 2. We know what our services are 3. We are able to measure our processes in a relevant manner 4. The reason our processes exist is to deliver a specific result 5. Every process delivers its primary results to a customer or stakeholder 6. We adopt a holistic approach for all Service Design aspects and areas to ensure consistency and integration 7. We actively manage the design of new or changed services 8. We actively manage the design of the service portfolio, including the Service Catalogue 9. We actively manage the design of the processes required 10. We actively manage the design of measurement methods and metrics 11. We agree service levels, SLAs and targets across the whole enterprise, ensuring critical business processes receive most attention 12. We measure IT quality in business/user terms, reporting what is relevant to users 13. We map business processes to IT infrastructure 14. We map business processes to business and service measurements 15. We map infrastructure resources to services 16. We provide end-to-end online business processes performance monitoring 17. We provide IT Services that are business and customer oriented, focused and driven 18. We provide IT Services that are cost effective and secure 19. We provide IT Services that are flexible and adaptable, yet fit for purpose at the point of delivery 20. We provide IT Services that can absorb an ever-increasing demand in the volume and speed of change 21. We provide IT Services that meet increasing business demands for continuous operation 22. We provide IT Services that are managed and operated to an acceptable level of risk
Page 34
Support Center – Managing and Analyzing 23. We provide IT Services that are responsive with appropriate availability matched to business needs 24. An IT Strategy or Steering Group carries the overall accountability for setting governance, direction, policy and strategy for IT Services Service Design Principles 1. New service solutions are added to the service portfolio from the concept phase 2. SLRs for a new service are understood before it goes live 3. Capacity Management is involved in modeling the SLRs 4. Financial Management is involved to set the budget 5. An initial Business impact analysis and Risk assessment is conducted before implementation 6. The Service Desk is made aware of new services, prepared and trained 7. Service transition plans the implementation and builds it into the forward schedule 8. Supplier Management is involved if procurement is required for the new service 9. We design services to satisfy business objectives 10. We design services that can be easily and efficiently developed 11. We design efficient and effective processes 12. We identify and manage risks prior to services becoming live 13. We design secure and resilient IT Services 14. We design measurement methods and metrics for processes and their deliverables 15. We produce and maintain IT design plans 16. We assist in the development of design policies and standards 17. We balance design between functionality, resources and schedules 18. We identify Service Requirements 19. We identify and document Business Requirements and Drivers 20. We collect, analyze and engineer requirements 21. We design appropriate services, technologies, processes that meet business requirements 22. We review and revise all processes and documents involved in service Design
Page 35
Support Center – Managing and Analyzing 23. We liaison with all other design and planning activities and roles 24. Our service portfolio clarifies why a customer should buy these services 25. Our service portfolio clarifies why customers should buy these services from us 26. Our service Portfolio clarifies what the pricing and chargeback models are 27. We evaluate alternative solutions. 28. We have a procurement process for procuring the preferred solution 29. We use a SOA approach for designing and developing business processes and solutions 30. We use BSM to enable It components to be linked to business goals Service Design Processes 1. We have defined Service Catalogue Management's Purpose, Goal and Objective 2. We have defined Service Catalogue Management's Scope 3. We have defined Service Catalogue Management's Value to the business 4. We have defined Service Catalogue Management's Policies, Principles and basic concepts 5. We have defined Service Catalogue Management's Process Activities, Methods and Techniques 6. We have defined Service Catalogue Management's Triggers, Inputs, Outputs and interfaces 7. We have defined Service Catalogue Management's KPIs 8. We have defined Service Catalogue Management's Challenges, Critical Success Factors and Risks 9. We have defined Capacity Management's Purpose, Goal and Objective 10. We have defined Capacity Management's Scope 11. We have defined Capacity Management's Value to the business 12. We have defined Capacity Management's Policies, Principles and basic concepts 13. The Business Capacity Management sub-process is defined 14. The Service Capacity Management sub-process is defined 15. The Component Capacity Management sub-process is defined 16. We have defined Capacity Management's Process Activities, Methods and Techniques
Page 36
Support Center – Managing and Analyzing 17. The underpinning activities (tuning, utilization and response time monitoring etc.) of Capacity Management are defined 18. Threshold management and control is defined 19. Demand Management is defined 20. Modeling and trending are defined 21. Application sizing is defined 22. We have defined Capacity Management's Triggers, Inputs, Outputs and interfaces 23. We have defined Capacity Management's KPIs 24. We have defined Capacity Management's Information Management reporting 25. We have defined Capacity Management's Challenges, Critical Success Factors and Risks 26. We have defined Availability Management's Purpose, Goal and Objective 27. We have defined Availability Management's Scope 28. We have defined Availability Management's Value to the business 29. We have defined Availability Management's Policies, Principles and basic concepts 30. We have defined Availability Management's Process Activities, Methods and Techniques 31. The Reactive activities of Availability Management are Defined 32. The Proactive activities of Availability Management are defined 33. We have defined Availability Management's Triggers, Inputs, Outputs and interfaces 34. We have defined Availability Management's KPIs 35. We have defined Availability Management's Information Management reporting 36. We have defined Availability Management's Challenges, Critical Success Factors and Risks 37. We have defined Service Continuity Management's Purpose, Goal and Objective 38. We have defined Service Continuity Management's Scope 39. We have defined Service Continuity Management's Value to the business 40. We have defined Service Continuity Management's Policies, Principles and basic concepts 41. We have defined Service Continuity Management's Process Activities, Methods and Techniques
Page 37
Support Center – Managing and Analyzing 42. Service Continuity Management's Stage 1: Initiation is defined 43. Service Continuity Management's Stage 2: Requirements and Strategy is defined 44. Service Continuity Management's Stage 3: Implementation is defined 45. Service Continuity Management's Stage 4:On-going Operation is defined 46. We have defined Service Continuity Management's Triggers, Inputs, Outputs and interfaces 47. We have defined Service Continuity Management's KPIs 48. We have defined Service Continuity Management's Information Management reporting 49. We have defined Service Continuity Management's Challenges, Critical Success Factors and Risks 50. We have defined Information Security Management's Purpose, Goal and Objective 51. We have defined Information Security Management's Scope 52. We have defined Information Security Management's Value to the business 53. We have defined Information Security Management's Policies, Principles and basic concepts 54. We have a defined Security Framework 55. We have an Information Security Policy 56. We have an Information Security Policy Management System 57. We have defined Information Security Management's Process Activities, Methods and Techniques 58. Information Security Management's Security Controls are defined 59. Information Security Management's Management of security breaches and incidents is defined 60. We have defined Information Security Management's Triggers, Inputs, Outputs and interfaces 61. We have defined Information Security Management's KPIs 62. We have defined Information Security Management's Information Management reporting 63. We have defined Information Security Management's Challenges, Critical Success Factors and Risks 64. We have defined Supplier Management's Purpose, Goal and Objective 65. We have defined Supplier Management's Scope
Page 38
Support Center – Managing and Analyzing 66. We have defined Supplier Management's Value to the business 67. We have defined Supplier Management's Policies, Principles and basic concepts 68. We have defined Supplier Management's Process Activities, Methods and Techniques 69. We have defined how we evaluate new suppliers and contracts 70. We maintain a SDC (supplier and Contracts Database) 71. We have defined how we establish new suppliers and contracts 72. We have defined how we manage supplier, contract management and performance 73. We have defined how we manage contract renewal and / or termination 74. We have defined Supplier Management's Triggers, Inputs, Outputs and interfaces 75. We have defined Supplier Management's KPIs 76. We have defined Supplier Management's Information Management reporting 77. We have defined Supplier Management's Challenges, Critical Success Factors and Risks Service Design Technology Related Activities 1. Defining Functional requirements is an integral part of requirements engineering 2. Defining Management and operational requirements is an integral part of requirements engineering 3. Defining Usability requirements is an integral part of requirements engineering 4. Interviews are used as a Requirements investigation technique 5. Workshops are used as a Requirements investigation technique 6. Observation is used as a Requirements investigation technique 7. Protocol analysis is used as a Requirements investigation technique 8. Shadowing is used as a Requirements investigation technique 9. Scenario analysis is used as a Requirements investigation technique 10. Prototyping is used as a Requirements investigation technique 11. Requirements are documented in a standardized way in the requirements catalogue 12. Management of Data resources is defined within the scope of Data Management 13. Management of Data/information technology is defined within the scope of Data Management
Page 39
Support Center – Managing and Analyzing 14. Management of information processes is defined within the scope of Data Management 15. Management of data standards and policies is defined within the scope of Data Management 16. Data is valued as an asset 17. Data is classified as operational, tactical and strategic 18. Data standards are defined and managed 19. Data ownership is defined and managed 20. Data migration is defined and managed 21. Data storage is defined and managed 22. Data capture is defined and managed 23. Data retrieval and usage is defined and managed 24. Data integrity is addressed and managed 25. The application portfolio is described in Application Management 26. Applications and Service Portfolios are linked in Application Management 27. CASE tools and repositories are used and aligned in Application Management 28. The Design of specific applications is managed in Application Management 29. Managing trade-offs is addressed in Application Management 30. The application portfolio is described in Application Management 31. Application Development covers consistent coding conventions 32. Application Development covers application independent building guidelines 33. Application Development covers operability testing 34. Application Development covers management checklists for the building phase 35. Application Development covers organization of the build team roles 36. Major outputs from the development phase are scripts to be run before or after deployment 37. Major outputs from the development phase are scripts to start or stop the application 38. Major outputs from the development phase are scripts to check hardware and software configurations of environments before deployment
Page 40
Support Center – Managing and Analyzing 39. Major outputs from the development phase are customized scripts to manage the application 40. Major outputs from the development phase are specifications of access control for the system resources used by the application 41. Major outputs from the development phase are specifications of the details required to track an application's major transaction 42. Major outputs from the development phase are SLA targets and requirements 43. Major outputs from the development phase are operational requirements and documentation 44. Major outputs from the development phase are support requirements 45. Major outputs from the development phase are procedures for application recovery and back-ups Organizing for Service Design 1. The RACI model is used to define the roles and responsibilities for Service Design 2. Functional roles are analyzed from the RACI matrix 3. Activities are analyzed from the RACI matrix 4. Skills and attributes are analyzed from the RACI matrix 5. Process owner roles and responsibilities are defined and scoped 6. Service Design Manager roles and responsibilities are defined and scoped 7. IT Planner roles and responsibilities are defined and scoped 8. IT designer / Architect roles and responsibilities are defined and scoped 9. Service Catalogue Manager roles and responsibilities are defined and scoped 10. Service Level Manager roles and responsibilities are defined and scoped 11. Availability Manager roles and responsibilities are defined and scoped 12. Service Continuity Manager roles and responsibilities are defined and scoped 13. Capacity Manager roles and responsibilities are defined and scoped 14. Security Manager roles and responsibilities are defined and scoped 15. Supplier Manager roles and responsibilities are defined and scoped Service Design Technology Considerations 1. We have tools and techniques that enable hardware design
Page 41
Support Center – Managing and Analyzing 2. We have tools and techniques that enable software design 3. We have tools and techniques that enable environmental design 4. We have tools and techniques that enable process design 5. We have tools and techniques that enable data design 6. Our tools manage of all stages of the service lifecycle 7. Our tools manage all aspects of the services and its performance 8. Our tools enable service achievement, SLA, OLA and all contractual management 9. Our tools have consolidated metrics and metrics trees (dashboards) with drill down functionalities 10. Our tools give us consistent and consolidated views across all processes, systems, technologies and groups 11. Our tools show us the relationships and integration of the business and its processes with IT services, systems and processes 12. Our tools offer us a comprehensive set of search and reporting facilities 13. Our tools enable us to manage the service costs 14. Our tools enable us to manage the relationships, interfaces and inter-dependencies 15. Our tools enable the management of the service portfolio and service catalogue 16. We have a Configuration Management system (CMS) 17. We have a Service Knowledge Management System (SKMS) Service Design Process Implementation Considerations 1. A Business Impact Analysis is used to define our critical services and what constitutes a Major incident 2. A Business Impact Analysis is used to define acceptable levels and times of service outage levels 3. A Business Impact Analysis is used to define critical business and service periods 4. A Business Impact Analysis is used to define the cost of loss of service 5. A Business Impact Analysis is used to define the potential security implications of a loss of service 6. Service Level Requirements for all services are ascertained 7. Risks to the Services and processes are assessed
Page 42
Support Center – Managing and Analyzing 8. Service Design is implemented by starting with a Vision, knowing where we are now, where we want to be, how we get there, hoe we will know we have gotten there and how we keep going 9. There are measurement systems in place for Service Design (e.g. Six Sigma) 10. The Prerequisites for success (PFS) are clearly defined 11. The critical success factors and key performance indicators are defined
Service Transition - Service Management as a Practice 1. Service Management is clearly defined 2. We know what our services are 3. We have clearly defined functions and processes across the lifecycle 4. We are able to measure the processes in a relevant matter 5. The reason a process exists is to deliver a specific result 6. Every process delivers its primary result to a customer or stakeholder 7. The goals of Service Transition are defined 8. The objectives of Service Transition are defined 9. The purpose of Service Transition is Defined 10. The Scope of Service transition is defined 11. Service Transition enables us to align the new or changed service with the customer's business requirements 12. Service Transition ensures that customers and users can use the new or changed service so that it maximizes value to the business 13. We have measurements for alignment with the business and It plans 14. We have measurements for Service Transition 15. Interfaces to other Service Lifecycle stages are clearly defined Service Transition Principles 1. Service Utilities are Defined 2. Service Warranties are Defined 3. We have defined and implemented a formal policy for service transition 4. We have a policy for implementing all changes to services through service transition
Page 43
Support Center – Managing and Analyzing 5. We have a policy for adopting a common framework and standards 6. We have a policy for Maximizing re-use of established processes and systems 7. We have a policy for aligning service transition plans with the business needs 8. We have a policy for establishing and maintaining relationships with stakeholders 9. We have a policy for establishing effective controls and discipline 10. We have a policy for providing systems for knowledge transfer and decision support 11. We have a policy for planning release and deployment packages 12. We have a policy for Anticipating and managing course corrections 13. We have a policy for Proactively managing resources across service transitions 14. We have a policy for ensuring early involvement in the service lifecycle 15. We have a policy for assuring the quality of the new or changed service 16. We have a policy for proactively improving quality during service transition Service Transition Processes 1. The purpose , goal and objective for the Transition Planning and Support process is defined 2. The scope of the Transition Planning and Support process is defined 3. A service transition policy is clearly defined 4. A release policy is clearly defined 5. A transition strategy is clearly defined 6. Service transition preparation activities are defined 7. Service transition is planned and coordinated 8. Advice is given as part of transition process support 9. Administration is organized for transition process support 10. Progress monitoring and reporting is part of process support 11. Triggers, input and Output / Inter-process interfaces are defined 12. Key performance indicators and metrics are defined 13. The purpose, goal and objective for the Change Management process is defined 14. The scope for change management is defined
Page 44
Support Center – Managing and Analyzing 15. The policies, principles and basic concepts for change management are defined 16. We have defined the types of change requests 17. We have defined standard (pre-authorized) changes 18. Remediation planning for changes is defined 19. Planning and controlling changes is an integrated activity of change management 20. Change and release scheduling is an integrated activity of change management 21. Ensuring there are remediation plans is an integrated activity of change management 22. Measurement and control of changes is an integrated activity of change management 23. Management reporting is an integrated activity of change management 24. Understanding the impact of change is an integrated activity of change management 25. Continual improvement is an integrated activity of change management 26. Raising and recording changes is defined 27. Reviewing the RFC is defined 28. Assessing and evaluating the Change is defined 29. Authorizing the Change is defined 30. Co-coordinating change implementation is defined 31. Reviewing and closing change records is defined 32. Change process models and workflows are defined 33. The Change advisory board is defined 34. Emergency changes are defined 35. Triggers, Input and output and inter-process interfaces are defined 36. Key performance indicators and metrics are defined 37. The purpose, goal and objective for the Service Asset and Configuration Management process is defined 38. The scope for SACM is defined 39. The policies, principles and basic concepts for SACM are defined 40. The Configuration Management System is defined 41. Asset and Configuration Management activities are defined
Page 45
Support Center – Managing and Analyzing 42. Management and planning for SACM is defined 43. Configuration identification is defined 44. Configuration control is defined 45. Status reporting is defined 46. Verification and audit is defined 47. Triggers, Input and output and inter-process interfaces are defined 48. Key performance indicators and metrics are defined 49. The purpose, goal and objective of the Release and Deployment Management process is defined 50. The scope for Release and deployment is defined 51. The policies, principles and basic concepts for Release and Deployment are defined 52. Release Unit and Identification is defined 53. Release design options are considered 54. Release and deployment models are defined 55. The planning of releases is managed 56. Preparation for build, test and deployment is managed 57. Build and test is managed 58. Service testing and pilots are managed 59. Planning and preparing for deployment are managed 60. Transfer, Deployment and retirement are managed 61. Deployment verification is managed 62. Early life support is managed 63. Review and closing of a deployment is managed 64. Review and closing of the service transition is managed 65. Triggers, Input and output and inter-process interfaces are defined 66. Key performance indicators and metrics are defined 67. The purpose, goal and objective of the Service Validation and Testing process is defined 68. The scope for Service Validation and Testing is defined
Page 46
Support Center – Managing and Analyzing 69. The policies, principles and basic concepts for Service Validation and testing are defined 70. Inputs from Service Design are defined 71. Service quality and assurance is defined 72. Service Quality, Risk, service transition, release and change management Policies are defined 73. The Test strategy is defined 74. Test Models are defined 75. Validation and testing perspectives are defined 76. Testing approaches and techniques are examined and defined 77. Design considerations are defined 78. Different types of testing are defined 79. Triggers, Input and output and inter-process interfaces are defined 80. Key performance indicators and metrics are defined 81. The purpose, goal and objective of the Evaluation process is defined 82. The scope for Evaluation is defined 83. The policies, principles and basic concepts for Evaluation are defined 84. Service Evaluation terms are defined 85. The Evaluation process is defined 86. The Evaluation plan is defined 87. Evaluation of predicted performance is managed 88. Evaluation of actual performance is managed 89. Risk management is defined 90. Evaluation reporting is defined 91. Triggers, Input and output and inter-process interfaces are defined 92. Key performance indicators and metrics are defined 93. The purpose, goal and objective of the Knowledge Management process is defined 94. The scope for knowledge management Evaluation is defined 95. The policies, principles and basic concepts for Knowledge Management are defined
Page 47
Support Center – Managing and Analyzing 96. Knowledge management is defined using a DIKW (data -information-knowledge-wisdom) approach 97. A Service Knowledge Management System (SKMA) Is in place to capture and manage knowledge 98. The Knowledge Management Strategy is defined 99. Knowledge Transfer is defined 100. Data and information Management is integrated with Knowledge Management 101. Access and use of the Knowledge Management system is defined 102. Triggers, Input and output and inter-process interfaces are defined 103. Key performance indicators and metrics are defined Service Transition common operation activities 1. Managing Communication and commitment is a common operation activity 2. Communications during Service Transition are defined 3. Communication planning is managed 4. Different methods of communication are applied 5. Managing Organization and stakeholder Change is a common operation activity 6. The emotional cycle of change is managed 7. Service Transition's role in organizational change is clearly defined 8. Organizational change is planned and implemented 9. A variety of organizational change products is used 10. Organizational readiness for Change is assessed 11. Progress of organizational change is monitored 12. Organization and people issues are dealt with in sourcing changes 13. Organizational Change management's best practices (e.g. Kotter) are applied 14. Stakeholder management is a common operation activity 15. We have a stakeholder management strategy 16. We produce stakeholder maps and analysis 17. Changes in stakeholder commitment are captured Organizing Service Transition
Page 48
Support Center – Managing and Analyzing 1. The Process Owner role and the Service Owner role are defined 2. The organizational context for transitioning a service is set 3. Organizational models to support service transition are defined 4. The Service Transition Manager role is defined 5. Planning and support is organized 6. The Service Asset Manager role is defined 7. The Configuration Manager role is defined 8. The Configuration Analyst role is defined 9. The Configuration administrator / librarian role is defined 10. The CMS / Tool administrator role is defined 11. The configuration control board role is defined 12. Change Authority is defined 13. The Change Manager role is defined 14. The Change Advisory Board role is defined 15. Performance and risk evaluation management is defined 16. Service Knowledge management is defined 17. The service test manager role is defined 18. The release and deployment roles are defined 19. The Release packaging and Build roles are defined 20. Deployment is defined 21. Early life support is defined 22. Build and test environment management is defined 23. The Service Transition relationship with other lifecycle stages are defined Service Transition Technology Considerations 1. A service Knowledge Management system is in place 2. Collaborative, content management, workflow tools are in place 3. Data mining tools are in place 4. Extract, load and transform tools are in place
Page 49
Support Center – Managing and Analyzing 5. Measurement and reporting system tools are in place 6. Test management and testing tools are in place 7. Database and test data management tools are in place 8. Copying and publishing tools are in place 9. Release and deployment technology tools are in place 10. Deployment and logistics systems and tools are in place 11. Configuration Management systems and tools are in place 12. Version control tools are in place 13. Document-management systems are in place 14. Requirements analysis and design tools, systems architecture and CASE tools are in place 15. Database management audit tools to track physical databases are in place 16. Distribution and installation tools are in place 17. Comparison tools (software files, directories, databases) are in place 18. Build and Release tools (that provide listings of input and output CIs) are in place 19. Installation and de-installation tools (that provide listings of CIs installed) are in place 20. Compression tools (to save storage space) are in place 21. Listing and configuration baseline tools (e.g. Full directory listings with date–time stamps and check sums) are in place 22. Discovery and audit tools (also called ‗inventory‘ tools) are in place 23. Detection and recovery tools (where the build is returned to a known state) are in place 24. Visualization, mapping and graphical representations with drill down reporting tools are in place Implementing Service Transition 1. Justification of Service Transition is undertaken 2. Designing Service Transition has been done 3. Applicable standards and policies have been researched 4. Relationships have been defined 5. Budgets and resources have been allocated
Page 50
Support Center – Managing and Analyzing 6. Service transition has been introduced 7. the Cultural change aspects have been addressed 8. Risks and value have been weighed
Service Operation - Service Management as a Practice 1. Service Management is clearly defined 2. We know what our services are 3. We have clearly defined functions and processes across the lifecycle 4. We are able to measure the processes in a relevant matter 5. The reason a process exists is to deliver a specific result 6. Every process delivers its primary result to a customer or stakeholder 7. The goals of Service Operation are defined 8. The objectives of Service Operation are defined 9. The purpose of Service Operation is Defined 10. The Scope of Service Operation is defined 11. The Event Management process is defined 12. The Incident and Problem Management process is defined 13. The Request fulfillment process is defined 14. The Access Management process is defined 15. The Service Desk function is defined 16. The Technical Management function is defined 17. The IT operations Management function is defined 18. The Application Management function is defined 19. Interfaces to other Service Lifecycle stages are clearly defined Service Operation Principles 1. Distinctive functions, groups, teams, departments and divisions are defined 2. We have a balance between an internal IT view and external business view 3. We balance stability interests versus responsiveness to changes 4. We balance quality of service versus cost of service
Page 51
Support Center – Managing and Analyzing 5. We balance reactiveness versus proactiveness 6. All Service operation staff is fully aware that they are providing a service to the business 7. We have a clear definition of It service objectives and performance criteria 8. We have linkage of IT Service specifications to the performance of the IT infrastructure 9. We have a definition of operational performance requirements 10. We have a mapping of services and technology 11. We have the ability to model the effect of changes in technology and changes to business requirements 12. We have appropriate cost models to evaluate ROI and cost reduction strategies 13. Operational health is monitored with a set of Vital signs 14. We have routine Operational communication 15. We have formalized communication between shifts 16. We have formalized performance reporting 17. We have formalized communication in projects 18. We have formalized communication related to exceptions 19. We have formalized communication related to emergencies 20. We have training on new or customized processes and service designs 21. We have communication of strategy and design to our service operation teams formalized 22. The means of communication (email, sms etc) are defined 23. We have a structured, regular Operations Meeting 24. We have structured, regular Department, Group and Team Meetings 25. We have structured, regular Customer Meetings 26. We participate in the definition and maintenance of process manuals for all processes we are involved in 27. We establish our own technical procedures manuals 28. We participate in the creation and maintenance of planning documents 29. We participate in the definition and maintenance of Service Management Tool work instructions
Page 52
Support Center – Managing and Analyzing Service Operation Processes 1. We have defined Event Management's Purpose, Goal and Objective 2. We have defined Event Management's Scope 3. We have defined Event Management's Value to the business 4. We have defined Event Management's Policies, Principles and basic concepts 5. The "Event Occurs" process activity is specified 6. The "Event Notification" process activity is specified 7. The "Event Detection" process activity is specified 8. The "Event Filtering" process activity is specified 9. The "Significance of Events Categorization" process activity is specified 10. The "Event Correlation" process activity is specified 11. The "Trigger" process activity is specified 12. The "Response Selection" process activity is specified 13. The "Review Actions" process activity is specified 14. The "Close Actions" process activity is specified 15. We have defined Event Management's Triggers, Inputs, Outputs and interfaces 16. We have defined Event Management's KPIs and metrics 17. We have defined Event Management's Information Management reporting 18. We have defined Event Management's Challenges, Critical Success Factors and Risks 19. We have defined Incident Management's Purpose, Goal and Objective 20. We have defined Incident Management's Scope 21. We have defined Incident Management's Value to the business 22. We have defined Incident Management's Policies, Principles and basic concepts 23. Timescales are agreed for all incident handling stages 24. Incident Models are defined 25. Major Incidents are defined 26. The "Incident Identification" process activity is specified 27. The "Incident logging" process activity is specified
Page 53
Support Center – Managing and Analyzing 28. The "Incident categorization" process activity is specified 29. The "Incident Prioritization" process activity is specified 30. The "Initial Diagnosis" process activity is specified 31. The "Incident Escalation" process activity is specified 32. The "Incident Identification" process activity is specified 33. The "Investigation and Diagnosis" process activity is specified 34. The "Resolution and recovery" process activity is specified 35. The "Incident Closure" process activity is specified 36. We have defined Incident Management's Triggers, Inputs, Outputs and interfaces 37. We have defined Incident Management's KPIs and metrics 38. We have defined Incident Management's Information Management reporting 39. We have defined Incident Management's Challenges, Critical Success Factors and Risks 40. We have defined Request Fulfillment‘s Purpose, Goal and Objective 41. We have defined Request Fulfillment‘s Scope 42. We have defined Request Fulfillment‘s Value to the business 43. We have defined Request Fulfillment‘s Policies, Principles and basic concepts 44. The "Menu Selection" activity is specified 45. The "Financial approval" activity is specified 46. The "Other approval" activity is specified 47. The "Fulfillment" activity is specified 48. The "Closure" activity is specified 49. We have defined Request Fulfillment‘s Triggers, Inputs, Outputs and interfaces 50. We have defined Request Fulfillment‘s KPIs and metrics 51. We have defined Request Fulfillment‘s Information Management reporting 52. We have defined Request Fulfillment‘s Challenges, Critical Success Factors and Risks 53. We have defined Problem Management's Purpose, Goal and Objective 54. We have defined Problem Management's Scope 55. We have defined Problem Management's Value to the business
Page 54
Support Center – Managing and Analyzing 56. We have defined Problem Management's Policies, Principles and basic concepts 57. The "Problem Detection" process activity is specified 58. The "Problem Logging" process activity is specified 59. The "Problem Categorization" process activity is specified 60. The "Problem Prioritization" process activity is specified 61. The "Problem Investigation and Diagnosis" process activity is specified 62. The "Workarounds" process activity is specified 63. The "Raising a known error record" process activity is specified 64. The "Problem Resolution" process activity is specified 65. The "Problem Closure" process activity is specified 66. The "Major Problem Review" process activity is specified 67. The "Errors detected in the development environment" process activity is specified 68. We have defined Problem Management's Triggers, Inputs, Outputs and interfaces 69. The CMS acts as a valuable source for Problem Management 70. We have a Known Error Database to allow quicker diagnosis and resolution 71. We have defined Problem Management's KPIs and metrics 72. We have defined Problem Management's Information Management reporting 73. We have defined Problem Management's Challenges, Critical Success Factors and Risks 74. We have defined Access Management's Purpose, Goal and Objective 75. We have defined Access Management's Scope 76. We have defined Access Management's Value to the business 77. We have defined Access Management's Policies, Principles and basic concepts 78. The "Requesting Access" process activity is specified 79. The "Verification" process activity is specified 80. The "Providing Rights" process activity is specified 81. The "Monitoring Identity Status" process activity is specified 82. The "Logging and Tracking Access" process activity is specified
Page 55
Support Center – Managing and Analyzing 83. The "Removing or restricting rights" process activity is specified 84. We have defined Access Management's Triggers, Inputs, Outputs and interfaces 85. We have defined Access Management's KPIs and metrics 86. We have defined Access Management's Information Management reporting 87. We have defined Access Management's Challenges, Critical Success Factors and Risks Common Service Operation Activities 88. We know where we are on the technology centric Vs business centric scale 89. Monitoring and control is a continual cycle 90. We use tools to monitor the status of key CIs and key operational activities 91. We ensure that specified conditions are met (or not met), and if not to raise an alert to the appropriate group (e.g. the availability of key network devices) 92. We ensure that the performance or utilization of a component or system is within a specified range (e.g. disk space or memory utilization) 93. We detect abnormal types or levels of activity in the infrastructure (e.g. potential security threats) 94. We detect unauthorized changes (e.g. introduction of software) 95. We ensure compliance with the organization‘s policies (e.g. inappropriate use of email) 96. We track outputs to the business and ensure that they meet quality and performance requirements 97. We track any information that is used to measure Key Performance Indicators 98. We use tools to collate the output of monitoring into information that can be disseminated to various groups, functions or processes 99. We interpret the meaning of that information 100. We determining where that information would best be used 101. We ensure that decision makers have access to the information that will enable them to make decisions 102. We route the reported information to the appropriate person, group or tool 103. We use tools to define what conditions represent normal operations or abnormal operations 104. We regulate performance of devices, systems or services 105. We Measure availability
Page 56
Support Center – Managing and Analyzing 106. We Initiate corrective action, which could be automated (e.g. reboot a device remotely or run a script), or manual (e.g. notify operations staff of the status) 107. We manage the monitor control loop 108. We have defined what needs to be monitored 109. We have internal and external monitoring and control 110. We manage different types of monitoring 111. We monitor in test environments 112. We manage reporting and action upon monitoring 113. We perform service operation audits 114. In IT operations we have a defined Console Management/Operations Bridge 115. In IT operations we have a defined job scheduling role 116. In IT operations we have a defined back-Up and Restore role 117. In IT operations we have a defined Print and Output Role 118. Mainframe management is a mature practice 119. Server Management and support is a mature practice 120. Network management is a mature practice 121. Storage and archive is a mature practice 122. Database Administration is a mature practice 123. Directory Services Management is a mature practice 124. Desktop Support is a mature practice 125. Middleware management is a mature practice 126. Internet/Web Management Mainframe management is a mature practice 127. Facilities and Data Center Management is a mature practice 128. Information Security Management within Service Operation is a mature practice 129. Mainframe management is a mature practice Organizing Service Operation 1. The Service Desk function is defined 2. We have Justification for and the Role of the Service Desk defined
Page 57
Support Center – Managing and Analyzing 3. We have Service Desk Objectives 4. We have a clear Service Desk Organizational Structure 5. Service Desk Staffing is managed 6. We have Service Desk Metrics 7. We investigate(d) Outsourcing the Service Desk 8. The Technical Management Role is defined 9. We have clear Technical Management Objectives 10. We have defined Generic Technical Management Activities 11. We have a clear Technical Management Organization 12. We have Technical Design and Technical Maintenance and Support 13. We have Technical Management Metrics 14. We have Technical Management Documentation 15. The IT Operations Management role is defined 16. IT Operations Management Objectives are defined 17. We have a IT Operations Management Organization 18. We have IT Operations Management Metrics 19. We have IT Operations Management Documentation 20. The Application Management Role is defined 21. We have Application Management Objectives 22. We have Application Management Principles 23. The Application Management Lifecycle is defined 24. We have defined Application Management Generic Activities 25. We have a clear Application Management Organization 26. We have defined Application Management Roles and Responsibilities 27. We have Application Management Metrics 28. We have Application Management Documentation 29. We have clear Service Desk Roles 30. We have Technical Management Roles
Page 58
Support Center – Managing and Analyzing 31. We have IT Operations Management Roles 32. We have Applications Management Roles 33. We have Event Management Roles 34. We have Incident Management Roles 35. We have Request Fulfillment Roles 36. We have Problem Management Roles 37. We have Access Management Roles defined 38. We are organized by Technical Specialization 39. We are organized by Activity 40. We are organized to Manage Processes 41. IT Operations are organized by Geography 42. We have Hybrid Organization Structures of the above Service Operation Technology Considerations 1. We have Integrated IT Service Management Technology 2. We offer Self Help 3. We have a Workflow or Process Engine 4. We have an Integrated CMS 5. We have Discovery/Deployment /Licensing Technology 6. We have Remote Control 7. We have Diagnostic Utilities 8. We have Reporting facilities 9. We have Dashboards 10. We have Integration with Business Service Management 11. We have Event Management technology 12. We have Incident Management technology 13. We have Integrated ITSM technology 14. We have Workflow and Automated Escalation 15. We have Request Fulfillment applications
Page 59
Support Center – Managing and Analyzing 16. We have Problem Management applications 17. We have Integrated Service Management Technology 18. We have Change Management applications 19. We have an Integrated CMS 20. We have a Known Error Database 21. We have Access Management applications 22. We have a Service Desk tool 23. We have Service desk specific Telephony infrastructure 24. The Service desk has access to Support Tools 25. We have IT Service Continuity Planning for ITSM Support Tools Implementing Service Operation 1. We actively Manage Change in Service Operation 2. We monitor and manage Change Triggers 3. We manage Change Assessment 4. We have Measurement of Successful Change defined 5. We Assess and Manage Risks in Service Operation 6. Operational Staff is involved in Service Design and Transition 7. With Planning & Implementing Service Management Technologies we check Licenses 8. With Planning & Implementing Service Management Technologies we check deployment 9. With Planning & Implementing Service Management Technologies we do capacity checks 10. With Planning & Implementing Service Management Technologies we manage the timing of technology deployment
Continual Service Improvement- Service Management as a Practice 1. Service Management is clearly defined 2. We know what our services are 3. We have clearly defined functions and processes across the lifecycle 4. We are able to measure the processes in a relevant matter 5. The reason a process exists is to deliver a specific result
Page 60
Support Center – Managing and Analyzing 6. Every process delivers its primary result to a customer or stakeholder 7. The goals of CSI are defined 8. The objectives of CSI are defined 9. The purpose of CSI is Defined 10. The Scope of CSI is defined 11. We have a CSI Plan 12. Our Service improvement, benefits, ROI and VOI outcomes are clearly defined 13. We have CSI justifications for Business drivers and Technology Drivers 14. The business/customer benefits of CSI are clearly defined 15. The financial benefits of CSI are clearly defined 16. The innovation benefits of CSI are clearly defined 17. The IT Organization Internal benefits of CSI are clearly defined 18. The business/customer benefits of CSI are clearly defined 19. Interfaces to other Service Lifecycle stages are clearly defined CSI Principles 1. CSI is imbedded in organizational change 2. CSI ownership is clearly defined 3. We have role definitions assigned in key activities to key roles 4. We monitor external (regulation, legislation etc.) and internal (org. structure, culture etc.) drivers to CSI 5. We have fully accepted that the IT organization must become a service provider to the business or cease to be relevant 6. We involve the business and determine their service level requirements 7. We define the internal portfolio of Services: services that are planned, in development, in production. 8. We have defined a customer-facing Service Catalogue which details every service and service package offered 9. We Identified internal IT departmental relationships, and codified them with Operational Level Agreements (OLAs) 10. We have identified existing contractual relationships (UCs) with external vendors.
Page 61
Support Center – Managing and Analyzing 11. We utilize the Service Catalogue as the baseline, negotiate Service Level Agreements (SLAs) with the business 12. We have created a Service Improvement Plan (SIP) to continually monitor and improve the levels of service 13. We have service measurement baselines defined 14. We apply the 7-step improvement process 15. We benchmark our services 16. CSI is aligned with governance programs 17. CSI is aligned with supporting frameworks, models, standards and quality systems CSI Processes 1. We have defined what we should measure using The 7 Step Improvement Process 2. We have defined what we can measure using The 7 Step Improvement Process 3. We have defined data gathering (who/how/when/integrity of data) using The 7 Step Improvement Process 4. We have defined how we process the data using The 7 Step Improvement Process 5. We have defined how we analyze the data using The 7 Step Improvement Process 6. We have defined how we present and use the information using The 7 Step Improvement Process 7. We have implemented corrective action using The 7 Step Improvement Process 8. We have defined integration with the rest of the lifecycle domains and service management processes 9. We have Technology metrics in place 10. We have Process metrics in place 11. We have Service Metrics in place 12. CSFs and KPIs are defined 13. The purpose, goal and objective for the Service Reporting process is defined 14. We have defined our reporting policy and rules 15. We have defined our service measurement objectives 16. We have defined our CSI policies 17. Monitoring requirements are defined and implemented
Page 62
Support Center – Managing and Analyzing 18. Data is gathered and analyzed on a consistent basis. 19. Trend reporting is provided on a consistent basis 20. Service Level Achievement reports are provided on a consistent basis 21. Internal and External Service reviews are completed on a consistent basis 22. Services have either clearly defined service levels or service targets 23. Service Management processes have Critical Success Factors and Key Performance Indicators 24. We have defined the Return on Investment (ROI) process for CSI 25. The business case for ROI is established 26. We know what the benefits are of ITIL service improvements 27. We know how it impacts our business 28. We know how revenue is increased with ROI 29. We know our value on investments 30. We know what our ROI is 31. We know what our payback time is 32. We know how ITIL benefits translate to business benefits 33. We measure benefits achieved 34. The business questions for CSI are defined 35. We know where we are now 36. We know what we want 37. We know what we actually need 38. We know what we can afford 39. We know what we will get 40. We know what we did get 41. Service level Management plays a key role in working with the business 42. The goal for the Service Level Management process is defined 43. The service improvement programme is defined CSI methods and techniques
Page 63
Support Center – Managing and Analyzing 1. We have defined methods and techniques for CSI 2. We know the efforts and costs for CSI 3. We have a CSI implementation review and evaluation 4. We have CSI assessments 5. We have defined when to assess 6. We have defined what to assess and how 7. We perform Gap analyses 8. We have a benchmarking procedure 9. We know our benchmarking costs 10. We know the value of benchmarking 11. We have defined the benefits of benchmarking 12. We know who is involved in benchmarking 13. We have defined what to benchmark 14. We know what to compare with industry norms 15. Our benchmark approach is well defined 16. We use the balanced score card approach for measuring and reporting 17. We use SWOT analysis 18. We use the Deming Cycle 19. Component Failure Impact analysis (CFIA) is used 20. Fault Tree Analysis (FTA) is used 21. Service Failure Analysis (SFA) is used 22. Technical Observation (TO) is used 23. Business Capacity Management (BCM) is used 24. Service Capacity Management is used 25. Component Capacity Management is used 26. Workload management and demand management are used 27. The iterative activities of Capacity Management are used 28. Business Continuity Management and ITSCM are integrated
Page 64
Support Center – Managing and Analyzing 29. Risk Management is integrated 30. Problem Management's Post implementation review delivers input to CSI 31. All CSI activities fall under the scope of Change, Release and Deployment Management 32. Inputs on CSIs "What do We Need" are delivered by the Service Knowledge Management system Organizing for CSI 1. Roles and responsibilities for CSI are defined 2. The CSI activities and skills required are defined 3. We have defined what we should measure 4. We have defined what we can measure 5. We have defined which data is gathered how 6. We have defined how we process the data 7. We have defined how we analyze the data 8. We have defined how we present and use the information 9. We have defined how we implement corrective action 10. The service manager role is defined 11. The CSI manager role is defined 12. The Service owner role is defined 13. The process owner role is defined 14. The Service knowledge management role is defined 15. The reporting analyst role is defined 16. The authority matrix is defined CSI Technology Considerations 1. We use an IT Service management suite to support CSI activities 2. We use systems and network management tools to support CSI activities 3. We use event management tools to support CSI activities 4. We use automated incident / problem management tools to support CSI activities 5. We use knowledge management tools to support CSI activities
Page 65
Support Center – Managing and Analyzing 6. We use tools to support CSI activities 7. We use service catalogue and workflow tools to support CSI activities 8. We use performance management tools to support CSI activities 9. We use application and service performance monitoring tools to support CSI activities 10. We use statistical analysis tools to support CSI activities 11. We use software version control tools to support CSI activities 12. We use software test management tools to support CSI activities 13. We use security management tools to support CSI activities 14. We use project and portfolio management tools to support CSI activities 15. We use financial management tools to support CSI activities 16. We use business intelligence and reporting tools to support CSI activities Implementing CSI 1. The critical roles for CSI have been identified and filled (CSI manager/service owner/reporting analyst) 2. Monitoring and reporting on technology, process and service metrics are in place 3. Internal service review meetings are scheduled 4. Either the service approach or the lifecycle approach is chosen as a basis for CSI implementation 5. Governance is addressed from a strategic view 6. The IT service Management program initiative is defined 7. The business drivers are defined 8. The process changes are defined 9. CSI and organizational change is underpinned by Kotter's change management best practices 10. We have a communication strategy and plan
CONCLUSION There is a lot more to implementing ITIL Service Management than meets the eye. The ITIL Framework is quite large and at first may be daunting to the IT Director or CIO who is investigating the implementation of the framework in the IT organisation.
Page 66
Support Center – Managing and Analyzing The first step is to understand the current situation. Where are we now? What is our current state of affairs? What can stay, and what has to change? This is also the time when your team will create the vision for the future: where do we want to be? What type of IT organisation do we want to be, and what level of maturity is required? The planning stage of an ITIL Implementation project can last anywhere between a month and a year. However, without this solid planning phase the outcome of the project will most likely be at risk. Based on the outcome of this assessment a long term plan can be painted as well as a selection of the first few processes that will be improved and implemented. The design and documentation of the new processes is a (relatively) easy task. The biggest challenge is to create processes that support the overall business vision of the IT shop, and have the full backup and support from the IT staff on the floor. Because ultimately they need to work with the new and improved processes. Creating a new series of process documents that nobody will read is a waste of money, time and effort. The challenge is to create a series of processes that are adopted by all IT staff in the shop and actively used for the delivery of IT Services to the customers. The benefits are achievable, and very tangible for most organisations. But only when you realise that implementing this framework is a lot more involved than a simple technology implementation. We are dealing with management processes and the adoption of improved processes by people... and that takes time.
Delivering Unforgettable Customer Service: The Guide For Implementing Perfect Service in Your Organization This book saves organizations. If you have been a struggling business owner thinking your problem was either that you are undercapitalized or that you have hired the wrong people. Delivering Unforgettable Customer Service is a wake up call. The problem might well be that you aren't creating Unforgettable Customer Service. You are satisfied if your customers are satisfied, but mostly service is so bad somply because customers expectations are low. It's easy to satisfy low expectations and it doesn't mean very much. You have to create Unforgettable Customer Service. Customers who tell others how wonderful you are. You'd want everyone in your Page 67
Support Center – Managing and Analyzing company focused on customers. Focused on creating stories your customers can tell others. Best of all Delivering Unforgettable Customer Service gives you the road map to do it, all wrapped up in easy lessons. This book may be simple, but it is also profound and by far the best customer service book you will ever read. Start today with adopting the strategy of creating Unforgettable Customer Service and then get everyone in the company to do the same. The result will be that you will have stopped burning your customer list every six months. you will be retaining old customers, adding new ones and sales are way up. Today Delivering Unforgettable Customer Service is required reading for every new hire.
Customer service Customer service is the provision of service to customers before, during and after a purchase. According to Turban et al. (2002), ―Customer service is a series of activities designed to enhance the level of customer satisfaction – that is, the feeling that a product or service has met the customer expectation.‖ Its importance varies by product, industry and customer. As an example, an expert customer might require less pre-purchase service (i.e., advice) than a novice. In many cases, customer service is more important if the purchase relates to a ―service‖ as opposed to a ―product". Customer service may be provided by a person (e.g., sales and service representative), or by automated means called self-service. Examples of self service are Internet sites. The experience a customer has of a product also affect the total service experience, but this is more of a product direct feature than what is included in the definition of customer service. Customer service is normally an integral part of a company‘s customer value proposition. From the point of view of an overall sales process engineering effort, customer service plays an important role in an organization's ability to generate income and revenue. From that perspective, customer service should be included as part of an overall approach to systematic improvement. Some have argued that the quality and level of customer service has decreased in recent years, and that this can be attributed to a lack of support or understanding at the executive and middle management levels of a corporation and/or a customer service policy. Others, like Headsets.com CEO Michael G. Faith (Mike Faith), believe Page 68
Support Center – Managing and Analyzing that providing a high level of customer service, which he refers to as Customer Love, is the only way to grow your business in these times. Faith recently spoke at the Inc. Growco Conference on the subject of using customer service to grow your business.
Instant feedback Recently, many organizations have implemented feedback loops that allow them to capture feedback at the point of experience. For example, National Express, one of the UK's leading travel companies invites passengers to send text messages whilst riding the bus. This has been shown to be useful as it allows companies to improve their customer service before the customer defects, thus making it far more likely that the customer will return next time.
Setting the right KPIs A challenge working with Customer Service is to ensure that you have focused your attention on the right key areas, measured by the right Key Performance Indicator. There is no challenge to come up with a lot of meaningful KPIs, but the challenge is to select a few which reflects your overall strategy. In addition to reflecting your strategy it should also enable staff to limit their focus to the ones that really matter. The focus must be of those KPIs, which will deliver the most value to the overall objective, e.g. cost saving, service improving etc. It must also be done in such a way that staff sincerly believe that they can make a difference with the effort.
Customer Service - An Imperative The Golden Rule, "do unto others as you would have them do unto you," may seem self-evident in the way we try to conduct our personal lives. Yet this axiom is assuming new importance as a guiding principle in the world of business. The climate of the recession-ridden early 1980s, when customers blithely traded away high-quality service in exchange for price reductions or convenience, is no more. Instead, customers are demanding service again. Companies of all sizes are realizing that their strongest selling point can sometimes boil down to treating customers as they would like to be treated - or better. "Consumers are beginning to feel that their needs haven't been met," explains Bonnie Jansen of the U.S. Office of Consumer Affairs. "They're sick of getting poor service all the time." The message is getting through. According to John Goodman, president of the Technical Assistance Research Programs Institute (TARP), "In the past few years, companies began to realize that service was really a competitive factor, and began to view it as an integral part of their product." The growing significance of meeting - or exceeding - customer demands for quality service has special implications for small businesses. It is in this arena that small companies can, in the least expensive way, set themselves apart from the competition. Page 69
Support Center – Managing and Analyzing In fact, a recent three-year study by the National Federation of Independent Business (NFIB) in Washington, D.C. showed that small businesses which put heavy emphasis on customer service were more likely to survive and succeed than competitors who emphasized such advantages as lower prices or type of product.
Golden Rule #1: Put the Customer First "A strong customer ethic must guide your business from the inception," writes author and business owner Paul Hawken in his book Growing a Business. "No matter whether you manufacture, grow, produce, distribute, or sell, you are 'in service.'" Quality customer service begins with your employees. An owner of a successful chain of hair salons advises that the first step is to set standards, then make sure everyone in the company understands them. Finally, he says, reward employees for achieving your service goals. Be sure to seek out and solve any annoyances they might have that could lead to poor morale. An employee with a complaint cannot be completely effective in dealing with customers. "If you take care of your employees, they will take care of your customers." On the other hand, Hawken warns, if your employees are not customer-oriented, no standards or goals will change that. "We concentrate on hiring people who embody the quality of service for which we strive. It is difficult to teach someone to be helpful and serve others if he or she is misanthropic to begin with." Hiring the best people means trusting them. Your employees should be able to do what is necessary to make the customer happy without fear of reprisal. Hawken says, "Policies and procedures are helpful only as guides toward an end result. When employees run out of possibilities to make the customer happy, they must have the latitude to improvise to make it right. Most employees operate in a state of fear that their own generosity with a customer will be viewed as foolishness by their boss. This situation will stifle flexible customer service."
Golden Rule #2: Stay Close to Your Customers In the smartest companies, asking questions and listening carefully to the answers is an important part of customer service. These firms train their employees to focus on what the customer is saying, then tailor products or services to meet customer needs. Says one corporate executive, and his words hold true for smaller firms as well, "Knowing what's on the customer's mind is the smartest thing we can do." It is also cheaper than attracting new customers. According to the Customer Service Institute, 65% of a company's business comes from existing customers, and it costs five times as much to attract a new customer than to keep an existing one satisfied. Losing a customer is even more expensive. According to studies by the Technical Assistance Research Programs Institute, 91% of unhappy customers will never Page 70
Support Center – Managing and Analyzing again buy from a company that has displeased them; they will also voice their dissatisfaction to at least seven other people. This responsibility to be receptive does not lie solely with your employees, however. If you want your business to be successful, you must listen to and talk with customers as well. There is no substitute for getting out and learning from the customers themselves how you might serve them better. The best business owners are not only committed to staying close to their clientele, but also identify with them. They give their customers the level of service they themselves would expect to receive. Moreover, a good relationship with customers necessitates paying attention to every link in the distribution chain; this means listening to everyone who helps get your products to market and asking them for suggestions on improving your service. Be sure to take advantage of feedback from employees, especially those whose everyday job is dealing with customers. They can serve as tremendous reservoirs of information. "Our goal as a company is to create customer service that is not just the best, but legendary," Paul Hawken asserts. "'Legendary' gives everyone who deals with customers a rich sense of the possibilities."
Golden Rule #3: Pay Attention to the Little Details Many owners search for a special touch that will make them stand out from the crowd. Discount coupons, longer hours, home delivery, or free coffee, for example, all show customers you want to take that extra step to please them. Some of the most effective extras are really very basic adages of conducting good business, although customers are often surprised when they take place. These include answering the phone by the third ring, treating customers respectfully and courteously at all times, greeting them by name, promptly answering their questions, and, if you can't, getting back to them with an answer as quickly as possible, and manufacturing high-quality goods that work the first time and keep working.
Conclusion Customer service is definitely enjoying resurgence. It's no longer the domain of a few clever companies which have made it synonymous with their names. No business, whatever its size, can afford to take customers for granted, because it is without question a buyer's market and becomes more so every day. To succeed, you must give your customers what they want, not what you think they want. As you never know who might eventually become a customer, that means providing courteous, friendly service to your suppliers and others with whom you come in contact as well as current customers. If you want to keep customers coming back for more, practicing the Golden Rules has never made better business sense.
Five Rules of Customer Care Page 71
Support Center – Managing and Analyzing Critical to keeping customers happy is understanding them and the way they think. For example, customers do business on the basis of emotional desire - they want what they want when they want it. Customers also tend to gravitate toward a company or group of people they like. Most customers also have a strong tendency to stick with businesses with which they are familiar, and are slow to change buying habits unless given a very good reason. However, when they are displeased, even by a small disappointment or discourteous word, various surveys have revealed that customers tell from seven to eleven people about their dissatisfaction. An important key to serving customers well is this: don't try to change them. Here are five specific steps to help you take full advantage of the critical element of customer care: 1. Conduct your own survey. Profit from the ideas, suggestions, and complaints of your present and former customers. Talk and meet with your customers. Ask questions. Learn their attitudes, what they want, and what they dislike. 2. Check employees' telephone manners periodically. This link is particularly important for small businesses, as bad telephone handling can undermine other constructive efforts to build a profitable enterprise. 3. Rules such as prompt answering and a cheerful attitude of helpfulness are of critical importance. Have someone whose voice is unfamiliar play the role of a customer or prospective customer, preferably a difficult one. 4. Make customer service a team effort. Use group meetings, memos, posters, and in-house publications to build customer consciousness throughout the organization. Continually drive home the crucial rule that getting and holding customers requires team play; invite employees' ideas. 5. Extend your efforts after hours. It's the friendly feelings people have that draw them to you and your business. Take advantage of the relaxed atmosphere of social occasions or a neighborly chat over the back fence to turn friends into customers or to reinforce the loyalty of existing ones.
Choosing the Right Customer Service Representatives
Nature of the Work
Training, Other Qualifications, and Advancement
Employment
Job Outlook Page 72
Support Center – Managing and Analyzing
Projections Data
Earnings
OES Data
Related Occupations
Sources of Additional Information
Significant Points
Job prospects are expected to be excellent.
Most jobs require only a high school diploma but educational requirements are rising.
Strong verbal communication and listening skills are important.
Nature of the Work Customer service representatives are employed by many different types of companies to serve as a direct point of contact for customers. They are responsible for ensuring that their company‘s customers receive an adequate level of service or help with their questions and concerns. These customers may be individual consumers or other companies, and their service needs can vary considerably. All customer service representatives interact with customers to provide information in response to inquiries about products or services and to handle and resolve complaints. They communicate with customers through a variety of means—by telephone; by e-mail, fax, regular mail; or in person. Some customer service representatives handle general questions and complaints, whereas others specialize in a particular area. Many customer inquiries involve routine questions and requests. For example, customer service representatives may be asked to provide a customer with their credit card balance, or to check on the status of an order. However, other questions are more involved, and may require additional research or further explanation on the part of the customer service representative. In handling customers‘ complaints, they must attempt to resolve the problem according to guidelines established by the company. These procedures may involve asking questions to determine the validity of a complaint; offering possible solutions; or providing customers with refunds, exchanges, or other offers, like discounts or coupons. In some cases, customer service representatives are required to follow up with an individual customer until a question is answered or an issue is resolved. Some customer service representatives help people decide what types of products or services would best suit their needs. They may even aid customers in completing Page 73
Support Center – Managing and Analyzing purchases or transactions. Although the primary function of customer service representatives is not sales, some may spend time encouraging customers to purchase additional products or services. (For information on workers whose primary function is sales, see the statements on sales and related occupations elsewhere in the Handbook.) Customer service representatives also may make changes or updates to a customer‘s profile or account information. They may keep records of transactions and update and maintain databases of information. Most customer service representatives use computers and telephones extensively in their work. Customer service representatives frequently enter information into a computer as they are speaking to customers. Often, companies have large amounts of data, such as account information, that is pulled up on a computer screen while the representative is talking to a customer so he or she can answer specific questions. Customer service representatives also usually have answers to the most common customer questions, or guidelines for dealing with complaints. In the event that they encounter a question or situation to which they do not know how to respond, workers consult with a supervisor to determine the best course of action. They generally use multiline telephone systems, which may route calls directly to the most appropriate representative. However, at times, they must transfer calls to someone who may be better able to respond to the customer‘s needs. In some organizations, customer service representatives spend their entire day on the telephone. In others, they may spend part of their day answering e-mails and the remainder of the day taking calls. For some, most of their contact with the customer is face to face. Customer service representatives need to remain aware of the amount of time spent with each customer so that they can fairly distribute their time among the people who require their assistance. This is particularly important for those whose primary activities are answering telephone calls and whose conversations are required to be kept within a set time limit. For those working in call centers, there is usually very little time between telephone calls. When working in call centers, customer service representatives are likely to be under close supervision. Telephone calls may be taped and reviewed by supervisors to ensure that company policies and procedures are being followed. Job responsibilities also can differ, depending on the industry in which a customer service representative is employed. For example, those working in the branch office of a bank may assume the responsibilities of other workers, such as teller or new account clerk, as needed. In insurance agencies, a customer service representative interacts with agents, insurance companies, and policyholders. These workers handle much of the paperwork related to insurance policies, such as policy applications and changes and renewals to existing policies. They answer questions regarding policy coverage, help with reporting claims, and do anything else that may need to be done. Although they must have similar credentials and knowledge of insurance products as insurance agents, the duties of a customer service Page 74
Support Center – Managing and Analyzing representative differ from those of an agent as they are not responsible for seeking potential customers. Customer service representatives employed by utilities and communications companies assist individuals interested in opening accounts for various utilities such as electricity and gas, or for communication services such as cable television and telephone. They explain various options and receive orders for services to be installed, turned on, turned off, or changed. They also may look into and resolve complaints about billing and other service.
Work environment. Although customer service representatives work in a variety of settings, most work in areas that are clean and well lit. Many work in call or customer contact centers where workers generally have their own workstation or cubicle space equipped with a telephone, headset, and computer. Because many call centers are open extended hours, beyond the traditional work day, or are staffed around the clock, these positions may require workers to take on early morning, evening, or late night shifts. Weekend or holiday work also may be necessary. As a result, the occupation is well suited to flexible work schedules. About 17 percent of customer service representatives work part time. The occupation also offers the opportunity for seasonal work in certain industries, often through temporary help agencies. Call centers may be crowded and noisy, and work may be repetitious and stressful, with little time between calls. Workers usually must attempt to minimize the length of each call, while still providing excellent service. To ensure that these procedures are followed, conversations may be monitored by supervisors, which be stressful. Also, long periods spent sitting, typing, or looking at a computer screen may cause eye and muscle strain, backaches, headaches, and repetitive motion injuries. Customer service representatives working outside of a call center environment may interact with customers through several different means. For example, workers employed by an insurance organization or in a grocery store may have customers approach them in person or contact them by telephone, computer, mail, or fax. Many of these customer service representatives work a standard 40-hour week; however, their hours generally depend on their employer‘s hours of operation. Work environments outside of a call center also vary accordingly. Most customer service representatives work either in an office or at a service or help desk. Customer service representatives may have to deal with difficult or irate customers, which can be challenging. However, the ability to resolve customers‘ problems has the potential to be very rewarding.
Training, Other Qualifications, and Advancement
Page 75
Support Center – Managing and Analyzing Most jobs require at least a high school diploma. However, employers are increasingly seeking candidates with some college education. Most employers provide training to workers before they begin serving customers. Education and training.
Most customer service representative jobs require only a high school diploma. However, because employers are demanding a higher skilled workforce, many customer service jobs now require an associate or bachelor‘s degree. High school and college level courses in computers, English, or business are helpful in preparing for a job in customer service. Training requirements vary by industry. Almost all customer service representatives are provided with some training prior to beginning work. This training generally includes customer service and phone skills; information on products and services; information about common customer problems; the use of the telephone and computer systems; and company policies and regulations. Length of training varies, but usually lasts at least several weeks. Because of a constant need to update skills and knowledge, most customer service representatives continue to receive training throughout their career. This is particularly true of workers in industries such as banking, in which regulations and products are continually changing. Other qualifications.
Because customer service representatives constantly interact with the public, good communication and problem-solving skills are a must. Verbal communication and listening skills are especially important. For workers who communicate through email, good typing, spelling, and writing skills are necessary. Basic to intermediate computer knowledge and good interpersonal skills also are important qualities for people who wish to be successful in the field. Customer service representatives play a critical role in providing an interface between customers and companies. As a result, employers seek out people who are friendly and possess a professional manner. The ability to deal patiently with problems and complaints and to remain courteous when faced with difficult or angry people is very important. Also, a customer service representative needs to be able to work independently within specified time constraints. Workers should have a clear and pleasant speaking voice and be fluent in English. However, the ability to speak a foreign language is becoming increasingly necessary. Although some positions may require previous industry, office, or customer service experience, many customer service jobs are entry level. However, within insurance agencies and brokerages, these jobs usually are not entry-level positions. Workers must have previous experience in insurance and often are required by State regulations to be licensed like insurance sales agents. A variety of designations are available to demonstrate that a candidate has sufficient knowledge and skill, and continuing education courses and training often are offered through the employer. Page 76
Support Center – Managing and Analyzing Advancement.
Customer service jobs are often good introductory positions into a company or an industry. In some cases, experienced workers can move up within the company into supervisory or managerial positions or they may move into areas such as product development, in which they can use their knowledge to improve products and services. As they gain more knowledge of industry products and services, customer service representatives in insurance may advance to other, higher level positions, such as insurance sales agent.
Employment Customer service representatives held about 2.2 million jobs in 2006. Although they were found in a variety of industries, about 23 percent of customer service representatives worked in finance and insurance. The largest numbers were employed by insurance carriers, insurance agencies and brokerages, and banks and credit unions. About 14 percent of customer service representatives were employed in administrative and support services. These workers were concentrated in the business support services industry (which includes telephone call centers) and employment services (which includes temporary help services and employment placement agencies). Another 11 percent of customer service representatives were employed in retail trade establishments such as general merchandise stores and food and beverage stores. Other industries that employ significant numbers of customer service representatives include information, particularly the telecommunications industry; manufacturing, such as printing and related support activities; and wholesale trade.
Job Outlook Customer service representatives are expected to experience growth that is much faster than the average for all occupations through the projection period. Furthermore, job prospects should excellent as workers who leave the occupation will need to be replaced. Employment Change.
Employment of customer service representatives is expected to increase 25 percent from 2006 to 2016, which is much faster than the average for all occupations. This occupation will have one of the largest numbers of new jobs arise, about 545,000 over the 2006-16 projection period. Beyond growth stemming from expansion of the industries in which customer service representatives are employed, a need for additional customer service representatives is likely to result from heightened reliance on these workers. Customer service is very important to the success of any organization that deals with customers, and strong customer service can build sales, visibility, and loyalty as companies try to distinguish themselves from competitors. In Page 77
Support Center – Managing and Analyzing many industries, gaining a competitive edge and retaining customers will be increasingly important over the next decade. This is particularly true in industries such as financial services, communications, and utilities, which already employ numerous customer service representatives. As the trend towards consolidation in industries continues, centralized call centers will provide an effective method for delivering a high level of customer service. As a result, employment of customer service representatives may grow at a faster rate in call centers than in other areas. However, this growth may be tempered by a variety of factors such as technological improvements that make it increasingly feasible and cost-effective for call centers to be built or relocated outside of the United States. Technology is affecting the occupation in many ways. The Internet and automated teller machines have provided customers with means of obtaining information and conducting transactions that do not entail interacting with another person. Technology also allows for greater streamlining of processes, while at the same time increasing the productivity of workers. The use of computer software to filter e-mails, generating automatic responses or directing messages to the appropriate representative, and the use of similar systems to answer or route telephone inquiries are likely to become more prevalent in the future. Also, with rapidly improving telecommunications, some organizations have begun to position their call centers overseas. Despite such developments, the need for customer service representatives is expected to remain strong. In many ways, technology has heightened consumers‘ expectations for information and services, and the availability of information online seems to have generated more need for customer service representatives, particularly to respond to e-mail. Also, technology cannot replace human skills. As more sophisticated technologies are able to resolve many customers‘ questions and concerns, the nature of the inquiries handled by customer service representatives is likely to become increasingly complex. Furthermore, the job responsibilities of customer service representatives are expanding. As companies downsize or take other measures to increase profitability, workers are being trained to perform additional duties such as opening bank accounts or cross-selling products. As a result, employers increasingly may prefer customer service representatives who have education beyond high school, such as some college or even a college degree. While jobs in some industries—such as retail trade—may be affected by economic downturns, the customer service occupation generally is resistant to major fluctuations in employment. Job prospects.
Prospects for obtaining a job in this field are expected to be excellent, with more job openings than jobseekers. Bilingual jobseekers, in particular, may enjoy favorable Page 78
Support Center – Managing and Analyzing job prospects. In addition, numerous job openings will result from the need to replace experienced customer service representatives who transfer to other occupations or leave the labor force. Replacement needs are expected to be significant in this large occupation because many young people work as customer service representatives before switching to other jobs. This occupation is well suited to flexible work schedules, and many opportunities for part-time work will continue to be available, particularly as organizations attempt to cut labor costs by hiring more temporary workers.
Projections Data Projections Data Projections data from the National Employment Matrix
Occupational title
Employment, 2006
2,202,000
Customer service representatives
Projected employment, 2016
Change, 2006-16 Number
Percent
2,747,000
545,000
25
NOTE: Data in this table are rounded.
.
Earnings In May 2006, median hourly earnings for wage and salary customer service representatives were $13.62. The middle 50 percent earned between $10.73 and $17.40. The lowest 10 percent earned less than $8.71 and the highest 10 percent earned more than $22.11. Earnings for customer service representatives vary according to level of skill required, experience, training, location, and size of firm. Median hourly earnings in the industries employing the largest numbers of these workers in May 2006 were: Insurance carriers $15.00 Agencies, brokerages, and other insurance related activities 14.51 Depository Credit Intermediation 13.68 Employment services
11.74
Telephone call centers
10.29
In addition to receiving an hourly wage, full-time customer service representatives who work evenings, nights, weekends, or holidays may receive shift differential pay. Also, because call centers are often open during extended hours, or even 24 hours a day, some customer service representatives have the benefit of being able to work a Page 79
Support Center – Managing and Analyzing schedule that does not conform to the traditional workweek. Other benefits can include life and health insurance, pensions, bonuses, employer-provided training, and discounts on the products and services the company offers.
Related Occupations Customer service representatives interact with customers to provide information in response to inquiries about products and services and to handle and resolve complaints. Other occupations in which workers have similar dealings with customers and the public are information and record clerks; financial clerks such as tellers and new account clerks; insurance sales agents; securities, commodities, and financial services sales agents; retail salespersons; computer support specialists; and gaming services workers.
Differentiating your organization through Customer Focus Increasingly organizations are looking at service more as a strategic advantage than as an operational necessity. Businesses are feeling the pressures of a constantly changing marketplace and are experiencing difficulties differentiating their offerings in the intensified competition of this environment. A consistent theme shared by those businesses thriving in this competitive marketplace is a strategic emphasis on enhancing revenue by making quality, innovation, and customer responsiveness the central values of their corporate cultures. Research has shown that companies that have successfully accomplished this differentiation charge more for their products, grow market share faster, and have a better return on sales than competitors. On the other hand, businesses that neglect the service component are carrying the needlessly high costs of bad service through the active word of mouth of dissatisfied customers and increasingly expensive advertising and marketing to attract new customers. We discovered that many recent predictions about market forces had already come true. Businesses were already feeling the pressures of a changing marketplace and were experiencing difficulties differentiating their offerings in this competitive environment. Many businesses respond to these market pressures first by lowering prices and competing as if goods and services were commodities. These businesses soon found that there always seemed to be a competitor willing to offer a deeper discount. They also found that a consumer base could be attracted but not maintained on price alone. Next, many businesses turned to cost containment, trying to maintain profitability by controlling overhead. In some cases, Page 80
Support Center – Managing and Analyzing these strategies proved successful, but all too often these approaches resulted in flat earnings and loss of market share. The few businesses to thrive in this competitive marketplace were diligently pursuing a different strategy, one aimed on enhancing revenue by making quality, innovation, and customer responsiveness the central values of their corporate cultures. These rare businesses managed to shape their very structure and purpose toward creating and keeping customer satisfaction, and these few enterprises enjoy profitability and dominant market share. In Thriving on Chaos, Tom Peters offers this formula, ―Long-term profit equals revenue from continuously happy customer relationships minus cost.‖ Peters‘ formula for profitability has face validity and seems the direct product of oldfashioned common sense, but its truth is also measurable. Ron Zemke, writing in Employment Relations Today, cites a study that reveals, ―...companies that distinguish themselves in their customers‘ eyes on the basis of service and quality charge more for their products and services (up to 10 percent more), grow market share faster (6 percent vs. 2 percent), and have a better return on sales than competitors (12 percent vs. 4 percent).‖ The companies that maintain a primary strategic focus on their competitors (competing on the basis of price) and companies that maintain a primary strategic focus on internal issues (competing by cost containment) are finding themselves absorbing the exorbitant costs of delivering poor service to their customers. Data compiled by Technical Assistance Research Programs, or TARP, a Washington DC based research firm, highlight the costs of failing to satisfy customers: • Customers who are only somewhat satisfied are 10-20% less likely to make a repeat purchase than customers who are very satisfied. •
Customers who experience mild dissatisfaction tell on average 9 other people.
• Customers who experience stronger dissatisfaction tell on average 16 other people. • Only 4% of customers who experience a small problem will make their experience known to senior management of the vendor organization. • In research covering over 30 industries TARP found that companies spend, on average, 3-5 times more to replace a dissatisfied customer than to keep a current customer. (And this figure is even higher in big-ticket products and business-tobusiness sales!) The message to the business world is clear. This data turns an old adage on its head. What you don‘t know is hurting you. Customers who are less than satisfied may not be letting you know what they think of your organization, but they are telling Page 81
Support Center – Managing and Analyzing other potential customers about their dissatisfaction. Customers who experience dissatisfaction are becoming your competitor‘s customers. Attracting new customers is more expensive than keeping current customers. And most importantly the message is: Companies that position customer responsiveness as a primary business strategy are making money and gaining market share. Many businesses and institutions got the message and are moving to become ―customer-focused.‖ This movement involves a rethinking of values, policies, and controls and a restructuring that reflects a renewed sense of mission. Training is but one means of instituting change and communicating purpose. Customer Focus is designed to complement such a movement toward revenue enhancement through renewed attention to the customer‘s interface with an organization. Customer Focus is the key to customer satisfaction, and is the response to a variety of market forces. Organisations were asking for skill-building training that could be delivered by internal trainers and could be delivered in several configurations. They were concerned with keeping and increasing customer loyalty in the face of greater competition. As they align their businesses with a new strategy, they needed training that supported this new strategy. Many customers expressed a need for training that would help providers deal with ―difficult‖ customers. Customer Focus meets all these requirements. It provided knowledge, enhances skills, and renews the attitudes of those who work with customers. Research tells us that ―Good and bad feelings represent independent dimensions of affective responses to products in use (post purchase). Good feelings about product/consumption outcomes do not necessarily imply the absence of unpleasant feelings.‖ (R.A. Westbrook, ―Product/consumption-based Affective Responses and Post-purchase Processes‖, Journal of Marketing Research) this counterintuitive conclusion that satisfaction and dissatisfaction are two separate dimensions is the basis for our model, the Zone of Indifference. Satisfaction is not the opposite of dissatisfaction. Nor is it the absence of dissatisfaction. Upon reflection we are able to adjust our common sense concept to include this idea. We can remember buying a new car, loving the purchase, but hating the process, or eating a cheeseburger that satisfied certain cravings, but caused a tummy ache. Research also tells us that customers with big problems behave differently than customers with minor problems. And also there is research to indicate that highly satisfied customers tend to repurchase with greater frequency than mildly satisfied customers. Which is to say dissatisfaction and satisfaction are experienced in degrees. A customer can be, ―Well, I don‘t know, kind of satisfied, maybe,‖ or ―Pretty satisfied,‖ or ―Boy, that‘s terrific!‖ We know from personal experience that high dissatisfaction and high satisfaction are relatively rare, and that most customer experiences are mixed and have a mild intensity. That is, most of the time customers Page 82
Support Center – Managing and Analyzing experience a combination of mild dissatisfaction and mild satisfaction. In our model we represent these mid-range conditions as the Zone of Indifference. This ―Zone of Indifference‖ represents both a huge opportunity for dramatic increases in satisfaction and a dangerously tenuous customer base. Relatively small improvements in the service encounter can intensify the customer‘s mildly positive affects and move the customer from mildly satisfied, out of the Zone of Indifference, to satisfaction. TARP‘s research, that 96% of all customers with a minor problem don‘t communicate their problem to the management of the vending organization, tells us that the concerns of customers in the Zone of Indifference are unknown to the service vendor and are therefore generally ignored. The mildly satisfied and mildly dissatisfied customers are easily, and rightfully, lost to competitors, if their positive affects aren‘t strengthened by the service interaction.
The Customer Focus Model Satisfaction is the positive judgment made by the customer after evaluating the service, product, or buying experience. The customer, not the service provider or company policies, determines whether or not satisfaction is obtained. The findings of cognitive psychology tell us that this determination is fairly complex and is built from several interacting components. Each customer comes to the service interaction loaded with a unique combination of information, experience, expectations, and a variety of feelings, or affects, about the impending experience. The service interaction itself adds additional information, experience, affects, and expectations are met or disconfirmed. All of these processes go on in, in a sense, inside the customer and are accessible only through the customer‘s own report and by observing the customer‘s behaviour. R.E. Krapfel in ―Customer complaint and salesperson response: The effect of the Communication Source,‖ published in the Journal of Retailing, is able to document how customer appearance and interaction style effect the outcome of complaint requests. This study found that customers perceived to be more similar to the employee are judged to have requests that are more legitimate, and that customer‘s interaction style and appearance influence the employee‘s willingness to comply with a complaint request. The study recommends that customers ―dress up‖ to increase the likelihood of complaints being redressed! Of course, our experience as customers reminds us that we repeatedly adjust our behaviour to ―match‖ the scene. Customer Focus, however, recommends that the service provider adjust to the interaction style of the individual customer. Research shows that most service interactions leave the customers feeling mildly indifferent about their experience...that customers come to the service interaction loaded with a wide Page 83
Support Center – Managing and Analyzing variety of experience, expectations, feelings, and information...that it may take only a small assortment of positive events (a personal greeting, a smile, a quick action on the customer‘s behalf, a demonstration of competence, a clear explanation, etc.) to intensify customer‘s positive affects and shape the customer‘s determination of satisfaction. Since service providers aren‘t normally mind readers and don‘t have access to customers‘ internal processes, they are left to observe customer behaviour in order to make some determination of the customer‘s individual attitude. The concept isolates four very general groups of observable temporary customer behaviours that we call the customer attitudes. The four customer attitudes describe a broad range of behaviour encountered in a service interaction. In concept testing sessions and in field trials customer service personnel from a wide variety of businesses have found the customer attitudes to have immediate face validity and serve as a useful diagnostic tool for the customer/service provider interaction.
The Customer Focus Approach Since customers come to the service encounter with a variety of attitudes and with various needs and expectations, the concept offers a dynamic and flexible model for customer interactions. The model is dynamic in that it accepts the premise that customers with different attitudes need different initial responses from service providers...and that customers can and will change attitudes in the course of a single interaction. The model reflects what actually happens when a service provider meets a customer‘s needs and helps the customer to from a judgment of satisfaction about the experience. This is to say that the model helps service providers deal both with the service issue and with the customer‘s emotionality or affect. Research has shown that an upset customer will report stronger positive affects, when the provider successfully redresses both the problem (fixes the toaster) and the customer‘s feelings about the problem (I‘m sorry for the inconvenience), that when only the service issue is addressed.
The Customer Focus Approach also helps the customer form a judgment of satisfaction by encouraging the service provider to ask for an expression of satisfaction. Since satisfaction is the province of the customer, the only way to know if a customer is satisfied is to ask. And rather than rely solely on measurement instruments or response cards, which only capture the feedback of compliant customers, the Customer Focus Approach asks every customer to respond. This simple but powerful component of the service interaction offers several benefits. It accomplishes a great deal of what Tom Peters (In Search of Excellence) calls naïve Page 84
Support Center – Managing and Analyzing listening by inviting the customer to immediately report on his or her impressions of the provider organization. It reinforces in the customer‘s mind the positive aspects of the experience. It helps get at lingering or unspoken needs, and expectations and allows the service provider to loop back into the approach to meet these needs. And it provides immediate, frequent, and very powerful feedback to the service provider.
Conclusion Customer Focus was developed through a thoroughly market-oriented process. It was created from the needs of the marketplace as a way to address today‘s business issues. It is based on extensive research and experience. The central ideas of the concept -- that customers are individuals, that satisfaction is the judgment made by the individual customer in response to an interaction with an individual service provider -- differentiate this training from other customer service training. Customers are seen as individuals rather than as demographic aggregates. Service providers are seen as individuals with significant expertise and influence.
Hiring the Best Customer Service Representatives This Guide is all about clarity of the total hiring process – for you, your manager and your candidates. Great Process to Hire the Best. Computers and equipment are wonderful tools, but people make the difference. Hiring the Best makes it clear just how valuable it is to hire and work with the best. The mistakes you will avoid make the investment very valuable. Hiring the Best provides you with a process that reduces trial and error in recruiting a lot, but still ensures that you will be able to hire the best. Thischapter guides you to how to perform a truly in-depth hiring process and interview for candidates. The process will allow you and your company to select the best candidates for key positions. You will be able to use the materials shown here as an outstanding tool, giving you insight into the candidates experience, performance history, and growth allowing you to determine what they are capable of today and in the future. This will, in short, let you go from hoping your next hire works out to being confident your next hire will be a star. Before you make your next hire, use this Guide.
THE INTERVIEW AND SELECTION PROCESS Five Steps for Successful Behavioral Interviewing 1 Analyze the Technical Aspects of the Job Technical Competency Assessment Guide
Page 85
Support Center – Managing and Analyzing 2
Determine the Customer Service Focused Competencies of the Job Customer Service Focused Behavior Assessment Guide 3 Develop Interview Questions 4 Conduct the Interview 5 Reference and Background Checking After the Interview Making A Job Offer Informing Unsuccessful Candidates Retention of Interview Materials Sample Behavioral-Based Customer Service Focused Interview Questions This Advisory gives detailed information about the interview process. One of the most important parts of the process of hiring is determining what competencies are required for the job, and developing interview questions that will help the hiring manager determine if the candidates have these competencies. Competency or Behavioral-based Interviewing The single best predictor of future behavior is a person’s recent past behavior. The evaluation of a candidate should be based on the specific examples of technical and personal/interpersonal competencies provided by the candidate during the course of the interview. Success for most jobs requires a combination of technical and personal/interpersonal competencies. FIVE STEPS FOR SUCCESSFUL BEHAVIORAL INTERVIEWING There are five steps for the hiring manager to follow to be most successful in behavior-based interviewing. They are listed here and described in more detail in the following pages: 1. Analyze the technical aspects of the job. 2. Determine the personal/interpersonal competencies of the job. 3. Develop interview questions to assess both aspects. 4. Conduct the interview. 5. Value the importance of the reference checks. Step 1 Analyze the Technical Aspects of the Job Technical competencies are the knowledge and skills that are necessary for satisfactory performance of a given job. Studying the position description, observing the job being performed, and interviewing the previous and current holders of the job and the immediate supervisor will be helpful in determining the competencies required and the performance standard. Asking a series of questions will help you in establishing the technical competencies. Ask questions such as: What would the ―perfect‖ candidate‘s competencies and skills look like; What will a person in this job have to do on a regular basis to succeed; What are the necessary competencies and skills the person will need in order to achieve the desired results of the position; How will a person hired for this job know he or she is succeeding, and Why have people left this job in the past? After you have analyzed the job and developed several technical competencies, list the top five most important technical competencies the candidate MUST have to succeed in the job. Remember when developing your interview questions to keep the questions open-ended, simple, direct and specific. Base all the questions on the job description and the top five technical competencies. Avoid questions that require overly specific knowledge. Below is a sample Technical Competency Assessment Guide for use in determining the technical competencies and developing relevant interview questions. TECHNICAL COMPENTENCIES ASSESSMENT GUIDE
Page 86
Support Center – Managing and Analyzing Job Title: _______________________________________ A. Analyze Technical Aspects of Job. (Answer questions and list competencies in the space.) What would the ―perfect‖ candidate‘s competencies and skills look like? What will a person in this job have to do on a regular basis to succeed? What are the necessary competencies and skills the person will need in order to achieve the desired results of the position? How will a person hired for this job know he or she is succeeding? Why have people left this job in the past? B. List the top five most important technical competencies the candidate MUST have to succeed in the job. 1. 2. 3. 4. 5. C. Develop a Technical Question for Each of the Five Required Technical Competencies. Base all your questions on the job description and the technical competencies you listed above. Keep the questions open-ended, simple, direct and specific. Avoid questions that require a specific knowledge of your division. Ask for assistance developing technical questions if you are not the technical expert. Step 2 Determine the Customer Service Focused Competencies of the Job A large percentage of employees who did not succeed in a position had the technical skills but did not have the customer service focused skills required for the job. Identifying the customer service focused competencies needed to successfully perform the job and determining if the candidate possesses those competencies is critical. For example, an individual working in a receptionist position will need to be flexible and unflappable in order to handle the pressure of multiple phone calls and simultaneous visitors. They also need some degree of friendliness for welcoming the public and some degree of extroversion, since most people calling an organization would like to be met by someone with enthusiasm. Assessing customer service focused competencies during the interview process is something we may not be typically used to doing as managers. We are experienced in determining if the candidate has the technical skills and abilities to perform the job. But in order to get the BEST candidate for the position, customer service focused competencies need to be determined and assessed also. To determine what customer service focused competencies are needed for the position, questions similar to those asked to determine the technical competencies should be answered: What would the ―perfect‖ candidate‘s customer service focused competencies look like; What will a person in this job have to do on a regular basis to succeed; What are the necessary customer service focused competencies the person will need in order to achieve the desired results of the position; How will a person hired for this job know he or she is meeting the customer service focused expectations; and Related to customer service reasons, why have people left this job in the past? As you think about the job vacancy you need to fill, focus on the customer service focused competencies or behaviors that an individual needs to exhibit in order to succeed in this job.
Page 87
Support Center – Managing and Analyzing Depending on the specific job under consideration, customer service focused characteristics, such as paying attention to detail, being self-motivated, getting along with others, having leadership qualities, and being tolerant of stressful events, are examples of the skills critical to success on the job. Below you will find five descriptive elements of personality to assist you in determining customer service focused competencies. Descriptive words have been added to give you ideas and help you determine what behaviors are required for the position. Towards the end of this document, you will find a list of questions to correspond to each personality factor. These questions can be used to develop the examination portion of the recruiting announcement or they can be used in the interview process. The five descriptive elements of personality are Responsible, Likeable, Believable, Outgoing and Unflappable. Definitions: Responsible. The ability to organize or schedule people, tasks, and self; to develop realistic action plans while remaining sensitive to time constraints and resource availability; and having a well developed sense of ethics and integrity. Characterized by high levels of responsibility and behaviors these employees are controlled, disciplined, precise, persistent, and businesslike. Their behavior is consistent, scrupulous, and reliable, and their work is purposeful, highly systematic, and well organized. They approach life as a series of tasks to be accomplished and goals to be reached. Descriptors: detail-oriented; quality-focused; high-integrity; responsible; trustworthy; dependable; cost-conscious; exact; disciplined; committed; cautious; casual; easygoing. Likeable. Describes a person‘s ability to modify their behavioral style to respond to the needs of others while maintaining one‘s own objectives and sense of dignity. In the moderate to high range of likeability, we find sympathetic, helpful, and understanding individuals. They are agreeable, compassionate, thoughtful, and kind. They appear to accept things as they are, nurture others, and are obviously friendly and caring people. Descriptors: amicable; accommodating; supportive; helpful; compromising; collaborative; friendly; empathetic; empowering; congenial; easygoing. Believable. Capable of eliciting belief or trust. In the middle to low range of believable thinking, we find people who are open, willing to reexamine tenets and consider new ideas. They are capable of reasonable levels of professional and personal risk taking and are willing to work outside their ―comfort zone.‖ Highly believable people can be described as practical, predictable and conventional, willing to follow procedures without question. They often form the emotional ―back bone‖ of an organization. Descriptors: creative; original; flexible; spontaneous; open-to-new-ideas; independent; curious; untraditional; venturesome; uninhibited; conventional; down-to-earth; concrete; traditional; practical; methodical; systematic. Outgoing. Describes the ability to work with people in such a manner as to build high morale and group commitments to goals and objectives. Individuals in the moderately high range of extroversion are upbeat, positive, and energetic. They tend to be enterprising, cheerful, and appropriately assertive. They demonstrate leadership, team-building capability, and are able to coach or facilitate a work team‘s progress. Individuals who are moderately introverted are often viewed as self-contained, generally well balanced, and able to work well either alone or in small groups. Descriptors: active; outgoing; dominant; forceful; enthusiastic; assertive; persuasive; energizing; entrepreneurial; ambitious; risk-taking; self-contained; task-oriented; quiet; restrained; formal; unassuming; reserved; thoughtful. Unflappable. The ability to maintain a mature, problem-solving attitude while dealing with a range of stressful conditions, such as interpersonal conflict, hazardous conditions, personal rejection, hostility, or time demands. At moderately high levels of stress tolerance we find relaxed, secure, and hardy individuals who are poised and adaptive in a wide range of situations. They are steady, realistic, self-reliant, and able to cope effectively across a wide range of situations and circumstances. They demonstrate maturity that is not necessarily
Page 88
Support Center – Managing and Analyzing related to age, but to the ability to maintain a clear perspective under stressful conditions as well as those that elicit little or no stress. Descriptors: calm; well adjusted; secure; even-tempered; self-assured; unflappable; resilient; poised; composed; self-confident; optimistic. CUSTOMER SERVICE FOCUSED BEHAVIORS ASSESSMENT GUIDE Job Title: _________________________________________ A. List the most typical Customer Service Focused behaviors required on this job on a daily basis. Use the previously identified personality factors to help you. Responsible – detail-oriented; quality-focused; high-integrity; responsible; trustworthy; dependable; cost conscious; exact; disciplined; committed; cautious; casual; easygoing. Likeable – amicable; accommodating; supportive; helpful; compromising; collaborative; friendly; empathetic; empowering; congenial; easygoing. Believable – creative; original; flexible; spontaneous; open-to-new-ideas; independent; curious; untraditional; venturesome; uninhibited; conventional; down-to-earth; concrete; traditional; practical; methodical; systematic. Outgoing – active; outgoing; dominant; forceful; enthusiastic; assertive; persuasive; energizing; entrepreneurial; ambitious; risk-taking; self-contained; task-oriented; quiet; restrained; formal; unassuming; reserved; thoughtful. Unflappable – calm; well-adjusted; secure; even-tempered; self-assured; unflappable; resilient; poised; composed; self-confident; optimistic. B. List of Customer Service Focused Behaviors 1. 2. 3. 4. 5. C. Develop a Question for Each of the Customer Service Focused Behaviors 1. 2. 3. 4. 5. Step 3 Develop Interview Questions to Assess Both Technical and Customer Service Focused Competencies Decide how long the interviews will be and select a reasonable number of questions to ask. In a half-hour interview, only about 5 behavioral-based questions can comfortably be asked. If five questions are asked, at least two of them should be customer service-type questions, depending upon the type of job. Always ask open-ended questions. Ask, ―This job involves dealing with difficult customers. Think of a time when you had to deal with a difficult customer and tell us what you did.” Don‘t ask, ―Have you ever dealt with difficult customers?” You probably will get an answer like, ―Yes, I work with difficult customers all the time.‖ But it won‘t tell you HOW the individual works with difficult customers. If you feel the candidate is making up an answer, or is giving you a ―canned‖ answer, ask a probing question or two to get more detail. ―What exactly did you say to the customer to get them to stop yelling.” Generally, if they have read a book on ―most commonly asked interview questions‖ and memorized an answer, or are making up the situation, a probing question will generally fluster them and they will not be as confident in giving an answer. You can ask for the candidate to think of another example to use in answering the question. Using the list of most important tasks you developed during the review of the Position Description, develop open-ended questions to determine if the candidate has the technical
Page 89
Support Center – Managing and Analyzing skills necessary for the job. Only ask technical questions that relate to that particular job. Don‘t ask a question about using equipment if they don‘t use that equipment to do their job. Using the list of customer service focused skills you identified from the position description are needed to do the job, develop open-ended questions to determine the candidate‘s customer service focused competencies. There is a list of sample interview questions at the end of this document to help you. They are arranged by the five personality factors identified above. Step 4 Conducting the Interview Have an interview panel of at least two managers/supervisors; some managers may also wish to include a non-management employee with special knowledge of the position duties as part of a panel. If you choose to include a non-management employee on your interview panel, be sure to discuss interviewing procedures and confidentiality of candidate information with the employee prior to the interviews. It is encouraged that all interview panels be as diverse as possible. Before the interview starts, establish the criteria used for scoring and then meet with the interview panel to discuss the process and review the questions and criteria used for scoring. Welcome the candidate and establish rapport by introducing them to the members of the interview panel. Ask easy questions such as ―Did you have any difficulty finding the office?‖ or ―Would you like a glass of water before we begin?‖ Give a brief explanation of the organization or section and show the organization chart so they understand how this position fits within the organization. If you have handed the position description and organization chart out while they waited for the interview to start, ask if they have any questions about the position or organization. Explaining the interview process can also help ease a candidate‘s nervousness and also gives them information about the process, including, approximate length of the interview, the interview will be a series of prepared questions asked by the interview panel designed to get to know the candidate, and the panel will be taking notes during the interview. Transition into the main purpose of the interview by saying, ―Let‘s get a bit more focused and start asking the interview questions.‖ Even though the interview process is accomplished through a panel, one person should act as ―facilitator‖ and make sure the interview stays focused. Some candidates tend to wander, give ―canned‖ speeches, or simply try to deliver a monologue. In such cases, you need to diplomatically interrupt and redirect the candidate to the question at hand. You might simply say, ―I think we‘ve gotten a little off target here. Let me restate my question.‖ To clarify a response or to get a candidate to give specific examples you can ask, ―Please give me a specific example about when you…‖ Because behavior-based questions require specific examples to answer them successfully, sometimes a candidate will need to think for a few seconds to come up with an appropriate example. You may have to wait 30, 60, or even 90 seconds for the candidate to start answering the question. Resist the temptation to talk during this silence! It takes time to recall specific behavioral examples that clearly answer your questions and you want the candidate to do their best during the interview. An option available to the hiring manager is to hand out the list of questions to the candidates a few minutes before the interview starts, so the candidate can start thinking of specific examples ahead of time and organizing their thoughts. If an answer does not give you the information you need to rate the candidate‘s answer, use open-ended probes such as: ―Could you review your role in…‖ ―Please describe how you…‖ ―What happened after…‖ If after the first or second try to get an answer more relevant to the question move on to the next question.
Page 90
Support Center – Managing and Analyzing After each interview take a few minutes for the panel members to summarize their thoughts and score the questions, or complete the rating process. Affirmative Action Organizations value diversity in the workplace. Every effort will be made to reach out to the broadest possible labor market. All employment decisions will be based on the most suitable candidate relative to a position, while taking into consideration Affirmative Action goals. Step 5 Background and Reference Checks The final stage of the hiring process is the background and reference checks. The Human Resources Background Investigator will verify information provided by the applicant by contacting former and current supervisors, persons listed by the candidate as references, and others who are thought to be able to provide information about the competencies of a candidate. The Background Investigator listens for subtle innuendoes and long pauses after posing questions, and will evaluate whether the individual giving the reference sounds like he/she is struggling to carefully select each word. In these instances, more specific probing questions will be asked. Occasionally, a finalist will indicate they do not wish you to contact their current employer. In these cases, you need to explain that the organization needs to contact this employer to assist with the hiring decision and that we don‘t hire anyone without completing a background and reference check with the current employer. Making a Job Offer When you have identified the candidate to whom you would like to make a job offer based on the information gathered through the application, examination, interview, evaluation of background and references, and you have the approval of your supervisor, and the Director or Deputy Director, you may contact that candidate and offer him/her the position. Before you contact the candidate, please work closely with Human Resources staff to verify certain information. For example, Classification Salary Range Rate of pay and timing of first pay increase Vacation accrual rate and ability to transfer vacation accruals from another State organization Trial Service period Eligibility for Personal benefits Confirming Job Offer Letter Human Resources staff will send a confirming job offer letter. The letter will outline the terms of the job offer and will provide a space for the candidate to sign his or her name confirming that he/she accepts the terms of employment. This signed copy must be returned to Human Resources to document the understanding and the acceptance of the terms. It is important that all information in this letter of confirming letter of hire be correctly stated because it is an implied employment contract. Informing Unsuccessful Candidates After the selected candidate formally accepts your job offer, each of the remaining candidates should be contacted to notify them that the hiring decision has been made. Human Resources can help you with this step. If a candidate contacts you directly to ask why he or she was not hired, the best thing to do is to simply tell them that we hired the most suitable candidate for the position. If they continue to ask for information, contact your Human Resources staff for guidance in how to answer the candidate‘s questions. Retention of Interview Materials Please collect all interview and selection materials and notes and return them promptly to Human Resources.
Page 91
Support Center – Managing and Analyzing
SAMPLE CUSTOMER SERVICE FOCUSED INTERVIEW QUESTIONS (Grouped by customer service based behaviors) Responsible 1 Tell us about a time when the details of something you were doing were especially important. How did you attend to them? 2 Describe a time when you had to make a difficult decision on the job. What facts did you consider? How long did it take you to make a decision? 3 Jobs differ in the extent to which people work independently or as part of a team. Tell us about a time when you worked independently. 4 It is often easy to blur the distinction between confidential information and public knowledge. Have you ever been faced with this dilemma? What did you do? 5 Tell us about a time when you put in some extra effort to help move a particular project forward. How did you do it and what happened? 6 Tell us about a demanding situation in which you managed to remain calm and composed. What did you do and what was the outcome? 7 There are times when we have a great deal of paperwork to complete in a short time. How do you do to ensure your accuracy? 8 Give an example of a time you noticed a process or task that was not being done correctly. How did you discover or come to notice it, and what did you do? 9 We often have to push ourselves harder to reach a target. Give us a specific example of when you had to give yourself that extra push. 10 Tell us about a time when you achieved success through your willingness to react quickly. 11 Tell us about a time when you disagreed with a procedure or policy instituted by management. What was your reaction and how did you implement the procedure or policy? 12 What kinds of measures have you taken to make sure all of the small details of a project or assignment were done? Please give a specific example. 13 How do you determine what constitutes a top priority in scheduling your work? Give a specific example. 14 If I call your references, what will they say about you? 15 What are two or three examples of tasks that you do not particularly enjoy doing? Tell us how you remain motivated to complete those tasks. 16 What has been your greatest success, personally or professionally? 17 What can you tell us about yourself that you feel is unique and makes you the best candidate for this position? 18 What strengths do you have that we haven‘t talked about? 19 Tell us about a time when you had to review detailed reports or documents to identify a problem. How did you go about it? What did you do when you discovered a problem? 20 How do you determine what constitutes a top priority in scheduling your time (the time of others)? 21 Do you have a system for organizing your own work area? Tell us how that system helped you on the job. 22 Have you planned any conferences, workshops or retreats? What steps did you take to plan the event? Likeable 1 Tell us about a time when you were able to build a successful relationship with a difficult person. 2 Give us an example of how you have been able to develop a close, positive relationship with one of your customers. 3 Give us an example of how you establish an atmosphere at work where others feel comfortable in communicating their ideas, feelings and concerns.
Page 92
Support Center – Managing and Analyzing 4
Describe a particularly trying customer complaint or resistance you had to handle. How did you react and what was the outcome? 5 How would you describe your management style? How do you think your subordinates perceive you? 6 Some people are difficult to work with. Tell us about a time when you encountered such a person. How did you handle it? 7 In working with people, we find that what works with one person does not work with another. Therefore, we have to be flexible in our style of relating to others. Give us a specific example of when you had to vary your work style with a particular individual. How did it work out? 8 It is important to remain composed at work and to maintain a positive outlook. Give us a specific example of when you were able to do this. 9 Having an understanding of the other person‘s perspective is crucial in dealing with customers. Give us an example of a time when you achieved success through attaining insight into the other person‘s perspective. 10 Have you ever had difficulty getting along with a co-worker? How did you handle the situation and what was the outcome? 11 Tell us about a time when you needed someone‘s cooperation to complete a task and the person was uncooperative. What did you do? What was the outcome? 12 There are times when people need extra assistance with difficult projects. Give us an example of when you offered assistance to someone with whom you worked. 13 Tell us about a situation in which you became frustrated or impatient when dealing with a coworker. What did you do? What was the outcome? 14 Many jobs are team-oriented where a work group is the key to success. Give us an example of a time when you worked on a team to complete a project. How did it work? What was the outcome? 15 Tell us about a job where the atmosphere was the easiest for you to get along and function well. Describe the qualities of that work environment. 16 On occasion we may be faced with a situation that has escalated to become a confrontation. If you have had such an experience, tell me how you handled it. What was the outcome? Would you do anything differently today? 17 Describe a time when you weren‘t sure what a customer wanted. How did you handle the situation? 18 We don‘t always make decisions that everyone agrees with. Give us an example of an unpopular decision you have made. How did you communicate the decision and what was the outcome? Believable 1 Describe your ideal supervisor. 2 What were some of the most important things you accomplished on your last job? 3 What is your management style? How do you think your subordinates perceive you? 4 Give us an example of when someone brought you a new idea, particularly one that was odd or unusual. What did you do? 5 It is important that performance and other personnel issues be addressed timely. Give examples of the type of personnel issues you‘ve confronted and how you addressed them. Including examples of the process you used for any disciplinary action taken or grievance resolved. 6 Give us an example of how you establish an atmosphere at work where others feel comfortable in communicating their ideas, feelings and concerns. 7 Give a specific example of how you have involved subordinates in identifying performance goals and expectations. 8 All jobs have their frustrations and problems. Describe some specific tasks or conditions that have been frustrating to you. Why were they frustrating and what did you do?
Page 93
Support Center – Managing and Analyzing 9
Jobs differ in the degree to which unexpected changes can disrupt daily responsibilities. Tell what you did and us about a time when this happened. 10 What are your standards of success in your job and how do you know when you are successful? 11 Sometimes supervisors‘ evaluations differ from our own. What did you do about it? 12 What do you do differently from other (__________)? Why? Give examples. 13 We don‘t always make decisions that everyone agrees with. Give us an example of an unpopular decision you made. How did you communicate the decision and what was the outcome? 14 Describe a situation in which you received a new procedure or instructions with which you disagreed. What did you do? 15 Describe a situation in which you had to translate a broad or general directive from superiors into individual performance expectations. How did you do this and what were the results? 16 Give an example of how you monitor the progress your employees are making on projects or tasks you delegated. Outgoing 1 Describe a time when you were able to effectively communicate a difficult or unpleasant idea to a superior. 2 Tell us about a time when you had to motivate a group of people to get an important job done. What did you do, what was the outcome? 3 Tell us about a time when you delayed responding to a situation until you had time to review the facts, even though there was pressure to act quickly. 4 There are times when we need to insist on doing something a certain way. Give us the details surrounding a situation when you had to insist on doing something ―your way‖. What was the outcome? 5 On occasion, we have to be firm and assertive in order to achieve a desired result. Tell us about a time when you had to do that. 6 Being successful is hard work. Tell us about a specific achievement when you had to work especially hard to attain the success you desired. 7 In job situations you may be pulled in many different directions at once. Tell us about a time when you had to respond to this type of situation. How did you manage yourself? 8 Many of us have had co-workers or managers who tested our patience. Tell us about a time when you restrained yourself to avoid conflict with a co-worker or supervisor. (restrained) 9 In working with people, we find that what works with one person does not work with another. Therefore, we have to be flexible in our style of relating to others. Give us a specific example of when you had to vary your work style with a particular individual. How did it work out? 10 Describe some particularly trying customer complaints or resistance you have had to handle. How did you react? What was the outcome? 11 Have you ever had difficulty getting along with co-workers? How did you handle the situation and what was the outcome? 12 Tell us about a time when you needed someone‘s cooperation to complete a task and the person was uncooperative. What did you do? What was the outcome? 13 Tell us about a situation in which you became frustrated or impatient when dealing with a coworker. What did you do? What was the outcome? 14 Sooner or later we all have to deal with a customer who has unreasonable demands. Think of a time when you had to handle unreasonable requests. What did you do and what was the outcome? 15 Tell us about a time when you were effective in handling a customer complaint. Why were you effective? What was the outcome? 16 How do you know if your customers are satisfied?
Page 94
Support Center – Managing and Analyzing Unflappable 1 There are times when we all have to deal with deadlines and it can be stressful. Tell us about a time when you felt pressured at work and how you coped with it. 2 Give us an example of a demanding situation when you were able to maintain your composure while others got upset. 3 On occasion, we experience conflict with our superiors. Describe such a situation and tell us how you handled the conflict. What was the outcome? 4 We have to find ways to tolerate and work with difficult people. Tell us about a time when you have done this. 5 Many times, a job requires you to quickly shift your attention from one task to the next. Tell us about a time at work when you had to change focus onto another task. What was the outcome? 6 Tell us about a time when you received accurate, negative feedback by a co-worker, boss, or customer. How did you handle the evaluation? How did it affect your work? 7 Give us an example of when you felt overly sensitive to feedback or criticism. How did you handle your feelings? 8 Give us an example of when you made a presentation to an uninterested or hostile audience. How did it turn out? 9 Tell us about a time when you put in some extra effort to help move a project forward. How did you do that? What happened? 10 Describe suggestions you have made to improve work procedures. How did it turn out?
INTERVIEWING A Practical Guide for Selecting THE INTERVIEW PROCESS 1. PLANNING Time spent planning will ensure the interview process proceeds smoothly and that you obtain the information needed to assess the candidates. You should: Review the position description and qualification requirements (refer to the vacancy announcement). Thoroughly review all candidate applications. Ask yourself: – What are the strengths/weaknesses of this candidate? What is the candidate‘s relevant skills/experience? – Does the education fit the job requirements? Is there evidence of the ability to communicate with individuals and groups from diverse backgrounds in a variety of situations? Is there evidence of the ability to lead and accomplish work through others? Decide who you will interview. Although you are not required to interview all candidates, think about the perception of other candidates if you interview only one person. Formulate questions and write them down. This will help ensure you ask all candidates the same questions. Allow 1-2 hours for the interview. 2. CONFIRMING/SCHEDULING INTERVIEW Selecting officials are encouraged to confirm scheduled interviews with applicants in writing. 3. CONDUCTING THE INTERVIEW After welcoming the candidate, spend a few minutes chatting informally. It will help you both relax. Give a brief overview of the job and mission of the organization. Ask questions and listen. Probe for additional information. Ask the candidate to elaborate on or clarify what
Page 95
Support Center – Managing and Analyzing was just said. (Although it is important that you write down a list of questions before you begin the interviews, you are not prohibited from asking additional questions.) Indirect probing is also an effective way to elicit more information. If you are silent for a few seconds after the candidate responds, that may allow them time to think of additional things to say; or you may use neutral phrases, such as: I see, or, oh? That may prompt the candidate to elaborate further. The point is that in this phase of the interview, it is the candidate who should be doing most of the talking. Take notes, but don‘t try to capture every word. It‘s distracting to you and the candidate. Allow the candidate time to ask questions. This is where you can elaborate on the Organization, your lab, and/or the specific job. Inform the candidate about maxi flex, leave, benefits, holidays, etc. Some suggested interview questions can be found in Section III, TIPS ON INTERVIEWING. 4. CLOSING If the candidate won‘t be considered further, close the interview diplomatically. If you are interested in the candidate, you may: Ask if the candidate is still interested in the position. Inform the candidate of the next step. Be prepared to advise on the timeframe for selection and how the selectee will be notified. Inform the candidate that references will be checked. Thank the candidate for coming for the interview, applying for the position, and/or having an interest in the Organization and position. Write up your notes. 5. FOLLOW-UP A good customer service practice is to write all candidates acknowledging the interview and thanking the person for showing an interest in the organization. You may wish to do so after a selection has been made.
TIPS ON INTERVIEWING 1. QUESTIONS/ASSESSMENT TOOLS Careful thought should be given to constructing the interview. Together with the KSAs (knowledge, skills, and abilities) and SPFs (selective placement factors) you used in the vacancy announcement, the kind of questions you ask will determine the type of person you select for your position. There are various assessment tools available to evaluate candidates including: A. The Behavioral Event Inventory (BEI). The candidate describes, in detail, a past experience that demonstrates the KSA or competency to a panel. The panel is facilitated by a person trained in the method. The phases of the process include planning, orientation, and interviewing, debriefing, and follow-up documentation. B. The Traditional Interview. Questions are developed prior to the interview. The same basic questions are asked of each candidate. Additionally the interviewer can, Encourage the candidate to give an example of a real situation, activity, or problem that includes: a description of the context, or environment; evidence or characteristics of the audience; the action taken; and the outcome. Ask open-ended questions. Asking yes and no questions will severely limit the kind of information you obtain from the interview. The only yes or no question you should ask is, ―Are you still interested in this position?‖ 2. INTERVIEW QUESTIONS TO GET YOU STARTED What interests you most about our position? What role do you take in a group situation? Give an example.
Page 96
Support Center – Managing and Analyzing
Why do you want to work for our organization? What are your short-term and long-term goals? What are the two biggest accomplishments in your life? What has been your greatest technical achievement in your current position? Your career? Describe your participation in professional associations. What planning processes have you found useful? In what way do you feel you have improved in your planning abilities/methods? How does your past experience impact your qualifications for this position? 3. SUPERVISOR & MANAGER COMPETENCIES When preparing for supervisory or managerial interviews (whether using traditional or BEI), all candidates must be evaluated using the following two competencies: A. Leading People. This competency includes conflict management, cultural awareness, team building, mentoring, and integrity/honesty (either work related or outside experience). Ask each candidate to describe a situation, problem, or event that demonstrates: Ability to work with a diverse group. Ability to prevent or mediate a conflict or disagreement or overcome dissension in a group. Ability to instill trust and confidence in others. Use of skills and abilities as a leader under stressful conditions. B. Building Coalitions/Communications. This competency includes oral and/or written communication, influencing/negotiating, partnering, interpersonal skills, and political savvy. Ask each candidate to describe a situation, problem or event that demonstrates: Ability to express ideas or give instructions not easily or readily understood by their audience. Ability to make presentations to groups in order to gain acceptance of an idea by the group. Negotiating skills to gain approval for change or modification to programs, procedures, etc. 4. INTERVIEWING PEOPLE WITH DISABILITIES Concentrate on the applicant‘s technical and professional knowledge, skills, abilities, experiences and interests, not on the disability. Remember, you cannot interview a disability, hire a disability or supervise a disability. You can interview a person, hire a person, and supervise a person. The American with Disabilities Act (ADA) separates the hiring process into three stages: preoffer, post-offer and employment. At each stage, the rules differ regarding the permissibility of disability-related questions and medical examinations. Definition of a ―Disability-Related Question‖ means a question that is likely to elicit information about the disability. Definition of ―Medical Examination‖ is a procedure or test that seeks information about an individual‘s physical or mental impairments or health. Therefore, the two most important questions for employers to address are: Is the question disability-related or is the examination medical? And Where are we (i.e., at which stage - pre-offer, post-offer, or employment) in the employment process? At the first stage (the pre-offer stage), the ADA prohibits all disability-related questions and medical examinations, even if the questions or examinations are related to the job. At the second stage (after the applicant is given a conditional job offer), the law allows all disability-related questions and medical examinations, as long as all entering employees in the job category are asked the questions or given the examinations. At the third stage (after the employee starts work), the law permits disability-related questions and medical examinations only if they are job-related and consistent with business necessity. The law requires that medical information collected at any stage must be kept
Page 97
Support Center – Managing and Analyzing confidential. For examples of some commonly asked questions on ―Pre-employment Disability Related Questions and Medical Examination Questions,‖ please refer to the Equal Employment Opportunity Commission website at www.eeoc.gov/docs/preemp.html. 5. ACCOMMODATING PERSONS WITH DISABILITIES FOR AN INTERVIEW Application and interviewing procedures should comply with the American with Disabilities Act (ADA). The ADA prohibits disability-related questions or medical exams before a real job offer is made. Agencies employment offices and interviewing location(s) are to be accessible to applicants with mobility, visual, hearing or cognitive disabilities. Be willing to make appropriate and reasonable accommodations to enable a job applicant with a disability to present him or herself in the best possible light. When setting up the interview explain what the hiring process involves and ask the individual if he or she will need reasonable accommodations for any part of the interview process. For example, if a person who is blind states he or she will need help filling out forms, provide the assistance; provide an interpreter for an applicant who is deaf, if he or she requests one; provide details or specific instructions to applicants with cognitive disabilities, if this type of accommodation is required. Do not let a rehabilitation counselor, social worker or other third party take an active part in or sit in on an interview unless the applicant requests it. Make sure that all questions asked during the interview are job-related. Speak to essential job functions regarding the position for which the applicant is applying, as well as why, how, where, when and by whom each task or operation is performed. Do not ask whether or not the individual needs an accommodation to perform these functions, because such information is likely to reveal whether or not the individual has a disability. This is an ADA requirement to ensure that an applicant with a disability in not excluded before a real job offer is made. 6. INTERVIEW DOs & DON’Ts DO... Be friendly to establish rapport, help the candidate feel at ease. Listen attentively. Keep the interview under control. If the interviewee becomes verbose or drifts off the subject, it‘s your job to get back on track. Use professional terminology to evaluate the candidate‘s knowledge. Consider potential as well as current ability. Note the kinds of questions the candidate asks. Do they concern opportunities for self-improvement and increased responsibilities, or only pay and fringe benefits? Be objective. Know yourself and your stereotypes. Understand that we tend to hire people who look like us. Be honest, even if it means saying something negative (e.g., the facility is old and there is not much office space). Just don‘t overemphasize it. Observe the candidate. Relax and enjoy the interview. DON’T... Talk too much. Use a rigid or overly standardized approach. If you‘ve prepared your questions, you can be flexible during the interview, knowing that you can easily get back on track. You‘ll become more flexible and react easily to different situations and personalities as you gain experience. Try to impress the interviewee with your knowledge. Hide demands of the job. A good candidate reacts favorably to these. Make commitments you may regret or are not authorized to make.
Page 98
Support Center – Managing and Analyzing
Be satisfied with surface facts. Look for reasons, and probe. Take detailed notes. It may keep you from observing nonverbal responses and maintaining the conversational flow. Ask questions in a way that indicates the answers you want. Ask convoluted or over-defined questions. Be aggressive or evasive. Raise candidates‘ hopes when they are not likely to be selected.
CHECKING REFERENCES You have completed the interviews, but you are not done yet. A resume and interview are great tools, but the reference check is really the only way you have to verify information given by the candidates. Normally, you will conduct a reference check on the one or two finalists. Reliability of the reference check is based on the concept that past performance is a good predictor of future performance. Reference checks will help: Verify information the candidate provided both in the application and during the interview. You gain insight into who your candidates are and how they behave in the workplace. Never make an offer (remember, you can only make a tentative offer) without first doing an exhaustive check of the candidate‘s background. A comprehensive reference check goes back 5 years and includes contacting a minimum of three sources that are knowledgeable about the candidate‘s abilities. Contact Enough references to confirm the quality of your selection. 1. WHICH REFERENCES SHOULD I CHECK? Academic references–institutions and teachers/professors. Current and former supervisors–immediate supervisors are often the best sources for reliable information about a candidate‘s work performance. Your network of professional associates/associations. Candidate‘s personal references–they will generally provide a favorable reference. Ask them for names and positions of other persons who know the candidate and contact them. Candidate‘s colleagues–business or work associates will sometimes provide an objective analysis of the candidate‘s strengths and weaknesses. Seek your own independent sources who know the candidate. 2. TIPS FOR CHECKING REFERENCES Ask only job-related questions and ask the same questions about each candidate. Ask open-ended questions and probe. Use telephone reference checks rather than mail inquiries since they are faster and less time consuming. Keep the conversation casual. If you speak to the person in a relaxed manner, you will get better results. If the reference provider keeps talking, keep listening and asking more questions. Seek out judgmental comments and try to read between the lines of what the person is telling you. A reference who says the candidate tried hard or is a people person may be saying such things to avoid talking about real problems or issues. Do not eliminate one candidate because of poor references and then neglect to check references from the remaining candidate(s). Always check dates and times the person giving the reference worked with or supervised the candidate, and then Determine if there is a personal relationship.
Page 99
Support Center – Managing and Analyzing
Give only a general description of the vacant position. Too many details may bias the reference person in formulating their answers. As in the case of the employment interview, let the other person do most of the talking. Do not use leading questions such as ―He‘s a good manager, isn‘t he?‖ Do not let a prominent characteristic, such as a good academic record; overshadow less obvious or possibly negative traits, such as a poor leave record. Speak to someone in addition to the current supervisor. A dishonest supervisor may try to unload a problem employee by giving a glowing reference. Listen carefully to the answers you are given and take notes. 3. THE REFERENCE CHECK: QUESTIONS TO ASK When contacting a reference, we recommend you begin with, ―Thank you for taking a few moments to provide information about our job candidate. The information you provide will be considered along with other information submitted by the applicant and other references. Please be aware that under the Federal government‘s employment policies, we may become obligated to disclose the information to the applicant or others involved in the selection or review process.‖ Then, ask and record the answers to the following: How long have you known the candidate? In what capacity were you associated with the candidate? As employer? Supervisor? Co-worker? Friend? Other? Using a scale of 1-5, with 1 being poor and 5 being excellent, how would you rate the candidate in comparison to most others you have known. RATINGS 12345 Work ethic? Work quality? Technical skills? Writing skills? Communication skills? Interpersonal skills? Reliability & dependability?
________ ________ ________ ________ ________ ________ ________
Receptivity to feedback?
________
Adaptability to change? Ability to deal with job stress?
________ ________
What would you consider to be some of this candidate‘s most positive attributes or strengths? What would you consider to be some areas where this person is not as strong or needs to improve? What type of work environment does the candidate require to excel? Describe the candidate‘s initiative, personality, and negative habits. How does the candidate get along with customers? Co-workers? Supervisors and managers? Is the candidate reliable? Honest? Trustworthy? Of good character? Would you rehire the candidate? Is there any other information concerning the candidate‘s qualifications,
Page 100
Support Center – Managing and Analyzing character, conduct and general fitness I should know about? PROHIBITED QUESTIONS & PRACTICES Please do not put yourself in a position of engaging in a prohibited personnel practice related to employment and selection. As a selecting official with the authority to take, direct others to take, recommend, or approve any personnel action, you must not: Discriminate for or against any employee or candidate for employment on the basis of race, color, national origin, gender, religion, age, disability, political beliefs, sexual orientation, and marital or family status. Deceive or willfully obstruct any person with respect to such person‘s right to compete for employment. Influence any person to withdraw from competition for any position for the purpose of improving or injuring the prospects of any other person for employment. Appoint or employ a relative to a position over which you exercise jurisdiction or control as a selecting official. Take or fail to take a personnel action with respect to a candidate for employment as a reprisal. Discriminate for or against a candidate for employment on the basis of conduct which does not adversely affect the performance of the candidate or the performance of others (except for criminal behavior).
RECORDING A PROFILE OF IMPRESSIONS Candidate‘s Name_______________________ 1. What are the candidate‘s strongest assets in relation to the requirements for this position? 2. What are the candidate‘s shortcomings in relation to this position? 3. The candidate seemed knowledgeable about/ interested in: 4. Contradictions or inconsistencies noted were: 5. The candidate was evasive about: 6. Overall, the candidate responded to questions with: (e.g., openness, confidence, poise, directness, glibness, evasiveness, etc.) Examples? 7. Overall, reference checks were positive, mediocre, less than positive. Examples/key descriptions or characteristics? SUPERVISORY & MANAGERIAL COMPETENCIES: Leading People is there evidence demonstrating: 1. Ability to gain commitment and support from others? 2. Ability to develop solutions to management problems? 3. Ability to establish performance objectives? 4. Ability to foster cooperative working environment among employees? 5. Ability to deal with morale and employee concerns? Building Coalitions/Communication is there evidence demonstrating: 1. Conflict resolution? 2. Working as a member of a team? 3. Expression of ideas and views that others understand and that influence (persuade) them to act?
RECRUITING It Takes More Than A Job Announcement! One of the critical steps in the recruitment process involves the actions you take to speed up the process and reach the largest, desirable pool of candidates.
Page 101
Support Center – Managing and Analyzing Simply posting the vacancy on job websites will not guarantee that you receive quality applications for the job. This chapter provides suggestions on steps YOU should take to ensure YOUR recruitment activity works for YOU. Considering these suggestions can help minimize the time required for recruitment on YOUR end and also help the Human Resources (HR) Specialist speed up the process.
BEFORE SUBMITTING the Vacancy REVIEW AND RETHINK THE POSITION DESCRIPTION o Ensure that the duties and responsibilities reflect the needs (or discipline) of the position at this time. o Determine if it accurately reflects the knowledge, skills, and abilities (KSAs) needed to perform the job. o Ensure that the KSAs can be directly related back to duties and responsibilities in the position description. o Develop your ―Quality Experience‖ definition. Identify experience a candidate will need to bring to the job on day one. CONSIDER ALTERNATIVE HIRING METHODS o Determine if the position can be filled using the Student Career Experience Program (SCEP), Federal Career Intern Program, Career Enhancement Program, and USDA Direct Hire Authority, special hiring authorities for individuals with disabilities or veterans, or other hiring methods. THINK ABOUT THE VACANCY ANNOUNCEMENT o Determine who the applicants are you are trying to reach. o Determine if you will need to recruit nationwide or if there will be sufficient candidates in the local commuting area to give you a diverse applicant pool from which to select. DEVELOP A STRATEGY TO REACH YOUR CANDIDATE POOL o Identify ways to market the job announcement to reach potential applicants. o Visit or contact the Career Center, Deans, and Professors if you are located on a campus to promote and highlight the many career opportunities available with ARS. o Identify colleagues (both within and outside the organization) who can help in marketing the job. o Identify colleges and universities or professional societies and organizations where the announcement should be mailed. o Identify newspapers, journals, or online advertising sites that might be useful in marketing the job. o Contact the Recruitment Office and your Area Civil Rights Manager for ideas on how to reach a diverse candidate pool. CONTACT YOUR SERVICING HR SPECIALIST o Discuss recruitment strategies and alternatives, as well as expectations for completion of the action. o Keep in touch with your HR Specialist by e-mail during the recruitment process. SUBMIT ALL REQUIRED PAPERWORK o Submit all position descriptions and forms needed to request the personnel action. o Submit draft ad text along with the request to save time (remember, your servicing HR Specialist must review and approve all ads prior to being placed). o Submit your ―Quality Experience‖ definition. WHILE THE VACANCY ANNOUNCEMENT IS OPEN CONDUCT YOUR MARKETING o Be PROACTIVE!
Page 102
Support Center – Managing and Analyzing o
Personally identify potential candidates and send a note with the announcement or call to encourage them to apply – be cautious, however, and don’t give the impression they will get the job. o Send the vacancy announcement to individuals, schools and colleges, or organizations you have identified, and place ads in newspapers, magazines, and online job boards. o E-mail the announcement to co-workers, colleagues, stakeholders, and peers with a brief note asking for assistance in publicizing the job. o Document your efforts. IDENTIFY A DIVERSE GROUP OF INTERVIEW PANEL MEMBERS AND SET UP PANEL DATES o Ask your HR Specialist for an approximate timeframe for receipt of the certificate of eligibles. o Ask interview panel members to block out time on their calendars for the interview process. o Clear your calendar also! o Keep your interview panel members informed throughout the recruitment process – if conflicts arise, replace panel members immediately. DEVELOP INTERVIEW QUESTIONS o Share interview questions with the panel members for comments and suggestions. CONTACT YOUR HR SPECIALIST THROUGHOUT THE PROCESS o Ask if you are receiving applications. o Determine if you need to extend the closing date. Ask your HR Specialist to scan applications received to get an idea of the quality of applicants before making a decision to extend the closing date. ONCE THE CERTIFICATE IS RECEIVED SCHEDULE THE INTERVIEWS IMMEDIATELY SO THE BEST CANDIDATES ARE STILL AVAILABLE! o Review the certificate right away and identify the candidates you believe should be interviewed. Ask for help from colleagues as needed. Set a timeframe to complete the interviews. o Schedule the interviews close together to minimize losing a desirable candidate and to maximize the likelihood of remembering individual candidates‘ strengths and weaknesses. o Have an open mind – interview ―Preference Eligible‖ (Veterans and Displaced) candidates before making judgments on their ability to do the job. Remember, if they are on the certificate, they meet the qualifications for the position. Talk to your HR Specialist if you have concerns. o Advise applicants of your timeframe for conducting the interviews – if they are interested, they will make themselves available. o Advise the candidates of the process you will use to conduct interviews (for example, interview panel – give them guidelines). CONDUCT REFERENCE CHECKS o Always conduct reference checks on top candidates! This is more critical than ever before. MAKE YOUR TENTATIVE SELECTION o Contact the candidate selected to advise that their name is being recommended to Human Resources. Ask if any issues with pay, incentives, EOD, etc. o Notify HR Specialist of your decision and discuss options for offering recruitment incentives. Remember, the HR Specialist must make the official offer of employment. o Obtain required area/organization approvals of the selection and incentives being proposed.
Page 103
Support Center – Managing and Analyzing o
Ask the HR Specialist to issue the written employment offer including information on negotiated pay, recruitment incentives and bonuses, and EOD date. AFTER THE SELECTION IS MADE NOTIFY OTHER CANDIDATES INTERVIEWED OF YOUR DECISION o HR will notify all non-selected candidates of the final outcome. o Contact the candidates interviewed and encourage them to apply for other positions. SHARE IMPRESSIVE APPLICATIONS o Share other impressive applications with colleagues who may be recruiting for similar jobs – they can contact and encourage quality applicants to apply for their positions. o Share a copy of other impressive applications with the Recruitment Office – this office can refer the applications to others recruiting for similar positions. PREPARE FOR THE NEW EMPLOYEE’S ARRIVAL o Make copies of appropriate policies, procedures, and other documents the new employee should read. o Have the employee‘s workspace cleaned up and the desk stocked with essential supplies. o Prepare the performance plan and provide it along with a copy of the position description on the first day of work. o Set time on your calendar to spend with the new employee on the first day – show them around the facility, discuss the job and work they will be doing, provide time to read through materials, and let the employee know they can ask questions. o Make sure the employee is set up with an e-mail address and computer access, etc. o Identify a mentor and develop an Individual Development Plan (IDP) to address with the employee. o Inform the employee of the probationary period requirements as well as the promotion potential, if any, of the position.
ASSESSING YOUR RECRUITMENT AND SELECTION PRACTICES Policies and Procedures Your organization‘s policies and procedures should thoroughly document the recruitment, assessment and selection processes. The policies and procedures should be accessible and understood by not only HR professionals but Managers and others involved in the hiring process. Ask yourself these questions to help assess whether or not your organization‘s policies and procedures are current and include new requirements. Are recruitment, assessment and selection processes supported by written policies and procedures that are up-to-date, accurate and complete? (Ideally within 2 years.) How widely communicated are the organization‘s written recruitment, assessment and selection policies to those who are involved in the process? (Ideally to all staff.) Does the organization utilize these policies and procedures for the recruitment, assessment and selection processes? Does the organization have a written policy describing procedures for the review of competencies and/or qualifications? Does the organization follow a formal recruitment, assessment and selection plan at the start of each recruitment? (Link to sample recruitment plan) Training Managers, supervisors, and personnel involved in the hiring process should receive comprehensive training in the organization‘s full recruitment process and thoroughly understand proper interview and selection techniques. Who performs recruitment activities for the organization? (Ideally HR with unit management participation.) On average, how long does it take to fill a position within the organization from the start of recruitment until an offer is extended? (Ideally 2 months or less.)
Page 104
Support Center – Managing and Analyzing
Does the organization provide training and/or written guidelines about recruitment, assessment and selection policies and procedures to managers and supervisors prior to them seeking to fill a position (e.g., reviewing applications, conducting interviews, and evaluating candidates)? Recruitment Strategies The organization should tailor their recruitment strategy to meet the need for the specific position and the organization‘s goals, as well as attract a diverse pool of applicants. Does the organization develop a specific recruiting and marketing plan to identify how and who they need to contact to help achieve finding the best candidates? Does the organization have a plan to recruit qualified applicants who represent the diversity of the State or local service area? Does the organization compare its workforce demographics to the State, county or local labor force demographics? Does the organization utilize specialized recruitment strategies to attract hard-to-find, qualified candidates? What recruitment strategies are utilized to attract hard-to-find qualified candidates? (Ideally executive search firms, internet job sites, local and regional newspapers, job fairs, professional organizations, civic organizations, networking, Employment Security Department, etc.) Does the organization track the effectiveness of different recruiting methods? Are recruitment sources periodically evaluated to assure they meet the needs of the organization and return on investment calculated? Recruitment Process and Hiring Recruitment procedures should be developed and administered in compliance with all applicable organization policies, bargaining agreements, laws, regulations, and professional standards. Is a job analysis conducted to identify the key responsibilities of a position prior to announcement? Are required qualifications reviewed prior to position announcements to assure they are job related? Are preferred qualifications reviewed prior to position announcements to assure they are job related? Does the organization‘s HR staff assure all applicants selected for employment meet the posted qualifications for the position? What percentage of job announcements identify the competencies needed to perform the job? Are essential functions of the position discussed with the candidate? Does the organization utilize a behavioral interviewing tool to develop standardized, relevant interview questions? Selection Process Selection procedures should be developed and administered in compliance with all applicable laws, regulations, and professional standards. What methods are used for the selection process? (Ideally selection matrix, interview notes, resume ranking, skills testing, reference checks, background checks, etc.) What percentage of the final selection decisions is documented? (This includes reasons for hire versus non-hire.) How long is the selection documentation retained? (Three (3) year record retention mandated for State of Washington.) Does the organization evaluate and assess how well the selection procedures worked? How frequently does the organization assess its selection procedures?
Page 105
Support Center – Managing and Analyzing
Does the organization maintain documentation of the assessment process?
Appendix Sample Customer Service Plan ACME Customer Service Plan
Background
Executive Order
Principles
Approach/Scope
Our Customers
Standards
Organization-wide Standards
Future Efforts
Further Information
Attachments
BACKGROUND ACME, founded in xxxx, is one of the world's foremost xxxx, and the Federal focal point for xxxx in the United States. xx Institutes and Centers comprise the ACME, which has the primary research goal of acquiring new knowledge to help prevent, detect, diagnose, and treat disease and disability from the rarest genetic disorder to the common cold. The ACME mission is to uncover new knowledge that will lead to better health for everyone. In 1993, President William J. Clinton issued Executive Order 12862 challenging Federal agencies to improve customer service. Further, Executive Order 12862 tasked agencies to survey their customers to identify what kinds of services they really want and to gather ideas from front-line employees on how to better deliver those services. The goal of this Customer Service Plan is to convey to you, the customer, a realistic, achievable approach for improving customer service at the National Institutes of Health. ACME is committed to improving the way it offers high quality services that are easily accessible to every American citizen. With this in mind, this Customer Service Plan is organized for your convenience. We want the plan to be as user-friendly as possible, and we welcome your comments and suggestions.
EXECUTIVE ORDER Page 106
Support Center – Managing and Analyzing Executive Order 12862, "Setting Customer Service Standards" requires Federal agencies to: a. Identify customers who are, or should be, served by the organization; b. Survey customers to determine the kind and quality of services they want and their level of satisfaction with existing services; c. Post service standards and measure results against them; d. Benchmark customer service performance against the best in business; e. Survey front-line employees on barriers to, and ideas for, matching the best in business; f. Provide customers with choices in both the sources of service and the means of delivery; g. Make information, services, and feedback systems easily accessible; h. Provide means to address customer feedback; and, i.
Provide feedback to our customers on what improvements we have made.
PRINCIPLES This Customer Service Plan is based on ideas, suggestions, and feedback received from our customers as well as an extensive best practices search. It defines our customer service standards and processes for building and maintaining high quality services to meet those standards throughout the country. The following principles drove the process for developing the plan: 1. Customers Know What They Want - Rather than sitting back and assuming that we know what customers wanted and needed, our organization is going out and asking. Through formal surveys, focus groups, and conversations, we are listening to what our customers think about the types and quality of services and products we offer. What we learn is helping to shape the ways in which we strive to redirect our services to ensure that we continuously improve our ability to meet your needs. 2. Customer's Needs Are Paramount - Based on feedback from our customers, ACME must respond to comments and suggestions about improving the way we deliver products and services. 3. Communication Is Key to Our Success - Developing effective tools to maintain lines of communication with our customers will help us do our jobs better. By Page 107
Support Center – Managing and Analyzing developing more effective ways to direct information to our customers and by providing clearer paths to receive feedback, our organization will better address customer needs and concerns.
APPROACH/SCOPE ACME is diligently working to address the spirit of Executive Order 12862. A dedicated group of representatives from across the organization is convening to form an on-going Customer Service Management group to implement the customer service program and to ensure that the organization enhances its customer focus as it improves current services and develops new initiatives. The organization has gathered information from customer service surveys, focus groups with front-line staff, and conversations with key external partners, to ensure that initiatives address issues important to our customers. This plan presents an opportunity to share with our customers our commitment to providing quality service. ACME is committed to protecting, promoting, and enhancing the health of the American people and to improving its processes to offer high quality services that are easily accessible to the public. The Customer Service Plan establishes a broad framework to address customer issues. The customer service standards address issues our customers have told us are important to them. The primary focus of this document is to ensure that we are continuously listening to our customers and making certain that their needs are being met or exceeded. While the focus is on our outside customers, it does not diminish the need to ensure that our internal ACME customer needs are also being met. It is imperative that an integrated view of all our customers' needs be pursued in order to ensure that the needs of our entire customer population are met. If we do not provide outstanding service to our internal customers, we will be unable to provide outstanding support to our external customers.
OUR CUSTOMERS The ACME serves four primary external customer groups--the general public, health professionals, other governmental agencies, and grantee/contractor organizations. These four broad categories encompass the populations that we serve and work with most often. When the organization embarked on this process, we felt it was necessary to define and limit our primary groups. As we continue with our customer service initiatives, we may include additional customer groups.
STANDARDS The standards described in this report represent the ACME effort to identify the needs and concerns of our customers and to establish measurable processes to address these needs and concerns. The standards have been developed from Page 108
Support Center – Managing and Analyzing information gathered from surveys/focus groups, and benchmarking with other outstanding organizations and are based on measured performance attributes - a set of criteria that expresses customer requirements and expectations. Performance attributes are organized into two categories. 1. Process attributes -- transaction-related characteristics represented by internal operations, such as procedures, policies, and functions - the primary focus is continuously improving our internal operations so we can deliver our products and services quicker, better and cheaper; and 2. Quality attributes -- image-related characteristics that describe the contact between the customer and the organization. The overall standard of quality we seek is customer service for the American people that is equal to or better than the best in business. The following attributes were used to develop the standards: Process Attributes
a. Consistency in policies and procedures - holding to the same principles across the organization b. Convenient feedback mechanisms - feedback that are easy to use and access c. Frequent communication - including follow-up - any form of communication on a regular basis, where taking action following that communication enhances the effectiveness of that communication d. Managing resources well - careful control and use of resources, human as well as fiscal, to maximize their impact and effectiveness e. Problem solving and attempts to remove barriers - proposed solutions or considerations to resolve something that is an obstruction or prevents progress f. Prompt handling of customer feedback - immediate or quick management of customer dissatisfaction by empowering employees to fix problems g. Flexible options - sending and receiving information using a variety of methods, including greater use of e-commerce solutions h. Continuous Improvement - striving to do everything quicker, better and cheaper Quality Attributes
Page 109
Support Center – Managing and Analyzing a. Accessible - ability or freedom to approach, communicate with, or make use of b. Courteous - respect or consideration c. Flexible - capability to adapt to or change requirements d. Knowledgeable - familiarity with or understanding of facts and/or conditions e. Listens well - gives attention and/or careful consideration to what is said f. Reliable and Trustworthy - dependable, confidence in character, abilities, and truth g. Timely - information and/or responses are provided early or on time
ORGANIZATION-WIDE STANDARDS The following standards apply to all customer groups. All ACME Customers are entitled to:
fair, courteous and professional treatment
information that is accurate and current
timely responses to requests
reasonable access to appropriate staff
two-way communication
opportunities for collaboration and partnerships, as appropriate and
consideration of their opinions and concerns by the organization in the decision making process
use of plain language for all communication with the public
In addition:
The General Public is entitled to accurate and timely information about research being conducted.
Professionals are entitled to timely information that will assist them in advancing and protecting the public health.
Other Organizations are entitled to: Page 110
Support Center – Managing and Analyzing i. cooperation from the ACME in maximizing efficient use of resources, eliminating duplication of efforts and carrying out collaborative efforts; ii. technical assistance, training and guidance iii. Grantee/Contractor Organizations are entitled to: iv. timely review of applications and awards; v. professional treatment in resolving disputes; vi. fair application of laws, regulations and policies; vii. fair and consistent application reviews; viii. respect in the performance of duties and responsibilities; and ix. timely payment.
FUTURE EFFORTS ACME will continue to embark on a variety of initiatives to ensure that it continues to address customer needs. The on-going Customer Service Management group will coordinate these activities. Ensuring that quality service is provided is an on-going process that requires changes in the way we do business by increasing emphasis on listening to our customers and by learning from the best in private industry. The organization will strive to reinvent itself -- to become more efficient and effective--and to provide the types of services the public expects. Over the coming months, the organization will: a. develop programs and initiatives that address customer needs. The organization, as a whole, and the individual centers and institutes will use the information gathered from the survey and focus groups to develop and enhance services. b. benchmark against the best-in-the-business. The organization will determine what internal processes need to be improved, benchmark with leading industries, and establish performance standards. c. establish processes to improve customer feedback. Systems will be established to receive and address customer suggestions and feedback.
Page 111
Support Center – Managing and Analyzing
Incident Management INTRODUCTION ROADMAP Many organizations are looking to implement Incident Management as a way to improve the structure and quality of the business. This document describes the contents of the Incident Management Guide. The information found within the book is based on the ITIL Version 2 framework, specifically the Incident Management process within the Service Support phase. The guide is designed to answer a lot of the questions about Incident Management and provide you with useful guides, templates and essential, but simple assessments. The supporting documents and assessments will help you identify the areas within your organization that require the most activity in terms of change and improvement. Presentations can be used to educate or be used as the basis for management presentations or when making business cases for Incident Management implementation. The additional information will enable you to improve your organizations methodology knowledge base. The guide serves to act as a starting point. It will give you a clear path to travel. It is designed to be a valuable source of information and activities. The Incident Management Guide:
Flows logically,
Is scalable,
Provides presentations, templates and documents,
Saves you time.
Step 1 Start by reviewing the PowerPoint presentation. Incident Management ITIL V2 – This presentation provides a detailed and comprehensive overview of Incident Management in the specialist areas of ITIL Version 2 and in particular, within the Incident Management process is part of the Service Support phase. This presentation will give you a good knowledge and understanding of all the terms, activities and concepts required within Incident Management. They can also be used Page 112
Support Center – Managing and Analyzing as the basis for management presentations or when making a formal business case for Incident Management implementation. Make sure you pay close attention to the notes, as well as the slides, as references to further documents and resources are highlighted here. Step 2 If you did not look at the supporting documents and resources when prompted during the PowerPoint presentations, do this now. Below is an itemized list of the supporting documents and resources for easy reference. You can use these documents and resources within your own organization or as a template to help you in prepare your own bespoke documentation. Incident Management ITIL V2:
Business Justification Document
Objectives and Goals
Policies Objectives and Scope
Incident Category Definition
Communication Plan
Incident Management Process Flow
Reports KPI’s and Metrics
Incident Ticket Template
Incident Management Process
Step 3 Alternatively, continue by working through the Implementation Plan with the focus on your organization. This will help you ascertain the Incident Management maturity for your organization. You will able to identify gaps and areas of attention and/or improvement. The supporting documents and resources found within the book will help you fill these gaps by giving you a focused, practical and user-friendly approach to Incident Management.
INCIDENT MANAGEMENT PRESENTATION
Page 113
Support Center – Managing and Analyzing
Page 114
Support Center – Managing and Analyzing These bullet points help to illustrate why it is that we need to introduce the disciplines of effective and efficient Process management into our IT environments. Briefly discuss each, you can of course add or delete points according to your own situation.
ITSM is not something on its own, but closely linked to the business. Explain difference between ‗effective‘ (doing the right thing) and ‗efficient‘ (doing the right thing the right way). The objective tree is a useful way to help explain the importance of IT being a supporting department to the business. To meet organisational objectives, the organization has business processes in place. Examples of business processes are sales, admin and financial (who have a ―sales process‖) or logistics, customer service and freight (who have a ―customer returns process‖). Each of the units involved in these business processes needs IT Services (e.g. CRM application, e-mail, word processing, financial tools). Each of these services runs on IT infrastructure that has to be properly managed (Service Management). IT Infrastructure includes hardware, software, procedures, policies, documentation, etc. ITIL provides a framework for the management of IT Infrastructure.
Page 115
Support Center – Managing and Analyzing
Traditionally we look at the IT department as a collection of specialists with specialist skills. This is a functional way to look at IT and it puts people into departmental silos.
Best practice processes will transverse functional departments and help to break down the silos/walls/barriers to communication between them. Explain the benefits of processes in general. Other points to explain:
A process is a set of activities with a common goal.
A process can measure the input, output and activities.
A process will link these measurements to targets.
Page 116
Support Center – Managing and Analyzing
An IT organization needs to focus on all these aspects to deliver the right IT services (effective) in the right way (efficient). Generally, the technology perspective gets a lot of attention (time, budget, people, etc). More and more people see the importance of processes (which is why ITIL is getting so popular). There is also an organization perspective: the alignment of vision, strategy and goals with the day to day activities in IT. This is useless, if it is not communicated (which is virtually always the case) and finally, there is the people perspective, which looks at the ‗soft side‘: is your staff happy, do they have the right skills, are you managing them effectively, etc.
Page 117
Support Center – Managing and Analyzing Incident Management is one of 10 ITIL processes. Here we get to see the others and the one function (Service Desk). Security Management can be included as well, due to it‘s critical importance.
Is a process that is based around communication and monitoring
Is a process that requires high client/customer liaison
Provides information to all other processes (e.g. customer expectations, financial information,etc.)
Requires information from other processes (e.g. reports on performance, trending information, customer satisfaction ratings)
etc.
Page 118
Support Center – Managing and Analyzing Focus is on ―as quickly as possible‖. So, providing Work-arounds is fully accepted. Incident Management is NOT about root cause analysis or implementing structural solutions. Normal service operation is defined in the SLAs.
Page 119
Support Center – Managing and Analyzing
The inputs of the Incident Management process are:
Incident details sourced from (for example) Service Desk, networks or computer operations.
Configuration details from the Configuration Management Database (CMDB)
Response from Incident matching against Problems and Known Errors.
Resolution details
Response on RFC to effect resolution for Incident(s).
The outputs of the Incident Management process are:
RFC for Incident resolution; updated Incident record (including resolution and / or Work-arounds)
Resolved and closed Incidents
Communication to Customers
Management information (reports)
Page 120
Support Center – Managing and Analyzing
Incidents can come from different sources: detection and reporting by a user incident logging via telephone, e-mail, fax, … detection by a system event is automatically logged as incident detection by Service Desk personnel personnel takes care of incident logging detection by personnel of another IT department personnel takes care of incident logging or reporting via Incident Management The tasks within this activity are: •Record basic details of the Incident •Alert specialist support group(s) as necessary •Start procedures for handling the service request
Page 121
Support Center – Managing and Analyzing
The tasks for this activity are:
Classify Incidents
Matching against Known Errors and Problems
Informing Problem Management of the existence of new Problems and of unmatched or multiple Incidents
Assigning impact and urgency, and thereby defining priority
Assessing related configuration details
Providing initial support (assess Incident details, find quick resolution)
Closing the Incident or routing to a specialist support group, and informing the User(s)
Impact: degree to which the business is effected by the incident Page 122
Support Center – Managing and Analyzing Urgency: degree to which the incident resolution can be delayed (this includes ease with which incident can be solved). Expected effort plays also a role. Examples: 1. High Impact – low Urgency; Server down which affects a department but on holidays so it is not urgent. 2. High Urgency – Low Impact; an individuals laptop has no modem and he will need to use it while away, he flies out this afternoon!
Spend some time on making the difference between Incidents and Problems clear. Spend some time on the relationships between Incident, Problem, Known Error, Request for Change, structural resolution.
Page 123
Support Center – Managing and Analyzing The tasks for this activity are:
Assessment of the Incident details
Collection and analysis of all related information, and resolution
(including any Workaround) or a route to n-line support
Functional: to find someone who can solve the incident Hierarchical: to inform someone of the incident (and the [potential] effects on the SLA) In practice, they will often be combined. Give examples!! Example: 1. Hierarchical; the Operations Manager. 2. Functional; 2nd line support.
The tasks for this activity are: Page 124
Support Center – Managing and Analyzing
Resolve the Incident using the solution / Work-around or, alternatively, to raise an RFC (including a check for resolution)
Take recovery actions
The tasks for this activity are:
The confirmation of the resolution with the Customer or originator
Update Incident details
Close Incident
The tasks for this activity are:
Monitor Incidents
Escalate Incidents
Inform User Page 125
Support Center – Managing and Analyzing
Page 126
Support Center – Managing and Analyzing The ARCI Model is used to link process activities with responsibilities. 4 types of responsibilities (in blue index). This works on any level, so process, procedure etc. Steps within process/procedure on vertical axis. Rules: only 1 ‗A‘ per row (clear ownership), at least 1 ‗R‘ per row, as many of the others as necessary. If a certain column remains empty, then that group has no involvement in process. If multiple columns have identical entries, than those groups can be merged from a process point of view.
Page 127
Support Center – Managing and Analyzing
Page 128
Support Center – Managing and Analyzing
Page 129
Support Center – Managing and Analyzing
SUPPORTING DOCUMENTS Through the documents, look for text surrounded by << and >> these are indicators for you to create some specific text.
Watch also for highlighted text which provides further guidance and instructions.
BUSINESS JUSTIFICATION DOCUMENT
IT Services Business Justification Process: Incident Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<
>
Business Justification Document for Incident Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly
Release Date:
be reminded of the key topics that have to be considered. This document serves as a reference for HOW TO APPROACH THE TASK OF SEEKING FUNDS for the implementation of the Incident Management process. This document provides a basis for completion within your own organization.
This document was; Prepared by: Incident Management Business Justification On: <> AAnd strong enoughby: business case will ensure progress and funds are made available for any IT accepted On: initiative.
<>
Page 130
Support Center – Managing and Analyzing This may sound like a bold statement but it is true. As IT professionals we have (for too long) assumed that we miss out on funds while other functional areas (e.g. Human resources and other shared services) seem to get all that they want. However, the problem is not with them, it‘s with US. We are typically poor salespeople when it comes to putting our case forward. We try to impress with technical descriptions, rather than talking in a language that a business person understands. For example:
We say We have to increase IT security controls, with the implementation of a new firewall.
We should say Two weeks ago our biggest competitor lost information that is now rumored to be available on the internet. The network bandwidth is our biggest bottleneck The e-mail you send to the other national and we have to go to a switched local managers will take 4 to 6 hours to be environment. delivered. It used to be 2 to 3 minutes, but we are now using our computers for many more tasks. Changes to the environment are scheduled for a We are making the changes on Sunday period of time when we expect there to be afternoon. There will be less people working minimal business impact. then. Doesn‘t that sound familiar? To help reinforce this point even further, consider the situation of buying a new fridge. What if the technically savvy sales person wants to explain ―the intricacies of the tubing structure used to super cool the high pressure gases, which flow in an anti-clockwise direction in the Southern hemisphere‖. Wouldn‘t you say ―too much information, who cares – does it make things cold?‖ Well IT managers need to stop trying to tell business managers about the tubing structure and just tell them what they are interested in. So let‘s know look at some benefits of Incident Management. Remember that the comments here are generic, as they have to apply to any organization. If you need assistance in writing business benefits for your organization please e-mail [email protected] for a quotation.
Benefits Through a properly controlled and structured Incident Management process we will be able to more effectively help in the alignment of the delivery of IT service to the
Notes/Comments/Relevance
Page 131
Support Center – Managing and Analyzing business requirements. This is achieved by reducing the amount of lost time that the business people experience from incidents. A reduction in the amount of time spent being reactive will therefore allow IT to spend more time on aligning the IT Services with the needs of the Business. A heightened visibility and increased communication related to incidents for both business and IT support staff. The reader should be able to draw upon experience regarding the overall negative impact that an unpublicized incident has. Also the negative impact on staff morale that having to deal with fallout from incidents that they weren‘t even aware of. Organizations and therefore IT environments are becoming increasingly complex and continually facing new challenges. The ability to meet these challenges is dependant on the speed and flexibility of the organization. The ability to cope with more changes at the business level will be directly impacted by how quickly IT Departments can restore service and reduce the amount of time in ‗loss of service due to incidents‘. (Reader, here you can describe a missed opportunity, due to slow Incident Management or a process dragged down by bureaucracy)
Noticeable increases in the potential productivity of end users and key personnel through reduced interruption times, higher quality services and less diversion from planned tasks due incidents not being dealt with correctly. The goal statement of Incident Management is to restore normal service operation as quickly as possible. By the very nature of this statement we can expect a reduction in user interruption times. Whether end users and staff take advantage of this reduced down-time is not an issue for IT professionals to monitor. Knowing that we have made more working time available is what we need to publish – NOT productivity rates. An ITIL Incident Management process will guide you towards understanding the financial implications of all those incidents occurring in the IT infrastructure. This has real benefits as it may prevent an organization from spending money on areas of the IT Infrastructure where there really haven‘t been any significant incidents or impacts on the business. Incident Management aides in improving the security
Page 132
Support Center – Managing and Analyzing aspects of the organization with respect to IT. Incident Management will work in conjunction with Security Management to track and respond to security incidents in the appropriate manner. Correct recording and management of Security Incidents will help in trend analysis for future preventative actions. The Incident Manager will ensure that the impact of the incident has been fully assessed prior to starting the resolution. This helps provide a sense of urgency to the Service Desk staff, thus ensuring they act with priority, and not perform those tasks that may be easier to do. With a sound Incident Management process we can expect an overall improvement in the rate of resolution as more and more incidents have recorded resolution histories that can be used by the Service Desk. Any ITIL process has the potential to increase the credibility of the IT group, as they offer a higher quality of service, combined with an overall professionalism that can be lacking in ad-hoc activities.
OBJECTIVES AND GOALS
IT Services Detailed Objectives/Goals Process: Incident Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Page 133
Support Center – Managing and Analyzing
Detailed Objectives/Goals
Release Date:
for Incident Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. The detailed objectives for Incident Management should include the following salient points: Objective To restore service as quickly as possible. Incidents in the IT Infrastructure are a sure sign of the organization being reactive and not having proactive processes in place. To restore service as quickly as possible we need a way of capturing past incidents and the resolutions used to restore service. Minimize the adverse affects of Incidents on the IT Infrastructure and the Business by becoming proactive. Once developed an Incident Management process can be used to supply workarounds and also capture incidents before they are realised by the business or before they cause significant harm to the IT services being delivered. To establish efficient assessment guidelines that covers the business, technical and financial aspects of resolving incidents in the infrastructure. Generally this will involve different people so the challenge is designing a process that minimizes the time taken. To develop a variety of activities to cater for commonly occurring degrees of incidents. For example, there is a wide degree of potential impacts that an incident may have on the environment. If we can categorize these impacts we can pre-build models for dealing with them. To establish ground rules that distinguishes an Incident from a problem from a known error. An incident is seen as the symptom for larger or unknown issues that may exist in your environment. Develop working relationships with all other process areas. The Incident Management process should be
Notes Met/Exceeded/Shortfall Dates/names/role titles
Page 134
Support Center – Managing and Analyzing considered a proactive one requiring input from other process areas. Obvious links include Configuration Management (to verify configuration information and trends against configuration items) and Change Management (to check the results of implemented changes) and Network Management tools (to identify potential threats to the IT Infrastructure). Develop a sound Incident Management process and look for continuous improvement.
Use these objectives to generate discussion about others that may be more appropriate to list than those provided.
Page 135
Service Desk Workbook
POLICIES OBJECTIVES AND GOALS
IT Services Policies, Objectives and Scope Process: Incident Management Status:
Version:
In draft Under Review Sent for Approval Approved Rejected <>
Release Date: Policies, Objectives and Scope for Incident Management This document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered.
Policy Statement
Page 136
Service Desk Workbook
A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous Use this text box to answer the ―SENSE OF URGENCY‖ question regarding this process. Why is effort being put into this process? Not simply because someone thinks it‘s a good idea. That won‘t do. The reason has to be based in business benefits. You must be able to concisely document the reason behind starting or improving this process. Is it because of legal requirements or competitive advantage? Perhaps the business has suffered major problems or user satisfaction ratings are at the point where outsourcing is being considered. A policy statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHY question for this process.
Objectives Statement Something worked toward or striven for; a goal. Use this text box to answer the ―WHERE ARE WE GOING‖ question regarding this process. What will be the end result of this process and how will we know when we have reached the end result? Will we know because we will establish a few key metrics or measurements or will it be a more subjective decision, based on instinct? A generic sample statement on the “objective” for Incident Management is: The objective of the Incident Management process is to ensure that the Organisation and the services it provides to its customers are not affected by incidents occurring within the IT Infrastructure. Incident Management will work together with other processes to ensure that an incident is dealt with in the most efficient way possible, thus restoring service as quickly as possible and reducing the effect of the incident on the business. Note the keywords in the statement. For the statement on Incident Management they are “dealt with in the most efficient” and “restoring service as quickly as possible”. These are definite areas that we can set metrics for and therefore measure progress. An objective statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHERE question for this process.
Page 137
Service Desk Workbook
Scope Statement The area covered by a given activity or subject Use this text box to answer the ―WHAT‖ question regarding this process. What are the boundaries for this process? What does the information flow look like into this process and from this process to other processes and functional areas? A generic sample statement on the “scope” for Incident Management is: The Incident Management process will be responsible for the processing of incidents involving the following aspects of the IT Infrastructure: Hardware Software System Software Etc All Documents pertaining to the above Systems and Services Incident Management will not be responsible for those components that exist under the banner of Applications Development. The recording, monitoring and closing of incidents will be the sole responsibility of the Service Desk. The above Policy Statement was; A scope statement any bigger than this text box, may be too lengthy to read, lose the intended audience Prepared by: with detail, not be clearly focussed on answering the WHAT question for this process. The above Objective Statement was; On: <> Prepared by: On: And accepted by: <> And accepted by: <> On: On: <>
INCIDENT CATEGORY DEFINITION The above Scope Statement was; Prepared by: On: <> And accepted by: On: <>
Page 138
Service Desk Workbook
IT Services Incident Category Definition Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Document Control Author Prepared by Document Source This document is located on the LAN under the path: I:/IT Services/Service
Release Date:
Support/Incident Management Document Approval This document has been approved for use by the following: , IT Services Manager , IT Service Delivery Manager , National IT Help Desk Manager Amendment History Issue
Date
Amendments
Completed By
Distribution List When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: Business Unit
Stakeholders
IT
Page 139
Service Desk Workbook
Introduction Purpose The purpose of this document is to provide the IT Organization with the specifications of the information to be captured on an Incident Ticket. Scope This document describes the following:
details of Incident categories
Audience This document is relevant to all staff in Ownership IT Services has ownership of this document. Related Documentation Include in this section any related Incident Management reference numbers and other associated documentation:
INC8200 Incident Management Implementation Plan / Project Plan
INC8300 Incident Management Policies, Guidelines and Scope Document
INC8600 Incident Management Process
Executive Overview Describe the purpose, scope and organization of the document. Incident Overview This document contains suggestions regarding the status and categories for incident tickets. The definition of an Incident is: Any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service. The definition of a Service Request is: Any request for information / advice / documentation / password reset or any event which is not considered a failure of the IT Infrastructure and is not a Change. Status Types
Page 140
Service Desk Workbook
Each Incident ticket should record the current status of that ticket. The following table lists some examples:
Value
Notes
New
Default status on ticket.
Contact
Customer has been contacted.
Notified
Used to initiate & record notification of ticket to 2nd line support or 3rd Parties.
Committed
Acceptance of call by support group.
Solving
Solving by support group.
Pending
This is a wait status
Resolved
Ticket is resolved
Closed
Ticket is closed, Customer / End User has confirmed service restoration.
It may also be necessary to break this down further and include a sub-status or a status reason that can be nested under each of the above status types. Some examples are illustrated in the following table:
Status Reason Service Desk
Notes The ticket is with the Service Desk for that status
Support Group
The ticket is with 2nd line support for that status
3rd Party
Stop SLA Clock
Canc. by Customer Canc. by IT Department Customer Action Needed
Stop SLA Clock
Customer Mgt
Stop SLA Clock
Customer Not Available
Stop SLA Clock
Customer Requested Delay
Stop SLA Clock Page 141
Service Desk Workbook
Customer Support Group
Stop SLA Clock
Down No Loan Down Waiting Loan Down Waiting Rep Down Waiting Spares Up Fixed & Monitoring Up Waiting Loan Up Waiting Repair Up Waiting Spares Up Waiting Test Definition Details Incident Type – Category Type Matrix INCIDENT TYPES CATEGORY TYPE
Incident Please Specify
X
Support
Work
Request
Request
X
X
Add User
x
Delete User
x
Modify User
x
Password Reset
x
Add
x
x
Modify
x
x
Delete
x
x
Audit
x
x x
Backup and Recovery
x
x
Batch Processing
x
x
Printing
x
x
Scheduled Outage Unscheduled Outage
Feedback X
x x
Consulting
x
x
Advice and Guidance
x
x Page 142
Service Desk Workbook
Training
x
x
Relocate
x
x
Reporting
x
x
Performance
x
x
Customer Complaint
x
Customer Compliment
x
Environment
x
x
x
Hardware
x
x
x
Software
x
x
x
x
x
x
x
Maintenance Security
x
Service Desk Services
x
Desktop Services
x
Network Services
x
Data/Voice Services
x
Communications
x
x
Contract
x
Sales
x
Billing
x
Incident Type Definitions Incident Types are a high level classification of service offerings. They provide both << company >> and the Client a high level overview of the services that are being actioned by << company >>. Certain incident types can only be used when the request for service from the client is within the scope of the contract or SLA. Incident or Support Requests outside the scope of the contract are classified as Work Requests. Incident This is the default Case Type. Incidents are a direct result of a product and/or service error. An error is defined as a product or service not functioning as specified
Page 143
Service Desk Workbook
as normal behaviour by the vendor. Unscheduled Outages also fall under this case type. Cases of this type can also include warranty cases. Support Request Requests for services within the contracted scope of services agreed between << company >> and the Customer. This includes requests such as new users, password resets etc. Support Requests also include requests for support in the use of particular software or hardware. These requests can be in relation to a client perceived hardware / software Incident. All Support Requests must fall within the scope of the contract or SLA. Work Request Request for items not covered by a Contract or SLA are considered Work Requests. Services such as consultation, procurement, change management and performance of audits that are not part of contracted services are examples of a Work Request. However, it is possible that a service provided to one Customer is a Work Request (not in their contract or SLA) while the same service provided to another Customer is not (is in their contract or SLA). Work Requests result in the billing of the Customer. Feedback This is where a Customer, Supplier or Service provider, providing information on the level of service that they have received from various << company >> service delivery divisions. Category Type Definitions Category Types are a second level definition to that of Incident Types. This will enable << company >> to categorise tickets in more detail to enable aggregation of similar tickets for reporting. The Incident Type and Category Type work together as a nested drop down. Add User Incident
Support
Work
Request
Request
Feedback
X Request for a new user to be added to a system(s). Delete User Incident
Support
Work
Feedback Page 144
Service Desk Workbook
Request
Request
X Request for the deletion of a user from a system(s). Modify User Incident
Support
Work
Request
Request
Feedback
X Request to modify user details within a system(s). This can also be a request to move user accounts from server to server. Password Reset Incident
Support
Work
Request
Request
Feedback
X Request for a password reset within a system(s). Add Incident
Support
Work
Request
Request
X
Feedback
X
Request for the addition of extra software, hardware, product or service within an environment or system. Modify Incident
Support
Work
Request
Request
X
X
Feedback
Request for the modification of an environment, product or service. This encapsulates modifications to a PC, Laptop, Mainframe, Midrange, Server, hardware, software etc. Delete Incident
Support
Work
Request
Request
X
X
Feedback
Page 145
Service Desk Workbook
Request for the modification of an environment, product or service such as PC, Laptop, Mainframe, Network service or environment etc, only in respect to the removal or deletion of hardware or software. Audit Incident
Support
Work
Request
Request
X
X
Feedback
Requests that require an audit of a particular machine or requests to audit an entire environment. Backup and Recovery Incident
X
Support
Work
Request
Request
X
X
Feedback
Any Incidents or requests in relation to the backup and recovery of information. In relation to Walk in Repair, the case may simply be a request to recover information off certain types of media. Batch Processing Incident
X
Support
Work
Request
Request
Feedback
X
For cases in relation to batch processing where there is a fault with the batch, or a support request to schedule new batch jobs. Printing Incident
X
Support
Work
Request
Request
Feedback
X
Any Incidents or requests regarding printing issues experienced as a result of other hardware or software issues. Scheduled Outage Incident
Support
Work
Request
Request
X
X
Feedback
Page 146
Service Desk Workbook
An Outage that has the approval of all stakeholders within a Change Request. This can also relate to a request to schedule an outage. Unscheduled Outage Incident
Support
Work
Request
Request
Feedback
X Outages in regards to products or services, or any critical impact environment, that have not been scheduled or approved. Consulting Incident
Support
Work
Request
Request
X
X
Feedback
A request for Consulting services from any area of expertise within << company >>. Advice and Guidance Incident
Support
Work
Request
Request
X
X
Feedback
A request from the client requiring advice or guidance for a particular Incident or request for information. Training Incident
Support
Work
Request
Request
X
X
Feedback
Any requests for training in the use of << company >> supplied equipment or services. This request can fall outside the scope of a contract, thus becoming a billable case. Relocate Incident
Support
Work
Request
Request
X
X
Feedback
Requests in relation to the movement of any products or services within the Client‘s environment, including the movement of staff. Page 147
Service Desk Workbook
Reporting Incident
Support
Work
Request
Request
X
X
Feedback
Requests in relation to ad-hoc reporting, changes to the reporting environment and/or structure. Performance Incident
X
Support
Work
Request
Request
Feedback
X
Incidents, Requests or repairs in relation to performance issues in regards to environments ranging from the Desktop to Network/Server/LAN/WAN environments. Customer Complaint Incident
Support
Work
Request
Request
Feedback
X Customer complaints in relation to products or services provided by << company >>. Customer Compliment Incident
Support
Work
Request
Request
Feedback
X Customer compliments in relation to products or services provided by << company >>. Environment Incident
X
Support
Work
Request
Request
X
X
Feedback
incidents or requests relating to environment issues e.g. air conditioning, power, water, fire and other hazards. Hardware Incident
Support
Work
Feedback Page 148
Service Desk Workbook
X
Request
Request
X
X
Incidents, Requests, inquiries and repairs in relation to hardware issues, unless there is something more specific to the ticket in another activity type. Software Incident
X
Support
Work
Request
Request
X
X
Feedback
Incidents, Requests, inquiries and repairs in relation to software issues, unless there is something more specific to the ticket in another activity type. Maintenance Incident
Support
Work
Request
Request
X
X
Feedback
Maintenance involves anything done to maintain the IT environment, product or service, such as running scan disk on a PC, or removal of obsolete user ids on a server etc. Security Incident
X
Support
Work
Request
Request
X
X
Feedback
Incidents or Requests relating to physical intrusion or data access should be logged under security. For example, someone may feel that their e-mail account has been tampered with and require an investigation, or an attempt has been made to gain access to a building or to data. Service Desk Services Incident
Support
Work
Request
Request
Feedback
X General feedback regarding Service Desk Services. Desktop Services
Page 149
Service Desk Workbook
Incident
Support
Work
Request
Request
Feedback
X General feedback regarding Desktop Services. Network Services Incident
Support
Work
Request
Request
Feedback
X General feedback regarding Network Services. Data/Voice Services Incident
Support
Work
Request
Request
Feedback
X General feedback regarding Data/Voice Services. Communications Incident
X
Support
Work
Request
Request
Feedback
X
Communications covers anything to do with data, voice, or network products or services. This activity type can be used only if something more specific is not available. Contract Incident
Support
Work
Request
Request
Feedback
X Any questions or information required about the current contract between << company >> and the client. Sales Incident
Support
Work
Request
Request
Feedback
X Any questions or information regarding Sales. Page 150
Service Desk Workbook
Billing Incident
Support
Work
Request
Request
Feedback
X Any questions or information regarding Billing. Subcategory Against the Categories listed above, some IT Service Management tools will allow further breakdown of the information. This is sometimes called a subcategory. The following list provides some examples:
Business Applications
Client Systems
Network LAN
Network WAN
Printing
Shared Infrastructure
Telecoms
etc
Product Type It is also possible to add a third level ticket categorisation. This can be placed at the product type level. This information does not need to be nested, but can be made available regardless of the Incident Type, Category or Subcategory. The following list provides some examples of product types:
PABX
Phone
Mobile Phone
PDA
Laptop
Standard Application
Non-Standard Application
Desktop
Printer Page 151
Service Desk Workbook
Router
Switch
Consumable
Etc.
Appendices Include any applicable appendices that are needed. Terminology Make sure that all terminology is captured and documented correctly.
COMMUNICATION PLAN
IT Services Communication Plan Process: Incident Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date: Communication Plan for Incident Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered.
Page 152
Service Desk Workbook
This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Incident Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding information to share with others. The document is deliberately concise and broken into communication modules. This will allow the reader to pick and choose information for e-mails, flyers, etc. from one or more modules if and when appropriate. This document was; Prepared by: On: <> Initial Communication And accepted by: On:the Benefits. <> Sell
First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system, a new way of working. WHY? It is here that we need to promote and sell the benefits. However, be cautious of using generic words. Cite specific examples from your own organization that the reader will be able to relate to (to help develop specific examples contact [email protected] for competitive quotation).
Generic Benefit statements
Specific Organizational example
Improved Customer Service Reduction in the number of Incidents
This is important because… In recent times our incidents within IT have… Apart from the obvious benefits, the IT department in recent times has… A recent example of … saw the individual and others in the company start to…
Provides quicker resolution of Incidents Improved Organisational learning
The above Communication module (or elements of) was/were distributed; To: On: <> Incident Management Goal By: On:
<>
Page 153
Service Desk Workbook
The Goal of Incident Management.
The Goal of Incident Management can be promoted in the following manner. Official Goal Statement: To restore IT Services as quickly as possible, within the agreed time scales, so as to minimise the adverse effect of Incidents on the IT Services used by the business.
High visibility and wide channels of communication are essential in this process. Gather specific Incident Requirements from nominated personnel
(Special Tip: Beware of using only Managers to gain information from, as the resistance factor will be high)
Oversee the monitoring of processes to ensure that the business needs of IT are not impacted, but taking into account that changes are required to ensure continued high levels of IT Service Delivery and Support.
Provide relevant reports to nominated personnel.
(Special Tip: Beware of reporting only to Managers. If you speak to a lot of people regarding Service Support and Delivery then you need to establish ways to report to these people the outcomes and progress of the discussions). Always bear in mind the ―so what‖ factor when discussing areas like goals and objectives. If you cannot honestly and sensibly answer the question ―so what‖ – then you are not selling the message in a way that is personal to the listener and gets their ―buy-in‖.
The above Incident Management Goals module was distributed; To: On:
<>
Incident Management Activities Intrusive & Hidden Activities By: On:
<>
Page 154
Service Desk Workbook
The list of actions in this module will have a direct impact on end users and IT Staff. They will be curious as to why staff are working with them in this manner, rather than the historical method of just ―doing it‖. There could be an element of suspicion and resistance, so consider different strategies to overcome this initial scepticism. Incident Recording Set clear definitions for the recording of incidents. This will allow easier and more effective trending of incidents Central recording of incidents will help in reducing the amount of lost incidents. Incidents will be handled by trained experts in the process, thus providing better customer service. Incident Classification Incident classification can happen at first or second line support Clear definitions required for classification. This will increase the ability to perform trend analysis on incidents Incident Diagnosis Diagnosis of the incident can be performed at first or second line support This will help provide a structure to understand the nature of the incident Determine the correct work-around The work-around should be selected on its ability to restore service as quickly as possible without causing any additional incidents or complicating the underlying error Incident Resolution The resolution of an incident can be performed at first or second line support Resolution differs from closure and communication of this fact is integral to the process. Resolution occurs when the incident is believed to no longer be in effect. Resolution can happen without customer or end-user input or communication. Incident Closure Incident closure is the sole responsibility of the Service Desk Closure only occurs when the customer or end-user has confirmed that the incident is no longer disrupting their service Separation of Resolution and Closure provide a process that stimulates good customer service
Incident Management Planning Information regarding activities was distributed; To: On:
<>
By: On:
<>
Page 155
Service Desk Workbook
Costs Information relating to costs may be a topic that would be held back from general communication. Failure to convince people of the benefits will mean total rejection of associate costs. If required, costs fall under several categories: Personnel – incident tracking staff, database management team (Set-up and ongoing of the incident database) Accommodation – Physical location (Set-up and ongoing) Software – Tools (Set-up and ongoing) Hardware – Infrastructure (Set-up) Education – Training (Set-up and ongoing) Procedures – external consultants etc (Set-up) The costs of implementing Incident Management will be outweighed by the benefits. For example, many organizations have a negative perception of the incident management process as it doesn‘t remove the cause. To alleviate this, customers and end-users need to be constantly informed of the progress of their incident. This provides good customer service and adds a level of comfort to the users in the sense that they can ―see‖ action taking place. Incident Management does not have to be a reactive process, an incident can be something that may cause a disruption to service. A well run Incident Management process will make major inroads into altering the perception of the IT Organisation.
Details regarding the cost of Incident Management were distributed; To: INCIDENT MANAGEMENT PROCESS FLOW On:
<>
REPORTS KPI’s AND METRICS By: On:
<>
IT Services Reports and KPI Targets Process: Incident Management Status:
In draft Under Review Sent for Approval Approved Page 156
Service Desk Workbook
Rejected Reports and KPI Targets for Incident Management
Version:
<>
The document is not to be considered an extensive statement as its topics have to be
Release Date:
generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE ON SUITABLE KEY PERFORMANCE INDICATORS (KPIs) and REPORTS FOR MANAGEMENT for the Incident Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding the measures that would be meaningful for this process. The metrics demonstrated are intended to show the reader the range of metrics that can be used. The message must also be clear that technology metrics must be heavily supplemented with non-technical and business focused metrics/KPI’s/measures. This document was; Prepared by: On: performance indicators <> Key (KPI’s) Continuous improvement requires that each process needs to have a plan about And accepted by:
―how‖ and ―when‖ to measure its own performance. While there can be no set On:
<>
guidelines presented for the timing/when of these reviews; the ―how‖ question can be answered with metrics and measurements. With regard to timing of reviews then factors such as resource availability, cost and ―nuisance factor‖ need to be accounted for. Many initiatives begin with good intentions to do regular reviews, but these fall away very rapidly. This is why the process owner must have the conviction to follow through on assessments and meetings and reviews, etc. If the process manager feels that reviews are too seldom or too often then the schedule should be changed to reflect that. Establishing SMART targets is a key part of good process management. SMART is an acronym for: Page 157
Service Desk Workbook
Simple Measurable Achievable Realistic Time Driven Metrics help to ensure that the process in question is running effectively. With regard to INCIDENT MANAGEMENT the following metrics and associated targets should be considered:
Key Performance Indicator
Target Value (some examples)
Time Frame/Notes/Who
Using data from the Configuration Management Database (CMDB) indicate any particular Configuration items that are experiencing reoccurring Incidents. (For more information on the CMDB refer to the Configuration Management process at www.theartofservice.com CONFIGMGT). Number of Incidents logged. Number of Service / Support Requests logged These can be broken down by the following: Number of Incidents per Priority, Impact, Urgency Number of Incidents per Type and Category Number of Incidents per Person (i.e. top ten incidents per user) Number of Incidents per CI Type (i.e. top ten infrastructure incidents) Etc. The average time to achieve Incident Resolution. This can be broken down by the following: Type Page 158
Service Desk Workbook
Category Priority, Impact, Urgency The percentage of incidents handled within the agreed Service Level Agreements for that type of incident or CI. The average cost per incident Percentage of incidents resolved at first line support that have been agreed to be resolved via an SLA.
Percentage of Incidents resolved without on-site contact Percentage of incidents assigned more than 2 times.
This is a common KPI, and is also commonly misused. There will be a certain amount of incidents, determined via an SLA, which should be resolved at First Line Support. This number could potentially be only 10% of all calls received by First Line Support. Therefore a good statistic is say 90% of incidents that are agreed to be resolved at First Line Support.
This is an interesting number. It shows the effectiveness of the process and the level of knowledge of staff on the Service Desk. Ideally, if the Service Desk cannot resolve the incident, then it should only be assigned once to a support group, and then once back to the Service Desk.
Special Tip: Beware of using percentages in too many cases. It may even be better to use absolute values when the potential number of maximum failures is less than 100. Reports for Management Management reports help identify future trends and allow review of the ―health‖ of the process. Setting a security level on certain reports may be appropriate as well as categorizing the report as Strategic, Operational or Tactical. Page 159
Service Desk Workbook
The acid test for a relevant report is to have a sound answer to the question; ―What decisions is this report helping management to make?‖ Management reports for Incident Management should include:
Report The number of Incidents lodged, quantity rejected and the percentage that were issued as priority 1. As well as these numbers a very concise view of major incidents can also be included. Summary of incidents that are still to be resolved. Management will be interested to see the number of higher priority incidents still awaiting resolution. Importantly each outstanding incident should show how long it has been in this status. Incidents that have been in waiting for long periods of time may be downgraded or even closed. The number of incidents attributable to different business areas is also useful. This will help Management to understand departments that are in a state of continual disruption. Incidents can indicate poor management, fluctuating internal or increasing pressures from external forces. The Number of Incidents logged per person. This can provide the Top Ten Callers, and appropriate action can take place. Analysis and results of meetings completed The situation regarding the process staffing levels and any suggestions regarding redistribution, recruitment and training required. Human resource reporting including hours worked against activities (including weekend/after hours work, for example, on call duties). Audit Reports should verify that any selected Incident contains all relevant and expected information. Relevant Financial information– to be provided in conjunction with Financial Management for IT Services This information will include a cost per incident summary.
Time Frame/Notes/Who Priority 1 incidents should be fully described.
INCIDENT TICKET TEMPLATE
Page 160
Service Desk Workbook
IT Services Incident Ticket Template Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Document Control Author Prepared by Document Source This document is located on the LAN under the path: I:/IT Services/Service Support/Incident Management Document Approval This document has been approved for use by the following: , IT Services Manager , IT Service Delivery Manager , National IT Help Desk Manager Amendment History Issue
Date
Amendments
Completed By
Distribution List Page 161
Service Desk Workbook
When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: Business Unit
Stakeholders
IT
Introduction Purpose The purpose of this document is to provide the IT Organization with the specifications of the information to be captured on an Incident Ticket. Scope This document describes the following:
details of Incident Ticket attributes
Audience This document is relevant to all staff in Ownership IT Services has ownership of this document. Related Documentation Include in this section any related Incident Management reference numbers and other associated documentation:
INC8200 Incident Management Implementation Plan / Project Plan
INC8300 Incident Management Policies, Guidelines and Scope Document
INC8600 Incident Management Process
INC8700 Incident Management Category Definition Document
Executive Overview Describe the purpose, scope and organization of the document. Incident Overview The document‘s intent is to provide a list of attributes / fields that need to be captured on an Incident Ticket. For the purpose of this document, an Incident Ticket will be defined as a ticket to record information regarding an Incident or Service Request. The definition of an Incident is:
Page 162
Service Desk Workbook
Any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service. The definition of a Service Request is: Any request for information / advice / documentation / password reset or any event which is not considered a failure of the IT Infrastructure and is not a Change. The document will guide you through several sections of information. These sections could be considered as different tabs on a ticket within an ITSM tool. The following definitions apply for the following tables:
Read Only: No data may be entered into the field
System Generated: The application will automatically generate the correct value(s).
Check Box: A box, that when clicked upon will then show a mark, indicating that the box has been activated.
Linked Record: Means that the field provides a button to allow the user to click on, which will take them to a list of records in the database, at which point they may choose a value to populate the field with.
User Defined: Field allows the user to enter any value that they wish
User Defined Array: Field is considered a large text box which will allow the user to type multiple lines of text
Drop Box: Field allows the user to click on a drop down list of information, where they are allowed to make one selection to populate the field.
Drop Box – Nested: The values in this field are dependant on the values listed in the above Drop Box.
Break in Format: Indicates where there will be a visual break in sets of information captured on the Incident Ticket.
Ticket Details This is a common set of information to be gathered for each Incident Ticket. Field Ticket ID
Description (Where Necessary) This is the number for the ticket. This should be an
Type of Field Read Only. Page 163
Service Desk Workbook
Field
Contact Name First Name
Description (Where Necessary) incremental number. N.B. In high call volume service desks, this number can quickly increase. Some Service Desks use the following format, which guarantees the number will never exceed a certain length. YYYYMMDDxxxx, where (xxxxx) is a number that resets every day and increments with each new ticket logged. Self Explanatory. Self Explanatory.
Last Name
Self Explanatory.
Employee Id.
Email
It may be necessary to have a unique ID for each contact on the ticket. An employee id is common solution. Self Explanatory.
Corporate Structure / Department Phone #
This field lists the Corporate Structure of Department that the Contact belongs to. Phone Number
Ext #
Extension Number
Fax #
Facsimile Number
Critical User
Reported By Phone #
This check box indicates if the user is of importance within the company and requires a better level of service. Break in Format This field is a check box that will display the next section of information. This is a common requirement, as in some scenarios the person calling about the incident is not necessarily the individual with the issues. For example, Personal Assistance calling on behalf of the CEO. Name of the person reporting the incident. Phone Number
Ext #
Extension Number
Reported By Different from Contact
Type of Field System Generated.
Linked Record. Read Only. Populated by Contact Name. Read Only. Populated by Contact Name. Read Only. Populated by Contact Name. Read Only. Populated by Contact Name. Linked Record. Read Only. Populated by Contact Name. Read Only. Populated by Contact Name. Read Only. Populated by Contact Name. Check Box.
Check Box
Linked Record. Read Only. Populated by Contact Name. Read Only. Populated by Contact Name. Page 164
Service Desk Workbook
Field Fax #
Description (Where Necessary) Facsimile Number
Room / Floor Ref.
Break in Format This field should be a linked record and not rely on the above information. The simple reason is that some employees in your organization may move around and therefore their usual location may not be applicable. Self Explanatory
Cost Centre
Self Explanatory
Location
Status
Owner
Type Category Subcategory Product Type Impact Urgency Priority SLA Configuration Id. Type
Model
Break in Format The status of the ticket. This will be initially set to open when first logged. Please see INC8700 Incident Category Definition Document for further information. Initially populated by the individual (operator) logging the ticket, however, this is a changeable field as tickets may change ownership due to various reasons. The owner of the ticket can only be a Service Desk representative. This defines the type of ticket. Values here include: Incident and Service Request. Please see INC8700 Incident Category Definition Document for further information. Please see INC8700 Incident Category Definition Document for further information. Please see INC8700 Incident Category Definition Document for further information. The impact is the measure of business criticality. Urgency is about the necessary speed to solve the ticket Priority is defined by expected effort in resolving the ticket. The associated SLA. Break in Format The Configuration Item number that is involved in the incident The type of Configuration Item. For example: Hardware, Software, Printer, PC etc.
The model of the Configuration Item. For example: HP LaserJet, HP Desktop, Dell Desktop etc.
Type of Field Read Only. Populated by Contact Name. Linked Record.
Read Only. Populated by Location. Read Only. Populated by Location. Drop Box.
Linked Record.
Drop Box. Drop Box Drop Box – Nested Drop Box Drop Box Drop Box Drop Box Linked Record Linked Record Read Only. Populated by Configuration Id. Read Only. Populated by Configuration Page 165
Service Desk Workbook
Field
Description (Where Necessary)
Type of Field Id.
Assignment Group Assignee Name Phone #
Break in Format The 2nd or 3rd Line Support group to which the ticket has been assigned. An individual within the assignment group that is working on the ticket. Self Explanatory
Linked Record. Linked Record. Read Only. Populated by the Assignee Name field.
Update Details Field
Brief Description Description
Description (Where Necessary) The likely cause of the incident. This can be changed at the end of the life of the ticket. A brief description of the ticket. A full description of the ticket.
Ticket Update
Break in Format Field to allow the users to type any updates.
Update History
Field that shows all previous entered updates.
Cause Code
Type of Field Drop Box. User Defined. User Defined Array. User Defined Array. Read Only.
Related Tickets Details It should be a function of the IT Service Management tool to allow users to associate other tickets to the Incident Ticket being worked on. The association would be done by a corresponding search and attachment process. This will be determined by the tool itself. When associating another ticket to the incident ticket, the following information will automatically be attached.
Field
Incident ID.
Description (Where Necessary) Incident Tickets Incident Ticket number
Open Time
Time the incident ticket was opened
Status
Current Status of the ticket
Type of Field
Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Page 166
Service Desk Workbook
Field
Description (Where Necessary)
Type
Type of ticket
Category
Category for the ticket
Brief Description
A brief description of the ticket
Problem Tickets Problem ID See document PROB6800 Problem Ticket Template Open Time See document PROB6800 Problem Ticket Template Status See document PROB6800 Problem Ticket Template Category See document PROB6800 Problem Ticket Template Brief Description See document PROB6800 Problem Ticket Template Known Error Tickets Error ID See document PROB6900 Known Error Ticket Template Open Time See document PROB6900 Known Error Ticket Template Status See document PROB6900 Known Error Ticket Template Category See document PROB6900 Known Error Ticket Template Brief Description See document PROB6900 Known Error Ticket Template Request For Changes Change Number See document CHG7800 Request for Change (RFC) Template. Category See document CHG7800 Request for Change (RFC) Template. Phase See document CHG7800 Request for Change (RFC) Template. Asset See document CHG7800 Request for Change (RFC) Template. Description See document CHG7800 Request for Change (RFC) Template. Planned Start Date See document CHG7800 Request for Change (RFC) Template. Planned End Date See document CHG7800 Request for Change
Type of Field Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Auto Populated. Read Only. Page 167
Service Desk Workbook
Field
Description (Where Necessary) (RFC) Template.
Type of Field Auto Populated.
Resolution Details Field Resolution Code
Resolution Description Resolution Details
Description (Where Necessary) The resolution code for the ticket. This may include values such as: User Error, Training, Advice Given, No-Error, etc A brief description of the resolution given. A full description of the resolution applied to the ticket.
Type of Field Drop Box.
User Defined. User Defined Array.
History Field
Opened At
Description (Where Necessary) Name of the individual who opened / created / logged the ticket. Time the ticket was opened / created / logged.
Updated By Update At
Name of the individual who updated the ticket Time the ticket was last updated.
Resolved By Resolved At
Name of the individual who placed the ticket into a resolved status. Time the ticket was resolved.
Closed By Closed At
Name of the individual who closed the ticket. Time the ticket was closed.
Opened By
Type of Field Linked Record. Date / Time Field. Linked Record. Date / Time Field. Linked Record. Date / Time Field. Linked Record. Date / Time Field.
Appendices Include any applicable appendices that are needed. Terminology Make sure that all terminology is captured and documented correctly.
INCIDENT MANAGEMENT PROCESS Page 168
Service Desk Workbook
IT Services Roles, Responsibilities Process: Incident Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Detailed responsibilities of the Incident Management process owner The Incident Manager…..
Release Date: 1.
2.
3.
4.
5.
Description Will develop and maintain the Incident Management Process. Will develop, maintain and promote Incident Management as being a proactive process. Will coordinate process reviews utilizing independent parties to provide an objective view on the simplicity of the process and areas for improvement. Will be responsible for implementing any design improvements identified. Conducts reviews on Incidents and Service / Support Requests that have been identified and actioned to verify that all steps were completed and the objective of the process was achieved. Arrange and run all Incident Management reviews with the Service Desk team. Reviews should also occur on a daily (Priority 1), weekly (Priority 2 and 3) and monthly (All Calls) basis. The reviews where necessary will include other IT Departments as well as key customers. Will control and review: Any outstanding process related actions Current targets for service performance The process mission statement
Notes/Comments
Page 169
Service Desk Workbook
6.
Make available relevant, concise reports that are both timely and readable for Customers and Management
Detailed skills of the Incident Management process owner The Problem Manager…..
1.
2.
3.
Description The Incident Manager will display a communication style based on information and escalation. High degree of analytical skills to be able to assess the impact of incidents on different business systems and people. High degree of analytical skill needed to be able to help in the process or restoring service as quickly as possible. Semi-Technical ability in being able to read data from the Configuration Management process that will help with the identification of affected items involved in an incident.
4.
An ability to run a meeting according to strict guidelines (not to get side-tracked on items that one person may be interested in).
5.
The Incident Manager must be able to communicate with people at all levels of the organization. This is especially important during meetings. The process manager must be able to demonstrate ways to ―do things differently‖ that will improve the process. Must be able to think logically about potential incidents that could affect the organization and design appropriate assessment and diagnosis activities. This will provide a strong link to the Problem Management process
6. 7.
Notes/Comments
IMPLEMENTATION AND PROJECT PLAN
IT Services Implementation Plan/Project Plan Skeleton Outline Process: Incident Management Page 170
Service Desk Workbook
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date: Planning and implementation for Incident Management This document as described provides guidance for the planning and implementation of the Incident Management ITIL process. The document is not to be considered an extensive plan as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered for planning and implementation of this process.
Initial planning When beginning the process planning the following items must be completed: CHECK
DESCRIPTION
or or date Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (e.g. Internal, outsourced, hybrid) for the process. Assign a person to the key role of process manager/owner. This person is responsible for the process and all associated systems. This will person will generally be the Service Desk Manager. However, it is important to understand the differences and common conflicts that can occur between the two roles, for example, the Service Desk Manager may be concerned with call volumes and answer times, whereas the Incident Manager may be concerned with percentage of resolution at first point of call.
Page 171
Service Desk Workbook
Conduct a review of activities that would currently be considered as an activity associated with this process. Make notes and discuss the ―re-usability‖ of that activity. Three key activities of Incident Management should always remain with the Service Desk. They are:
Tracking, Monitoring and Co-ordinating of Incidents and Service Requests Incident Recording Incident Closure Create and gain agreement on a high-level process plan and a design for any associated process systems. NOTE: the plan need not be detailed. Too many initiatives get caught up in too much detail in the planning phase. KEEP THE MOMENTUM GOING. Review the finances required for the process as a whole and any associated systems (expenditure including people, software, hardware, accommodation). Don‘t forget that the initial expenditure may be higher than the ongoing costs. Don‘t forget annual allowances for systems maintenance or customizations to systems by development staff. Agree the policy regarding this process
Create Strategic statements. Policy Statement The policy establishes the ―SENSE OF URGENCY‖ for the process. It helps us to think clearly about and agree on the reasons WHY effort is put into this process. An inability to answer this seemingly simple, but actually complex question is a major stepping stone towards successful implementation The most common mistake made is that reasons regarding IT are given as the WHY we should do this. Reasons like ―to make our IT department more efficient‖ are far too generic and don‘t focus on the real issue behind why this process is needed. The statement must leave the reader in no doubt that the benefits of this process will be far reaching and contribute to the business in a clearly recognizable way. Objective Statement Page 172
Service Desk Workbook
When you are describing the end or ultimate goal for a unit of activity that is about to be undertaken you are outlining the OBJECTIVE for that unit of activity. Of course the activity may be some actions for just you or a team of people. In either case, writing down the answer to WHERE will this activity lead me/us/the organization is a powerful exercise. There are many studies that indicate the simple act of putting a statement about the end result expected onto a piece of paper, then continually referring to it, makes achieving that end result realistic. As a tip regarding the development of an objective statement; don‘t get caught up in spending hours on this. Do it quickly and go with your instincts or first thoughts – BUT THEN, wait a few days and review what you did for another short period of time and THEN commit to the outcome of the second review as your statement. Scope Statement In defining the scope of this process we are answering what activities and what ―information interfaces‖ does this process have. Don‘t get caught up in trying to be too detailed about the information flow into and out of this process. What is important is that others realize that information does in fact flow. For example, with regard to the INCIDENT MANAGEMENT process we can create a simple table such as: Incident Management Information flows Process
Process
Information
Incident Management
to
Problem Management
Incidents with unknown causes
Problem Management
to
Incident Management
Known Errors, Workaround, quick fixes
Incident Management
to
Change Management
Requests for Change
Change Management
to
Incident Management
Info on planned changes as some incidents will be resolved through an RFC
Page 173
Service Desk Workbook
Incident Management
to
Availability Management
Reports of availability-related incidents
Availability Management
to
Incident Management
Explanations regarding unacceptable levels of availability
Steps for Implementation. There can be a variety of ways to implement this process. For a lot of organizations a staged implementation may be suitable. For others a ―big bang‖ implementation – due to absolute equality may be appropriate. In reality however, we usually look at implementation according to pre-defined priorities. Consider the following options and then apply a suitable model to your own organization or case study.
STEPS
NOTES/ /RELEVANCE/DATES/ WHO
Define the Objective and Scope for Incident Management Establish and agree on a clear definition for the words ―Incident‖, ―Service / Support Request‖, ―Problem‖, ―Known Error‖ within the context of the process. This is one of the most interesting aspects. It can be very difficult to get everyone to agree to a definition, and it can be very difficult to establish the correct understanding of the definition. However, get this right, and the rest of the process is fairly easy. Seek initial approval Establish and Define Roles and Responsibilities for the process. Appoint an Incident Manager. Establish and Define Incident Categories and Service / Support Categories Establish Incident Management Process Establish and Define Relationship with all other processes. This is another key aspect of the Incident Management process. Incident Management will record all incidents that may pertain to any of the other processes. For example, Incidents resulting from Availability, Incidents resulting from Security, Incidents resulting from IT Service Continuity Management, Incidents resulting from Changes or Releases, etc. Page 174
Service Desk Workbook
Establish monitoring levels Define reporting standards Publicize and market The priority selection has to be made with other factors in mind, such as competitive analysis, any legal requirements, and desires of ―politically powerful influencers‖.
Costs The cost of process implementation is something that must be considered before, during and after the implementation initiative. The following points and table help to frame these considerations: (A variety of symbols have been provided to help you indicate required expenditure, rising or falling expenditure, level of satisfaction regarding costs in a particular area, etc.) Initial Personnel
During
Ongoing
Costs of people for initial design of process, implementation and ongoing support Accommodation Costs of housing new staff and any associated new equipment and space for documents or process related concepts. Software New tools required to support the process and/or the costs of migration from an existing tool or system to the new one. Maintenance costs Hardware New hardware required to support the process activities. IT hardware and even new desks for staff. Education Re-education of existing staff to learn new techniques and/or learn to operate new systems. Procedures Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel. Page 175
Service Desk Workbook
In most cases, costs for process implementation have to be budgeted for (or allocated) well in advance of expenditure. Part of this step involves deciding on a charging mechanism (if any) for the new services to be offered. Build the team
Each process requires a process owner and in most situations a team of people to assist. The Incident Management process is one of the processes in the Service Support set that shows very visible benefits from the outset and is very influential in setting the perception of IT Services to its customers and end users. Of course a lot will be dependant on the timing of the implementation and whether it is to be staged or implemented as one exercise. Analyse current situation and FLAG Naturally there are many organizations that have many existing procedures/processes and people in place that feel that the activities of Incident Management are already being done. It is critical to identify these systems and consider their future role as part of the new process definition. Examples of areas to review are:
Area
Notes
Power teams Current formal procedures Current informal procedures Current role descriptions Existing organizational structure Spreadsheets, databases and other repositories Other…
Implementation Planning After base decisions regarding the scope of the process and the overall planning activities are complete we need to address the actual implementation of the process. It is unlikely that there will not be some current activity or work being performed that would fit under the banner of this process. However, we can provide a comprehensive checklist of points that must be reviewed and done. Implementation activities for Incident Management Page 176
Service Desk Workbook
Activity
Notes/Comments/ Time Frame/Who
Review current and existing Incident Management practices in greater detail. Make sure you also review current process connections from these practices to other areas of IT Service Delivery and Support. Review the ability of existing functions and staff. Can we ―reuse‖ some of the skills to minimize training, education and time required for implementation? Establish the accuracy and relevance of current processes, procedures and meetings. As part of this step if any information is credible document the transition from the current format to any new format that is selected. Decide how best to select any vendor that will provide assistance in this process area (including tools, external consultancy or assistance to help with initial high workload during process implementation). Establish a selection guideline for the evaluation and selection of tools required to support this process area (i.e. Incident Management tools). Purchase and install tools required to support this process (i.e. Incident Management tool). Ensure adequate skills transfer and ongoing support is considered if external systems are selected. Create required business processes interfaces for this process that can be provided by the automated tools (e.g. reporting – frequency, content). Document and get agreement on roles, responsibilities and training plans. Communicate with and provide necessary education and training for staff that covers the actual importance of the process and the intricacies of the process itself. An important point to remember is that if this process is to be implemented at the same time as other processes that it is crucial that both implementation plans and importantly timing of work is complementary.
Cutover to new processes The question of when a new process actually starts is one that is not easy to answer. Most process activity evolves without rigid starting dates and this is what we mean when we answer a question with ―that‘s just the way it‘s done around here‖. Ultimately we do want the new process to become the way things are done around here, so it may even be best not to set specific launch dates, as this will set the expectation that from the given date all issues relating to the process will disappear (not a realistic expectation).
Page 177
Service Desk Workbook
INTRODUCTION
Welcome to this ―Clustered Practitioner Program‖ from The Art of Service. This program is fully accredited by the globally recognized accreditation agency for IT Service Management programs – EXIN. The program has been developed and accredited in accordance with guidelines provided by EXIN.
The ITIL Practitioner Support and Restore is intended for professionals who will participate in managing, organizing, and optimizing, the operations of the Support and Restore processes in an IT Service organization. Page 178
Service Desk Workbook
Typically such organizations will have implemented, or started to implement, elements of the ITIL Framework or may be looking to make improvements in these process areas.
The requirement to look at the provision of IT Services in a professional way is driven by a variety of factors. Organizations understand the benefits of having Information Technology (IT) throughout their structure. However, few realize the potential of truly aligning the IT department‘s objectives with the business objectives. More and more organizations are beginning to recognize IT as being a crucial delivery mechanism of services to their customers. The starting point for IT Service Management (ITSM) and the ITIL Framework is not the technology, not the processes; it is the organizational objectives.
Page 179
Service Desk Workbook
The IT Infrastructure Library is a set of books/CDs with best (good) practice processes on how to manage the provision of IT services. It is the ―process‖ part of the Service Management challenge (people, process and technology). The core set of material is the following set of tightly coupled areas:
Service Delivery
Service Support
Security Management
Business Perspective: The IS View on Delivering Services to the Business (Vol I)
Applications Management
ICT Infrastructure Management
Planning to implement Service Management
Software Asset Management
Page 180
Service Desk Workbook
OGC: Office of Government Commerce (the trademark owners of ITIL) APMG: In 2006 APMG won the tender to own the rights for accreditation and certification of the ITIL courses. EXIN and ISEB used to be independent bodies, but now sublicense through APMG. EXIN: Stichting EXameninstituut voor INformatica (Translation: Foundation for EXamination INformation Systems) ISEB: Information Systems Examination Board. This certification is recognized world wide! TSO: The Stationary Office Tool Vendors: (HP, Infra, Remedy, HEAT, etc…) provide technical solutions for customers trying to implement ITIL/IT service management. There is no such thing as ITIL certified tools. Only people can be ITIL certified.
continued… Page 181
Service Desk Workbook
ITSMF: (IT Service Management Forum) is the only internationally recognized and independent organization dedicated to ITSM. Accredited Vendors: (E.g. The Art of Service) only accredited vendors can provide ITIL training.
Page 182
Service Desk Workbook
GENERAL TERMS AND CONCEPTS
Page 183
Service Desk Workbook
Balanced score cards (BSC): One of the most common methods of measurement. This method uses the objectives of the organization or process to define Critical Success Factors (CSF‘s). Critical Success Factors (CSF’s): Are defined for a number of areas of interest or perspectives: customer/market, business processes, personnel/innovation and finance. Key Performance Indicators (KPI’s): The parameters for measuring progress relative to key objectives or CSF‘s in the organization. Process: A process is a logically related series of activities conducted towards a defined objective. Processes may define roles, responsibilities, tools, management controls, policies, standards, guidelines, activities and work instructions if they are needed. Process Owner: A process owner is responsible for the process results. Example: The owner for the Service Level Management Process
continued…
Page 184
Service Desk Workbook
Process Manager: A process manager is responsible for the realization and structure of the process, and the reports to the process owner. Function: A team or group of people and the tools they use to carry out one or more Processes or Activities. Functions provide units of organization responsible for specific outcomes. E.g. The Service Desk function is responsible for performing activities from the other ITIL processes including Incident Management, Event Management, Request Fulfilment etc. Vital Business Function (VBF): A function of a business process that is critical to the success of the business. Vital Business Functions are an important consideration of all ITIL processes.
More and more people see the importance of Processes. The Organizational Perspective issue ensures that we align the vision, strategy and goals of the business with the delivery of IT services. The People issue is without doubt where we – as IT Service Management professionals face our greatest challenges. Historically, the Technology considerations got most attention. Now we understand that without well defined processes we can often make inappropriate selections in this area.
Page 185
Service Desk Workbook
To impress stakeholders (e.g. customers, investors, personnel) your organization will have to communicate the ‗vision‘ and why they should do business with you, e.g. because you are the cheapest, the most reliable etc. The vision can be communicated in the form of a mission statement (see slide). The mission statement should be a short, concise description of the objectives of the organization and the values it believes in. The policy of the organization is the combination of all decisions and measures taken to define and realize the objectives. Implementing policies in the form of specific activities requires planning. Realization of the planned activities requires action. Actions are allocated to personnel tasks, or outsource to external organizations. There is a danger, that after time, the mission, objectives and policies will be forgotten by the organization. This why it is so important to measure at every stage of the organizations maturity, to ensure remedial action is taken when necessary.
Page 186
Service Desk Workbook
So if we accept that the objectives are the starting point for the provision of IT Services, how can we position the delivery of services and the utilization of the ITIL Framework. The objective tree is a very powerful tool not only in showing the benefit and alignment of IT and Service Management principals to the business, but also in being able to effectively sell the concepts as well. See if you can follow along in the following paragraphs and match the sentences to the above objective tree. To meet organizational objectives, the organization has business processes in place. Examples of business processes are sales, admin and financial departments working together in a ―sales process‖ or logistics, customer service and freight who have a ―customer returns process‖. Each of the units involved in these business processes needs one or more services (eg. CRM application, e-mail, word processing, financial tools).
continued… Page 187
Service Desk Workbook
Each of these services runs on IT infrastructure. IT Infrastructure includes hardware, software, procedures, policies, documentation, etc. This IT Infrastructure has to be managed. ITIL provides a framework for the management of IT Infrastructure. Proper management of IT Infrastructure will ensure that the services required by the business processes are available, so that the organizational objectives can be met.
The questions raised on the left hand side of this diagram arise constantly in the processbased approach typical of modern IT Service Management. The tools to answer these questions are shown on the right hand side of the diagram. The standards for the output of each process have to be defined in such a way that the complete chain of processes that meets the corporate objective, if each process complies with its process standard. If the result of a process meets the defined standard, then the process is effective. If the activities in the process are also carried out with the minimum required effort and cost, then the process is efficient. Processes are often described using procedures and work instructions.
Page 188
Service Desk Workbook
Elements derived from the OGC – Planning to Implement Service Management. GQM = Goals/Questions/Metrics The first and most important question that needs to be answered is whether the ―initiative‖ or adoption of a CSIP (Continuous Service Improvement Program) will deliver sufficient revenue/savings to justify the expense. The principle challenge is that much of the benefit cannot be quantified (e.g. quality, flexibility, service satisfaction). With regards to Risk Management we must remember that this initiative is not the only one competing for organizational budget. What is the effect on other initiatives if this IT initiative is successful at attracting funds? Also what risks will be faced after the program has begun? The salient point is that risks will always be present, so don‘t attempt to eliminate them – simply get to understand them. The Gap analysis is generally an opportunity to use ―scores‖ to measure current and future expected levels of maturity. For example a 5 level model of maturity is defined in the OGC ―Planning to Implement Service Management‖ text (Initial, Repeatable, Defined, Managed, Optimized).
Page 189
Service Desk Workbook
Elements derived from the OGC – Planning to Implement Service Management IT organizational maturity progresses through a variety of stages (Technology focus, Product/Service focus, Customer focus, Business focus, Value Chain). To move from one stage to the next requires management and control over people, processes, technology, steering, attitude and changing relationships between the business and the IT organization. IT process maturity is best measured by using an assessment tool for a more detailed analysis. A variety of such assessments can be carried out as ―self-assessments‖ as well as commercially available solutions. (Also discussed in the next slide)
Elements derived from the OGC – Planning to Implement Service Management Page 190
Service Desk Workbook
(notice some of the concepts raised by Kotter creeping through – the fundamentals are all the same). The starting point should not be determined on the emotions or ―feelings‖ of an individual. The starting point will be a combination of current maturity levels of the IT organization, the IT processes AS WELL AS – overall organization priorities, IT ―pain points‖, process interdependencies (eg. You cannot have Problem, without Incident Management) and other factors (including budget, available resources and current workloads). The most important aspect of the communication plan is that it needs to be ongoing and not just given enthusiastic support at the outset of the CSIP initiative. Under the banner of managing organizational change; it simply isn‘t enough to get a group of people together that have project management and ITIL skills and experience. There is a multitude of issues that have to be considered and addressed (including resistance, gaining and keeping commitment, involvement and communication).
continued… Cultural change is largely reflected in the leadership/management style that is prevalent/dominant in the organization. Remember that some organizations suit dominant leadership styles (e.g. Regimented organizations (such as military units)). Careful role definition is required (see later section on using the ARCI model), especially when considering the allocation of new activities to existing staff (overload) or the conflict that could arise when processes are implemented across traditional hierarchical models. As people are an integral part of the CSIP there is a need to provide appropriate levels of education. The critical element being timing of delivery. All too often we see education programs delivered only to witness a lack of follow up activity that gives the participant an opportunity to put the theory into practice.
Page 191
Service Desk Workbook
Finally, tools. The raging debate is which comes first. Tools or process? In reality, most organizations have a variety of IT Service Management tools already. It is not the place of this program to suggest that existing tools are a wasted investment, however, the commonly accepted principle is that the processes should be supported by the tools and not the other way around.
We need to use measures and metrics to help us determine a ―point of acceptance‖ with regard to process improvements and progress of the CSIP. CSFs are quite simply the things that we have to be able to do. They tell us in qualitative terms the basic objective for a process (eg. the CSFs for Change Management can be (a) a repeatable change process, (b) ability to deliver change quickly, (c) deliver organizational benefits via change management). KPIs can be considered the quantitative elements of a process that give us a guide to the process efficiency (eg. the KPIs for Change Management can be (a) the number of rejected RFCs, (b) the size of the change backlog, (c) quantity of changes delivered according to RFC schedule). Note that there are generally a lot more KPIs than CSFs for a given process. Organizational drivers are the points that are raised by ―business people‖ as their ―wish list‖ for the IT department. There have been many surveys conducted over many years, but the essence of what business people want from their IT departments can be condensed down into several points. These include support business operation, facilitate delivery of electronic
Page 192
Service Desk Workbook
services, and help to deliver business strategies, enable change to match pace with required business change.
Elements derived from the OGC – Planning to Implement Service Management Quick wins should be used to help drive more change that is medium to long term. Also consider what your legacy of change will be. Consider in 10 years time when all current staff have moved on or been replaced. When asked why certain activities are done the way they are – what will be the response? That is the way it’s done around here. Perhaps that could be considered a good legacy, provided that part of ―the way it‘s done around here‖ involves continual monitoring and reviews. The real essence of a CSIP is the first word of the acronym. Continuous! The way to create continuity is to go back to the start and begin again. Remember it begins with the VISION. The vision must essentially promote business and IT alignment. Knowledge management is another way to ensure the legacy of the work you do is not lost. The rate of change, staff turnover, expectations of performance and market place competition are all heading in an upwards direction. With these trends the organization cannot afford to retain knowledge and not learn from previous mistakes and lessons. The CSIP must include in its overall design elements consideration for the gathering, organizing and accessibility of data/information/knowledge.
Page 193
Service Desk Workbook
Most businesses are hierarchically arranged. They have departments, which are responsible for a group of employees. There are various ways of structuring departments, for example by customer, product, region or discipline. In this type of arrangement we often see that communication is ineffective.
A process is a logically related series of activities for the benefit of a defined objective. This slide illustrates cross functional process flows. The concept of processes ―linking‖ functional areas together can apply to business departments as equally as it can to IT functional areas.
Page 194
Service Desk Workbook
What is the Goal? To bake a cake! What are the inputs? The ingredients (eggs, milk, flour, sugar, butter, chocolate) plus equipment such as pans, mixers etc. What are the activities? Mix, pre-heat oven, bake, cool, decorate etc. What are the measures? How much ingredients, how long to bake, at what temperature etc. What are the norms? The recipe
What are the outputs? CAKE!!!!!!
continued… As we can see the basis of ITIL‘s approach to Service Management is on the interrelated activities.
Unlike a project a process is never ending Page 195
Service Desk Workbook
In this example, baking a specific cake (eg. a birthday cake for Jane) is a project.
The goals, activities, inputs, outputs, goals, measures and norms defined makes up the process for baking cakes.
The ARCI model helps show how a process actually does work end to end across several functional groups. A – Accountability (is made accountable for ensuring that the action takes place, even if they might not do it themselves). R – Responsibility (actually does the work for that activity but is responsible to the function or position that has an ―A‖ against it. C – Consult (advice / guidance / information can be gained from this function or position prior to the action taking place). I – Inform (the function or position that is told about the event after it has happened). General Rules
Only 1 ―A‖ per Row (ensures accountability, more than one ―A‖ would confuse this)
Page 196
Service Desk Workbook
At
least
1
―R‖
per
Row
(shows
that
actions
are
taking
place)
INTRODUCTION TO SUPPORT AND RESTORE PROCESSES
Introduction to Service Desk
Page 197
Service Desk Workbook
Service Desk Types: Relates to the skill level and resolution rate for service calls. Service Desk Organizational Structure: Relates to the physical organization of the service desk Incident: Any event which is not part of the standard operation of a service and which causes, or may cause an interruption to, or a reduction in the quality of that service. A failure of a CI that has not yet affected service is also classified as an incident. Service Request: Request for information or status of a service (not related to loss of service) Includes Standard Changes. Eg. Contact details, Service availability, request for common software. Page 198
Service Desk Workbook
Request for Change: Request to Move, Add, Change (MAC) Eg. Asking for changes to functionality of applications or supporting infrastructure. Access Rights: User or user groups permission rights to use a service, and the prevention of access to non-authorized users. Effectively the execution of both Availability and Information Security management, in that is enable the organisation to manage CIA of the organization‘s data and intellectual property.
Basically, there are three areas of required expertise for Service Desk staff: Technical skills for first line call resolution (unless it‘s a call center). Communication skills: listening, reasoning, negotiating, conflict resolution etc…Business understanding: in order to determine the effect of incidents, requests etc on the business – this one is usually understated. It is up to the organization to determine the focus of skills: how much technical etc? Question: ―What‘s the focus in your organization?‖ OGC recommends that a service desk member should be:
customer-focused
articulate and methodical
trained in interpersonal skills
multilingual (if required)
able to understand the business‘s objectives
Page 199
Service Desk Workbook
able to understand and accept that the Customer‘s problem affects the business, without the Customer there is no support department, the Customer is an expert in their own field
genuinely wanting to deliver a first-class service
team-focused
continued…
empathic with users
professional in their conduct
active listeners
willing to accept ownership
able to work under stressful situations.
Introduction to Incident Management
Page 200
Service Desk Workbook
Page 201
Service Desk Workbook
Incident: Any event which is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service. Service Request: Every Incident not being a failure in the IT Infrastructure. (Request for support, delivery, information, advice or documentation) Workaround: Used to restore agreed service operation, as quickly as possible. May use non-IT systems. Escalation: The mechanism that assists timely resolution of an Incident.
Introduction to Problem Management
Page 202
Service Desk Workbook
Page 203
Service Desk Workbook
Incident: Any event which is not part of the standard operation of a service and which causes, or may cause an interruption to, or a reduction in the quality of that service. A failure of a CI that has not yet affected service is also classified as an incident. Problem: Unknown underlying cause of one or more Incidents (The investigation) Known Error: Known underlying cause. Successful diagnosis of the root cause of a Problem, and a workaround or permanent solution has been identified KEDB: Known Error Database Workaround: Used to restore agreed service operation, as quickly as possible.
Page 204
Service Desk Workbook
SUPPORT AND RESTORE
Service Desk
Page 205
Service Desk Workbook
Other consideration for preparing to set up a Service Desk include:
The environment
Defining your services
Service Desk pre-Release requirements
Advertising and selling the Service Desk.
Page 206
Service Desk Workbook
Choosing quick wins should be based on what important to your customer and will yield a short-term service improvement and enhance customer perception. Quick wins are essential to obtain customer and business support during the initial phases of any service improvement project e.g.
Provision of faster response and standard requests
Enhancement of professionalism of the Incident registration and closure process
Keeping Customers better informed of progress
Allowing Customers to register and query their own requests
Publishing a Service Catalogue and User Handbook
Improving communications with the business
Development of better working relationships within the business
Reduced Incident –resolution times
Improvements to business reporting.
Page 207
Service Desk Workbook
Page 208
Service Desk Workbook
Page 209
Service Desk Workbook
When visiting a customer location, the same personalized service can be provided to confirm that you have attended, especially if the customer was not there at the time.
E.g. the Service Desk may act as a the focal point for Change requests from users, issuing Change schedules on behalf of Change Management, and keeping users informed of progress on changes. Change Management should therefore ensure that the Service Desk is kept constantly aware of change activities.
Page 210
Service Desk Workbook
Common structured interrogation technique: Providing a common structured dialogue to managing Customer requests is essential, no matter who in the support organization Page 211
Service Desk Workbook
responds to the Customer. The order in which questions and responses are required helps both the Customer and the support person to ensure nothing is forgotten. Using a common technique presents a professional and well structured organization to the Customer. Customer details and identification: Correct and unique Customer identification is essential to ensure that Customer details, existing requests and management information are uniquely and easily selectable. The more we know about our customer the more we can support them! Maintaining the Customer database: Maintaining a single source of Customer and supplier details is a major issue for many organizations, because they generally have several sources to deal with. A process should be defined for maintaining Customer, support staff and supplier details that answers all the relevant questions e.g. what needs to be stored? what are the sources and where are they stored? How do we consolidate them? How do we keep them up to date? Who maintains the master source?
continued… Marketing the Service Desk amongst Customers: Raising the profile of the support services, especially the Service Desk is critical to success. The Service Desk needs to attain its own identity in order to instill confidence and strengthen the Customer relationship e.g. invite customers to visit you computer training and support facilities, use advertizing materials etc.
Page 212
Service Desk Workbook
Page 213
Service Desk Workbook
Page 214
Service Desk Workbook
Every incident and request reported by the Customer should be registered, regardless of the time taken to find a solution. The actual elapsed time is not a measure of its importance or business impact. Every contact with the customer provides an invaluable metric to assist in the understanding of Customer requirements.
As there are different types of Service Desk, each having its own requirements, particular attention should be paid to selecting the right type and caliber of staff.
Page 215
Service Desk Workbook
Defining full time staffing levels is very difficult without a definitive way to predict the demand for service. All these items should be carefully considered before making any decision on staffing levels. This should also be reflected in the levels of documentation required. Remember that the better the service, the more business it will use.
Page 216
Service Desk Workbook
To deal with some of these staffing constraints, it is common to use ‗expert‘ Customers to deal with 1st line support Problems and queries: they are known as a Super User. With all requests entered into the main Service Desk tool, valuable usage details can be provided to the local management to ensure that resource is focused in the correct areas and not misused.
Page 217
Service Desk Workbook
Types of request that staff may be spending the most time on:
Equipment failures
Business application problems
Telecommunications
Customer queries
Installations/upgrades.
Types of request that may be taking the longest time to turnaround to the customer:
1st line support
2nd line internal support groups
3rd party support groups
Suppliers.
Which customers require the most support, and in which areas? This information can be used to develop training programs for both Customer staff and Service Desk and support staff.
Page 218
Service Desk Workbook
Computerizing the Service Desk will provide additional benefits, namely:
accessibility to all support staff and perhaps customers and users
the faster turnaround of Customer requests
request tracking, escalation and workflow is improved
better information is available in the form of online access to: o Known Errors, solutions and request histories o external knowledge sources
management information is more accessible and accurate
duplicate, lost or forgotten requests are reduced
skilled staff and resources are better used
complex support tasks and calculations are made easier
ITIL and business processes are automated
integration with other business processes and systems provides streamline IT management (e.g. service desk staff effort exported to organization‘s ERP systems).
Page 219
Service Desk Workbook
Some of the issues that will help you decide on build versus buy include the following.
Do you have the Service Management and business expertise to design: o integration with email and other communication systems? o automated operations? o cross-platform and multilingual support? o integration with other support tools such as Asset Management and Configuration Management, Change control and automated operations?
Do you have the resource, both now and in the future, to plan, implement, upgrade and maintain the system?
Who will support it, how long will it take to develop, who is going to pay for it, when will it be ready?
What if your ‗experts‘ leave?
Page 220
Service Desk Workbook
In conjunction with the business and process requirements, the technological requirements of the organization must be carefully considered. Poor performance by the tool may lead to staff frustration, who may bypass the tool in order to provide timelier incident resolution. This may eventually lead to a loss in the return on investment.
The use of intelligent phone systems and interactive voice recognition (IVR), voicemail and email can greatly benefit your Service Desk. It should however, not be used as an electronic barrier. The careful set-up of IVR systems is required so as to prevent the customer being passed around. Some customers of major organizations have become so frustrated with IVRs that ―IVR cheat sheets‖ have been published on the Internet. IT service providers should consider that some customers may contact the Service Desk by mobile phone, and call queuing will be expensive for the customer.
Page 221
Service Desk Workbook
If voicemail and email are used, it is imperative that they are reviewed regularly and responses sent promptly to those leaving messages. Put SLAs in place to maximize these technologies and ensure a consistent and high-quality service is maintained.
Page 222
Service Desk Workbook
Service Desk outsourcing considerations are as follows:
have the outsourcer use your Service Desk tool, not the other way round – often internal support staff are involved in the support process and you do not want to retrain them each time you change supplier
insist that you have complete access/ownership to management information at its source
make sure the supplier is capable of supplying suitably skilled and qualified Service Management staff for holiday and sickness cover
be sure to request details and previous experience of all supplied staff
continually monitor ‗value for money‘, deliverables and the business benefits derived
regularly check for supplier dependencies – ensure all procedures, functions and processes are clearly documented, up-to-date and available
make certain that the contractual terms, deliverables and chargeable activities are clearly understood and agreed by both parties
seek professional and specialist assistance when negotiating contractual terms with a supplier.
Page 223
Service Desk Workbook
continued… Vendor partnership You are buying a total solution and you should want your vendor to be a business partner. Utilize the vendor‘s expertise to help you implement any service-improvement project. A sign of a good working relationship between yourselves and a supplying organization is that it is hard to tell the contracted staff from the full-time employees, in terms of their commitment and understanding of the Customers needs. A professional vendor will seek a long-term relationship and repeat businesses in the form of additional product‘s upgrades, training and consultancy. Often buying the tool is the easy part; the costs of the software or other tools are generally the minority of the costs associated with an implementation project. Do not underestimate the cost of retraining your staff, the costs of changing procedures to maximize the benefits of the new tool, and the impact on Customers or secondary support organizations of the cost of expansion and additional software licenses.
Page 224
Service Desk Workbook
Depending on the incident being reported and detail required, further information may need to be obtained e.g. version number, supplier, software model, grouping etc. When an incident is completed, it is beneficial, for certain types of request, to enter a ‗closure classification‘ or ‗closure code‘. This should state the actual cause, a summary conclusion, or a specific course of action e.g.
Incident completed successfully
Customer training required
Documentation needs reviewed
No faults found
Monitoring required
Advice given
Change request needs to be raised.
Page 225
Service Desk Workbook
Page 226
Service Desk Workbook
Aligning Customer perception and satisfaction is paramount to the success of any support operation. It is customer perception that, in the end, defines whether the Service Desk is meeting their needs. Satisfaction surveys are an excellent method of monitoring Customer perception and expectation and can be used to monitor the function and identify improvement areas.
Page 227
Service Desk Workbook
Page 228
Service Desk Workbook
Reporting is often subjective and needs to be focused on business improvement. It is important that results are not just filed away but used as an essential business tool to justify, develop and continually improve the service.
The most valuable and expensive resource within the support operation is the staff. Optimizing staff utilization is of primary importance. Workload analysis can help determine staffing levels, when staff are needed, and how work patterns vary from day-to-day, or even week–to-week. Accurate support staff and 3rd party workload analyses need to take into account the complete request life-cycle and the time spent during each phase. For detailed analysis, support staff should enter the time they spend working on a request or any part of it. This slide gives an example of a single request, which took four hours to complete. In the given example, we may wish to know whether the 3rd party engineer exceeded his or her SLA, as well as the actual Customer Incident. In the same situation we may also wish to know how long a request may spend in a specific status, priority. Workload analysis is an important tool for identifying SLA and OLA target achievement.
Page 229
Service Desk Workbook
Incident Management
Page 230
Service Desk Workbook
If resources are not available to implement all Service Support processes at the same time, begin by implementing the Service Desk function together with Incident Management. This will result in ‗quick wins‘ and therefore acceptance of process implementation in general within in the IT organization and with Customers.
Page 231
Service Desk Workbook
Don‘t plan to implement and operate Incident Management in isolation. The scope of planning should be extended to include the implementation and integration and operation of all the Service Support Processes and function. If resources are not available to implement all Service Support processes at the same time, begin by implementing the Service Desk function together with Incident Management. This will result in ‗quick wins‘ and therefore acceptance of process implementation in general within the IT organization and with customers. Plan to create the Service Desk and to define Incident Management process at the earliest opportunity.
Page 232
Service Desk Workbook
The planning phase for Incident Management could last from 3-6 months for a sophisticated, extensive solution. The implementation phase could last from 3 months to 1 year, although implementation and improvement should be considered as an ongoing activity. Procurement of hardware and software can be time-consuming. Start selection procedures ASAP, based on seeking those that support the ITIL processes, and provide the required level of flexibility to allow for organization-specific needs.
continued… Keep closely linked systems, especially Configuration Management, in step. Plan for the creation of a CMDB and the conversion of existing equipment inventories. If no integrated Configuration Management system is in place, make this database part of the Incident Management system. Plan for interface with Problem Management system to assist Service Desk with recognizing and advising on Known Errors. If a system like this is scheduled for later implementation, using a paper-based system in the interim will be helpful.
Page 233
Service Desk Workbook
Page 234
Service Desk Workbook
Up to date CMDB: a prerequisite for an efficiently working Incident Management process. If a CMDB is not available, information about CI‘s related to Incidents should be obtained manually, and determining impact and urgency will be much more difficult and time consuming. Knowledge base e.g. problem/error database: should be developed to provide resolutions and work-arounds. This will greatly speed up the process of resolving Incidents. Third party known error databases should also be available to assist in this process. Effective automated system: is fundamental for Incident management and the success of the Service Desk. Paper-based systems are not really practical or necessary, now that good and cheap support tools are available. Close link with SLM: to obtain necessary Incident response targets. Timely Incident resolution will satisfy customer and users.
Page 235
Service Desk Workbook
Page 236
Service Desk Workbook
Page 237
Service Desk Workbook
Most SW vendors (HP, BMC, Infra, Goldmine) have applied ITIL flavour to their tools. This assists in linking to CMDB, SLAs etc… Page 238
Service Desk Workbook
Self help and self logging by users is also recommended for efficiency and effectiveness of the Incident Management process.
Page 239
Service Desk Workbook
Ownership, Monitoring, Tracking & Communication
Service Desk OWNS/accountable for ALL Incidents
Monitor progress, escalation of Incidents,
Advise user and IT management
Incident identification and Logging
Update/confirm Incident and user details Categorization, Initial Support, Prioritization (Most critical activity)
Categorize so the exact type of call is recorded e.g. Incident (Eg. Desktop, Network, Email) Assess urgency and impact to assign priority Match against existing Problems/Known Errors Match multiple Incidents and create new Problem record. Prioritization –taking into account the impact and urgency (how quickly to incident needs a resolution).
Page 240
Service Desk Workbook
continued… Investigation and Diagnosis
Assess the Incident details and provide workaround (if available)
Escalate to support areas (Functional) or IT management (Hierarchical)
Resolution and Recovery
Resolve the Incident or raise a RFC Incident Closure
Update details of actions taken and classification of Incident. Confirm closure with User
Page 241
Service Desk Workbook
Escalation is the human element of Incident Prioritization. It helps us identify incidents that may need to be moved up or down the priority list due to changing factors or priorities. ITIL defines two types of escalation. Functional: Based on knowledge or expertise
Also known as ―Horizontal Escalation‖
Based on knowledge or expertise.
Hierarchical: For corrective actions by authorized line management • Also known as ―Vertical Escalation‖ •When resolution of an incident will not be in time or satisfactory
Escalations can be combined.
Page 242
Service Desk Workbook
Page 243
Service Desk Workbook
Categorization is the unemotional/statistical aspect of prioritization IMPACT + URGENCY = PRIORITY!!!! Impact: Degree to which the user/business is affected Urgency: Degree to which resolution can be delayed
Page 244
Service Desk Workbook
A separate procedure, with shorter timescales and greater urgency, must be used for ‗major‘ incidents. The Problem manager should be alerted ASAP and will arrange a meeting with the relevant parties e.g. all key internal staff, vendor support staff and IT Services management, with the purpose of reviewing progress and determining the best course of action. A Service Desk representative should attend these meetings and ensure a there is a record of all actions and decisions made (ideally this will form part of the incident record)
Page 245
Service Desk Workbook
During Ownership, Monitoring, Tracking and Communication functional escalation can be performed to other solution groups (or hierarchical escalation) in order to reach decisions on the handling of the incident.
Page 246
Service Desk Workbook
Problem Management
Page 247
Service Desk Workbook
Page 248
Service Desk Workbook
Page 249
Service Desk Workbook
Good Problem Management relies to a great extent on an implemented and efficient Incident Management process. So it is sensible to implement Problem Management either in parallel with, or after Incident Management processes. If resources are scarce, it is advisable to concentrate in the first instance on the implementation of Problem and error control (reactive Problem Management). When these activities reach maturity, resources can be directed to proactive Problem Management. The quality of proactive Problem Management depends largely on successful implementation of service monitoring activities and the base data thereby captured. Smaller organizations can introduce reactive Problem Management by focusing daily on the ‗top ten‘ Incidents of the previous day. This can prove to be effective, since experience shows that 20% of Problems cause 80% of service degradation!
Page 250
Service Desk Workbook
Page 251
Service Desk Workbook
An effective automated registration of Incidents. With an effective classification, is fundamental for the success of Problem Management.
Setting achievable objectives and making use of the Problem -solving talents of existing staff is a key activity. Consider ‗part-time‘ Problem Management, whereby staff set side periods when they will look at Problems away from the daily fire-fighting pressures.
In view of the potentially conflicting interests between Incident Management and Problem Management good cooperation between both processes is essential. Both also have enormous synergy, which can help.
Page 252
Service Desk Workbook
Disseminating this information is the primary task of the Service Desk. Problem Management should provide sufficient information and support to the Service Desk for this task. Relevant information can be distributed by Problem Management to the Service Desk and the support organization by feeding this information into existing Service Management tools and databases.
Page 253
Service Desk Workbook
It is recommended that the Service Desk Manger and the Problem Manger roles are not combined because of the conflicting interests inherent in these roles. Page 254
Service Desk Workbook
Page 255
Service Desk Workbook
Most SW vendors (HP, BMC, Infra, Goldmine) have applied ITIL flavour to their tools. This assists in linking to CMDB, SLAs etc… Self help and self logging by users is also recommended for efficiency and effectiveness of the Incident Management process.
Page 256
Service Desk Workbook
This slide illustrates how the Service Desk, Incident, Problem and Change Management can be connected. This shows just one example of the actions taken when a user reports an Incident to the Service Desk.
Page 257
Service Desk Workbook
Reactive Problem Control is concerned with identifying the real underlying causes of Incidents in order to prevent future recurrences. The three phases involved in the (reactive) Problem control processes are:
Problem identification and recording
Problem classification – in terms of the impact on the business
Problem investigation and diagnosis.
When the root cause is detected the error control process begins.
Page 258
Service Desk Workbook
It should be noted that some Problems may be identified by personnel outside the Problem Management team, e.g. by Capacity Management. Regardless, all problems should be notified and recorded via the Problem Management process. Much of the Availability Management process is concerned with the detection and avoidance of Problems and Incidents to the IT Infrastructure; a synergy between the two areas is thus an invaluable aid to improving service quality. Problem records need to be recorded in a database (CMDB) and are very similar to Incident records. The solution and workarounds of Incidents should be recorded in the relevant Problem records for others to access should other related Incidents occur.
Page 259
Service Desk Workbook
The objectives of Problem investigation frequently conflict with those of Incident resolution. E.g. Problem Investigation may require detailed diagnostics data, which is available only when an Incident has occurred; its capture may significantly delay the restoration of normal services. It is essential that Problem Control liaise closely with Incident control and the computer operations or network control functions to get a balanced view of the right time for such actions.
Page 260
Service Desk Workbook
Many IT departments are concerned with error control, and it spans both the live and development environments. It directly interfaces with, and operates alongside, Change Management processes.
Page 261
Service Desk Workbook
Tips on error control:
Not all known errors need to be resolved.
Preparing an RFC is one of the responsibilities of error control.
Consider creating standard error records e.g. by specific CI, or by device category, for routine hardware failures.
The rectification of many hardware faults is carried under Incident control, and not via error control and Change Management.
Ideally, common tools should be used for Incident, Problem and error control in live and development environments.
In practice, the level of detail usually required for development Configuration Management often precludes a viable shared system.
Page 262
Service Desk Workbook
Errors found during live operations are identified and recorded during the Problem Control activity – investigation and diagnosis. The Problem records form the basis of the Known Error record. Errors found during the development activity are likely to include known, but unresolved, errors from the development phase. The data relating to Known Errors, from development, needs to be made available to the custodians of the live environment when an application or a Release package is implemented. The Problem Management system should provide a record of all resolution activity and provide monitoring and tracking facilities for support staff. It should also provide a complete audit trail navigable in either direction, from Incident to Problem to Known Error to Change Request to Release.
Page 263
Service Desk Workbook
This data is then available for Incident matching, providing guidance during future investigations on resolving and circumventing Incidents, and for providing management information.
Consideration should be given to inserting into the process an interim status, on the Incident, Known Error and Problem records, of ‗Closed pending PIR‘ to ensure that the fixes have actually worked. PIR: For Incidents, this may involve nothing more than a telephone call to the user to ensure that they are now content. For more serious and Problems and Known Errors, a formal review may be required.
Page 264
Service Desk Workbook
Trend Analysis: Using Incident and Problem analysis reports Pro-active Problem Management can identify:
Trends, such as the post-Change occurrence of particular Problem types.
Incipient faults of a particular type.
Recurring Problems of a particular type or with an individual item.
The need for more Customer training or better documentation.
Analysis of Problem Management data may reveal:
That problems occurring on one platform may occur on another platform.
The existence of recurring Problems.
Targeting Preventative action: Once Trend Analysis has identified faults within the IT Infrastructure, focus can be given to Problem areas that need the most attention.
Page 265
Service Desk Workbook
continued… Problem Management should initiate appropriate actions:
Raising an RFC
Provide feedback regarding testing, procedures, training and documentation
Initiating customer education and training
Initiating service support staff education and training
Ensure adherence to Problem Management and Incident Management procedures
Process or procedural improvement
Tips on proactive Problem Management:
Added value of trend analysis in CI robustness is rather limited until sufficient historical data has been accumulated.
Engineering reports from many manufacturers‘ operating systems provide information on inherent Problems. These reports should be examined on a regular basis to identify potential hardware Problems before they occur.
Proactive Problem Management does not necessarily need to be a full-time task.
Page 266
Service Desk Workbook
Page 267
Service Desk Workbook
In addition to Management reports, periodic audits of all operations and procedures should take place. These audits are intended to confirm that the Problem Management and support teams are adhering to defined procedures. These audits will include analysis of major problem reviews.
Reports are produced and analyzed according to the agreed schedule.
A representative sample of Incidents to verify that related Problems have been correctly identified and recorded.
A representative sample of Problems to verify that Problems are diagnosed correctly by authorized Changes to CI‘s and within the prescribed period.
A representative sample of Known Errors, to verify that Known Errors are cleared by authorized Changes to CI‘s and within a prescribed period.
Thresholds for escalation are adhered to Page 268
Service Desk Workbook
A representative sample of records, for correctness and completeness.
Documentation is being maintained correctly - updates being distributed by Problem Management staff and executed recipients.
Management reports are produced regularly and are meaningful.
Evidence of trend analyses and the identification of preventative actions.
Staff training records.
This slide illustrates how the Service Desk, Incident, Problem and Change Management can be connected. This shows just one example of the actions taken when a user reports an Incident to the Service Desk.
Page 269
Service Desk Workbook
SERVICE DESK – REVIEW
Page 270
Service Desk Workbook
Page 271
Service Desk Workbook
Page 272
Service Desk Workbook
INCIDENT MANAGEMENT – REVIEW
Ownership, Monitoring, Tracking & Communication
Service Desk OWNS/accountable for ALL Incidents
Monitor progress, escalation of Incidents,
Advise user and IT management
Incident identification and Logging
Update/confirm Incident and user details Categorization, Initial Support, Prioritization (Most critical activity)
Page 273
Service Desk Workbook
Categorize so the exact type of call is recorded e.g. Incident (Eg. Desktop, Network, Email) Assess urgency and impact to assign priority Match against existing Problems/Known Errors Match multiple Incidents and create new Problem record. Prioritization –taking into account the impact and urgency (how quickly to incident needs a resolution).
continued… Investigation and Diagnosis
Assess the Incident details and provide workaround (if available)
Escalate to support areas (Functional) or IT management (Hierarchical)
Resolution and Recovery
Resolve the Incident or raise a RFC Incident Closure
Update details of actions taken and classification of Incident. Confirm closure with User
Page 274
Service Desk Workbook
This slide acknowledges that there will be issues. There always will be – to think otherwise is naïve.
Page 275
Service Desk Workbook
Page 276
Service Desk Workbook
This slide illustrates how the Service Desk, Incident, Problem and Change Management can be connected. This shows just one example of the actions taken when a user reports an Incident to the Service Desk.
Page 277
Service Desk Workbook
PROBLEM MANAGEMENT – REVIEW
Reactive Problem Control is concerned with identifying the real underlying causes of Incidents in order to prevent future recurrences. The three phases involved in the (reactive) Problem control processes are:
Problem identification and recording
Problem classification – in terms of the impact on the business
Problem investigation and diagnosis.
When the root cause is detected the error control process begins.
Page 278
Service Desk Workbook
Tips on error control:
Not all known errors need to be resolved.
Preparing an RFC is one of the responsibilities of error control.
Consider creating standard error records e.g. by specific CI, or by device category, for routine hardware failures.
The rectification of many hardware faults is carried under Incident control, and not via error control and Change Management.
Ideally, common tools should be used for Incident, Problem and error control in live and development environments.
In practice, the level of detail usually required for development Configuration Management often precludes a viable shared system.
Page 279
Service Desk Workbook
Trend Analysis: Using Incident and Problem analysis reports Pro-active Problem Management can identify:
Trends, such as the post-Change occurrence of particular Problem types.
Incipient faults of a particular type.
Recurring Problems of a particular type or with an individual item.
The need for more Customer training or better documentation.
Analysis of Problem Management data may reveal:
That problems occurring on one platform may occur on another platform.
The existence of recurring Problems.
Targeting Preventative action: Once Trend Analysis has identified faults within the IT Infrastructure, focus can be given to Problem areas that need the most attention.
continued… Problem Management should initiate appropriate actions:
Raising an RFC
Provide feedback regarding testing, procedures, training and documentation
Initiating customer education and training
Initiating service support staff education and training
Ensure adherence to Problem Management and Incident Management procedures
Process or procedural improvement
Tips on proactive Problem Management:
Added value of trend analysis in CI robustness is rather limited until sufficient historical data has been accumulated Page 280
Service Desk Workbook
Engineering reports from many manufacturers‘ operating systems provide information on inherent Problems. These reports should be examined on a regular basis to identify potential hardware Problems before they occur.
Proactive Problem Management does not necessarily need to be a full-time task.
It is always good to balance the general benefits and positive theoretical discussions that surround the ITIL processes. This slide acknowledges that there will be issues. There always will be – to think otherwise is naïve. So use this slide as a discussion point about the likelihood of these issues arising. See if you can draw on any participants experiences.
Page 281
Service Desk Workbook
Page 282
Service Desk Workbook
Page 283
Service Desk Workbook
ASSIGNMENTS Assignment 1 – Service Desk You will complete the following tasks relating to the Service Desk over the course of the day, culminating in a presentation that will summarize your knowledge. You will need to use the associated case study in responding during these tasks and for the final presentation. Task a) Prepare and deliver a presentation outlining information flows between the Service Desk and the Service Support processes. Relate your presentation to the case study. Your audience will be Managers from the business organization. Supplement the presentation with a fact sheet that explains the relationships. Task b) Design templates to be used for customer communications in the following situations:
Incident/Service Request confirmation
General correspondence e.g. incident progress reports, further information required etc
Physical attendance e.g. when the customer was not present.
Task c) Presentation Acting as an external consultant, you are required to deliver a presentation to the CIO and managing directors who are considering implementing a Service Desk. Your presentation will need to include:
What are the goals of the Service Desk?
What are the activities that are performed?
Who will be involved?
What are the benefits that would be delivered to the organization?
What challenges may be faced and how would these be overcome?
Conclusion.
Formal memo to Financial Controller – detailing the cost benefits.
Assignment 2 – Incident Management You will complete the following tasks relating to Incident Management over the course of the day, culminating in a presentation that will summarize your knowledge. You will need to use the associated case study in responding during these tasks and for the final presentation.
Page 284
Service Desk Workbook
Task a) Prepare and deliver a presentation outlining how Incident Management will interface with the Service Delivery processes. Your audience will be Service Delivery Process Managers. Supplement the presentation with a factsheet that explains the relationships. Task b) Present a concise explanation of on the activities of the Incident Management process. Your audience will be Managers from the business organization. Supplement your presentation with handout notes. Task c) Acting as an external consultant, you are required to deliver a presentation to the CIO and managing directors who are considering implementing Incident Management. Your presentation will need to include:
A brief description of Incident Management
What are the goals of Incident Management?
What are the activities that are performed?
Who will be involved?
What are the benefits that would be delivered to the organization?
What challenges may be faced and how would these be overcome?
Conclusion.
Formal memo to Financial Controller – explaining cost benefits.
Task d) You are the Incident Manager and have received feedback that customers are concerned about the following issues with Incident Management:
Lack of communication
Service Desk reputation: bad attitude
Failure to explain/justify the use of resources.
Using the case study, prepare a written response, explaining how you intend to address each issue.
Assignment 3 – Problem Management You will complete the following tasks relating to Problem Management over the course of the day, culminating in a presentation that will summarize your knowledge. You will need to use the associated case study in responding during these tasks and for the final presentation. Task a) Prepare and deliver a presentation outlining how Problem Management will interface with the Service Delivery processes. Your audience will be Service Delivery
Page 285
Service Desk Workbook
Process Managers. Supplement the presentation with a factsheet that explains the relationships. Task b) A Major Problem Review is required. Using the case study, write a memo inviting relevant members of the organization to attend (you will need to clarify why their attendance is required). You will also need to include a detailed agenda for this meeting. Task c) Acting as an external consultant, you are required to deliver a presentation to the CIO and managing directors who are considering implementing Problem Management. Your presentation will need to include:
A brief description of Problem Management
What are the goals of Problem Management?
What are the activities that are performed?
Who will be involved?
What are the benefits that would be delivered to the organization?
What challenges may be faced and how would these be overcome?
Conclusion.
Formal memo to Financial Controller – explaining cost benefits.
Task d) Create a plan for the concurrent implementation of the Support and Restore processes. Present to Senior IT Management.
Page 286
Service Desk Workbook
ASSIGNMENT RESOURCES
Case Study – RECE Shoe Company
Business Case Study RECE Shoe Company Global Conglomerate ITIL Practitioners Case Study V1.0
Introduction Rece Couture Shoe Company of London, England, is a privately owned shoe company, founded in 1994.
Rece has grown rapidly to become one of the leading shoe retailers of the world.
During recent years Rece has expanded substantially to reach in 2004 the third most favoured designer shoe label. The company has also expanded the product line with the introduction of an accessory line. Such spectacular growth has been achieved internally and not through acquisition or merger. Rece is a company that has major operations centres in New York, Paris, Milan, Hong Kong and Melbourne, as well as 150 retail outlets worldwide (Rece stores and concessions in major department store locations). In addition, Rece operates an online store with the capacity to accept in excess of 5000 online orders per day.
Rece provides an unparalleled service network via dedicated own offices throughout the world and remains a truly independent and private Company able to respond quickly to market changes and implement long term plans, without unnecessary interference or delay.
With a streamlined management structure in London, England, Rece has become a leading Page 287
Service Desk Workbook
customer focused and cost effective global retailer, their first class craftsmanship is favoured by international stars and elegant women worldwide. Officers & Employees
CEO: Claire Enever (co-founder and president) Creative Director: Angela Miller Group Managing Director, Finance and Administration: Paul J. Rizzo, Group Managing Director, Commercial and Consumer: Bernard Scholl Group Managing Director, Retailing Business Solutions: Cecile Yelland Group Managing Director, International Shipping: Anton Chirac Group Managing Director, Employee Relations: Rebecca Cartwright Group Managing Director, Network and Technology: Anwar Sadat Group Managing Director, Sales and Marketing: Steve Birch Group Managing Director, Press and Public relations: Carla Scott Group Managing Director, Convergent Business: Rachael Alfonsin Group Managing Director, Legal and Regulatory: Pien Ch'iao 2007 Employees: 13,840 1-Year Employee Growth: (7.7%)
Headquarters: Level 42, 76 Oxford Street, London, England
Vision Rece vision is to enhance its position as the leading designer shoe design and retailer in the world. To realise this vision and prepare for competition, Rece has adopted a four-part growth strategy, entailing: Optimising returns from the ‗classic‘ products and services throughout the world Developing and delivering value-added services via an online interface and extended accessories line. Transforming our corporate culture and improving productivity Extending our global scope The Rece Organization The organization is virtually identical at each of the head offices. For example, each head office will have the following departments: Page 288
Service Desk Workbook
Marketing and Sales Design and Manufacturing Retailing and Logistics Shipping and distribution Customer Services Maintenance Legal Accounts Department Human Resources ICT Department Each manager for the listed departments will report directly to the director of that that local office. The CEO of the company and her managing directors are located in Head Office in London, England. Logistics The logistics department‘s main responsibility is to ensure that all goods being shipped by sea or land are loaded to the appropriate carrier. This is to ensure that Rece can fulfil their obligations regarding paid orders from their customers. The logistics department works very closely with both the Sales and the Manufacturing departments. The logistics departments will organise the loading and consignment of the goods, but it needs to also ensure that appropriate crews have already been notified and that there is an availability of transport. The Sales, Manufacturing and Logistics departments work closely together. As a result of the complexity of the relationship a number of business process issues can arise. In the event that it becomes difficult to ascertain the nature or the solution for the issues, the Logistics department will be given priority to manage the issue to resolution. The Logistics department will therefore have the final authority in these decisions. Maintenance The Maintenance department is responsible for maintaining and stocking the necessary parts for both road and air transport. The primary objective is being responsible for the state of repair of the delivery road vehicles. Rece operates a number of large container workshops around the world, so that maintenance can be carried out more efficiently. Sales
Page 289
Service Desk Workbook
The sales department is responsible for obtaining orders for international company chains and stores requiring Rece concession stock. They are also responsible for the online orders made via the Rece website. Rece operates a total of 350 dedicated sales offices across the entire globe, and employs approximately 8,000 sales staff. Because of such a large volume of people each regional head office will have a Sales Director which will look after the sales offices within that region. Accounts Department The Accounts Department takes care of the head office's financial accounts, including the management of the accounts payable and accounts receivable ledgers. The Accounts Department also takes care of the payment of salary to staff members and any contractors. There will also be small Accounts Departments at each key location across the globe. The managers of these departments will report directory to the manager at the head office for that region. As a general rule, there is not more than four Accounts Departments per region. The Accounts Departments work very closely with the Sales Departments. The Sales departments will interface into the computer systems controlled by the Accounts Department. Human Resources The Human Resources department is the department, involved in the recruitment, selection and discharge of personnel and in human resource management. For example, each head office employs a company doctor and a psychologist, who provide medical and mental assistance to employees.
Rece sees this function as being critical to their organization. Sales, Design and some Manufacturing staff are required to travel on a regular basis, sometimes at short notice for extended periods of time. This can place a serious strain on staff and their families, and as a result Rece wishes to ensure the well being of its staff members as it is recognises that they are integral to the organization. Rece does this through medical and mental assistance programs, and by offering generous product discount and annual leave packages. ICT Department Each head office around the world employees a small team of IT personnel to help deliver and support IT Services for their specific regions. For all intents, these groups run fairly autonomously, having their own support teams, including their own Service Desks. However, in London, there is a central ICT Department that provides IT Support for all the store and online requirements. Page 290
Service Desk Workbook
The Rece information systems
General The computerisation of Rece‘s information systems has not been fully completed at this stage. However, there are certain aspects that can be considered fairly mature. A large part of the financial accounts of the entire Rece organization have been computerised. Due to the geography that exists between the various head offices, there had been identified a need for a virtually identical computerisation standard at these offices. However, unfortunately a large part of the handling of orders and planning processes has not been as well computerised as possible. This is generally due to local constraints being enforced by the relevant government organizations within the various regions that Rece operates. Resolution of this is being seen as a key aspect of the success of the Rece organization. Systems
FINANCE is the information system used by the Accounts Department to prepare financial reports. FINANCE contains modules for accounts receivable, accounts payable, salary records and book keeping. After an order is completed, the relevant invoices are created automatically. The payments to suppliers of shipping and payments to providers of specialist maintenance are also made by means of this system. Due to the need for various head offices to comply with the local laws regarding finances, the FINANCE system has evolved to be the most diverse system in the organization, being virtually different at each head office. PAYPOINT is the companies‘ point of sale system. This is ready for an up date. The technology being used is out of date and not to the standard represented by the company, who want to be state of the art but at the right cost! STOCK is the Rece Inventory Management system. It holds list of goods and materials themselves, held available in stock by the business. The inventory is held in order to manage and hide from the customer the fact that manufacture/supply delay is longer than delivery delay, and also to ease the effect of imperfections in the manufacturing process that lower production efficiencies if production capacity stands idle for lack of materials.
Page 291
Service Desk Workbook
FOCUS is the companies CRM system that manages their relationships with customers, including the capture, storage and analysis of customer, vendor, partner, and internal process information. There are three aspects to the FOCUS system:
Operational - automation or support of customer processes that includes the company sales or service reps
Collaborative - direct communication with customers that does not include the company sales or service reps
Analytical - analysis of customer data for a broad range of purposes
Currently the third aspect of Analysis is not used effectively. General Systems
There is also a general suite of applications, mainly Microsoft, with some Lotus Notes, which includes an e-mail, word processor, spreadsheet application, appointment calendars & scheduling software and the Human Resources applications. These suites of applications are offered via local networks. The links between local networks and the links between desktop computers are completely transparent to the users.
This software is stored centrally on the main servers within the ICT Department in London, which allows remote users to download them as needed. However, each head office around the world, local versions are kept as this allows for easier management of the local standard operating environments. Hardware
Each of the head offices uses a series of UNIX based servers for capturing and recording their information. These servers have direct data links back to the head office in London, where the information is then stored on a central mainframe. The mainframe is equipped with disk and tape storage facilities. However, across the organization the network structure is fairly similar at each of the head offices. This allows for easier deployment of applications across the entire organization.
Additional Infrastructure Information
Page 292
Service Desk Workbook
The wide area network has been outsourced. The outsourcer in this situation is managing and coordinating the leasing of the necessary network infrastructure. The outsourcer is responsible for providing monitoring information regarding the availability of the wide area network. The cost of the organization maintaining the WAN infrastructure was considered too great. However, recently it is being seen by the organization that the infrastructure may not be as stable as proposed and are looking at the IT Departments to manage this in a more structure manner. This has resulted in incomplete transactions being fed back into the central mainframe, potentially costing the organization millions of dollars. IT Organization
Due to the diverse nature of Rece, there are a number of IT Departments. However, policy and objectives for IT are created and managed from the London office. London is seen as the central IT Department. However, autonomy is provided to the other head offices to manage, deliver and support IT Services as they need. As such, each head office has a Chief Information Officer (CIO), who reports into the Group Managing Director, Network and Technology. All CIO‘s have a monthly video conference call, with a bi-annual face to face meeting. At the bi-annual meeting, strategy and policies for Information Services and Information Technology are discussed and agreed upon. This meeting is chaired by the Group Managing Director, Network and Technology. In addition to this, there are regular consultations between the head offices regarding technical matters. Telephone and e-mail are the means most commonly used for this with the occasional video conference. There is however a general consensus amongst the senior IT Managers that the IT functions within Rece could probably contribute more to the business objectives of the company. However, they still all agree that in general terms the deployment and organization of its IT resources is reasonably good:
Communication internationally is regular with good information and results
Head Offices are communicating well
The technical infrastructure has been extensively documented by each head office
London
Page 293
Service Desk Workbook
London uses a Fujitsu 8500 series mainframe as its central computer. The mainframe serves as a way of centralizing all the data from the other various head offices. The mainframe has approximately 3000 GB of disk storage. Due to the large nature of the organization, it was determined that there also needed to be a development mainframe, although scaled down in size. At this stage the organization does not have a testing mainframe and as such, most of the testing is carried in the development environment. The remote head offices can access the mainframe via deployed client applications and for some specific uses, via the World Wide Web. Sales Offices
The following IT components have been installed at each local sales office:
Personal Computers
Operating System: Windows 2000
No CD ROMs
No Floppy Disk Drives
Pentium III – 500Mhz
At least 1 Server –
Operating System: Windows 2000 Server
This allows individual sales offices to enter shipping orders into the system, as well as create and distribute information via email for their local regions. This is seen as a key aspect, as each sales office is responsible for generating their revenue. General – Other Head Offices At certain times and for certain parts of the infrastructure, development and maintenance of this is contracted out to various suppliers with whom a maintenance agreement has been signed.
At this stage Rece does not have any reciprocal arrangements with any other company in the event of a disaster. The IT Organizational structure of each of the head offices is as follows:
Regional IT Manager – Overall Manager for the specific region
Network Manager - Local Area Network infrastructure
Project Manager - who is responsible for testing and co-ordinating any modifications to the systems and solving small problems Page 294
Service Desk Workbook
Service Desk - manager specialising in the management of the service desk representatives and dealing with IT Incidents
Desktop Manager – responsible for managing co-ordinating the roving engineers.
Change Control Co-ordinator
In addition to this, there is a group of roving engineers who travel their local region and are trained to solve the most commonly occurring problems independently. If he/she is unable to do this, the head office is contacted. The call will then be routed through to the local head office, if resolution is not possible then the assistance of suppliers who are able to solve the problems are called in. Issues to be considered. A. The relationship between the IT organization and the Business is strained. Customers and Users are complaining that they are unsupported by the IT Staff. Incidents that are reported are not recorded and there is little or no follow up. Users claim that they have to continually call the Service Desk to find out what, if any, progress has been made, and that they never get to speak to the same person twice which means they have to repeat the details of their incident report. It is also widely reported that the Service Desk are consistently rude and unfriendly in person and over the telephone. The feedback from the Service Desk is that they are under-staffed and unable to meet the current demand. They explain that this has had negative affects on staff morale and attitude. There is a high turn over of Service Desk staff, which has led to an inconsistent training and development. Several requests for new staff have been refused by senior management who believe that the Service Desk are not managing their resources appropriately and are unable to justify the additional need for staff. B. Last week Rece lost the use of STOCK, the stock inventory system for 3.5 hours. The system went down at 8.05 am. During this time new orders could not be taken, existing orders could not be filled, the manufacturing department where unable to order sufficient materials and staff where overwhelmed with customer complaints and queries. This was not considered a ‗disaster‘ situation as the SLA states the system would have to be down for 4.5 hours before IT Service Continuity Management takes over. It has been decided to conduct
Page 295
Service Desk Workbook
a major problem review in order to improve the IT department‘s delivery and support of the STOCK system.
Page 296
Service Desk Workbook
EXAM PREPARATION QUESTION 1 A small organization has limited numbers of staff that can take on process ownership roles and as such there has been some discussion about who in the organization can take on the roles of Incident and Problem manager. Which of the following statements is incorrect regarding such a situation? a) The Problem Manager and Service Desk manager roles can be combined b) The Incident Management and Problem Management roles can be combined c) The Service Desk Manager and Incident Management process owner can be combined QUESTION 2 An upgrade to an existing application has been released across the organization. The upgrade was not properly tested. When all the staff come in for work after the weekend they are unable to get access to the new application. Which process will first notice the effect of this? a) Incident Management b) Problem Management c) Service Desk QUESTION 3 Of the following, what is the best example of a service request? a) Upgrade to accounting application b) Moving a server to a location c) Granting a user access to a common application QUESTION 4 While reviewing Incident and Problem records, it is found support groups have not adhered to the escalation thresholds. These thresholds were established based on the Service Levels agreed with the customers. When questioned, support groups state the escalation thresholds are too short and/or not reasonable timeframes. As a result, the support groups request more time before the event is escalated (e.g., increase the escalation threshold). Which one of the following is the most effective improvement option to ensure adherence to the escalation thresholds? Page 297
Service Desk Workbook
a) Renegotiate the OLA to tie the performance of OLA to annual bonus pay b) Improve the escalation process and procedures c) Renegotiate the SLA to allow for more relaxed escalation thresholds QUESTION 5 Which of the following terms conveys the degree to which an incident leads to a departure from the normal service level? a) Impact b) Escalation c) Urgency QUESTION 6 The main reason not to outsource a Service Desk is that: a) The Service Desk staff are not located in the same location as the users b) The external Service Desk staff have no feeling of ownership for the calls c) Quality support requires intellectual capital of an organization, that cannot be easily transferred QUESTION 7 Which of the following is NOT a skill required of Service Desk staff? a) Programming Skills b) Customer Service Skills c) Technical Knowledge QUESTION 8 Which Key Performance Indicator is important for determining the added value of the Problem Management process for the Service Desk? a) The number of RFCs for error resolution b) The number of structural errors in the infrastructure that have been resolved c) The number of closed Problems QUESTION 9 Users who work with the Payroll System have problems with printing: no prints are produced. The workaround offered is that one must first break off the session before the prints roll out. An RFC has been submitted for a structural solution that ensures that in the Page 298
Service Desk Workbook
new Payroll module, a time-out of 10 seconds is set as standard. In this phase of the Problem process, what must be fed back to the Service Desk? a) What is the cause of this Problem and how it must be solved b) Which information they should give to the users c) How the Service Desk can recognize and solve Incidents related to this Problem QUESTION 10 Which of the following is not a responsibility of the first line Service Desk staff? a) Solving all service requests and tracking cost per incident for management reporting b) Incident registration and initial support c) Closure of incidents and solving incidents not routed QUESTION 11 Within ITIL the Service Desk is also referred to as which of the following? a) First line support b) First Point of contact c) Single Point of contact QUESTION 12 Setting up a Service Desk requires a lot of thought regarding the benefits that will be delivered to the organization. Delivering benefits comes from understanding the critical success factors (CSF). Which is not a CSF of the Service Desk? a) Goals and deliverables are clearly identified b) Improved user and customer satisfaction c) Business needs are understood d) Investment is made for training Service Desk staff and support teams QUESTION 13 The Service Desk has received a call regarding the release of an application. The error being received by the end user is "Unable to process request, incorrect string entered" What would be the most likely reason for these calls? a) Release roll back required b) End user training required c) Problem to be resolved Page 299
Service Desk Workbook
QUESTION 14 The Service Desk manager is conducting an information session regarding the implementation of a local Service Desk. The Manager explains that the following are considerations for establishing a local Service Desk. 1. Making localized skills available to other local service desks. 2. Using the same escalation procedures across all locations. 3. Using common reporting metrics. From the following list which would you select as another consideration? a) Discouraging the ‗super user‘ from providing local support b) Providing training in learning the cultural differences for International organizations c) Creating commonality in top level request classifications QUESTION 15 Which of the following is NOT a function of a Service Desk? a) Tracing the underlying cause of incidents b) To maintain ownership of an Incident from discovery to closure c) To act as an interface for Service Management activities such as Change Requests QUESTION 16 Critical Success Factors (CSF) and Key Performance Indicators (KPI) can provide very useful information. One of the critical success factors for the Incident Management process is to "resolve Incidents quickly". To support this critical success factor many KPIs can be used. Which of the following KPIs will be most useful to help you demonstrate the good performance of the Incident Management process? a) Percentage reduction of Incidents incorrectly categorized b) Percentage reduction in average time to respond to a call for assistance from firstline c) Reduced mean elapsed time for resolution or circumvention of Incidents, broken down by category and priority QUESTION 17 An incident is not resolved following the initial support offered by the first line of support. What step should be taken next?
a) Escalate the incident to second level support for further investigation and diagnosis b) Perform a Boolean search on the knowledge base with an extended time period Page 300
Service Desk Workbook
c) Request further information from the person that has logged the incident QUESTION 18 In ITIL terminology, an Incident is defined as… a) Any event which requires the approval of the Change Management process and is captured in the CMDB b) Any event that is not part of the standard operation and may cause a disruption to or degradation in service quality c) Any event which cases one or more incidents in the IT infrastructure to which the cause is unknown QUESTION 19 What is missing from the following list of incident management activities? 1. Detection and recording 2. ? 3. Investigation and diagnosis 4. Resolution and recovery 5. Closure. a) Categorization & matching b) Functional Escalation c) Hierarchical Escalation d) Classification & Initial support QUESTION 20 The goal of Incident Management is to…? a) Remove the cause of Problems in the IT infrastructure b) Restore normal service operation as quickly as possible c) Act as a single point of contact for end users QUESTION 21 Your organization has defined the following criteria for determining the impact on the business of an incident. High impact: a vital business function is unavailable to an entire department Medium impact: a regular business function is unavailable to part of a department -Low impact: a single desktop or non-critical peripheral device is unavailable Consider the following three incidents:
Page 301
Service Desk Workbook
Incident 1: The vice-president of the finance department reports that her laptop keeps rebooting. She has an important report to complete. Incident 2: The supervisor of the payroll department reports that he has just received the new tax tables from the government. These tables must be incorporated into the payroll system as soon as possible. Incident 3: The supervisor of the distribution center reports that she can not print the manifests required to ship goods. All printouts are totally illegible. Which of these incidents has a high business impact based on the information available at this time? a) Incident 2 b) Incident 1 c) Incident 3 QUESTION 22 The Business Manager has requested that some of the third party suppliers have access to update Service Desk records, this request has the approval of the Service Desk Manager and will be agreed through Underpinning Contracts. What do you as the Incident Manager have to consider with regard to this request?
a) Communicating to the End Users this scenario b) The affect this will have on the Incident Management process c) If this is possible using the software QUESTION 23 Each incident goes through a number of ‗actions‘ during its life-cycle. For each action it is important to record the name or identification of the person or support group recoding the action and the date/time of the action. Of the following which would you also consider as mandatory to record for each action? a) Related Configuration Item (CI) information b) Description and outcome of action c) Time spent on the action QUESTION 24
Page 302
Service Desk Workbook
As project manager for the implementation of the Incident Management process you have finished defining the procedures necessary. Other factors that you need to consider concern the people that will be involved and the timing of going live with the process itself. Which item is missing from the process implementation checklist? a) Cost benefits analysis b) Dependency review c) Return on investment analysis QUESTION 25 The current position of an Incident in the Incident Management lifecycle is called…? a) The Priority b) The Urgency c) The Impact d) The Status QUESTION 26 The amount of effort required to detect and recover a failing Configuration Item (CI) allows the Service Provider to ‗classify‘ the problem. Which of the following lists is used to classify problems? a) Category, Impact, Urgency, Priority b) Priority, Impact, Cost, Resources c) Category, Effort, Cost, Impact QUESTION 27 From the following list which can be considered as benefits of Problem Management? 1. Reduced incident volume 2. Permanent solutions 3. Higher first time fix at the Service Desk a) 1 and 2 only b) All are benefits of Problem Management c) 1 only QUESTION 28 The goal of Problem Management is to…
Page 303
Service Desk Workbook
a) Restore normal service operation as quickly as possible and minimize the adverse impact on business operations b) Minimize the adverse impact of Incidents and Problems, and to prevent the reoccurrence of Incidents c) To ensure IT systems are available over a set period of time or at a given instance as defined by Service Level Management QUESTION 29 Which process will Problem Management consult to gain an understanding of the infrastructure and the relationships between infrastructure items? a) Configuration Management b) Release Management c) Change Management QUESTION 30 A User calls the Service Desk to report an Incident related to the functioning of a PC. Service Desk staff ask the User to reboot the PC to see if the Incident could be quickly resolved. As such, "reboot" can be considered and used as a Workaround for many PC related incidents. To record this Workaround in the Known-error database, the following is a suggested procedure: Service Desk staff records this Workaround in the Incident record Incident Management will record the Workaround in the Known-error database and
inform the Workaround and the associated Incident records to Problem Management Problem Management will further analyze the incidents and the Workaround to find a
permanent solution. What is wrong in this procedure? a) Problem Management must record the Workaround in the Known-error database and not the Service Desk staff b) The Workaround is not analyzed by Problem Management before it is recorded in the Known Error database c) The Problem Manager must record the Workaround in the Known-error database QUESTION 31 Page 304
Service Desk Workbook
You are the Problem Manager for your organization. You have just completed the resolution of a very major Problem. Before you can close the Problem record, best practice calls for a review of actions. You publish an agenda for the meeting and invite the appropriate people to determine: What was done right? What was done wrong? How to prevent the Problem from happening again?
In order to conduct a full major Problem review, what is missing from the agenda? a) Review of the Problem Management process b) What could be done better next time? c) Review of the Incident Management process QUESTION 32 There is confusion as to which process controls the final stages of error resolution. Which of the following is the most appropriate guidance? a) Release Management, as this process actually distributes the resolution to the live environment b) Change Management controls the final stages as it often requires analysis and assessment of the resolution actions to be carried out c) Problem Management as through the Error Control activity QUESTION 33 You are the Problem Manager and are wishing to implement Proactive Problem Management. Which of the following would create the greatest challenge for you to do so? a) Lack of human resources b) Lack of financial resources c) Lack of sufficient historical data QUESTION 34 Which of the following is the most suitable measure to ensure that all involved staff are following the procedures of the Problem Management process? a) Problem related incident measure Page 305
Service Desk Workbook
b) Periodic Audits c) Problems categorized by status and impact d) Strict Management reporting QUESTION 35 Each month the Problem Management department produces the following statistical reports: A. The progress of Problems B. The number of defined Problems in percentage of total C. The number of solved Problems in percentage of total D. The reasons for Problems arising E. The elapsed time of Problems F. The number of RFCs that have arisen from Problems in percentage of total G. The effort taken in dealing with Problems Which report should Problem Management provide to Service Level Management? a) Report C b) Report F c) Report B QUESTION 36 Which of the following would NOT be appropriate for communicating as a benefit of a centralized Service Desk and Incident Management support team? a) Reduced operational costs for Support b) An ability to handle incidents from multiple locations and time zones 24/7 c) Central incident registration d) Central location for monitoring and responding to incidents QUESTION 37 How should the categories for Incidents be defined for use by the Service desk when registering Incidents? Page 306
Service Desk Workbook
a) In management terms b) In technical terms c) In end-user terms QUESTION 38 Which process or function maintains ownership of an Incident throughout its lifecycle? a) Problem Management b) The Service Desk c) Incident Management QUESTION 39 What are the key differences between the "Investigation & Diagnosis" activities that are performed within both Incident and Problem Management? a) Nothing, they both do the same thing b) For Incidents, Investigation and Diagnosis investigates all common and known issues, Vendor documentation and CMDB data. Problem Management requires actual investigation that does not rely on documentation c) They are similar activities, only the timeframes are shorter for Incident Management QUESTION 40 Recently it has been reported that SLA targets regarding the resolution of Incidents and associated Problem Records have not been met. It is agreed that a lack of adequate staffing is the issue. Who should determine where extra staff should be allocated to support this situation? a) The Service Desk Manager as the Service Desk is accountable for Incidents throughout their lifecycle b) The Support and Restore team as they collectively understand the relationships and interfaces between the two processes and the Service Desk c) The Incident Manager as it is the resolution of Incidents that is most important d) The Problem Manager as they can investigate why SLAs are not being met
Page 307
Service Desk Workbook
FURTHER READING For more information on other products available from The Art of Service, you can visit our website: http://www.theartofservice.com If you found this workbook helpful, you can find more publications from The Art of Service at: http://www.amazon.com
Service Desk INTRODUCTION ROADMAP Many organizations are looking to implement a Service Desk as a way to improve the structure and quality of the business. This document describes the contents of the Service Desk Guide. The information found within the Guide is based on the ITIL Version 2 framework, focusing on the Service Support phase of the ITIL framework and in particular the Service Desk function. The Guide is designed to answer a lot of the questions about a Service Desk and provides you with useful guides and user-friendly templates. Presentations can be used to educate or be used as the basis for management presentations or when making business cases for Service Desk implementation. The additional information will enable you to improve your organizations knowledge base and provide practical, usable examples and templates for you to use in the implementation and maintenance of a Service Desk. The guide serves to act as a starting point. It will give you a clear path to travel. It is designed to be a valuable source of information and activity. The Service Desk Guide:
Flows logically,
Is scalable,
Provides presentations, templates and documents,
Saves you time.
Page 308
Step 1 Start by reviewing the PowerPoint presentation: Service Desk ITIL V2 Presentation This presentation will give you a good knowledge and understanding of all the terms, activities and concepts required within the Service Desk function. They can also be used as the basis for management presentations or when making a formal business case for Service Desk implementation. Make sure you pay close attention to the notes pages, as well as the slides, as references to further documents and resources are highlighted here. Step 2 If you did not look at the supporting documents and resources when prompted during the PowerPoint presentations, do this now. Below is an itemized list of the supporting documents and resources for easy reference. You can use these documents and resources within your own organization or as a template to help you in prepare your own bespoke documentation.
Service Desk Factsheet
Business Justification Document
Policies Objectives and Scope
Objectives and Goals
Service Desk Manager Role
Email Text
Business & IT Flyers
Outsourcing Template
Communication Plan
Report KPI‘s & Metrics
Service Desk Technology
Step 3 Alternatively, you can continue by working through the additional documents:
Implementation Plan & Project Plan
Page 309
This time; with the focus on your organization. This will help you ascertain the Service Desk maturity for your organization. You will able to identify gaps and areas of attention and/or improvement. The supporting documents and resources found within this guide will help you fill these gaps by giving you a focused, practical and user-friendly approach to implementing and maintaining a Service Desk.
SERVICE DESK PRESENTATION
Page 310
These bullet points help to illustrate why it is that we need to introduce the disciplines of effective and efficient Process management into our IT environments. Briefly discuss each, you can of course add or delete points according to your own situation.
ITSM is not something on its own, but closely linked to the business. Explain difference between ‗effective‘ (doing the right thing) and ‗efficient‘ (doing the right thing the right way). The objective tree is a useful way to help explain the importance of IT being a supporting department to the business. To meet organisational objectives, the organization has business processes in place. Examples of business processes are sales, admin and financial (who have a Page 311
―sales process‖) or logistics, customer service and freight who have a ―customer returns process‖. Each of the units involved in these business processes needs IT Services (e.g. CRM application, e-mail, word processing, financial tools). Each of these services runs on IT infrastructure that has to be properly managed (Service Management). IT Infrastructure includes hardware, software, procedures, policies, documentation, etc.
Traditionally we look at the IT department as a collection of specialists with specialist skills. This is a functional way to look at IT and it puts people into departmental SILO‘s.
Page 312
Best practice processes will transverse functional departments and help to break down the silo‘s/walls/barriers to communication between them. Explain the benefits of processes in general. Other points to explain:
A process is a set of activities with a common goal.
A process can measure the input, output and activities.
A process will link these measurements to targets.
An IT organization needs to focus on all these aspects to deliver the right IT services (effective) in the right way (efficient). Generally, the technology perspective gets a lot of attention (time, budget, people etc). More and more people see the importance of processes (which is why ITIL is getting so popular). There is also an organization perspective: the alignment of vision, strategy and goals with the day to day activities in IT. This is useless, if it is not communicated (which is virtually always the case and finally, there is the people perspective, which looks at the ‗soft side‘: is your staff happy, do they have the right skills, are you managing them effectively etc.
Page 313
Service Level Management is one of 10 ITIL processes. Here we get to see the others and the one function (Service Desk). Security Management can be included as well, due to it‘s critical importance. Make sure that participants understand that Service Level Management is not an isolated process, but:
Is a process that is based around communication and monitoring
Is a process that requires high client/customer liaison
Provides information to all other processes (e.g. customer expectations, financial information,etc.)
Requires information from other processes (e.g. reports on performance, trending information, customer satisfaction ratings) etc.
Page 314
Please refer to Business Justification on page 39 within this guide for more information.
Page 315
The main SD role is that of single point of contact (SPOC). You want to avoid users calling the various support groups all the time.
Service request: e.g. a question about the opening hours of the SD Request for change: e.g. a new laptop Some organizations have given the SD a very central role within the IT dep't, in which they manage suppliers, manage the CMDB, manage backups etc…
Page 316
Four main types of SD, ranging from call center to expert SD. As you climb up, the skill level increases, as will the costs (of the SD). [call center just passes on calls; unskilled SD solves a few; skilled SD solves a lot; expert SD solves everything!]
This slide and the next 3 show different organizational forms for the SD. The Local SD is based on the concept of 1 SD for each user group.
Page 317
This slide and the next 3 show different organizational forms for the SD. The central SD is based on the concept of 1 SD for the organisation.
A split function SD could be chosen if e.g. you have an IT and a business SD. Both SD‘s are seen as a central point of contact for their specific responsibilities. Attention should be give to making it clear to users which desk does what. The desks can share procedures, communication activities etc.
Page 318
In the virtual SD, the analysts could physically be anywhere! They could be grouped over the organisation, over several locations or even working separately from home. Think about the technology you‘d need to do this.
Basically, there are 3 areas of required expertise for SD staff: Technical skills for first line call resolution (unless it‘s a call center) Communication skills: listening, reasoning, negotiating, conflict resolution etc… Business understanding: in order to determine the effect of incidents, requests etc on the business – this one is usually understated It is up to the organization to determine the focus of skills: how much technical etc? Question: ―What‘s the focus in your organization?‖ Page 319
Statement #1 is v. extreme; of course, communication skills are important, but so are technical and business skills. If you opt for a call center function, then the statement is valid. Statement #2: if this is so, ask yourself why?? And how is it dealt with? Why is it important to deal with users bypassing the SD?
SUPPORTING DOCUMENTS Through the documents, look for text surrounded by << and >> these are indicators for you to create some specific text.
Page 320
Watch also for highlighted text which provides further guidance and instructions.
SERVICE DESK FACTSHEET Why Cost reductions are a necessity in today's economy and internal support groups are a frequent cost reduction target. Service Desks and desktop support teams need to ensure that their services are clearly defined and aligned with business needs. The Service Desk is a single point of contact (SPOC) for end-users who need help. Without this single point of contact an organisation would face major losses in time spent on looking for ways to fix issues and get help. Goal
To provide a single point of contact for Customers
To facilitate the restoration of normal operational service with minimal business impact on the Customer within agreed service levels and business priorities.
The main types of Service Desks are:
Call Centre: only call dispatching, no other activities done
Unskilled Service Desk: call despatching, incident tracking, feedback mechanism to clients
Skilled Service Desk: large number of incidents are solved at the Service Desk
Expert Service Desk: incorporates Incident Management and Problem Management (partly). Most incidents are solved at the Service Desk
Activities The Service Desk performs the first line support for the IT Services. Apart from the Call Centre, all Service Desk types perform the following activities:
Receive all calls and e-mails on incidents
Incident recording (including RFC‘s)
Incident Classification
Incident Prioritisation
Incident Escalation
Search for Work Around Page 321
Update the customer and IT group on progress
Perform communication activities for the other ITIL processes (e.g. Release notifications, change schedules, SLM-reports)
Perform daily CMDB verification
Report to Management, Process Managers and customers (through SLM) on Service Desk performance
Service Desk technology
Communication technology such as Computer Telephony Integration (CTI) or Voice Over Internet Protocol (VOIP)
Interactive Voice Response systems (IVR)
E-mail, Fax servers (fax via e-mail or the Internet), Forwarding calls to pagers, mobile phones, laptop and palmtop computers
Intranet and Internet self-service platforms
Logical model of an IT Service Desk
Results To introduce and maintain a successful Service Desk, it is essential that:
Business needs are understood
Customer requirements are understood Page 322
Investment is made in training for Customers, support teams and Service Desk staff
Service objectives, goals and deliverables are clearly defined
Service levels are practical, agreed, and regularly reviewed
The benefits are accepted by the business. Cost
Personnel – to man Service Desk (Set-up and ongoing)
Accommodation – Physical location (Set-up and ongoing)
Software – Tools (Set-up and ongoing)
Hardware – Infrastructure (Set-up)
Education – Training (Set-up and ongoing)
Procedures – external consultants etc (Set-up)
Benefits
Improved Customer Service perception and satisfaction
Increased accessibility through a single point of contact, communication, and information
Better-quality and quicker turnaround of customer requests
Improved teamwork and communication
Enhanced focus and a proactive approach to Service provision
A reduced negative business impact
Better managed infrastructure and control
Improved usage of IT support resources and increased productivity of business personnel
More meaningful management information to support decisions.
One key benefit of a Service Desk is the provision of management information;
Staff resource usage
Service deficiencies
Service performance and target achievement
Customer training needs
Associated costs.
Page 323
BUSINESS JUSTIFICATION DOCUMENT
IT Services Business Justification Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Business Justification Document for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will
Release Date:
certainly be reminded of the key topics that have to be considered. This document serves as a reference for HOW TO APPROACH THE TASK OF SEEKING FUNDS for the implementation of the Service Desk Function. This document provides a basis for completion within your own organization.
This document was; Prepared by:Business Justification Service Desk On: <> A strong enough business case will ensure progress and funds are made available for any IT initiative. And accepted by: On:may sound like a bold<> This statement but it is true. As IT professionals we have (for too long) assumed that we miss out on funds why other functional areas (e.g. Human resources and other shared services) seem to get all that they want.
Page 324
However, the problem is not with them, it‘s with US. We are typically poor salespeople when it comes to putting our case forward. We try to impress with technical descriptions, rather than talking in a language that a business person understands. For example We say We have to increase IT security controls, with the implementation of a new firewall.
We should say Two weeks ago our biggest competitor lost information that is now rumored to be available on the internet. The network bandwidth is our biggest The e-mail you send to the other national bottleneck and we have to go to a switched managers will take 4 to 6 hours to be delivered. It local environment. used to be 2 to 3 minutes, but we are now using our computers for so many more tasks. Changes to the environment are scheduled We are making the changes on Sunday afternoon. for a period of time when we expect there There will be less people working then. to be minimal business impact. Doesn‘t that sound familiar? To help reinforce this point even further, consider the situation of buying a new fridge. What if the technically savvy sales person wants to explain ―the intricacies of the tubing structure used to super cool the high pressure gases, which flow in an anti-clockwise direction in the Southern hemisphere‖. Wouldn‘t you say ―too much information, who cares – does it make things cold?‖ Well IT managers need to stop trying to tell business managers about the tubing structure and just tell them what they are interested in. So let‘s know look at some benefits of Service Desk. Remember that the comments here are generic, as they have to apply to any organization. If you need assistance in writing business benefits for your organization please e-mail [email protected] for a quotation. Benefits Introduces a structured support system, where each person has a common and concise view on the function of the Service Desk in the organization. Reduces the reliance on key staff to perform multiple duties. Depending on the model of Service Desk support there can be a shift from subject matter experts spending a high degree of time working on administrative tasks, rather than actually helping people.
Notes/Comments/Relevance
Page 325
The properly managed Service Desk will also have built in redundancy with respect to the people involved, so that there is always back-up and resources available should one person be absent. With the co-introduction of a sound Incident Management and Problem Management process the Service Desk will move away from a function that is continually in a ―fire-fighting‖ mode to one that delivers true value-added support to the organization. A professional Service Desk will quickly start to change any negative perception that customers or end-users will have. This change cannot be expected simply by launching the Service Desk. The communication plan that announces the new service must also be carefully planned and implemented.
The new Service Desk structure will bring to an end (or else significantly reduce) the number of unrecorded requests for assistance and unauthorized changes to the IT infrastructure. While people are involved with the function there will always be ―by-passing‖, however, the checks and reporting structures for this function will help to reduce this. A new Service Desk function is often accompanied with a new Service Desk tool. This combined with a standard education base for all staff helps the same problems being resolved repeatedly rather than eliminated Such steps lead to immediate results in not having to solve the same problem multiple times, as staff learn how to search for any occurrence of the problem as well as how to record incidents to allow for easier faster searching. The reporting structure that will be designed with the new function allows more meaningful information to be delivered. Such reporting has more of a business focus, Page 326
rather than a traditional focus on reporting the number of calls received or resolved at first point of contact. With this new business focus managers are much more empowered to justify the costs of running their areas of responsibility, as they can know demonstrate real business returns
POLICIES OBJECTIVES AND SCOPE
IT Services Policies, Objectives and Scope Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Policies, Objectives and Scope for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics
Release Date:
that have to be considered.
Policy Statement
Page 327
A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous
Use this text box to answer the ―SENSE OF URGENCY‖ question regarding this function. Why is effort being put into this function? Not simply because someone thinks it‘s a good idea. That won‘t do. The reason has to be based in business benefits. You must be able to concisely document the reason behind starting or improving this function. Is it because of legal requirements or competitive advantage? Perhaps the business has suffered major problems or user satisfaction ratings are at the point where outsourcing is being considered. A policy statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHY question for this process.
The above Policy Statement was;
Objectives Statement Prepared by: On:
<>
And accepted by: On:
<>
Page 328
Something worked toward or striven for; a goal. Use this text box to answer the ―WHERE ARE WE GOING‖ question regarding this function. Generic sample Mission statement for Service Desk is: "Service Desk Mission Statement: The Service Desk is to provide all users with a single, helpful, first point of contact with the IT department. The Service Desk covers a wide variety of activities including: To provide a helpful and friendly first point of contact for the IT Department. To provide basic support for computing and audio/visual services. To provide the necessary online forms to request equipment, repairs, and network account changes. To provide online FAQ's, manuals, and tutorials to empower users to self-troubleshoot. To provide equipment delivery and repair services. What will be the end result of this function and how will we know when we have reached the end result? Will we know because we will establish a few key metrics or measurements or will it be a more subjective decision, based on instinct? A generic sample statement on the “objective” for Service Desk is: The Service Desk function provides a single point of contact for the customers of the IT department, not only for incidents and questions but also for other activities such as Change requests and SLM reports. In many cases the service desk represents the IT department to the customer and to the end-user and as such is key in the customer satisfaction and perception of the IT department. Note the keywords in the statement. For the statement on Service Desk they are ―representative, customer satisfaction, perception‖ and ―single point of contact‖. These are definite areas that we can set metrics for and therefore measure progress. An objective statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHERE question for this process. The above Objective Statement was; Prepared by: On:
Scope Statement
<>
Andarea accepted by: by a given activity or subject The covered On:
<>
Page 329
Use this text box to answer the ―WHAT‖ question regarding this function. What are the boundaries for this function? What does the information flow look like into this function and from this function to other processes? A generic sample statement on the “scope” for Service Desk is: The Service Desk function will be responsible for managing first line support and general customer contact involving all aspects of the IT service Delivery. The Service Desk will be responsible for the daily verification of the CMDB. Service Desk will not be responsible for problem analysis and management of changes. An scope statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHAT question for this process. Be aware that the scope of the Service Desk depends on the way the IT department is organised. It can be as broad or narrow as needed. You might wish to use Service Desk staff to perform simple activities for the other processes, i.e. performing routine changes, updating databases, sending out reports.
OBJECTIVES AND GOALS
IT Services Detailed Objectives/Goals Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Page 330
Release Date: Detailed Objectives/Goals for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. The detailed objectives for Service Desk should include the following salient points: Objective
Improve Customer Satisfaction By providing a single point of contact for the customers and end-users you will make the accessibility of the IT department higher. This will improve the customer satisfaction as they now know where to go to when they have a question or IT issue. Don‘t forget to include the IT staff as end-users in the survey. One of the main improvements should be that the Service Desk takes a lot of workload off the IT specialists. Responsiveness When a customer / end-user contact the Service Desk they should be looked after swiftly. By monitoring the responsiveness of the SD staff you can improve the perception that the customer / end-user has of the IT department. Accessibility of the IT department is one of the main objectives of a Service Desk. It shouldn‘t be difficult to get in touch with the Service Desk. (you probably don‘t speak highly of a Service Desk where you have to wait 2 minutes on the phone before somebody picks up) Establish efficient reporting lines Service Desk staff also plays a major part in the communication from the IT department back to the customers / end-users. IT should be clear who reports on what and why. SD staff very often sends out the monthly performance reports to the customers on behalf of the SLM process. Professional image of the IT department With a well established Service Desk and experienced, pro-active, friendly staff the image of the IT department will be more positive. The Service Desk should focus on a professional work ethic and approach.
Notes Met/Exceeded/Shortfall
Dates/names/role titles
Page 331
To establish ground rules that distinguish a genuine request for Incident as oppose to a Service Request. A Service request is a low impact activity that has traditionally been treated as an Incident. A classic example is changing of administrator passwords. Such a step is the result of a security policy and does not require formalized Incident procedures. There will however, be a detailed procedure about when and how passwords are to be Incident and who is to be advised, etc. – but approval from the Incident Manager is not required. Develop working relationships with all other process areas. The Service Desk is a pivotal one with regard to requiring input from other process areas. Obvious links include Incident Management (SD staff are first point of call for incidents and record all incidents that come in), Configuration Management (to verify configuration information) and Release Management (sending out release notices). Less obvious links include Financial Management for IT Services (to establish Return on Investment (ROI) on incidents and the cost per call) and IT Service Continuity Management (to the level of Service Desk support during a contingency situation).
Develop a SD that suits the organisation and look for continuous improvement. A Service Desk can be designed in various ways: you can have a local service Desk, or a distributed Service Desk. Some organisations even opt for a virtual Service Desk to make it easier to support the ‗follow the sun‘ concept. What type of Service Desk suits your organisation? How does this SD design support the overall Service Desk goals and business goals?
Use these objectives to generate discussion about others that may be more appropriate to list than those provided.
SERVICE DESK MANAGER ROLE
IT Services Page 332
Role, Responsibilities Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Detailed responsibilities of the Service Desk Manager Please be aware that the Service Desk manager has a slightly different role than the process managers in an IT organisation. Where usually the process managers don‘t
Release Date:
have a line responsibility and are not accountable for staffing matters, the Service Desk manager does perform that role. Separate from the content-related responsibilities you‘ll also have people management responsibilities and the way your staffs perform will reflect on your own performance review. The Service Desk Manager….. 7. 8.
9. 10. 11. 12.
13.
Description Will design and implement a Service Desk that supports the IT department in meeting the business objectives. Will manage and coordinate the daily activities and processes that take place at the Service Desk to ensure operational, tactical and strategic objectives are achieved. Is responsible for the cost effectiveness (and overall efficiency) of the Service Desk. Is responsible for hiring and firing of Service Desk staff. Conducts performance reviews on staff to establish the improvement in performance on a regular basis. Will act as escalation point for staffing issues. This is part of the line management role, and the Service Desk Manager reports to the IT Director (or CIO depending on the organizational structure). Will liaise with the relevant parties involved with all ITIL processes to ensure activities that are performed at the Service Desk (for other processes) are co-ordinated and carried out
Notes/Comments Use the notes/Comment s column in different ways. If you are looking to apply for the role of Service Desk Manager, then you can check yourself against the list (with ticks or look to update your resume). If you are looking to appoint a Service Desk Page manager or 333 promote someone from within the organization you can make notes
14.
15. 16.
according to plan. Will control and review: Any outstanding process related actions Current targets for service performance The mission statement Make available relevant, concise reports that are both timely and readable for Customers, Process Owners and Management Timely and pro-active escalation of incidents, service request, training requests and request for changes to the appropriate areas.
Detailed skills of the Service Desk Manager The Service Desk Manager….. 8.
9.
Description … should be able to develop and maintain the appropriate policies and procedures to run a Service Desk. High degree of interpersonal skills to be able to manage the Service Desk staff and deal with conflicts.
10. Semi-Technical ability in being able to choose an appropriate Service Desk system to support the activities and procedures. The technical skills are also needed to understand the incidents that are reported by the customers/end-users so that they are resolved as soon as possible without excessive use of 2nd line support. 11. An ability to run a department according to strict guidelines 12. Communicate with people at all levels of the organization. This is especially important as the Service Desk provides a single point of contact for the IT Department. 13. The Service Desk Manager should have the skills and attitude to improve the SD organisation and dealing with the potential resistance that this will cause. 14. Must be able to think logically and analyze Service Desk performance. 15. Should be able to market the IT department to the customers and specifically the importance of the service desk. 16. Should be firm enough to be able to deal with circumventions of the agreed procedures.
Notes/Comments Use the notes/Comments column in different ways. If you are looking to apply for the role of Service Desk Manager, then you can check yourself against the list (with ticks or look to update your resume).
If you are looking to appoint a Service Desk manager or promote someone from within the organization you can make notes about their abilities in the particular area.
EMAIL TEXT Page 334
IT Services Service Desk: Email Texts Status: Introduction
Version:
In the next section of this document is an
Release Date:
example email text that can be distributed across
Draft 0.1
your organisation. Note, that this is just one piece of text for one email. However, it is advisable to create a few different versions of the below text, which you can store in this document, for future use. This is very important, as each time you send an email regarding your Service Desk it should be different and targeted to the correct audience. This document provides a method for also keeping track of your communication that you have made to the rest of the organisation, and to keep in focus the promises that have been made regarding this function. Dear << insert audience here, for example, Customer, IT Staff, Marketing Dept etc >> Information Technology Service Desk In order to improve the IT Services and ensure that they are aligned with the needs of the organisation, we have made several changes to the Service Desk. What is the purpose of the Service Desk? This Service Desk is responsible for providing 1st line IT Support to the business. We have defined the Goal for Service Desk as follows: << INSERT YOUR GOAL FOR THE SERVICE DESK HERE >> What are the benefits to you?
You will be kept informed about your issue at all times Page 335
Recurring issues with IT Services will be better identified for further action
Provide clear understanding of the services you will receive
Better customer focus when dealing with the IT department
How will the Service Desk work? A single Service Desk phone number will be provided to the business. As soon as you have an IT issue, you will call that number and the Service Desk will take your details. Some of the details are your name and brief description of the request. Upon registration of your issue or request you will be provided with an Incident Reference Number. This number can be used at anytime to see how your incident or request is progressing. Upon resolution of your request, you will be contacted to ensure that there are still no outstanding issues. It is at this point that all Service Desk representatives will be asking you about the how well we performed. We see this as an integral step in helping improve our services. The commencement date of the Service Desk is scheduled for: << insert date >> OR Completion of the Service Desk will be: << insert date >> This is an integral part of the services we provide and there may be some operational difficulties to overcome, but with your support, I am sure we can provide an extremely beneficial function to both the Business / << company name >> and IT. If you have any questions regarding this, please do not hesitate to contact me on << phone number >> << Your Name and Titles >>
BUSINESS AND IT FLYERS OUTSOURCING TEMPLATE
IT Services Outsourcing Template Service Desk Page 336
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Service Desk Outsourcing Template The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly
Release Date:
be reminded of the key topics that have to be considered. This document serves as a TEMPLATE FOR ENGAGING AN EXTERNAL PARTY TO MANAGE A SERVICE DESK. This document provides a basis for completion within your own organization. This document contains prompts and text that would be meaningful for this activity. This document was; Prepared by: On:
<>
IT OUTSOURCING SERVICE AGREEMENT BETWEEN And accepted by: _________________________ On:
AND
<>
_______________________ THIS AGREEMENT between _________________ (―OUTSOURCER‖) and ________________________(―CLIENT‖) is made this ____ day of _________, ____. WHEREAS, the CLIENT desires to purchase IT management and operation outsourcing services in support of the management and operation of the company‘s Information Technology need ; and WHEREAS, OUTSOURCER wishes to provide the total outsourcing services described herein in accordance with the terms and conditions hereof; NOW THEREFORE, in consideration of the payments herein agreed to be made and the covenants and agreement herein contained, the parties hereto, intending to be legally bound, hereby agree to the following: Page 337
SERVICES Starting on the Effective Date (as defined in Section 3.1), OUTSOURCER shall perform the IT Outsourcing services described in this Agreement and Exhibit A, attached hereto and made a part hereof (―Scope of Services‖). COST FOR SERVICES The costs for services to be provided by OUTSOURCER are set forth in Exhibit B attached hereto and made a part hereof. Such costs shall be subject to a cost of living adjustment, as more fully set forth in Exhibit B. TERMS AND CONDITIONS Term: This Agreement shall commence on _____________________, 19___ (the ―Effective Date‖), and terminate on _______________________, 19___. Invoices and Payment Terms: OUTSOURCER shall submit monthly invoices to the CLIENT. Invoices shall be issued before services are rendered by OUTSOURCER and shall be submitted by OUTSOURCER at least 30 business days before payment is due by the CLIENT. Exhibit C indicates the monthly amounts to be paid by the CLIENT for OUTSOURCER staff services and expenses. The CLIENT shall pay according to this schedule. Payment not received within [five (5)] days of the due date will be subject to an interest charge. All interest charges will be computed at the current prime rate. Data Processing Equipment and Supplies: Subject to Section 3.9(c) below, as between the parties, the CLIENT reserves and retains the right, title and interest in any and all computing equipment, software, systems, data, output and other materials or property except that which is furnished by OUTSOURCER and is not developed pursuant to this Agreement, which retains such rights itself. Upon expiration or earlier termination of this Agreement, OUTSOURCER shall relinquish to CLIENT the use of equipment provided by CLIENT in as good condition as when turned over to OUTSOURCER, reasonable wear and tear excepted. All costs relating to data processing equipment and supplies for the CLIENT‘s computer functions shall be the responsibility of the CLIENT.
Page 338
All costs relating to OUTSOURCER‘s consultants fee, salaries, Medical, Insurance, recruitment fee, training expenses shall be the responsibility of the OUTSOURCER. The CLIENT shall also provide to OUTSOURCER, at no charge to OUTSOURCER subject to Section 3.17 CLIENT Policy and Procedures, the following in order to allow OUTSOURCER to perform under this Agreement. All utilities, including any special power and air conditioning needed, as determined solely by CLIENT, to operate the CLIENT‘s data processing equipment and storage of computer supplies; Storage, in an area removed from the data processing site, for historical data and backup material that may be needed to reconstruct data files in the event working files are destroyed by natural disasters, fire, riots or other causes; Computing supplies such as paper, forms, ribbons, tapes, disk packs and microfilm; and Security, fire control equipment and janitorial support for the CLIENT‘s data processing facilities. Work Space: At no charge to OUTSOURCER, subject to Section 3.17 CLIENT Policy and Procedures, the CLIENT shall provide OUTSOURCER, with an appropriately furnished, conveniently located office or other suitable work space for use by the OUTSOURCER staff in performing work under this Agreement. Also at no charge to OUTSOURCER, the CLIENT shall provide office supplies, telephone service and reproduction, telecommunications and office equipment reasonable and necessary to support OUTSOURCER‘s staff and performance of this Agreement. Use of Data Processing Equipment: At no charge to OUTSOURCER, subject to Section 3.17 CLIENT Policy and Procedures, the CLIENT shall provide OUTSOURCER access to all equipment, equipment services, programs and supplies necessary to support the computing needs of the CLIENT. The CLIENT shall provide OUTSOURCER‘s staffs access to all such equipment so that OUTSOURCER may perform its obligations under this Agreement including, but not limited to, operating all such equipment. Use of Software and Access to Personnel:
Page 339
For purposes of performance under this Agreement, OUTSOURCER shall have complete access to, shall operate and shall, subject to CLIENT‘s approval and obligations of CLIENT under third party agreements, have the right to modify or alter all CLIENT software programs and related material, pursuant to the Scope of Services. OUTSOURCER shall also have reasonable access to the CLIENT‘s management, professional and operating personnel necessary for performance under this Agreement, as well as to all materials, records, discs, tapes or other information necessary to perform the services contemplated hereby. OUTSOURCER and CLIENT each realize that time is of the essence in order to accomplish the objectives of this Agreement, including the Scope of Services. OUTSOURCER agrees to provide requests for support from CLIENT in a timely and reasonable manner. CLIENT agrees to handle OUTSOURCER‘s requests for support, to the best of its ability, in a timely and reasonable manner. Status Reporting: OUTSOURCER management staff shall conduct regular meetings with the CLIENT Contract Administrator (as defined in Section 4.4 hereof) and such other persons as may be designated by the CLIENT to formally review OUTSOURCER performance under the terms of this Agreement. These meetings shall be conducted at a time and location mutually agreed upon. OUTSOURCER shall also prepare, on a monthly and quarterly basis, as applicable, a written status report which documents past activities and outlines planned activities for the forthcoming month or year. Non-Solicitation: Beginning on the Effective Date and continuing for a period of one year from the expiration or termination of this Agreement, the CLIENT shall not, without OUTSOURCER‘s prior written consent (which consent may be withheld at OUTSOURCER‘s sole discretion), enter into any contract (including, but not limited to, an employment contract, facilities management contract or consulting contract) with (i) any employee or former employee of OUTSOURCER who performed work under this Agreement within two years of such contract (a ―OUTSOURCER Employee‖) or (ii) any person, firm, corporation or enterprise by which the OUTSOURCER Employee is employed or with which such OUTSOURCER Employee is affiliated (including, but not limited to, as a consultant, shareholder, Page 340
partner, officer or director) (―OUTSOURCER Employee‘s New Firm‖), whereby the OUTSOURCER Employee or OUTSOURCER Employee‘s New Firm would provide to the CLIENT all or part of the services provided by OUTSOURCER to the CLIENT under this Agreement. Beginning on the Effective Date and continuing for a period of one year from the expiration or termination of this Agreement, OUTSOURCER shall not, without CLIENT‘s prior written consent (which consent may be withheld at CLIENT‘s sole discretion), enter into any contract (including, but not limited to, an employment contract, facilities management contract, or consulting contract) with (i) CLIENT employee(s), or (ii) any person, firm, corporation or enterprise by which the CLIENT Employee is employed or with which such CLIENT Employee is affiliated (including, but not limited to, as a consultant, shareholder, partner, officer or director) (―CLIENT Employee‘s New Firm‖). Confidentiality and Ownership of Material: Subject to paragraph (c) below, ownership of all data, material and documentation originated and prepared for the CLIENT pursuant to this Agreement shall belong exclusively to the CLIENT. Upon termination of the Agreement, all such data, material and documentation shall be returned by OUTSOURCER to the CLIENT. CLIENT and OUTSOURCER shall treat the other‘s ―Confidential Information‖ (as defined below) as proprietary. Each of CLIENT an OUTSOURCER shall (i) exercise due care to keep in confidence and not disclose Confidential Information to any individual other than its own employees who have a ―need to know‖ in order to perform the obligations of CLIENT or OUTSOURCER, as applicable, under this Agreement; (ii) not duplicate or publish any Confidential Information; and (iii) use Confidential Information only for the purposes authorized herein. The foregoing obligations shall not apply to Confidential Information if, and only to the extent that, it: (a)
is or becomes public knowledge through no fault of either of the parties hereto
(b)
was previously known by the recipient;
(c)
is lawfully provided to the recipient without restriction by an independent third party; or
(d)
must be disclosed pursuant to applicable law or regulation; provided, however, that with respect to exception (a), the disclosing party (i.e., the party who is disclosing to a third party information which is confidential to the other party to Page 341
this Agreement) shall first establish that the full particulars of the Confidential Information are, in the combination disclosed to the disclosing party, well known or generally used within the industry, not merely that the individual features are in the public domain or available in isolated segments in two or more readilyavailable public sources; and provided, further that the burden shall be on the disclosing party to prove the applicability of any of exceptions (a), (b), and (c). For purposes hereof, ―Confidential Information‖ shall mean manufacturing, engineering, software, business, customer, marketing, financial and other nonpublic information, reports or trade secrets relating to the business of OUTSOURCER or the CLIENT, as applicable, and created or learned by the CLIENT or OUTSOURCER, as applicable, in connection with the performance of this Agreement. All worldwide right, title and interest in Intellectual Property Rights (as defined below) relating to in severable improvements in software and documentation not owned by or licensed to OUTSOURCER, which improvements are made, conceived or developed by OUTSOURCER in the performance of its duties under this Agreement shall vest exclusively in CLIENT. In severable improvements shall mean those improvements that are not applicable to other software. All worldwide right, title and interest in Intellectual Property Rights in, to, or relating to new software, including without limitation, modules, subroutines and stand-alone programs, and related documentation made, conceived or developed by OUTSOURCER in the performance of its duties under this Agreement shall vest exclusively with CLIENT. All worldwide right, title and interest in Intellectual Property Rights in, to, or relating to severable improvements and modifications made, created, conceived or developed by OUTSOURCER in the performance of its duties under this Agreement, to software and related documentation not owned by or licensed to OUTSOURCER, shall vest exclusively in CLIENT. Severable improvements shall mean those improvements having application in and to other software. ―Intellectual Property Rights‖ shall mean all patents, trade secrets, and copyrights in, covering, and relating to software and documentation made, created, conceived, developed, improved or modified by OUTSOURCER in the performance of its duties under this Agreement. Page 342
Notwithstanding the foregoing to the contrary, Software developed under grants where OUTSOURCER is responsible for all aspects of development shall be done under a specific change of scope, and the ownership of the software so developed shall be governed by the grant provisions, and if there are no ownership requirements under the grant provisions, then the provisions of subparagraph (d) shall apply. Notwithstanding the foregoing to the contrary, Software developed under grants where OUTSOURCER provides management and coordination services only shall not require a specific change of scope, and the ownership of the software so developed shall be governed by the grant provisions, and if there are no ownership requirements under the grant provisions, then the provisions of subparagraph 3.9.4 shall apply. Liability and Warranties: Subject to its record retention policies, the CLIENT shall maintain Adequate Supporting Material to enable OUTSOURCER to update or regenerate, as necessary, data files, printer outputs and other data. In the event of loss, damage, destruction of any data, service, system or program due to the negligence of OUTSOURCER, OUTSOURCER‘s liability therefore shall be limited to either the replacement, repair, reconstruction, redevelopment or regeneration, at OUTSOURCER‘s option, of the lost, damaged, destroyed or inoperable data, service, system or program from the CLIENT‘s supporting material or otherwise as appropriate in the method deemed, most suitable, by OUTSOURCER for such action. In the event the CLIENT has failed to maintain Adequate Supporting Material, Outsourcer‘s liability shall be strictly limited to the same costs of replacement, repair, reconstruction, redevelopment or regeneration as if the CLIENT had so maintained adequate supporting material. Adequate Supporting Material is defined for the purposes of this Section as the original source material or data input documents initially provided to OUTSOURCER or replacement source material or data input documents provided to OUTSOURCER from time to time from which OUTSOURCER has obtained and input data in performance of its services hereunder. OUTSOURCER shall not be liable for any damages resulting or arising from CLIENT‘s failure to perform its obligations hereunder, provided that OUTSOURCER is not responsible for such failure to perform. Page 343
To the extent permitted Law, OUTSOURCER shall not be liable, whether contractually or in tort, for any consequential, special or indirect damages arising out of or in connection with this Agreement. To the extent they are beyond the reasonable control of OUTSOURCER, OUTSOURCER shall not be responsible for schedule delays, inaccuracies or other consequences resulting from incorrect CLIENT data, lateness in delivery by of CLIENT‘s data or the failure of CLIENT‘s equipment or personnel. OUTSOURCER agrees to be liable for, defend and indemnify CLIENT against all claims, suits, judgments or damages, including the cost of administrative hearings, court costs and attorneys fees, arising out of the negligent or intentional acts or omissions, or violations of laws or regulations, of or on the part of OUTSOURCER or its agents, officers, subcontractors or employees, in the course of the operation of this Agreement. Warranties: OUTSOURCER SHALL PERFORM THE SERVICES UNDER THIS AGREEMENT IN ACCORDANCE WITH STANDARDS OF CARE, SKILL AND DILIGENCE CONSISTENT WITH RECOGNIZED AND PRUDENT INFORMATION TECHNOLOGY PRACTICES, ALL APPLICABLE LAWS AND REGULATIONS, THE SCOPE OF SERVICES, EXHIBITS, DOCUMENTS AND PROCEDURES APPLICABLE TO THE SERVICES, AND THE DEGREE OF KNOWLEDGE, SKILL AND JUDGEMENT NORMALLY EXERCISED BY PROFESSIONALS WITH RESPECT TO SERVICES OF THE SAME OR SIMILAR NATURE. THIS IS THE ONLY WARRANTY MADE BY OUTSOURCER WITH RESPECT TO ITS SERVICES UNDER THIS AGREEMENT AND TO THE EXTENT PERMITTED BY LAWS IS IN LIEU OF ALL OTHER UNDERSTANDINGS AND ALL WARRANTIES, EXPRESSED, IMPLIED OR STATUTORY, AS TO THE SERVICES TO BE PROVIDED BY OUTSOURCER, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR USE FOR A PARTICULAR PURPOSE. Taxes: This Agreement does not include charges for any taxes, which now or in the future may be deemed by a taxing authority to be applicable to the services to be provided by OUTSOURCER. In the event a taxing authority determines now or in the future that such services are subject to tax, Page 344
OUTSOURCER shall invoice such taxes to the CLIENT and the CLIENT shall pay same simultaneously with the payment to which taxes relate. CLIENT hereby represents that it is not currently subject to any such taxes and will notify OUTSOURCER in a timely manner if CLIENT becomes subject to any such tax. At the time of execution of this Agreement taxes on services provided by OUTSOURCER to CLIENT hereunder are not required to be paid, but if in the future are required, then CLIENT shall pay such taxes. Force Majeure: If either OUTSOURCER or the CLIENT is prevented from performing any task hereunder, in whole or in part, as a result of a cause beyond its reasonable control, which may include an Act of God, war, civil disturbance or organized labor dispute, such failure to perform shall not be grounds for termination of this Agreement. Termination: This Agreement may be terminated by a party (the ―Terminating Party‖) prior to the expiration of its stated term upon the occurrence of an ―Event of Default‖ affecting the other party (the ―Terminated Party‖) An ―Event of Default‖ shall mean: (a)
failure by a party to timely perform any obligation under this Agreement, including without limitation CLIENT‘s failure to pay or cause to be paid any sums due in the manner provided in this Agreement within fifteen (15) business days of the date such payments were due; or OUTSOURCER not performing any of its obligations in accordance with this Agreement and all Exhibits thereto; or
(b) any representation or warranty made by either party herein or in any document executed simultaneously and in connection herewith, or in any document or certificate furnished in connection herewith or therewith or pursuant hereto or thereto shall have been incorrect in any material respect at the time made; or (c)
Upon the occurrence of an Event of Default the Terminating Party may give notice of termination to the Terminated Party, identifying in reasonable detail the nature of the Event of Default. Thereupon, the Terminated party shall have 30 days to correct in all material respects the Event of Default (15 business days if the Event of Default consists in CLIENT‘s failure to pay outstanding sums within 15 business days of the date the payment was due). If the Page 345
Terminated party so cures the Event of Default, then the notice of termination shall be ineffective. If the Terminated party does not so cure the Event of Default within the aforementioned period, then this Agreement shall be terminated upon the expiration of such period (the ―Termination Date‖). CLIENT shall pay OUTSOURCER in full, within 15 business days of receipt of a final invoice from OUTSOURCER, for all services rendered up to and including the Termination Date. Phase Over: Prior to the expiration pursuant to its term of this Agreement, OUTSOURCER shall develop a plan for the orderly transition of all services provided by OUTSOURCER under this Agreement (the ―Transition Plan‖). Such Transition Plan shall be developed by OUTSOURCER in conjunction with OUTSOURCER‘s employees on site, the CLIENT‘s executives and administrators and such other persons as shall be designated by the CLIENT. The CLIENT shall fully cooperate with OUTSOURCER in order to develop the Transition Plan. The Transition Plan shall be completed no later than 90 days prior to expiration of this Agreement. It shall cover, inter alia, the training of CLIENT‘s personnel in the operation and maintenance of the systems used and operated by OUTSOURCER during the term of the Agreement. CLIENT shall notify OUTSOURCER of its acceptance of the Transition Plan within 14 days of receipt from OUTSOURCER. OUTSOURCER shall complete all transition activities associated with the orderly termination of this Agreement on or before the date the notice of termination becomes effective. OUTSOURCER shall effect the transition to the CLIENT. If due to OUTSOURCER‘s actions or omissions (i) the Transition Plan is not completed within the aforementioned period and the notice of termination becomes effective, or (ii) if the Transition Plan is completed and the notice of termination becomes effective but an orderly transition is not effected prior to the Termination Date, then OUTSOURCER shall continue to perform such services as may be required by the CLIENT, at no additional cost to CLIENT, in order to operate the CLIENT‘s computing system until such time as an orderly transition may be effected, but no later than 90 days after the Termination Date. In the event of termination of this Agreement following the occurrence of an Event of Default on the part of OUTSOURCER, OUTSOURCER shall immediately upon the Page 346
issuance of the notice of termination develop a Transition plan in accordance with the procedures set forth in paragraph (a)
Above except, however, that the Transition Plan shall be completed no later than 30 days after the date of the notice of termination. CLIENT shall notify OUTSOURCER of its acceptance of the Transition Plan within 14 days of receipt from OUTSOURCER. OUTSOURCER shall complete all Transition activities associated with the termination by reason of its default no later than 60 days following OUTSOURCER‘s receipt of CLIENT‘s acceptance of the Transition Plan.
In the event of termination of this Agreement following the occurrence of an Event of Default on the part of CLIENT, then OUTSOURCER may, at the sole option of CLIENT, continue to perform such services as may be required by the CLIENT, at its rates then in effect, in order to operate the CLIENT‘s computing system until such time as an orderly transition may be effected, but no later than 90 days after the Termination Date; provided, however, that if the Event of Default consists in CLIENT‘s failure to pay any sums due OUTSOURCER, then OUTSOURCER shall continue to perform such services as may be required by the CLIENT after the Termination Date, at OUTSOURCER‘s rates then in effect, only if the CLIENT pays for such services in advance. Funding: CLIENT hereby represents to OUTSOURCER that (i) the services to be performed by OUTSOURCER hereunder are necessary to CLIENT‘s efficient operation of its business and (ii) to the best of its knowledge, after investigation, it believes that sufficient funds may be obtained by it or appropriated for it in order to make all payments contemplated hereby. CLIENT shall make its best efforts to obtain, or cause to be appropriated as part of CLIENT‘s annual budget, sufficient funds to pay the sums due from time to time hereunder. Independent Contractor Status: OUTSOURCER and CLIENT acknowledge and agree that OUTSOURCER is and shall be an independent contractor; that neither OUTSOURCER nor any of its employees, representatives or agents is, or shall be deemed to be, an employee, partner or joint venture of the CLIENT; and that neither OUTSOURCER nor any of its employees, representatives Page 347
or agents shall be entitled to any employee benefits under any employee benefit plan, including medical, insurance and other similar plans, of the CLIENT. OUTSOURCER further acknowledges that the CLIENT will not withhold any amounts in respect to local taxes from amounts payable by the CLIENT hereunder and it shall be the exclusive responsibility of OUTSOURCER to pay all amounts due in respect of applicable federal, state and local taxes on such amounts. Client Policy and Procedures: OUTSOURCER agrees to comply with all applicable CLIENT policies and procedures, including but not limited to those regarding conditions of work, access to and use of CLIENT‘s offices, facilities, work space, support services, supplies, Data Processing Equipment and software and access. MISCELLANEOUS PROVISIONS Severability: Each provision of this Agreement shall be a separate and distinct covenant and, if declared illegal, unenforceable or in conflict with any governing law, shall not affect the validity of the remaining portion of this Agreement. Client’s Contract Administrator: The CLIENT shall appoint as Contract Administrator _________________, who will be delegated the duty and responsibility of maintaining liaison with OUTSOURCER and to oversee performance of this Agreement. OUTSOURCER’s Contract Administrator: The Outsourcer shall appoint as Contract Administrator __________________, who will be delegated the duty and responsibility of maintaining liaison with CLIENT and to oversee performance of this Agreement. Successors: This Agreement and all future amendments shall be binding on parties and their heirs, successors and assigns. The CLIENT agrees that OUTSOURCER may pledge or assign the net sums of money due and to become due to it hereunder to any bank, lending agency or institution as collateral security. Renewal/Extension:
Page 348
Upon written agreement of both parties entered into at least ninety (90) days prior to the expiration date, this Agreement may be extended for successive one year periods on the terms and conditions then in effect subject however, to such modifications as may be set forth in the extension agreement. Entire Agreement-Amendments: (a)
This Agreement, together with the Exhibits hereto, embodies the entire agreement and understanding between the parties hereto and supersedes all prior understandings and agreements, whether written or oral, between the parties hereto relating to the matter hereof.
(b) This Agreement (including the Exhibits hereto) may not be amended or modified except in writing signed by the parties hereto. Assignment This Agreement may not be assigned by either party without the prior written consent of the other party. For the avoidance of doubt, a change of control of OUTSOURCER shall not constitute an assignment for purposes hereof. Attorneys Fees In the event that suit is brought to enforce the provisions of this Agreement, the prevailing party, as determined by the judge, or arbitrator in the event of arbitration, shall be entitled to an award of reasonable attorneys fees, paralegals' fees and court costs, whether incurred before trial, at trial, during appeals, or in any mediation or arbitration required by a court.
COMMUNICATION PLAN
IT Services Communication Plan Function: Service Desk Status:
In draft Under Review Sent for Approval Page 349
Approved Rejected
Communication Plan for the Service Desk The document is not to be
Version:
<>
considered an extensive statement as its topics have to be generic enough to suit any reader
Release Date:
for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Service Desk function. This document provides a basis for completion within your own organization. This document contains suggestions regarding information to share with others. The document is deliberately concise and broken into communication modules. This will allow the reader to pick and choose information for e-mails, flyers, etc. from one or more modules if and when appropriate. This document was; Prepared by: On:
<>
Initial Communication And accepted by: On:
<>
Page 350
Sell the Benefits First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system, a new way of working. WHY? It is here that we need to promote and sell the benefits. However, be cautious of using generic words. Cite specific examples from your own organization that the reader will be able to relate to (to help develop specific examples contact [email protected] for competitive quotation). Generic Benefit statements Specific Organizational example
Service Desk provides a single point of contact for our customers and endusers
This is important because…
Allows us to manage all incidents and the registration of RFC‘s and Service requests.
Our last Customer Satisfaction Survey shows that our customers are not satisfied with the way we handle their calls for help…
Helps us to more effectively manage our communications to the business.
Apart from the obvious benefits of communication, the specific reason why we bring this up is…
The Service Desk will assist the other process areas with some operational activities….
IT staff are more and more buried under administration type activities and this is effecting the quality of their work. Wouldn‘t it be wonderful if….
The above Communication module (or elements of) was/were distributed; To: On: Service Desk Goal By: On:
<>
<>
Page 351
The Goal of the Service Desk
The Goal of the Service Desk can be promoted in the following manner. Official Goal Statement: Improving customer satisfaction due to the single point of contact for all customers and end users, thus providing clear communication lines to the IT department and back to the customers and end-users.
High visibility and wide channels of communication are essential in this function. Gather specific Service Desk Requirements from nominated personnel
(Special Tip: Beware of using only Managers to gain information from, as the resistance factor will be high)
Oversee the registration and resolution of incidents to ensure that the business needs of IT are not impacted more than necessary.
Provide relevant reports to nominated personnel.
(Special Tip: Beware of reporting only to Managers. If you speak to a lot of people regarding Service Delivery then you need to establish ways to report to these people the outcomes and progress of the discussions). Always bear in mind the ―so what‖ factor when discussing areas like goals and objectives. If you cannot honestly and sensibly answer the question ―so what‖ – then you are not selling the message in a way that is personal to the listener and gets their ―buy-in‖.
The above Service Desk Goals module was distributed; To: On: <> Service Desk Activities By: Intrusive & Hidden Activities On: <>
Page 352
The list of actions in this module may have a direct impact on end users. They will be curious as to why all of a sudden they have to call the Service Desk, rather than Joe Blog in IT, like they used to do. There could be an element of suspicion, so consider different strategies to overcome this initial scepticism. Information relating to costs may be a topic that would be held back from general communication. Failure to convince people of the benefits will mean total rejection of associate Call logging (activity forfall Incident Mgt.) categories: costs. If required, costs under several Set out clear procedures to submit Personnel – Service Desk staff incidents and requests. Set out clear procedures incidents areand escalated to other areas Accommodation – Physicalwhen location (Set-up ongoing) Verify (activity for(Set-up Conf. Mgt) CMDB Software – Tools and ongoing) As part the registration, classification and categorization of the incident Service Desk staff will ask of Hardware – Infrastructure (Set-up) specific verify CMDB information. questions Educationto – Training (Set-up and ongoing) Monitor progress Procedures – external consultants etc (Set-up) All incidents that come in to the Service Desk are monitored when they go through the various processes Management, Problem Change Management). monitoring is The costs (incident of implementing a Service Desk Management, will be outweighed by the benefits. ForThe example, important as the Service is also perception the first point contact for progress updates many organizations haveDesk a negative of of their IT department because of to customers and end-users. inaccessibility of the key people. End-user training In some organizations it is the Service Desk who organises and performs induction training, desktop training and other forms of end-user training. A well run Service Desk will make major inroads into altering that perception. Pro-Active activities As the Service Desk staff talk to the customers and end-users every day of the week, they should be able to point out to the other process owners where the areas for improvement are. Customer Satisfaction Surveys One of the communications to the customers is the regular customer satisfaction survey. The Service Desk staff develop the survey, send them out to the customers (or ask the questions on the phone) , process the responses and publish the results. Communication to customers Service Desk staff send out reports, notifications and memos to customers and end-users to: Notify them of the performance of the IT department Notify them of service (un)availability and release dates Update on incident/problem/change progress
Service Desk Planning Information regarding activities was distributed; To: On:
Costs <>
By: REPORTS KPI’s AND METRICS On: <>
IT Services Page 353
Reports and KPI Targets Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Reports and KPI Targets for the Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will
Release Date:
certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE ON SUITABLE KEY PERFORMANCE INDICATORS (KPIs) and REPORTS FOR MANAGEMENT for the Service Desk. This document provides a basis for completion within your own organization. This document contains suggestions regarding the measures that would be meaningful for this process. The metrics demonstrated are intended to show the reader the range of metrics that can be used. The message must also be clear that technology metrics must be heavily supplemented with non-technical and business focused metrics/KPI’s/measures. This document was; Prepared by: On:
<>
Key performance indicators (KPI’s) Continuous improvement requires that each process needs to have a plan about And accepted by: ―how‖ and ―when‖ to measure its own performance. While there can be no set On:
<>
guidelines presented for the timing/when of these reviews; the ―how‖ question can be answered with metrics and measurements. With regard to timing of reviews then factors such as resource availability, cost and ―nuisance factor‖ need to be accounted for. Many initiatives begin with good intentions to do regular reviews, but these fall away very rapidly. This is why the Page 354
process owner must have the conviction to follow through on assessments and meetings and reviews, etc. If the process manager feels that reviews are too seldom or too often then the schedule should be changed to reflect that. Establishing SMART targets is a key part of good process management. SMART is an acronym for:
Simple Measurable Achievable Realistic Time Driven Metrics help to ensure that the process in question is running effectively. With regard to the SERVICE DESK the following metrics and associated targets should be considered: Key Performance Indicator
Reduction in the Number of Complaints
Meetings held (on time) to review performance
Costs of Service Support decreasing.
Target Value (some examples) Expressed as a number, this would be a good indication of the Service Desk performance with regards to Customer Service. A reducing number here may be a good indication or at least the number should be stable. The more efficient the Service Desk, the quicker the restoration of
Time Frame/Notes/Who
Page 355
The percentage of SLA‘s being met due to proper management of the Incidents and Service Request by the Service Desk
Decrease in Resolution Time
Increase in First Line Resolution
service, thus reducing loss of productivity. The greater the number here, the more effective the Service Desk has become
Expressed as a number. If the resolution time is decreasing, then more information may be being captured at the Service Desk and the skill of the staff could be increasing An increase in First Line resolution will indicate a growing skill level at the Service Desk.
Others
Special Tip: Beware of using percentages in too many cases. It may even be better to use absolute values when the potential number of maximum failures is less than 100 Reports for Management Management reports help identify future trends and allow review of the ―health‖ of the function. Setting a security level on certain reports may be appropriate as may be categorizing the report as Strategic, Operational or Tactical.
Page 356
The acid test for a relevant report is to have a sound answer to the question; ―What decisions is this report helping management to make?‖ Management reports for the Service Desk should include:
Report Number of Phone Calls Received Number of Drop Outs / Hang Ups % of Tickets Resolved at First Line
Time Frame/Notes/Who Weekly, Monthly, Yearly Weekly, Monthly, Yearly Monthly, Yearly
Average Answer Time Break down of Calls per Department within the Organisation Service Desk Cost Analysis Calls by Customer: Top 10 Callers Service Desk Availability Customer Satisfaction Survey Report
Weekly, Monthly, Yearly Weekly, Monthly, Yearly Monthly, Yearly Weekly, Monthly, Yearly Weekly, Monthly, Yearly Weekly, Monthly, Yearly
Bonus Documents Service Desk Critical Success – Service Desk Representative Factors and Key Performance Indicators
Call Centre Critical Success Factors
Results ½ Year
Result Year End
Customer complaints <2 per month Client relations and conduct becoming a representative of the Call Centre Phones: Incoming:incidents logged 2:1 Resolution rate = 60% Average speed to answer <25 seconds >80% time live on phone
Yes Yes Yes Yes Yes Yes
Yes Yes Yes Yes Yes Yes
<1% calls that breach SLA in a month
Yes
Yes
E-mails/fax – date in, date logged Ticket ownership taken Shift change over form Reports – completed in required time frame Daily report out by 10:00am 10 proactive calls in a week
Yes Yes Yes Yes No
Yes Yes Yes Yes No
No
No
Key Performance Indicator Service Level Agreement
Measurement
Ticket Utilisation Daily Tasks
Weekly Tasks
Page 357
SERVICE DESK TECHNOLOGY
IT Services Service Desk Technology Selection Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Service Desk Technology Selection for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics
Release Date:
that have to be considered . This document serves as a reference for QUESTIONS THAT CAN HELP AN ORGANIZATION SELECT A TOOL for the Service Desk Function. This document provides a basis for completion within your own organization.
Service Desk Technology Selection
The following is a list of questions that can be asked of key stakeholders and staff involved with the Service Desk and Service Management, to help define the requirements for a Service Desk.
Page 358
The questions have been categorised into process segments. The questions below are there to generate thought. Some of the questions may actually be more applicable during a scope and design phase and may not be asked during the exercise. The purpose of this exercise is to gather the organizations requirements of what needs to be included in an IT Service Management tool. The requirements will be based on business needs and aligned to IT Service Management (ITSM) processes. Collated answers can be used as an ―ITSM Tool Requirements‖ document that can be used in future Request for Tenders (RFT). The document can also be provided to current tool vendors so that they may help the organization in changing their current tool environments to match the needs described in the ITSM Tool Requirements document. It is important that when the organization implements ITSM processes that they have a supporting tool, to make those processes work as effectively as possible with minimal cost and disruption to the business. The ITSM Tool Requirements document can list all the requirements discovered during the exercise. The document will not be a scope or design document detailing field requirements, naming of fields, technical effort or describe in any great detail each function within a tool.
Processes Service Level Management Does the tool need to have the ability to add service levels? At what level are service levels to be added? i.e. Configuration Level, Contact Level, Organisational Level, Departmental Level, Locations level? How do you want control of the service levels managed? How do you want escalation of warnings to be carried out? In what medium do you need this carried out? How many levels of escalation do you need? Does escalation need to be sent to process owners? Does escalation need to be sent to IT Functional Managers? Does escalation need to be sent to IT Functional staff? Does escalation need to be sent to Business Managers? How do you see this happening? Page 359
Do you need external escalation medium? (i.e. pager, mobile phone) How do you see the information contained in this area being needed or used in the areas listed below? Which report possibilities do you need? What sort of reports are you looking for? At which level do reports need to be created for? Do you need to be able to stop the clock ticking on SLA‘s? Incident Management Does the tool need to log incidents? How do you want incidents registered? Will the tool automatically detect incidents? What time stamping is needed? At what levels should categorisations take place? Severity, Priority, Urgency or Impact, or all? – ITIL uses Urgency and Impact to determine Priority. Does the tool need to automatically allocate these priorities? Based on what requirements? What warnings are needed? What information needs to be stored on the incident ticket? How do you expect numbering to work? Is there a need to record Configuration Items? Is there a need to record linked Changes, Problems and other tickets to an incident? Will an incident automatically escalate? Will incidents be resolved then closed? When closing an incident what notifications need to be sent? Do notifications need to be sent? What information do you want to capture during the resolution of an incident? What information do you want to capture during the closing of an incident? What information do you want to capture during the investigation of the incident? Who will have access to the incident tickets? What information will they need? Do different users of the system need to see different information? Does the tool need to automatically prioritise multiple incidents?
Page 360
Do you want to capture the status of an incident? At how many levels? Will this need to change automatically? Do you need to add notes to the incident? Do you want users to be able to change the display? How do you see ownerships of tickets working? Does the tool need to be able to show related records based on contact, configuration item, categories, locations, etc? Do you want the tool to have the option for users to report an incident via mail? Are there any other methods to log an incident? Do you want to see SLA information on the incident ticket? What reports do you want for incident management? Do you want to record user input and user time stamps on the tickets? I.e. who did what and when and what they did or what they changed? Will a knowledge management database be linked to incident management? Problem Management Does the tool need to support the ITIL process ―Problem Management‖? Does the tool need to register problem tickets as being separate from Incident tickets? Do you see this as another category? Does the tool need to register Known Errors? Do you see Known errors as just another category on an incident ticket? Do you see problem tickets and known error tickets being logged manually and / or automatically? What time stamping do you need on the ticket? How do you want problem, and known error tickets categorised? Do they need to be categorised in the same manner as incident tickets? Do you want the following information captured?
Status of problem
Function responsible for the solution of the problem
Actions already taken
Problem solution
Work arounds Page 361
Does the tool need to offer the option of dividing the total collection of problems into usable groups (e.g. equipment, network, data communications, work stations, etc.)? Do you want to capture the impact of the solution to parts of the IT-infrastructure or business? Do you need to capture Urgency, Impact and Priority on a problem ticket? What categorisations do you see on the ticket? Do you want escalations to occur from problem tickets? At what levels should escalations occur from problem tickets? Do escalations need to be sent to multiple people? Can escalations be sent to business people, i.e. contacts in the database? Will there be SLA‘s for problems? Do you need to record SLA data against problem tickets? What information do you need to capture on problem tickets? Consider the following:
Time spent for research and diagnosis per department or supplier?
Short description of actions taken?
Input of people needed?
Input of resources needed?
Costs?
Descriptions of actions taken?
Status?
Service?
Configuration Item?
Used time to solve a problem?
Time expired for open problems?
Expected time frames?
Will the problem tickets show links to other tickets? Will a knowledge management database be linked to problem management? Configuration Management Does the management tool support the ITIL process of Configuration Management? Do you need the tool to have an integrated CMDB (Configuration Management Database)? Page 362
How do you see the CMDB being populated? Who will maintain the CMDB? How do you see this working? What will the process be? Do you need the tool to be able to define a Configuration Item (CI), or will they be defined by a management tool? How do see the management tool defining a CI (e.g. hardware, software, network components, services etc.)? Do you want to capture relations between CI‘s? At what level? (This is where the strengths lie in Configuration Management tools and process) Do you need to see graphical representation of relationships? Do you need to status account for each CI? Do you want to record the lifecycle of the CI? At what level do you want to record CI? Do you need to record attributes of CI‘s? Do you have a list of key attributes? Will the management tool define the attributes or will a management tool do this? Do you want the tool to automatically create Asset ID‘s for CI‘s? Do you want to protect the CMDB from authorised use? Do you see only a select few people will have access to the CMDB? What levels of access will be needed on the CMDB? How do you see the CMDB relating to the other ITIL processes from a tool perspective? Do you expect to store associated documentation within the CMDB? Do you expect to manage licenses through the CMDB? Do you expect to record license information in the CMDB? Do you want the management tool to have the option to define and register a basic configuration and to save this separately (e.g. registration of the structure of (a part of) the IT infrastructure in a stable situation, so this can be consulted)? How do you see CI‘s being added or deleted? What naming conventions are needed? How will you determine the uniqueness of CI‘s? Does the tool allow unique identifiers? Do you need to capture model numbers, version numbers etc? What information do you see being captured against each CI? Page 363
Should each CI form be different for each other CI? Will each CI form only show data that is needed for that CI? Will there be multiple CI forms? Is there an interface with the Incident, Change, and Problem and Release tickets? Do you want cost information recorded? Do you want Maintenance information recorded? Will there be automatic alerts in the Configuration Management tool? What are the alerts that you want (e.g. changes, status changes, outages, maintenance schedules and tasks including responsibilities)? Will the CMDB be integrated into the tool? Change Management Does the management tool need to support ITIL processes? Does the management tool need a separate Change Management proposal? Does the management tool need to offer a standard change proposal that can be used by all employees within the organization? How do you want to classify Changes? Does the tool need to have a Forward Schedule of Changes? How do you see an FSC working within the tool? Do you need the tool to automatically save changes to the CMDB? Do you need to associate CI‘s to the RFC? Do you need to distinguish between different types of changes? Does the tool need to have different types of RFC forms for different changes? Does the tool need to have electronic signatures or a way for people to approve and disapprove changes? Some changes need multiple tasks carried out to achieve the change, how do you see this working in the management tool? Do you need the tool to register the causes of the change at such levels as, service levels, infrastructure, and organization? Do you expect to be able to record service levels against each RFC? What alerts do you see as needed in the tool? How do you see alerts being sent? What reports do you need to generate for Change Management? Does the business need to be involved in approving changes? What happens when a change is rejected? Page 364
What happens when a change is accepted? What information do you need to record on a change? Does the tool need to link to any other modules or processes? Will reports be transparent to other applications (e.g. MS Office)? Release Management Does the management tool need to support the process of Release Management? Does the management tool need to offer the option to indicate the status of a software product? What status indications do you need? Do you need a mechanism to prevent authorised and unauthorised status transitions? Does the management tool need to interface with a possible change management module? Why? Does it need to interface with a configuration management module? Why? How does the management tool structure the Definitive Software Library? How does the management tool structure the Definitive Hardware Store? Do you need the tool to have options regarding (total) overviews of software and breakdown facilities? Does the tool need to offer the option to perform semi-automatic fallback plans? Do you need to record the following information in the tool?
The number of licenses used
The users who use the applications
The version number of an application per user
The organisational criticism of an application
The names of applications installed
The version number of all applications installed
License numbers of all applications installed
Number / amount of spending necessary for a fallback
Input of people and resources, specified by activity
Developments and expectations for the future
Deviations from the planning and budget
How easy should it be to adapt or develop reports? Page 365
Do reports need to be transparent to other applications? Which other links do you require from Release Management to other ITIL processes? Availability Management Does the management tool need to support the ITIL processes? Should the tool offer an interface into the Service Level Management module? Should the management tool automatically generate a warning, should the agreed availability not be met? Do you need this warning to be sent to multiple process owners? Does it need to be sent to business management? How else do you see people being notified about a lack of availability? Does the management tool need to link to an incident or problem? Do you want the unavailability of (part of) the infrastructure be linked to an event? Does the tool need to be proactive in determining possible availability levels in the future? Do you want to capture the following information?
Name of the system
Time period in which the measurements are performed
Total realised availability per defined system
Data and times on which the defined system was not available
Causes for the temporary unavailability of the defined system
Solutions for availability of the define system
What reports do you want out of the tool? Which automatic links do you need in the tool? How will the tool integrate with other tools? Do you see this linking to the Configuration Management module? What information would you like to see passed between the modules? Capacity Management Does the management tool need to support the ITIL process? Does the management tool need to offer the option to generate the following information?
Name of the transaction processing system
Start and closing times Page 366
Total number of processes transactions
Total period of time the CPU was in use
Total number of I/Os
Average memory capacity
Total paging rate
Total swapping rate
Breakdown of above mentioned information.
Should the tool offer an interface into the Service Level Management module? Should the management tool automatically generate a warning, should the agreed capacity not be met? Do you need this warning to be sent to multiple process owners? Does it need to be sent to business management? How else do you see people being notified about a lack of capacity? Does the management tool need to link to an incident or problem? Do you want the capacity of (part of) the infrastructure be linked to an event? Does the tool need to be proactive in determining possible capacity levels in the future? What reports do you want out of the tool? Which automatic links do you need in the tool? How will the tool integrate with other tools? Do you see this linking to the Configuration Management module? What information would you like to see passed between the modules? Financial Management Does the management tool need to support the ITIL process ―Financial Management‖? Up to which detail level do you want the structure of costs per SLA, to be agreed with the customer, be rendered? Where do you expect to see costs captured? Against which records in the tool do you see cost being captured? Do you see cost as being automatically calculated in the tool? Do you expect to capture charge rates for resources? Do you expect to associate charge rates for resources? What links do you see Financial Mgt having with other modules in the tool? Page 367
Will there be penalties associated with breach of SLA and do you see the tool automatically capturing and calculating this? Do you expect to capture costs against Configuration Items? IT Service Continuity Management Does the management tool need to support the process of IT Service Continuity Management? How do you see a tool support the process of IT Service Continuity Management? Does the tool need to account or capture information regarding inadequate IT Continuity endangering the continuity of one or more business processes (not IT processes)? What links are needed from this process to the other ITIL processes? What other information do you see being captured?‖ Other Requirements The tool vendor is to explain the functionalities of the above processes as much as possible, in case these functionalities are not handled by the above questions. General Do you expect that a knowledge management tool well be integral to the overall tool? At what level should there be search screens? Do users need the ability to tailor / change the output of the searches (e.g. can they add or remove extra columns of information)? Do you need users to be able to create their own searches? List all and any module you believe need to be in the tool? Do you want to be able to determine how tickets are numbered? What sort of flexibility in ticket numbering do you expect? Does the management tool need to offer the option of ―job scheduling‖? How do you see job scheduling notification working? Do you need to print from the management tool? Technical Requirements Should the tool be able to be integrated with Active Directory to enable single sign on? Should the tool come with its own proprietary database? Should the tool integrate with any specific databases? Page 368
What other integration requirements are there? Who do you expect to tailor the tool? What level of technical complexity do you believe the tool should have? What level of IT expertise do you believe staff should have to tailor the tool? Requirements regarding support / maintenance What is your definition of support? What level of support do you require? Do you have time frames in mind for support? Do you want the support guaranteed via an SLA? Required Courses Are you going to send people on courses with regards to the tool? At what level do you require courses? How many people do you see going on courses? Are you going to rely on the vendor or the reseller to supply courses? What level of training do you people will need? Reports What reports do you believe need to come with the tool? Are you going to provide or do you have a third party reporting tool? What sort of reporting functionality do you require in the tool, if any? Do you want the vendor to supply you with a list of reports during a tender process? Security Does the tool need to offer the option of access control? What security requirements are needed in the tool? Does data need to be separated from functional groups? Does the organization have a naming and login convention or policy? Do you expect to be able to create your own naming conventions? Will anyone else external to the organization have access or need access to the tool and for what purposes? Do you want to be able to do the following?
Allocate users identification
Allocate (temporary) passwords
Define minimum password lengths
Command periodical changing of passwords Page 369
Register failed login attempts
Temporary close a workstation of (for example) three failed login attempts
Allocate users authorisations (access to certain parts of the IT infrastructure)
Allocate users right within the authorised domains
Assure that previous allocated users identifications will not be re-allocated
Implement the single sign-on principle
Reference Sites How many reference sites do you want from the vendor? What are you looking for in a reference site? Do you want to see a site where the implementations weren‘t successful? Do you want to be able to visit the reference sites? How long would you like to spend at each reference site? Implementation How much during an implementation do you expect from the organization? How long do you expect an implementation to take? Do you want an estimate from a vendor? How do you see costs being shown by the vendor? How do you expect the vendor to show and describe the size of the implementation?
Terminology Incident Management: Process responsible for restoring service back to the customer and end user with minimal disruption. Problem Management: Process responsible for removing the underlying causes of incidents to help improve the quality of IT Services. Configuration Management: The process of identifying, controlling, accounting and maintaining those IT components that help deliver a service to the customer and end users. Change Management: A process that provides a structure for managing changes in the IT infrastructure. Release Management: A process that provides a structure on how Software and associated hardware is released into the IT environment, minimising any disruption this may cause. Escalation: This term is considered to replace notification. You can have two types of escalation, functional and / or hierarchical. Functional: to the people that will solve Page 370
the problem, i.e. functional teams. Hierarchical: escalation to management, including managers of functional teams and managers of the business.
IMPLENTATION AND PROJECT PLAN
IT Services Implementation Plan/Project Plan Skeleton Outline Function: Service Desk Planning and
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
implementation for Service Desk This document as described provides guidance for the planning and implementation for a Service Desk as described under the ITIL framework. The document is not to be
Release Date:
considered an extensive plan as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered for planning and implementation of this process.
Initial planning When beginning the process planning the following items must be completed: CHECK
DESCRIPTION
or or date Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (e.g. Internal, outsourced, Page 371
hybrid) for the Service Desk. Assign a person to the key role of Service Desk manager/owner. This person is responsible for the Incident Management process and all associated systems. However, it is important to understand the differences and common conflicts that can occur between the two roles, for example, the Service Desk Manager may be concerned with call volumes and answer times, whereas the Incident Manager may be concerned with percentage of resolution at first point of call. Conduct a review of activities that would currently be considered as an activity associated with this process. Make notes and discuss the ―re-usability‖ of that activity. Three key activities of the Service Desk are:
Tracking, Monitoring and Co-ordinating of Incidents and Service Requests Incident Recording Incident Closure Create and gain agreement on a high-level associated process plans and a design for any associated process systems. NOTE: the plan need not be detailed. Too many initiatives get caught up in too much detail in the planning phase. KEEP THE MOMENTUM GOING. Review the finances required for the Service Desk as a whole and any associated systems (expenditure including people, software, hardware, accommodation). Don‘t forget that the initial expenditure may be higher than the ongoing costs. Don‘t forget annual allowances for systems maintenance or customizations to systems by development staff.
Create Strategic statements. Policy Statement The policy establishes the ―SENSE OF URGENCY‖ for the process. It helps us to think clearly about and agree on the reasons WHY effort is put into this process. An inability to answer this seemingly simple, but actually complex question is a major stepping stone towards successful implementation
Page 372
The most common mistake made is that reasons regarding IT are given as the WHY we should do this. Reasons like to make our IT department more efficient are far too generic and don‘t focus on the real issue behind why this process is needed. The statement must leave the reader in no doubt that the benefits of this process will be far reaching and contribute to the business in a clearly recognizable way. Objective Statement When you are describing the end or ultimate goal for a unit of activity that is about to be undertaken you are outlining the OBJECTIVE for that unit of activity. Of course the activity may be some actions for just yourself or a team of people. In either case, writing down the answer to WHERE will this activity to me/us/the organization is a powerful exercise. There are many studies that indicate the simple act of putting a statement about the end result expected onto a piece of paper, then continually referring to it, makes achieving that end result realistic. As a tip regarding the development of an objective statement; don‘t get caught up in spending hours on this. Do it quickly and go with your instincts or first thoughts – BUT THEN, wait a few days and review what you did for another short period of time and THEN commit to the outcome of the second review as your statement. Scope Statement In defining the scope of this process we are answering what activities and what ―information interfaces‖ does this process have. Don‘t get caught up in trying to be too detailed about the information flow into and out of this process. What is important is that others realize that information does in fact flow. For example, with regard to the SERVICE DESK process we can create a simple table such as: Service Desk Information flows
Process
Process
Information
Service Desk
to
Problem Management
Incidents with unknown causes
Problem
to
Service Desk
Known Errors, Work-around, quick fixes Page 373
Management
Service Desk
to
Change Management
Requests for Change
Change Management
to
Service Desk
Info on planned changes as the Service Desk may need to keep end users informed in the case of failed changes
Service Desk
to
Availability Management
Reports of availability-related incidents
Availability Management
to
Service Desk
Explanations regarding unacceptable levels of availability and solutions that the Service Desk can apply with end users.
Steps for Implementation. There can be a variety of ways to implement this process. For a lot of organizations a staged implementation may be suited. For others a ―big bang‖ implementation – due to absolute equality may be appropriate. In reality however, we usually look at implementation according to pre-defined priorities. Consider the following options and then apply a suitable model to your own organization or case study.
STEPS
NOTES/ /RELEVANCE/DATES/ WHO
Define the Objective and Scope for the Service Desk Establish and agree on a clear definition for the words ―Incident‖, ―Service / Support Request‖, ―Problem‖, ―Known Error‖ for the Service Desk staff. This is one of the most interesting aspects. It can be very difficult to get everyone to agree to a definition, and it can be very difficult to establish the correct understanding of the definition. However, get this right, and the rest of the Service Desk staff will find it easier to log tickets. Establish and Define Roles and Responsibilities for the process. Appoint a Service Desk Manager. Establish the physical environment for the Service Desk. Page 374
In running a 24 x 7 Service Desk it is important to be aware of local laws and customs with regards to minimum staffing levels during the night time shifts. Establish the Incident Management Process Tailor the ITSM Tools to suit the Incident Management process in line with the needs of the Service Desk. Establish and Define Relationship with all other processes. This is another key aspect of the Service Desk. Service Desk will record all incidents that may pertain to any of the other processes. For example, Incidents resulting from Availability, Incidents resulting from Security, Incidents resulting from IT Service Continuity Management, Incidents resulting from Changes or Releases, etc. Establish monitoring levels. This will rely heavily on your telecommunications ability. Such things as integrated CTI technology will help. Define reporting standards Publicize and market The priority selection has to be made with other factors in mind, such as competitive analysis, any legal requirements, and desires of ―politically powerful influencers‖.
Costs The cost of process implementation is something that must be considered before, during and after the implementation initiative. The following points and table helps to frame these considerations: (a variety of symbols have been provided to help you indicate required expenditure, rising or falling expenditure, level of satisfaction regarding costs in a particular area, etc. Initial Personnel Costs of people for initial design of process, implementation and ongoing support Accommodation Costs of housing new staff and any associated new equipment and space for documents or process related concepts. Software New tools required to support the process and/or the costs of migration from an existing tool or system to the new one. Maintenance costs
During
Ongoing
Page 375
Hardware New hardware required to support the process activities. IT hardware and even new desks for staff. Education Re-education of existing staff to learn new techniques and/or learn to operate new systems. Procedures Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel. In most cases, costs for Process / Function implementation have to be budgeted for (or allocated) well in advance of expenditure. Part of this step involves deciding on a charging mechanism (if any) for the new services to be offered. Build the team
Each process requires a process owner and in most situations a team of people to assist. The Service Desk process is one of the processes in the Service Support set that shows very visible benefits from the outset and is very influential in setting the perception of IT Services to its customers and end users. Of course a lot will be dependant on the timing of the implementation and whether it is to be staged or implemented as one exercise. Analyse current situation and FLAG Naturally there are many organizations that have many existing procedures/processes and people in place that feel that the activities of the Service Desk is already being done. It is critical to identify these systems and consider their future role as part of the new process definition. Examples of areas to review are: Area
Notes
Power teams Current formal procedures Current informal procedures Current role descriptions Existing organizational structure Spreadsheets, databases and other repositories Other…
Implementation Planning Page 376
After base decisions regarding the scope of the Service Desk and the overall planning activities are complete we need to address the actual implementation of the function. It is unlikely that there will not be some current activity or work being performed that would fit under the banner of this function. However, we can provide a comprehensive checklist of points that must be reviewed and done. Implementation activities for Service Desk
Activity
Notes/Comments/Time Frame/Who
Review current and existing Service Desk practices in greater detail. Make sure you also review current process connections from these practices to other areas of IT Service Delivery and Support. Review the ability of existing functions and staff. Can we ―reuse‖ some of the skills to minimize training, education and time required for implementation? Establish the accuracy and relevance of current associated processes, procedures and meetings. As part of this step if any information is credible, document the transition from the current format to any new format that is selected. Decide how best to select any vendor that will provide assistance in this area (including tools, external consultancy or assistance to help with initial high workload during the implementation). Establish a selection guideline for the evaluation and selection of tools required to support this area (i.e. Service Desk tools). Purchase and install tools required to support this function (i.e. Service Desk tool). Ensure adequate skills transfer and on-going support is catered for if external systems are selected. Create any required business processes interfaces for this function that can be provided by the automated tools (e.g. reporting – frequency, content). Document and get agreement on roles, responsibilities and training plans. Communicate with and provide necessary education and training for staff that covers the actual importance of the function and the intricacies of being part of the Service Desk itself. An important point to remember is that if the Service Desk is to be implemented at the same time as other processes then it is crucial that both implementation plans and importantly timing of work is complementary.
Cutover to new function
Page 377
The question of when a function actually starts is one that is not easy to answer. Most functional activity evolves without rigid starting dates and this is what we mean when we answer a question with ―that‘s just the way it‘s done around here‖. Ultimately we do want the new Service Desk to become the way things are done around here, so it may even be best not to set specific launch dates, as this will set the expectation that from the given date all issues relating to the Service Desk will disappear (not a realistic expectation).
Page 378
Service Desk Workbook
Service Desk INTRODUCTION ROADMAP Many organizations are looking to implement a Service Desk as a way to improve the structure and quality of the business. This document describes the contents of the Service Desk Workbook. The information found within the Workbook is based on the ITIL Version 3 framework, focusing on the Service Delivery phase of the Service Lifecycle and in particular the Service Desk function. The Workbook is designed to answer a lot of the questions about a Service Desk and provides you with useful guides and user-friendly templates. Presentations can be used to educate or be used as the basis for management presentations or when making business cases for Service Desk implementation. The additional information will enable you to improve your organizations knowledge base and provide practical, usable examples and templates for you to use in the implementation and maintenance of a Service Desk. The workbook serves to act as a starting point. It will give you a clear path to travel. It is designed to be a valuable source of information and activity.
The Service Desk Workbook:
Flows logically,
Is scalable,
Provides presentations, templates and documents,
Saves you time.
Page 379
Service Desk Workbook
Step 1 Start by reviewing the PowerPoint presentations in the following order: 1. Service Desk ITIL V3 Presentation These presentations will give you a good knowledge and understanding of all the terms, activities and concepts required within the Service Desk function. They can also be used as the basis for management presentations or when making a formal business case for Service Desk implementation. Make sure you pay close attention to the notes pages, as well as the slides, as references to further documents and resources are highlighted here. Step 2 If you did not look at the supporting documents and resources when prompted during the PowerPoint presentations, do this now. Below is an itemized list of the supporting documents and resources for easy reference. You can use these documents and resources within your own organization or as a template to help you in prepare your own bespoke documentation.
Service Desk ITIL V3:
Service Desk - Roles and Responsibilities
Service Desk Technology
Outsourcing Contract Template
Service Desk- Metrics
Communication Plan
Business Flyers
ITIL V3 Incident Management Process Flow Diagram
Page 380
Service Desk Workbook
Step 3 Alternatively, you can continue by working through the additional documents:
Service Desk - Objectives and Goals
Policies objectives & scope
Implementation Plan & Project Plan
Business Justification document
This time; with the focus on your organization. This will help you ascertain the Service Desk maturity for your organization. You will able to identify gaps and areas of attention and/or improvement. The supporting documents and resources found within this workbook will help you fill these gaps by giving you a focused, practical and user-friendly approach to implementing and maintaining a Service Desk.
Page 381
Service Desk Workbook
SERVICE DESK ITIL V3 PRESENTATION
GOAL:
To support the agreed IT service provision by ensuring the accessibility
and availability of the IT-organization and by performing various supporting activities.
Service Desk Types: Relates to the skill level and resolution rate for service calls. Service Desk Organizational Structure: Relates to the physical organization of the service desk Incident: Any event which is not part of the standard operation of a service and which causes, or may cause an interruption to, or a reduction in the quality of that Page 382
Service Desk Workbook
service. A failure of a CI that has not yet affected service is also classified as an incident. Service Request: Request for information or status of a service (not related to loss of service) Includes Standard Changes. Eg. Contact details, Service availability, request for common software. Request for Change: Request to Move, Add, Change (MAC) Eg. Asking for changes to functionality of applications or supporting infrastructure.
Continued.. Access Rights: User or user groups permission rights to use a service, and the prevention of access to non-authorized users. Effectively the execution of both Availability and Information Security management, in that is enable the organisation to manage CIA of the organization‘s data and intellectual property.
Page 383
Service Desk Workbook
The main Service Desk role is provide a single point of contact (SPOC) for users. QUESTION: Why do you want to avoid users calling the various support groups?
To minimize/avoid users calling support groups directly
Control of call end-end
consistency of service
more (cost) effective use of IT staff
You can find more information on the activities of the Service Desk in the ITIL V3 Incident Management Process Flow Diagram, available on page 87 in this workbook.
Page 384
Service Desk Workbook
The 3 types of Service Desks are: Call Centre: Handling/logging of large volumes of calls, Help Desk: Manage and co-ordinate incidents, Service Desk: A wide variety of services offered,
Benefits of this structure: Local user knowledge, language/country specific etc Disadvantages of this structure:
Page 385
Service Desk Workbook
Costs of running multiple service desks, inconsistency of service, reporting, lack of knowledge and skill sharing etc
Benefits of this structure: Reduced operational costs, Improved usage of available resources, Consistency of call handling. Disadvantages of this structure: Costs of handling 24x7 or different time zones, lack of local knowledge, possible gaps in language and culture.
Benefits of this structure:
Page 386
Service Desk Workbook
Global organizations, 24x7 support, Reduced operational costs, Improved usage of available resources. Disadvantages of this structure: Cost of implementation (technology), consistency of service, reporting, skill sharing.
Benefits of this structure: Consistent service, ability to handle multiple time zones and language. Disadvantages of this structure: Cost of technology, using single language for multiple regions.
Page 387
Service Desk Workbook
Many organizations find it beneficial to offer ―Self Help‖ capabilities to their users. The technology should therefore support this capability with some form of web frontend allowing web pages to be defined offering a menu-driven range of self help and service requests – with a direct interface into the back-end process-handling software.
Regardless of the reasons for, or the extent of, the outsourcing contract, it is vital that the organization retains responsibility for the activities and services provided by the Service Desk. The organization is ultimately responsible for the outcomes of the decision and must therefore determine what service the outsourcer provides, not the other way around.
There are some safeguards that are needed to ensure that the outsourced Service Desk works effectively and efficiently with the organization‘s other IT teams and Page 388
Service Desk Workbook
departments and that end-to end Service Management control is maintained (particularly important if seeking ISO/IEC 20000 certification). Tools are consistent with those used in the customer organization. Outsourcing is often seen as an opportunity to replace outdated or inadequate tools, only to find that there are severe integration problems between the new tool and the legacy tools and processes.
It is often a challenge integrating processes and tools in a less mature organization with those in a more mature organization. A common but incorrect assumption is that the maturity of the one organization will somehow result in higher maturity in the other. Active involvement to ensure alignment of processes and tools is essential to a smooth transition and ongoing management of services between the internal and external organizations. In fact, if this is not directly addressed, it could result in the failure of the contract.
Page 389
Service Desk Workbook
Further examples of SLA targets can be found in the Service Desk Metrics document
In cases where the Service Desk is located off-shore, not all of these measures will be possible. However, the need for training and communication of the Service Desk staff is still critical, even more so in cases where there are language and cultural differences.
Page 390
Service Desk Workbook
Training programs focused on cultural understanding of the customer market
Language skills – especially the understanding of idiomatic use of the language in the customer market. This is not so that the Service Desk staff sound like naives of the customer‘s country (that type of insincerity is very quickly detected by customers), but to facilitate better understanding of the customer and the better to appreciate their priorities.
Regular visits by representatives of the customer organization to provide training and appropriate feedback directly to the Service Desk Manager.
Training in the use of the customer organization tools and methods of work. This is especially effective if similar training materials are presented by the same instructors as those used by the customer organization.
Page 391
Service Desk Workbook
Data that is related specifically to performance of employees of the outsourcing company will remain the property of that company, which is often legally prevented from sharing the data with the customer organization. This may also be true of other data that is used purely for the internal management of the Service Desk, such as head count, optimization activities, Service Desk cost information etc. All reporting requirements and issues around ownership of data must be specified in the underpinning contract with the company providing the outsourcing service.
Page 392
Service Desk Workbook
SUPPORTING DOCUMENTS Through the documents, look for text surrounded by << and >> these are indicators for you to create some specific text.
Watch also for highlighted text which provides further guidance and instructions. Service Desk Role and Responsibilities The key to effective ITSM is ensuring that there is clear accountability and roles defined to carry out the practice of Service Operation. A role is often tied to a job description or work group description but does not necessarily need to be filled by one individual. The size of an organization, how it is structured, the existence of external partners and other factors will influence how roles are assigned. Whether a particular role is filled by a single individual or shared between two or more, the importance is the consistency of accountability and execution, along with the interaction with other roles in the organization. The following roles are needed for the Service Desk. Service Desk Manager In large organizations where the Service Desk is of a significant size, a Service Desk Manager role may be justified with the Service Desk Supervisor(s) reporting to him or her. In such cases this role may take responsibility for some of the activities listed above and may additionally perform the following activities:
Manage the overall desk activities, including the supervisors
Act as a further escalation point for the supervisor(s)
Take on a wider customer-services role
Report to senior managers on any issue that could significantly impact the business
Attend Change Advisory Board meetings
Take overall responsibility for incident and Service Request handling on the Service Desk. This could also be expanded to any other activity taken on by the Service Desk – e.g. monitoring certain classes of event.
Note: in all cases, clearly defined job descriptions should be drafted and agreed so that specific responsibilities are known. Page 393
Service Desk Workbook
Service Desk Supervisor In very small desks it is possible that the senior Service Desk Analyst will also act as the Supervisor – but in larger desks it is likely that a dedicated Service Desk Supervisor role will be needed. Where shift hours dictate it, there may be two or more post-holders who fulfill the role, usually on an overlapping basis. The Supervisor‘s role is likely to include:
Ensuring that staffing and skill levels are maintained throughout operational hours by managing shift staffing schedules, etc.
Undertaking HR activities as needed
Acting as an escalation point where difficult or controversial calls are received
Production of statistics and management reports
Representing the Service Desk at meetings
Arranging staff training and awareness sessions
Liaising with senior management
Liaising with Change Management
Performing briefings to Service Desk staff on changes or deployments that may affect volumes at the Service Desk
Assisting analysts in providing first-line support when workloads are high, or where additional experience is required.
Service Desk Analysts The primary Service Desk Analyst role is that or providing first-level support through taking calls and handling the resulting incidents or Service Requests using the Incident Reporting and Request Fulfillment processes, in line with the Service Desk objectives. Super Users In summary, this role will consist of business users who act as liaison points with IT in general and the Service Desk in particular. The role of Super User can be summarized as follows:
To facilitate communication between IT and the business at an operational level
To reinforce expectations of users regarding what Service Levels have been agreed Page 394
Service Desk Workbook
Staff training for users in their area
Providing support for minor incidents or simple request fulfillment
Involvement with new releases and rollouts.
Service Desk Technology
IT Services Service Desk Technology Selection Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Service Desk Technology Selection for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. Page 395
Service Desk Workbook
This document serves as a reference for QUESTIONS THAT CAN HELP AN ORGANIZATION SELECT A TOOL for the Service Desk Function. This document provides a basis for completion within your own organization.
Service Desk Technology Selection The following is a list of questions that can be asked of key stakeholders and staff involved with the Service Desk and Service Management, to help define the requirements for a Service Desk.
The questions have been categorized into process segments. The questions are designed to generate thought. Some of the questions may actually be more applicable during a scope and design phase and may not be asked during the exercise. The purpose of this exercise is to gather the organization‘s requirements of what needs to be included in an IT Service Management tool. The requirements will be based on business needs and aligned to IT Service Management (ITSM) processes. Collated answers can be used as an ―ITSM Tool Requirements‖ document that can be used in future Request for Tenders (RFT). The document can also be provided to current tool vendors so that they may help the organization in changing their current tool environments to match the needs described in the ITSM Tool Requirements document. It is important that when the organization implements ITSM processes that they have a supporting tool, to make those processes work as effectively as possible with minimal cost and disruption to the business. The ITSM Tool Requirements document can list all the requirements discovered during the exercise. The document will not be a scope or design document detailing field requirements, naming of fields, technical effort or describe in any great detail each function within a tool. Page 396
Service Desk Workbook
Processes Service Level Management Does the tool need to have the ability to add service levels? At what level are service levels to be added? i.e. Configuration Level, Contact Level, Organizational Level, Departmental Level, Locations level? How do you want control of the service levels managed? How do you want escalation of warnings to be carried out? In what medium do you need this carried out? How many levels of escalation do you need? Does escalation need to be sent to process owners? Does escalation need to be sent to IT Functional Managers? Does escalation need to be sent to IT Functional staff? Does escalation need to be sent to Business Managers? How do you see this happening? Do you need external escalation medium? (i.e. pager, mobile phone) How do you see the information contained in this area being needed or used in the areas listed below? Which report possibilities do you need? What sort of reports are you looking for? At what level do reports need to be created for? Do you need to be able to stop the clock ticking on SLAs? Incident Management Does the tool need to log incidents? How do you want incidents registered? Page 397
Service Desk Workbook
Will the tool automatically detect incidents? What time stamping is needed? At what levels should categorization take place? Severity, Priority, Urgency or Impact, or all? – ITIL uses Urgency and Impact to determine Priority. Does the tool need to automatically allocate these priorities? Based on what requirements? What warnings are needed? What information needs to be stored on the incident ticket? How do you expect numbering to work? Is there a need to record Configuration Items? Is there a need to record linked Changes, Problems and other tickets to an incident? Will an incident automatically escalate? Will incidents be resolved then closed? When closing an incident what notifications need to be sent? Do notifications need to be sent? What information do you want to capture during the resolution of an incident? What information do you want to capture during the closing of an incident? What information do you want to capture during the investigation of the incident? Who will have access to the incident tickets? What information will they need? Do different users of the system need to see different information? Does the tool need to automatically prioritize multiple incidents? Do you want to capture the status of an incident? At how many levels? Will this need to change automatically? Page 398
Service Desk Workbook
Do you need to add notes to the incident? Do you want users to be able to change the display? How do you see ownerships of tickets working? Does the tool need to be able to show related records based on contact, configuration item, categories, locations, etc? Do you want the tool to have the option for users to report an incident via mail? Are there any other methods to log an incident? Do you want to see SLA information on the incident ticket? What reports do you want for incident management? Do you want to record user input and user time stamps on the tickets? I.e. who did what and when and what they did or what they changed? Will a knowledge management database be linked to incident management? Problem Management Does the tool need to support the ITIL process ―Problem Management‖? Does the tool need to register problem tickets as being separate from Incident tickets? Do you see this as another category? Does the tool need to register Known Errors? Do you see Known Errors as just another category on an incident ticket? Do you see problem tickets and known error tickets being logged manually and / or automatically? What time stamping do you need on the ticket? How do you want problem, and known error tickets categorized? Do they need to be categorized in the same manner as incident tickets? Do you want the following information captured? Page 399
Service Desk Workbook
Status of problem
Function responsible for the solution of the problem
Actions already taken
Problem solution
Work around
Does the tool need to offer the option of dividing the total collection of problems into usable groups (e.g. equipment, network, data communications, work stations, etc.)? Do you want to capture the impact of the solution to parts of the IT-infrastructure or business? Do you need to capture Urgency, Impact and Priority on a problem ticket? What categorizations do you see on the ticket? Do you want escalations to occur from problem tickets? At what levels should escalations occur from problem tickets? Do escalations need to be sent to multiple people? Can escalations be sent to business people, i.e. contacts in the database? Will there be SLAs for problems? Do you need to record SLA data against problem tickets? What information do you need to capture on problem tickets? Consider the following:
Time spent for research and diagnosis per department or supplier?
Short description of actions taken?
Input of people needed?
Input of resources needed?
Costs?
Descriptions of actions taken?
Status?
Service?
Configuration Item? Page 400
Service Desk Workbook
Time to solve a problem?
Time expired for open problems?
Expected time frames?
Will the problem tickets show links to other tickets?
Will a knowledge management database be linked to problem management?
Service Asset & Configuration Management Does the management tool support the ITIL process of Configuration Management? Do you need the tool to have an integrated CMDB (Configuration Management Database)? How do you see the CMDB being populated? Who will maintain the CMDB? How do you see this working? What will the process be? Do you need the tool to be able to define a Configuration Item (CI), or will they be defined by a management tool? How do see the management tool defining a CI (e.g. hardware, software, network components, services etc.)? Do you want to capture relations between CIs? At what level? (This is where the strengths lie in Configuration Management tools and process) Do you need to see graphical representation of relationships? Do you need a status account for each CI? Do you want to record the lifecycle of the CI? At what level do you want to record CI? Do you need to record attributes of CIs? Do you have a list of key attributes? Will the management tool define the attributes or will a management tool do this? Do you want the tool to automatically create Asset ID‘s for CIs? Do you want to protect the CMDB from unauthorized use? Will only a select few people will have access to the CMDB? Page 401
Service Desk Workbook
What levels of access will be needed to the CMDB? How do you see the CMDB relating to the other ITIL processes from a tool perspective? Do you expect to store associated documentation within the CMDB? Do you expect to manage licenses through the CMDB? Do you expect to record license information in the CMDB? Do you want the management tool to have the option to define and register a basic configuration and to save this separately (e.g. registration of the structure of (a part of) the IT infrastructure in a stable situation, so this can be consulted)? How do you see CIs being added or deleted? What naming conventions are needed? How will you determine the uniqueness of CIs? Does the tool allow unique identifiers? Do you need to capture model numbers, version numbers etc? What information do you see being captured against each CI? Should each CI form be different for each other CI? Will each CI form only show data that is needed for that CI? Will there be multiple CI forms? Is there an interface with the Incident, Change, Problem and Release tickets? Do you want cost information recorded? Do you want Maintenance information recorded? Will there be automatic alerts in the Configuration Management tool? What are the alerts that you want (e.g. changes, status changes, outages, maintenance schedules and tasks including responsibilities)? Will the CMDB be integrated into the tool? Change Management Does the management tool need to support ITIL processes? Page 402
Service Desk Workbook
Does the management tool need a separate Change Management proposal? Does the management tool need to offer a standard change proposal that can be used by all employees within the organization? How do you want to classify Changes? Does the tool need to have a Forward Schedule of Changes? How do you see an FSC working within the tool? Do you need the tool to automatically save changes to the CMDB? Do you need to associate CIs to the RFC? Do you need to distinguish between different types of changes? Does the tool need to have different types of RFC forms for different changes? Does the tool need to have electronic signatures or a way for people to approve and disapprove changes? Some changes need multiple tasks carried out to achieve the change, how do you see this working in the management tool? Do you need the tool to register the causes of the change at such levels as, service levels, infrastructure, and organization? Do you expect to be able to record service levels against each RFC? What alerts do you see as needed in the tool? How do you see alerts being sent? What reports do you need to generate for Change Management? Does the business need to be involved in approving changes? What happens when a change is rejected? What happens when a change is accepted? What information do you need to record on a change?
Page 403
Service Desk Workbook
Does the tool need to link to any other modules or processes? Will reports be transparent to other applications (e.g. MS Office)? Release & Deployment Management Does the management tool need to support the process of Release Management? Does the management tool need to offer the option to indicate the status of a software product? What status indications do you need? Do you need a mechanism to control authorized and unauthorized status transitions? Does the management tool need to interface with a possible change management module? Why? Does it need to interface with a configuration management module? Why? How does the management tool structure the Definitive Software Library? How does the management tool structure the Definitive Hardware Store? Do you need the tool to have options regarding (total) overviews of software and breakdown facilities? Does the tool need to offer the option to perform semi-automatic fallback plans? Do you need to record the following information in the tool?
The number of licenses used
The users who use the applications
The version number of an application per user
The criticality of an application
The names of applications installed
The version number of all applications installed
License numbers of all applications installed
Number / amount of spending necessary for a fallback
Input of people and resources, specified by activity
Developments and expectations for the future
Page 404
Service Desk Workbook
Deviations from the planning and budget
How easy should it be to adapt or develop reports? Do reports need to be transparent to other applications? Which other links do you require from Release Management to other ITIL processes? Availability Management Does the management tool need to support the ITIL processes? Should the tool offer an interface into the Service Level Management module? Should the management tool automatically generate a warning, should the agreed availability not be met? Do you need this warning to be sent to multiple process owners? Does it need to be sent to business management? How else do you see people being notified about a lack of availability? Does the management tool need to link to an incident or problem? Do you want the unavailability of (part of) the infrastructure to be linked to an event? Does the tool need to be proactive in determining possible availability levels in the future? Do you want to capture the following information?
Name of the system
Time period in which the measurements are performed
Total realized availability per defined system
Data and times on which the defined system was not available
Causes for the temporary unavailability of the defined system
Solutions for availability of the define system
What reports do you want out of the tool? Which automatic links do you need in the tool? How will the tool integrate with other tools? Page 405
Service Desk Workbook
Do you see this linking to the Configuration Management module? What information would you like to see passed between the modules? Capacity Management Does the management tool need to support the ITIL process? Does the management tool need to offer the option to generate the following information?
Name of the transaction processing system
Start and closing times
Total number of process transactions
Total period of time the CPU was in use
Total number of I/Os
Average memory capacity
Total paging rate
Total swapping rate
Breakdown of above mentioned information.
Should the tool offer an interface into the Service Level Management module? Should the management tool automatically generate a warning, should the agreed capacity not be met? Do you need this warning to be sent to multiple process owners? Does it need to be sent to business management? How else do you see people being notified about a lack of capacity? Does the management tool need to link to an incident or problem? Do you want the capacity of (part of) the infrastructure to be linked to an event? Does the tool need to be proactive in determining possible capacity levels in the future? What reports do you want out of the tool? Which automatic links do you need in the tool? How will the tool integrate with other tools? Page 406
Service Desk Workbook
Do you see this linking to the Configuration Management module? What information would you like to see passed between the modules? Financial Management Does the management tool need to support the ITIL process ―Financial Management‖? To what detail level do you want the structure of costs per SLA to be rendered? Where do you expect to see costs captured? Against which records in the tool do you see cost being captured? Do you see cost as being automatically calculated in the tool? Do you expect to capture charge rates for resources? Do you expect to associate charge rates for resources? What links do you see Financial Mgt having with other modules in the tool? Will there be penalties associated with breach of SLA and do you see the tool automatically capturing and calculating this? Do you expect to capture costs against Configuration Items? IT Service Continuity Management Does the management tool need to support the process of IT Service Continuity Management? How do you see a tool supporting the process of IT Service Continuity Management? Does the tool need to account or capture information regarding inadequate IT Continuity endangering the continuity of one or more business processes (not IT processes)? What links are needed from this process to the other ITIL processes? What other information do you see being captured?‖ Other Requirements Page 407
Service Desk Workbook
The tool vendor is to explain the functionality of the above processes as much as possible, in case the functionality are not handled by the above questions. General Do you expect that a knowledge management tool well be integral to the overall tool? At what level should there be search screens? Do users need the ability to tailor / change the output of the searches (e.g. can they add or remove extra columns of information)? Do you need users to be able to create their own searches? List all and any module you believe need to be in the tool. Do you want to be able to determine how tickets are numbered? What sort of flexibility in ticket numbering do you expect? Does the management tool need to offer the option of ―job scheduling‖? How do you see job scheduling notification working? Do you need to print from the management tool? Technical Requirements Should the tool be able to be integrated with Active Directory to enable single sign on? Should the tool come with its own proprietary database? Should the tool integrate with any specific databases? What other integration requirements are there? Who do you expect to tailor the tool? What level of technical complexity do you believe the tool should have? What level of IT expertise do you believe staff should have to tailor the tool? Requirements regarding support / maintenance Page 408
Service Desk Workbook
What is your definition of support? What level of support do you require? Do you have time frames in mind for support? Do you want the support guaranteed via an SLA? Required Courses Are you going to send people on courses with regards to the tool? At what level do you require courses? How many people do you see going on courses? Are you going to rely on the vendor or the reseller to supply courses? What level of training do you people will need? Reports What reports do you believe need to come with the tool? Are you going to provide or do you have a third party reporting tool? What sort of reporting functionality do you require in the tool, if any? Do you want the vendor to supply you with a list of reports during a tender process? IT Information Security Does the tool need to offer the option of access control? What security requirements are needed in the tool? Does data need to be separated from functional groups? Does the organization have a naming and login convention or policy? Do you expect to be able to create your own naming conventions? Will anyone else external to the organization have access or need access to the tool and for what purposes? Page 409
Service Desk Workbook
Do you want to be able to do the following?
Allocate users identification
Allocate (temporary) passwords
Define minimum password lengths
Command periodical changing of passwords
Register failed login attempts
Temporary close a workstation of (for example) three failed login attempts
Allocate users authorizations (access to certain parts of the IT infrastructure)
Allocate user rights within the authorized domains
Assure that previous allocated users identifications will not be reallocated
Implement the single sign-on principle
Reference Sites How many reference sites do you want from the vendor? What are you looking for in a reference site? Do you want to see a site where the implementations weren‘t successful? Do you want to be able to visit the reference sites? How long would you like to spend at each reference site? Implementation How much time during an implementation do you expect from the organization? How long do you expect an implementation to take? Do you want an estimate from a vendor? How do you see costs being shown by the vendor? How do you expect the vendor to show and describe the size of the implementation? Terminology Page 410
Service Desk Workbook
Incident Management: To restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. Problem Management: To minimize the adverse impact of Incidents and Problems on the business that are caused by errors within the IT infrastructure, and to prevent the recurrence of Incidents related to these errors. Defined as two major processes: Reactive Problem Management, Proactive Problem Management ** Service Asset & Configuration Management: To support the agreed IT service provision by managing, storing and providing information about Configuration Items (CI‘s) and Service Assets throughout their life cycle. This process manages the service assets and Configuration Items in order to support the other Service Management processes. Change Management: To ensure that standardized methods and procedures are used for efficient and prompt handling of all Changes, in order to minimize the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organization. Release Management: To deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to Service Operation. Escalation: This term is considered to replace notification. You can have two types of escalation, functional and / or hierarchical. Functional: to the people that will solve the problem, i.e. functional teams. Hierarchical: escalation to management, including managers of functional teams and managers of the business.
Service Desk Outsourcing Template
IT Services Outsourcing Template Page 411
Service Desk Workbook
Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Service Desk Outsourcing Template The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a TEMPLATE FOR ENGAGING AN EXTERNAL PARTY TO MANAGE A SERVICE DESK. This document provides a basis for completion within your own organization. This document contains prompts and text that would be meaningful for this activity.
IT OUTSOURCING SERVICE AGREEMENT BETWEEN _________________________ AND _______________________ THIS AGREEMENT between _________________ (―OUTSOURCER‖) and
Page 412
Service Desk Workbook
________________________ (―CLIENT‖) is made this ____ day of _________, ____. WHEREAS, the CLIENT desires to purchase IT management and operation outsourcing services in support of the management and operation of the company‘s Information Technology need ; and WHEREAS, OUTSOURCER wishes to provide the total outsourcing services described herein in accordance with the terms and conditions hereof; NOW THEREFORE, in consideration of the payments herein agreed to be made and the covenants and agreement herein contained, the parties hereto, intending to be legally bound, hereby agree to the following: 1. SERVICES
Starting on the Effective Date (as defined in Section 3.1), OUTSOURCER shall perform the IT Outsourcing services described in this Agreement and Exhibit A, attached hereto and made a part hereof (―Scope of Services‖). 2. COST FOR SERVICES
The costs for services to be provided by OUTSOURCER are set forth in Exhibit B attached hereto and made a part hereof. Such costs shall be subject to a cost of living adjustment, as more fully set forth in Exhibit B. 3. TERMS AND CONDITIONS 3.1 Term:
This Agreement shall commence on _____________________, 19___ (the ―Effective Date‖), and terminate on _______________________, 19___. 3.2 Invoices and Payment Terms:
Page 413
Service Desk Workbook
3.2.1
OUTSOURCER shall submit monthly invoices to the CLIENT. Invoices shall be issued before services are rendered by OUTSOURCER and shall be submitted by OUTSOURCER at least 30 business days before payment is due by the CLIENT.
3.2.2
Exhibit C indicates the monthly amounts to be paid by the CLIENT for OUTSOURCER staff services and expenses. The CLIENT shall pay according to this schedule. Payment not received within [five (5)] days of the due date will be subject to an interest charge. All interest charges will be computed at the current prime rate.
3.3 Data Processing Equipment and Supplies:
Subject to Section 3.9(c) below, as between the parties, the CLIENT reserves and retains the right, title and interest in any and all computing equipment, software, systems, data, output and other materials or property except that which is furnished by OUTSOURCER and is not developed pursuant to this Agreement, which retains such rights itself. Upon expiration or earlier termination of this Agreement, OUTSOURCER shall relinquish to CLIENT the use of equipment provided by CLIENT in as good condition as when turned over to OUTSOURCER, reasonable wear and tear excepted. 3.3.2
All costs relating to data processing equipment and supplies for the CLIENT‘s computer functions shall be the responsibility of the CLIENT.
3.3.3
All costs relating to OUTSOURCER‘s consultants fee, salaries, Medical, Insurance, recruitment fee, training expenses shall be the responsibility of the OUTSOURCER.
3.3.4
The CLIENT shall also provide to OUTSOURCER, at no charge to OUTSOURCER subject to Section 3.17 CLIENT Policy and Procedures, in order to allow OUTSOURCER to perform under this Agreement.
(a)
All utilities, including any special power and air conditioning needed, as determined solely by CLIENT, to operate the CLIENT‘s data processing equipment and storage of computer supplies;
Page 414
Service Desk Workbook
(b)
Storage, in an area removed from the data processing site, for historical data and backup material that may be needed to reconstruct data files in the event working files are destroyed by natural disasters, fire, riots or other causes;
(c)
Computing supplies such as paper, forms, ribbons, tapes, disk packs and microfilm; and
(d)
Security, fire control equipment and janitorial support for the CLIENT‘s data processing facilities.
3.4 Work Space:
At no charge to OUTSOURCER, subject to Section 3.17 CLIENT Policy and Procedures, the CLIENT shall provide OUTSOURCER, with an appropriately furnished, conveniently located office or other suitable work space for use by the OUTSOURCER staff in performing work under this Agreement. Also at no charge to OUTSOURCER, the CLIENT shall provide office supplies, telephone service and reproduction, telecommunications and office equipment reasonable and necessary to support OUTSOURCER‘s staff and performance of this Agreement. 3.5 Use of Data Processing Equipment:
At no charge to OUTSOURCER, subject to Section 3.17 CLIENT Policy and Procedures, the CLIENT shall provide OUTSOURCER access to all equipment, equipment services, programs and supplies necessary to support the computing needs of the CLIENT. The CLIENT shall provide OUTSOURCER‘s staffs access to all such equipment so that OUTSOURCER may perform its obligations under this Agreement including, but not limited to, operating all such equipment. 3.6 Use of Software and Access to Personnel:
Page 415
Service Desk Workbook
For purposes of performance under this Agreement, OUTSOURCER shall have complete access to, shall operate and shall, subject to CLIENT‘s approval and obligations of CLIENT under third party agreements, have the right to modify or alter all CLIENT software programs and related material, pursuant to the Scope of Services. OUTSOURCER shall also have reasonable access to the CLIENT‘s management, professional and operating personnel necessary for performance under this Agreement, as well as to all materials, records, discs, tapes or other information necessary to perform the services contemplated herein. OUTSOURCER and CLIENT each realize that time are of the essence in order to accomplish the objectives of this Agreement, including the Scope of Services. OUTSOURCER agrees to respond to requests for support from CLIENT in a timely and reasonable manner. CLIENT agrees to handle OUTSOURCER‘s requests for support, to the best of its ability, in a timely and reasonable manner. 3.7 Status Reporting:
OUTSOURCER management staff shall conduct regular meetings with the CLIENT Contract Administrator (as defined in Section 4.2.1 hereof) and such other persons as may be designated by the CLIENT to formally review OUTSOURCER performance under the terms of this Agreement. These meetings shall be conducted at a time and location mutually agreed upon. OUTSOURCER shall also prepare, on a monthly and quarterly basis, as applicable, a written status report which documents past activities and outlines planned activities for the forthcoming month or year. 3.8 Non-Solicitation: 3.8.1
Beginning on the Effective Date and continuing for a period of one year from the expiration or termination of this Agreement, the CLIENT shall not, without OUTSOURCER‘s prior written consent (which consent may be withheld at OUTSOURCER‘s sole discretion), enter into any contract (including, but not limited to, an employment contract, facilities management contract or consulting contract) with (i) any employee or former employee of OUTSOURCER who performed work under this Agreement within two years of such contract (an ―OUTSOURCER Page 416
Service Desk Workbook
Employee‖) or (ii) any person, firm, corporation or enterprise by which the OUTSOURCER Employee is employed or with which such OUTSOURCER Employee is affiliated (including, but not limited to, as a consultant, shareholder, partner, officer or director) (―OUTSOURCER Employee‘s New Firm‖), whereby the OUTSOURCER Employee or OUTSOURCER Employee‘s New Firm would provide to the CLIENT all or part of the services provided by OUTSOURCER to the CLIENT under this Agreement. 3.8.2
Beginning on the Effective Date and continuing for a period of one year from the expiration or termination of this Agreement, OUTSOURCER shall not, without CLIENT‘s prior written consent (which consent may be withheld at CLIENT‘s sole discretion), enter into any contract (including, but not limited to, an employment contract, facilities management contract, or consulting contract) with (i) CLIENT employee(s), or (ii) any person, firm, corporation or enterprise by which the CLIENT Employee is employed or with which such CLIENT Employee is affiliated (including, but not limited to, as a consultant, shareholder, partner, officer or director) (―CLIENT Employee‘s New Firm‖).
3.9 Confidentiality and Ownership of Material: 3.9.1
Subject to paragraph (c) below, ownership of all data, material and documentation originated and prepared for the CLIENT pursuant to this Agreement shall belong exclusively to the CLIENT. Upon termination of the Agreement, all such data, material and documentation shall be returned by OUTSOURCER to the CLIENT.
3.9.2
CLIENT and OUTSOURCER shall treat the other‘s ―Confidential Information‖ (as defined below) as proprietary. Each of CLIENT an OUTSOURCER shall (i) exercise due care to keep in confidence and not disclose Confidential Information to any individual other than its own employees who have a ―need to know‖ in order to perform the obligations of CLIENT or OUTSOURCER, as applicable, under this Agreement; (ii) not duplicate or publish any Confidential Information; and (iii) use Confidential Information only for the purposes authorized
Page 417
Service Desk Workbook
herein. The foregoing obligations shall not apply to Confidential Information if, and only to the extent that, it: (a)
is or becomes public knowledge through no fault of either of the parties hereto
(b)
was previously known by the recipient;
(c)
is lawfully provided to the recipient without restriction by an independent third party; or
(d)
must be disclosed pursuant to applicable law or regulation; provided, however, that with respect to exception (a), the disclosing party (i.e., the party who is disclosing to a third party information which is confidential to the other party to this Agreement) shall first establish that the full particulars of the Confidential Information are, in the combination disclosed to the disclosing party, well known or generally used within the industry, not merely that the individual features are in the public domain or available in isolated segments in two or more readilyavailable public sources; and provided, further that the burden shall be on the disclosing party to prove the applicability of any of exceptions (a), (b), and (c).
3.9.3
For purposes hereof, ―Confidential Information‖ shall mean manufacturing, engineering, software, business, customer, marketing, financial and other non-public information, reports or trade secrets relating to the business of OUTSOURCER or the CLIENT, as applicable, and created or learned by the CLIENT or OUTSOURCER, as applicable, in connection with the performance of this Agreement. 3.9.4.1
All worldwide right, title and interest in Intellectual Property Rights (as defined below) relating to in severable improvements in software and documentation not owned by or licensed to OUTSOURCER, which improvements are made, conceived or developed by OUTSOURCER in the performance of its duties under this Agreement shall vest Page 418
Service Desk Workbook
exclusively in CLIENT. In severable improvements shall mean those improvements that are not applicable to other software. 3.9.4.2
All worldwide right, title and interest in Intellectual Property Rights in, to, or relating to new software, including without limitation, modules, subroutines and stand-alone programs, and related documentation made, conceived or developed by OUTSOURCER in the performance of its duties under this Agreement shall vest exclusively with CLIENT.
3.9.4.3
All worldwide right, title and interest in Intellectual Property Rights in, to, or relating to severable improvements and modifications made, created, conceived or developed by OUTSOURCER in the performance of its duties under this Agreement, to software and related documentation not owned by or licensed to OUTSOURCER, shall vest exclusively in CLIENT. Severable improvements shall mean those improvements having application in and to other software.
3.9.5
―Intellectual Property Rights‖ shall mean all patents, trade secrets, and copyrights in, covering, and relating to software and documentation made, created, conceived, developed, improved or modified by OUTSOURCER in the performance of its duties under this Agreement.
3.9.6
Notwithstanding the foregoing to the contrary, Software developed under grants where OUTSOURCER is responsible for all aspects of development shall be done under a specific change of scope, and the ownership of the software so developed shall be governed by the grant provisions, and if there are no ownership requirements under the grant provisions, then the provisions of subparagraph (d) shall apply.
3.9.7
Notwithstanding the foregoing to the contrary, Software developed under grants where OUTSOURCER provides management and coordination services only shall not require a specific change of scope, and the ownership of the software so developed shall be governed by the grant provisions, and if there are no ownership requirements under Page 419
Service Desk Workbook
the grant provisions, then the provisions of subparagraph 3.9.4 shall apply. 3.10 Liability and Warranties: 3.10.1
Subject to its record retention policies, the CLIENT shall maintain Adequate Supporting Material to enable OUTSOURCER to update or regenerate, as necessary, data files, printer outputs and other data. In the event of loss, damage, destruction of any data, service, system or program due to the negligence of OUTSOURCER, OUTSOURCER‘s liability therefore shall be limited to either the replacement, repair, reconstruction, redevelopment or regeneration, at OUTSOURCER‘s option, of the lost, damaged, destroyed or inoperable data, service, system or program from the CLIENT‘s supporting material or otherwise as appropriate in the method deemed, most suitable, by OUTSOURCER for such action. In the event the CLIENT has failed to maintain Adequate Supporting Material, Outsourcer‘s liability shall be strictly limited to the same costs of replacement, repair, reconstruction, redevelopment or regeneration as if the CLIENT had so maintained adequate supporting material. Adequate Supporting Material is defined for the purposes of this Section as the original source material or data input documents initially provided to OUTSOURCER or replacement source material or data input documents provided to OUTSOURCER from time to time from which OUTSOURCER has obtained and input data in performance of its services hereunder. OUTSOURCER shall not be liable for any damages resulting or arising from CLIENT‘s failure to perform its obligations hereunder, provided that OUTSOURCER is not responsible for such failure to perform.
3.10.2
To the extent permitted Law, OUTSOURCER shall not be liable, whether contractually or in tort, for any consequential, special or indirect damages arising out of or in connection with this Agreement. To the extent they are beyond the reasonable control of OUTSOURCER, OUTSOURCER shall not be responsible for schedule delays, inaccuracies or other consequences resulting from incorrect CLIENT data, lateness in delivery of CLIENT‘s data or the failure of CLIENT‘s equipment or personnel. Page 420
Service Desk Workbook
3.10.3
OUTSOURCER agrees to be liable for, defend and indemnify CLIENT against all claims, suits, judgments or damages, including the cost of administrative hearings, court costs and attorneys fees, arising out of the negligent or intentional acts or omissions, or violations of laws or regulations, of or on the part of OUTSOURCER or its agents, officers, subcontractors or employees, in the course of the operation of this Agreement.
3.10.4
Warranties: OUTSOURCER SHALL PERFORM THE SERVICES UNDER THIS AGREEMENT IN ACCORDANCE WITH STANDARDS OF CARE, SKILL AND DILIGENCE CONSISTENT WITH RECOGNIZED AND PRUDENT INFORMATION TECHNOLOGY PRACTICES, ALL APPLICABLE LAWS AND REGULATIONS, THE SCOPE OF SERVICES, EXHIBITS, DOCUMENTS AND PROCEDURES APPLICABLE TO THE SERVICES, AND THE DEGREE OF KNOWLEDGE, SKILL AND JUDGEMENT NORMALLY EXERCISED BY PROFESSIONALS WITH RESPECT TO SERVICES OF THE SAME OR SIMILAR NATURE. THIS IS THE ONLY WARRANTY MADE BY OUTSOURCER WITH RESPECT TO ITS SERVICES UNDER THIS AGREEMENT AND TO THE EXTENT PERMITTED BY LAWS IS IN LIEU OF ALL OTHER UNDERSTANDINGS AND ALL WARRANTIES, EXPRESSED, IMPLIED OR STATUTORY, AS TO THE SERVICES TO BE PROVIDED BY OUTSOURCER, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR USE FOR A PARTICULAR PURPOSE.
3.11 Taxes:
This Agreement does not include charges for any taxes, which now or in the future may be deemed by a taxing authority to be applicable to the services to be provided by OUTSOURCER. In the event a taxing authority determines now or in the future that such services are subject to tax, OUTSOURCER shall invoice such taxes to the CLIENT and the CLIENT shall pay same simultaneously with the payment to which taxes relate. Page 421
Service Desk Workbook
CLIENT hereby represents that it is not currently subject to any such taxes and will notify OUTSOURCER in a timely manner if CLIENT becomes subject to any such tax. At the time of execution of this Agreement taxes on services provided by OUTSOURCER to CLIENT hereunder are not required to be paid, but if in the future are required, then CLIENT shall pay such taxes. 3.12 Force Majeure:
If either OUTSOURCER or the CLIENT is prevented from performing any task hereunder, in whole or in part, as a result of a cause beyond its reasonable control, which may include an Act of God, war, civil disturbance or organized labor dispute, such failure to perform shall not be grounds for termination of this Agreement. 3.13 Termination:
3.13.1
This Agreement may be terminated by a party (the ―Terminating Party‖) prior to the expiration of its stated term upon the occurrence of an ―Event of Default‖ affecting the other party (the ―Terminated Party‖)
3.13.2
An ―Event of Default‖ shall mean: (a)
failure by a party to timely perform any obligation under this Agreement, including without limitation CLIENT‘s failure to pay or cause to be paid any sums due in the manner provided in this Agreement within fifteen (15) business days of the date such payments were due; or OUTSOURCER not performing any of its obligations in accordance with this Agreement and all Exhibits thereto; or
(b)
any representation or warranty made by either party herein or in any document executed simultaneously and in connection herewith, or in any document or certificate furnished in connection herewith or therewith or pursuant hereto or thereto shall have been incorrect in any material respect at the time made; or
(c)
Upon the occurrence of an Event of Default the Terminating Party may give notice of termination to the Terminated Party, Page 422
Service Desk Workbook
identifying in reasonable detail the nature of the Event of Default. Thereupon, the Terminated party shall have 30 days to correct in all material respects the Event of Default (15 business days if the Event of Default consists of CLIENT‘s failure to pay outstanding sums within 15 business days of the date the payment was due). If the Terminated party so cures the Event of Default, then the notice of termination shall be ineffective. If the Terminated party does not so cure the Event of Default within the aforementioned period, then this Agreement shall be terminated upon the expiration of such period (the ―Termination Date‖). 3.13.3
CLIENT shall pay OUTSOURCER in full, within 15 business days of receipt of a final invoice from OUTSOURCER, for all services rendered up to and including the Termination Date.
3.14 Phase Over: 3.14.1
Prior to the expiration pursuant to its term of this Agreement, OUTSOURCER shall develop a plan for the orderly transition of all services provided by OUTSOURCER under this Agreement (the ―Transition Plan‖). Such Transition Plan shall be developed by OUTSOURCER in conjunction with OUTSOURCER‘s employees on site, the CLIENT‘s executives and administrators and such other persons as shall be designated by the CLIENT. The CLIENT shall fully cooperate with OUTSOURCER in order to develop the Transition Plan. The Transition Plan shall be completed no later than 90 days prior to expiration of this Agreement. It shall cover, inter alia, the training of CLIENT‘s personnel in the operation and maintenance of the systems used and operated by OUTSOURCER during the term of the Agreement. CLIENT shall notify OUTSOURCER of its acceptance of the Transition Plan within 14 days of receipt from OUTSOURCER.
3.14.2
OUTSOURCER shall complete all transition activities associated with the orderly termination of this Agreement on or before the date the notice of termination becomes effective. OUTSOURCER shall effect the transition to the CLIENT. Page 423
Service Desk Workbook
3.14.3
If due to OUTSOURCER‘s actions or omissions (i) the Transition Plan is not completed within the aforementioned period and the notice of termination becomes effective, or (ii) if the Transition Plan is completed and the notice of termination becomes effective but an orderly transition is not effected prior to the Termination Date, then OUTSOURCER shall continue to perform such services as may be required by the CLIENT, at no additional cost to CLIENT, in order to operate the CLIENT‘s computing system until such time as an orderly transition may be effected, but no later than 90 days after the Termination Date.
3.14.4
In the event of termination of this Agreement following the occurrence of an Event of Default on the part of OUTSOURCER, OUTSOURCER shall immediately upon the issuance of the notice of termination develop a Transition plan in accordance with the procedures set forth in paragraph (a) except, however, that the Transition Plan shall be completed no later than 30 days after the date of the notice of termination. CLIENT shall notify OUTSOURCER of its acceptance of the Transition Plan within 14 days of receipt from OUTSOURCER. OUTSOURCER shall complete all Transition activities associated with the termination by reason of its default no later than 60 days following OUTSOURCER‘s receipt of CLIENT‘s acceptance of the Transition Plan.
3.14.5
In the event of termination of this Agreement following the occurrence of an Event of Default on the part of CLIENT, then OUTSOURCER may, at the sole option of CLIENT, continue to perform such services as may be required by the CLIENT, at its rates then in effect, in order to operate the CLIENT‘s computing system until such time as an orderly transition may be effected, but no later than 90 days after the Termination Date; provided, however, that if the Event of Default consists in CLIENT‘s failure to pay any sums due OUTSOURCER, then OUTSOURCER shall continue to perform such services as may be required by the CLIENT after the Termination Date, at OUTSOURCER‘s rates then in effect, only if the CLIENT pays for such services in advance.
3.15 Funding: Page 424
Service Desk Workbook
3.15.1
CLIENT hereby represents to OUTSOURCER that (i) the services to be performed by OUTSOURCER hereunder are necessary to CLIENT‘s efficient operation of its business and (ii) to the best of its knowledge, after investigation, it believes that sufficient funds may be obtained by it or appropriated for it in order to make all payments contemplated hereby.
3.15.2
CLIENT shall make its best efforts to obtain, or cause to be appropriated as part of CLIENT‘s annual budget, sufficient funds to pay the sums due from time to time hereunder.
3.16 Independent Contractor Status:
OUTSOURCER and CLIENT acknowledge and agree that OUTSOURCER is and shall be an independent contractor; that neither OUTSOURCER nor any of its employees, representatives or agents is, or shall be deemed to be, an employee, partner or joint venture of the CLIENT; and that neither OUTSOURCER nor any of its employees, representatives or agents shall be entitled to any employee benefits under any employee benefit plan, including medical, insurance and other similar plans, of the CLIENT. OUTSOURCER further acknowledges that the CLIENT will not withhold any amounts in respect to local taxes from amounts payable by the CLIENT hereunder and it shall be the exclusive responsibility of OUTSOURCER to pay all amounts due in respect of applicable federal, state and local taxes on such amounts. 3.17 Client Policy and Procedures:
OUTSOURCER agrees to comply with all applicable CLIENT policies and procedures, including but not limited to those regarding conditions of work, access to and use of CLIENT‘s offices, facilities, work space, support services, supplies, Data Processing Equipment and software and access. 4. MISCELLANEOUS PROVISIONS 4.1 Severability: Page 425
Service Desk Workbook
Each provision of this Agreement shall be a separate and distinct covenant and, if declared illegal, unenforceable or in conflict with any governing law, shall not affect the validity of the remaining portion of this Agreement. 4.2.1 Client’s Contract Administrator: The CLIENT shall appoint as Contract Administrator _________________, who will be delegated the duty and responsibility of maintaining liaison with OUTSOURCER and to oversee performance of this Agreement. 4.2.2 OUTSOURCER’s Contract Administrator: The Outsourcer shall appoint as Contract Administrator __________________, who will be delegated the duty and responsibility of maintaining liaison with CLIENT and to oversee performance of this Agreement. 4.3 Successors:
This Agreement and all future amendments shall be binding on parties and their heirs, successors and assigns. The CLIENT agrees that OUTSOURCER may pledge or assign the net sums of money due and to become due to it hereunder to any bank, lending agency or institution as collateral security. 4.4 Renewal/Extension:
Upon written agreement of both parties entered into at least ninety (90) days prior to the expiration date, this Agreement may be extended for successive one year periods on the terms and conditions then in effect subject however, to such modifications as may be set forth in the extension agreement. 4.5 Entire Agreement-Amendments: (a)
This Agreement, together with the Exhibits hereto, embodies the entire agreement and understanding between the parties Page 426
Service Desk Workbook
hereto and supersedes all prior understandings and agreements, whether written or oral, between the parties hereto relating to the matter hereof. (b)
This Agreement (including the Exhibits hereto) may not be amended or modified except in writing signed by the parties hereto.
4.6 Assignment
This Agreement may not be assigned by either party without the prior written consent of the other party. For the avoidance of doubt, a change of control of OUTSOURCER shall not constitute an assignment for purposes hereof. 4.7 Attorneys Fees
In the event that suit is brought to enforce the provisions of this Agreement, the prevailing party, as determined by the judge, or arbitrator in the event of arbitration, shall be entitled to an award of reasonable attorneys‘ fees, paralegals' fees and court costs, whether incurred before trial, at trial, during appeals, or in any mediation or arbitration required by a court.
Service Desk Metrics Metrics should be established so that performance of the Service Desk can be evaluated at regular intervals. This is important to assess the health, maturity, efficiency, effectiveness and any opportunities to improve Service Desk operations. Metrics for Service Desk performance must be realistic and carefully chosen. It is common to select those metrics that are easily available and that may seem to be a possible indication of performance; however, this can be misleading. For example, the total number of calls received by the Service Desk is not in itself an indication of either good or bad performance and may in fact by caused by events completely outside the control of the Service Desk – for example a particularly busy period for the organization, or the release of a new version of a major corporate system. An increase in the number of calls to the Service Desk can indicate less reliable services over that period of time – but may also indicate increased user confidence in Page 427
Service Desk Workbook
a Service Desk that is maturing, resulting in a higher likelihood that users will seek assistance rather than try to cope alone. For this type of metric to be reliable for reaching either conclusion, further comparison of previous periods for any Service Desk improvements implemented since the last measurement baseline, or service reliability changes, problems, etc. to isolate the true cause for the increase is needed. Further analysis and more detailed metrics are therefore needed and must be examined over a period of time. These will include the call-handling statistics, and additionally:
The first-line resolution rate: the percentage of calls resolved at first line, without the need for escalation to support other groups. This is the figure often quoted by organizations as the primary measure of the Service Desks performance – and used for comparison purposes with the performance of other desks – but care is needed when making any
comparisons. For greater accuracy and more valid comparisons this can be broken down further as follows:
The percentage of calls resolved during the first contact with the Service Desk, i.e. while the user is still on the telephone to report the call
The percentage of calls resolved by the Service Desk staff themselves without having to seek deeper support from other groups. Note: some desks will choose to co-locate or embed more technically skilled second-line staff with the Service Desk. In such cases it is important when making comparisons to also separate out (i) the percentage resolved by the Service Desk staff alone; and (ii) the percentage resolved by the first-line Service Desk staff and second-line support staff combined.
Average time to resolve an incident (when resolved at first line)
Average time to escalate an incident (where first-line resolution is not possible)
Page 428
Service Desk Workbook
Average Service Desk cost of handling an incident. Two metrics should be considered here:
Total cost of the Service Desk divided by the number of calls. This will provide an average figure which is useful as an index and for planning purposes but does not accurately represent the relative costs of different types of calls
By calculating the percentage of call duration time on the desk overall and working out a cost per minute (total costs for the period divided by total call duration minutes) this can be used to calculate the cost for individual calls and give a more accurate figure.
By evaluating the types of incidents with call duration, a more refined picture of cost per call by types arises and gives an indication of which incident types tend to cost more to resolve and possible targets for improvements.
Percentage of customer or user updates conducted within target times, as defined in SLA targets
Average time to review and close a resolved call
The number of calls broken down by time of day and day or week, combined with the average call-time metric, is critical in determining the number of staff required.
Communication Plan
IT Services Communication Plan Function: Service Desk
Page 429
Service Desk Workbook
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Communication Plan for the Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Service Desk function. This document provides a basis for completion within your own organization. This document contains suggestions regarding information to share with others. The document is deliberately concise and broken into communication modules. This will allow the reader to pick and choose information for e-mails, flyers, etc. from one or more modules if and when appropriate.
Initial Communication
Page 430
Service Desk Workbook
Sell the Benefits. First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system, a new way of working. WHY?
It is here that we need to promote and sell the benefits. However, be cautious of using generic words. Cite specific examples from your own organization that the reader will be able to relate to (to help develop specific examples contact [email protected] for competitive quotation).
Generic Benefit statements
Specific Organizational example
Service Desk provides a single point of contact for our customers and endusers
This is important because…
Allows us to manage all incidents and the registration of RFC‘s and Service requests.
Our last Customer Satisfaction Survey shows that our customers are not satisfied with the way we handle their calls for help…
Helps us to more effectively manage our communications to the business.
Apart from the obvious benefits of communication, the specific reason why we bring this up is…
The above Communication module (or elements of) was/were distributed; The Service Desk will assist the other IT staff are more and more buried processDesk areasGoal with some operational under administration type activities and Service To: activities…. this is effecting the quality of their work. Wouldn‘t it be wonderful if…. On: <> By: On:
<>
Page 431
Service Desk Workbook
The Goal of the Service Desk. The Goal of the Service Desk can be promoted in the following manner.
Official Goal Statement: To support the agreed IT service provision by ensuring the accessibility and availability of the IT-organization and by performing various supporting activities.
High visibility and wide channels of communication are essential in this function. Gather specific Service Desk Requirements from nominated personnel
(Special Tip: Beware of using only Managers to gain information from, as the resistance factor will be high)
Oversee the registration and resolution of incidents to ensure that the business needs of IT are not impacted more than necessary.
Provide relevant reports to nominated personnel.
(Special Tip: Beware of reporting only to Managers. If you speak to a lot of people regarding Service Delivery then you need to establish ways to report to these people the outcomes and progress of the discussions).
The above Service Desk Goals module was distributed; Always bear in mind the ―so what‖ factor when discussing areas like goals and objectives. If you cannot honestly and sensibly answer the question ―so what‖ – then To: you are not selling the message in a way that is personal to the listener and gets their On: <> ―buy-in‖. By: On:
<>
Page 432
Service Desk Workbook
Service Desk Activities
The list of actions in this module may have a direct impact on end users. They will be curious as to why all of a sudden they have to call the Service Desk, rather than Joe Blogs in IT, like they used to do. There could be an element of suspicion, so consider different strategies to overcome this initial skepticism.
Call logging (activity for Incident Mgt.) Set out clear procedures to submit incidents and requests. Set out clear procedures when incidents are escalated to other areas Verify CMDB (activity for Conf. Mgt)
As part of the registration, classification and categorization of the incident Service Desk staff will ask specific questions to verify CMDB information. Monitor progress
All incidents that come in to the Service Desk are monitored when they go through the various processes (incident Management, Problem Management, Change Management). The monitoring is important as the Service Desk is also the first point of contact for progress updates to customers and end-users. End-user training
In some organizations it is the Service Desk who organizes and performs induction training, desktop training and other forms of end-user training. Pro-Active activities
As the Service Desk staff talk to the customers and end-users every day of the week, they should be able to point out to the other process owners where the areas for improvement are.
Customer Satisfaction Surveys
One of the communications to the customers is the regular customer satisfaction survey. The Service Desk staff develop the survey, send them out to the customers (or ask the questions on the phone), process the responses and publish the results.
Communication to customers
Service Desk staff send out reports, notifications and memos to customers and end-users to: Notify them of the performance of the IT department Notify them of service (un)availability and release dates Update on incident/problem/change progress
Page 433
Service Desk Workbook
Intrusive & Hidden Activities
Service Desk Planning Costs
Information relating to costs may be a topic that would be held back from general communication. Failure to convince people of the benefits will mean total rejection of associate costs. If required, costs fall under several categories:
Personnel – Service Desk staff
Accommodation – Physical location (Set-up and ongoing)
Software – Tools (Set-up and ongoing)
Hardware – Infrastructure (Set-up)
Education – Training (Set-up and ongoing)
Procedures – external consultants etc (Set-up)
The costs of implementing a Service Desk will be outweighed by the benefits. For example, many organizations have a negative perception of their IT department because of inaccessibility of the key people.
A well run Service Desk will make major inroads into altering that perception.
Details regarding the cost of Service Desk were distributed; To: On:
<>
Business Flyers
By:
On:
<>
Page 434
Service Desk Workbook
Page 435
Service Desk Workbook
SERVICE DESK OBJECTIVES AND GOALS
IT Services Detailed Objectives/Goals Function: Service Desk Status:
Version:
In draft Under Review Sent for Approval Approved Rejected <>
Release Date: Detailed Objectives/Goals for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. The detailed objectives for Service Desk should include the following salient points: Objective
Notes Met/Exceeded/Shortfall
Improve Customer Satisfaction
Page 436
Service Desk Workbook
By providing a single point of contact for the customers and end-users you will make the accessibility of the IT department higher. This will improve customer satisfaction as they now know where to go to when they have a question or IT issue.
Dates/names/role titles
Don‘t forget to include the IT staff as end-users in the survey. One of the main improvements should be that the Service Desk takes a lot of workload off the IT specialists.
Responsiveness When a customer / end-user contacts the Service Desk they should be looked after swiftly. By monitoring the responsiveness of the SD staff you can improve the perception that the customer / end-user has of the IT department. Accessibility of the IT department is one of the main objectives of a Service Desk. It shouldn‘t be difficult to get in touch with the Service Desk. (You probably don‘t speak highly of a Service Desk where you have to wait 2 minutes on the phone before somebody picks up) Establish efficient reporting lines Service Desk staff also play a major part in the communication from the IT department back to the customers / end-users. IT should be clear who reports on what and why. SD staff very often send out the monthly performance reports to the customers on behalf of the SLM process.
Page 437
Service Desk Workbook
Professional image of the IT department With a well established Service Desk and experienced, pro-active, friendly staff the image of the IT department will be more positive. The Service Desk should focus on a professional work ethic and approach.
To establish ground rules that distinguish a genuine request for Incident as opposed to a Service Request. Request for information or status of a service (not related to loss of service) Includes Standard Changes. Eg. Contact details, Service availability, request for common software. . There will however, be a detailed procedure about when and how passwords are to be reset and who is to be advised, etc. – but approval from the Incident Manager is not required. Develop working relationships with all other process areas. The Service Desk is a pivotal one with regard to requiring input from other process areas. Obvious links include Incident Management (SD staff are first point of call for incidents and record all incidents that come in), Configuration Management (to verify configuration information) and Release Management (sending out release notices). Less obvious links include Financial Management for IT Services (to establish Return on Investment (ROI) on incidents and the cost per call) and IT Service Continuity Management (to the level of Service Desk Page 438
Service Desk Workbook
support during a contingency situation).
Develop a SD that suits the organization and look for continuous improvement. A Service Desk can be designed in various ways: you can have a local service Desk, or a distributed Service Desk. Some organizations even opt for a virtual Service Desk to make it easier to support the ‗follow the sun‘ concept. What type of Service Desk suits your organization? How does this SD design support the overall Service Desk goals and business goals?
Use these objectives to generate discussion about others that may be more appropriate to list than those provided. Refer also to the Communication Plan document (available within this workbook) for ideas on how to communicate the benefits of Incident Management.
Page 439
Service Desk Workbook
POLICIES OBJECTIVES AND SCOPE
IT Services Policies, Objectives and Scope Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Refer to the Implementation Plan & Project Plan document for planning and implementation guidelines. Policies, Objectives and Scope for Service Desk This document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. Policy Statement
Page 440
Service Desk Workbook
A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous
Use this text box to answer the ―SENSE OF URGENCY‖ question regarding this function.
Why is effort being put into this function? Not simply because someone thinks it‘s a good idea. That won‘t do. The reason has to be based in business benefits.
You must be able to concisely document the reason behind starting or improving this function.
Is it because of legal requirements or competitive advantage? Perhaps the business has suffered major problems or user satisfaction ratings are at the point where outsourcing is being considered.
A policy statement any bigger than this text box, may be too lengthy to read, lose the The above Policy Statement intended audience with detail,was; not be clearly focused on answering the WHY question for this process. Prepared by: Objectives Statement On:
<>
And accepted by: On:
<>
Page 441
Service Desk Workbook
Something worked toward or aimed for; a goal.
Use this text box to answer the ―WHERE ARE WE GOING‖ question regarding this function. The above Objective Statement was; Prepared by: Generic sample Mission statement for Service Desk is: On: <>
Service Desk Mission Statement: The Service Desk aims to support the agreed IT And accepted by:
service provision by ensuring the accessibility and availability of the IT-organization and On:
<>
by performing various supporting activities.
To provide a helpful and friendly first point of contact for the IT Department. To provide basic support for computing and audio/visual services. To provide the necessary online forms to request equipment, repairs, and network account changes. To provide online FAQ's, manuals, and tutorials to empower users to self-troubleshoot. To provide equipment delivery and repair services.
What will be the end result of this function and how will we know when we have reached the end result? Will we know because we will establish a few key metrics or measurements or will it be a more subjective decision, based on instinct?
A generic sample statement on the “objective” for Service Desk is:
The Service Desk function provides a single point of contact for the customers of the IT department, not only for incidents and questions but also for other activities such as Change requests and SLM reports. In many cases the service desk represents the IT department to the customer and to the end-user and as such is key in the customer satisfaction and perception of the IT department.
Note the keywords in the statement. For the statement on Service Desk they are “representative, customer satisfaction, perception” and “single point of contact”. These are definite areas that we can set metrics for and therefore measure progress.
An objective statement any bigger than this text box, may be too lengthy to read, lose the
Refer to the Service document (available within intended audience withDesk detail,Metrics not be clearly focused on answering the this WHERE question for this document) process. Page 442
Service Desk Workbook
Refer to the Service Desk - Objectives and Goals document (available within this document). Scope Statement The area covered by a given activity or subject Use this text box to answer the ―WHAT‖ question regarding this function.
What are the boundaries for this function? What does the information flow look like into this function and from this function to other processes?
A generic sample statement on the “scope” for Service Desk is:
The Service Desk function will be responsible for managing first line support and general customer contact involving all aspects of the IT Service Operation. The Service Desk will be responsible for the daily verification of the CMDB.
Service Desk will not be responsible for problem analysis and management of changes.
A scope statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focused on answering the WHAT question for this process.
Be aware that the scope of the Service Desk depends on the way the IT department is organized. It can be as broad or narrow as needed. You might wish to use Service Desk staff to perform simple activities for the other processes, i.e. performing routine changes, updating databases, sending out reports.
Page 443
Service Desk Workbook
IMPLEMENTATION PLAN AND PROJECT PLAN
IT Services Implementation Plan/Project Plan Skeleton Outline Process: Knowledge Management Status: Version:
0.1
Release Date:
Planning and Implementation for Knowledge Management This document as described provides guidance for the planning and implementation of the Knowledge Management ITIL process. The document is not to be considered an extensive plan as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered for planning and implementation of this process. Initial planning When beginning the process planning the following items must be completed: CHECK
DESCRIPTION
or or date Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (e.g. Internal, outsourced, Page 444
Service Desk Workbook
hybrid) for the process. Assign a person to the key role of process manager/owner. This person is responsible for the process and all associated systems.
Conduct a review of activities that would currently be considered as an activity associated with this process. Make notes and discuss the ―re-usability‖ of that activity. Three key activities of Knowledge Management are:
Gathering, analyzing, storing and sharing knowledge and information within the organization.
Improve efficiency by reducing the need to rediscover knowledge.
Create and gain agreement on a high-level process plan and a design for any associated process systems. NOTE: the plan need not be detailed. Too many initiatives get caught up in too much detail in the planning phase. KEEPS THE MOMENTUM GOING. Review the finances required for the process as a whole and any associated systems (expenditure including people, software, hardware, accommodation). Don‘t forget that the initial expenditure may be higher than the ongoing costs. Don‘t forget annual allowances for systems maintenance or customizations to systems by development staff. Agree the policy regarding this process
Create Strategic statements
Policy Statement
The policy establishes the ―SENSE OF URGENCY‖ for the process. It helps us to think clearly about and agree on the reasons WHY effort is put into this process.
Page 445
Service Desk Workbook
An inability to answer this seemingly simple, but actually complex question is a major stepping stone towards successful implementation The most common mistake made is that reasons regarding IT are given as the WHY we should do this. Reasons like to make our IT department more efficient are far too generic and don‘t focus on the real issue behind why this process is needed. The statement must leave the reader in no doubt that the benefits of this process will be far reaching and contribute to the business in a clearly recognizable way.
Objective Statement
When you are describing the end or ultimate goal for a unit of activity that is about to be undertaken you are outlining the OBJECTIVE for that unit of activity. Of course the activity may be some actions for just yourself or a team of people. In either case, writing down the answer to WHERE will this activity to me/us/the organization is a powerful exercise. There are many studies that indicate the simple act of putting a statement about the end result expected onto a piece of paper, then continually referring to it, makes achieving that end result realistic. As a tip regarding the development of an objective statement; don‘t get caught up in spending hours on this. Do it quickly and go with your instincts or first thoughts – BUT THEN, wait a few days and review what you did for another short period of time and THEN commit to the outcome of the second review as your statement.
Scope Statement
In defining the scope of this process we are answering what activities and what ―information interfaces‖ does this process have. Don‘t get caught up in trying to be too detailed about the information flow into and out of this process. What is important is that others realize that information does in fact flow. Page 446
Service Desk Workbook
For example, with regard to the KNOWLEDGE MANAGEMENT process we can create a simple table such as: Knowledge Management Information flows
Process
Process
Information
Knowledge Management
to
Problem Management
Error database, skills database of staff, supplier requirements and abilities
Problem Management
to
Knowledge Management
Report of knowledge related problems and known errors
Knowledge Management
to
Change Management
RFC records and histories, Known Error information
Change Management
to
Knowledge Management
Info on changes as some RFC‘s to update knowledge database
Knowledge Management
to
Service Level Management
Knowledge reporting to planned vs. actual comparison
Service Level Management
to
Knowledge Management
Service Level Requirements, SLA‘s, OLA‘s, UC‘s
Page 447
Service Level Management Workbook
Steps for Implementation There can be a variety of ways to implement this process. For a lot of organizations a staged implementation may be suited. For others a ―big bang‖ implementation – due to absolute equality may be appropriate. In reality however, we usually look at implementation according to pre-defined priorities. Consider the following options and then apply a suitable model to your own organization or case study.
STEPS
NOTES/ /RELEVANCE/DATES/ WHO
Define the Objective and Scope for Knowledge Management
Establish and agree on a clear definition for the words:
Data
Information
Knowledge
Wisdom
This is one of the most interesting aspects. It can be very difficult to get everyone to agree to a definition, and it can be very difficult to establish the correct understanding of the definition. However, get this right, and the rest of the process is made easier.
Seek initial approval
Establish and Define Roles and Responsibilities for the process. Appoint a Knowledge Manager.
Page 448
Service Level Management Workbook
Establish and Define the Scope for Knowledge Management and the relationships with IT Services
Establish Knowledge Management Process
Establish and Define Relationship with all other processes. This is another key aspect of the Knowledge Management process. Knowledge Management is where we are helping set the expectations of service and influence their perceptions. Knowledge Management works closely with Service Level Management and Release and Deployment Management to achieve this.
Establish monitoring levels. Knowledge from as seen by the business is related to the service and not the components that make up the service.
Define reporting standards
Publicize and market
The priority selection has to be made with other factors in mind, such as competitive analysis, any legal requirements, and desires of ―politically powerful influencers‖.
Costs The cost of process implementation is something that must be considered before, during and after the implementation initiative. The following points and table helps to frame these considerations: (A variety of symbols have been provided to help you indicate required expenditure, rising or falling expenditure, level of satisfaction regarding costs in a particular area, etc. Page 449
Service Level Management Workbook Initial Personnel Costs of people for initial design of process, implementation and ongoing support Accommodation Costs of housing new staff and any associated new equipment and space for documents or process related concepts.
During
Ongoing
Software New tools required to support the process and/or the costs of migration from an existing tool or system to the new one. Maintenance costs Hardware New hardware required to support the process activities. IT hardware and even new desks for staff. Education Re-education of existing staff to learn new techniques and/or learn to operate new systems. Procedures Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel. In most cases, costs for Process implementation have to be budgeted for (or allocated) well in advance of expenditure. Part of this step involves deciding on a charging mechanism (if any) for the new services to be offered.
Build the team Each process requires a process owner and in most situations a team of people to assist. The Knowledge Management process is one of the processes in the Service Transition phase that shows very visible benefits from the outset and is very
Page 450
Service Level Management Workbook
influential in setting the perception of IT Services to its customers and end users. Of course a lot will be dependant on the timing of the implementation and whether it is to be staged or implemented as one exercise.
Analyze current situation and FLAG Naturally there are many organizations that have many existing procedures/processes and people in place that feel that the activities of Knowledge Management is already being done. It is critical to identify these systems and consider their future role as part of the new process definition. Examples of areas to review are: Area
Notes
Power teams Current formal procedures Current informal procedures Current role descriptions Existing organizational structure Spreadsheets, databases and other repositories Other…
Implementation Planning After base decisions regarding the scope of the process and the overall planning activities are complete we need to address the actual implementation of the process. It is unlikely that there will not be some current activity or work being performed that would fit under the banner of this process. However, we can provide a comprehensive checklist of points that must be reviewed and done. Implementation activities for Knowledge Management Page 451
Service Level Management Workbook Activity
Notes/Comme nts/Time Frame/Who
Review current and existing Knowledge Management practices in greater detail. Make sure you also review current process connections from these practices to other areas of IT Service Transition.
Review the ability of existing functions and staff. Can we ―reuse‖ some of the skills to minimize training, education and time required for implementation?
Establish the accuracy and relevance of current processes, procedures and meetings. As part of this step if any information is credible document the transition from the current format to any new format that is selected.
Decide how best to select any vendor that will provide assistance in this process area (including tools, external consultancy or assistance to help with initial high workload during process implementation).
Establish a selection guideline for the evaluation and selection of tools required to support this process area (i.e. Knowledge Management tools).
Purchase and install tools required to support this process (i.e. Knowledge Management tool). Ensure adequate skills transfer and on-going support is catered for if external systems are selected.
Create any required business processes interfaces for this process that can be provided by the automated tools (e.g. reporting – frequency, content).
Document and get agreement on roles, responsibilities and training plans.
Page 452
Service Level Management Workbook
Communicate with and provide necessary education and training for staff that covers the actual importance of the process and the intricacies of being part of the process itself.
An important point to remember is that if this process is to be implemented at the same time as other processes that it is crucial that both implementation plans and importantly timing of work is complementary.
Cutover to new processes The question of when a new process actually starts is one that is not easy to answer. Most process activity evolves without rigid starting dates and this is what we mean when we answer a question with ―that‘s just the way it‘s done around here‖. Ultimately we do want the new process to become the way things are done around here, so it may even be best not to set specific launch dates, as this will set the expectation that from the given date all issues relating to the process will disappear (not a realistic expectation).
Page 453
Service Level Management Workbook
BUSINESS JUSTIFICATION DOCUMENT
IT Services Business Justification Function: Service Desk Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Business Justification Document for Service Desk The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a reference for HOW TO APPROACH THE TASK OF SEEKING FUNDS for the implementation of the Service Desk Function. This document provides a basis for completion within your own organization.
Service Desk Business Justification A strong enough business case will ensure progress and funds are made available for any IT initiative. This may sound like a bold statement but it is true. As IT professionals we have (for too long) assumed that we miss out on funds while other functional areas (eg. Human resources and other shared services) seem to get all that they want.
Page 454
Service Level Management Workbook However, the problem is not with them, it‘s with US. We are typically poor salespeople when it comes to putting our case forward. We try to impress with technical descriptions, rather than talking in a language that a business person understands. For example: We say
We should say
We have to increase IT security controls, with the implementation of a new firewall.
Two weeks ago our biggest competitor lost information that is now rumored to be available on the internet.
The network bandwidth is our biggest bottleneck and we have to go to a switched local environment.
The e-mail you send to the other national managers will take 4 to 6 hours to be delivered. It used to be 2 to 3 minutes, but we are now using our computers for many more tasks.
Changes to the environment are scheduled We are making the changes on Sunday for a period of time when we expect there afternoon. There will be less people to be minimal business impact. working then.
Doesn‘t that sound familiar? To help reinforce this point even further, consider the situation of buying a new fridge. What if the technically savvy sales person wants to explain ―the intricacies of the tubing structure used to super cool the high pressure gases, which flow in an anti-clockwise direction in the Southern hemisphere‖. Wouldn‘t you say ―too much information, who cares – does it make things cold?‖ Well IT managers need to stop trying to tell business managers about the tubing structure and just tell them what they are interested in. So let‘s know look at some benefits of Service Desk. Remember that the comments here are generic, as they have to apply to any organization. If you need assistance in writing business benefits for your organization please e-mail [email protected] for a quotation. Benefits
Notes/Comments/Relevance
Introduces a structured support system, where each person has a common and concise view on the function of the Service Desk in the Page 455
Service Level Management Workbook organization. Reduces the reliance on key staff to perform multiple duties. Depending on the model of Service Desk support there can be a shift from subject matter experts spending a high degree of time working on administrative tasks, to actually helping people. The properly managed Service Desk will also have built in redundancy with respect to the people involved, so that there is always back-up and resources available should one person be absent.
With the co-introduction of a sound Incident Management and Problem Management processes the Service Desk will move away from a function that is continually in a ―firefighting‖ mode to one that delivers true valueadded support to the organization.
A professional Service Desk will quickly start to change any negative perception that customers or end-users will have. This change cannot be expected simply by launching the Service Desk. The communication plan that announces the new service must also be carefully planned and implemented.
The new Service Desk structure will bring to an end (or else significantly reduce) the number of unrecorded requests for assistance and unauthorized changes to the IT infrastructure. While people are involved with the function there will always be ―by-passing‖, however, the checks and reporting structures for this function will help to reduce this.
Page 456
Service Level Management Workbook A new Service Desk function is often accompanied with a new Service Desk tool. This combined with a standard education base for all staff helps the same problems being resolved repeatedly rather than eliminated Such steps lead to immediate results in not having to solve the same problem multiple times, as staff learn how to search for any occurrence of the problem as well as how to record incidents to allow for easier faster searching.
The reporting structure that will be designed with the new function allows more meaningful information to be delivered. Such reporting has more of a business focus, rather than a traditional focus on reporting the number of calls received or resolved at first point of contact. With this new business focus managers are much more empowered to justify the costs of running their areas of responsibility, as they can know demonstrate real business returns.
Page 457
Service Level Management Workbook
Service Level Management INTRODUCTION ROADMAP Many organizations are looking to implement a Service Level Management as a way to improve the structure and quality of the business. This document describes the contents of the Service Level Management Workbook. The information found within the Workbook is based on the ITIL Version 3 framework, specifically the Service Design and Continual Service Improvement phases which incorporate the updated ITIL version 3 Service Level Management process. The Workbook is designed to answer a lot of the questions that Service Level Management process raises and provides you with useful guides, templates and essential, but simple assessments. The supporting documents and assessments will help you identify the areas within your organization that require the most activity in terms of change and improvement. Presentations can be used to educate or be used as the basis for management presentations or when making business cases for Service Level Management implementation. The additional information and bonus resources will enable you to improve your organizations methodology knowledge base. The workbook serves to act as a starting point. It will give you a clear path to travel. It is designed to be a valuable source of information and activities. The Service Level Management Workbook:
Flows logically,
Is scalable,
Provides presentations, templates and documents,
Saves you time.
Step 1 Start by reviewing the PowerPoint presentations in the following order: Presentations 1 and 2 provide a detailed and comprehensive overview of Service Level Management in the specialist areas of ITIL Version3 1. ITIL V3 SLM Presentation - Service Design. 2. ITIL V3 SLM Presentation - CSI These presentations will give you a good knowledge and understanding of all the terms, activities and concepts required within the Service Level Management Page 458
Service Level Management Workbook
process. They can also be used as the basis for management presentations or when making a formal business case for Service Level Management implementation. Make sure you pay close attention to the notes pages, as well as the slides, as references to further documents and resources are highlighted here. Step 2 If you did not look at the supporting documents and resources when prompted during the PowerPoint presentations, do this now. Below is an itemized list of the supporting documents and resources for easy reference. You can use these documents and resources within your own organization or as a template to help you in prepare your own bespoke documentation. ITIL V3 SLM Presentation - Service Design 1. Objectives and Goals 2. Policies Objectives and Scope 3. SLM Scope 4. Business Justification document 5. Organizing for Service Design - Roles & Responsibilities 6. SLM Process Manager 7. Customer Based SLA 8. Service Based SLA 9. Multi level SLA's 10. Business and IT Service Mapping 11. Operational Level Agreement 12. Service Level Requirements 13. Service Options 14. Underpinning Contracts 15. Functional Specification 16. Technical Specification 17. Price List 18. Communication Plan 19. Business and IT Flyers 20. Reports KPI's other metrics 21. SLM Process Manager 22. Organizing for Service Design - Roles & Responsibilities ITIL V3 SLM Presentation - CSI Page 459
Service Level Management Workbook
Step 3 Alternatively, continue by working through the SLM Implementation & Project Plan with the focus on your organization. This will help you ascertain the Service Level Management maturity for your organization. You will able to identify gaps and areas of attention and/or improvement. The supporting documents and bonus resources found within the workbook will help you fill these gaps by giving you a focused, practical and user-friendly approach to Service Level Management.
SERVICE DESIGN
Service Level Management (SLM) is a process that is found within two Service Lifecycle phases. Page 460
Service Level Management Workbook
Within Service Design, Service Level Management is concerned with:
Design and plan process
Determining Service Level Requirements (SLRs)
Negotiating and Agreeing upon SLAs, OLAs and UCs.
Within Continual Service Improvement, Service Level Management is concerned with improving services and processes through constant:
Monitoring (executed within Service Operation)
Reporting
Evaluating
Improving
The major focus of Service Level Management within Continual Service Improvement is identifying potential service improvements.
SLM is a vital process for every IT service provider organisation as it is responsible for agreeing and documenting service level targets and responsibilities within SLAs and SLRs for every activity within IT. If targets are appropriate and accurately reflect the requirements of the business, the service delivered will align with business requirements and meet the expectations of the customers and users in terms of service quality. When targets are not aligned with business needs, the service provider activities and service levels will not be aligned with business expectations and therefore problems will develop. Page 461
Service Level Management Workbook
The SLA is effectively a level of assurance or warranty with regard to the level of service quality delivered by the service provider for each of the services delivered to the business. The quality of the Service Portfolio and the Service Catalogue is pivotal to the success of the SLM.
Service Level Management (SLM) negotiates, agrees and documents appropriate IT service targets with representatives of the business, and then monitors and produces reports on the service provider;s ability to deliver the agreed level of service.
Proactive measures are also taken to seek and implement improvements to the level of service delivered. Page 462
Service Level Management Workbook
SLM is the name given to the processes of planning, coordinating, drafting, agreeing, monitoring and reporting of SLA‘s, and the ongoing review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved.
SLM must manage the expectation and perception of the business, customers and users in order to ensure that the quality of service delivered by the service provider is matched to those expectations and needs. In order to do this effectively, SLA should establish and maintain SLAs for all current live services and manage the level of service provided to meet the targets and quality measurements contained within the
Page 463
Service Level Management Workbook
SLAs. SLM should also produce and agree SLRs for all planned new or changed services. This enables SLM to ensure that all services and components are designed and delivered to meet their targets in terms of business needs. The SLM processes should include the:
Development of relationships with the business
Negotiation and agreement of current requirements and targets, and the documentation and management of SLAs for all operational services
Negotiation and agreement of future requirements and targets, and the documentation and management of SLRs for all proposed new or changed services
Development and management of appropriate Operational Level Agreements (OLAs) to ensure that targets are aligned with SLA targets
Continued…
Review of all underpinning supplier contracts and agreements with Supplier Management to ensure that targets are aligned with SLA targets
Reporting and management of all services and review of all SLA breaches and weaknesses
Instigation and coordination of a Service Improvement Plan (SIP) for the management, planning and implementation of all service and process improvements
Page 464
Service Level Management Workbook
SLM is not only concerned with ensuring that current services and SLA‘s are managed, but is also involved in ensuring that new requirements are captured and that new or changed services and SLA‘s are developed to match the business needs and expectations. SLA‘s provide the basis for managing the relationship between the service provider and the customer, and SLM provides that central point of focus for a group of customers, business untis or lines of business.
Written agreement between a service provider and Customers), that documents agreed Service Levels for a Service: Service Level Agreements (SLAs)
Written statement of IT services, default levels and options: Service Catalogue Page 465
Service Level Management Workbook
Contract with an external supplier that supports the IT organization in their delivery of services: Underpinning Contract (UCs)
Internal agreement which supports the IT organization in their delivery of services: Operational Level Agreement (OLAs)
Detailed recording of the Customer‘s needs: Service Level Requirements
Service Based SLA The SLA covers one service, for all customers of that service. Difficulties may arise if the specific requirements of different customers vary for the same service, or if characteristics of the infrastructure mean that different service levels are inevitable. As such, separate targets may be needed within the one
Page 466
Service Level Management Workbook
agreement. However, where common levels of service are provided across all areas of the business, service-based SLAs may be the most efficient approach. Customer Based SLA The SLA is an agreement with an individual customer group, covering all the services they use. Customers often prefer such an agreement, as a single document will cover all their needs.
Multi – level SLA’s Some organizations have chosen to adopt a multi level SLA structure. E.g A 3 level structure such as; Corporate Level: covers all generic SLM issues to every customer throughout the organization. Customer Level: covers all SLM issues relevant to a particular customer group of business unit, regardless of the service being used Service Level: covers all SLM issues relevant to the specific service, in relation to a specific customer group
Page 467
Service Level Management Workbook
The activity of determining the initial targets for inclusion with an SLR or SLA can be very difficult. All other processes need to be consulted for their opinion on realistic targets, such as Incident Management on incident targets. Capacity and Availability Management processes will be of particular value in determining appropriate service availability and performance targets. While many organizations have to give initial priority to introducing SLAs for existing services, it is also important to establish procedures for agreeing SLRs for new services being developed or procured. If can be difficult to draw out specific requirements, as the business may need help in understanding and defining their needs, particularly in terms of capacity, security, availability and IT service continuity. Several iterations of negotiations may be required before an affordable balance is struck between what is sought and what is achievable and affordable.
Page 468
Service Level Management Workbook
The Service Desk, when linked to a comprehensive CMS, can be used to monitor the customer‘s perception of availability. It can also be used to monitor incident response times and resolution times. It is essential to ensure that any incident / problem handling targets included in SLAs are the same as those included in Service Desk tools and used for escalation and monitoring purposes. Some amendments may be needed to support tools, to include the necessary fields so that relevant data can be captured. Transaction response times can be a difficult area to monitor and can be dealt with in the following ways:
Include a statement in the SLA stating that any response time delays experienced for more than x minutes should be reported to the Service Desk
Agree and include in the SLA an acceptable target for the number of such incidents that can be tolerated in the reporting period
Create an incident category of ‗poor response‘ to ensure that such incidents are logged accurately
Produce regular reports of target time breaches and instigate investigations via Problem Management to find a solution
Page 469
Service Level Management Workbook
SLAs are just documents, and in themselves do not materially alter the quality of service being provided. However, it must be noted that SLAs do affect the behaviour and help engender an appropriate service culture, which can then have an immediate beneficial effect and make longer-term improvements possible. It is recommended that attempts be made to monitor customer perception on soft issues such as opinions or feelings toward the service. Methods of doing this include:
Periodic questionnaires and customer surveys
Customer feedback from service review meetings
Page 470
Service Level Management Workbook
Feedback from Post Implementation Reviews (PIRs) conducted as part of the Change Management process on major changes, releases, new or changed services etc.
Telephone perception surveys (perhaps at random on the Service Desk, or using regular customer liaison representatives)
Satisfaction survey handouts (left with customers following installations, service visits etc.)
User group or forum meetings
Analysis of complaints and compliments
Continued…
Where possible, targets should be set for these and monitored as part of the SLA. Ensure that if users provide feedback they receive some return, and demonstrate to them that their comments have been incorporated in an action plan, perhaps an SIP. All customer satisfaction measurements should be reviewed, and where variations are identified, they should be analysed with action taken to rectify the variation.
Page 471
Service Level Management Workbook
OLAs need not be very complicated, but should set out specific back-to-back targets for support groups that underpi8n the targets included in the SLAs. OLAs should be monitored against OLA and SLA targets, and reports on achievements provided as feedback to the appropriate managers of each support team. This highlights potential problem areas, which may need to be addressed internally or by a further review of the SLA or OLA. Before committing to new or revised SLAs, it is therefore important that existing contractual arrangements are investigated and, where necessary, upgraded.
SLM should identify the specific reporting needs and automate production of all reports wherever possible. The extent, accuracy and ease with which automated reports can be produced should form part of the selection criteria for integrated support tools. Page 472
Service Level Management Workbook
Operational reports must be produced on a regular basis. This should be weekly, or possibly more frequently and must produce exception reports whenever an SLA has been broken or threatened. Periodic reports must be produced and circulated to customers and appropriate IT managers a few days in advance of service level reviews, so that any queries or disagreements can be resolved ahead of any review meetings. These reports should incorporate details of performance against all SLA targets, together with details of any trends or specific actions being undertaken to improve service quality. Other interim reports may be required by IT management for OLA or internal performance reviews and/or supplier or contract management.
Continued…
It is essential that accurate information from all areas and all processes are analysed and collated into a concise and comprehensive report on service performance, as measured against agreed business targets. Service reports should not only include details of current performance, but should also provide historic information on past performance and trends, so that the impact of improvement actions can be measured and predicted.
Page 473
Service Level Management Workbook
Particular attention should be focused on each breach of service level to determine exactly what caused the loss of service and what can be done to prevent any recurrence. Reports should also be produced on the progress and success of the SIP, such as the number of SIP actions that were completed and the number of actions that delivered their expected benefit.
Reviews should ensure that the services covered have:
Relevant targets
No significant changes
Change Management control any agreed changes
Include overall strategy documents. Page 474
Service Level Management Workbook
The Business Service Catalogue provides information on all the key business and IT contacts relating to the services, their use and their importance. In order to ensure that this is done in a consistent manner, SLM should perform the following activities:
Confirm stakeholders, customers and key business managers and service users.
Assist with maintaining accurate information within the service portfolio and service catalogue.
Be flexible and responsive to the needs of the business, customers and users and understand current and planned new business processes and their requirements for new or changed services, documenting and communicating these requirements to all other processes as well as facilitating and innovating change wherever there is business benefit.
Develop a full understanding of business, customer and user strategies.
Regularly sample the customer experience – providing feedback on customer issues to IT
Ensure the correct relationship processes are in place to achieve objectives
Proactively market and exploit the Service Portfolio and Service Catalogue.
Promote service awareness and understanding
Page 475
Service Level Management Workbook
Continued…
Raise the awareness and understanding
Facilitate the development and negotiation of appropriate, achievable and realistic SLR‘s and Sla‘s between the business and IT.
Ensure the business, customers and users understand their responsibilities/commitments to IT.
Definitions of what constitutes a complaint and compliment should be agreed with the customers, together with the agreed procedures for their correct management and analysis. All complaints and compliments should be recorded and communicated to the relevant parties. All complaints should also be actioned and resolved to the satisfaction of the originator. If not, there should be an escalation procedure for all complaints that are not actioned and resolved within the agreed timescale. Reports should also be produced on the numbers and types of complaints, trends identified and actions taken to reduce the numbers received. Similar reports should be produced for compliments. Page 476
Service Level Management Workbook
Page 477
Service Level Management Workbook
Objective:
Number or percentage of service targets being met
Number and severity of service breaches
Number of services with up-to-date SLA‘s
Number of services with timely reports and active service reviews
Subjective: Improvement in customer satisfaction
Page 478
Service Level Management Workbook
CONTINUAL SERVICE IMPROVEMENT
Page 479
Service Level Management Workbook
Service Level Management (SLM) is a process that is found within two Service Lifecycle phases. Within Service Design, Service Level Management is concerned with:
Design and plan process
Determining Service Level Requirements (SLRs)
Negotiating and Agreeing upon SLAs, OLAs and UCs.
Within Continual Service Improvement, Service Level Management is concerned with improving services and processes through constant:
Monitoring (executed within Service Operation)
Reporting
Evaluating Page 480
Service Level Management Workbook
Improving
The major focus of Service Level Management within Continual Service Improvement is identifying potential service improvements.
This provides input into CSI activities and helps prioritize improvement projects. Even though SLM is critical for many organizations it is often one of the least mature processes. Service Level Management can be described using two words: building relationships! Building relationships with customers, the functional groups within IT and the vendor community who provide services to IT.
Page 481
Service Level Management Workbook
Even without any formal SLA‘s or OLA‘s, an organization can still strive to improve the services they provide to customers.
Explicit SLA: one of the goals of SLM, is to get a formal document that clearly defines the services provided, levels of service, quality of service and cost of the service. Everyone understands their responsibilities Implicit SLA: based on how you have provided your service in the past. If you provide good service the customers expect good service. If you improve on your service, then this becomes the new minimal level expected. Also if you have provided poor service in the past then your customers will actually expect poor service. Implicit SLA‘s are difficult to manage. Psychological SLA: often associated with the Service Desk where we publish information to the end users often b y putting a sticker on their monitor that states ‗if you need help call ######‘. In the mind of end users this creates an agreement that all they have to do is call the Service Desk to find a solution to their issues. In realty there are some Service Desks and Help Desks that provide less than ideal help!
Page 482
Service Level Management Workbook
SLM is essential in any organization so that levels of IT service needed to support the business can be determined, and monitoring can be initiated to identify whether the required service levels are being achieved – and if not, why not! Service Level Management is a cornerstone of CSI. Why embark on any service improvement initiative if the customers and the business are satisfied with the levels of service received? Because business requirements change!
The Service Level Management process is created in the Service Design phase of the Service Lifecycle. It is important that CSI is involved in the design of SLM to ensure that measurable targets are created. These targets can then be used to identify potential service improvements.
Page 483
Service Level Management Workbook
Where an underlying difficulty has been identified which is adversely impacting upon service quality, Service Level Management must, in conjunction with CSI, using Problem Management and Availability Management, instigate a SIP to identify and implement whatever actions are necessary to overcome the difficulties and restore service quality.
At any time, a number of separate initiatives that form part of the SIP may be running in parallel to address difficulties with a number of services.
Page 484
Service Level Management Workbook
If an organization is outsourcing its service provision to a third party, the issue of service improvement should be discussed at the outset and covered in the contract. Otherwise there is no incentive for the supplier to improve service targets if they are already meeting contractual obligations and additional expenditure is needed to make the improvements.
This model emphasizes the fact that there are many opportunities for CSI. The model illustrates a constant cycle for improvement. Additional info for Items to consider list:
Embrace the vision by understanding the high level business objectives.
Access the current situation to obtain an accurate and unbiased snapshot of where the organization right now. This baseline assessment is an analysis of Page 485
Service Level Management Workbook
the current position in terms of the business, organization, people, process and technology.
Based on a deeper development of the principles defined in the vision. The full vision can be years away but this step provides specific goals and a manageable timeframe.
Detail the CSI plan to achieve higher quality service provision by implementing ITSM processes.
Verify that measurements and metrics are in place to ensure that milestones were achieved, process compliance is high, and business objectives and priorities were met by the level of service.
Finally, the processes should ensure that the momentum for quality improvement is maintained by assuring that changes become embedded in the organization.
SUPPORTING DOCUMENTS Through the documents, look for text surrounded by << and >> these are indicators for you to create some specific text. Watch also for highlighted text which provides further guidance and instructions.
Objectives and Goals
IT Services Detailed Objectives/Goals Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Page 486
Service Level Management Workbook
Release Date:
Detailed Objectives/Goals for Service Level Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. The detailed objectives for Service Level Management should include the following salient points: Objective After they have been agreed upon a specific objective for the process is to continue reporting metrics. This is an activity that is often forgotten over time or simply not done from the out-set.
Notes Met/Exceeded/Shortfall
Dates/names/role titles
Appoint/Recruit the SLM team and provide ongoing awareness, education and training for staff involved with the process and communication to non-involved, but affected personnel. Setting schedules for reviews of Service Level Agreements and associated supporting documentation. Arranging the logistics of bringing the involved parties together (at intervals that are not considered to be a ―nuisance‖ but will allow the process objective to be upheld. Monitor customer and end-user satisfaction levels. Monitor the marketplace for appropriate process tools and make recommendations. Design, manage and implement an awareness/communication plan appropriate for this process.
Page 487
Service Level Management Workbook
Use these objectives to generate discussion about others that may be more appropriate to list than those provided. Failure to meet objectives (or when service breaches are detected) should trigger a process for improvement. Under the Service Level Management process, we refer to this as a Service Improvement Plan (SIP). Service Improvement Plan (SIP) Where an underlying difficulty has been identified that has lead to a degradation in service quality it is necessary for the Service Level Management process to start a Service Improvement Plan (SIP). The SIP must be drawn together with input from other processes (in particular Problem Management) so that the action steps in the SIP do in fact contribute to improvements and eradication of poor performance. Areas to address
Comments/Examples
SIP Reference number
Unique identifying number for the SLA (for inclusion in the Configuration Management Data Base – CMDB)
Owner
Functional role description of who is responsible for this SIP (who would participate in a review of this document). Representatives from customer and IT.
Service Name
Preferably use a name that is common language in the organization (not a technical name).
Service Description (Business) (refer to Technical Considerations later in this table)
Briefly describe the primary function of the service. Use language that is business user friendly. (eg. instead of ―NT Server, with 2Gb RAM and 500Gb of disk storage‖ – we would say ―large central server designed for all customers to use and share information from‖)
Service Breach(s) details
The SIP will generally be based on broken SLAs.
Time Frame/Notes/Who
Page 488
Service Level Management Workbook
(refer to Problem & Availability Management issues).
Use this section to briefly detail in generic terms why this SIP is required.
Problem Management details
The SIP will be driven as a result of the need to improve degraded performance. It is likely that there have been continuing Problems that have led to the service degradation. From Problem Management we can gain a better understanding of the background to the SIP.
Availability Management details
After the SIP is instigated the end users and customers should expect a higher level of service availability than they have in the past. The SIP must directly address the issue of availability by reviewing the past, current and future availability metrics for this service.
Service Security Considerations
Briefly list any considerations regarding security considerations for this SIP.
SIP Validity period
Is there a life-span for this SIP; is the life of the SIP time based or driven by activities only?
SPECIFIC SIP ACTIONS
This part of the SIP will outline actual steps to be taken to improve availability and eradicate poor performance. This section of the SIP can be run as a Project if large enough, or as a simple list of action items, responsible person and timeframe. Action items will centre on discussions, negotiations, communications, Page 489
Service Level Management Workbook
documentation (new and updates to existing), testing, reviews, training/education and reworking current procedures and work practices. (Note: don‘t forget to track changes and ensure the Configuration Management database is updated).
Version Control Information
SIP Creation Date SIP Last Modify Date
Technical considerations
In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalogue or Technical Specification.
Notes & Comments
Policies Objectives and Goals
IT Services Policies, Objectives and Scope Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Page 490
Service Level Management Workbook
Refer to Implementation Plan - Project Plan for planning and implementation guidelines (that includes the Policy, Objectives and Scope statements) on page 193. Policies, Objectives and Scope for Service Level Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered.
Policy Statement A course of action, guiding principle, or procedure considered expedient, prudent, or advantageous
Use this text box to answer the ―SENSE OF URGENCY‖ question regarding this process. Why is effort being put into this process? Not simply because someone thinks it‘s a good idea. That won‘t do. The reason has to be based in business benefits. You must be able to concisely document the reason behind starting or improving this process. Is it because of legal requirements or competitive advantage? Perhaps the business has suffered major problems or user satisfaction ratings are at the point where outsourcing is being considered. A policy statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHY question for this process. The above Policy Statement was; Prepared by: Objectives Statement On: <> And accepted by: On:
<>
Page 491
Service Level Management Workbook
Something worked toward or striven for; a goal Use this text box to answer the ―WHERE ARE WE GOING‖ question regarding this process. What will be the end result of this process and how will we know when we have reached the end result? Will we know because we will establish a few key metrics or measurements or will it be a more subjective decision, based on instinct? A generic sample statement on the “objective” for Service Level Management is: The Service Level Management process aims to improve, while maintaining, IT Service delivery quality. Actions to achieve this include the requirement to conduct repetitive actions that include reporting, agreeing and monitoring. The process must review Service Achievements against customer expectations and take steps to improve or modify Service Delivery accordingly. Note the keywords in the statement. For the statement on Service Level Management they are “report, agree and monitor”. These are definite areas that we can set metrics for and therefore measure progress.
The above Objective was;this text box, may be too lengthy to read, An objective statement Statement any bigger than lose the intended audience with detail, not be clearly focussed on answering the Prepared by: WHERE question for this process.
On:
<>
And accepted by: On:
<>
Scope Statement The area covered by a given activity or subject
Page 492
Service Level Management Workbook
Use this text box to answer the ―WHAT‖ question regarding this process. What are the boundaries for this process? What does the information flow look like into this process and from this process to other processes and functional areas? A generic sample statement on the “scope” for Service Level Management is: Through the use of agreements written in the form of documents the SLM process will manage relationships between providers of IT services that are both external to the organization and internal to the organization. These external agreements shall be referred to as Underpinning contracts and the internal agreements will be called Operational Level Agreements. An scope statement any bigger than this text box, may be too lengthy to read, lose the intended audience with detail, not be clearly focussed on answering the WHAT question for this process.
SLM Scope The above Scope Statement was; Prepared by: On:
<>
And accepted by: On:
<>
IT Services Scope Document Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Page 493
Service Level Management Workbook
Version:
<>
Release Date:
Document Control Author
Prepared by <> Document Source
This document is located on the LAN under the path: I:/IT Services/Service Delivery/Service Level Management/Scope Document Approval
This document has been approved for use by the following:
<>, IT Services Manager
<>, IT Service Delivery Manager
<>, National IT Help Desk Manager
Amendment History
Issue
Date
Amendments
Completed By
Distribution List
When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: <> Business Unit
Stakeholders
IT
Introduction Purpose The purpose of this document is to provide the IT Organization with the specifications of the IT Services that will be included within the scope of the Service Level Management Process. Scope Page 494
Service Level Management Workbook
This document describes the following:
Scope of Service Level Management
<>
Audience This document is relevant to all staff in <> Ownership IT Services has ownership of this document. Related Documentation Include in this section any related Service Level Management reference numbers and other associated documentation:
Implementation Plan / Project Plan
Policies, Guidelines and Scope Document
Process Template
Service Catalogue
Executive Overview Describe the purpose, scope and organization of the document. Service Level Management Overview The document‘s intent is to provide a scope for the Service Level Management Process. The definition of an SLA is: << Insert your organizations definition here >> The definition of an OLA is: << Insert your organizations definition here >> The definition of a UC is: << Insert your organizations definition here >> Process Scope The process scope details the scope of the activities that need to occur within the Service Level Management Process. Definition This activity helps define the services that you already deliver and can deliver. The output from this activity is the Service Catalogue. In this section determine the scope of the Service Catalogue. Specify Page 495
Service Level Management Workbook
This activity is about gathering the Service Level Requirements. This will be done by a series of interviews with department managers and senior executives. In this section determine the scope of the Requirements gathering.
Department
Services
Business Owner
IT Owner
<< Department:
The department to be interviewed
Services:
The services being provided to that department
Business Owner:
The department manager or other
IT Owner:
The IT personnel who will be responsible for providing the service
>> Negotiate and Agree In this activity we create the necessary SLAs, OLAs and UCs necessary to support the agreed services. In conjunction with the above table, we can now set the scope for the SLA. In this manner we need to determine what will be included in the SLA. For example: Customer
IT Service
Service Level Agreements Availability
Capacity
Marketing
Email
Sales and Support
Logistics
Disaster Recovery
Monitor Page 496
Service Level Management Workbook
In this section we need to set the scope for which aspects of the services we are going to monitor, and what tools we are going to use to monitor the services with. This will be done in conjunction with the above table. Reports Reports are an integral way of spreading information about IT Services back to the business as well as to IT Departments for process improvement. As such the reports should be written in Business English as well as Technical English. In this section, provide a list of reports necessary for each customer based on each service. The below table provides an example. Reports Customer
Business Reports
Service
Marketing
Email
Marketing
Internet
Sales
Logistics
Sales
Accounts
Transport
Logistics
IT Reports
Productivity
No. of Incidents
% of Availability
Bandwidth
CPU Seconds
Transaction Rates
Page 497
Service Level Management Workbook
Appendices Include any applicable appendixes that are needed. Terminology Make sure that all terminology is captured and documented correctly.
Business Justification Document
IT Services Business Justification Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Business Justification Document for Service Level Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a reference for HOW TO APPROACH THE TASK OF SEEKING FUNDS for the implementation of the Service Level Management process. This document provides a basis for completion within your own organization.
This document was; Service Level Prepared by: Management Business Justification A strong enough business case will ensure progress and funds are made available for any IT On: <> initiative. And accepted by: On:
<>
Page 498
Service Level Management Workbook
This may sound like a bold statement but it is true. As IT professionals we have (for too long) assumed that we miss out on funds while other functional areas (e.g. Human resources and other shared services) seem to get all that they want. However, the problem is not with them, it‘s with US. We are typically poor salespeople when it comes to putting our case forward. We try to impress with technical descriptions, rather than talking in a language that a business person understands. For example: We say
We should say
We have to increase IT security controls, with the implementation of a new firewall.
Two weeks ago our biggest competitor lost information that is now rumored to be available on the internet.
The network bandwidth is our biggest bottleneck and we have to go to a switched local environment.
The e-mail you send to the other national managers will take 4 to 6 hours to be delivered. It used to be 2 to 3 minutes, but we are now using our computers for many more tasks.
Changes to the environment are scheduled We are making the changes on Sunday for a period of time when we expect there afternoon. There will be less people working to be minimal business impact. then.
Doesn‘t that sound familiar? To help reinforce this point even further, consider the situation of buying a new fridge. What if the technically savvy sales person wants to explain ―the intricacies of the tubing structure used to super cool the high pressure gases, which flow in an anti-clockwise direction in the Southern hemisphere‖. Wouldn‘t you say ―too much information, who cares – does it make things cold?‖ Well IT managers need to stop trying to tell business managers about the tubing structure and just tell them what they are interested in. So let‘s know look at some benefits of Service Level Management. Remember that the comments here are generic, as they have to apply to any organization.
Notes/Comments/Relevance The most important aspect of Service Level Management is the monitoring and delivery of services that lead to increasing satisfaction levels of customers. (Note in ITIL terms the Customer is the person who Page 499
Service Level Management Workbook
―pays‖ for the IT Service)
With Service Level Management we focus on meeting the Service Level Requirements specified to us by customers. The SLR gives us a blueprint to check our own Service Delivery against. IT Services delivered that have no corresponding SLR may in fact be surplus to business requirements.
Service Level Management forces us into the creation of targets and metrics against which we can measure performance. If it can‘t be measured it can‘t be managed.
Through the process of Service Level Management we can develop a common language of understanding between IT and Customers. The process of establishing and monitoring performance levels means that when IT and business people discuss IT related issues they are in fact talking about the same thing (and not – as often happens – talking at odds with each other. For example if a meeting is held to discuss the Service Level Agreement for the provision of E-mail services then there is common ground for discussion.
Service Level Management also ensures that we have clearly defined roles and responsibilities. This is a clear benefit in that we can easily identify those involved with negotiations, escalations, monitoring and reporting. Even if one person performs many different roles within the process we can clearly articulate what these are. (importantly, the process also allows us to document customer responsibilities as well as IT)
The monitoring aspect of SLM is the perfect way to discover weak or potentially weak areas of Service Delivery. Ideally, identified in advance so that remedial action can be taken (e.g. Service Improvement Plan – SIP)
Page 500
Service Level Management Workbook
SLM underpins supplier management (and vice versa) - in cases where services are outsourced the SLAs are a key part of managing the relationship with the thirdparty - in other cases service monitoring allows the performance of suppliers (internal and external) to be evaluated and managed When we create Service Level Agreements – the most widely known single activity of Service Level Management - we generally include a section on Pricing. The SLA then becomes the basis of charging for IT Services (Note that IT Service Managers must be able to clearly articulate the difference between cost and value – cost is discussed in absolute monetary terms; value is a discussion regarding potential business impact).
An important, but often overlooked part of this process is the identification of weaknesses in the use of IT Services from the organization end-user population. Monitoring the nature of calls for support and general communication can help us to identify such weaknesses and therefore suggest education programs that will address the lack of knowledge and skill.
Having a continuous improvement philosophy regarding IT Service delivery ensures that the IT Department is (a) looking to reduce service disruptions and (b) decrease the overall cost of service delivery (without compromising the quality).
Organizing for Service Design – Roles & Responsibilities To enable the Service Design phase to be successful, it is essential that the relevant roles and responsibilities are defined, within the organization of various activities. When designing a service or a process, it is imperative that all the roles are clearly defined. A trademark of high performing organizations is the ability to make the right decisions quickly and execute them effectively. Whether the decision involves a strategic choice or a critical operation, being clear on who has input, who decides and who takes action will enable the company to move forward rapidly. The RACI model is beneficial in enabling decisions to be made with pace and confidence. RACI is an acronym for the main roles of: Responsible – person or people responsible for getting the job done. Page 501
Service Level Management Workbook
Accountable – only one person can be accountable for each task. Consulted – people who are consulted and whose opinions are sort. Informed – people who are kept up-to-date on progress. Occasionally an extended version of RACI is used called RACI-VS, with two further roles as follows: Verifies – person or group that checks whether the acceptance criteria have been met. Signs off – person who approves the V decision and authorizes the product hand-off. This could be the Accountable (or A) person. A third variation of the RACI model is RASCI, where the S represents Supportive. This role provides additional resources to conduct the work, or plays a supportive role in implementation, for example. This could be beneficial for IT service implementation. The RACI chart shown below in Table 1 shows the structure and power of RACI modelling with the activities down the left-hand side including the actions that need to be taken and decisions that must be made. Across the top, the chart lists the functional roles responsible for carrying out the initiative or playing a part in decision making. Whether RACI or some other tool or model is used, the important thing is to not just leave the assignment of responsibilities to chance or leave it to the last minute to decide. Conflicts can be avoided and decisions can be made quickly if the roles are allocated in advance. To build a RACI chart the following steps are required:
Identify the activities/processes
Identify/define the functional roles
Conduct meetings and assign the RACI codes
Identify any gaps or overlaps – e.g. where there are two R‘s or no R‘s
Distribute the chart and incorporate feedback
Ensure that the allocations are being followed.
Table 1 Example RACI matrix
Director service management
Service Level Manager
Problem Manager
Security Manager
Procurement Manager
Page 502
Service Level Management Workbook
Activity 1
AR
C
I
I
C
Activity 2
A
R
C
C
C
Activity 3
I
A
R
I
C
Activity 4
I
A
R
I
Activity 5
I
I
A
C
I
Page 503
Service Level Management Workbook
Functional Roles Analysis
Many A‘s: are duties segregated properly? Should someone else be accountable for some of these activities? Is this causing a bottleneck in some areas that will delay decisions?
Many R‘s: Is this too much for one function?
No empty spaces: Does this role need to be involved in so many tasks?
Also, does the type or degree of participation for this role‘s qualifications?
Activity Analysis
More than one A: only one role can be accountable.
No A‘s‖: at least one A must be assigned to each activity.
More than one R: too many roles responsible often mean that no one takes responsibility. Responsibility may be shared, but only if roles are clear.
No R‘s: at least one person must be responsible.
Many C‘s: is there a requirement to consult with so many roles? What are the benefits and can the extra time be justified?
No C‘s and I‘s: are the communication channels open to enable people and departments to talk to each other and keep each other up-to-date .
Skills & Attributes The specific roles within ITIL Service Management all require specific skills, attributes and competences from the people involved to enable them to work effectively and efficiently. However, whatever role, it is imperative that the person carrying out that role has the following attributes:
Awareness of the business priorities, objectives and business drivers
Awareness of the role IT plays in enabling the business objectives to be met
Customer service skills
Awareness of what IT can deliver to the business, including latest capabilities
The competence, knowledge and information necessary to complete their role
The ability to use, understand and interpret the best practice, policies and procedures to ensure adherence.
The following are examples of attributes required in many of the roles, dependent on the organization and the specific role:
Page 504
Service Level Management Workbook
Management skills – both from a person management perspective and from the overall control of process. Meeting skills – to organize, chair, document and ensure actions are followed up Communications – an important element of all roles is raising awareness of the processes to ensure buy-in and conformance. An ability to communicate at all levels within the organization will be imperative. Articulate - both written, for reports etc., and verbal Negotiation – required for several aspects, such as procurement and contracts Analytical – to analyse metrics produced from the activity. More information about the skills and competences of these roles can be found within the Skills Framework for the Information Age (SFIA – www.sfia.org.uk) Service Level Manager The Service Level Manager has responsibility for ensuring that the aims of Service Level Management are met. This includes responsibilities such as:
Keeping aware of changing business needs
Ensuring that the current and future service requirements of customers are identified, understood and documented in SLA and SLR documents.
Negotiating and agreeing levels of service to be delivered with the customer (either internal or external); formally documenting these levels of service in SLA‘s.
Negotiating and agreeing OLA‘s and, in some cases, other SLA‘s and agreements that underpin the SLA‘s with the customers of the service.
Assisting with the production and maintenance of an accurate Service Portfolio, Service Catalogue, Application Portfolio and the corresponding maintenance procedures.
Ensuring that targets agreed within underpinning contracts are aligned with SLA and SLR targets.
Ensuring that service reports are produced for each customer service and that breaches of SLA targets are highlighted, investigated and actions taken to prevent their recurrence.
Ensuring that service performance reviews are scheduled, carried out with customers regularly and are documented with agreed actions progressed. Page 505
Service Level Management Workbook
Ensuring that improvement initiatives identified in service reviews are acted on and progress reports are provide to customers
Reviewing service scope, SLA‘s, OLA‘s and other agreements on a regular basis, ideally at least annually.
Ensuring that all changes are assessed for their impact on service levels, including SLA‘s, OLA‘s and underpinning contracts, including attendance at CAB meetings if appropriate.
Identifying all key stakeholders and customers
Developing relationships and communication with stakeholders, customers and key users.
Defining and agreeing complaints and their recording management, escalation, where necessary, and resolution
Definition recording and communication of all complaints
Measuring, recording, analysing and improving customer satisfaction.
SLM Process Manager
IT Services Role, Responsibilities Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Detailed responsibilities of the Service Level Management process owner The Service Level Manager….. Page 506
Service Level Management Workbook
Description
Notes/Comments
17. Will design, maintain and review a structure for the process that covers the interactions of the people involved and the expected content of Service Level Management related documents (involving IT and Customers) AND Coordinates any required Service Improvement Plans/Programmes to eradicate falling Service Delivery performance
Use the notes/Comments column in different ways. If you are looking to apply for a process role, then you can check yourself against the list (with ticks or look to update your resume).
18. Will coordinate process reviews utilizing independent parties to provide an objective view on the simplicity of the process and areas for improvement. Will be responsible for implementing any design improvements identified. 19. Will establish, maintain and review: Service Level Agreements with the business Customer (including a decision on SLA Structure). Operational Level Agreements with the IT provider Underpinning Contracts with third party providers.
If you are looking to appoint a process manager or promote someone from within the organization you can make notes about their abilities in the particular area.
20. Is responsible for the creation, maintenance, marketing and distribution of the Service Catalog (which documents the IT Services offered by the organization) 21. Will control and review: Any outstanding process related actions Current targets for service performance Performance against SLAs, OLAs and UCs 22. Make available relevant, concise reports that are both timely and readable for Customers and IT providers.
Detailed skills of the Service Level Management process owner The Service Level Manager….. Description
Notes/Comments
17. The Service Level Manager will display a communication style based around listening and demonstrable genuine interest. Ability to use and apply valuable information gained from customers. Page 507
Service Level Management Workbook 18. High degree of people/relationship management focus and an ability to deal with an administrative workload. Will also tend to be balanced in negotiations – almost to the point of neutrality during discussions between the customer and the IT Service Provider. 19. The Service Level Manager will take an active interest in learning about services offered by external and internal providers. The manager will be interested in understanding how services are provided, rather than just accepting a marketing statement. 20. The Service Level Manager must have good oral and presentation skills. They are a ―champion‖ for this process and must display an air of confidence, without arrogance. 21. The Service Level Manager must be able to communicate with people at all levels of the organization; this is one contributing factor that also will require a high degree of understanding of human emotion and resistance. 22. The process manager must be able to demonstrate ways to ―do things differently‖ that will improve the process. They must not be risk adverse, but must be very risk conscious. 23. Although not a highly numeric role, the selected person must be able to understand the basics of supply and demand, with a commonsense attitude to service charging and a grip on basic statistical analysis. 24. The process manager will need to be able to engage in technical discussions with technical people (to ensure credibility) and to engage in business discussions with business people, about those technical issues (of course in non-technical terms).
Customer Based SLA
IT Services Customer Based SLA Page 508
Service Level Management Workbook
Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Customer Based Service Level Agreement (SLA) The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE CUSTOMER OF IT SERVICES (Covering all the IT Services they use). This document provides a basis for completion within your own organization. The customer based SLA is usually preferred by customers as it allows a single document to cover all the IT Services that they use. It means less administration time spent in negotiating different documents and generally only requires a single representative to participate on behalf of the business. An agreement with an individual Customer group, covering all the services they use. For example, agreements may be reached with an organization‘s Finance Department covering, say, the Finance System, the Accounting System, the Payroll System, the Billing System, the Procurement System and any other IT systems that they use.
Advantage Customer based SLA
Disadvantage
An agreement with an individual Customer groups could cover all of the services they use.
An inability to deal with differing requirements amongst users in the same customer group.
Page 509
Service Level Management Workbook
Service A Service B
Customer
Service C
The following form can be used as the Customer Based SLA document. The SLA does not have to be in a lengthy written format and in fact it is more likely to be adopted if it is kept concise, with only salient details. With regard to Customer Based SLA the following points should be addressed: Overall SLA Information
Areas to address
Comments/Examples
Description of the ―agreement‖
Brief description of the contents of this SLA Note: the SLA may cover several IT Services. Use this section simply as an Executive summary. Do not try to describe each service here.
Reference number
Unique identifying number for the SLA (for inclusion in the Configuration Management Data Base – CMDB)
Owner
Functional role description of who is responsible for this SLA (who would participate in a review of this document?) Representatives from customer and IT. (Special tip: Avoid using names as it dates the document quickly)
Time Frame/Notes/Who
Page 510
Service Level Management Workbook
Customer definition
List and/or describe the customers that are considered for in this SLA.
SLA Validity period
Duration that this SLA is expected to remain in place before it is reviewed.
SLA Review Procedure
The process for reviewing the SLA and who is involved. Special Tip: Avoid using people‘s names and use role descriptions to avoid dating the document.
Version Control Information
SLA Creation Date SLA Last Modify Date
Specific Service Information (Duplicate the following table for each service to be covered in this SLA). Areas to address
Comments/Examples
Service Name
Preferably use a name that is common language in the organization (not a technical name).
Service Description (Business) (refer to end of table for technical considerations)
Briefly describe the primary function of the service. Use language that is business user friendly. (eg. instead of ―NT Server, with 2Gb RAM and 500Gb of disk storage‖ – we would say ―large central server designed for all customers to use and share information‖)
Time Frame/Notes/Who
Page 511
Service Level Management Workbook Service Expectation Level
This is a unique concept to this SLA design template. Far too often we write descriptions of IT Services in a clinical fashion. These clinical descriptions set an expectation for the customer/end-user about the IT Service. Quite often the description is interpreted by the reader in a way not intended by the writer. Use this section to set the expectations of the reader. If you feel that there could be some interruptions to service delivery, because the service is relatively new, then document that here. However, remember that using the reason ―new service‖ has only a limited life-span.
Service Security Considerations
Briefly list any considerations regarding security considerations for this service. Are there any differences in the level of accessibility for different people/roles for this service? (try to use role descriptions – instead of names)?
Service Target Response priorities
If the SLA accommodates different priorities they must be listed here, with a description on the type of service that each priority level should receive.
Service Target Response time
Here we document the agreed response time for the different priority levels.
Service Support Hours
Consider marginally longer Page 512
Service Level Management Workbook (Availability)
support hours (if less than 24) Maximum number of accepted outages. Minimum percentage availability. Maximum number of errors or reruns.
Service Out of Hours support procedure
Are the in hours support staff the same as out of hours? Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?
Service Charging policy
Do we require external staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?
Service Metrics for performance
What will be the performance numbers for the work performed under this UC? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?
Service Breach Clause
Perhaps your organizational culture is built upon imposing penalties for poor performance. If this is the case, then the penalties for failing to meet the stated metrics must be listed here. If the SLA is not to have a penalty focus, then simply remove this line.
Page 513
Service Level Management Workbook Continuity Considerations (should be linked to the IT Service Continuity Plan)
If the agreed support hours cannot be met, then it is necessary to invoke a continuity option for this service. The definition of when this invocation should occur will be listed here. Cross-referencing to the IT Service Continuity Plan is also required.
UC Cross references
Reference number to related and closely coupled UCs
OLA Cross references
Reference number to any closely coupled agreements with internal IT department
Technical considerations
In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalogue or Technical Specification.
Notes & Comments
NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS.
Service Based SLA
IT Services Service Based SLA Process: Service Level Management Page 514
Service Level Management Workbook
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Service Based Service Level Agreement (SLA) The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE CUSTOMER OF IT SERVICES, FOR A SINGLE SERVICE. This document provides a basis for completion within your own organization. The service based SLA is usually preferred by IT as it allows a single document to cover a single service for all end-users of that service. It means less administration time spent in negotiating different documents with different customers and less time spent on worrying about accommodating different requirements amongst users.
Advantage Service based SLA Disadvantage
Just one SLA document could be agreed for all Customers/end users of a single service. Inability to satisfy the customers that have differing requirements of the service being addressed.
Customer A Service
Customer B Customer C
This document was; Prepared by: On:
<>
And accepted by: On:
<>
Page 515
Service Level Management Workbook
The following form can be used as the Service Based SLA document. The SLA does not have to be in a lengthy written format and in fact it is more likely to be adopted if it is kept concise, with only salient details. With regard to Service Based SLA the following points should be addressed:
Specific Service Information (Duplicate the following table for as many services to be covered in this SLA).
Areas to address
Comments/Examples
Description of the ―agreement‖
Brief description of the contents of this SLA Note: the SLA will cover only ONE IT Service, but end users from many areas. Use this section simply as an Executive summary.
Reference number
Unique identifying number for the SLA (for inclusion in the Configuration Management Data Base – CMDB)
Owner
Functional role description of who is responsible for this SLA (who would participate in a review of this document?). Representatives from customer and IT. (Special tip: Avoid using names as it dates the document quickly)
Service Name
Preferably use a name that is common language in the organization (not a technical name).
Time Frame/Notes/Who
Service Description (Business) Briefly describe the primary (refer to Technical function of the service. Considerations later in this table) Use language that is business Page 516
Service Level Management Workbook user friendly. (eg. instead of ―NT Server, with 2Gb RAM and 500Gb of disk storage‖ – we would say ―large central server designed for all customers to use and share information‖)
Service Expectation Level
This is a unique concept to this SLA design template. Far too often we write descriptions of IT Services in a clinical fashion. These clinical descriptions set an expectation for the customer/end-user about the IT Service. Quite often the description is interpreted by the reader in a way not intended by the writer. Use this section to set the expectations of the reader. If you feel that there could be some interruptions to service delivery, because the service is relatively new, then document that here. However, remember that using the reason ―new service‖ has only a limited life-span.
Service Security Considerations
Briefly list any considerations regarding security considerations for this service. Are there any differences in the level of accessibility for different people/roles for this service? (try to use role descriptions – instead of names)?
Service Target Response priorities
If the SLA accommodates different priorities they must be listed here, with a description on the type of service that each priority level should receive.
Service Target Response time
Here we document the agreed response time for the different Page 517
Service Level Management Workbook priority levels set.
Service Support Hours (Availability)
Consider marginally longer support hours (if less than 24) Maximum number of accepted outages. Minimum percentage availability. Maximum number of errors or reruns.
Service Out of Hours support procedure
Are the in hours support staff the same as out of hours? Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?
Service Charging policy
Do we require external staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?
Service Metrics for performance
What will be the performance numbers for the work performed under this UC? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?
Service Breach Clause
Perhaps your organizational culture is built upon imposing penalties for poor performance. If this is the case, then the penalties for failing to meet the stated metrics must be listed here. If the SLA is not to have a penalty focus, then simply remove this line.
Continuity Considerations
If the agreed support hours Page 518
Service Level Management Workbook (should be linked to the IT Service Continuity Plan)
cannot be met, then it is necessary to invoke a continuity option for this service. The definition of when this invocation should occur will be listed here. Cross-referencing to the IT Service Continuity Plan is also required.
SLA Validity period
Duration that this SLA is expected to remain in place before it is reviewed.
SLA Review Procedure
The process for reviewing the SLA and who is involved. Special Tip: Avoid using people‘s names and use role descriptions to avoid dating the document.
Version Control Information
SLA Creation Date SLA Last Modify Date
UC Cross references
Reference number to related and closely coupled UCs
OLA Cross references
Reference number to any closely coupled agreements with internal IT department
Technical considerations
In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalog or Technical Specification.
Notes & Comments
Page 519
Service Level Management Workbook Customer Information Areas to address
Comments/Examples
Time Frame/Notes/Who
Customer definition List and/or describe the customers that are included in this SLA. It is most likely that the customers will be all endusers of IT services in the organization. However, the SLA for this service may be only for particular function holders that are spread throughout the organization).
NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS.
Multi Level SLA’s
IT Services Multi-Level Based SLA Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Page 520
Service Level Management Workbook
Version:
<>
Release Date:
Multi-Level Based Service Level Agreement (SLA) The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE CUSTOMER OF IT SERVICES, FOR MULTIPLE SERVICES. This document provides a basis for completion within your own organization. The multi-level based SLA is usually preferred by IT as it allows a single document to cover a single service for all end-users of that service. It means less administration time spent in negotiating different documents with different customers and less time spent on worrying about accommodating different requirements amongst users. This structure allows SLAs to be kept to a manageable size, avoids unnecessary duplication, and reduces the need for frequent updates.
Advantage Multi-Level based SLA
It requires more time to negotiate and obtain agreement than other structures.
Disadvantage
SERVICE D
Service A
Customer
Service B
Customer
Service C
This document was; Prepared by:
(The following form can be used as the Multi-Level Based SLA document. The SLA On:
<>
does not have to be in a lengthy written format and in fact it is more likely to be And accepted adopted if it isby: kept concise, with only salient details)
SLA On: Information
<> Page 521
Service Level Management Workbook
Areas to address
Comments/Examples
Time Frame/Notes/Who
Description of the ―agreement‖
Brief description of the contents of this SLA Note: the SLA will cover only ONE IT Service, but end users from many areas. Use this section simply as an Executive summary.
Reference number
Unique identifying number for the SLA (for inclusion in the Configuration Management Data Base – CMDB)
Owner
Functional role description of who is responsible for this SLA (who would participate in a review of this document?). Representatives from customer and IT. (Special tip: Avoid using names as it dates the document quickly)
Specific Service Information (Duplicate the following table for as many services to be covered). Areas to address
Comments/Examples
Service Identification Code (This code can be crossreferenced in the Customer information table).
A unique reference number for this service.
Service Name
Preferably use a name that is common language in the organization (not a technical name).
Service Description (Business) (refer to Technical Considerations later in this
Briefly describe the primary function of the service. Use language that is business user friendly.
Time Frame/Notes/Who
Page 522
Service Level Management Workbook table)
(eg. instead of ―NT Server, with 2Gb RAM and 500Gb of disk storage‖ – we would say ―large central server designed for all customers to use and share information‖)
Service Expectation Level
This is a unique concept to this SLA design template. Far too often we write descriptions of IT Services in a clinical fashion. These clinical descriptions set an expectation for the customer/end-user about the IT Service. Quite often the description is interpreted by the reader in a way not intended by the writer. Use this section to set the expectations of the reader. If you feel that there could be some interruptions to service delivery, because the service is relatively new, then document that here. However, remember that using the reason ―new service‖ has only a limited life-span.
Service Security Considerations
Briefly list any considerations regarding security considerations for this service. Are there any differences in the level of accessibility for different people/roles for this service? (try to use role descriptions – instead of names)?
Service Target Response priorities
If the SLA accommodates different priorities they must be listed here, with a description on the type of service that each priority level should receive.
Service Target Response time
Here we document the agreed Page 523
Service Level Management Workbook response time for the different priority levels set.
Service Support Hours (Availability)
Consider marginally longer support hours (if less than 24) Maximum number of accepted outages. Minimum percentage availability. Maximum number of errors or reruns.
Service Out of Hours support procedure
Are the in hours support staff the same as out of hours? Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?
Service Charging policy
Do we require external staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?
Service Metrics for performance
What will be the performance numbers for the work performed under this UC? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?
Service Breach Clause
Perhaps your organizational culture is built upon imposing penalties for poor performance. If this is the case, then the penalties for failing to meet the stated metrics must be listed here. If the SLA is not to have a penalty focus, then simply Page 524
Service Level Management Workbook remove this line.
Continuity Considerations (should be linked to the IT Service Continuity Plan)
If the agreed support hours cannot be met, then it is necessary to invoke a continuity option for this service. The definition of when this invocation should occur will be listed here. Cross-referencing to the IT Service Continuity Plan is also required.
SLA Validity period
Duration that this SLA is expected to remain in place before it is reviewed.
SLA Review Procedure
The process for reviewing the SLA and who is involved. Special Tip: Avoid using people‘s names and use role descriptions to avoid dating the document.
Version Control Information
SLA Creation Date SLA Last Modify Date
UC Cross references
Reference number to related and closely coupled UCs
OLA Cross references
Reference number to any closely coupled agreements with internal IT department
Technical considerations
In this section you can describe any technical considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalog or Technical Specification.
Page 525
Service Level Management Workbook Notes & Comments
Customer Information
(Duplicate the following table for as many customers to be covered). Areas to address
Comments/Examples
Time Frame/Notes/Who
Customer definition
List and/or describe the customers that are included in this SLA. It is most likely that the customers will be all end-users of IT services in the organization. However, the SLA for this service may be only for particular function holders that are spread throughout the organization).
Applicable Services
Description of Service and/or Service identification code/s
NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF AN SLA THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF AN SLA and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS.
Business and IT Service Mapping
IT Services Business and IT Service Mapping Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved
Page 526
Service Level Management Workbook Rejected
Version:
<>
Release Date:
Document Control Author Prepared by Document Source This document is located on the LAN under the path: I:/IT Services/Service Delivery/Business and IT Service Mapping/ Document Approval This document has been approved for use by the following:
, IT Services Manager
, IT Service Delivery Manager
, National IT Help Desk Manager
Amendment History Issue
Date
Amendments
Completed By
Distribution List When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: <> Business Unit
Stakeholders
IT
Introduction Purpose The purpose of this document is to provide IT departments with an understanding of how the IT Services provided map to the organization‘s business processes. Page 527
Service Level Management Workbook
Scope This document describes the following:
details of each Business Process and the corresponding IT Service provided by the IT departments within the organization:
description of business process
description of service
business contacts
service contacts
Note: It is assumed for each Business Process and IT Service described in this document that the supporting back-end technology is already in place and operational. Audience This document is relevant to all staff in <> Ownership IT Services has ownership of this document in conjunction with nominated Business Representatives. Related Documentation The following documents may help you to complete or understand the purpose of this document:
Relevant SLA and procedural documents
Relevant IT Services Catalogue
Relevant Technical Specification documentation
Relevant Functional Specification documentation
Relevant User Guides and Procedures
Executive Overview In the past organization‘s IT Services functions have generally grown and developed into large complex environments. Unfortunately this growth has not always been as structured and pre-planned as it should have been. The result has been an IT department not having a very clear picture of all the services they currently provide, and with no accurate profile of the actual customers for each of these services.
Page 528
Service Level Management Workbook
With increasing demands being placed on IT services and increasing reliance on IT systems, it has become imperative for the IT department to establish an accurate picture of the services it provides and to whom it provides them. This document describes an approach for mapping IT Services to the Business Process. That is, mapping what services are provided by IT to the business areas that use them. Mapping Business Process and IT Service: An approach Most organizations now understand the benefits of having Information Technology (IT) throughout their structure. Few realize the potential of truly aligning the IT department‘s objectives with the business objectives. However, more and more organizations are beginning to recognize IT as being a crucial delivery mechanism of services to their customers. When the IT services are so critical, steps must be in place to ensure that the IT group adds value and delivers consistently. In line with this concept, the first step in mapping IT Services to the needs of the business is to understand the organization. An organization starts with a Mission Statement. The Mission Statement for an organization defines its reason for being. Once we capture the Mission Statement, the next thing to look at is the Vision Statement. The Vision Statement defines where it is that the organization wants to go. By understanding where the organization wishes to position itself within its market space, then we can start looking at how its short term and long term objectives align with this. At this point we need to see the ―objectives and strategy‖ of the organization. By having this information, IT departments are more likely to be aware of the pressing business issues and needs that may impact on the services that they provide. For example, the organization may have an objective of expanding its business into new markets within the next 12 months, requiring additional offices and staff. The direct impact on IT departments would be the successful planning of capacity of new IT Services, the successful planning of how to change our current services to meet the demands of the business, and being flexible enough to meet these demands. However, an objective is not sufficient enough to determine how IT departments should be delivering its services. The organization will meet these objectives by changing, enhancing or creating new business processes. For example, Page 529
Service Level Management Workbook
Administration staff may need additional resources, a new ordering package may be required, or perhaps a new billing process needs to be implemented to meet these objectives. Therefore, after capturing the organizational objectives, we need to understand how these map to current business process, if the current business processes are changing or if they are becoming obsolete and if there will be any new business processes. This is where the IT departments need to capture the Business Processes being used by the organization. Once the IT departments have a clear view of each of the business units involved in the business process, we need to capture the fact that the business processes need one or more IT services (eg. CRM application, e-mail, word processing, financial tools) to function. Each of these IT services runs on IT infrastructure. This is where IT departments now map the IT Services to those Business Processes listed above. With this information IT Departments will now be able to clearly see how their IT Infrastructure / IT Services supports the business. This allows IT to better deliver IT aligned Services to the organization. A simple model for this approach is illustrated below.
What are the Objectives of the organization? What is its Mission and Vision?
What Business Processes are in place or will be in place to meet these needs?
What IT Services are needed or in place to service the Business Processes?
Business Objectives
Business Processes
IT Services
Page 530
Service Level Management Workbook
Mission Statement A mission statement describes the reason for the organization‘s being. Without an understanding of the mission statement of an organization, it becomes hard to define what it is that the organization is trying to achieve. In this section of the document capture the mission statement of the organization. It is important to show that the IT department is aware of the business. Vision Statement In this section, document the Vision statement for the organization. Below is a text example of what may be included in this section. Listed below is the Vision Statement for <>:
Quality Care
Convenient Service
Good Experiences
Care at Competitive Prices
Service You'll Recommend to Friends and Family
These are the major goals of the staff at <>. With over xxx services and xxx staff, we constantly strive to provide the highest-quality service throughout the xxxxxxxx. >>
Business Process Summary The below table is an example of a Business Process Summary Table. Columns and Rows can be added as needed. A more detailed breakdown of each process name is provided in the following pages. << Business Process Name: The name of the process if available Process Owner:
The name of the Department head or Business Representative for the process
Description:
A brief description of the process
Department(s):
The Department(s) that is involved or uses this process
Parent Process:
Any process that may be considered a lead into this process or is seen has having a higher business criticality
Triggers:
What causes the process to start? This is important as IT can then determine if and how their Services interact with other business process or external organizations. Page 531
Service Level Management Workbook
>>
BUSINESS Process Name
Process Owner
Description
Department(s)
Parent Process
Triggers
Business Process A This section of the document should be repeated for each Business Process. Department Name of the department Process Name of the process, and official abbreviation, if any Process Owner Name of the Department head or person responsible for ensuring the effectiveness and efficiency of the process. Description Briefly explain the purpose of the business process. Parent Business Activity/Process Name of the parent business activity or process, if any Primary Product(s) List the primary product(s), and explain if necessary. Identify the customer for each primary product. Trigger(s) List the event(s) that trigger the process. (Triggers can be a calendar date, as well as an actual event.) Sub-processes If the process is subdivided, list the sub-processes here. Standard Path Events/Activities Page 532
Service Level Management Workbook
List the important activities and/or events that occur as part of the standard path for this process. If an activity or event occurs in a specific sub-process, identify the subprocess that includes the activity/event. Note any locations where an alternative path breaks off from the standard path. Alternative Path Events/Activities List the important activities and/or events that occur as part of the alternative path for this process, beginning with a note on where the alternative path breaks off from the standard path, and ending with a note on where the alternative path rejoins the standard path, if it does. If an activity or event occurs in a specific sub-process, identify the sub-process that includes the activity/event. Inputs List the inputs to the process, and explain if necessary. Identify the source of the input. If the input is specific to a sub-process, identify the sub-process. Secondary Products List the by-products, or minor outputs that result from the process. Identify the customer for each output. If the secondary product is specific to a sub-process, identify the sub-process. Participants List the participants (actors) in the process, and explain their function briefly. If the participant is active only in a specific sub-process, identify the sub-process. IT Services The following section provides a table for capturing those IT Services that help support the business process described in this section. << Fields:
IT Service:
In this field capture the name of the IT Service. A likely source of for this information would be the IT Service Catalogue.
Description:
Write a brief description about the service.
IT Service Owner:
List any responsibilities for this IT Service. This would include the owner of the IT Service and any Page 533
Service Level Management Workbook
additional support personnel that are involved in the deliver of the IT Service.
Hours of Availability:
List the hours of support for the particular IT Service. Eg. 24 hours x 7 Days per week, Monday – Friday: 8.00am – 6.00pm, etc.
Contract:
Is the IT Service provided under the agreement of a contract? If so, it is important to capture any contracts that may be in place for the IT Service. Contracts will have a direct impact on how the IT Service is delivered.
Service Level Agreements: List any applicable SLAs for the IT Service.
Impact:
If the particular IT Service was unavailable, how would this impact on the Business Process.
>> This table should be used on a landscape page layout.
IT Service
Description
IT Service Owner
Hours of Availability
Contract
Service Level Agreements
Impact
Business Process B Department Process Process Owner Page 534
Service Level Management Workbook
Description Parent Business Activity/Process Primary Product(s) Trigger(s) Sub-processes Standard Path Events/Activities Alternative Path Events/Activities Inputs Secondary Products Participants IT Services IT Service
Description
IT Service Owner
Hours of Availability
Contract
Service Level Agreements
Impact
Page 535
Service Level Management Workbook
Business Process and IT Service Summary This section provides a summary matrix table of the business processes and their corresponding IT Services. This is a comprehensive summary table designed to be tailored for your needs. If necessary add or remove rows and columns as needed. A simpler matrix may be just as effective for your needs. The table breaks down the IT Services and offers you the ability to capture the owner of the IT Service, the impact of the service on the business process and the agreed service hours. The impact is an arbitrary value that IT and the business need to agree upon. These values may be defined within the Service Catalogue or the Service Level Agreements. The table also breaks down the Business Processes and offers you the ability to capture the department(s) that are involved in that particular business process, the business owner of the process, and the business rating. The Business Owner may be hard to define in an organization, in this instance there maybe a number of owners of the process which would generally be made up of the Department heads. The Business Rating is also an arbitrary value that the business needs to agree upon. In most instances each department will rate their business processes Critical or Very High. The easy way to determine the Business Rating of the process would be to ascertain if the business could still deliver its services if that business process was unavailable for a period of time.
Business Process A
IT Services
Owner Service A Impact
<>
Business Process B
Department
Owner
Business Rating
Department
Owner
Business Rating
Accounting
<<Busines s Process Owner>>
Very High
Admin
<<Business Process Owner>>
Medium
Very
Page 536
Service Level Management Workbook High
Service B
Service C
Service D
Servic e Hours
24 x 7
Owner
<>
Impact
High
Servic e Hours
Mon-Fri: 8am 6pm
Owner
<>
Impact
Medium
Servic e Hours
Mon-Sat: 6am 6pm
Owner
<>
Impact
Low
Servic e Hours
Mon-Fri: 6am 10pm
Appendices List any appendices needed in conjunction with this document. Terminology IT Infrastructure: includes hardware, software, procedures, policies, documentation, etc.
Operational Level Agreement
IT Services Operational Level Agreement Process: Service Level Management Page 537
Service Level Management Workbook
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Operational Level Agreement (OLA) The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND THE IT DEPARTMENT. This document provides a basis for completion within your own organization. There is a common misconception that the Service Level Management Process owner must be a member of the IT Department. This is not the case and quite often the best person for the role is someone with no bias towards IT. For example, a Human Resource Manager would do well in a role that has such a high degree of communication required.
This document was;
(The following Prepared by: form can be used as the OLA document. The OLA does not have to be in a lengthy written format and in fact it is more likely to be adopted if it is kept On:
<>
concise, with only salient details) And accepted by: With regard to OPERATIONAL LEVEL AGREEMENTS (OLAs) the following points should beOn: addressed:
<>
Areas to address
Link to parent Service Level Agreement
Comments/Examples
Time Frame/Notes/Who
Cross reference to the ―parent‖ SLA.
Page 538
Service Level Management Workbook Description of Service
Brief description (should be taken from SLA)
OLA Reference number
Unique identifying number for the OLA (for inclusion in the Configuration Management Data Base – CMDB)
OLA Owner
Functional role description of who is responsible for this OLA (who would participate in a review of this document) (Special tip: Avoid using names as it dates the document quickly)
OLA Parties involved
Within the IT department perhaps there are different functional parties involved. List them here with a brief description of their involvement.
OLA Target Response priorities (reflected in parent SLA)
If the OLA caters for different priorities they must be listed here, with a description on the type of service that each priority level should receive.
OLA Target Response time (reflected in parent SLA)
Consider quicker response time to allow for delays
Page 539
Service Level Management Workbook OLA Support Hours (reflected in parent SLA)
Consider marginally longer support hours (if less than 24)
OLA Out of Hours support procedure (reflected in parent SLA)
Are the in hours support staff the same as out of hours. Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?
OLA Charging policy (reflected in parent SLA)
Do we require staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?
OLA Metrics for performance (reflected in parent SLA)
What will be the performance numbers for the work performed under this OLA? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?
OLA Cross references
Reference number to other closely coupled OLAs
UC Cross references
Reference number to any closely coupled agreements with external suppliers
OLA Validity period
Duration that this OLA is expected to remain Page 540
Service Level Management Workbook in place before it is reviewed.
OLA Review Procedure
The process for reviewing the OLA and who is involved. Special Tip: Avoid using people‘s names and use role descriptions to avoid dating the document.
Version Control Information
OLA Creation Date OLA Last Modify Date
Notes & Comments
(Duplicate the above table for the number of OLAs to be created)
Service Level Requirements
IT Services Service Level Requirements Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Service Level Requirements (SLR)
Page 541
Service Level Management Workbook The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR ESTABLISHING THE NEEDS OF CUSTOMERS WITH REGARD TO IT SERVICES. This document provides a basis for completion within your own organization. The document is made up of 3 sections. The first section allows you to briefly describe the service. The second section is where you capture user specific requirements (duplicate this section the number of times required). The third section allows you to cross reference the requirements uncovered in this study with other agreements/documents that may already exist. This document was; Prepared by: On:
<>
(The following form can be used as an SLR interview or data gathering document. And accepted by:
The SLR document does not have to be in a lengthy written format and in fact it is On: likely to be adopted <> more if it is kept concise, with only salient details) With regard to understanding SERVICE LEVEL REQUIREMENTS (SLR‘s) the following points should be addressed:
Service Information
Areas to address
Comments/Examples
Unique SLR Reference #
Useful to cross reference to related Service Level Agreements, OLAs or Underpinning Contracts
Related SLA Reference #
For cross referencing to the created Service Level Agreement (filled in after the SLA is created).
Time Frame/Notes/Who
Service Name Preferably use a name that is common language in the organization (not a technical Page 542
Service Level Management Workbook name).
Service Description (Business) (refer to end of table for technical considerations)
Briefly describe the primary function of the service. Use language that is business user friendly. (eg. instead of ―NT Server, with 2Gb RAM and 500Gb of disk storage‖ – we would say ―large central server designed for all customers to use and share information‖)
Customer Information (Duplicate the following table for as many services to be covered in this SLR).
Areas to address
Comments/Examples
Customer Definition and date of discussion
Whether the customer is an; Individual Individual representing a group of users A group meeting to discuss service requirements. It should be documented here. The date is an important consideration as requirements will definitely change over time. You can use this form or the SLA that will be derived from it as a starting point for the next review.
Customer Expectations
This is a unique concept to this SLA design template. Far too often we write descriptions of IT Services in a clinical fashion. These clinical descriptions set an expectation for the customer/end-user about the IT Service. Quite often the description is interpreted by
Time Frame/Notes/Who
Page 543
Service Level Management Workbook the reader in a way not intended by the writer. Use this section to set the expectations of the reader. If you feel that there could be some interruptions to service delivery, because the service is relatively new, then document that here. However, remember that using the reason ―new service‖ has only a limited life-span.
Service Security Considerations
Briefly list any considerations regarding security considerations that the representative has for this service. Should there be differences in the level of accessibility for different people/roles for this service? (try to use role descriptions – instead of names). Be careful of using generic terms like ―confidential‖. Confidential can be interpreted different ways (eg. Confidential to the individual or for the functional group or for a peer group).
Service Target Response priorities
What sort of priority levels of support need to be in place for this service? Are there categories of end user for the service that require differing levels of support? (Eg. Group A requires phone support only, Group B needs face-to-face support)
Service Target Response time
Against the levels/priorities defined are there corresponding response times Page 544
Service Level Management Workbook for the different priorities? (Eg. Group A needs immediate response, Group B needs a 2 hour response)
Service Support Hours (Availability)
Service Out of Hours support procedure
What are the REALISTIC support hours required for this service? Impress upon the representatives understand that IT staff also have day jobs and do not automatically start work, after they have gone home!! Get numbers: What is the maximum number of accepted outages, in a given time period? What would be an acceptable number of errors or reruns? Is after hours support required? To what degree is the support needed (full support, partial, best effort)?
Service Charging policy
Does the representative have any expectation regarding charges for Service Delivery? Be careful with this question as it may create some defensive reaction from the representative (what do you mean I have to pay for the service? I never have in the past!!) The question of charging is generally a more strategic decision made by business managers. How is charging to be implemented? (eg. Per user, per transaction) What is the customer budget with regard to this service?
Service Metrics for performance
Can the representative help you to define metrics for this service? Page 545
Service Level Management Workbook Does the representative have a way that they classify the service? (that we may have missed – as our focus tends to be more on technical issues)
Service Breach Clause
Does the representative have any thoughts regarding penalties that should be imposed if the service cannot be delivered according to agreed expectations? (Realistic!)
Continuity Considerations
Does the representative have any expectations regarding how the service should be recovered in the event of an extended outage? Do they require immediate recovery, or can they work in a paper based mode for a period of time? Can the customer accept any loss of data? If yes, what is the roll back point (eg. 2 hours, 1 day, 1 week)?
Non-representative Information (Duplicate the following table for the number of services that data is being gathered on).
Areas to address
Comments/Examples
SLA Cross Reference
Make a reference to any existing SLAs that may be able to be adapted or modified to meet this requirement.
Technical considerations
In this section you can describe any technical
Time Frame/Notes/Who
Page 546
Service Level Management Workbook considerations that are essential to document. It is more likely however, that you will include here a link to the Service Catalog or Technical Specification. You can use this section as a check that the service is in fact documented in the Service Catalog.
Notes & Comments
NOTE: THERE CAN BE NO SINGLE CORRECT DEFINITION OF A DATA GATHERING EXERCISE FOR IT SERVICE DELIVERY REQUIREMENTS THAT WILL COVER ALL SITUATIONS FOR ALL ORGANIZATIONS. THIS TEMPLATE HOWEVER, DOES PROMPT THE READER TO CONSIDER THE MOST CRITICAL AREAS OF DATA GATHERING and IT PROVOKES THOUGHT ABOUT OTHER AREAS THAT COULD BE INCLUDED BASED ON INDIVIDUAL NEEDS. (Duplicate the above table for the number of Services that requirements are to be gathered for)
Service Options
IT Services Process: Service Level Management Service Options Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Page 547
Service Level Management Workbook
Release Date:
Document Control Author Prepared by Document Source This document is located on the LAN under the path: I:/IT Services/Service Delivery/Service Level Management/Service Options Document Approval This document has been approved for use by the following: , IT Services Manager , IT Service Delivery Manager , National IT Help Desk Manager Amendment History Issue
Date
Amendments
Completed By
Distribution List
When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: Business Unit
Stakeholders
IT Introduction Purpose The purpose of this document is to provide the IT Organization with a breakdown of options for the Services listed in the Service Catalog Scope This document describes the following:
Service Options Page 548
Service Level Management Workbook
<>
Audience This document is relevant to all staff in Ownership IT Services has ownership of this document. Related Documentation Include in this section any related Service Level Management reference numbers and other associated documentation:
Implementation Plan / Project Plan
Policies, Guidelines and Scope Document
SLM Process Template
Service Catalogue
Executive Overview Note: The intent of this document is to provide a simple break down of options available for IT Services. This document is to be used in conjunction with Service Catalogue. Service Level Management Overview Summarize the organization definition for crucial Service Level Management components here. The definition of an SLA is: << insert your company’s definition here >> The definition of an OLA is: << insert your company’s definition here >> The definition of a UC is: << insert your company’s definition here >> The definition of a service is: << insert your company’s definition here >> Service Options The following table breaks down each service and the available options. This is a template and is used to illustrate for the user of this document the available options and structure to use when creating service options. Page 549
Service Level Management Workbook
The below table should be created for each individual service offered in the Service Catalogue.
IT Service:
Business Process:
IT Owner:
Business Owner:
Service Criticality:
Business Process Criticality:
Service Components
Service Options Platinum
Gold
Silver
Bronze
Default
Availability Capacity Response SLA Recovery SLA Service Hours Recovery Options Security Pricing
Appendices Include any applicable appendixes that are needed. Terminology Make sure that all terminology is captured and documented correctly. Page 550
Service Level Management Workbook
Underpinning Contracts
IT Services Underpinning Contracts Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Underpinning Contract (UC) The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR THE CREATION OF AN AGREEMENT BETWEEN THE SERVICE LEVEL MANAGEMENT PROCESS OWNER AND AN EXTERNAL PROVIDER (THIRD PARTY) OF IT SERVICES. This document provides a basis for completion within your own organization. There is a common misconception that the Service Level Management Process owner must be a member of the IT Department. This is not the case and quite often the best person for the role is someone with no bias towards IT. For example, a Human Resource Manager would do well in a role that has such a high degree of communication required.
Page 551
Service Level Management Workbook
(The following form can be used as the UC document. The UC does not have to be in a lengthy written format and in fact it is more likely to be adopted if it is kept concise, with only salient details) With regard to UNDERPINNING CONTRACTS (UCs) the following points should be addressed:
Areas to address
Comments/Examples
Link to parent Service Level Agreement
Cross reference to the ―parent‖ SLA.
Description of Service
Brief description (should be taken from SLA)
UC Reference number
Unique identifying number for the UC (for inclusion in the Configuration Management Data Base – CMDB)
UC Owner
Functional role description of who is responsible for this UC (who would participate in a review of this document?) (Special tip: Avoid using names as it dates the document quickly)
UC Parties involved
Within the external provider there may be different functional parties involved. List them here with a brief description of their involvement.
UC Target Response priorities (reflected in parent SLA)
If the UC accommodates different priorities they
Time Frame/Notes/Who
Page 552
Service Level Management Workbook must be listed here, with a description of the type of service that each priority level should receive.
UC Target Response time (reflected in parent SLA)
Consider quicker response time to allow for delays
UC Support Hours (reflected in parent SLA)
Consider marginally longer support hours (if less than 24)
UC Out of Hours support procedure (reflected in parent SLA)
Are the in hours support staff the same as out of hours? Phone numbers and what information will be required when support is called. What does the user do if the nominated person is not available?
UC Charging policy (reflected in parent SLA)
Do we require external staff to only act if they have a validated cost code for work? Are there any special aspects of the work that has to be recorded for later charging?
UC Metrics for performance (reflected in parent SLA)
What will be the performance numbers for the work performed under this UC? Will the expected performance be higher than negotiated in the SLA to allow a safety margin?
UC Cross references
Reference number to other closely coupled UCs Page 553
Service Level Management Workbook
OLA Cross references
Reference number to any closely coupled agreements with internal IT department
UC Validity period
Duration that this UC is expected to remain in place before it is reviewed.
UC Review Procedure
The process for reviewing the UC and who is involved. Special Tip: Avoid using people‘s names and use role descriptions to avoid dating the document.
Version Control Information
UC Creation Date UC Last Modify Date
Notes & Comments
(Duplicate the above table for the number of UCs to be created)
Functional Specification
IT Services Functional Specification Process: Service Level Management Service: <service name> Page 554
Service Level Management Workbook
Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Document Control Author Prepared by <> Document Source This document is located on the LAN under the path: I:/IT Services/Service Delivery/Functional Specifications/ Document Approval This document has been approved for use by the following:
<>, IT Services Manager
<>, IT Service Delivery Manager
<>, National IT Help Desk Manager
Amendment History Issue
Date
Amendments
Completed By
Distribution List When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: <> Business Unit
Stakeholders
IT
Introduction Page 555
Service Level Management Workbook
Purpose The purpose of this document is to provide relevant Business Units with the functional specifications of the range of services provided by IT Services to the <> community. Scope This document describes the following: details of each service provided by IT Services including:
description of service
functional capabilities of the service
user characteristics
user operations and practices
software and hardware interfaces
service contacts
details of procedures for the service
Note: It is assumed for each service described in this document that the supporting back-end technology is already in place and operational. Audience This document is relevant to all staff in <> Ownership IT Services has ownership of this document. Related Documentation Include in this section any related Service Level Agreement reference numbers and other associated documentation:
Relevant SLA and procedural documents
Relevant IT Services Catalogue
Relevant Technical Specification documentation
Relevant User Guides and Procedures
Executive Overview Describe the purpose, scope and organization of the Functional Specification document.
Service Overview Service Description Page 556
Service Level Management Workbook
Describes briefly the reason for the service, and lists the most important features and capabilities. Also include the services relationship to the business processes. Service functional capabilities This section presents a list of the functions that the service will be required to perform. Where the service comprises of several functional capabilities, a table may be developed to illustrate these relationships. The list of functional capabilities may be an updated version of the capabilities listed in the original ―Service Level Requirements‖ for this service. (Refer to Service Level Requirements) User characteristics This section describes the intended users of the service in terms of job function, specialized knowledge, or skill levels required. This section should consider various user classes or profiles such as managers, engineers, equipment operators, IT support staff, and network or database administrators. User operations and practices Describes how persons will normally use the service, and the tasks they will most frequently perform. Also covers how users might use the service on an occasional basis. Consider using a formal ―Use Case‖ to specify the end-users' expected use of the service. This may also be derived from the Service Level Requirements. General constraints This section will list the limitations, user interface limitations, and data limitations of the service. Includes items such as minimum availability, capacity, security needed by the service to function. It should also include maintenance requirements; more specifically the amount of time and frequency the service will be unavailable due to maintenance and service. Also, states if training is required for use of the system. Assumptions This section lists any assumptions that were made in specifying the functional requirements of this service. Page 557
Service Level Management Workbook
Other services How does the service interact with other services? Specific Function Descriptions This section is repeated for each function of the service. Some examples of functions are: email sending or receiving, sorting or archiving email, virus checking and scanning of email, and recovery of email services. Description The description describes the function and its role in the service. Inputs Describe the inputs to the function. Input validation strategy, allowed email types and values are specified for each input. Processing Describes what is done by the function. Cited here would be database definitions where relevant, transaction algorithms or functions, flow of information etc. Outputs This section describes the outputs of the function. Where a user interface description is relevant, it is included. Reports generated are also defined. External Interfaces The interfaces in this section are specified by documenting: the name and description of each item, source or input, destination or output, ranges, accuracy and tolerances, units of measure, timing, display formats and organization, availability and capacity requirements and any relevant agreements that may impact on the service. User Interfaces Where necessary. This section describes all major forms, screens, or web pages, including any complex dialog boxes. This is usually best done via simulated, non-functioning screen shots (such as PowerPoint slides), and may take the form of a separate document.
The navigation flow of the windows, menus, and options is described, along with
Page 558
Service Level Management Workbook
the expected content of each window. Examples of items that could be included are screen resolutions, color scheme, primary font type and size. Discussion also includes how input validation will be done, and how the service will be protected from security issues. This section can be generic enough to describe simply the User Interfaces to the functions of the service. Examples of items here would be client interface available, web interface available, email interface available etc. Hardware Interfaces Describes the components needed to provide the service, and also other output or input devices such as printers or handheld devices. Software Interfaces This section describes any software that will be required in order for the service to operate fully. Includes any developed software or commercial applications that customers will be utilizing together with the planned service. Also describes any software that the service will interact with such as operating system platforms supported, file import and export, networking, automation, or scripting. This section will also specify whether the users must provide the interface software and any special licensing requirements. Communication Interfaces Describes how the service will communicate with itself (for multi-platform applications) or other software applications or hardware, including items such as networking, email, intranet, and Internet communications, PABX, IP telephony etc. Functional Design Constraints Any examples of constraints that will prevent or influence the ability of the system to deliver the expected functionality will be listed here.
Attributes Security Describes where necessary the technical security requirements for the service. For example, any password-protected access levels such as operator, engineer/modeller, manager, database administrator and which functionality will be accessible to each access level, firewall requirements and virus software. This section should also describe all physical, organizational and procedural security requirements for the service. Page 559
Service Level Management Workbook
Reliability, Availability, Maintainability This section describes requirement items such as days or weeks of continuous operation, strategy for data recovery, structuring of service for ease of future modification. Installation and Distribution This section describes the planned method for installation and distribution of releases for the service: done by the user independently, done by customer company internal IT services, done by an external contractor. The section should specify the handling of such items as data transfer from prior releases, the physical storage of hardware and software in conjunction with releases and the presence of software or hardware elements from prior releases. Usability It is important to describe items that will ensure the user-friendliness of the service. Examples include error messages that direct the user to a solution, user documentation, online help etc. Additional Requirements Describes other characteristics the service must have, that were not covered in the prior sections. Administration Includes any periodic updating or data management needed for the service.
User documentation: Describes the user documentation to be delivered in conjunction with the service, including both hard copy and online requirements.
Other requirements: Describes any other requirements not already covered above that need to be considered during the design of the service.
Technical Specification
IT Services Technical Specification Process: Service Level Management Page 560
Service Level Management Workbook
Service: <service name> Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Document Control Author Prepared by Document Source This document is located on the LAN under the path: I:/IT Services/Service Delivery/Technical Specifications/ Document Approval This document has been approved for use by the following:
, IT Services Manager
, IT Service Delivery Manager
, National IT Help Desk Manager
Amendment History Issue
Date
Amendments
Completed By
Distribution List When this procedure is updated the following copyholders must be advised through email that an updated copy is available on the intranet site: <> Business Unit
Stakeholders
IT Page 561
Service Level Management Workbook
Introduction Purpose The purpose of this document is to provide relevant IT Units with the technical specifications for the range of services provided by IT Services to the <> community. Scope This document describes the following: details of each service provided by IT Services including:
description of service
functional capabilities of the service
user characteristics
user operations and practices
software and hardware interfaces
service contacts
details of procedures for the service
Note: It is assumed for each service described in this document that the supporting functional awareness of the service is already known. Audience This document is relevant to IT staff in <> Ownership IT Services has ownership of this document. Related Documentation Include in this section any related Service Level Agreement reference numbers and other associated documentation:
Relevant SLA and procedural documents
Relevant IT Services Catalogue
Relevant Technical Specification documentation
Relevant User Guides and Procedures
Executive Overview Describe the purpose, scope and organization of the Technical Specification document. Page 562
Service Level Management Workbook
Service Overview Service Description Describes briefly the reason for the service, and lists the most important features and capabilities. Also include the services relationship to the business processes. Service technical capabilities This section presents a list of the technical aspects that the service will be required to perform. Where the service comprises of technical aspects, a table may be developed to illustrate these relationships. User characteristics This section describes the intended users of the service in terms of job function, specialized knowledge, or skill levels required. This section should consider various user classes or profiles such as managers, engineers, equipment operators, IT support staff, and network or database administrators. User operations and practices Describes how persons will normally use the service, and the tasks they will most frequently perform. Also covers how users might use the service on an occasional basis. Consider using a formal ―Use Case‖ to specify the end-users' expected use of the service. This may also be derived from the Service Level Requirements. Assumptions This section lists any assumptions that were made in specifying the technical requirements of this service. Other services How does the service technically interact with other services? Specific Technical Descriptions This section is repeated for each technical aspect of the service. Some examples of technical aspects are: Processing, Backup, Archive, Restores. Description The description describes the Technical aspect and its role in the service. Inputs Page 563
Service Level Management Workbook
Describe the inputs to the aspect. Data feeds from other systems, human input or automated timed activities are examples of inputs. Processing Describes what is done. For example with regard to backups we would describe the database close, backup and database restart activities. Outputs This section describes the outputs. For example, if we are describing the archive activity we would expect to end up with a media storage device that would be stored in a secure location. Reports generated are also defined. Other technical considerations The interfaces in this section are specified by documenting: the name and description of each item, source or input, destination or output, ranges, accuracy and tolerances, units of measure, timing, display formats and organization, availability and capacity requirements and any relevant agreements that may impact on the service. Hardware details Describes the technical components needed to provide the service, and also other output or input devices such as printers or handheld devices. Software details Describes the technical aspects of the software used to provide the service (eg. client server details), operating system levels, backup software used, virus protection details, other supporting services and applications that contribute to the service availability. Communication details Describes how the service will communicate with itself (for multi-platform applications) or other software applications or hardware, including items such as networking, email, intranet, and Internet communications, PABX, IP telephony etc. Performance Discusses items such as response times, throughput requirements, data volume requirements, maximum data file size or problem complexity, maximum number of concurrent uses, and peak load requirements (for web-based applications). Includes expected response times for entering information, querying data files and Page 564
Service Level Management Workbook
databases, performing calculations of various complexities, and importing/exporting data. Technical Design Constraints Examples of technical constraints that affect service design choices are items such as memory constraints involving minimum and maximum RAM and hard disk space, and limitations arising from hardware, software or communications standards. Additional Requirements Describes other characteristics the service must have, that were not covered in the prior sections. Administration Includes any periodic updating or data management needed for the service.
User documentation: Describes the user documentation to be delivered in conjunction with the service, including both hard copy and online requirements.
Other requirements: Describes any other requirements not already covered above that need to be considered during the design of the service.
Price List
IT Services Price List Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Page 565
Service Level Management Workbook
Price List Considerations for Service Level Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR DETERMINING THE PRICE OF IT SERVICE DELIVERY TO CUSTOMERS. This document provides a basis for completion within your own organization. This document can be read in conjunction with: Service Catalogue (which is where summary pricing information is presented).
This document was; There are three considerations to review when looking to establish the prices for IT Prepared by: Services that are delivered. It is the combination of these areas that will help the Service On: Manager (along with<> Level the process owner for Financial Management for IT Services) setAnd andaccepted negotiateby: pricing for IT Service delivery. These considerations are: On: <> 1) The degree of IT costs that are expected to be recovered. Such a decision will generally come from a business policy regarding cost recovery for other shared services. For example if Human Resources aim to recover all costs from the departments or user groups it supports, it is likely that this will also apply to IT. 2) The degree that IT wants to change consumption patterns of Customers and Users There is no surer thing. Once services start to cost, then behaviours will change and demand will decrease. Of course, the major challenge of looking to use pricing to influence (drive down) consumption is the major resistance that can be expected. 3) Budget influence Careful and well articulated pricing for IT Services allows better predictions regarding the expected budget required for a future time period. This positive influence helps to reduce the number of unexpected surprises that can often happen, when budget funds cannot support requirements. Use the following table with examples to help determine which IT Services will be charged for in your organization and the basis upon which you will levy that charge. Page 566
Service Level Management Workbook Chargeable Item (examples)
Ancillary Services
Cost basis
Sales transaction
Network connection Personal Computer File server processing
Simple cost per transaction, or; Cost per speed of processing, or; Cost per size of transaction
E-mail sent
Network connection to mail server Personal Computer Internet connection
Per unit, or; Stored limit, or; Mail items in the ―in-box‖
An important point to consider regarding the pricing of services is the case when a customer claims that they can buy the service cheaper from an external provider. While this may be the case, the overall impact on the organization may be negative – so it may be necessary to impose restrictions regarding purchase of external services when suitable internal services are available. Once the pricing differential is identified a controlled process of (a) reducing costs or (b) outsourcing to an external provider can be carried out. The final point to consider regarding the price of IT Services is whether actual funds transfer will take place or if charges are just imaginary (or ―nominal‖). Nominal charging allows customers to see the costs of the IT Services they consume, but they are not expected to transfer funds from their cost centres to the IT department. This method can have a low impact; in that without transferring funds, the affect on behaviour may be negligible.
Communication Plan
IT Services Communication Plan Process: Service Level Management Status:
In draft
Page 567
Service Level Management Workbook Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Communication Plan for Service Level Management The document is not to be considered an extensive statement as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE FOR COMMUNICATIONS REQUIRED for the Service Level Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding information to share with others. The document is deliberately concise and broken into communication modules. This will allow the reader to pick and choose information for e-mails, flyers, etc. from one or more modules if and when appropriate.
Initial Communication
Page 568
Service Level Management Workbook
Sell the Benefits First steps in communication require the need to answer the question that most people (quite rightly) ask when the IT department suggests a new system, a new way of working. WHY? It is here that we need to promote and sell the benefits. However, be cautious of using generic words. Cite specific examples from your own organization that the reader will be able to relate to. Generic Benefit statements
Specific Organizational example
CM provides accurate information on our IT components.
This is important because…
Allows us to more carefully control the valuable IT infrastructure.
In recent times our control on IT has…
Helps us to more effectively manage our expenditure on IT.
Apart from the obvious benefits, the IT department in recent times has…
Assists with protecting against illegal or unauthorized software.
A recent example of … saw the individual and the company face severe penalties.
The above Communication module (or elements of) was/were distributed; To:
Service Level Management Goals On: <> By: On:
<>
Page 569
Service Level Management Workbook
The Goals of Service Level Management The Goals of Service Level Management can be promoted in the following manner. Official Goal Statement: Through a process of continual negotiation, discussion, monitoring and reporting the Service Level Management process aims to ensure the delivery of IT Services that meet the requirements and expectations of our customers and end-users.
Seek agreement on expected delivery of IT service by gaining an understanding of the Service Level Requirements from nominated personnel
(Special Tip: Beware of using only Managers to gain information from, as the resistance factor will be high)
Oversee the monitoring of service delivery to ensure that the negotiations regarding the service requirements are not ignored and treated as a once off exercise.
Provide relevant reports to nominated personnel.
(Special Tip: Beware of reporting only to Managers. If you speak to a lot of people regarding Service Delivery then you need to establish ways to report to these people the outcomes and progress of the discussions). Always bear in mind the ―so what‖ factor when discussing areas like goals and objectives. If you cannot honestly and sensibly answer the question ―so what‖ – then you are not selling the message in a way that is personal to the listener and gets their ―buy-in‖. The above Service Level Management Goals module was distributed; To: On: Service
<>
By: On: <> Service Level Management Activities
Page 570
Service Level Management Workbook Intrusive & Hidden Activities
The list of actions in this module may have a direct impact on end users. They will be curious as to why staff have a sudden interest in trying to develop an understanding regarding what they need from IT. There could be an element of suspicion, so consider different strategies to overcome this initial scepticism. Identification Analysing current services and Service Level Requirements Recording the current service provision in a Service Catalogue. Definition Matching & customising (with the customer) of the right service provision against the right costs: Service Catalogue Demands of the customer (Service Level Requirements). Agreement (Defining and signing SLA/s) Service Level Agreements, supported by: Operational Level Agreements (OLAs) and Underpinning Contracts Monitoring Measuring the actual service levels against the agreed service levels Reporting Reporting on the service provision (to the customer and the IT organisation) Evaluation (review) Evaluate the service provision with the customer Match & customise: adjust service provision if required? (SIP, SQP) Match & customise: adjust SLA if required? Information regarding activities was distributed; To: Service Level Management Deliverable On:
<>
By: On:
<>
Page 571
Service Level Management Workbook
Outputs of the Process There are a variety of output documents that should be visible to the customer and end-user. Outlining these will allow the use of common terms – which enhances the overall communication process. SLR = Service Level Requirements Detailed recording of the customers‘ needs Blueprint for defining, adapting and revising of services Service Spec Sheets = Service Specifications Connection between functionality (externally / customer focussed) and technicalities (internally / IT organisation focussed) Service Catalogue Detailed survey of available services Detailed survey of available service levels Derived from the Service Spec Sheets, but written in ―customer terminology‖ SLA = Service Level Agreement The written agreement between the provider and the customer (business representative) Service Level Achievements = the Service Levels that are realised SIP = Service Improvement Programme / Plan Actions, phases and delivery dates for improvement of a service OLA = Operational Level Agreement (or SPA, Service Provisioning Agreement) A written agreement with another internal IT department to support the SLA UC = Underpinning Contract (=a written agreement with an external IT supplier)
Service Level Planning deliverables was distributed; News about theManagement Service Level Management To: On:
<>
By: On:
<>
Page 572
Service Level Management Workbook
Costs Information relating to costs may be a topic that would be held back from general communication. Failure to convince people of the benefits will mean total rejection of associated costs. If required, costs fall under several categories:
Personnel – audit verification staff, database management team (Set-up and ongoing) Accommodation – Physical location (Set-up and ongoing) Software – Tools (Set-up and ongoing) Hardware – Infrastructure (Set-up) Education – Training (Set-up and ongoing) Procedures – external consultants etc. (Set-up)
The costs of implementing Service Level Management will be outweighed by the benefits. For example, many organizations have a negative perception of the function of the IT Department. A well run Service Level Management process will make major inroads into altering that perception. Failure to deliver acceptable services will only add to any poor perceptions and start business people questioning the value of IT.
Details regarding the cost of Service Level management were distributed; To: On:
<>
By: On:
<>
Page 573
Service Level Management Workbook
Reports KPI’s Other Metrics
IT Services Reports and KPI Targets Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Note: SEARCH AND REPLACE
Reports and KPI Targets for Servicename>> Level Management <> as your input will be required generic enough to suit any reader for any organization. Also review any yellow highlighted text However, the reader will certainly be reminded of the key topics that have to be considered. This document serves as a GUIDE ON SUITABLE KEY PERFORMANCE INDICATORS (KPIs) and REPORTS FOR MANAGEMENT for the Service Level Management process. This document provides a basis for completion within your own organization. This document contains suggestions regarding the measures that would be meaningful for this process. The metrics demonstrated are intended to show the reader the range of metrics that can be used. The message must also be clear that technology metrics must be heavily supplemented with nontechnical and business focused metrics/KPI’s/measures. This document was; Prepared by: On:
<> Page 574
And accepted by: On:
<>
Service Level Management Workbook
Key performance indicators (KPI’s) Continuous improvement requires that each process needs to have a plan about ―how‖ and ―when‖ to measure its own performance. While there can be no set guidelines presented for the timing/when of these reviews; the ―how‖ question can be answered with metrics and measurements. With regard to timing of reviews then factors such as resource availability, cost and ―nuisance factor‖ need to be accounted for. Many initiatives begin with good intentions to do regular reviews, but these fall away very rapidly. This is why the process owner must have the conviction to follow through on assessments and meetings and reviews, etc. If the process manager feels that reviews are too seldom or too often then the schedule should be changed to reflect that. Establishing SMART targets is a key part of good process management. SMART is an acronym for:
Simple Measurable Achievable Realistic Time Driven Metrics help to ensure that the process in question is running effectively. With regard to SERVICE LEVEL MANAGEMENT the following metrics and associated targets should be considered: Key Performance Indicator
The percentage of Underpinning contracts and OLAs in place that are supporting Service Level Agreements.
Target Value (some examples)
Time Frame/Notes/Who
Expressed as a percentage, it indicates that SLAs are more than just a document, but have been extended into related agreements with internal and external providers. Page 575
Service Level Management Workbook
Meetings held (on time) to review performance
A reducing number here may be a good indication or at least the number should be stable.
Costs of Service Delivery decreasing.
The percentage of targets relating to Service delivery being met.
The number of Service breaches recorded
Improvements in salient points from Customer feedback forms
Others
Special Tip: Beware of using percentages in too many cases. It may even be better to use absolute values when the potential number of maximum failures is less than 100
Page 576
Service Level Management Workbook
Reports for Management Management reports help identify future trends and allow review of the ―health‖ of the process. Setting a security level on certain reports may be appropriate as well as categorizing the report as Strategic, Operational or Tactical. The acid test for a relevant report is to have a sound answer to the question; ―What decisions is this report helping management to make?‖ Management reports for Service Level Management should include:
Report
Time Frame/Notes/Who
Expected growth in demand for the service (will generally be high at start-up, but then plateau)
Serious Service breaches and remedy steps taken
Backlog details of process activities outstanding (along with potential negative impact regarding failure to complete the work in a timely manner) – but also provide solutions on how the backlog can be cleared.
Simple breakdown of new SLA/OLA/UCs created, simple notes on reviews of same completed.
Analysis and results of meetings completed
The situation regarding the process staffing levels and any suggestions regarding redistribution, recruitment and training required.
Human resource reporting including hours worked against project/activity (including weekend/after hours work).
Relevant Financial information– to be provided in conjunction with Financial Management for IT Services
SLM IMPLEMENTATION & PROJECT PLAN Page 577
Service Level Management Workbook
IT Services Implementation Plan/Project Plan Skeleton Outline Process: Service Level Management Status:
In draft Under Review Sent for Approval Approved Rejected
Version:
<>
Release Date:
Planning and implementation for Service Level Management This document as described provides guidance for the planning and implementation of the Service Level Management ITIL process. The document is not to be considered an extensive plan as its topics have to be generic enough to suit any reader for any organization. However, the reader will certainly be reminded of the key topics that have to be considered for planning and implementation of this process.
Initial planning When beginning the process planning the following items must be completed: CHECK or or date
DESCRIPTION
Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (eg. Internal, outsourced, hybrid) for the process. Assign a person to the key role of process manager/owner. This person is responsible for the process and all associated systems.
Page 578
Service Level Management Workbook
Conduct a review of activities that would currently be considered as an activity associated with this process. Make notes and discuss the ―re-usability‖ of that activity. Create and gain agreement on a high-level process plan and a design for any associated process systems. NOTE: the plan need not be detailed. Too many initiatives get caught up in too much detail in the planning phase. KEEP THE MOMENTUM GOING. Review the finances required for the process as a whole and any associated systems (expenditure including people, software, hardware, accommodation). Don‘t forget that the initial expenditure may be higher than the ongoing costs. Don‘t forget annual allowances for systems maintenance or customizations to systems by development staff. Agree to the policy regarding this process
Create Strategic statements Policy Statement The policy establishes the ―SENSE OF URGENCY‖ for the process. It helps us to think clearly about and agree on the reasons WHY effort is put into this process. An inability to answer this seemingly simple, but actually complex question is a major stepping stone towards successful implementation The most common mistake made is that reasons regarding IT are given as the WHY we should do this. Reasons like to make our IT department more efficient are far too generic and don‘t focus on the real issue behind why this process is needed. The statement must leave the reader in no doubt that the benefits of this process will be far reaching and contribute to the business in a clearly recognizable way. Objective Statement When you are describing the end or ultimate goal for a unit of activity that is about to be undertaken you are outlining the OBJECTIVE for that unit of activity. Of course the activity may be some actions for just you or a team of people. In either case, writing down the answer to WHERE will this activity lead me/us/the organization is a powerful exercise.
Page 579
Service Level Management Workbook
There are many studies that indicate the simple act of putting a statement about the end result expected onto a piece of paper, then continually referring to it, makes achieving that end result realistic. As a tip regarding the development of an objective statement; don‘t get caught up in spending hours on this. Do it quickly and go with your instincts or first thoughts – BUT THEN, wait a few days and review what you did for another short period of time and THEN commit to the outcome of the second review as your statement. Scope Statement In defining the scope of this process we are answering what activities and what ―information interfaces‖ does this process have. Don‘t get caught up in trying to be too detailed about the information flow into and out of this process. What is important is that others realize that information does in fact flow. For example, with regard to the SERVICE LEVEL MANAGEMENT process we can create a simple table such as: Service Level Management Information flows Process
Process
Information
SLMMgt
to
FinancialMgt
Customer budget details
FinancialMgt
to
SLMMgt
Expected ROI calculations for new service
ReleaseMgt
Details regarding mandatory times for service availability
SLMMgt
Expected impact (+ve or –ve) of release
ServiceDesk
Client expectations regarding call pick up times (eg. 2 rings)
SLMMgt
Details of irate callers
to SLMMgt to ReleaseMgt
to SLMMgt to ServiceDesk
Steps for Implementation
Page 580
Service Level Management Workbook There can be a variety of ways to implement this process. For a lot of organizations a staged implementation may be suitable. For others a ―big bang‖ implementation – due to absolute equality may be appropriate. In reality however, we usually look at implementation according to pre-defined priorities. Consider the following options and then apply a suitable model to your own organization or case study.
STEPS
NOTES/ /RELEVANCE/DATES/ WHO
Produce the Service Catalog
Plan the SLA Structure
Establish the Service Level Requirements
Draft SLA and seek initial approval
Establish monitoring levels
Review agreements with internal and external suppliers
Define reporting standards
Publicize and market
The priority selection has to be made with other factors in mind, such as competitive analysis, any legal requirements, and desires of ―politically powerful influencers‖.
Costs Page 581
Service Level Management Workbook The cost of process implementation is something that must be considered before, during and after the implementation initiative. The following points and table helps to frame these considerations: (A variety of symbols have been provided to help you indicate required expenditure, rising or falling expenditure, level of satisfaction regarding costs in a particular area, etc.)
Initial Personnel Costs of people for initial design of process, implementation and ongoing support Accommodation Costs of housing new staff and any associated new equipment and space for documents or process related concepts.
During
Ongoing
Software New tools required to support the process and/or the costs of migration from an existing tool or system to the new one. Maintenance costs Hardware New hardware required to support the process activities. IT hardware and even new desks for staff. Education Re-education of existing staff to learn new techniques and/or learn to operate new systems. Procedures Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel.
In most cases, costs for process implementation have to be budgeted for (or allocated) well in advance of expenditure. Part of this step involves deciding on a charging mechanism (if any) for the new services to be offered.
Build the team Page 582
Service Level Management Workbook
Each process requires a process owner and in most situations a team of people to assist. The Service Level Management process is perhaps the process in the Service Delivery set that has the largest amount of initial and on-going activity. The team size may or may not reflect this. Of course a lot will be dependant on the timing of the implementation and whether it is to be staged or implemented as one exercise. Analyze current situation and FLAG Naturally there are many organizations that have many existing procedures/processes and people in place that feel that the activities of SLM are already being done. It is critical to identify these systems and consider their future role as part of the new process definition. Examples of areas to review are:
Area
Notes
Power teams Current formal procedures Current informal procedures Current role descriptions Existing organizational structure Spreadsheets, databases and other repositories Other…
Implementation Planning After base decisions regarding the scope of the process and the overall planning activities are complete we need to address the actual implementation of the process. It is unlikely that there will not be some current activity or work being performed that would fit under the banner of this process. However, we can provide a comprehensive checklist of points that must be reviewed and done. Implementation activities for Service Level Management
Activity
Notes/Comments/T Page 583
Service Level Management Workbook ime Frame/Who
Review current and existing Service Level Management practices in greater detail. Make sure you also review current process connections from these practices to other areas of IT Service Delivery.
Review the ability of existing functions and staff. Can we ―reuse‖ some of the skills to minimize training, education and time required for implementation?
Establish the accuracy and relevance of current processes, procedures and meetings. As part of this step if any information is credible document the transition from the current format to any new format that is selected.
Decide how best to select any vendor that will provide assistance in this process area (including tools, external consultancy or assistance to help with initial high workload during process implementation).
Establish a selection guideline for the evaluation and selection of tools required to support this process area (i.e. SLA Management tools).
Purchase and install tools required to support this process (i.e. SLA Management tool). Ensure adequate skills transfer and on-going support is considered if external systems are selected.
Page 584
Service Level Management Workbook
Create any required business processes interfaces for this process that can be provided by the automated tools (eg. reporting – frequency, content).
Document and get agreement on roles, responsibilities and training plans.
Communicate with and provide necessary education and training for staff that covers the actual importance of the process and the intricacies of the process itself.
An important point to remember is that if this process is to be implemented at the same time as other processes that it is crucial that both implementation plans and importantly timing of work is complementary.
Cutover to new processes The question of when a new process actually starts is one that is not easy to answer. Most process activity evolves without rigid starting dates and this is what we mean when we answer a question with ―that‘s just the way it‘s done around here‖. Ultimately we do want the new process to become the way things are done around here, so it may even be best not to set specific launch dates, as this will set the expectation that from the given date all issues relating to the process will disappear (not a realistic expectation).
FURTHER INFORMATION For more information on other products available from The Art of Service, you can visit our website: http://www.theartofservice.com If you found this guide helpful, you can find more publications from The Art of Service at: http://www.amazon.com
Page 585
Service Level Management Workbook INDEX* A ability 13, 16, 24, 29, 52, 75-6, 87-9, 91, 95-103, 110, 132, 155, 334, 504-5, 507-8, 536 [15] acceptance 91, 97, 141, 346-7, 423-4 access 21, 48, 56, 60, 84, 109-10, 149, 259, 294, 297, 339-40, 348, 369-70, 409-10, 415-16, 425 [5] accommodation 98, 172, 175, 372, 375, 445, 450, 579, 582 accountability 16, 35, 196, 393 accounts 75, 290-1, 497 Accounts Department 290-1 ACME 106-8, 111 ACME CUSTOMER SERVICE PLAN 2 activities common operation 48 customer's business 29 documents past 340, 416 incident management 154, 176, 301 support business 29 unit of 173, 373, 446, 579 activity/event 533 activity type 149-50 ADA (American with Disabilities Act) 97-8 Adequate Supporting Material 343, 420 administration time 509, 515, 521 Advancement 1-2, 72, 75 agents 22, 74-5, 344, 347-8, 421, 425 agreement 171-2, 177, 337-42, 344-9, 371-2, 377, 412-24, 426-7, 444-5, 464, 467, 505-6, 509, 521, 570-1, 578-9 [11] written 349, 426, 465, 572 agreements/documents 542 alerts 364, 402-3 American with Disabilities Act (ADA) 97-8 analysis trend 24, 133, 155, 265-6, 269, 280 workload 229 Analyzing Business Justification Document 3 Analyzing SAMPLE CUSTOMER SERVICE 92 Analyzing Service Level Requirements 13 announcement 102-3, 105 answer 70-1, 74, 89-91, 99-100, 137-8, 153-4, 172-3, 177, 328-30, 351-2, 372-3, 378-9, 4312, 441-3, 446, 491-3 [11] answering 71, 89, 137-8, 173, 328-30, 373, 441-3, 446, 491-3, 580 APMG 181 Appendix Sample Customer Service Plan 2, 106 applicants 91, 95, 97-8, 100, 102-3, 105 Application Development 40 Application Management 40 applications 9, 21, 40-1, 66, 91, 99, 103-5, 111, 163, 263, 292, 297, 299, 342, 365-6, 404-5 [2] impressive 104 Approval Approved Rejected 130, 133, 136, 139, 152, 161, 169, 171, 324, 327, 330, 333, 337, 354, 358, 371 [23] arbitration 349, 427 area network 293 Art of Service 178, 182, 308, 585 ask 84, 89-91, 95-100, 103-4, 153, 304, 320, 351, 353, 431, 433, 569 assessments 13, 19, 67, 104-5, 112, 157, 170, 190, 305, 355, 458, 575 assets 29-30, 33-4, 40, 101, 167 assignment 3, 22, 92, 284-5, 349, 427, 502 assistance 74, 87, 93, 98, 103, 131, 177, 295, 300, 325-6, 377, 428, 452, 455-6, 584 associated systems 171-2, 372, 445, 578-9 assumptions 557, 563
Page 586
Service Level Management Workbook atmosphere 92-3 audience, intended 137-8, 328-30, 441-3, 491-3 audits 23, 46, 142, 144, 146, 268 authority, taxing 344, 421 Auto Populated 166-8 availability 15, 20, 22, 35, 56, 78, 366, 405, 432-3, 468-9, 489, 496-7, 513, 518, 524, 534-5 [13] Availability and Information Security management 199, 383 Availability Management 27, 174, 366, 374, 405, 484 B background 2, 91, 95, 99, 105-6, 489 backup 67, 142, 146, 316, 563-4 bake 195 BCM (Business Capacity Management) 64 Behavioral Event Inventory (BEI) 96-7 behaviors 86-9 behaviour 83-4, 470, 566-7 BEI (Behavioral Event Inventory) 96-7 benchmark 62, 64, 111 benchmarking 64, 109 benefits 5-6, 8, 16-19, 23-4, 26-8, 63-4, 79-80, 153, 156, 284-6, 299, 323, 351, 353, 385-7, 569 [32] Best Customer Service Representatives 2, 85 Beware 154, 352, 432, 570 BIA 12, 100, 538, 551 billing 75, 143-4, 151 book 5-9, 67-8, 89, 112-13, 291 best customer service 68 box 7, 163-6 business 12, 14, 16-19, 23-5, 27-39, 42-4, 52-6, 61-3, 69-72, 80-2, 185-7, 335-6, 461-5, 4756, 529-31, 536 [71] real 327, 457 business areas 160, 529 business benefits 15, 18, 63, 131, 137, 223, 325, 328, 441, 455, 475, 491 Business Capacity Management (BCM) 64 business case 130, 324, 454, 498 formal 113, 309, 380, 459 business criticality 165, 531 business Customer 507 business days 338, 345, 414, 422-3 business days of receipt 346, 423 business departments 194 business drivers 61, 66 Business Flyers 4, 434 business focus 190, 326, 457 Business Functions 12, 185 business goals 36, 332, 439 Business Impact Analysis 12, 42 business impacts 12, 33, 215 minimal 131, 321, 325, 455, 499 Business Justification 25, 130, 315, 324 Business Justification Document 3-4, 130, 324, 454, 459, 498 Business Justification Document for Service Desk 454 Business Justification Document for Service Level Management 498 Business Justification Function 324, 454 Business Justification Process 130, 498 business management 12, 366-7, 405-6 business managers 131, 302, 325, 359, 397, 455, 499, 545 business objectives 14, 35, 179, 293, 333, 486, 504, 529-30 high level 485 high-level 14
Page 587
Service Level Management Workbook business operations 304, 411 Business Operations Support Desk 322 business organization 284-5 Business Owner 496, 536, 550 business people 192, 362, 400, 500, 508 business person 131, 325, 455, 499 business priorities 321, 504 business processes 12, 26, 115, 184-5, 187-8, 219, 311-12, 368, 407, 475, 527-34, 536, 557, 563 new 529-30 Business Rating 536 business requirements 8, 13, 17, 35, 52, 461, 500 customer's 43 Business Service Catalogue 475 Business Service Catalogue and Technical Service Catalogue 15 Business Service Management 59 business support 207 business understanding 199, 319 Business Unit 139, 162, 467, 494, 527, 548, 555, 561 business units 530, 556 business user 394, 488, 511, 522, 543 business world 69, 81 C cake 195-6 calendars 103-4 call centers 74-5, 78-9, 199, 317, 319 candidate 76, 85-7, 89-91, 95-105 best 85, 92, 103, 105 qualified 105 candidate information 90 candidate pool 101-2 candidate services 32 candidate time 96 capabilities 10-11, 15, 26, 29, 32, 110, 388, 557, 563 functional 556-7, 562 service management 11 capacity 11, 15, 20, 22, 60, 100, 287, 367, 406, 468, 496, 529, 550, 557 CASE tools 40, 50 catalogue 6 certificate 103, 345, 422 challenges 11, 54, 132, 284-6 change management 27, 44-5, 135, 144, 173, 192, 210, 257, 262, 269, 277, 279, 364, 374, 402-3, 447 [6] integrated activity of 45 charge rates 367, 407 Chief Information Officer, see CIO CI (Configuration Item) 135, 158-9, 165, 198, 204, 235, 262, 268, 279, 302-3, 360-4, 368, 383, 398-402, 407, 411 CI form 364, 402 CIO (Chief Information Officer) 66, 284-6, 293, 333 CIs 50, 401-3 client 7, 22, 143-4, 147, 150 failure of 344, 420 indemnify 344, 421 limitation 345, 422 obligations of 340-1, 416-17 receipt of 347, 424 training of 346, 423 CLIENT Contract Administrator 340, 416 CLIENT employee 341, 417
Page 588
Service Level Management Workbook CLIENT Employee 341, 417 CLIENT for OUTSOURCER staff services 338, 414 CLIENT policies, applicable 348, 425 Client Policy and Procedures 348, 425 CLIENT Policy and Procedures 339, 414-15 CLIENT reserves 338, 414 CLIENT software programs 340, 416 Client's Contract Administrator 348, 426 closure 155, 241, 274, 300-1 CMDB (Configuration Management Database) 120, 158, 233, 235, 238, 256, 259, 301, 316, 330, 353, 362-4, 401-3, 443, 488, 510 [4] CMDB information 353, 433 CMS (Configuration Management system) 22, 42, 45, 49-50, 233 co-workers 93-5, 100, 103 coalition, guiding 25 Comments/Examples 488, 510-11, 516, 520, 522, 526, 538, 542-3, 546, 552 communication 14, 17, 24-5, 48, 52, 76, 78, 97, 107, 109-10, 153-6, 313-14, 350-3, 430-4, 505-6, 568-9 [18] formalized 52 Communication module 153, 350-1, 430-1, 568-9 communication plan 3-5, 24, 113, 152, 191, 326, 349-50, 429-30, 456, 459, 567 Communication Plan for Incident Management 152 Communication Plan for Service Level Management 568 Communication skills 100, 199, 319-20 communications plan 24 companies 5, 8, 10, 12, 27, 68-74, 76-7, 80-2, 85, 143-4, 147-8, 150, 287, 291, 293-4, 392 [6] company name 139-40, 162, 336, 548-9 company policies 74, 76, 83 competences 84, 504-5 competencies 86-91, 96-7, 104-5 personal/interpersonal 86 competitors 70, 77, 80-3, 131, 325, 455, 499 complaint requests 83 complaints 70, 72-6, 80, 83, 355, 471, 476, 506 compliments 471, 476 concepts, basic 36-9, 45-7, 53-5 conditions 56, 93, 110, 338, 349, 413-14, 426 Conducts reviews on Incidents and Service 169 Confidential Information 92, 341-2, 417-18 configuration information 135, 332, 438 Configuration Item, see CI Configuration Items 135, 158, 165, 302-3, 361, 363, 368, 399, 401, 407, 411 Configuration Management 27, 135, 233, 304, 332, 362-4, 366-7, 370, 401-2, 406-7, 438, 490 Configuration Management Database, see CMDB Configuration Management system, see CMS connection 342, 344, 418, 420 connection herewith 345, 422 consent 340-1, 416-17 prior written 340-1, 349, 416-17, 427 Considerations for Service Level Management 566 constraints 29-31, 557, 559 consultant 340-1, 417 contact 71, 73-5, 91, 99, 102-5, 109, 141, 164, 215, 221, 299, 301, 321, 351-2, 361-2, 399-400 [13] first point of 327, 329, 353, 433, 442, 457 Contact Name 164-5 Continual Service Improvement 4, 8, 11, 14, 24, 461, 479-81 Continual Service Improvement- Service Management 1, 60 continuity 10, 193, 368, 407 contract 11, 39, 143-4, 147, 150, 340-1, 389, 416-17, 466, 485, 505, 534-5 consulting 340-1, 416-17 facilities management 340-1, 416-17
Page 589
Service Level Management Workbook Contract Administrator 348, 426 control 8, 11, 18-20, 28, 37, 45, 56-7, 98, 101, 109, 169, 190, 334, 359, 397, 569 [4] conversations 74-5, 99, 107-8 corporation 68, 340-1, 417 cost benefits 284-6 cost information 364, 402 costs 11-12, 16, 21, 156-7, 175-6, 224, 338-9, 353-4, 375-6, 413-14, 429, 434, 449-50, 566-7, 573, 581-2 [36] customer relationships minus 81 Costs of Service Delivery 576 Costs of Service Support 355 courses 369, 409 Critical Success Factors, see CSFs Critical Success Factors and Risks 36-9, 53-6 CSFs (Critical Success Factors) 15, 43, 62, 184, 192, 299-300 CSI 1, 23-6, 61-6, 458-9, 483-5 business/customer benefits of 61 CSIP 189, 191-3 culminating 284-5 culture, organizational 32, 513, 518, 524 customer attitudes 84 Customer Based 459, 467, 508, 510 Customer Based Service Level Agreement 509 Customer Complaint Incident 148 customer complaints 93-4, 143, 148, 295, 357 Customer Compliment 143, 148 Customer Compliment Incident 148 customer contact 330, 443 customer/end-user 512, 517, 523, 543 customer experiences 82, 475 customer feedback 109, 111 Customer Focus 2, 80, 82-3, 85, 108, 190, 336 Customer Focus Approach 2, 84 Customer Focus Model 2, 83 customer groups 108, 110, 465, 467, 509 Customer Incident 229 customer market 391 customer organization 389, 391-2 customer perceptions 28, 207, 227 Customer Requested Delay 141 customer responsiveness 80-1 customer satisfaction 7, 68, 81-2, 299, 329, 331, 437, 442, 478 improving 352, 506 customer satisfaction ratings 118, 314 Customer Satisfaction Surveys 351, 353, 431, 433 customer service 1, 68-74, 76-7, 86-90, 92, 106, 109, 115, 155-6, 187, 312, 355, 505 flexible 70 high level of 69, 78 improving 106 strong 77 customer service experience 76 customer service initiatives 108 Customer Service Institute 70 customer service jobs 76-7 Customer Service Management 108, 111 customer service occupation 78 Customer Service Plan 106-8 customer service policy 68 customer service practice 96 customer service program 108
Page 590
Service Level Management Workbook customer service reasons 87 customer service representatives 73-9 full-time 79 salary 79 customer service representatives help people 73 customer service representatives interact 73, 80 customer service representatives work 75 customer service representatives work part time 75 Customer Service Skills 298 customer service standards 107 customer service training 85 customerCustomer staff and Service Desk 218 Customer Support Group 142 customers 10-14, 16-19, 28-34, 67-78, 80-5, 92-5, 106-9, 144, 212, 351-3, 433, 465-7, 50511, 515-17, 520-3, 570-2 [72] address 108, 111 difficult 89 dissatisfied 80-1, 83 new 34, 70, 80, 82 potential 75, 82 satisfied 82 customers/end-users 334 Customers/end users 515 D damages 5, 343-4, 420-1 data, incorrect CLIENT 344, 420 data input documents 343, 420 data management 17, 39-40, 560, 565 Data/Voice Services 143, 150 Data/Voice Services Incident 150 databases, knowledge management 361-2, 399, 401 date 103, 130, 138-9, 153-7, 168, 291, 328-9, 336-8, 345-7, 350-4, 422-4, 431-2, 441-2, 4904, 541-3, 569-74 [27] date-time stamps 50 Default‖ 345, 422 Define Incident Categories and Service 174 defined Incident Management's Policies 53 defined Information Security Management's Policies 38 defined Request Fulfillment 54 defined Service Catalogue Management's Policies 36 defined Service Continuity Management's Policies 37 definition, company's 549 degree 76, 82, 87, 94, 122-3, 134, 244, 298, 504, 545, 566 Delivering Unforgettable Customer Service 68 department 115-16, 153, 160-1, 164, 192, 287-8, 293, 329-31, 333-4, 351-3, 437-8, 442-3, 496-7, 527-32, 536, 538-9 [38] functional 116, 313 department Business Owner 496 Department heads 531-2, 536 department managers 496 Departmental Level 359, 397 deploy 29-30 deployment 19, 21-2, 40, 46, 49-50, 60, 292-3, 394 description 26, 96, 100, 166-71, 302, 333-4, 371, 507, 512, 516-17, 522-3, 531-2, 534-5, 543, 558, 563-4 [5] brief 166-8, 285-6, 336, 510, 516, 522, 531, 533, 539, 552 Descriptors 88-9 design 7, 11, 14-17, 24, 28, 34-6, 40, 52, 67, 170, 172, 220, 290, 333, 372, 445 [6] design document 359, 396 design services 35
Page 591
Service Level Management Workbook designations 5, 76 Designing Service Transition 16, 50 desk staff external Service 298 first line Service 299 first-line Service 428 incident Service 353, 433 training Service 299 desks 104, 318, 371, 394, 428-9 Desktop Services 143, 149-50 Detailed Objectives/Goals for Incident Management 134 Detailed Objectives/Goals for Service Desk 331, 436 Detailed Objectives/Goals for Service Level Management 487 Detailed Objectives/Goals Function 330, 436 development phase 40-1, 263 diagnosis 55, 204, 241, 258, 263, 274, 278, 300-1, 307, 362, 400 difficulties 80, 90, 93-4, 466, 484, 488 director, managing 284-6, 289 Disabilities 97-8 disability 97-8, 101-2, 106 cognitive 98 Disadvantages 385-7, 509, 515, 521 discretion 340-1, 416-17 dissatisfaction 71-2, 81-3 diversity, organizations value 91 document 130, 136-40, 152-3, 161-3, 350, 440-4, 493-5, 509-12, 514-17, 521-3, 527-9, 537-9, 541-2, 547-9, 554-6, 561-2 [56] credible 177, 452, 584 single 467, 509, 515, 521 supporting 2-4, 112-13, 130, 309-10, 320, 380-1, 458-60, 486 document Business Requirements 35 document CHG7800 Request 167 Document Control 139, 161, 494, 527, 548, 555, 561 Document for Service Desk 324 Document-management systems 50 Document Source 139, 161, 494, 527, 548, 555, 561 documentation 41, 67, 96, 106, 115, 140, 162-3, 188, 202, 216, 265, 280, 307, 341-2, 417-19, 464 [8] associated 140, 162, 363, 402, 495, 549, 556, 562 bespoke 113, 309, 380, 459 Duplicate 511, 516, 522, 526, 541, 543, 546-7, 554 duties 74, 78, 102, 111, 342, 348, 418-19, 426, 504 E e-mail 73-4, 76, 78, 102-3, 115, 121, 131, 153, 187, 292-3, 312, 321-2, 325, 350, 430, 567-8 [3] e-mail [email protected] 131, 325, 455 Early life support 46, 49 easygoing 88-9 education 1, 16, 76, 78, 175, 177, 191, 266, 280, 376-7, 450, 452-3, 487, 582, 584-5 documentat Effective Date 338, 340-1, 413, 416-17 elapsed time 215, 300, 306 employee id 164 employees 27, 70-2, 83, 87-8, 90, 94, 97, 101, 104, 109, 165, 194, 340-1, 346-7, 416-17, 425 [8] employers 75-6, 78, 91, 97, 100 employment 2, 77-8, 91, 97, 101, 103-5 employment contract 340-1, 416-17 Employment of customer service representatives 77
Page 592
Service Level Management Workbook end-users 155-6, 321, 326, 329, 331, 351-3, 431, 433, 437, 442, 456, 515, 520-1, 526, 557, 563 [2] England 287-9 enterprise 34, 81, 340-1, 417 environment 7-8, 14, 17, 28, 40, 80, 96, 101, 115, 131-2, 134, 143, 145-9, 206, 311, 325 [3] equipment, data processing 338-9, 348, 414-15, 425 equipment services 339, 415 error control 250, 261-2, 279, 305 escalation thresholds 297 escalations 170, 202, 219, 242, 268, 298, 359, 362, 370-1, 397, 400, 411, 428, 469, 500, 506 event 20, 29, 74, 92, 97, 121, 140, 163, 196, 301, 343-7, 366-7, 405-6, 420-4, 427, 532-3 [12] evidence 16, 95-6, 101 examples contact [email protected] 153, 351, 431 Executive Order 2, 106, 108 exercise 16, 173, 176, 341, 359, 373, 376, 396, 417, 446, 451, 570, 579, 583 EXIN 178, 181 Expected time frames 362, 401 expenditure 18, 172, 175-6, 372, 375-6, 445, 449-50, 485, 569, 579, 582 experience 8, 11, 19, 25, 27, 29, 68-9, 76, 79, 81, 83-5, 93, 97-8, 102, 132, 191 [3] expiration 338, 340-1, 345-6, 414, 416-17, 422-3 Extension Number 164 extent 7, 92, 250, 341, 344, 388, 418, 420-1, 472 External Service reviews 63 F Facsimile Number 164-5 failure 26, 140, 156, 163, 198, 202, 204, 343, 345, 347, 353, 383, 389, 420, 422-4, 573 [3] feedback 10-11, 24, 69, 71, 84, 95, 100, 107-9, 111, 142, 144-51, 266, 280, 285, 295, 471-2 [2] Field Description 163-8 financial information 118, 314, 577 Formal memo to Financial Controller 284-6 format 163-6, 177, 377, 452, 584 function 12, 33, 56, 93, 98, 105, 185, 196, 325-6, 328-30, 335-6, 377-8, 395-6, 441-3, 455-7, 557-9 [19] primary 74, 488, 511, 516, 522, 543 Functional 124, 241-2, 274, 370, 411 functional areas 31, 131, 138, 194, 324, 454, 493, 499 Functional Specification 459, 554, 556 Functional Specification document 556 Functional staff 359, 397 functionality 20-1, 35, 42, 368-9, 408-9, 559, 572 funds 130-1, 189, 324, 347, 425, 454, 498-9 G gaps 113, 310, 381, 386, 460, 502 generic 130-1, 134, 136, 152, 157, 171-2, 324-5, 327, 331, 337, 350, 354, 358, 454-5, 498-9, 578-9 [21] Goal and Objective 36-8, 53-5 goals 3-4, 10, 13, 15, 24-5, 43-7, 61-3, 70-1, 88, 105-6, 136-7, 195-6, 329-30, 352, 432, 486 [25] Golden Rule 1, 69-71 grants 343, 419 Group Managing Director 288, 293 groups 19-20, 25, 42, 51, 56, 72, 84, 88, 94-5, 97, 127, 133, 185, 191, 428, 544-5 [8] guide 7, 67, 70, 85, 112, 132, 163, 192, 308, 310, 315, 379, 458, 585 Guidelines and Scope Document 140, 495, 549 H hardware 8, 40, 115, 143-6, 148, 165, 172, 175, 188, 233, 292, 376, 450, 559-60, 564-5, 582 [7] head offices 288, 290-5
Page 593
Service Level Management Workbook health 97, 106, 108, 427 Hierarchical 124, 241-2, 274, 371, 411 high levels 15, 88, 154 hiring 2, 70, 79, 85-6, 333 hiring process 91, 97-8, 104 hours 71-2, 75, 79, 95, 131, 229, 295, 316, 325, 455, 499, 513, 518, 524, 534, 537 [3] Hours of Availability 534-5 hours support staff 513, 518, 524, 540, 553 HR, see Human Resources HR Specialist 102-4 Human Resources (HR) 16-17, 91, 102-4, 290, 305, 566 I ICT Department 290 ideas 72, 85, 88, 92-3, 97, 101-2, 106-7, 439 Implement Service Management 189-90, 193 implementation 7-8, 13-14, 35, 130-1, 170-2, 174-7, 232-3, 250, 324-5, 370-2, 374-7, 410, 444, 448, 450-2, 578-84 [18] incident management 112-13 service desk 308-9, 379-80 service level management 458-9 Implementation activities for Incident Management 176 Implementation activities for Service Desk 377 Implementation activities for Service Level Management 583 Implementation of Service Strategy 10 IMPLEMENTATION of SERVICE STRATEGY 1 Implementation Plan & Project Plan document 440 implementation process 13 Implementing Service Design 1, 11, 13 Implementing Service Operation 1, 18, 60 Implementing Service Transition 1, 15, 50 Improve Customer Satisfaction 331, 436 Improved Customer Service 153 Improved usage of available resources 386-7 improvement system 15 improvements 8, 14, 26, 28, 32, 83, 107, 112-13, 133, 169, 179, 233, 342, 418-19, 485, 488 [15] severable 342, 418-19 Incident and Problem Management 307 Incident and Problem Management process 51 Incident and Service Request 165 incident categories 140, 469 Incident Category Definition 3, 138-9 Incident Category Definition Document 165 Incident Closure 155, 299 incident control 260, 262, 279 incident details 122, 241, 274 Incident identification and Logging 240, 273 incident Management 353, 433 Incident Management 21, 27, 112-13, 119, 121, 132-4, 137-8, 152, 154, 156, 160, 169-74, 176-7, 185, 230-3, 284-5 [10] INCIDENT MANAGEMENT 3, 158, 235, 273, 361, 399 benefits of 131, 439 implementing 156, 285 sound 326, 456 Incident Management and Problem Management 252, 321 Incident Management and Problem Management roles 297 Incident Management Business Justification 130 Incident Management Category Definition Document Executive 162 Incident Management Goals 153-4, 285, 301
Page 594
Service Level Management Workbook Incident Incident Incident Incident Incident
Management Management Management Management Management
Guide 112 Implementation Plan 140, 162 Information flows Process 173 Policies 140, 162 Presentation 2, 113
Incident Management process 3, 112, 120, 130, 134, 137-8, 140, 153, 156-7, 168-9, 174, 176, 232, 300, 302-3, 375 [5] sound 133, 135 incident management process owner 169-70, 297 incident management reference numbers 140, 162 incident management reviews 169 Incident Management Roles 59 Incident Management Status 130, 133, 136, 152, 156, 169 incident management support team 306 incident management system 233 Incident Manager 133, 169-71, 174, 285, 302, 307, 332, 372, 438 incident matching 120, 264 Incident Mgt 353, 433 Incident Overview 140, 162 incident/problem/change progress 353, 433 Incident/Problem Management 20 incident record 21, 245, 304 incident registration 207, 299, 306 Incident Reporting and Request Fulfillment processes 394 incident resolution 120, 123, 158, 260, 307, 352, 432 timelier 221 incident ticket number 166 Incident Ticket Template 3, 160-1 incident tickets 140-1, 162-3, 166, 360-1, 398-9 Incident to Problem to Known Error 263 Incident Type 142-4, 151, 429 Incident Type and Category Type work 144 incidents 120-5, 132-4, 137-8, 142-51, 153-6, 158-60, 172-4, 240-2, 257-60, 297-304, 306-7, 332, 351-3, 360-1, 375, 397-9 [42] availability-related 174, 374 effect of 199, 319 escalation of 240, 273 log 360, 397 major 12, 42, 53, 160 multiple 240, 274, 360, 398 resolving 134, 235 Incidents and Service Request 356 Indifference 82-3 individuals 19, 75, 85, 88, 95, 102-3, 543 industries 7, 21, 68, 74-9, 111, 342, 418 business support services 77 Information Management defined Availability Management's 37 defined Event Management's 53 defined Incident Management's 54 defined Problem Management's 55 defined Service Continuity Management's 38 Information Security 199, 383, 409 Information Security Policy Management System 38 Information Services and Information Technology 293 Information Technology 179, 337, 413, 529 Information Technology Service Desk 335 information‖ 341-2, 417-18, 511, 517, 523, 543
Page 595
Service Level Management Workbook infrastructure 18, 115, 132, 134-5, 137-8, 188, 293-4, 301, 312, 363-4, 366-7, 370, 402-3, 405-6, 410-11, 530 [23] inputs 10, 12, 19, 25, 33, 36-9, 44-8, 50, 53-6, 65, 116, 120, 195-6, 533, 558, 563-4 [9] inquiries 73, 78, 80, 149 Intellectual Property Rights 342, 418-19 interactions, customer/service provider 84 interactive voice recognition (IVRs) 221, 322 interest 96-7, 184, 252, 254, 338, 342, 414, 418-19, 507, 571 interest charges 338, 414 interfaces 17, 21, 36-9, 42-3, 51, 53-6, 61, 76, 82, 233, 261, 285, 290, 300, 364-7, 404-6 [4] inter-process 44-8 required business processes 177, 377, 452, 585 Internal service review meetings 66 interview 2, 39, 85-6, 89-91, 95-9, 103-5, 496 interview panel 90, 103 interview panel members 103 interview process 86-8, 90, 95, 98 INTERVIEW QUESTIONS 2, 86, 89-90, 92, 96, 103, 105 interviewee 98 interviewing 2, 86, 95-6 introduction 15-16, 23, 56, 287 IT-organization 26-7, 382, 432, 442 IT Service Management (ITSM) 1, 7-9, 13, 19, 27, 59, 65-6, 115, 151, 166, 178-9, 181-2, 185, 188, 359, 396 [2] ITIL 1, 7-10, 26-7, 115, 117, 181, 188, 195, 242, 299, 313, 360, 398, 587 ITIL Framework 8, 66, 179, 187 ITIL implementation 8-10, 27 ITIL processes 26-7, 118, 133, 185, 233, 281, 314, 322, 333, 361, 363, 366-8, 399, 402, 405-7 ITIL Service Management 7-9, 504 ITIL Service Management implementation 7-8 ITIL Service Management process implementation 26 ITIL V3 SLM Presentation 458-9 ITSM, see IT Service Management ITSM support tools 21 ITSM Tool Requirements document 359, 396 ITSM tools 21-2, 163 IVRs (interactive voice recognition) 221, 322 J job 2, 31, 73, 76-9, 86-98, 102-5, 107, 501 Job Customer Service 86 K Key performance indicators 43-8, 157, 354, 575 Key Performance Indicators 157-8, 184, 298, 300, 354-5, 357, 574-5 KEY PERFORMANCE INDICATORS, see KPIs knowledge 11-12, 22-3, 29, 48, 74, 76-7, 82, 86-7, 96, 98, 102, 106, 112, 242, 284-5, 447 [13] knowledge base, organizations methodology 112, 458 Knowledge Management 47-8, 193, 444-5, 447, 449, 451-2 knowledge management process 47, 449-50 Known-error database 304 Known Errors 20, 120, 123, 134, 173, 204, 219, 233, 262-4, 268, 279, 304, 361, 373, 447 KPIs (KEY PERFORMANCE INDICATORS) 43-8, 54, 56, 62-3, 69, 157, 184, 192, 300, 354, 357, 574-5 KSAs 96, 102 L laptop 145-6, 302, 316, 322 last name 139, 161, 164, 494, 527, 548, 555, 561 laws 97, 105, 111, 344, 348, 421, 426 legacy 193 letter 91
Page 596
Service Level Management Workbook levels priority 512, 517, 523, 539, 544, 553 staffing 216, 229 liability 5, 343, 420 licences 21 dedicated 21 licenses 60, 363, 365, 402, 404 Likeable 88-9, 92 line support, first 159, 299, 321 line supp Linked Record 164-6, 168 linking 238, 256, 366-7, 406-7 links 6, 71-2, 104, 116, 135, 292, 313, 332, 362, 365-8, 401, 404-7, 438, 490, 514, 519 [4] automatic 366-7, 405-6 list 86-7, 89-90, 135, 162-3, 291, 332-4, 359, 368-9, 396, 408-9, 439, 485, 488-9, 511-12, 532-4, 557 [11] following 151, 300-1, 303 List of Customer Service 89 login, failed 370, 410 logistics department 289 London 287-90, 292-3 lose 137-8, 328-30, 441-3, 491-3 M MAC (Move, Add, Change) 199, 383 mainframe 145-6, 292-4 maintaining liaison, responsibility of 348, 426 maintenance 23, 52, 143, 149, 289, 294, 308, 346, 369, 379, 408, 423, 505, 507, 557 maintenance information 364, 402 Major outputs 40-1 management 8, 17, 19, 37, 42, 45-6, 64, 83, 159-60, 188, 240-1, 273-4, 337, 356, 413, 464 [33] mainframe 57 management information 22, 212, 223, 264, 323 management presentations 112-13, 308-9, 379-80, 458-9 Management reports for Service Level Management 577 management tool 363-8, 401-8 management tool structure 365, 404 management tool support 362, 401 managers 85, 87, 90, 94, 100, 104-5, 131, 154, 284-5, 289-90, 293-4, 300, 352, 432, 472-3, 570 [9] business focus 327, 457 managing Customer requests 211 map 527, 530 map business processes 34 market space 10-11, 30, 32, 529 marketing 80, 102, 212, 288-9, 342, 418, 496-7, 507 materials 14, 85, 104, 180, 291, 295, 338, 340-1, 343, 414, 416-17, 420 medical examinations 97 metrics 3-5, 9, 34-5, 44-8, 53-6, 113, 156-8, 192, 300, 309, 353-5, 427-9, 459, 486-7, 500, 574-5 [5] Metrics for Service Desk performance 427 mission statement 186, 334, 529, 531 Mission statement for Service Desk 329, 442 model 11, 52, 62, 82-4, 165, 174, 374, 448, 485, 502, 530, 581 model of Service Desk support 325, 456 modules 21, 153, 155, 291, 342, 350, 353, 365-8, 404, 406-8, 419, 430, 433, 568, 571 monitor 24, 56-7, 60-2, 94, 132, 223, 227, 462, 469, 482, 487, 492, 496-7 Monitoring and Co-ordinating of Incidents and Service Requests Most customer service 76 Most customer service representatives work 75
172, 372
Page 597
Service Level Management Workbook Move, Add, Change (MAC) 199, 383 movement 82, 147 Multi-Level Based 520-1 Multi-Level Based Service Level Agreement
521
N names 71, 91, 99, 101, 103, 139, 161, 164, 168, 336, 510-12, 516-17, 522-3, 531-3, 541-2, 554-5 [14] first 139, 161, 164, 494, 527, 548, 555, 561 National Federation of Independent Business (NFIB) 70 network 17, 22, 99, 120, 240, 274, 288, 293, 362, 400, 557, 563 Network Services 143, 146, 150 Network Services Incident 150 New customers/services 20 New Firm‖ 341, 417 New tools 23, 175, 224, 375, 389, 450, 582 NFIB (National Federation of Independent Business) 70 non-management employee 90 Notes/Comments 169-70, 177, 333-4, 507 notifications 353, 360, 370, 398, 411, 433 number 20-2, 158-60, 163-4, 289, 298, 306, 326-7, 336, 355-7, 429, 456-7, 474, 476, 484, 541-2, 545-7 [17] largest 77, 79 O Objective and Scope for Incident Management 174 objective statement 137-8, 172-3, 329, 373, 442, 446, 492, 579-80 objective tree 115, 187, 311 objectives 3-4, 10, 36-8, 43, 51, 53-5, 61, 88, 133-7, 186-7, 329-32, 436-7, 439-40, 486-8, 491-2, 529-30 [21] organizational 179, 187-8, 530 Objectives and Goals document 443 Objectives and Scope for Incident Management 136 Objectives and Scope for Service Desk 327, 440 Objectives and Scope for Service Level Management 491 Objectives and Scope Function 327, 440 obligations 289, 339, 341, 343, 345, 415, 418, 420, 422 occasions 19-20, 93-5 occupations 2, 73-5, 77-80 occurrence 326, 345-7, 422, 424, 457 officers 341, 344, 417, 421 OGC 189-90, 193, 199 OLAs (Operational Level Agreements) 4, 42, 61, 298, 447, 459, 461, 464, 466, 472-3, 480, 482, 495-6, 505-7, 537-42, 571-2 [2] omissions 344, 346, 421, 424 Open Time 166-7 operation capabilities 11 operation outsourcing services 337, 413 Operational Level Agreements, see OLAs Operational Staff in Service Design and Transition 20 operations 11, 16, 23-4, 28, 32, 57, 59, 75, 98, 109, 178, 232, 268, 337, 344, 346 [5] support business 192 order 11, 19, 21-3, 33, 73, 75, 86-7, 212, 291, 295-6, 339-41, 346-7, 411, 416-17, 423-5, 463 [18] organisation 7-9, 66-7, 82, 137, 156, 199, 318-19, 321, 332-3, 335, 357, 383, 571-2 organization 15-18, 21-9, 32, 77-82, 102-13, 130-4, 184-7, 190-3, 290-5, 324-7, 395-6, 40912, 485-8, 507-9, 526-31, 566-9 [89] external 186, 389, 531 mature 389 me/us/the 173, 373, 446, 579 physical 198, 382
Page 598
Service Level Management Workbook organization chart 90 organization name 494-5, 527-8, 531, 555-6, 561-2, 574 organization perspective 117, 313 organization policies, applicable 105 Organization-Wide Standards 2, 110 organizational change 16, 24, 32, 48, 61, 66 Organizational example 153, 351, 431, 569 organizational forms 317-18 organizational structure 176, 294, 333, 376, 451, 583 clear Service Desk 58 organizations definition 495 organizations knowledge base 308, 379 outcome 28, 30-1, 67, 83, 92-6, 154, 173, 185, 302, 352, 373, 388, 432, 446, 570, 580 outgoing 88-9, 94 outputs 24, 36-9, 44-8, 53-6, 116, 120, 188, 195-6, 313, 338, 368, 408, 414, 495, 558-9, 564 [1] outsource 32, 186, 298 outsourcer 293, 343, 348, 388, 420, 426 business of 342, 418 control of 349, 427 exclusive responsibility of 348, 425 negligence of 343, 420 reasonable control of 344, 420 OUTSOURCER access 339, 415 OUTSOURCER Employee 340-1, 416-17 OUTSOURCER management staff 340, 416 OUTSOURCER staff 339, 415 OUTSOURCER subject to Section 339, 414 OUTSOURCER's Contract Administrator 348, 426 outsourcing 19, 58, 137, 328, 389, 441, 485, 491, 567 Outsourcing Service Agreement 337, 412 Outsourcing services 338, 392, 413 total 337, 413 Outsourcing Template 4, 336, 411 owner 5, 70, 165, 184, 488, 496, 510, 516, 522, 533, 536-7, 550 ownership 16, 140, 162, 273, 298, 300, 307, 341, 343, 417, 419, 495, 528, 549, 556, 562 ownership requirements 343, 419 P panel 90, 96, 103 Paper-based systems 233, 235 Parent Business Activity/Process 532, 535 parent SLA 539-40, 552-3 part hereof 338, 413 participants 28-9, 191, 314, 533, 535 parties 19, 24-5, 141, 245, 333, 337-8, 341, 345, 348-9, 413-14, 418, 422, 426-7, 476 disclosing 341-2, 418 partner 13, 292, 341, 347, 417, 425 Party‖ 345, 422 path, standard 533 payments 290-1, 337-8, 345, 347, 413-14, 421-3, 425 PC 145-6, 149, 165, 304 penalties 368, 407, 513, 518, 524, 546, 569 perception 33, 95, 156, 176, 329, 331, 353, 376, 434, 437, 442, 449, 451, 463, 469, 573 performance 14, 56, 86, 101, 143-4, 339-40, 342-3, 353-4, 415-16, 418-20, 427-8, 473, 488-9, 513, 518, 524 [26] oversee 348, 426 review OUTSOURCER 340, 416 period, aforementioned 346, 423-4 person 5, 86-8, 90-101, 164, 170-1, 295, 301-2, 325-6, 340-1, 372, 416-17, 445, 455-6, 499-
Page 599
Service Level Management Workbook 502, 504, 578 [12] personality, five descriptive elements of 88 personality factors 88-90 personnel 19, 104, 121, 175, 186, 259, 290, 339, 344, 346, 375, 415, 420, 423, 450, 487 [2] field trials customer service 84 nominated 154, 352, 432, 570 personnel action 101-2 phases 7, 10-11, 23-5, 96, 167, 229, 258, 278, 299, 346, 423, 572 phone 71, 164, 166, 331, 353, 357, 433, 437 Phone numbers 164, 336, 513, 518, 524, 540, 553 PIRs (Post Implementation Reviews) 264, 471 plan 10-11, 15, 21-4, 43, 66, 92, 105-8, 157, 171-2, 220, 232-3, 286, 334, 371-2, 444-5, 578-9 [8] planning 22, 26, 45-6, 49, 95-6, 171, 186, 232, 365, 371, 405, 440, 444, 463-4, 529, 578 [1] Planning & Implementing Service Management Technologies 60 Planning and implementation for Service Level Management 578 Planning to Implement Service Management 189-90, 193 platform 265, 280 policies 13, 16, 27, 43-7, 92, 104, 109, 136, 172, 186, 293, 327, 440, 445, 490-1, 579 [23] Policies Objectives 3-4, 136, 327, 440 Policy Statement 136-8, 172, 327-8, 372, 440-1, 445, 491, 579 Populated 164-6 position 10, 75-6, 78, 86-8, 90-2, 96-9, 101-5, 187, 196, 288, 303, 486, 529 strategic 10 position announcements 105 position description 86, 89-90, 95, 102, 104 post-Change occurrence of particular Problem types 265, 280 Post Implementation Reviews (PIRs) 264, 471 potential service improvements, identifying 461, 481 PowerPoint presentations 112-13, 309, 380, 458-9 PRACTICE 1 practices, service level management 584 prerequisites 15, 43 presentations 95, 97, 112, 284-6, 308-9, 379-80, 458 final 284-5 Preventative action 133, 265, 269, 280 prices 27, 80-1, 566-7 pricing 31, 36, 501, 550, 566-7 Priority 158, 160, 165, 169, 303, 360, 362, 398, 400 Proactive Problem Management 266, 281, 305, 411 Problem Control 260, 263 problem investigation 260 Problem Management 15, 27, 55, 173, 247, 250, 252-3, 259, 268, 280, 285-6, 297, 303-7, 353, 447, 488-9 [8] PROBLEM MANAGEMENT 3, 278, 362, 401 benefits of 303 proactive 250, 266, 280 PROBLEM MANAGEMENT, problem analysis reports pro-active 265, 280 Problem Management, reactive 250 Problem Management and Incident Management 266, 280 problem management data 265, 280 problem management process 51, 170, 259, 298, 305, 326, 456 problem management roles 59, 297 problem management system 233, 263 Problem Management's Post implementation review 65 Problem Manager 170, 245, 297, 304-5, 307, 502 Problem Manager and Service Desk manager 297 Problem review 268, 286, 296, 305 problem tickets 167, 362, 400-1 problem types 265, 280 problems 67, 75-6, 81-4, 92-3, 96-7, 122-3, 259, 262-6, 268-9, 279-81, 294-5, 297-9, 303-6,
Page 600
Service Level Management Workbook 325-6, 360-2, 398-402 [31] common customer 76 minor 82-3 procedures, clear 353, 433 process activities 53, 55, 175, 376, 450, 577, 582 incident identification 53-4 process areas 134-5, 177, 179, 332, 351, 431, 438, 452, 584 process implementation 176-7, 450, 452, 582, 584 acceptance of 231-2 process managers 157, 170, 185, 322, 333, 355, 507-8, 575 process owners 15, 157, 176, 184-5, 353, 355, 359, 376, 397, 433, 450, 531-2, 534, 536, 566, 575 [1] multiple 366-7, 405-6 processes, new 15, 23, 67, 177, 453, 585 processing 138, 558, 563-4, 567 batch 142, 146 process‖ 115, 187, 312 products 5, 9, 13, 32, 68-71, 73-4, 76-7, 80-3, 107, 109, 143, 145-9, 194, 224, 288, 308 [1] primary 532, 535 profitability 78, 80-1 projects 9-10, 17, 19, 26, 52, 66-7, 92-5, 195-6, 489 providers, external 551-2, 567, 575 provisions 9, 179-80, 187, 323, 348-9, 426-7, 500 grant 343, 419-20 provisions of subparagraph 343, 419-20 Prudent Information Technology Practices 344, 421 publisher 5 Q qualifications 1-2, 72, 75-6, 97, 100, 103-4, 504 quality customer service 70 quality services 16, 69, 108, 111, 132 high 106, 108 questions customer service-type 89 disability-related 97-8 incident management 307 open-ended 89-90, 96, 99 probing 89, 91 R RACI 501-2 RACI matrix 41 read 67-8, 89, 99, 104, 137-8, 163-7, 328-30, 441-3, 491-3, 566 reader 7-8, 130, 132, 134, 136, 152-3, 157, 171-2, 350-1, 354, 430-1, 514-15, 520-1, 568-9, 574, 578-9 [28] Rece 287-91, 293, 295 Rece organization 291 receipt 103, 346-7, 423-4 recipient 341, 418 reconstruction 343, 420 record 100, 121, 141, 174, 245, 263, 302, 304, 332, 360, 363, 365, 375, 398, 401, 403-4 [1] record incidents 326, 457 record license information 363, 402 record service levels 364, 403 recruiting 2, 85, 101, 104-5 recruitment 2, 102, 104-5, 160, 290, 577 recruitment process 101-4 recruitment strategies 102, 105 redevelopment 343, 420 Reduced operational costs 386-7
Page 601
Service Level Management Workbook reduction 132, 140, 153, 163, 198, 202, 204, 300, 355, 382 reference number 510, 514, 516, 519, 522, 525, 540, 553-4 reference sites 370, 410 references 2, 86, 91-2, 96, 99-101, 105, 113, 130, 309, 324, 358, 380, 396, 454, 459, 498 [1] cross 538, 542, 552 regeneration 343, 420 regions 194, 290-1 register 207, 363-4, 402-3 register problem tickets 361, 399 registration 336, 352-3, 363, 402, 432-3 regulations 29, 61, 76, 105, 111, 341, 344, 418, 421 relation 23, 101, 144, 146-9, 363, 401, 467 Release Management 27, 304-5, 332, 365-6, 370, 404-5, 411, 438 replacement 19, 79, 343, 420 Reports and KPI Targets for Service Level Management 574 REPORTS KPI 3-5, 353 Request for Change, see RFC Request for Tenders (RFT) 359, 396 requirements 7, 12-14, 16-17, 38-9, 358-60, 368-9, 396, 407-8, 461, 464-6, 475, 515, 542-3, 546-7, 560, 565 [15] requirements investigation technique 39 research 25, 73, 80-5, 362, 400 resets, password 140, 142, 144-5, 163 resolution 55, 120, 122, 125, 133-4, 155, 160, 168, 171, 199, 235, 240-2, 244, 274, 300-1, 305 [8] resolution times 356, 469 resources 10, 17-18, 20, 28-9, 32, 35, 113, 219-20, 231-2, 250, 309-10, 367, 380-1, 386-7, 407, 459 [15] strategic 32 response times monitor incident 469 quicker 539, 553 responsibilities 4, 24, 41, 58, 65, 71, 74, 88, 102, 111, 127, 338-9, 393, 414, 500-2, 504-5 [22] document customer 500 responsiveness 51, 331, 437 restore service 132, 134, 155 result 7, 20, 34, 43, 51, 75-9, 137, 173, 231-2, 329, 373, 389, 442, 446, 492, 580 [14] Return on Investment, see ROI review 3, 6, 89-90, 102-4, 156-7, 169, 171-3, 176-7, 354-6, 371-3, 376-7, 451-2, 506-7, 5745, 577-80, 583-4 [52] timely 111 review Service Achievements 492 RFC (Request for Change) 45, 120, 123, 125, 167-8, 173, 199, 262, 266, 279-80, 298, 306, 316, 364, 403, 447 [3] RFC Incident Closure 241, 274 RFT (Request for Tenders) 359, 396 Right Customer Service Representatives 1, 72 risks 11-13, 17-18, 20, 31, 33-9, 42, 47, 51, 53-6, 67, 189, 508 ROI (Return on Investment) 52, 63, 105, 221, 303, 332, 438 role descriptions 511-12, 517, 519, 523, 525, 541, 544, 554 roles 7, 17, 23-4, 27-8, 36, 65-6, 176-7, 297, 333, 376-7, 393-4, 451-2, 500-2, 504-6, 538, 551 [19] Roles & Responsibilities 4, 459, 501 rows 127, 196-7, 531, 536 S SACM 45-6 sales 68, 74, 77, 80-1, 115, 143, 150, 187, 288-90, 311, 496-7 Sales Departments 290 sales offices 290, 294 sample, representative 268-9 SAMPLE CUSTOMER SERVICE 2
Page 602
Service Level Management Workbook scheduling 19, 22, 92 SCM and Service Knowledge Management Systems 17 scope 3-4, 44-7, 140, 143-4, 162, 173-4, 327, 330, 343, 359, 373-4, 396, 419, 440, 443-4, 493-7 [23] defined Incident Management's 53 defined Information Security Management's 38 defined Service Catalogue Management's 36 defined Service Continuity Management's 37 scope of Data Management 39-40 Scope of Services 340, 416, 506 SCOPE of SERVICES 344, 421 scope statement 138, 173, 329-30, 373, 443, 446, 492-3, 580 scripts 40, 57 SD 316-18, 320, 332, 439 SD staff 319, 331-2, 437-8 searches 42, 166, 326, 368, 408, 457, 574 Secondary Products 533, 535 section 11, 18, 90, 96, 140, 338-40, 413-16, 489-90, 495-7, 516-17, 522-3, 531-3, 542, 546-7, 556-60, 562-4 [15] security incidents 133 see 23, 74, 96, 118, 160, 191, 194-5, 304, 314, 336, 359-64, 366-70, 397-403, 406-7, 409-10, 529-30 [1] see costs 367, 407 see INC 165 see people being 366-7, 405-6 see problem tickets 361, 399 see SLA information 361, 399 selection 13, 67, 96, 99-101, 103-4, 163, 185, 290 selection policies 104-5 selection processes 2, 85, 104-5 Self Explanatory 164-6 server 123, 145, 149, 292, 294, 297, 488, 511, 517, 523, 543 Servic 537 Service Asset 33, 411 Service Asset & Configuration Management 401, 411 service availability 198, 383, 438, 489, 564, 580 Service Based 459, 466, 514, 516 Service Based Service Level Agreement 515 service being 467, 470, 515 Service Breach Clause 513, 518, 524, 546 service calls 198, 382 Service Catalog 507, 519, 525, 547-8, 581 Service Catalogue 10, 31, 34, 42, 62, 66, 462, 465, 475, 490, 495, 505, 514, 533, 549-50, 5712 [2] customer-facing 61 Service Catalogue Manager roles 41 Service Charging policy 513, 518, 524, 545 Service Components 80, 550 Service Continuity Management 174, 295, 332, 368, 375, 407, 438 Service Continuity Management's Stage 38 Service Continuity Manager roles 41 Service Continuity Plan 514, 519, 525 Service Continuity Planning for ITSM Support Tools 60 service costs 42 service degradation 250, 489 service delivery 187, 285, 352, 379, 432, 466, 492, 499-501, 512, 517, 523, 544-5, 566, 570, 576, 584 Service Delivery and Support 154, 177, 377 Service Delivery Manager 139, 161, 494, 527, 548, 555, 561 service delivery processes 285 Service Description 488, 511, 516, 522, 526, 539, 543, 552, 556, 563 Service Design 7, 10, 13-15, 24, 34, 41, 43, 47, 458-9, 461, 480, 483, 501
Page 603
Service Level Management Workbook SERVICE DESIGN 1, 4, 11, 13, 15, 460 Service Design and Service Transition 20 Service Design Manager roles 41 Service Design Process Implementation Considerations 42 service design processes 11, 14, 36 service designs 11, 52 Service Desk 3, 60, 159, 284, 295, 297-300, 303-4, 306-10, 321-6, 329-37, 350-8, 371-82, 390-6, 427-34, 436-9, 442-3 [37] benefits of 325, 455 distributed 332, 439 local 300, 332, 439 managed 326, 456 professional 326, 456 virtual 332, 439 Service Desk Activities 321, 352, 377, 433 Service Desk and Service Management 358, 396 Service Desk Business Justification 324, 454 SERVICE DESK FACTSHEET 3, 321 service desk function 51, 57, 185, 231-2, 308-9, 324, 326, 329-30, 350, 358, 379-80, 396, 430, 442-3, 454, 457 Service Desk Goal 332, 351-2, 431-2, 439 Service Desk Guide 308 Service Desk Information flows 373 Service Desk Introduction Roadmap 3-4, 308, 379 Service Desk Manager 171, 302, 307, 333-4, 372, 374, 391, 393 role of 333-4, 393 Service Desk Manager and Incident Management process owner 297 SERVICE DESK MANAGER ROLE 3, 332 Service Desk Metrics 4, 58, 427 Service Desk Metrics document 390, 442 Service Desk Mission Statement 329, 442 Service Desk Objectives 4, 58, 394, 436 Service Desk Organizational Structure 198, 382 Service Desk Outsourcing 337 Service Desk Outsourcing Template 4, 411-12 service desk performance 334, 355, 427 Service Desk Planning 353, 434 Service Desk Presentation 3, 310 Service Desk Requirements 352, 432 service desk role 4, 384 Service Desk Roles, clear 58 Service Desk Services 143, 149 service desk staff effort 219 Service Desk Staffing 58 Service Desk Status 324, 327, 330, 333, 349, 354, 358, 436, 440, 454 service desk support 325, 332, 456 Service Desk Technology 4, 358, 395 Service Desk Technology Selection 358, 395-6 Service Desk Technology Selection Function 358 service desk types 198, 321, 382 Service Desk Workbook 136-9, 141-77, 180-3, 195-8, 208-17, 230-8, 251-5, 257-61, 267-78, 295-9, 303-8, 379-85, 398-410, 412-16, 418-33, 435-41 [21] Service Desk Workbook Aligning Customer perception 227 Service Desk Workbook Balanced 184 Service Desk Workbook Categorization 244 Service Desk Workbook Choosing 207 Service Desk Workbook Computerizing 219 Service Desk Workbook Costs of running multiple service desks 386 Service Desk Workbook customer 288 Service Desk Workbook Data 392 Service Desk Workbook Depending 225
Page 604
Service Level Management Workbook Service Desk Workbook During Ownership 246 Service Desk Workbook Elements 189-90 Service Desk Workbook Employee‖ 417 Service Desk Workbook Errors 263 Service Desk Workbook Escalation 242 Service Desk Workbook Finally 192 Service Desk Workbook FOCUS 292 Service Desk Workbook Global organizations 387 Service Desk Workbook Good Problem Management 250 Service Desk Workbook Incident 202, 204, 302 Service Desk Workbook Incident Management 411 Service Desk Workbook Introduction 140 Service Desk Workbook Intrusive & Hidden 434 Service Desk Workbook Investigation and Diagnosis 241 Service Desk Workbook London 294 Service Desk Workbook Most 194, 256 Service Desk Workbook Ownership 240 Service Desk Workbook Problem Management 266 Service Desk Workbook Process Managers 185, 286 Service Desk Workbook QUESTION 300 Service Desk Workbook Reporting 229 Service Desk Workbook Request for Change 199 Service Desk Workbook Scope Statement 443 Service Desk Workbook Self help 239 Service Desk Workbook Service Desk 223 Service Desk Workbook Service Desk Supervisor 394 Service Desk Workbook Service Level Management 397 Service Desk Workbook Something 442 Service Desk Workbook Supporting Documents 393 Service Desk Workbook Task 285 Service Desk Workbook Tips 262, 279 Service Desk Workbook Trend Analysis 280 Service Desk Workbook Types 218 Service Desk Workbook Typically 179 Service Desk Workbook Vendor partnership 224 Service Desk Workbook Welcome 178 service disruptions 12, 501 Service Expectation Level 517, 523 Service Failure Analysis (SFA) 64 service hours 536, 550 service implementation 502 service improvement 10, 14-15, 61, 485 Service Improvement Plan, see SIP service improvement programme 63, 572 service improvement project 24, 207 Service Information 511, 516, 522, 542 service interaction 83-4 service Knowledge Management system 49 Service Knowledge Management system 65 Service Knowledge Management System (SKMS) 17, 42, 48-9, 65 Service Knowledge Management Systems 42, 48 Service Level Agreement reference numbers 556, 562 Service Level Agreements see SLA created 542 formal 13 parent 538, 552 Service Level Management implemented 26 implementing 573 major focus of 461, 481 Service Level Management (SLM) 15, 17, 27, 63, 314, 366-7, 405-6, 447, 458, 460-5, 467, 480-
Page 605
Service Level Management Workbook 4, 492-3, 499-501, 570, 577-8 [20] Service Level Management Activities 570, 583 Service Level Management and Business Relationship Management processes 24 Service Level Management and Release and Deployment Management 449 Service Level Management Business Justification 498 Service Level Management Deliverable 571 service level management forces 500 Service Level Management Goals 569-70 Service Level Management Information flows Process 580 Service Level Management Introduction Roadmap 4 Service Level Management Overview 495, 549 Service Level Management Planning 572 service level management process 63, 184, 458, 483, 488, 492, 494-5, 498, 538, 551, 568, 570, 573-4, 583 SERVICE LEVEL MANAGEMENT process 580 SERVICE LEVEL MANAGEMENT PROCESS OWNER 506-7, 509, 515, 521, 538, 551 service level management reference numbers 495, 549 Service Level Management Service Options Status 547 Service Level Management Status 486, 490, 493, 498, 506, 509, 520, 526, 541, 551, 565, 567, 574, 578 Service Level Management Workbook 450-1, 457-8, 460-72, 475-7, 479-81, 483-6, 493-502, 506-10, 516-20, 534-6, 540-2, 544-6, 548-54, 556-9, 568-70, 573-84 [11] Service Level Management Workbook Activity 452, 503 Service Level Management Workbook Administration 530 Service Level Management Workbook Areas 522 Service Level Management Workbook Chargeable Item 567 Service Level Management Workbook Communicate 453 Service Level Management Workbook considerations 547 Service Level Management Workbook Continuity Considerations 514 Service Level Management Workbook Create 585 Service Level Management Workbook Customer definition 511 Service Level Management Workbook Describe 564 Service Level Management Workbook Description 539 Service Level Management Workbook documentation 490 Service Level Management Workbook Establish 449 Service Level Management Workbook Functional Roles 504 Service Level Management Workbook High 537 Service Level Management Workbook Introduction 562 Service Level Management Workbook Intrusive 571 Service Level Management Workbook List 533 Service Level Management Workbook Management 505 Service Level Management Workbook Mission Statement 531 Service Level Management Workbook name 543 Service Level Management Workbook Notes 526 Service Level Management Workbook Objective 478 Service Level Management Workbook Operational reports 473 Service Level Management Workbook organization 456 Service Level Management Workbook Outputs 572 Service Level Management Workbook Particular attention 474 Service Level Management Workbook Price List 566 Service Level Management Workbook process 459 Service Level Management Workbook Rejected 527 Service Level Management Workbook Release Date 487 Service Level Management Workbook Reliability 560 Service Level Management Workbook response time 524 Service Level Management Workbook Service Expectation 512 Service Level Management Workbook Service Level 458 Service Level Management Workbook Service Overview 563 Service Level Management Workbook Something 492 Service Level Management Workbook Status 515, 538, 555 Service Level Management Workbook table 523 Service Level Management Workbook Version 521
Page 606
Service Level Management Workbook
Service Level Manager 23, 502, 505-8, 566 Service Level Manager roles 41 Service Level Requirements, see SLRs Service Level Requirements Process 541 service level reviews 473 service levels 8, 11, 19, 33-4, 62, 71, 144, 297, 321, 359, 397, 461-3, 465-7, 482-3, 505-6, 571-3 [5] Service Lifecycle 7, 10-11, 24, 42, 44, 379, 460, 480, 483 service lifecycle stages 43, 51, 61 Service Management 8-9, 12, 27-8, 34, 43, 51, 60, 115, 166, 180, 187, 192, 195, 220, 223, 312 [3] SERVICE MANAGEMENT 1, 11 Service Management, implementing ITIL 7, 9, 66 Service Management processes 8, 13, 62-3, 411 service management systems 11 Service Management Tool work instructions 52 Service Mapping 4, 52, 459, 526-7 Service Metrics 62, 66, 513, 518, 524, 545 service name 488, 511, 516, 522, 542, 554, 561 Service Operation 1, 8, 18-20, 51, 57, 60, 202, 204, 393, 411, 443, 461, 480 normal 119, 132, 301, 304, 411 purpose of 18, 51 Service Options 4, 459, 547, 549-50 service organization 32, 178 service outage levels 12, 42 Service Owner 533-7 service owner role 49, 65 service package 16, 61 service performance 334, 473 benchmark customer 107 service performance reviews 505 service periods 12, 42 service portfolio 11, 28, 34-6, 42, 462, 475, 505 service provider organizations 15 service providers 10-11, 15-16, 26, 29-30, 32, 61, 83-5, 144, 221, 303, 462-3, 465, 508 service provision 13, 19, 68, 382, 411, 432, 442, 485, 571 Service Provisioning Agreement 572 service quality 47, 301, 411, 461-2, 473, 484, 488 improving 28, 259 service reports 473, 505 service reps 292 service request handling 393 service requests 33, 121, 140, 162-3, 165, 172, 198, 202, 297, 299, 316, 332, 334, 351, 356, 372 [4] service requirements 35, 505, 543, 570 service review meetings 470 service reviews 506 active 478 Service Security Considerations 489, 512, 517, 523, 544 Service Spec Sheets 572 service specifications 52, 572 Service Strategy 1, 7, 10-11, 28-9 Service Support 112, 154, 308, 355 Service Support Hours 512, 518, 524, 545 Service Support processes 231-2, 284 Service Support Processes 232 Service Support set 176, 376 Service Target Response priorities 512, 517, 523, 544 Service Target Response time 512, 517, 523, 544 service targets 63, 462, 485
Page 607
Service Level Management Workbook Service Transition 1, 8, 10, 13, 15-18, 33, 43-4, 46-8, 50-1, 450, 452 service transition processes 15-17, 44 service users 475 Service Validation 46-7 service varieties 30 ServiceDesk 580 services 10-13, 27-36, 67-71, 73-8, 106-9, 143-50, 343-7, 382-9, 420-5, 461-8, 481-4, 493501, 505-31, 533-7, 541-54, 556-67 [79] audio/visual 329, 442 changed 12, 16, 34, 43-4, 464-5, 471, 475 coordination 343, 419 delivery mechanism of 179, 529 employment 77, 79 high-quality 69, 222 improving 461, 480 live 18, 23, 463 new 13, 15, 20, 35, 176, 326, 376, 450, 456, 468, 580, 582 personalized 210 repair 329, 442 restoring 137, 170, 370 shared 131, 324, 454, 499, 566 single 515, 521 telephone 339, 415 transitioned 17-18
services being
134, 496
ion 528, 556, 562 services functions 528 Services Manager 139, 161, 494, 527, 548, 555, 561 services relationship 557, 563 Services/Service Delivery/Business 527 Services/Service Delivery/Functional Specifications 555 Services/Service Delivery/Service Level Management/Scope Document Approval 494 Services/Service Delivery/Service Level Management/Service Options Document 548 Services/Service Support/Incident Management Document Approval 161 Services‖ 338, 413 service‖ 512, 517, 523, 544 set 13-15, 17, 26, 35, 49, 52, 103-4, 177, 180, 338, 378, 413, 453, 471-2, 496-7, 585 [15] Set-up 156, 323, 353, 434, 573 Setting Customer Service Standards 107 SFA (Service Failure Analysis) 64 Shared Licences 21 shareholder 340-1, 417 Sigma 14-15, 43 single point of contact 301, 316, 321, 323, 329, 331, 334, 351-2, 384, 431, 437, 442 SIP (Service Improvement Plan) 13, 62, 464, 471, 474, 484, 488-9, 500, 571-2 skills 11, 41, 65, 76, 79, 82, 86-8, 90, 96-7, 100, 102, 105, 344, 386-7, 421, 504-5 [8] SKMS, see Service Knowledge Management System SLA (Service Level Agreements) 15, 62, 143-4, 159, 356-7, 367-9, 461-73, 495-6, 500-1, 5057, 509-26, 534-6, 538-40, 542-3, 552-3, 571-2 [26] SLA, based 509, 515, 521 SLA Information 510, 521 SLA Management tools 584 slides 113, 190, 194, 229, 257, 269, 275, 277, 281, 309, 317-18, 380, 459 SLM, see Service Level Management SLMMgt 580 SLRs (Service Level Requirements) 4, 12-13, 35, 42, 61, 447, 459, 461, 464, 466, 468, 476, 500, 541-3, 557, 570-2 [4] software 7-8, 22, 56, 115, 143-6, 165, 172, 175, 188, 224, 338-9, 342-3, 414-15, 418-19, 559-
Page 608
Service Level Management Workbook 60, 564-5 [17] software version control tools 66 sound 131, 324-5, 391, 454-5, 499 Special Tip 154, 159, 352, 356, 432, 511, 519, 525, 541, 554, 570, 576 stability 18 staff 13-14, 17-18, 21-4, 27, 67, 69, 155, 175, 177, 229, 295, 297, 326, 375-7, 450, 582 [49] incident tracking 156 service operation 52 staff members 32, 290 stakeholders 10, 14, 17, 24-5, 28, 34, 43-4, 51, 61, 103, 139, 147, 162, 186, 475, 494 [5] start 7, 11, 13, 23-4, 40, 68, 90, 104, 112, 193, 309, 326, 380, 456, 458, 488 [2] statement 130, 132, 134, 136-7, 152, 157, 172-3, 320, 324, 327, 329, 373, 442, 446, 491-2, 579-80 [24] generic sample 137-8, 329-30, 442-3, 492-3 status 46, 56-7, 73, 139-41, 160-1, 165-7, 171, 198, 229, 306, 335, 337, 361, 365, 371, 383 [8] Step Improvement Process 62 Stop SLA Clock 141-2 strategy 10, 12, 14, 28-9, 32-3, 35, 38, 52, 68-9, 81-2, 102, 117, 155, 185, 293, 313 [4] structure 30, 61, 81, 112, 148, 155, 179, 185, 308, 363, 370, 379, 385-7, 402, 458, 521 [4] service desk 326, 456 tubing 131, 325, 455, 499 structured support system 325, 455 sub-process 532-3, 535 subject 26, 29, 69, 98, 138, 329, 338-41, 343-5, 413-17, 420-2, 443, 492 subparagraph 343, 419-20 success 9, 14-15, 19, 25-6, 43, 77, 86, 88, 93-4, 107, 185, 212, 227, 235, 252, 291 [2] successors 348, 426 sums 13, 50, 345, 347, 422-5 Super Users 217, 394 supervisors 74-5, 86, 91, 94, 100, 104-5, 302, 393-4 Supplement 284-6 suppliers 20-1, 39, 71, 144, 223, 225, 291, 294-5, 316, 362, 400, 464, 473, 485, 501, 572 supplies 18, 104, 338-9, 348, 369, 409, 414-15, 425, 508 support 7-9, 30, 67-8, 175, 177, 334-7, 339-40, 365-9, 375-7, 404-9, 415-16, 450, 452, 544-5, 582, 584 [46] initial 122, 240, 273, 299-300 level of 369, 409 support CSI activities 65-6 support groups 141, 159, 297, 316, 321, 384, 472 support hours 513-14, 518, 524-5, 534, 540, 545, 553 Support/Incident Management 139 support operation 227, 229 support organization 211, 253 support organizations, secondary 224 support OUTSOURCER 339, 415 Support Request 142-51, 158, 169 Support Request‖ 174, 374 support service transition 49 support services 16, 77, 212, 348, 425 support staff 18, 21-2, 132, 212, 218-19, 223, 229, 263, 557, 563 support tools 60, 220, 469 cheap 235 integrated 472 survey, regular customer satisfaction 353, 433 systems 11, 42, 44, 56, 92, 144-5, 175-6, 219-20, 291-2, 294-5, 343, 366, 375-6, 420, 450-1, 582-3 [27] computing 346-7, 424 T table
79, 173, 302, 373, 375, 447, 449, 488, 496-7, 511, 516, 531, 533-4, 536, 541, 543 [7]
Page 609
Service Level Management Workbook customer information 522 following 141, 163, 511, 516, 522, 526, 543, 546, 549, 566 tailor 105, 368-9, 375, 408 tapes 339-40, 415-16 tasks 11, 15, 19, 31, 67, 88, 92-5, 98, 121-2, 124-5, 130-1, 133, 284-6, 324-5, 454-5, 498-9 [9] full-time 266, 281 taxes 344-5, 421-2 local 348, 425 team 9-10, 17, 25, 51, 67, 72, 92-3, 101, 173, 176, 185, 290, 373, 376, 450, 582-3 [3] Technical and Customer Service 89 technical competencies 86-7 technical considerations 488, 490, 511, 514, 516, 519, 522, 525, 543, 546, 564 Technical Management Roles 58 techniques 24, 36-9, 41-2, 47, 63-4, 175, 376, 450, 582 technology 7, 9, 14, 20, 33, 35, 42, 52, 66, 78, 179-80, 190, 222, 288, 293, 387-8 [2] telephone 73-6, 121, 293, 295, 428 telephone calls 74, 264 templates 112-13, 167-8, 308-9, 337, 379-80, 412, 458-9, 514, 520, 526, 547, 549 document PROB6800 Problem Ticket 167 document PROB6900 Known Error Ticket 167 term goals, long 32 Terminated party 345-6, 423 termination 39, 338, 340-1, 345-7, 414, 416-17, 422-4 event of 346-7, 424 Termination Date 346-7, 423-4 terminology 27, 152, 168, 370, 410, 498, 537, 550 terms 11, 13-14, 16, 28, 33, 91, 112, 183, 224, 258, 278, 337-8, 345-6, 413, 422-3, 458 [16] text 102, 130, 320, 335, 337, 393, 412, 486 text box 137-8, 328-30, 441-3, 491-3 third party information 341, 418 ticket 141, 144, 149, 162-8, 357, 360-2, 368, 398-401, 408 time constraints 76, 88 Time Field 168 Time Frame/Notes/Who 158, 160, 355, 357, 488, 510-11, 516, 520, 522, 526, 538, 542-3, 546, 552, 575, 577 time stamping 360-1, 398-9 time zones 306, 386 timeframe 33, 96, 103, 297, 307, 486, 489 Timely Incident resolution 235 timescales 53, 245, 476 title 338, 342, 414, 418-19 Tool Requirements‖ document 359, 396 tools 10, 12-13, 22-3, 25, 41-2, 50, 56, 85, 184-5, 187-8, 192, 221, 224, 358-69, 389, 396-409 [21] assessment 96, 190 automated 177, 377, 452, 585 common 262, 279 customer organization 391 event management 65 financial 115, 187, 312, 530 install 177, 377, 452, 584 knowledge management 65, 368, 408 network management 65 performance management 66 problem management 65 reporting 50, 66, 369, 409 selection of 177, 377, 452, 584 service desk 326, 457 service management 253 service performance monitoring 66 software test management 66
Page 610
Service Level Management Workbook workflow 49, 66 top 86-7, 158, 160, 357, 502 topics 130, 134, 136, 152, 156-7, 171, 324, 327, 331, 337, 350, 353-4, 358, 371, 395, 573-4 [19] Total number 367, 406, 427 trade secrets 342, 418-19 trademarks 5, 501 training 1, 10, 16, 20, 23, 52, 75-6, 79, 82, 147, 177, 323, 377, 390-1, 452-3, 584-5 [17] end-user 353, 433 transactions 29, 41, 74, 78, 545, 567 transition, orderly 346-7, 423-4 transition activities 346-7, 423-4 transition capabilities 11 Transition Plan 346-7, 423-4 Transition Planning and Support process 44 transition process support 44 transitioning 16, 18, 49 trial 85, 349, 427 types, particular 265, 280 U UC (Underpinning Contract) 4, 302, 392, 447, 459, 466, 493, 495, 505-7, 513, 518, 524, 542, 549, 551-4, 571-2 [1] UCs, see Underpinning Contract Underpinning Contract (UCs) 4, 61, 302, 392, 459, 461, 466, 480, 493, 496, 505-7, 542, 551-2, 554, 571-2, 575 Underpinning Contract, see UC Underpinning Contracts 4, 302, 392, 459, 466, 493, 505-6, 542, 551-2, 571-2 understanding Service Level Requirements 542 Unforgettable Customer Service 67-8 units 115, 185, 187, 312, 558, 562, 564, 567 Unscheduled Outages 142, 144, 147 update 74, 166, 168, 333-4, 343, 353, 420, 433, 490, 507 upgrade 220, 224, 297 urgency 25, 122, 133, 158-9, 165, 235, 240, 244-5, 274, 303, 360, 362, 398, 400 User Defined Array 166, 168 user documentation 560, 565 User Site 322 user time stamps 361, 399 users 132, 144-5, 155-6, 163-4, 166, 199-200, 210, 239-41, 273-4, 298-300, 360-1, 370, 3834, 398-9, 542-5, 559-60 [52] Using Incident and Problem analysis 265, 280 V vacancy announcement 95-6, 102-3 variation 19, 22, 471 VBF (Vital Business Function) 185, 301 vendor 144, 177, 224, 256, 292, 369-70, 377, 409-10, 452, 584 version 130, 133, 136, 139, 152, 157, 161, 169, 171, 324, 327, 330, 333, 337, 350, 354 [31] Version Control Information 490, 511, 519, 525, 541, 554 version numbers 225, 363, 365, 402, 404 vest 342, 418-19 vision 10, 14, 25, 43, 67, 185-6, 193, 288, 485-6, 530 Vision Statement 25, 529, 531 Vital Business Function (VBF) 185, 301 W warnings 20, 360, 366-7, 398, 405-6 Warranties 343-4, 420-1 weaknesses 13-14, 31, 99, 103, 501 Web Licences 21
Page 611
Service Level Management Workbook windows 294, 558-9 work, service desk 336 work-arounds 119-20, 235 Work environments 1, 75, 93, 100 Work Request 142-51 work space 339, 348, 415, 425 workaround 124, 173, 202, 204, 241, 259, 274, 298, 304 workbook 308, 379, 381, 384, 439, 458, 460 workers 74-80 gaming services 80 world 7, 106, 287-9, 292 www.theartofservice.com 308, 585
i
ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries
Page 612
