Support Center Complete Handbook - How to analyze, assess, manage and deliver customer business needs and exceed customer expectations with help desk, support center and service desk

Support Center – Managing and Analyzing Contents INTRODUCTION ...

Author: Ivanka Menken | Gerard Blokdijk

73 downloads 951 Views 6MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Resolve the Incident using the solution / Work-around or, alternatively, to raise an RFC (including a check for resolution)



Take recovery actions


The confirmation of the resolution with the Customer or originator



Update Incident details



Close Incident


Monitor Incidents



Escalate Incidents



Inform User Page 125


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


Page 128


Page 129


SUPPORTING DOCUMENTS Through the documents, look for text surrounded by > 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:


Version:

Page 133


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:


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


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


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


IT Services Incident Category Definition Status:


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


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


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


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


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 > and the Client a high level overview of the services that are being actioned by >. 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


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 > 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 > service delivery divisions. Category Type Definitions Category Types are a second level definition to that of Incident Types. This will enable > 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


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


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


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 >. 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 > 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


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 >. Customer Compliment Incident

Support

Work

Request

Request

Feedback

X Customer compliments in relation to products or services provided by >. 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


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


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 > and the client. Sales Incident

Support

Work

Request

Request

Feedback

X Any questions or information regarding Sales. Page 150


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




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:


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


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


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


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


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


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


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


 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


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


IT Services Incident Ticket Template Status:


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


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


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


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


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


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


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


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


IT Services Roles, Responsibilities Process: Incident Management Status:


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


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


Status:


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


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


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


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


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


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


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


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


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


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


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


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


GENERAL TERMS AND CONCEPTS

Page 183


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


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


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


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


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


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


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


(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


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


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


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


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




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




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 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


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




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


Page 201


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


Page 203


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


SUPPORT AND RESTORE

Service Desk

Page 205


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


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


Page 208


Page 209


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


Common structured interrogation technique: Providing a common structured dialogue to managing Customer requests is essential, no matter who in the support organization Page 211


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


Page 213


Page 214


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


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


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


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


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


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


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


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 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


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


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


Page 226


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


Page 228


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


Incident Management

Page 230


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


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


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


Page 234


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


Page 236


Page 237


Most SW vendors (HP, BMC, Infra, Goldmine) have applied ITIL flavour to their tools. This assists in linking to CMDB, SLAs etc… Page 238


Self help and self logging by users is also recommended for efficiency and effectiveness of the Incident Management process.

Page 239


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


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


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


Page 243


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


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


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


Problem Management

Page 247


Page 248


Page 249


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


Page 251




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


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


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


Page 255


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


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


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


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


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


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


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


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


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


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


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


Page 267


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




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.


Page 269


SERVICE DESK – REVIEW

Page 270


Page 271


Page 272


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


 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


This slide acknowledges that there will be issues. There always will be – to think otherwise is naïve.

Page 275


Page 276



Page 277


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


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


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




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


Page 282


Page 283


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


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?















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


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?















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


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


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


 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


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


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


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


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


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 - 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


a major problem review in order to improve the IT department‘s delivery and support of the STOCK system.

Page 296


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


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


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


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


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


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


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


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


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


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


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


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






Policies Objectives and Scope






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 > 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:


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:


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:


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:


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 > 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: > 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: > OR Completion of the Service Desk will be: > 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 / > and IT. If you have any questions regarding this, please do not hesitate to contact me on > >

BUSINESS AND IT FLYERS OUTSOURCING TEMPLATE

IT Services Outsourcing Template Service Desk Page 336

Status:


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


Oversee the registration and resolution of incidents to ensure that the business needs of IT are not impacted more than necessary.




(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:


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


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 these are indicators for you to create some specific text. Watch also for highlighted text which provides further guidance and instructions.


IT Services Detailed Objectives/Goals Process: Service Level Management Status:


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


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.


Page 488


(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


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:


Version:

Release Date:

Page 490


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


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:


Scope Statement The area covered by a given activity or subject

Page 492


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:


IT Services Scope Document Process: Service Level Management Status:


Page 493


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


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


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: > The definition of an OLA is: > The definition of a UC is: > 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


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

> 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


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


Appendices Include any applicable appendixes that are needed. Terminology Make sure that all terminology is captured and documented correctly.


IT Services Business Justification Process: Service Level Management Status:


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


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


―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


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


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


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


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


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




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:


Version:

Release Date:

Detailed responsibilities of the Service Level Management process owner The Service Level Manager….. Page 506


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


Process: Service Level Management Status:


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 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


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)


Page 510


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.


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


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‖)


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.


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


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


Status:


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:


Page 515


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


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


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



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







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.








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






UC Cross references





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


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).


Multi Level SLA’s

IT Services Multi-Level Based SLA Process: Service Level Management Status:


Page 520


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


Areas to address

Comments/Examples



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


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


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.


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







Here we document the agreed Page 523

Service Level Management Workbook response time for the different priority levels set.


Consider marginally longer support hours (if less than 24) Maximum number of accepted outages. Minimum percentage availability. Maximum number of errors or reruns.








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






UC Cross references





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


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


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: 








Amendment History Issue

Date

Amendments

Completed By


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


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


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


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


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

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


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. > 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


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


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

>

Very High

Admin

>

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


Status:


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


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?


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.


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:


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).


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


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.


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).


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)


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)



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)?


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?


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)


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.


In this section you can describe any technical


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:


Version:

Page 547


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


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




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: > The definition of an OLA is: > The definition of a UC is: > The definition of a service is: > 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


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


Underpinning Contracts

IT Services Underpinning Contracts Process: Service Level Management Status:


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


(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


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)


UC Charging policy (reflected in parent SLA)


UC Metrics for performance (reflected in parent SLA)


UC Cross references

Reference number to other closely coupled UCs Page 553




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.


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


Status:


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: 









Date

Amendments

Completed By


Stakeholders

IT

Introduction Page 555


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: 




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: 











Executive Overview Describe the purpose, scope and organization of the Functional Specification document.

Service Overview Service Description Page 556


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


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


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


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: <service name> Status:


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: 









Date

Amendments

Completed By


Stakeholders

IT Page 561


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: 




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: 











Executive Overview Describe the purpose, scope and organization of the Technical Specification document. Page 562


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


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


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:


Version:

Release Date:

Page 565


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


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


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


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.




(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


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


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


Reports KPI’s Other Metrics

IT Services Reports and KPI Targets Process: Service Level Management Status:


Version:

Release Date:

Note: SEARCH AND REPLACE

Reports and KPI Targets for Servicename>> Level Management

Support Center Complete Handbook - How to analyze, assess, manage and deliver customer business needs and exceed customer expectations with help desk, support center and service desk

Help Desk 100 Success Secrets - Helpdesk Need to Know topics covering Help desk jobs, Help desk software, computer Help desk, Help desk support, Helpdesk jobs, IT Help desk and Much more

Customer Fraud and Business Responses

Data Mining Techniques: For Marketing, Sales, and Customer Support

Data Mining Techniques. For Marketing, Sales, and Customer Support

Wake Up Your Call Center: How to Be a Better Call Center Agent (Customer Access Management)

May I Help You?: Great Customer Service for Small Business

Secret Service: Hidden Systems That Deliver Unforgettable Customer Service

Customer Service For Dummies

ITIL Practitioner Support and Restore (IPSR) All-in-one Help Desk Exam Guide and Certification Work book; Define, Implement, Manage and Review Service ... Incident Management and Problem Management

Customer Care Excellence: How to Create an Effective Customer Focus (Customer Care Excellence: How to Create an Effective Customer Care)

Photoshop CS2 Help Desk Book

Leo Laporte's PC Help Desk

Customer Care Excellence: How to Create an Effective Customer Focus

Call Center Handbook: The Complete Guide to Starting, Running and Improving Your Call Center

Unleashing Excellence: The Complete Guide to Ultimate Customer Service

Unleashing Excellence: The Complete Guide to Ultimate Customer Service

Deliver outstanding customer service: gain and retain customers and stay ahead of the competition

Support and Strike!

Front and Center

Management: Meeting and Exceeding Customer Expectations, 9th Edition

Research and Information Center

Front and Center

The Seven Myths of Customer Management: How to be Customer-Driven Without Being Customer-Led

Inside the Customer Universe: How to Build Unique Customer Insight for Profitable Growth and Market Leadership

Blogging to Drive Business: Create and Maintain Valuable Customer Connections

The Story Biz Handbook: How to Manage Your Storytelling Career from the Desk to the Stage

The Story Biz Handbook: How to Manage Your Storytelling Career from the Desk to the Stage

Intermediate Accounting , 10th Edition (with Business and Company Resource Center)

The CRM Handbook: A Business Guide to Customer Relationship Management

Support Center Complete Handbook - How to analyze, assess, manage and deliver customer business needs and exceed customer expectations with help desk, support center and service desk

Help Desk 100 Success Secrets - Helpdesk Need to Know topics covering Help desk jobs, Help desk software, computer Help desk, Help desk support, Helpdesk jobs, IT Help desk and Much more

Customer Fraud and Business Responses

Data Mining Techniques: For Marketing, Sales, and Customer Support

Data Mining Techniques. For Marketing, Sales, and Customer Support

Wake Up Your Call Center: How to Be a Better Call Center Agent (Customer Access Management)

May I Help You?: Great Customer Service for Small Business

Secret Service: Hidden Systems That Deliver Unforgettable Customer Service

Customer Service For Dummies

ITIL Practitioner Support and Restore (IPSR) All-in-one Help Desk Exam Guide and Certification Work book; Define, Implement, Manage and Review Service ... Incident Management and Problem Management

Customer Care Excellence: How to Create an Effective Customer Focus (Customer Care Excellence: How to Create an Effective Customer Care)

Photoshop CS2 Help Desk Book

Leo Laporte's PC Help Desk

Customer Care Excellence: How to Create an Effective Customer Focus

Call Center Handbook: The Complete Guide to Starting, Running and Improving Your Call Center

Unleashing Excellence: The Complete Guide to Ultimate Customer Service

Unleashing Excellence: The Complete Guide to Ultimate Customer Service

Deliver outstanding customer service: gain and retain customers and stay ahead of the competition

Support and Strike!

Front and Center

Management: Meeting and Exceeding Customer Expectations, 9th Edition

Research and Information Center

Front and Center

The Seven Myths of Customer Management: How to be Customer-Driven Without Being Customer-Led

Inside the Customer Universe: How to Build Unique Customer Insight for Profitable Growth and Market Leadership

Blogging to Drive Business: Create and Maintain Valuable Customer Connections

The Story Biz Handbook: How to Manage Your Storytelling Career from the Desk to the Stage

The Story Biz Handbook: How to Manage Your Storytelling Career from the Desk to the Stage

Intermediate Accounting , 10th Edition (with Business and Company Resource Center)

The CRM Handbook: A Business Guide to Customer Relationship Management

Recommend Documents