the official introduction to the itil service lifecycle · the official introduction to the itil...

The Official Introduction to the ITILService Lifecycle

London: TSO

7238-TSO-ITIL-13 28/8/07 14:01 Page i

Published by TSO (The Stationery Office) and available from:

Online www.tsoshop.co.uk

Mail,Telephone, Fax & E-mailTSOPO Box 29, Norwich NR3 1GNTelephone orders/General enquiries: 0870 600 5522Fax orders: 0870 600 5533E-mail: [email protected]: 0870 240 3701

TSO Shops16 Arthur Street, Belfast BT1 4GD028 9023 8451 Fax 028 9023 540171 Lothian Road, Edinburgh EH3 9AZ0870 606 5566 Fax 0870 606 5588

TSO@Blackwell and other Accredited Agents

Published with the permission of the Office of Government Commerce on behalf of the Controller of Her Majesty’s Stationery Office.

© Crown Copyright 2007

This is a Crown copyright value added product, reuse of which requires a Click-Use Licence for value added material issued by OPSI.

Applications to reuse, reproduce or republish material in this publication should be sent to OPSI, Information Policy Team, St Clements House, 2-16 Colegate,Norwich, NR3 1BQ, Tel No (01603) 621000 Fax No (01603) 723000, E-mail: [email protected] , or complete the application form onthe OPSI website http://www.opsi.gov.uk/click-use/value-added-licence-information/index.htm

OPSI, in consultation with Office of Government Commerce (OGC), may then prepare a Value Added Licence based on standard terms tailored to yourparticular requirements including payment terms

The OGC logo ® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countriesThe swirl logo ™ is a Trade Mark of the Office of Government Commerce

First published 2007

ISBN 9780113310616

Printed in the United Kingdom for The Stationery Office

N5635491 c60 08/07

7238-TSO-ITIL-13 28/8/07 14:01 Page ii

List of figures vi

List of tables viii

OGC’s foreword ix

Chief Architect’s foreword x

Preface xi

1 Introduction 1

1.1 A historical perspective of IT servicemanagement and ITIL 3

1.2 ITIL today 3

1.3 The ITIL value proposition 4

1.4 The ITIL service management practices 4

1.5 What is a service? 5

1.6 Navigating the ITIL ServiceManagement Lifecycle 5

2 Core guidance topics 9

2.1 Service Strategy 11

2.2 Service Design 11

2.3 Service Transition 12

2.4 Service Operation 12

2.5 Continual Service Improvement 12

2.6 Lifecycle quality control 13

2.7 ITIL conformance or compliance – practiceadaptation 13

2.8 Getting started – Service Lifecycle principles 14

3 The ITIL Service ManagementLifecycle – core of practice 17

3.1 Functions and Processes across the lifecycle 20

4 Service Strategy – governance anddecision-making 23

4.1 Strategic assessment 25

4.2 Developing strategic capabilities 27

4.3 Service Provider types – matching need to capability 27

4.4 Services as assets – value creation 28

4.5 Defining the market space 29

4.6 Service Portfolios 30

4.7 Service outsourcing – practicaldecision-making 33

4.8 Return on investment (ROI) 35

4.9 Financial Management 36

4.10 Increasing service potential 38

4.11 Organizational development 39

| iii

Contents

7238-TSO-ITIL-13 28/8/07 14:01 Page iii

5 Service Design – building structuralservice integrity 43

5.1 Business value 46

5.2 Five aspects of Service Design 46

5.3 Identifying service requirements 47

5.4 Service Design models 48

5.5 Delivery model options 49

5.6 Service Catalogue Management 50

5.7 Service Level Management 52

5.8 Capacity Management 55

5.9 Availability Management 60

5.10 IT Service Continuity Management 64

5.11 Information Security Management 66

5.12 Supplier Management 70

6 Service Transition – preparing forchange 73

6.1 Transition Planning and Support 76

6.2 Change Management 80

6.3 Asset and Configuration Management 83

6.4 Release and Deployment Management 86

6.5 Service Validation and Testing Releases 88

7 Service Operation 91

7.1 Business value 94

7.2 Event Management 94

7.3 Incident Management 96

7.4 Request Fulfilment 99

7.5 Problem Management 101

7.6 Access Management 105

7.7 Service Operation functions 106

7.8 IT Operations Management 116

7.9 Application Management 117

7.10 Service Operation and project management 121

7.11 Assessing and managing risk inService Operation 122

7.12 Operational staff in Service Designand Transition 122

8 Continual Service Improvement 125

8.1 Purpose of CSI 125

8.2 CSI objectives 126

8.3 Business drivers 128

8.4 Technology drivers 128

8.5 Service measurement 129

8.6 Continual Service Improvement processes 129

8.7 Service reporting 140

iv | Contents

7238-TSO-ITIL-13 28/8/07 14:01 Page iv

9 Complementary guidance 145

9.1 ITIL and other frameworks, practicesand standards 145

10 The ITIL Service Management Model 149

10.1 Model element types 149

10.2 Basic elements 151

10.3 Creating a service 155

10.4 Strategy generation 155

10.5 Deciding the course of action tocreate a new service 158

Acronyms 173

Glossary 177

Index 227

Contents | v

7238-TSO-ITIL-13 28/8/07 14:01 Page v

Figure 2.1 The Deming Quality Cycle

Figure 3.1 The ITIL Service Lifecycle

Figure 3.2 Process architecture

Figure 3.3 Continual feedback loop

Figure 4.1 Service Provider capabilities and resources

Figure 4.2 Actionable components of service definitionsin terms of utility

Figure 4.3 Service Portfolio

Figure 4.4 Elements of a Service Portfolio and ServiceCatalogue

Figure 4.5 Service Portfolio management

Figure 4.6 Business impact and ROI outcome

Figure 5.1 Design dependencies

Figure 5.2 Service Catalogue elements

Figure 5.3 The Service Level Management process

Figure 5.4 Component-based Service Level Package

Figure 5.5 Capacity Management elements

Figure 5.6 The Availability Management process

Figure 5.7 Relationship between levels of availabilityand overall costs

Figure 5.8 Service Continuity lifecycle

Figure 5.9 IT Security Management process

Figure 5.10 Supplier Management – roles and interfaces

Figure 6.1 The Service Transition process

Figure 6.2 Normal Change Model

Figure 6.3 Service Asset and ConfigurationManagement – interfaces to the lifecycle

Figure 6.4 Example of a release package

Figure 6.5 Service testing and validation

Figure 7.1 The Event Management process

Figure 7.2 The Incident Management process flow

Figure 7.3 The Problem Management process flow

Figure 7.4 Single monitor control loop

Figure 7.5 Complex monitor control loop

Figure 7.6 ITSM monitor control loop

Figure 7.7 Role of Application Management in theapplication lifecycle

Figure 8.1 Continual Service Improvement model

Figure 8.2 Seven-step Improvement Process

Figure 8.3 Number of incident tickets opened over time

Figure 8.4 Service reporting process

Figure 10.1 Service Management Model element types

Figure 10.2 Service Lifecycle governance and operationalelements

Figure 10.3 Typical Type I Service Provider interactions

Figure 10.4 Type II Service Provider interactions

Figure 10.5 Type III Service Provider interactions

Figure 10.6 Basic Service Management Model processelements

vi |

List of figures

7238-TSO-ITIL-13 28/8/07 14:01 Page vi

Figure 10.7 ITIL Service Lifecycle main practice elements

Figure 10.8 Forming and formulating a Service Strategy

Figure 10.9 The Service Portfolio

Figure 10.10 Stage 1 – Service Strategy elements

Figure 10.11 Stage 2 – Design service solution

Figure 10.12 Stage 3 – Transition the service

Figure 10.13 Change Management elements

Figure 10.14 Normal Change Management process

Figure 10.15 Information flows at the Service Transitionstage

Figure 10.16 Stage 4 – Operate the service



Figure 10.19 Information flow in the Service Operationstage

Figure 10.20 Stage 5 – Continual Service Improvement

Figure 10.21 Information flow within Continual ServiceImprovement

Figure 10.22 Integrated lifecycle elements flow

Figure 10.23 Layered view of the main elements in theService Lifecycle

List of figures | vii

7238-TSO-ITIL-13 28/8/07 14:01 Page vii

Table 2.1 Roles and core guides

Table 4.1 Factors in strategic assessment

Table 4.2 Types of sourcing structures

Table 4.3 Example of increased Service Potential

Table 4.4 Basic organizational structures for types ofservice strategies

Table 5.1 Delivery model options

Table 8.1 Service metric examples

viii |

List of tables

7238-TSO-ITIL-13 28/8/07 14:01 Page viii

As co-founder of the ITIL concept and leader of its earlydevelopment, I’m delighted by the positive impact it hasmade on companies and organizations around the world.What began as a UK government initiative to set out anefficient, successful and reliable approach to servicemanagement is now a global endeavour, withpublications, training and support tools available in variouslanguages. Of course, successful growth doesn’t happenby chance and ITIL has proven itself many times overthrough the benefits it brings to the businesses thatembed its practices.

Since its creation in the late 1980s, ITIL has beendeveloped to keep up to date with a constantly changingservice management environment. Here in the latestversion, I am pleased to see a top-quality product.Consultation with experts on a global scale brings youleading practices, identified through experience andbrought together with the skills and expertise of ourpublishing partner, The Stationery Office (TSO).

I believe ITIL will continue to play an important role withingovernment as an effective standard framework fordelivery. However, the real value in ITIL is that its benefitsare available to every organization, large or small, with agenuine desire to deliver a high-performing serviceprovision. May your organization be one of those!

John StewartOffice of Government Commerce

| ix

OGC’s foreword

7238-TSO-ITIL-13 28/8/07 14:01 Page ix

This book is dedicated to the people who practise ITservice management. Through their knowledge andexperiences we have shaped the present and can seefurther toward the future along our journey to serviceexcellence.

Over the past two decades the world of IT has changeddramatically. The IT Infrastructure Library framework hasgrown along with it and has shaped a community ofpractice that has spawned an entire industry. What hasn’tchanged in all that time is the need for us as practitionersof service management to learn how best practices evolveand how they support and influence the customer’ssuccesses or failures.

In a world of growing complexity, choice and globalization,ITIL has remained at the heart of the industry, growing andevolving to meet the needs of service providers. Thecurrent version of ITIL is a product of this evolution.

Within the pages of this book, we will introduce ITIL to thenovice, further educate the practitioner and transform ourunderstanding of IT service management best practices.

This book captures the basic concepts of the ITIL ServiceLifecycle and its benefits. It serves as a reference to ITILservice management practices, but should not beconsidered a substitute for the ITIL core practice set.

It is from here we begin the journey into the ITIL servicemanagement practices.

Sharon TaylorChief Architect, ITIL Service Management Practices

x |

Chief Architect’s foreword

7238-TSO-ITIL-13 28/8/07 14:01 Page x

Life-cycle (noun) – The various stages through which aliving thing passes (Kernerman English MultilingualDictionary)

The very term ‘lifecycle’ is used to describe the evolutionof many living things in this world from their creation toexpiration. The time between creation and expiration isthe ‘journey’.

We need only look at our own life journeys to see a livingexample.

Creation – the first part of our journey. As an embryodevelops, its life blueprint is being established through thearchitecture of its DNA. The embryo’s genetic structure willdictate its capability, propensity for immunity orvulnerability to disease, and certain personalitycharacteristics it will carry throughout life.

Childhood – the formative stage. We are influenced by ourexposure to the world around us and can influence ourlife blueprint in how we manifest and integrate ourselveswith the world around us. Our understanding of ourneeds, both for growth and creativity, are our‘requirements’ that allow us to create value for ourselvesand those who come into contact with us.

Adulthood – where we hone our skills and perform withinexpected societal parameters. We strive to improve ourcapabilities continually and define our value. By this time,we have built a complex network of relationships anddependencies to others. The world we live in has becomefar more complex than in childhood and managing ourlives more challenging.

If you replace the human metaphor above with thelifecycle of service management, you will see manysimilarities. This is because the ITIL Service Lifecyclerepresents the same evolution – from creation toexpiration – and the stages in the ITIL Service Lifecycle arewhat fall in between.

We often forget that services are living things. Theyrequire sustenance to survive, they must continually adaptand evolve with changing needs of the business, and theywill pass through various stages over their lifetime.

Services are constrained by their genetic blueprint – risks,financial investment, culture and economics – but shouldevolve to influence their value through interaction,evolution, dependencies and relationships, and to exploitthese for positive outcomes.

This book will take you through these Service Lifecyclestages and show how to apply the knowledge containedin the ITIL core lifecycle publications.

| xi

Preface

7238-TSO-ITIL-13 28/8/07 14:01 Page xi

7238-TSO-ITIL-13 28/8/07 14:01 Page xii

Introduction 1

7238-TSO-ITIL-13 28/8/07 14:01 Page 1

7238-TSO-ITIL-13 28/8/07 14:01 Page 2

1.1 A HISTORICAL PERSPECTIVE OF ITSERVICE MANAGEMENT AND ITIL

IT service management (ITSM) evolved naturally as servicesbecame underpinned in time by the developingtechnology. In its early years, IT was mainly focused onapplication development – all the new possibilitiesseeming to be ends in themselves. Harnessing theapparent benefits of these new technologies meantconcentrating on delivering the created applications as apart of a larger service offering, supporting the businessitself.

During the 1980s, as the practice of service managementgrew, so too did the dependency of the business. Meetingthe business need called for a more radical refocus for anIT service approach and the ‘IT help desk’ emerged to dealwith the frequency of issues suffered by those trying touse IT services in delivery of their business.

At the same time, the UK government, fuelled by a needfor finding efficiencies, set out to document how the bestand most successful organizations approached servicemanagement. By the late 1980s and early 1990s, they hadproduced a series of books documenting an approach tothe IT service management needed to support businessusers. This library of practice was entitled the ITInfrastructure Library – ITIL to its friends.

The original Library grew to over 40 books, and started achain reaction of interest in the UK IT service community.The term ‘IT service management’ had not been coined atthis point, but became a common term around the mid1990s as the popularity of ITIL grew. In 1991, a user forum,the IT Information Management Forum (ITIMF), wascreated to bring ITIL users together to exchange ideas andlearn from each other, and would eventually change itsname to the IT Service Management Forum (itSMF). Today,

the itSMF has members worldwide as ITIL’s popularitycontinues to grow.

A formal standard for ITSM, The British Standard 15000,largely based on ITIL practices, was established andfollowed by various national standards in numerouscountries. Since then the ISO 20000:2005 Standard wasintroduced and gained rapid recognition globally.

ITIL’s next revision began in the mid 1990s, until 2004.Version 2 of ITIL, as it is commonly referred to, was a moretargeted product – with nine books – explicitly bridgingthe gap between technology and business, and withguidance focused strongly on the processes required todeliver effective services to the business customer.

1.2 ITIL TODAY

In 2004, the OGC began the second major refresh initiativeof ITIL, in recognition of the massive advancements intechnology and emerging challenges for IT serviceproviders. New technology architectures, virtualization andoutsourcing became a mainstay of IT and the process-based approach of ITIL needed to be revamped to addressservice management challenges.

After twenty years ITIL remains the most recognizedframework for ITSM in the world. While it has evolved andchanged its breadth and depth, it preserves thefundamental concepts of leading practice.

1.2.1 Why is ITIL so successful?ITIL is intentionally composed of a common senseapproach to service management – do what works. Andwhat works is adapting a common framework of practicesthat unite all areas of IT service provision toward a singleaim – delivering value to the business. The following list

| 3

1 Introduction

7238-TSO-ITIL-13 28/8/07 14:01 Page 3

defines the key characteristics of ITIL that contribute to itsglobal success:

� Non-proprietary – ITIL service management practicesare applicable in any IT organization because they arenot based on any particular technology platform, orindustry type. ITIL is owned by the UK government andnot tied to any commercial proprietary practice orsolution

� Non-prescriptive – ITIL offers robust, mature andtime-tested practices that have applicability to all typesof service organizations. It continues to be useful andrelevant in public and private sectors, internal andexternal service providers, small, medium and largeenterprise, and within any technical environment

� Best practice – ITIL service management practicesrepresent the learning experiences and thoughtleadership of the world’s best in class service providers

� Good practice – Not every practice in ITIL can beconsidered ‘best practice’, and for good reason. Formany, a blend of common, good and best practicesare what give meaning and achievability to ITSM. Insome respects, best practices are the flavour of theday. All best practices become common practices overtime, being replaced by new best practices.

1.3 THE ITIL VALUE PROPOSITION

All high-performing service providers share similarcharacteristics. This is not coincidence. There are specificcapabilities inherent in their success that they demonstrateconsistently. A core capability is their strategy. If you wereto ask a high-achieving service provider what makes themdistinctive from their competitors, they would tell you thatit is their intrinsic understanding of how they providevalue to their customers. They understand the customer’sbusiness objectives and the role they play in enablingthose objectives to be met. A closer look would reveal thattheir ability to do this does not come from reacting to

customer needs, but from predicting them throughpreparation, analysis and examining customer usagepatterns.

The next significant characteristic is the systematic use ofservice management practices that are responsive,consistent and measurable, and define the provider’squality in the eyes of their customers. These practicesprovide stability and predictability, and permeate theservice provider’s culture.

The final characteristic is the provider’s ability tocontinuously analyse and fine tune service provision tomaintain stable, reliable yet adaptive and responsiveservices that allow the customer to focus on their businesswithout concern for IT service reliability.

In these situations you see a trusted partnership betweenthe customer and the service provider. They share risk andreward and evolve together. Each knows they play a rolein the success of the other.

As a service provider, this is what you want to achieve. Asa customer, this is what you want in a service provider.

Take a moment look around at the industry high-performing service providers. You’ll see that most use ITILService Management practices. This isn’t coincidence at all.

1.4 THE ITIL SERVICE MANAGEMENTPRACTICES

When we turn on a water tap, we expect to see water flowfrom it. When we press down a light switch, we expect tosee light fill the room. Not so many years ago these verybasic things were not as reliable as they are today. Weknow instinctively that the advances in technology havemade them reliable enough to be considered a utility. Butit isn’t just the technology that makes the services reliable.It is how they are managed. This is service management!

4 | Introduction

7238-TSO-ITIL-13 28/8/07 14:01 Page 4

The use of IT today has become the utility of business.Simply having the best technology will not ensure itprovides utility-like reliability. Professional, responsive,value-driven service management is what brings thisquality of service to the business.

The objective of the ITIL Service Management practiceframework is to provide services to business customersthat are fit for purpose, stable and that are so reliable, thebusiness views them as a trusted utility.

ITIL offers best practice guidance applicable to all types oforganizations who provide services to a business. Eachpublication addresses capabilities having direct impact ona service provider’s performance. The structure of the corepractice takes form in a Service Lifecycle. It is iterative andmultidimensional. It ensures organizations are set up toleverage capabilities in one area for learning andimprovements in others. The core is expected to providestructure, stability and strength to service managementcapabilities with durable principles, methods and tools.This serves to protect investments and provide thenecessary basis for measurement, learning andimprovement.

The guidance in ITIL can be adapted for use in variousbusiness environments and organizational strategies. Thecomplementary guidance provides flexibility to implementthe core in a diverse range of environments. Practitionerscan select complementary guidance as needed to providetraction for the core in a given business context, much liketyres are selected based on the type of automobile,purpose and road conditions. This is to increase thedurability and portability of knowledge assets and toprotect investments in service management capabilities.

1.5 WHAT IS A SERVICE?

Service management is more than just a set of capabilities.It is also a professional practice supported by an extensivebody of knowledge, experience and skills. A global

community of individuals and organizations in the publicand private sectors fosters its growth and maturity. Formalschemes exist for the education, training and certificationof practising organizations, and individuals influence itsquality. Industry best practices, academic research andformal standards contribute to its intellectual capital anddraw from it.

The origins of service management are in traditionalservice businesses such as airlines, banks, hotels andphone companies. Its practice has grown with theadoption by IT organizations of a service-orientedapproach to managing IT applications, infrastructure andprocesses. Solutions to business problems and support forbusiness models, strategies and operations are increasinglyin the form of services. The popularity of shared servicesand outsourcing has contributed to the increase in thenumber of organizations who are service providers,including internal organizational units. This in turn hasstrengthened the practice of service management and atthe same time imposed greater challenges upon it.

Definition of a serviceA ‘service’ is a means of delivering value to customersby facilitating outcomes customers want to achievewithout the ownership of specific costs and risks.

There are a variety of contexts in which the definition ofa service can be expanded upon, but as a basicconcept, service is the means of delivering value, andno matter how your organization chooses to define aservice, this must be at the heart of what defines aservice.

1.6 NAVIGATING THE ITIL SERVICEMANAGEMENT LIFECYCLE

Before discussing the principles of ITIL servicemanagement practices, it is helpful to understand theoverall content structure and how topics areas are

Introduction | 5

7238-TSO-ITIL-13 28/8/07 14:01 Page 5

organized within each of the books that togethercomprise the practices.

The ITIL service management practices are comprised ofthree main sets of products and services:

� ITIL service management practices – core guidance

� ITIL service management practices – complementaryguidance

� ITIL web support services.

1.6.1 ITIL service management practices –core guidance

The core set consists of six publications:

� Introduction to ITIL Service Management Practices(this publication)

� Service Strategy

� Service Design

� Service Transition

� Service Operation

� Continual Service Improvement.

A common structure across all the core guidancepublications helps to easily find references betweenvolumes and where to look for similar guidance topicswithin each stage of the lifecycle:

Practice fundamentals

This section of each core publication sets out the businesscase argument of the need for viewing servicemanagement in a lifecycle context and an overview of thepractices in that stage of the lifecycle that contributes toit. It briefly outlines the context for the practices thatfollow and how they contribute to business value.

Practice principles

Practice principles are the policies and governance aspectsof that lifecycle stage that anchor the tactical processesand activities to achieving their objectives.

Lifecycle processes and activities

The Service Lifecycle stages rely on processes to executeeach element of the practice in a consistent, measurable,repeatable way. Each core publication identifies theprocesses it makes use of, how they integrate with theother stages of the lifecycle, and the activities needed tocarry them out.

Supporting organization structures and roles

Each publication identifies the organizational roles andresponsibilities that should be considered to manage theService Lifecycle. These roles are provided as a guidelineand can be combined to fit into a variety of organizationstructures. Suggestions for optimal organization structuresare also provided.

Technology considerations

ITIL service management practices gain momentum whenthe right type of technical automation is applied. Eachlifecycle publication makes recommendations on the areasto focus technology automation on, and the basicrequirements a service provider will want to considerwhen choosing service management tools.

Practice implementation

For organizations new to ITIL, or those wishing to improvetheir practice maturity and service capability, eachpublication outlines the best ways to implement the ITILService Lifecycle stage.

Challenges, risks and critical success factors

These are always present in any organization. Eachpublication highlights the common challenges, risks andsuccess factors that most organizations experience andhow to overcome them.

6 | Introduction

7238-TSO-ITIL-13 28/8/07 14:01 Page 6

Complementary guidance

There are many external methods, practices andframeworks that align well to ITIL practices. Eachpublication provides a list of these and how theyintegrate into the ITIL Service Lifecycle, when they areuseful and how.

Examples and templates

Each publication provides working templates andexamples of how the practices can be applied. They areprovided to help you capitalize on the industry experienceand expertise already in use. Each can be adapted withinyour particular organizational context.

1.6.2 ITIL service management practices –complementary guidance

This is a living library of publications with guidancespecific to industry sectors, organization types, operatingmodels and technology architectures. Each publicationsupports and enhances the guidance in the ITIL core.Publications in this category will be continually added tothe complementary library of practice and will containcontributions from the expert and user ITSM community.In this way, ITIL practices are illustrated in real-lifesituations and in a variety of contexts that add value andknowledge to your own ITIL practice.

1.6.3 ITIL web support servicesThese products are online, interactive services including aGlossary of Terms and Definitions, Interactive ServiceManagement Model, online subscriber services, casestudies, templates and ITIL Live® (www.itil-live-portal.com),an interactive expert knowledge centre where users canaccess time with ITSM experts to discuss questions andissues, and seek advice.

Introduction | 7

7238-TSO-ITIL-13 28/8/07 14:01 Page 7

7238-TSO-ITIL-13 28/8/07 14:01 Page 8

Core guidance topics 2

7238-TSO-ITIL-13 28/8/07 14:01 Page 9

7238-TSO-ITIL-13 28/8/07 14:01 Page 10

| 11

2.1 SERVICE STRATEGY

At the core of the Service Lifecycle is Service Strategy.

Service Strategy provides guidance on how to view servicemanagement not only as an organizational capability butas a strategic asset. Guidance is provided on the principlesunderpinning the practice of service management whichare useful for developing service management policies,guidelines and processes across the ITIL Service Lifecycle.

Topics covered in Service Strategy include thedevelopment of service markets, characteristics of internaland external provider types, service assets, the serviceportfolio and implementation of strategy through theService Lifecycle. Financial Management, DemandManagement, Organizational Development and StrategicRisks are among other major topics.

Organizations should use Service Strategy guidance to setobjectives and expectations of performance towards

serving customers and market spaces, and to identify,select and prioritize opportunities. Service Strategy isabout ensuring that organizations are in position tohandle the costs and risks associated with their serviceportfolios, and are set up not just for operationaleffectiveness but for distinctive performance.

Organizations already practicing ITIL use Service Strategyto guide a strategic review of their ITIL-based servicemanagement capabilities and to improve the alignmentbetween those capabilities and their business strategies.This ITIL volume encourages readers to stop and thinkabout why something is to be done before thinking ofhow.

2.2 SERVICE DESIGN

‘If you build it, they will come’ is a saying from a famous1989 Hollywood movie, Field of Dreams. But if you build itand it doesn’t provide value, they will soon leave!

For services to provide true value to the business, theymust be designed with the business objectives in mind.Service Design is the stage in the lifecycle that turnsService Strategy into the blueprint for delivering thebusiness objectives.

Service Design provides guidance for the design anddevelopment of services and service managementpractices. It covers design principles and methods forconverting strategic objectives into portfolios of servicesand service assets. The scope of Service Design is notlimited to new services. It includes the changes andimprovements necessary to increase or maintain value tocustomers over the lifecycle of services, the continuity ofservices, achievement of service levels, and conformanceto standards and regulations. It guides organizations on

ServiceDesign

ServiceOperation Service

Transition

ServiceStrategy

Continual ServiceImprovement

Continual Service

Improvem

ent Cont

inua

l Ser

vice

Impr

ovem

ent

ITIL

Complementary Publications

Web Support Services

2 Core guidance topics

7238-TSO-ITIL-13 28/8/07 14:01 Page 11

12 | Core guidance topics

how to develop design capabilities for servicemanagement.

Among the key topics in Service Design are ServiceCatalogue, Availability, Capacity, Continuity and ServiceLevel Management.

2.3 SERVICE TRANSITION

Transition [tran-zish-uhn] – Movement, passage, orchange from one position, state, stage, subject, concept,etc., to another; change: the transition from adolescenceto adulthood.

Service Transition provides guidance for the developmentand improvement of capabilities for transitioning new andchanged services into live service operation. Thispublication provides guidance on how the requirements ofService Strategy encoded in Service Design are effectivelyrealized in Service Operation while controlling the risks offailure and disruption.

The publication combines practices in Change,Configuration, Asset, Release and Deployment, Programmeand Risk Management and places them in the practicalcontext of service management. It provides guidance onmanaging the complexity related to changes to servicesand service management processes; preventing undesiredconsequences while allowing for innovation. Guidance isprovided on transferring the control of services betweencustomers and service providers.

Service Transition introduces the Service KnowledgeManagement System, which builds upon the current dataand information within Configuration, Capacity, KnownError, Definitive Media and Assets systems and broadensthe use of service information into knowledge capabilityfor decision and management of services.

2.4 SERVICE OPERATION

Service Operation embodies practices in the managementof the day-to-day operation of services. It includesguidance on achieving effectiveness and efficiency in thedelivery and support of services to ensure value for thecustomer and the service provider. Strategic objectives areultimately realized through Service Operation, thereforemaking it a critical capability. Guidance is provided onhow to maintain stability in service operations, allowingfor changes in design, scale, scope and service levels.Organizations are provided with detailed processguidelines, methods and tools for use in two major controlperspectives: reactive and proactive. Managers andpractitioners are provided with knowledge allowing themto make better decisions in areas such as managing theavailability of services, controlling demand, optimizingcapacity utilization, scheduling of operations and fixingproblems. Guidance is provided on supporting operationsthrough new models and architectures such as sharedservices, utility computing, web services and mobilecommerce.

Among the topics in this book are Event, Incident,Problem, Request, Application and Technical Managementpractices. This book discusses some of the newer industrypractices to manage virtual and service-orientedarchitectures.

2.5 CONTINUAL SERVICE IMPROVEMENT

Continual Service Improvement provides instrumentalguidance in creating and maintaining value for customersthrough better design, transition and operation of services.It combines principles, practices and methods from qualitymanagement, change management and capabilityimprovement. Organizations learn to realize incrementaland large-scale improvements in service quality,operational efficiency and business continuity. Guidance isprovided for linking improvement efforts and outcomes

7238-TSO-ITIL-13 28/8/07 14:01 Page 12

Core guidance topics | 13

with service strategy, design and transition. A closed-loopfeedback system, based on the Plan-Do-Check-Act (PDCA)model (see section 2.6), is established and capable ofreceiving inputs for improvements from any planningperspective.

Guidance on Service Measurement, demonstrating valuewith metrics, developing baselines and maturityassessments are among the key topics.

2.6 LIFECYCLE QUALITY CONTROL

Consistent with the structures adopted by high-performingbusinesses today and standards bodies around the world,the ITIL Service Lifecycle approach embraces and enhancesthe interpretation of the Deming Quality Cycle (Figure 2.1)of Plan-Do-Check-Act. You will see this quality cycle usedin the structure of the practices in each of the core guides.

The ITIL framework incorporates the Deming Quality Cycleby applying it to the Service Lifecycle stages. This helpsalign the practices of ITIL to the structure of externalpractices such as COBIT and ISO/IEC 20000.

2.7 ITIL CONFORMANCE OR COMPLIANCE –PRACTICE ADAPTATION

An important aspect of ITIL is the ‘open-source’ nature ofits practices. It is intended and strongly recommendedthat organizations adapt ITIL practices within their owncontext, and entrench their own best practices within anoverall Service Management framework.

For example, within Service Transition, ITIL provides aselection of Change Management models for standard,normal and emergency Changes. In many cases, thesemodels as described in Service Transition may be all youneed and they cover the range of possible change types in

Figure 2.1 The Deming Quality Cycle

Effective Quality Improvement

CHECK

PLANACT

DO

Time Scale

Mat

urity

Lev

el

Consolidation of the level reached

i.e. Baseline

BusinessIT

Alignment

Plan Project PlanDo ProjectCheck AuditAct New Actions

Continuous quality control and consolidation

7238-TSO-ITIL-13 28/8/07 14:01 Page 13

an organization. Within each model, a specific flow ofprocess and procedure is provided. If in your organization,more steps for an emergency change make sense to meetyour requirements and objectives, then you should adaptthese into the generic ITIL Change process flow. Doing sodoes not mean you no longer conform to ITIL. As long asthe main ITIL process steps, inputs and outputs areincluded and the objectives met, that is your best practiceand is fit for purpose in your organizational context.

ITIL is a framework an organization conforms to, notcomplies with. There is a major difference between thesetwo things and one that is often misunderstood.

Conformity allows flexibility in the adaptation of practiceswithin an organizational context while maintaining theoverall structure of the framework. Compliance is highlyspecific, often audited to a formal standard and theorganization’s practices must mimic externally definedpractices. There is a need for both within certain contexts,but a key to agile service management practices isknowing which, in what blend and in what contextconformance or compliance should apply.

Many organizations use ITIL as a means to achievecompliance with a formal, audited standard such asISO/IEC 20000:2005. The design of ITIL is particularlyuseful for this purpose since the framework is architectedto ensure that an organization’s service capabilities aredesigned and operated using the practices that align tothese standards.

This standard set outs the key areas of compliance andrequires that organizations can demonstrate that they usethe management systems and practices in these areas inorder to be compliant to the standard. Experts agree thatadopting ITIL produces a framework best suited toachieving ISO/IEC 20000 certification. Later in this book alist of common external frameworks, method andstandards are provided that have a solid alignment to the

practices of ITIL and fit well into any organization’s servicepractices.

2.8 GETTING STARTED – SERVICE LIFECYCLEPRINCIPLES

In the following chapters you will learn about the keyconcepts within the ITIL Service Lifecycle. You begin byworking your way from the core of the lifecycle, ServiceStrategy, then around the revolving lifecycle practices ofService Design, Transition and Operation, finishing withContinual Service Improvement. Afterward, you shouldhave a clear understanding of the basic concepts of theITIL Service Lifecycle and how the core practicepublications can be useful to you. This will help readers tofurther examine particular areas within any of the coreguidance books that offer detailed practice information inareas that support your day-to-day service managementrole.

The following table gives a general view of some of themore common roles in organizations and the ITIL servicemanagement practice core guides that host the day-to-daypractices, processes and activities most related to thoseroles.

14 | Core guidance topics

7238-TSO-ITIL-13 28/8/07 14:01 Page 14

Core guidance topics | 15

Table 2.1 Roles and core guides

Role Core guide

Service Desk Manager/staff Service Operation

Incident Manager/Technical Support staff Service Transition and Service Operation

Operations Management Service Transition and Service Operation

Change Manager/Change Requestor Service Transition

Solution Development Service Design

Testing/Production Assurance Service Transition and Service Operation

Service Level Manager All core publications

Application/Infrastructure Architect All core publications

Supplier Relationship Management Service Design

IT Steering/Governance Service Strategy, Service Design

CIO/IT Director All core publications

IT Service Manager All core publications

Portfolio Manager All core publications

NOTE: It is extremely important to reiterate that no one core book exists in isolation, just as no one part of service management practice does.

Organizations interested in adopting ITIL or further maturing their current ITIL practice must consider the lifecycle in its entirety and the benefit

all five of the core books provide. Just as this Introduction book is not a substitute for the core library, one core guide alone is not sufficient to

adopt and use the practices to their full potential.

7238-TSO-ITIL-13 28/8/07 14:01 Page 15

7238-TSO-ITIL-13 28/8/07 14:01 Page 16

The ITIL ServiceManagement Lifecycle –

core of practice 3

7238-TSO-ITIL-13 28/8/07 14:01 Page 17

7238-TSO-ITIL-13 28/8/07 14:01 Page 18

| 19

The Service Lifecycle contains five elements as shown inFigure 3.1, each of which rely on service principles,processes, roles and performance measures. The ServiceLifecycle uses a hub and spoke design, with ServiceStrategy at the hub, Service Design, Transition andOperation as the revolving lifecycle stages, and anchoredby Continual Service Improvement. Each part of thelifecycle exerts influence on the other and relies on theother for inputs and feedback. In this way, a constant setof checks and balances throughout the Service Lifecycle

ensures that as business demand changes with businessneed, the services can adapt and respond effectively tothem.

At the heart of the Service Lifecycle is the key principle –all services must provide measurable value to businessobjectives and outcomes. ITIL Service Management focuseson business value as its prime objective. Each practicerevolves around ensuring that everything a serviceprovider does to manage IT services for the business

3 The ITIL Service Management Lifecycle –core of practice

Figure 3.1 The ITIL Service Lifecycle

Service Strategy

ContinualService Improvement

ServiceTransition

ServiceDesign

ServiceOperation

7238-TSO-ITIL-13 28/8/07 14:01 Page 19

20 | The ITIL Service Management Lifecycle – core of practice

customer can be measured and quantified in terms ofbusiness value. This has become extremely importanttoday as IT organizations must operate themselves asbusinesses in order to demonstrate a clear return oninvestment and equate service performance with businessvalue to the customer.

3.1 FUNCTIONS AND PROCESSES ACROSSTHE LIFECYCLE

3.1.1 FunctionsFunctions are units of organizations specialized to performcertain types of work and responsible for specificoutcomes. They are self-contained with capabilities andresources necessary to their performance and outcomes.Capabilities include work methods internal to thefunctions. Functions have their own body of knowledge,which accumulates from experience. They providestructure and stability to organizations.

Functions typically define roles and the associated authorityand responsibility for a specific performance and outcomes.Coordination between functions through shared processesis a common pattern in organization design. Functions tendto optimize their work methods locally to focus on assignedoutcomes. Poor coordination between functions combinedwith an inward focus leads to functional silos that hinderalignment and feedback critical to the success of theorganization as a whole. Process models help avoid thisproblem with functional hierarchies by improving cross-functional coordination and control. Well-defined processescan improve productivity within and across functions.

3.1.2 ProcessesProcesses are examples of closed-loop systems becausethey provide change and transformation towards a goal,and use feedback for self-reinforcing and self-correctiveaction (Figure 3.2). It is important to consider the entireprocess or how one process fits into another.

Figure 3.2 Process architecture

Data,informationandknowledge

Desiredoutcome

Service control and quality

Process

Trigger

Activity 1

Customer

Suppliers

Activity 2

Activity 3

7238-TSO-ITIL-13 28/8/07 14:01 Page 20

The ITIL Service Management Lifecycle – core of practice | 21

Process definitions describe actions, dependencies andsequence. Processes have the following characteristics:

� They are measurable and are performance driven.Managers want to measure cost, quality and othervariables while practitioners are concerned withduration and productivity.

� They have specific results. The reason a process existsis to deliver a specific result. This result must beindividually identifiable and countable.

� They deliver to customers. Every process delivers itsprimary results to a customer or stakeholder. They maybe internal or external to the organization but theprocess must meet their expectations.

� They respond to a specific event. While a process maybe ongoing or iterative, it should be traceable to aspecific trigger.

3.1.3 Specialization and coordination acrossthe lifecycle

Specialization and coordination are necessary in thelifecycle approach. Feedback and control between thefunctions and processes within and across the elements ofthe lifecycle make this possible. The dominant pattern inthe lifecycle is the sequential progress starting fromService Strategy (SS) through Service Delivery (SD) –Service Transition (ST) – Service Operation (SO) and backto SS through Continual Service Improvement (CSI). That,however, is not the only pattern of action. Every elementof the lifecycle provides points for feedback and control.

The combination of multiple perspectives allows greaterflexibility and control across environments and situations.The lifecycle approach mimics the reality of mostorganizations where effective management requires theuse of multiple control perspectives. Those responsible forthe design, development and improvement of processesfor service management can adopt a process-basedcontrol perspective. For those responsible for managingagreements, contracts and services may be better servedby a lifecycle-based control perspective with distinctphases. Both these control perspectives benefit fromsystems thinking. Each control perspective can revealpatterns that may not be apparent from the other.

3.1.4 Feedback throughout the ServiceLifecycle

The strength of the ITIL Service Lifecycle rests uponcontinual feedback throughout each stage of the lifecycle.This feedback ensures that service optimization ismanaged from a business perspective and is measured interms of the value business derives from services at anypoint in time through the Service Lifecycle. The ITILService Lifecycle is non-linear in design. At every point inthe Service Lifecycle, monitoring, assessment and feedbackflows between each stage of the lifecycle which drivedecisions about the need for minor course corrections ormajor service improvement initiatives. The following figureillustrates some examples of the continual feedbacksystem built into the ITIL Service Lifecycle.

7238-TSO-ITIL-13 28/8/07 14:01 Page 21

22 | The ITIL Service Management Lifecycle – core of practice

Figure 3.3 Continual feedback loop

FeedbackLessons Learnedfor Improvement


Output

Output

Output




Service Strategies

Strategies, Policies,Standards

Service Design

Plans to create and modifyservices and service

management processes

Service TransitionManage the transition of anew or changed service

and/or service managementprocess into production

Service Operation

Day-to-day operations ofservices and service

management processes

Continual Service ImprovementActivities are embedded in the service lifecycle

7238-TSO-ITIL-13 28/8/07 14:01 Page 22

Service Strategy –governance anddecision-making 4

7238-TSO-ITIL-13 28/8/07 14:01 Page 23

7238-TSO-ITIL-13 28/8/07 14:01 Page 24

| 25

As the core of the ITIL Service Lifecycle, Service Strategysets the stage for developing a service provider’s corecapabilities. This chapter will discuss a selection of the keyconcepts from the Service Strategy book to help aid theunderstanding of the role of Service Strategy in the ITILService Lifecycle.

Imagine you have been given responsibility for an ITorganization. This organization could be internal orexternal, commercial or not-for-profit. How would you goabout deciding on a strategy to serve customers? What ifyou have a variety of customers, all with specific needsand demands? How do you define your service strategy tomeet all of them?

Service Strategy provides guidance to help answer thatkey question. It is comprised of the following keyconcepts.

� Value creation

� Service assets

� Service Provider types

� Service capabilities and resources

� Service structures

� Defining the service market

� Developing service offerings

� Financial Management

� Service Portfolios

� Demand Management

� Service assessment

� Return on investment.

4.1 STRATEGIC ASSESSMENT

In crafting a service strategy, a provider should first take acareful look at what it does already. It is likely therealready exists a core of differentiation. An establishedservice provider frequently lacks an understanding of itsown unique differentiators. The following questions canhelp expose a service provider’s distinctive capabilities:

Which of our services or service varieties are the most

distinctive?

Are there services that the business or customer cannoteasily substitute? The differentiation can come in the formof barriers to entry, such as the organization’s know-how

4 Service Strategy – governance anddecision-making

Resource andConstraints

Objectives fromRequirements

Strategies

Policies

Requirements

ServiceStrategy

The business/customers

7238-TSO-ITIL-13 28/8/07 14:01 Page 25

of the customer’s business or the broadness of serviceofferings. Or it may be in the form of raised switchingcosts, due to lower cost structures generated throughspecialization or service sourcing. It may be a particularattribute not readily found elsewhere, such as productknowledge, regulatory compliance, provisioning speeds,technical capabilities or global support structures.

Which of our services or service varieties are the most

profitable?

The form of value may be monetary, as in higher profits orlower expenses, or social, as in saving lives or collectingtaxes. For non-profit organizations, are there services thatallow the organization to perform its mission better?Substitute ‘profit’ with ‘benefits realized’.

Which of our customers and stakeholders are the

most satisfied?

Which customers, channels or purchase occasions are

the most profitable?

Again, the form of value can be monetary, social or other.

Which of our activities in our value chain or value

network are the most different and effective?

The answers to these questions will likely reveal patternsthat lend insight to future strategic decisions. Thesedecisions, and related objectives, form the basis of astrategic assessment.

Service Providers can be present in more than one marketspace. As part of strategic planning, Service Providersshould analyse their presence across various marketspaces. Strategic reviews include the analysis of strengths,weaknesses, opportunities and threats in each marketspace. Service Providers also analyse their business

26 | Service Strategy – governance and decision-making

Table 4.1 Factors in strategic assessment

Factor Description

Strengths and weaknesses The attributes of the organization. For example, resources and capabilities, servicequality, operating leverage, experience, skills, cost structures, customer service, globalreach, product knowledge, customer relationships and so on.

Distinctive competencies As discussed throughout the chapter, ‘What makes the service provider special to itsbusiness or customers?’

Business strategy The perspective, position, plans and patterns received from a business strategy. Forexample, a Type I and II may be directed, as part of a new business model, to exposeservices to external partners or over the internet.

This is also where the discussion on customer outcomes begins and is carried forwardinto objectives setting.

Critical success factors How will the Service Provider know when it is successful? When must those factors beachieved?

Threats and opportunities Includes competitive thinking. For example, ‘Is the service provider vulnerable tosubstitution?’

Or, ‘Is there a means to outperform competing alternatives?’

7238-TSO-ITIL-13 28/8/07 14:01 Page 26

potential based on un-served or underserved marketspaces. This is an important aspect of leadership anddirection provided by the senior management of ServiceProviders. The long-term vitality of the Service Providerrests on supporting customer needs as they change orgrow as well exploiting new opportunities that emerge.This analysis identifies opportunities with current andprospective customers. It also prioritizes investments inservice assets based on their potential to serve marketspaces of interest. For example, if a Service Provider hasstrong capabilities and resources in service recovery, itexplores all those market spaces where such assets candeliver value for customers.

4.2 DEVELOPING STRATEGIC CAPABILITIES

To operate and grow successfully in the long term, serviceproviders must have the ability to think and act in astrategic manner. The purpose of Service Strategy is tohelp organizations develop such abilities. The achievementof strategic goals or objectives requires the use of strategicassets. The guidance shows how to transform servicemanagement into a strategic asset. Readers benefit fromseeing the relationships between various services, systemsor processes they manage and the business models,strategies or objectives they support. The guidanceanswers questions of the following kind:

� What services should we offer and to whom?

� How do we differentiate ourselves from competingalternatives?

� How do we truly create value for our customers?

� How can we make a case for strategic investments?

� How should we define service quality?

� How do we efficiently allocate resources across aportfolio of services?

� How do we resolve conflicting demands for sharedresources?

A multi-disciplinary approach is required to answer suchquestions. Technical knowledge of IT is necessary but notsufficient. The guidance is pollinated with knowledge fromthe disciplines such as operations management,marketing, finance, information systems, organizationaldevelopment, systems dynamics and industrialengineering. The result is a body of knowledge robustenough to be effective across a wide range of businessenvironments. Some organizations are putting in place thefoundational elements of service management. Others arefurther up the adoption curve, ready to tackle challengesand opportunities with higher levels of complexity anduncertainty.

4.3 SERVICE PROVIDER TYPES – MATCHINGNEED TO CAPABILITY

The aim of service management is to make availablecapabilities and resources useful to the customer in thehighly usable form of services at acceptable levels ofquality, cost and risks. Service Providers help relax theconstraints on customers of ownership and control ofspecific resources. In addition to the value from utilizingsuch resources now offered as services, customers arefreed to focus on what they consider to be their corecompetence. The relationship between customers andService Providers varies by specialization in ownership andcontrol of resources and the coordination of dependenciesbetween different pools of resources.

Service Strategy defines three broad types of ServiceProviders with whom a customer is likely to engage inaccessing services.

� Type I – Internal Service Provider

Type I providers are typically business functionsembedded within the business units they serve. Thebusiness units themselves may be part of a largerenterprise or parent organization. Business functionssuch as finance, administration, logistics, human

Service Strategy – governance and decision-making | 27

7238-TSO-ITIL-13 28/8/07 14:01 Page 27

resources and IT provide services required by variousparts of the business. They are funded by overheadsand are required to operate strictly within themandates of the business. Type I providers have thebenefit of tight coupling with their owner-customers,avoiding certain costs and risks associated withconducting business with external parties.

� Type II – Shared Service Provider

Business functions such as finance, IT, human resourcesand logistics are not always at the core of anorganization’s competitive advantage. Hence, theyneed not be maintained at the corporate level wherethey demand the attention of the chief executive’steam. Instead, the services of such shared functions areconsolidated into an autonomous special unit called ashared services unit (SSU). This model allows a moredevolved governing structure under which an SSU canfocus on serving business units as direct customers.SSUs can create, grow and sustain an internal marketfor their services and model themselves along the linesof service providers in the open market. Like corporatebusiness functions, they can leverage opportunitiesacross the enterprise and spread their costs and risksacross a wider base.

� Type III – External Service Provider

Type III providers can offer competitive prices and drivedown unit costs by consolidating demand. Certainbusiness strategies are not adequately served byinternal Service Providers such as Type I and Type II.Customers may pursue sourcing strategies requiringservices from external providers. The motivation maybe access to knowledge, experience, scale, scope,capabilities and resources that are either beyond thereach of the organization or outside the scope of acarefully considered investment portfolio. Businessstrategies often require reductions in the asset base,fixed costs, operational risks or the redeployment offinancial assets. Competitive business environments

often require customers to have flexible and leanstructures. In such cases it is better to buy servicesrather than own and operate the assets necessary toexecute certain business functions and processes. Forsuch customers, Type III is the best choice for a givenset of services.

Today, it is common to see all three types combiningcapabilities to manage services for a customer. The power ofthis approach lies in selecting the right blend and balance.

The Service Strategy publication provides detailedguidance on provider types and how to decide on theright blend.

4.4 SERVICES AS ASSETS – VALUECREATION

A good business model describes the means of fulfilling anorganization’s objectives. However, without a strategy thatin some way makes a Service Provider uniquely valuable tothe customer, there is little to prevent alternatives fromdisplacing the organization, degrading its mission orentering its market space. A service strategy thereforedefines a unique approach for delivering better value. Theneed for having a service strategy is not limited to ServiceProviders who are commercial enterprises. Internal ServiceProviders need just as much to have a clear perspective,positioning and plans to ensure they remain relevant to thebusiness strategies of their enterprises.

Service assets have two main characteristics:

� Utility is perceived by the customer from theattributes of the service that have a positive effect onthe performance of tasks associated with desiredbusiness outcomes. This is fit for purpose.

� Warranty is derived from the positive effect beingavailable when needed, in sufficient capacity ormagnitude, and dependably in terms of continuity andsecurity. This is fit for use.


7238-TSO-ITIL-13 28/8/07 14:01 Page 28

Utility is what the customer gets, and warranty is how it isdelivered.

Resources and capabilities are types of assets that, whencombined in various ways, produce service utility andwarranty. Organizations use them to create value in theform of goods and services. Resources are direct inputs forproduction. Management, organization, people andknowledge are used to transform resources. Capabilitiesrepresent an organization’s ability to coordinate, controland deploy resources to produce value. They are typicallyexperience-driven, knowledge-intensive, information-basedand firmly embedded within an organization’s people,systems, processes and technologies.

Customers perceive benefits in a continued relationship,and entrust the provider with the business of increasingvalue and also adding new customers and market spacesto the realm of possibilities. This justifies furtherinvestments in service management in terms ofcapabilities and resources, which have a tendency toreinforce each other.

Customers may initially trust the provider with low-valuecontracts or non-critical services. Service management

responds by delivering the performance expected of astrategic asset. The performance is rewarded with contractrenewals, new services and customers, which togetherrepresent a larger value of business. To handle this increasein value, service management must invest further in assetssuch as process, knowledge, people, applications andinfrastructure. Successful learning and growth enablescommitments of higher service levels as servicemanagement gets conditioned to handle bigger challenges.

4.5 DEFINING THE MARKET SPACE

A market space is defined by a set of business outcomes,which can be facilitated by a service. The opportunity tofacilitate those outcomes defines a market space. Thefollowing are examples of business outcomes that can bethe bases of one or more market spaces:

� Sales teams are productive with sales managementsystem on wireless computers

� E-commerce website is linked to the warehousemanagement system

� Key business applications are monitored and secure


Figure 4.1 Service Provider capabilities and resources

Management

Organization

Processes

Knowledge

People

A1

A2

A3

A4

A5

Financial capital

Infrastructure

Applications

Information

A9

A8

A7

A6

People

Capabilities Resources

7238-TSO-ITIL-13 28/8/07 14:01 Page 29

� Loan officers have faster access to information requiredon loan applicants

� Online bill payment service offers more options forshoppers to pay

� Business continuity is assured.

Each of the conditions is related to one or more categoriesof customer assets, such as people, infrastructure,information, accounts receivables and purchase orders,and can then be linked to the services that make thempossible.

Customers will prefer the one that means lower costs andrisks. Service Providers create these conditions throughthe services they deliver and thereby provide support forcustomers to achieve specific business outcomes.

A market space therefore represents a set of opportunitiesfor Service Providers to deliver value to a customer’sbusiness through one or more services. This approach hasdefinite value for Service Providers in building strongrelationships with customers. Often it is not clear how

services create value for customers. Services are oftendefined in terms of resources made available for use bycustomers. Service definitions lack clarity in the context inwhich such resources are useful, and the businessoutcomes that justify their cost from a customer’sperspective. This problem leads to poor designs,ineffective operation and lacklustre performance in servicecontracts. Service improvements are difficult when it is notclear where improvements are truly required. Customerscan understand and appreciate improvements only withinthe context of their own business assets, performancesand outcomes. It is therefore important the ServiceProviders identify their market spaces by ensuring theydefine service by business outcomes such as thosedescribed above and in Figure 4.2.

4.6 SERVICE PORTFOLIOS

The Service Portfolio (Figure 4.3) represents thecommitments and investments made by a Service Provideracross all customers and market spaces. It represents


Figure 4.2 Actionable components of service definitions in terms of utility

being constrained bylocation or time

slowing down theloan process

disruption or lossfrom failures or

disastrous events

(Constraints removed)

field staff securelyaccess enterprise

applications

loans officersdetermine credit-

rating of applicants

business processescontinue to operate

(Outcomes supported)

Utility Part A Utility Part B

Mobile workspaceservices

Credit reportingservices

Businesscontinuity services

(Catalogue)

Lines of Service

provide value tothe customer

whenwithout

7238-TSO-ITIL-13 28/8/07 14:01 Page 30

present contractual commitments, new servicedevelopment, and ongoing service improvementprogrammes initiated by Continual Service Improvement.The portfolio also includes third-party services, which arean integral part of service offerings to customers. Somethird-party services are visible to the customers whileothers are not.

The Service Portfolio represents all the resources presentlyengaged or being released in various phases of the ServiceLifecycle. Each phase requires resources for completion ofprojects, initiatives and contracts. This is a very important

governance aspect of Service Portfolio Management (SPM).Entry, progress and exit are approved only with approvedfunding and a financial plan for recovering costs orshowing profit as necessary. The Portfolio should have theright mix of services in development for the market spacesand the Service Catalogue (Figure 4.4) to secure thefinancial viability of the Service Provider. The ServiceCatalogue is the only part of the Portfolio that recoverscosts or earns profits.


Figure 4.3 Service Portfolio

ServiceImprovement

Plan

Customer3

Customer2

Customer1

MarketSpace 1

MarketSpace 2

MarketSpace 3

Linked byservices

Third-partyServices

Market potentialfor services

ServicePortfolio

7238-TSO-ITIL-13 28/8/07 14:01 Page 31

If we think of SPM as a dynamic and ongoing process set,it should include the following work methods:

� Define: inventory services, ensure business cases andvalidate portfolio data

� Analyse: minimize portfolio value, align and prioritizeand balance supply and demand

� Approve: finalize proposed portfolio, authorize servicesand resources

� Charter: communicate decisions, allocate resourcesand charter services.


Figure 4.4 Elements of a Service Portfolio and Service Catalogue

Service Portfolio

Description

Value proposition

Business cases

Priorities

Risks

Offerings and packages

Cost and pricing

Service Catalogue(s)

Services

Supported products

Policies

Ordering and requestprocedures

Support terms andconditions

Entry points andescalations

Pricing and chargeback

7238-TSO-ITIL-13 28/8/07 14:01 Page 32

Figure 4.5 Service Portfolio management

4.6.1 Service PipelineThe Service Pipeline consists of services underdevelopment for a given market space or customer.These services are to be phased into operation by ServiceTransition after completion of design, development andtesting. The Pipeline represents the Service Provider’sgrowth and strategic outlook for the future. The generalhealth of the provider is reflected in the Pipeline. It alsoreflects the extent to which new service concepts andideas for improvement are being fed by Service Strategy,Service Design and Continual Service Improvement. Goodfinancial management is necessary to ensure adequatefunding for the Pipeline.

4.6.2 Service CatalogueThe Service Catalogue is the subset of the Service Portfoliovisible to customers. It consists of services presently activein the Service Operation phase and those approved to bereadily offered to current or prospective customers. Itemscan enter the Service Catalogue only after due diligencehas been performed on related costs and risks. Resourcesare engaged to fully support active services.

The Service Catalogue is useful in developing suitablesolutions for customers from one or more services. Itemsin the Service Catalogue can be configured and suitablypriced to fulfil a particular need. The Service Catalogue isan important tool for Service Strategy because it is thevirtual projection of the Service Provider’s actual andpresent capabilities. Many customers are only interested inwhat the provider can commit now, rather than in future.

4.7 SERVICE OUTSOURCING – PRACTICALDECISION-MAKING

A service strategy should enhance an organization’sspecial strengths and core competencies. Each componentshould reinforce the other. Change any one and you havea different model. As organizations seek to improve theirperformance, they should consider which competenciesare essential and know when to extend their capabilitiesby partnering in areas both inside and outside theirenterprise.

Outsourcing is the moving of a value-creating activity thatwas performed inside the organization to outside theorganization where it is performed by another company.What prompts an organization to outsource an activity isthe same logic that determines whether an organizationmakes or buys inputs. Namely, does the extra valuegenerated from performing an activity inside theorganization outweigh the costs of managing it? Thisdecision can change over time.

• Inventories• Business Case

• Service Portfolio• Authorization

• Value Proposition• Prioritization

• Communication• Resource allocation

Analyse

Define

Approve

Charter

ServiceStrategy


7238-TSO-ITIL-13 28/8/07 14:01 Page 33


Table 4.2 Types of sourcing structures

Sourcing structure Description

Internal (Type I) The provision and delivery of services by internal staff. Does not typically includestandardization of service delivery across business units.

Provides the most control but also the most limited in terms of scale.

Shared services (Type II) An internal business unit. Typically operates its profit and loss, and a chargebackmechanism. If cost recovery is not used, then it is internal not shared services.

Lower costs than Internal with a similar degree of control. Improved standardizationbut limited in terms of scale.

Full service outsourcing A single contract with a single Service Provider. Typically involves significant assettransfer.

Provides improved scale but limited in terms of best-in-class capabilities. Delivery risksare higher than prime, consortium or selective outsourcing as switching to analternative is difficult.

Prime A single contract with a single Service Provider who manages service delivery butengages multiple providers to do so. The contract stipulates that the prime vendor willleverage the capabilities of other best-in-class Service Providers.

Capabilities and risk are improved from single-vendor outsourcing but complexity isincreased.

Consortium A collection of Service Providers explicitly selected by the service recipient. Allproviders are required to come together and present a unified management interface.

Fulfils a need that cannot be satisfied by any single-vendor outsourcer. Provides best-in-class capabilities with greater control than prime. Risk is introduced in the form ofproviders forced to collaborate with competitors.

Selective outsourcing A collection of Service Providers explicitly selected and managed by the servicerecipient.

This is the most difficult structure to manage. The service recipient is the serviceintegrator, responsible for gaps or cross-provider disputes.

The term ‘co-sourcing’ refers to a special case of selective outsourcing. In this variant,the service recipient maintains an internal or shared services structure and combines itwith external providers. The service recipient is the service integrator.

7238-TSO-ITIL-13 28/8/07 14:01 Page 34

Sourcing requires businesses to formally consider asourcing strategy, the structure and role of the retainedorganization, and how decisions are made. When sourcingservices, the enterprise retains the responsibility for theadequacy of services delivered. Therefore, the enterpriseretains key overall responsibility for governance. Theenterprise should adopt a formal governance approach inorder to create a working model for managing itsoutsourced services as well as the assurance of valuedelivery. This includes planning for the organizationalchange precipitated by the sourcing strategy and a formaland verifiable description as to how decisions on servicesare made. Table 4.2 describes the generic forms of servicesourcing structures.

Partnering with providers who are ISO/IEC 20000compliant can be an important element in reducing therisk of service sourcing. Organizations who have achievedthis certification are more likely to meet service levels on asustained basis. This credential is particularly important inmulti-sourced environments where a common frameworkpromotes better integration. Multi-sourced environmentsrequire common language, integrated processes and amanagement structure between internal and externalproviders. ISO/IEC 20000 does not provide all of this but itprovides a foundation on which it can be built.

4.7.1 Sourcing governanceThere is a frequent misunderstanding of the definition of‘governance’, particularly in a sourcing context. Companieshave used the word interchangeably with ‘vendormanagement’, ‘retained staff’ and ‘sourcing managementorganization’. Governance is none of these.

Management and governance are different disciplines.Management deals with making decisions and executingprocesses. Governance only deals with making sounddecisions. It is the framework of decision rights thatencourages desired behaviours in the sourcing and thesourced organization. When companies confuse

management and governance, they inevitably focus onexecution at the expense of strategic decision-making.Both are vitally important. Further complicating matters isthe requirement of sharing decision rights with the ServiceProviders. When a company places itself in a position tomake operational decisions on behalf of an outsourcer,the outcomes are inevitably poor service levels andcontentious relationship management.

Governance is invariably the weakest link in a servicesourcing strategy. A few simple constructs have beenshown to be effective at improving that weakness:

� A governance body – By forming a manageably sizedgovernance body with a clear understanding of theservice sourcing strategy, decisions can be madewithout escalating to the highest levels of seniormanagement. By including representation from eachService Provider, stronger decisions can be made.

� Governance domains – Domains can cover decision-making for a specific area of the service sourcingstrategy. Domains can cover, for example, servicedelivery, communication, sourcing strategy or contractmanagement. Remember, a governance domain doesnot include the responsibility for its execution, only itsstrategic decision-making.

� Creation of a decision-rights matrix – This ties allthree recommendations together. RACI or RASIC chartsare common forms of a decision-rights matrix.

4.8 RETURN ON INVESTMENT (ROI)

Return on investment (ROI) is a concept for quantifyingthe value of an investment. Its use and meaning are notalways precise. When dealing with financial officers, ROImost likely means ROIC (return on invested capital), ameasure of business performance. In service management,ROI is used as a measure of the ability to use assets togenerate additional value. In the simplest sense, it is thenet profit of an investment divided by the net worth of


7238-TSO-ITIL-13 28/8/07 14:01 Page 35

the assets invested. The resulting percentage is applied toeither additional top-line revenue or the elimination ofbottom-line cost.

It is not unexpected that companies seek to apply ROI indeciding to adopt service management. ROI is appealingbecause it is self-evident. The measure either meets ordoes not meet a numerical criterion. The challenge iswhen ROI calculations focus on the short term. Theapplication of service management has different degreesof ROI, depending on business impact (see Figure 4.6).Moreover, there are often difficulties in quantifying thecomplexities involved in implementations.

While a service can be directly linked and justified throughspecific business imperatives, few companies can readilyidentify the financial return for the specific aspects ofservice management. It is often an investment thatcompanies must make in advance of any return.

4.9 FINANCIAL MANAGEMENT

Operational visibility, insight and superior decision-makingare the core capabilities brought to the enterprise throughthe rigorous application of Financial Management. Just asbusiness units accrue benefits through the analysis of


Figure 4.6 Business impact and ROI outcome

Improved Reliability

Improved Maintainability

Improved Services

Tangible Measure:Product orders can now be placed on-lineImpact:Product orders can be placed 24 x7

Tangible Measure:MTRS (Mean Time to Restore)Impact:MTRS to 2 hours from 6 hours

Tangible Measure:MTBF (Mean Time Between Failure)Impact:MTBF to 200 hours from 600 hours

Business Impact

Customer Satisfaction

Tangible Measure:Repeat Rate of BusinessTarget:Improve rate to 60% from 25%

Business Objectives

7238-TSO-ITIL-13 28/8/07 14:01 Page 36

product mix and margin data, or customer profiles andproduct behaviour, a similar utility of financial datacontinues to increase the importance of FinancialManagement for IT and the business as well.

Financial Management as a strategic tool is equallyapplicable to all three Service Provider types. Internalservice providers are increasingly asked to operate withthe same levels of financial visibility and accountability astheir business unit and external counterparts. Moreover,technology and innovation have become the corerevenue-generating capabilities of many companies.

Financial Management provides the business and IT withthe quantification, in financial terms, of the value of ITservices, the value of the assets underlying theprovisioning of those services, and the qualification ofoperational forecasting. Talking about IT in terms ofservices is the crux of changing the perception of IT andits value to the business. Therefore, a significant portion ofFinancial Management is working in tandem with IT andthe business to help identify, document and agree on thevalue of the services being received, and the enablementof service demand modelling and management.

Much like their business counterparts, IT organizations areincreasingly incorporating Financial Management in thepursuit of:

� Enhanced decision-making

� Speed of change

� Service Portfolio Management

� Financial compliance and control

� Operational control

� Value capture and creation.

One goal of Financial Management is to ensure properfunding for the delivery and consumption of services.Planning provides financial translation and qualification ofexpected future demand for IT services. FinancialManagement planning departs from historical IT planning

by focusing on demand and supply variances resultingfrom business strategy, capacity inputs and forecasting,rather than traditional individual line item expenditures orbusiness cost accounts. As with planning for any otherbusiness organization, input should be collected from allareas of the IT organization and the business.

Planning can be categorized into three main areas, eachrepresenting financial results that are required forcontinued visibility and service valuation:

� Operating and capital planning processes are commonand fairly standardized, and involve the translation ofIT expenditures into corporate financial systems as partof the corporate planning cycle. Beyond this, theimportance of this process is in communicatingexpected changes in the funding of IT services forconsideration by other business domains. The impactof IT services on capital planning is largelyunderestimated, but is of interest to tax and fixed-assetdepartments if the status of an IT asset changes.

� Demand representing the need and use of IT services.

� Regulatory and environmental-related planning shouldget its triggers from within the business. However,Financial Management should apply the properfinancial inputs to the related services value, whethercost-based or value-based.

4.9.1 Service valuationService valuation quantifies, in financial terms, the fundingsought by the business and IT for services delivered, basedon the agreed value of those services. FinancialManagement calculates and assigns a monetary value to aservice or service component so that they may bedisseminated across the enterprise once the businesscustomer and IT identify what services are actually desired.

� Hardware and software licence costs

� Annual maintenance fees for hardware and software


7238-TSO-ITIL-13 28/8/07 14:01 Page 37

� Personnel resources used in the support ormaintenance of a service

� Utilities, data centre or other facilities charges

� Taxes, capital or interest charges

� Compliance costs.

Financial Management plays a translational role betweencorporate financial systems and service management. Theresult of a service-oriented accounting function is that fargreater detail and understanding is achieved regardingservice provisioning and consumption, and the generationof data that feeds directly into the planning process. Thefunctions and accounting characteristics that come intoplay are discussed below:

� Service recording – The assignment of a cost entry tothe appropriate service. Depending on how servicesare defined, and the granularity of the definitions,there may be additional sub-service components

� Cost types – These are higher-level expensescategories such as hardware, software, labour,administration etc. These attributes assist withreporting and analysing demand and usage of servicesand their components in commonly used financialterms

� Cost classifications – There are also classificationswithin services that designate the end purpose of thecost. These include classifications such as:

� Capital/operational – this classification addressesdifferent accounting methodologies that arerequired by the business and regulatory agencies

� Direct/indirect – this designation determineswhether a cost will be assigned directly or indirectlyto a consumer or service:– Direct costs are charged directly to a service

since it is the only consumer of the expense– Indirect or shared costs are allocated across

multiple services since each service mayconsume a portion of the expense

� Fixed/variable – this segregation of costs is basedon contractual commitments of time or price. Thestrategic issue around this classification is that thebusiness should seek to optimize fixed service costsand minimize the variable in order to minimizepredictability and stability

� Cost units – a cost unit is the identified unit ofconsumption that is accounted for a particularservice or service asset.

4.9.2 Variable cost dynamicsVariable cost dynamics (VCD) focuses on analysing andunderstanding the multitude of variables that impactservice cost, how sensitive those elements are to variation,and the related incremental value changes that result.

Below is a very brief list of possible variable service costcomponents that could be included in such an analysis:

� Number and type of users

� Number of software licences

� Cost/operating foot of data centre

� Delivery mechanisms

� Number and type of resources

� Cost of adding one more storage device

� Cost of adding one more end-user license.

4.10 INCREASING SERVICE POTENTIAL

The capabilities and resources (service assets) of a ServiceProvider represent the service potential or the productivecapacity available to customers through a set of services.Projects that develop or improve capabilities and resourcesincrease the service potential. For example,implementation of a Configuration Management Systemleads to improved visibility and control over theproductive capacity of service assets such as networks,storage and servers. It also helps quickly to restore suchcapacity in the event of failures or outages. There is


7238-TSO-ITIL-13 28/8/07 14:01 Page 38

greater efficiency in the utilization of those assets andtherefore service potential because of capabilityimprovements in Configuration Management. Similarexamples are given in Table 4.3. One of the key objectivesof service management is to improve the service potentialof its capabilities and resources.

4.11 ORGANIZATIONAL DEVELOPMENT

When senior managers adopt a service managementorientation, they are adopting a vision for theorganization. Such a vision provides a model towardwhich staff can work. Organizational change, however, isnot instantaneous. Senior managers often make themistake of thinking that announcing the organizationalchange is the same as making it happen.

There is no one best way to organize. Elements of anorganizational design, such as scale, scope and structure,are highly dependent on strategic objectives. Over time,an organization will likely outgrow its design. Certainorganizational designs fit while others do not. The designchallenge is to identify and select among often distinctchoices. Thus the problem becomes much more solvablewhen there is an understanding of the factors thatgenerate fit and the trade-offs involved, such as controland coordination.

It is common to think of organizational hierarchies interms of functions. As the functional groups becomelarger, think of them in terms of departmentalization.A department can loosely be defined as an organizationalactivity involving over 20 people. When a functional groupgrows to departmental size, the organization can reorient


Table 4.3 Example of increased Service Potential

Service management Increasing service potential Increasing service potential initiative from capabilities from resources

Data centre rationalization

Training and certification

Implement Incident Managementprocess

Develop service design process

Thin-client computing Increased flexibility in work locations

Enhanced service continuity capabilities

Standardization and control of configurations

Centralization of administration functions

Systematic design of services

Enrichment of design portfolio

Re-use of service components

Fewer service failures through design

Better response to Service Incidents

Prioritization of recovery activities

Reducing losses in resource utilization

Knowledgeable staff in control of ServiceLifecycle

Improved analysis and decisions

Staffing of key competencies

Extension of Service Desk hours

Better control over service operations

Lower complexity in infrastructure

Development of infrastructure andtechnology assets

Increases the capacity of assets

Increases economies of scale and scope

Capacity building in service assets

7238-TSO-ITIL-13 28/8/07 14:01 Page 39

the group to one of the following areas or a hybridthereof:

� Function – preferred for specialization, the pooling ofresources and reducing duplication

� Product – preferred for servicing businesses withstrategies of diverse and new products, usuallymanufacturing businesses

� Market space or customer – preferred for organizingaround market structures. Provides differentiation inthe form of increased knowledge of and response tocustomer preferences

� Geography – the use of geography depends on theindustry. By providing services in close geographicalproximity, travel and distribution costs are minimizedwhile local knowledge is leveraged

� Process – preferred for an end-to-end coverage of aprocess.

Certain basic structures are preferred for certain servicestrategies, as shown in Table 4.4.

Service strategies are executed by delivering andsupporting the contract portfolio in a given market space.Contracts specify the terms and conditions under whichvalue is delivered to customer through services. From anoperational point of view this translates into specific levelsof utility and warranty for every service. Since every serviceis mapped to one or more market spaces, it follows thatthe design of a service is related to categories of customerassets and the service models. These are the basic inputsfor service design.

There is much more depth in Service Strategy thandepicted in the preceding pages. As the core of the ITILService Lifecycle, Service Strategy is a prime component ina good service management practice. The key conceptshave been outlined in this book to provide a basicunderstanding and illustrate the enormous benefits a


Table 4.4 Basic organizational structures for types of service strategies

Basic structure Strategic considerations

Functional Specialization

Common standards

Small size

Product Product focus

Strong product knowledge

Market space or customer Service unique to segment

Customer service

Buyer strength

Rapid customer service

Geography Onsite services

Proximity to customer for delivery and support

Organization perceived as local

Process Need to minimize process cycle times

Process excellence

7238-TSO-ITIL-13 28/8/07 14:01 Page 40

sound service strategy offers to every IT organization andtheir customers. You are encouraged to read the ServiceStrategy core guidance in its entirety as the best place tostart in expanding your knowledge of service managementpractices.


7238-TSO-ITIL-13 28/8/07 14:01 Page 41

7238-TSO-ITIL-13 28/8/07 14:01 Page 42

Service Design – buildingstructural service integrity 5

7238-TSO-ITIL-13 28/8/07 14:01 Page 43

7238-TSO-ITIL-13 28/8/07 14:01 Page 44

Following on from Service Strategy, Service Design is thenext stage in the ITIL Service Lifecycle. While the lifecycleis not entirely linear, we will portray each stage from alogical progression. The key concepts of Service Designrevolve around the five design aspects and the design ofservices, service processes and service capabilities to meetbusiness demand. The primary topics that will bediscussed here are not the entire spectrum of ServiceDesign, but the main elements that illustrate theobjectives of this stage in the Service Lifecycle:

� Aspects of Service Design

� Service Catalogue Management

� Service Requirements

� Service Design Models

� Capacity Management

� Availability Management

� Service Level Management.

The Service Design publication provides a greater level ofdetail on these and also on application and infrastructuredesign principles.

The main purpose of the Service Design stage of thelifecycle is the design of new or changed service forintroduction into the live environment. It is important thata holistic approach to all aspects of design is adopted andthat when changing or amending any of the individualelements of design all other aspects are considered. Thuswhen designing and developing a new application, thisshouldn’t be done in isolation, but should also considerthe impact on the overall service, the managementsystems and tools (e.g. the Service Portfolio andCatalogue), the architectures, the technology, the ServiceManagement processes and the necessary measurementsand metrics. This will ensure that not only the functionalelements are addressed by the design, but also that all of

| 45

5 Service Design – building structural serviceintegrity



Strategies

Policies

Requirements

ServiceStrategy


StandardsSDPs

SolutionDesigns

Architectures

ServiceDesign

7238-TSO-ITIL-13 28/8/07 14:01 Page 45

the management and operational requirements areaddressed as a fundamental part of the design and are notadded as an afterthought.

The main aim of Service Design is the design of new orchanged services. The requirements for these new servicesare extracted from the Service Portfolio and eachrequirement is analysed, documented and agreed and asolution design is produced that is then compared withthe strategies and constraints from Service Strategy toensure that it conforms to corporate and IT policies.

5.1 BUSINESS VALUE

With good Service Design it will be possible to deliverquality, cost-effective services and to ensure that thebusiness requirements are being met.

The following benefits are as a result of good ServiceDesign practice:

� Reduced total cost of ownership (TCO): cost ofownership can only be minimized if all aspects ofservices, processes and technology are designedproperly and implemented against the design

� Improved quality of service: both service andoperational quality will be enhanced

� Improved consistency of service: as services aredesigned within the corporate strategy, architecturesand constraints

� Easier implementation of new or changed services:as there is integrated and full Service Design, and theproduction of comprehensives Service Design Packages

� Improved service alignment: involvement from theconception of the service ensuring that new orchanged services match business needs, with servicesdesigned to meet Service Level Requirements

� More effective service performance: withincorporation and recognition of Capacity, Financial,Availability and IT Service Continuity plans

� Improved IT governance: assists with theimplementation and communication of a set ofcontrols for effective governance of IT

� More effective service management and ITprocesses: processes will be designed with optimalquality and cost-effectiveness

� Improved information and decision-making: morecomprehensive and effective measurements andmetrics will enable better decision-making andcontinual improvement of service managementpractices in the design stage of the Service Lifecycle.

5.2 FIVE ASPECTS OF SERVICE DESIGN

There are five aspects of design that need to beconsidered:

1 The design of the services, including all of thefunctional requirements, resources and capabilitiesneeded and agreed

2 The design of service management systems and tools,especially the Service Portfolio, for the managementand control of services through their lifecycle

3 The design of the technology architectures andmanagement systems required to provide the services

4 The design of the processes needed to design,transition, operate and improve the services, thearchitectures and the processes themselves

5 The design of the measurement methods and metricsof the services, the architectures and their constituentcomponents and the processes.

A results-driven approach should be adopted for each ofthe above five aspects. In each, the desired businessoutcomes and planned results should be defined so thatwhat is delivered meets the expectation of the customersand users. Thus this structured approach should beadopted within each of the five aspects to deliver quality,

46 | Service Design – building structural service integrity

7238-TSO-ITIL-13 28/8/07 14:01 Page 46

repeatable consistency and continual improvementthroughout the organization. There are no situationswithin IT service provision with either internal or externalservice providers where there are no processes in theService Design area. All IT Service Provider organizationsalready have some elements of their approach to thesefive aspects in place, no matter how basic. Before startingon the implementation of the improvement of activitiesand processes a review should be conducted of whatelements are in place and working successfully. ManyService Provider organizations already have matureprocesses in place for designing IT services and solutions.

5.3 IDENTIFYING SERVICE REQUIREMENTS

Service Design must consider all elements of the service bytaking a holistic approach to the design of a new service.This approach should consider the service and itsconstituent components and their inter-relationships,ensuring that the services delivered meet the functionalityand quality of service expected by the business in all areas:

� The scalability of the service to meet futurerequirements, in support of the long-term businessobjectives

� The business processes and business units supportedby the service

� The IT service and the agreed business functionalityand requirements

� The service itself and its Service Level Requirement(SLR) or Service Level Agreement (SLA)

� The technology components used to deploy anddeliver the service, including the infrastructure, theenvironment, the data and the applications

� The internally supported services and components andtheir associated Operational Level Agreements (OLAs)

� The externally supported services and components andtheir associated Underpinning Contracts (UCs), whichwill often have their own related agreements and/orschedules

� The performance measurements and metrics required

� The legislated or required security levels.

The relationships and dependencies between theseelements are illustrated in Figure 5.1.

The design needs to be holistic, and the main problemtoday is that organizations often only focus on thefunctional requirements. A design or architecture by verydefinition needs to consider all aspects. It is not a smallerorganization that combines these aspects, it is a sensibleone.

The design process activities are:

� Requirements collection, analysis and engineering toensure that business requirements are clearlydocumented and agreed

� Design of appropriate services, technology, processes,information and process measurements to meetbusiness requirements

� Review and revision of all processes and documentsinvolved in Service Design, including designs, plans,architectures and policies

� Liaison with all other design and planning activitiesand roles, e.g. solution design

� Production and maintenance of IT policies and designdocuments, including designs, plans, architectures andpolicies

� Revision of all design documents and planning for thedeployment and implementation of IT strategies usingroadmaps, programmes and project plans

� Risk assessment and management of all designprocesses and deliverables

� Ensuring alignment with all corporate and IT strategiesand policies.

Service Design – building structural service integrity | 47

7238-TSO-ITIL-13 28/8/07 14:01 Page 47

5.4 SERVICE DESIGN MODELS

Before adopting a design model for a major new service, areview of the current capability and provisions withrespect to all aspects regarding the delivery of IT servicesshould be conducted. This review should consider allaspects of the new service including:

� Business drivers and requirements

� Scope and capability of the existing service providerunit

� Demands, targets and requirements of the new service

� Scope and capability of external suppliers

� Maturity of the organizations currently involved andtheir processes

� Culture of the organizations involved

� IT infrastructure, applications, data, services and othercomponents involved

� Degree of corporate and IT governance and the levelof ownership and control required

� Budgets and resources available

� Staff levels and skills.


Figure 5.1 Design dependencies

Service Catalogue

Service Knowledge

Management System

Service Portfolio

32

Businessprocess 1

65

Businessprocess 4

98

Businessprocess 7

Business service a Business service b Business service c

GFEDCBService ASLAs

ServiceStrategy

ServiceImprovement

ServiceTransition

ServiceOperation

Measurementmethods

Architectures

Services

SupplierSecurity

AvailabilityIT Service Continuity

Capacity

SLM SCM

Processes

Service Design

Support teams

Suppliers

The business

IT

IT Services

7238-TSO-ITIL-13 28/8/07 14:01 Page 48

5.5 DELIVERY MODEL OPTIONS

Although the readiness assessment determines the gapbetween the current and desired capabilities, an ITorganization should not necessarily try to bridge that gapby itself. There are many different delivery strategies thatcan be used. Each one has its own set of advantages and

disadvantages, but all require some level of adaptationand customization for the situation at hand. Table 5.1 liststhe main categories of sourcing strategies with a shortabstract for each. Delivery practices tend to fall into one ofthese categories or some variant of them.


Table 5.1 Delivery model options

Delivery strategy Description

Insourcing This approach relies on utilizing internal organizational resources in the design,development, transition, maintenance, operation and/or support of a new, changed orrevised services or data centre operations

Outsourcing This approach utilizes the resources of an external organization or organizations in aformal arrangement to provide a well-defined portion of a service’s design,development, maintenance, operations and/or support. This includes the consumptionof services from Application Service Providers (ASPs) described below

Co-sourcing Often a combination of insourcing and outsourcing, using a number of outsourcingorganizations working together to co-source key elements within the lifecycle. Thisgenerally will involve using a number of external organizations working together todesign, develop, transition, maintain, operate and/or support a portion of a service

Partnership or multi-sourcing Formal arrangements between two or more organizations to work together to design,develop, transition, maintain, operate and/or support IT service(s). The focus here tendsto be on strategic partnerships that leverage critical expertise or market opportunities

Business process outsourcing (BPO) The increasing trend of relocating entire business functions using formal arrangementsbetween organizations where one organization provides and manages the otherorganization’s entire business process(es) or function(s) in a low-cost location.Common examples are accounting, payroll and call-centre operations

Application service provision (ASP) Involves formal arrangements with an ASP organization that will provide sharedcomputer-based services to customer organizations over a network. Applicationsoffered in this way are also sometimes referred to as ‘on-demandsoftware/applications’. Through ASPs the complexities and costs of such sharedsoftware can be reduced and provided to organizations that could otherwise not justifythe investment

Knowledge process outsourcing (KPO) The newest form of outsourcing, KPO is a step ahead of BPO in one respect. KPOorganizations provide domain-based processes and business expertise rather than justprocess expertise and require advanced analytical and specialized skills from theoutsourcing organization

7238-TSO-ITIL-13 28/8/07 14:01 Page 49

5.6 SERVICE CATALOGUE MANAGEMENT

Over the years, organizations’ IT infrastructures havegrown and developed, and there may not always be aclear picture of all the services currently being provided orthe customers of each service. In order to establish anaccurate picture, it is recommended that an IT ServicePortfolio containing a Service Catalogue is produced andmaintained to provide a central accurate set ofinformation on all services and to develop a service-focused culture.

In the preceding chapter, we learned about the ServicePortfolio and its constituent elements. Among them is theService Catalogue.

The objective of Service Catalogue Management is tomanage the information contained within the ServiceCatalogue and to ensure that it is accurate and reflects thecurrent details, status, interfaces and dependencies of allservices that are being run or being prepared to run in thelive environment.

The Service Catalogue provides business value as a centralsource of information on the IT services delivered by theservice provider organization. This ensures that all areas ofthe business can view an accurate, consistent picture ofthe IT services, their details and their status. It contains acustomer-facing view of the IT services in use, how theyare intended to be used, the business processes theyenable, and the levels and quality of service the customercan expect of each service.

Service Catalogue Management activities should include:

� Definition of the service

� Production and maintenance of an accurate ServiceCatalogue

� Interfaces, dependencies and consistency between theService Catalogue and Service Portfolio

� Interfaces and dependencies between all services andsupporting services within the Service Catalogue andthe CMS

� Interfaces and dependencies between all services, andsupporting components and Configuration Items (CIs)within the Service Catalogue and the CMS.

When initially completed, the Service Catalogue mayconsist of a matrix, table or spreadsheet. Manyorganizations integrate and maintain their Portfolio andCatalogue as part of their CMS. By defining each service asa CI and, where appropriate, relating these to form aservice hierarchy, the organization is able to relate eventssuch as Incidents and RFCs to the services affected, thusproviding the basis for service monitoring and reportingusing an integrated tool (e.g. ‘list or give the number ofIncidents affecting this particular service’). It is thereforeessential that changes within the Service Portfolio andService Catalogue are subject to the Change Managementprocess.

The Service Catalogue can also be used for other ServiceManagement purposes (e.g. for performing a BusinessImpact Analysis (BIA) as part of IT Service ContinuityPlanning, or as a starting place for redistributingworkloads, as part of Capacity Management). The cost andeffort of producing and maintaining the catalogue, with itsrelationships to the underpinning technology components,is therefore easily justifiable. If done in conjunction withprioritization of the BIA, then it is possible to ensure thatthe most important services are covered first.

The Service Catalogue has two aspects:

� Business Service Catalogue: containing details of allof the IT services delivered to the customer, togetherwith relationships to the business units and thebusiness processes that rely on the IT services. This isthe customer view of the Service Catalogue


7238-TSO-ITIL-13 28/8/07 14:01 Page 50

� Technical Service Catalogue: containing details of allthe IT services delivered to the customer, together withrelationships to the supporting services, sharedservices, components and CIs necessary to support theprovision of the service to the business. This shouldunderpin the Business Service Catalogue and not formpart of the customer view.

The key activities within the Service CatalogueManagement process should include:

� Agreeing and documenting a service definition with allrelevant parties

� Interfacing with Service Portfolio Management to agreethe contents of the Service Portfolio and ServiceCatalogue

� Producing and maintaining a Service Catalogue and itscontents, in conjunction with the Service Portfolio

� Interfacing with the business and IT Service ContinuityManagement on the dependencies of business unitsand their business processes with the supporting ITservices, contained within the Business ServiceCatalogue

� Interfacing with support teams, Suppliers andConfiguration Management on interfaces anddependencies between IT services and the supportingservices, components and CIs contained within theTechnical Service Catalogue

� Interfacing with Business Relationship Managementand Service Level Management to ensure that theinformation is aligned to the business and businessprocess.

The Service Catalogue forms an integral part of the overallService Portfolio and is a key, customer-facing view of theservices on offer. It establishes the expectations of valueand potential that customers can expect from their IT


Figure 5.2 Service Catalogue elements

BusinessProcess 1

BusinessProcess 2

BusinessProcess 3

Service A Service B Service C Service D Service E

SupportServices

Hardware Software Applications Data

Technical Service Catalogue

Business Service Catalogue

The Service Catalogue

7238-TSO-ITIL-13 28/8/07 14:01 Page 51

service provider(s). The Service Design core publicationcontains detailed guidance on the construction andmanagement of a Service Catalogue.

5.7 SERVICE LEVEL MANAGEMENT

Service Level Management (SLM) negotiates, agrees anddocuments appropriate IT service targets withrepresentatives of the business, and then monitors andproduces reports on the Service Provider’s ability to deliverthe agreed level of service. SLM is a vital process for everyIT Service Provider organization in that it is responsible foragreeing and documenting service level targets andresponsibilities within Service Level Agreements (SLAs) andService Level Requirements (SLRs), for every activity withinIT. If these targets are appropriate and accurately reflectthe requirements of the business, then the servicedelivered by the Service Providers will align with businessrequirements and meet the expectations of the customersand users in terms of service quality. If the targets are notaligned with business needs, then Service Provideractivities and service levels will not be aligned withbusiness expectations and problems will develop.

The SLA is effectively a level of assurance or warranty withregard to the level of service quality delivered by theService Provider for each of the services delivered to thebusiness. The success of SLM is very dependent on thequality of the Service Portfolio and the Service Catalogueand their contents, because they provide the necessaryinformation on the services to be managed within the SLMprocess.

The objectives of SLM are to:

� Define, document, agree, monitor, measure, report andreview the level of IT services provided

� Provide and improve the relationship andcommunication with the business and customers

� Ensure that specific and measurable targets aredeveloped for all IT services

� Monitor and improve customer satisfaction with thequality of service delivered

� Ensure that IT and the customers have a clear andunambiguous expectation of the level of service to bedelivered

� Ensure that proactive measures to improve the levelsof service delivered are implemented wherever it iscost-justifiable to do so.

The key activities within the SLM process should include:

� Determine, negotiate, document and agreerequirements for new or changed services in SLRs, andmanage and review them through the Service Lifecycleinto SLAs for operational services

� Monitor and measure service performanceachievements of all operational services against targetswithin SLAs

� Collate, measure and improve customer satisfaction

� Produce service reports

� Conduct service review and instigate improvementswithin an overall Service ImprovementProgramme/Plan (SIP)

� Review and revise SLAs, service scope OLAs, contractsand any other underpinning agreements

� Develop and document contacts and relationships withthe business, customers and stakeholders

� Develop, maintain and operate procedures for logging,actioning and resolving all complaints, and for loggingand distributing compliments

� Log and manage all complaints and compliments

� Provide the appropriate management information toaid performance management and demonstrate serviceachievement

� Make available and maintain up-to-date SLMdocument templates and standards.


7238-TSO-ITIL-13 28/8/07 14:01 Page 52


Figure 5.3 The Service Level Management process

GFDCBService A

The business

32

BusinessProcess 1

65

BusinessProcess 4

Business Unit A Business Unit B

SLA(s)

Contracts

SLM

SLA(s)SLR(s)

Determine,document & agreerequirements for newservices SLRs & makeSLAs

Monitor serviceperformance againstSLA & produce servicereports

Conduct servicereview & instigateimprovements withinan overall SIP

Documentstandards &templates

Assist with theService Catalogue& maintain documenttemplates

Develop contacts& relationships,record & managecomplaints &compliments

Collate, measure& improvecustomersatisfaction

Review & reviseSLAs, servicescope & underpinningagreements

ServiceCatalogue

ServiceReports

OLAs

Support teams Supplier Management Suppliers

7238-TSO-ITIL-13 28/8/07 14:01 Page 53

There are a number of potential options, including thefollowing.

� Service-based SLA

This is where an SLA covers one service for all thecustomers of that service – for example, an SLA maybe established for an organization’s e-mail service,covering all of the customers of that service. Wherecommon levels of service are provided across all areasof the business, e.g. e-mail or telephony, the service-based SLA can be an efficient approach to use.Multiple classes of service, e.g. gold, silver and bronze,can also be used to increase the effectiveness ofservice-based SLAs.

� Customer-based SLA

This is an agreement with an individual customergroup covering all the services they use. For example,agreements may be reached with an organization’sfinance department covering, say, the finance system,the accounting system, the payroll system, the billingsystem, the procurement system, and any other ITsystems that they use. Customers often prefer such anagreement, as all of their requirements are covered in asingle document. Only one signatory is normallyrequired, which simplifies this issue.

� Multi-level SLA

Some organizations have chosen to adopt a multi-levelSLA structure. For example, a three-layer structure asfollows:

� Corporate level: covering all the generic SLM issuesappropriate to every customer throughout theorganization. These issues are likely to be lessvolatile, so updates are less frequently required

� Customer level: covering all SLM issues relevant tothe particular customer group or business unit,regardless of the service being used

� Service level: covering all SLM issues relevant to thespecific service, in relation to a specific customergroup (one for each service covered by the SLA).

The wording of SLAs should be clear and concise andleave no room for ambiguity. There is normally no needfor agreements to be couched in legal terminology, andplain language aids a common understanding. It is oftenhelpful to have an independent person, who has not beeninvolved with the drafting, to do a final read-through. Thisoften throws up potential ambiguities and difficulties thatcan then be addressed and clarified. For this reason alone,it is recommended that all SLAs contain a glossary,defining any terms and providing clarity for any areas ofambiguity.

5.7.1 Service Level RequirementsThis is one of the earliest activities within the ServiceDesign stage of the Service Lifecycle. Once the ServiceCatalogue has been produced and the SLA structure hasbeen agreed, a first SLR must be drafted. It is advisable toinvolve customers from the outset, but rather than goingalong with a blank sheet to start with, it may be better toproduce a first outline draft of the performance targetsand the management and operational requirements, as astarting point for more detailed and in-depth discussion.Be careful, though, not to go too far and appear to bepresenting the customer with a fait accompli.

It cannot be overstressed how difficult this activity ofdetermining the initial targets for inclusion with an SLR orSLA is. All of the other processes need to be consulted fortheir opinion on what are realistic targets that can beachieved, such as Incident Management on incidenttargets. The Capacity and Availability Managementprocesses will be of particular value in determiningappropriate service availability and performance targets.


7238-TSO-ITIL-13 28/8/07 14:01 Page 54

5.7.2 Monitoring service level performanceNothing should be included in an SLA unless it can beeffectively monitored and measured at a commonlyagreed point. The importance of this cannot beoverstressed, as inclusion of items that cannot beeffectively monitored almost always results in disputes andeventual loss of faith in the SLM process. A lot oforganizations have discovered this the hard way and as aresult have absorbed heavy costs, both in a financial senseas well as in terms of negative impacts on their credibility.

It is essential that monitoring matches the customer’s trueperception of the service. Unfortunately this is often verydifficult to achieve. For example, monitoring of individualcomponents, such as the network or server, does notguarantee that the service will be available so far as thecustomer is concerned. Where multiple services aredelivered to a single workstation, it is probably moreeffective to record only downtime against the service theuser was trying to access at the time (though this needsto be agreed with the customers).

There are a number of important soft issues that cannotbe monitored by mechanistic or procedural means, suchas customers’ overall feelings (these need not necessarilymatch the hard monitoring). For example, even whenthere have been a number of reported service failures,customers may still feel positive about things, becausethey may feel satisfied that appropriate actions are beingtaken to improve things. Of course, the opposite mayapply, and customers may feel dissatisfied with someissues (e.g. the manner of some staff on the Service Desk)when few or no SLA targets have been broken.

From the outset, it is wise to try to manage customers’expectations. This means setting proper expectations andappropriate targets in the first place, and putting asystematic process in place to manage expectations goingforward, as satisfaction = perception – expectation (wherea zero or positive score indicates a satisfied customer).

SLAs are just documents, and in themselves do notmaterially alter the quality of service being provided(though they may affect behaviour and help engender anappropriate service culture, which can have an immediatebeneficial effect, and make longer-term improvementspossible). A degree of patience is therefore needed andshould be built into expectations.

5.7.3 Key performance indicatorsKey performance indicators (KPIs) and metrics can be usedto judge the efficiency and effectiveness of the SLMactivities and the progress of the SIP. These metrics shouldbe developed from the service, customer and businessperspective and should cover both subjective andobjective measurements such as the following.

� Objective:

� Number or percentage of service targets being met� Number and severity of service breaches� Number of services with up-to-date SLAs� Number of services with timely reports and active

service reviews� Subjective:

� Improvements in customer satisfaction.

Practising SLM can achieve a high trust factor between thebusiness and the service provider. It establishes a patternof quality and service management practices,demonstrated through reporting and interaction with thecustomer over time, that can instil a sense of trust andexpectation from the business, which in turn engendersloyalty. No service provider should underestimate howimportant SLM is. The Service Design core publicationoffers detailed guidance in SLM.

5.8 CAPACITY MANAGEMENT

Capacity Management is a process that extends across theService Lifecycle. A key success factor in managingcapacity is ensuring it is considered during the Service


7238-TSO-ITIL-13 28/8/07 14:01 Page 55

Design stage. It is for this reason that the CapacityManagement Process is included in this book. CapacityManagement is supported initially in Service Strategywhere the decisions and analysis of business requirementsand customer outcomes influencing the development ofpatterns of business activity (PBA), levels of service (LOS)and service level packages (SLPs) are identified. Thisprovides the predictive and ongoing capacity indicatorsneeded to align capacity to demand. An example of acomponent-based SLP is illustrated in Figure 5.4.

Capacity Management ensures that the capacity andperformance of the IT services and systems match theevolving agreed demands of the business in the most

cost-effective and timely manner. Capacity Management isessentially a balancing act:

� Balancing costs against resources needed: the need toensure that processing Capacity that is purchased isnot only cost-justifiable in terms of business need, butalso makes the most efficient use of those resources

� Balancing supply against demand: the need to ensurethat the available supply of IT processing powermatches the demands made on it by the business,both now and in the future; it may also be necessaryto manage or influence the demand for a particularresource.


Figure 5.4 Component-based Service Level Package

Dataencryption

service

StandardE-mail

WirelessVoice &

DataDial-tone

Onsitesupport

‘24x7x365’

WorldwideMobility

Componentservice

Customerasset

Service asset

Service Components

3G Wireless Phone Desktop Phone Office FaxNotebook PCHardware

security token

7238-TSO-ITIL-13 28/8/07 14:01 Page 56

The objectives of Capacity Management are to:

� Produce and maintain an appropriate and up-to-dateCapacity Plan, which reflects the current and futureneeds of the business

� Provide advice and guidance to all other areas of thebusiness and IT on all capacity- and performance-related issues

� Ensure that service performance achievements meet orexceed all of their agreed performance targets, bymanaging the performance and capacity of bothservices and resources

� Assist with the diagnosis and resolution ofperformance- and capacity-related incidents andproblems

� Assess the impact of all changes on the Capacity Plan,and the performance and capacity of all services andresources

� Ensure that proactive measures to improve theperformance of services are implemented wherever itis cost-justifiable to do so.

The Capacity Management process should include:

� Monitoring patterns of business activity and servicelevel plans through performance, utilization andthroughput of IT services and the supportinginfrastructure, environmental, data and applicationscomponents and the production of regular and ad hocreports on service and component capacity andperformance

� Undertaking tuning activities to make the mostefficient use of existing IT resources

� Understanding the agreed current and future demandsbeing made by the customer for IT resources andproducing forecasts for future requirements

� Influencing demand management, perhaps inconjunction with Financial Management

� Producing a Capacity Plan that enables the ServiceProvider to continue to provide services of the qualitydefined in SLAs and that covers a sufficient planningtimeframe to meet future service levels required asdefined in the Service Portfolio and SLRs

� Assistance with the identification and resolution of anyIncidents and Problems associated with service orcomponent performance

� The proactive improvement of service or componentperformance wherever it is cost-justifiable and meetsthe needs of the business.

The elements of Capacity Management are illustrated inFigure 5.5.

5.8.1 Business Capacity ManagementThis sub-process translates business needs and plans intorequirements for service and IT infrastructure, ensuring thatthe future business requirements for IT services arequantified, designed, planned and implemented in a timelyfashion. This can be achieved by using the existing data onthe current resource utilization by the various services andresources to trend, forecast, model or predict futurerequirements. These future requirements come from theService Strategy and Service Portfolio detailing newprocesses and service requirements, changes, improvementsand also the growth in the already existing services.

5.8.2 Service Capacity ManagementThe focus of this sub-process is the management, controland prediction of the end-to-end performance andcapacity of the live, operational IT services usage andworkloads. It ensures that the performance of all services,as detailed in service targets within SLAs and SLRs, ismonitored and measured, and that the collected data isrecorded, analysed and reported. Wherever necessary,proactive and reactive action should be instigated, toensure that the performance of all services meets theiragreed business targets. This is performed by staff with


7238-TSO-ITIL-13 28/8/07 14:01 Page 57

knowledge of all the areas of technology used in thedelivery of end-to-end service, and often involves seekingadvice from the specialists involved in Resource CapacityManagement. Wherever possible, automated thresholdsshould be used to manage all operational services toensure that situations where service targets are breachedor threatened are rapidly identified and cost-effectiveactions to reduce or avoid their potential impactimplemented.

5.8.3 Component Capacity ManagementThe focus in this sub-process is the management, controland prediction of the performance, utilization and capacityof individual IT technology components. It ensures that allcomponents within the IT infrastructure that have finiteresource are monitored and measured, and that thecollected data is recorded, analysed and reported. Again,wherever possible, automated thresholds should beimplemented to manage all components, to ensure thatsituations where service targets are breached orthreatened by component usage or performance arerapidly identified, and cost-effective actions to reduce oravoid their potential impact are implemented.

There are many similar activities that are performed byeach of the above sub-processes, but each sub-processhas a very different focus. Business Capacity Managementis focused on the current and future businessrequirements, while Service Capacity Management isfocused on the delivery of the existing services thatsupport the business, and Component CapacityManagement is focused on the IT infrastructure thatunderpins service provision.

� The Capacity Management Information System(CMIS): holds the information needed by allsub-processes within Capacity Management. Forexample, the data monitored and collected as part ofResource and Service Capacity Management is used in

Business Capacity Management to determine whatinfrastructure components or upgrades to componentsare needed, and when

� The Capacity Plan: used by all areas of the businessand IT management and is acted on by the IT ServiceProvider and senior management of the organizationto plan the capacity of the IT infrastructure, it alsoprovides planning input to many other areas of IT andthe business. It contains information on the currentusage of service and components and plans for thedevelopment of IT capacity to meet the needs in thegrowth of both existing service and any agreed newservices. The Capacity Plan should be actively used as abasis of decision-making. Too often Capacity Plans arecreated and never referred to or used

� Service performance information and reports: usedby many other processes. For example, the CapacityManagement process assists Service Level Managementwith the reporting and reviewing of serviceperformance and the development of new SLRs orchanges to existing SLAs. It also assists the FinancialManagement process by identifying when moneyneeds to be budgeted for IT infrastructure upgrades, orthe purchase of new components

� Workload analysis and reports: used by IT operationsto assess and implement changes in conjunction withCapacity Management to schedule or re-schedulewhen services or workloads are run, to ensure that themost effective and efficient use is made of theavailable resources

� Ad hoc capacity and performance reports: used byall areas of Capacity Management, IT and the businessto analyse and resolve service and performance issues

� Forecasts and predictive reports: used by all areas toanalyse, predict and forecast particular business and ITscenarios and their potential solutions

� Thresholds, alerts and events.


7238-TSO-ITIL-13 28/8/07 14:01 Page 58


Figure 5.5 Capacity Management elements

Review currentcapacity & performance

Improve current service& component capacity

Assess, agree &document new

requirements & capacity

Plan new capacity

Capacity &performance

reports

Capacity Plan

Forecasts

Capacity ManagementInformation System

(CMIS)

BusinessCapacity Management

ServiceCapacity Management

ComponentCapacity Management

SLA/SLRIT servicedesign

CapacityManagement

Tools

Service Portfolio

Businessrequirements

7238-TSO-ITIL-13 28/8/07 14:01 Page 59

Additional detailed guidance can be found in the ServiceDesign publication.

5.9 AVAILABILITY MANAGEMENT

Availability Management is the window of service qualityto a business customer. A Service Provider who does notapply solid practices to AM and who cannot offer reliable,stable service availability will never have a customer’sloyalty.

The objectives of Availability Management are to:

� Produce and maintain an appropriate and up-to-dateAvailability Plan that reflects the current and futureneeds of the business

� Provide advice and guidance to all other areas of thebusiness and IT on all availability-related issues

� Ensure that service availability achievements meet orexceed all of their agreed targets, by managing service-and resource-related availability performance

� Assist with the diagnosis and resolution of availability-related Incidents and Problems

� Assess the impact of all changes on the AvailabilityPlan and the performance and capacity of all servicesand resources

� Ensure that proactive measures to improve theavailability of services are implemented wherever it iscost-justifiable to do so.

Availability Management should ensure the agreed level ofavailability is provided. The measurement and monitoringof IT availability is a key activity to ensure availability levelsare being met consistently. Availability Managementshould look to continually optimize and proactivelyimprove the availability of the IT infrastructure, the servicesand the supporting organization, in order to provide cost-effective availability improvements that can deliverbusiness and customer benefits.

The Availability Management process should include:

� Monitoring of all aspects of availability, reliability andmaintainability of IT services and the supportingcomponents, with appropriate events, alarms andescalation, with automated scripts for recovery

� Maintenance of a set of methods, techniques andcalculations for all availability measurements, metricsand reporting

� Assistance with risk assessment and managementactivities

� Collection of measurements, analysis and production ofregular and ad hoc reports on service and componentavailability

� Understanding the agreed current and future demandsof the business for IT services and their availability

� Influencing the design of services and components toalign with business needs

� Producing an Availability Plan that enables the ServiceProvider to continue to provide and improve servicesin line with availability targets defined in SLAs and toplan and forecast future availability levels required asdefined in SLRs

� Maintaining a schedule of tests for all resilient andfailover components and mechanisms

� Assistance with the identification and resolution of anyIncidents and Problems associated with service orcomponent unavailability

� Proactive improvement of service or componentavailability wherever it is cost-justifiable and meets theneeds of the business.


7238-TSO-ITIL-13 28/8/07 14:01 Page 60

The Availability Management process (Figure 5.6) has twokey elements:

� Reactive activities: the reactive aspect of AvailabilityManagement involves the monitoring, measuring,analysis and management of all events, Incidents andProblems involving unavailability. These activities areprincipally involved within operational roles

� Proactive activities: the proactive activities ofAvailability Management involve the proactiveplanning, design and improvement of availability.These activities are principally involved within designand planning roles.

Availability Management is completed at twointerconnected levels:

� Service availability: involves all aspects of serviceavailability and unavailability and the impact ofcomponent availability, or the potential impact ofcomponent unavailability on service availability

� Component availability: involves all aspects ofcomponent availability and unavailability.

A guiding principle of Availability Management is torecognize that it is still possible to gain customersatisfaction even when things go wrong. One approach tohelp achieve this requires Availability Management toensure that the duration of any Incident is minimized toenable normal business operations to resume as quickly asis possible. An aim of Availability Management is to ensurethe duration and impact from Incidents impacting ITservices are minimized, to enable business operations toresume as quickly as is possible. The analysis of the‘expanded incident lifecycle’ enables the total IT servicedowntime for any given Incident to be broken down andmapped against the major stages that all Incidentsprogress through (the lifecycle). Availability Managementshould work closely with Incident Management andProblem Management in the analysis of all Incidentscausing unavailability.

5.9.1 Identifying vital business functions

The term ‘vital business function’ (VBF) is used to reflectthe business-critical elements of the business processsupported by an IT service. The service may also supportless critical business functions and processes. It isimportant that the VBFs are recognized and documentedto provide the appropriate business alignment and focus.

5.9.2 Designing for availabilityThe level of availability required by the business influencesthe overall cost of the IT service provided. In general, thehigher the level of availability required by the business thehigher the cost. These costs are not just the procurementof the base IT technology and services required tounderpin the IT infrastructure. Additional costs are incurredin providing the appropriate service managementprocesses, systems management tools and high availabilitysolutions required to meet the more stringent availabilityrequirements. The greatest level of availability should beincluded in the design of those services supporting themost critical of the VBFs.

When considering how the availability requirements of thebusiness are to be met, it is important to ensure that thelevel of availability to be provided for an IT service is atthe level actually required and is affordable and cost-justifiable to the business (Figure 5.7).


7238-TSO-ITIL-13 28/8/07 14:01 Page 61

5.9.3 Service Failure AnalysisService Failure Analysis (SFA) is a technique designed toprovide a structured approach to identifying theunderlying causes of service interruptions to the user. SFAutilizes a range of data sources to assess where and whyshortfalls in availability are occurring. SFA enables a holisticview to be taken to drive not just technologyimprovements, but improvements to the IT supportorganization, processes, procedures and tools. SFA is runas an assignment or project and may utilize otherAvailability Management methods and techniques toformulate the recommendations for improvement. Thedetailed analysis of service interruptions can identify

opportunities to enhance levels of availability. SFA is astructured technique to identify improvementopportunities in end-to-end service availability that candeliver benefits to the user. Many of the activities involvedin SFA are closely aligned with those of ProblemManagement and in a number of organizations theseactivities are performed jointly by Problem and AvailabilityManagement.

The high-level objectives of SFA are:

� To improve the overall availability of IT services byproducing a set of improvements for implementationor input to the Availability Plan


Figure 5.6 The Availability Management process

AvailabilityManagementInformation

System (AMIS)

AvailabilityManagementreports

AvailabilityPlan

Availabilitydesign criteria

Availabilitytestingschedule

Review all new &changed services & test

all availability &resilience mechanisms

Plan & design fornew & changed

services

Risk assessment& Management

Implement cost –justifiable

countermeasures

Proactive activities

Monitor, measure,analyse report & review

service &component availability

Investigate all service &component unavailability

& instigate remedialaction

Reactive activities

7238-TSO-ITIL-13 28/8/07 14:01 Page 62

� To identify the underlying causes of service interruptionto users

� To assess the effectiveness of the IT supportorganization and key processes

� To produce reports detailing the major findings andrecommendations

� To ensure availability improvements derived from SFA-driven activities are measured.

SFA initiatives should use input from all areas and allprocesses including, most importantly, the business andusers. Each SFA assignment should have a recognizedsponsor(s) (ideally, joint sponsorship from the IT and

business) and involve resources from many technical andprocess areas. The use of the SFA approach:

� Provides the ability to deliver enhanced levels ofavailability without major cost

� Provides the business with visible commitment fromthe IT support organization

� Develops in-house skills and competencies to avoidexpensive consultancy assignments related toavailability improvement

� Encourages cross-functional team working and breaksbarriers between teams and is an enabler to lateralthinking, challenging traditional thoughts andproviding innovative and often inexpensive solutions


Figure 5.7 Relationship between levels of availability and overall costs

Cost

s

Specialsolutionswithredundancy

Highavailabilitydesign

EffectiveServiceManagement

SystemsManagement

Base products,technology andcomponents

Availability

7238-TSO-ITIL-13 28/8/07 14:01 Page 63

� Provides a programme of improvement opportunitiesthat can make a real difference to service quality anduser perception

� Provides opportunities that are focused on deliveringbenefit to the user

� Provides an independent healthcheck of IT servicemanagement processes and is the stimulus for processimprovements.

Designing for availability is a key activity, driven byAvailability Management, which ensures that the statedavailability requirements for an IT service can be met.However, Availability Management should also ensure thatwithin this design activity there is focus on the designelements required to ensure that when IT services fail, theservice can be reinstated to enable normal businessoperations to resume as quickly as is possible. ‘Designingfor Recovery’ may at first sound negative. Clearly goodavailability design is about avoiding failures and deliveringwhere possible a fault-tolerant IT infrastructure. However,with this focus, is too much reliance placed on technologyand has as much emphasis been placed on the fault-tolerant aspects of the IT infrastructure? The reality is thatfailures will occur. The way the IT organization managesfailure situations can have a positive effect on theperception of the business, customers and users of the ITservices.

Key messageEvery failure is an important moment of truth – anopportunity to make or break your reputation withthe business.

The process of Availability Management contains anumber of methods, techniques and practices forassessing, preventing and analysing service failures.Details about these methods can be found in theService Design publication.

5.10 IT SERVICE CONTINUITY MANAGEMENT

Service failures of extreme magnitude are not somethingany business or service provider wants to experience. Eventhe best-planned and managed services however, can bethe victim of catastrophic failure through events that arenot in the direct control of a service provider.

Most of us purchase insurance to protect us in the eventsomething of great value, such as our home, becomes thevictim of a catastrophic event. Insurance gives us peace ofmind that if the unplanned happens, we have the meansto recover from such disasters. The amount of insurancewe purchase is gauged on the predicted replacementvalue of our possessions, the likelihood such a disastercould happen and how quickly we can restore our losses.This is a form of risk management.

IT Service Continuity Management is the part of ITILpractice that evaluates the level of insurance we need toprotect service assets and a manuscript to recover from adisaster.

The goal of ITSCM is to support the overall BusinessContinuity Management process by ensuring that therequired IT technical and service facilities (includingcomputer systems, networks, applications, datarepositories, telecommunications, environment, technicalsupport and Service Desk) can be resumed withinrequired, and agreed, business timescales.

The objectives of ITSCM are to:

� Maintain a set of IT Service Continuity Plans and ITrecovery plans that support the overall BusinessContinuity Plans (BCPs) of the organization

� Complete regular Business Impact Analysis (BIA)exercises to ensure that all continuity plans aremaintained in line with changing business impacts andrequirements


7238-TSO-ITIL-13 28/8/07 14:01 Page 64

� Conduct regular risk assessment and managementexercises in conjunction particularly with the businessand the Availability Management and SecurityManagement processes that manages IT services withinan agreed level of business risk

� Provide advice and guidance to all other areas of thebusiness and IT on all continuity- and recovery-relatedissues

� Ensure that appropriate continuity and recoverymechanisms are put in place to meet or exceed theagreed business continuity targets

� Assess the impact of all changes on the IT ServiceContinuity Plans and IT recovery plans

� Ensure that proactive measures to improve theavailability of services are implemented wherever it iscost-justifiable to do so

� Negotiate and agree the necessary contracts withsuppliers for the provision of the necessary recoverycapability to support all continuity plans in conjunctionwith the Supplier Management process.

The ITSCM process includes:

� The agreement of the scope of the ITSCM process andthe policies adopted

� Business Impact Analysis (BIA) to quantify the impactthat loss of IT service would have on the business

� Risk analysis – the risk identification and riskassessment to identify potential threats to continuityand the likelihood of the threats becoming reality. Thisalso includes taking measures to manage the identifiedthreats where this can be cost-justified

� Production of an overall ITSCM strategy that must beintegrated into the BCM strategy. This can be producedfollowing the two steps identified above and is likely toinclude elements of risk reduction as well as selectionof appropriate and comprehensive recovery options

� Production of ITSCM plans, which again must beintegrated with the overall BCM plans

� Testing of the plans

� The ongoing operation and maintenance of the plans.

Service continuity is implemented and managed in fourstages (Figure 5.8):

1 Initiation – Policy setting, defining scope and terms ofreference, project planning and resource allocation

2 Requirements and strategy – Business impactanalysis, risk assessment

3 Implementation – Executing risk reduction measures,recovery option arrangements, testing the plans

4 Ongoing operation – Education and awareness,change control of ITSCM plans, ongoing testing.

A good place to start is by assessing the threats and risksto VBFs (as described in the preceding section onAvailability Management). This will help revealvulnerabilities to vital business operations and ensure thatpreventative and recovery plans and mechanisms are inplace. Consistent with the ITSCM process, this should becontinually evaluated to ensure that changes to services orbusiness requirements have not affected the ability of theITSCM process to be effective when needed.

The Service Design core publication offers detailedguidance on how to establish and maintain ITSCM.


7238-TSO-ITIL-13 28/8/07 14:01 Page 65

5.11 INFORMATION SECURITY MANAGEMENT

Across the world, organizations create value through theintellectual property they own and use to deliver productsand services. Protecting intellectual capital is a primaryneed for business and is increasingly legislated by law. Thetechnology today offers us unlimited potential to create,gather and amass vast quantities of information. A serviceprovider is responsible to ensure that they can guaranteethe business information is protected from intrusion, theft,loss and unauthorized access.

Information security is a management activity within thecorporate governance framework, which provides thestrategic direction for security activities and ensuresobjectives are achieved. It further ensures that that theinformation security risks are appropriately managed andenterprise information resources are used responsibly. The

purpose of ISM is to provide a focus for all aspects of ITsecurity and manage all IT security activities.

The term ‘information’ is used as a general term andincludes data stores, databases and metadata. Theobjective of information security is to protect the interestsof those relying on information, and the systems andcommunications that deliver the information, from harmresulting from failures of availability, confidentiality andintegrity.

For most organizations, the security objective is met when:

� Information is available and usable when required, andthe systems that provide it can appropriately resistattacks and recover from or prevent failures(availability)

� Information is observed by or disclosed to only thosewho have a right to know (confidentiality)


Figure 5.8 Service Continuity lifecycle

Invocation

Requirementsand strategy

Initiation

Implementation

OngoingOperation

Policy settingScopeInitiate a project

Business Impact AnalysisRisk AssessmentIT Service Continuity Strategy

Develop IT Service Continuity PlansDevelop IT plans, recovery plans andproceduresOrganisation PlanningTesting strategy

Education, awareness and trainingReview and auditTestingChange Management

BusinessContinuityStrategy

BusinessContinuity

Plans

BusinessContinuityManagement(BCM)

Lifecycle Key activities

7238-TSO-ITIL-13 28/8/07 14:01 Page 66

� Information is complete, accurate and protectedagainst unauthorized modification (integrity)

� Business transactions as well as information exchangesbetween enterprises, or with partners, can be trusted(authenticity and non-repudiation).

Prioritization of confidentiality, integrity and availabilitymust be considered in the context of business andbusiness processes. The primary guide to defining whatmust be protected and the level of protection has to comefrom the business. To be effective, security must addressentire business processes from end to end and cover thephysical and technical aspects. Only within the context ofbusiness needs and risks can management define security.

ISM activities should be focused on and driven by anoverall Information Security Policy and a set ofunderpinning specific security policies. The policy shouldhave the full support of top executive IT management andideally the support and commitment of top executivebusiness management. The policy should cover all areas ofsecurity, be appropriate, meet the needs of the businessand should include:

� An overall Information Security Policy

� Use and misuse of IT assets policy

� An access control policy

� A password control policy

� An e-mail policy

� An internet policy

� An anti-virus policy

� An information classification policy

� A document classification policy

� A remote access policy

� A policy with regard to supplier access of IT services,information and components

� An asset disposal policy.

These policies should be widely available to all customersand users and their compliance should be referred to in all

SLRs, SLAs, contracts and agreements. The policies shouldbe authorized by top executive management within thebusiness and IT, and compliance to them should beendorsed on a regular basis. All security policies should bereviewed and where necessary revised on at least anannual basis.

The five elements within an Information SecurityManagement System (ISMS) framework are:

� Control

The objectives of the control element of the ISMS areto:

� Establish a management framework to initiate andmanage information security in the organization

� Establish an organization structure to prepare,approve and implement the information securitypolicy

� Allocate responsibilities� Establish and control documentation

� Plan

The objective of the plan element of the ISMS is todevise and recommend the appropriate securitymeasures, based on an understanding of therequirements of the organization.

The requirements will be gathered from such sourcesas business and service risk, plans and strategies, SLAsand OLAs and the legal, moral and ethicalresponsibilities for information security. Other factors,such as the amount of funding available and theprevailing organization culture and attitudes tosecurity, must be considered.

The Information Security Policy defines theorganization’s attitude and stance on security matters.This should be an organization-wide document, notjust applicable to the IT Service Provider. Responsibilityfor the upkeep of the document rests with theInformation Security Manager


7238-TSO-ITIL-13 28/8/07 14:01 Page 67

� Implement

The objective of the implementation element of theISMS is to ensure that appropriate procedures, toolsand controls are in place to underpin the InformationSecurity Policy.

Amongst the measures are:

� Accountability for assets – ConfigurationManagement and the CMS are invaluable here

� Information classification – information andrepositories should be classified according to thesensitivity and the impact of disclosure

The successful implementation of the security controlsand measures is dependent on a number of factors:

� The determination of a clear and agreed policyintegrated with the needs of the business

� Security procedures that are justified, appropriateand supported by senior management

� Effective marketing and education in securityrequirements

� A mechanism for improvement

� Evaluation

The objectives of the evaluation element of the ISMSare to:

� Supervise and check compliance with the securitypolicy and security requirements in SLAs and OLAs

� Carry out regular audits of the technical security ofIT systems

� Provide information to external auditors andregulators, if required

� Maintain

The objectives of this maintain element of the ISMS areto:

� Improve on security agreements as specified in, forexample, SLAs and OLAs

� Improve the implementation of security measuresand controls

� This should be achieved using a PDCA (Plan-Do-Check-Act) cycle, which is a formal approachsuggested by ISO 27001 for the establishment ofthe ISMS or Framework. This cycle is described inmore detail in the Continual Service Improvementpublication.

Security measures can be used at a specific stage in theprevention and handling of security incidents, as illustratedin Figure 5.9. Security incidents are not solely caused bytechnical threats – statistics show that, for example, thelarge majority stem from human errors (intended or not)or procedural errors, and often have implications in otherfields such as safety, legal or health.

The following stages can be identified. At the start there isa risk that a threat will materialize. A threat can beanything that disrupts the business process or hasnegative impact on the business. When a threatmaterializes, we speak of a security incident. This securityincident may result in damage (to information or to assets)that has to be repaired or otherwise corrected. Suitablemeasures can be selected for each of these stages. Thechoice of measures will depend on the importanceattached to the information:

� Preventive: security measures are used to prevent asecurity incident from occurring. The best-knownexample of preventive measures is the allocation ofaccess rights to a limited group of authorized people.The further requirements associated with this measureinclude the control of access rights (granting,maintenance and withdrawal of rights), authorization(identifying who is allowed access to whichinformation and using which tools), identification andauthentication (confirming who is seeking access) andaccess control (ensuring that only authorized personnelcan gain access)


7238-TSO-ITIL-13 28/8/07 14:01 Page 68

� Reductive: further measures can be taken in advanceto minimize any possible damage that may occur.Familiar examples of reductive measures are makingregular backups and the development, testing andmaintenance of contingency plans

� Detective: if a security incident occurs, it is importantto discover it as soon as possible – detection. A familiarexample of this is monitoring, linked to an alertprocedure. Another example is virus-checking software

� Repressive: measures are then used to counteract anycontinuation or repetition of the security incident. Forexample, an account or network address is temporarilyblocked after numerous failed attempts to log on orthe retention of a card when multiple attempts aremade with a wrong PIN number

� Corrective: damage is repaired as far as possible usingcorrective measures. For example, corrective measuresinclude restoring the backup, or returning to aprevious stable situation (roll-back, back-out). Fallbackcan also been seen as a corrective measure.

The documentation of all controls should be maintainedto reflect accurately their operation, maintenance and theirmethod of operation.

ISM faces many challenges in establishing an appropriateInformation Security Policy with an effective supportingprocess and controls. One of the biggest challenges is toensure that there is adequate support from the business,business security and senior management. If these are notavailable, it will be impossible to establish an effective ISMprocess. If there is senior IT management support, but


Figure 5.9 IT Security Management process

InformationSecurityManagementSystem (ISMS)

InformationSecurity Policy(s)

Security reportsand information

Securitycontrols

Security risksand responses

Communicate,implement andenforce adherenceto all securitypolicies

Monitor andmanage securityincidents andbreaches

Assess andcategoriseinformation assets,risks andvulnerabilities

Produce andmaintain anInformationSecurity Policy

Regularlyassess, reviewand report securityrisks and threats

Impose andreview risksecurity controls,review andimplementrisk mitigation

Report, reviewand reduce securitybreaches andmajor incidents

7238-TSO-ITIL-13 28/8/07 14:01 Page 69

there is no support from the business, IT security controlsand risk assessment will be severely limited in what theycan achieve because of this lack of support from thebusiness. It is pointless implementing security policies,procedures and controls in IT if these cannot be enforcedthroughout the business. The major use of IT services andassets is outside of IT, and so are the majority of securitythreats and risks.

In some organizations the business perception is thatsecurity is an IT responsibility, and therefore the businessassumes that IT will be responsible for all aspects of ITsecurity and that IT services will be adequately protected.However, without the commitment and support of thebusiness and business personnel, money invested inexpensive security controls and procedures will be largelywasted and they will mostly be ineffective.

Refer to the Service Design core publication for furtherguidance and detailed practices on Information SecurityManagement.

5.12 SUPPLIER MANAGEMENT

The Supplier Management process ensures that suppliersand the services they provide are managed to support ITservice targets and business expectations. The aim of thissection is to raise awareness of the business context ofworking with partners and suppliers, and how this workcan best be directed toward realizing business benefit forthe organization.

It is essential that Supplier Management processes andplanning are involved in all stages of the Service Lifecycle,from strategy and design, through transition and operation,to improvement. The complex business demands requirethe complete breadth of skills and capability to supportprovision of a comprehensive set of IT services to abusiness, therefore the use of value networks and thesuppliers and the services they provide are an integral partof any end-to-end solution. Suppliers and the management

of suppliers and partners are essential to the provision ofquality IT services (see Figure 5.10).

The main objectives of the Supplier Management processare to:

� Obtain value for money from supplier and contracts

� Ensure that underpinning contracts and agreementswith suppliers are aligned to business needs, andsupport and align with agreed targets in SLRs andSLAs, in conjunction with SLM

� Manage relationships with suppliers

� Manage supplier performance

� Negotiate and agree contracts with suppliers andmanage them through their lifecycle

� Maintain a supplier policy and a supporting supplierand contract database (SCD).

The Supplier Management process should include:

� Implementation and enforcement of the supplier policy

� Maintenance of an SCD

� Supplier and contract categorization and riskassessment

� Supplier and contract evaluation and selection

� Development, negotiation and agreement of contracts

� Contract review, renewal and termination

� Management of suppliers and supplier performance

� Agreement and implementation of service and supplierimprovement plans

� Maintenance of standard contracts, terms andconditions

� Management of contractual dispute resolution

� Management of sub-contracted suppliers.

IT supplier management often has to comply withorganizational or corporate standards, guidelines andrequirements, particularly those of corporate legal, financeand purchasing.


7238-TSO-ITIL-13 28/8/07 14:01 Page 70

Satisfaction surveys also play an important role inrevealing how well supplier service levels are aligned tobusiness needs. A survey may reveal instances where thereis dissatisfaction with the service, yet the supplier isapparently performing well against its targets (and viceversa). This may happen where service levels areinappropriately defined and should result in a review ofthe contracts, agreements and targets. Some serviceproviders publish supplier league tables based on theirsurvey results stimulating competition between suppliers.

For those significant supplier relationships in which thebusiness has a direct interest, both the business (in

conjunction with the procurement department) and IT willhave established their objectives for the relationship, anddefined the benefits they expect to realize. This forms amajor part of the business case for entering into therelationship.

These benefits must be linked and complementary, andmust be measured and managed. Where the business isseeking improvements in customer service, then ITsupplier relationships contributing to those customerservices must be able to demonstrate improved service intheir own domain, and how much this has contributed toimproved customer service.


Figure 5.10 Supplier Management – roles and interfaces

Supplier Mgt.Process Owner

ContractsManager

Finance &Purchasing

Legal

SupplierManager 1

SupplierManager 2

SupplierManager 3

SupplierManager 4

Service Provider

Service Service Service Service Service Service

Supplier 6

Supplier 5

Supplier 4

Supplier 3

Supplier 2

Supplier 1 Sub-contractedSupplier 2

Sub-contractedSupplier 1

7238-TSO-ITIL-13 28/8/07 14:01 Page 71

Strong, trusted relationships with suppliers are an integralelement of successful service management and enhancethe value of any service provider to the business.

The Service Design book contains all the details to guideyou through Supplier Management and achieve this levelof relationships with suppliers.


7238-TSO-ITIL-13 28/8/07 14:01 Page 72

Service Transition –preparing for change 6

7238-TSO-ITIL-13 28/8/07 14:01 Page 73

7238-TSO-ITIL-13 28/8/07 14:01 Page 74

In the IT world, many business innovations are achievedthrough project initiatives that involve IT. In the end,whether these are minor operational improvements ormajor transformational events, they all produce change. Inthe preceding chapter we looked at creating andimproving services through the design stage of thelifecycle. Now we must ensure that what is planned to beimplemented will achieve the expected objectives. It is atthis point the knowledge that has been generated andthat will be needed to manage services once in the liveenvironment, must be managed and shared across theorganization. This is done through Service Transition.

In this chapter we will discuss a few of the key conceptswithin Service Transition:

� Transition Planning

� Asset and Configuration Management

� Release and Deployment Management

� Change Management

� Testing and Validation.

The purpose of Service Transition is to:

� Plan and manage the capacity and resources requiredto package, build, test and deploy a release intoproduction and establish the service specified in thecustomer and stakeholder requirements

| 75

6 Service Transition – preparing for change



Strategies

Policies

Requirements

ServiceStrategy


StandardsSDPs

SolutionDesigns

Architectures

ServiceDesign

SKMS

TransitionPlans

TestedSolutions

ServiceTransition

7238-TSO-ITIL-13 28/8/07 14:01 Page 75

� Provide a consistent and rigorous framework forevaluating the service capability and risk profile beforea new or changed service is released or deployed

� Establish and maintain the integrity of all identifiedservice assets and configurations as they evolvethrough the Service Transition stage

� Provide good-quality knowledge and information sothat Change and Release and DeploymentManagement can expedite effective decisions aboutpromoting a release through the test environmentsand into production

� Provide efficient repeatable build and installationmechanisms that can be used to deploy releases to thetest and production environments and be rebuilt ifrequired to restore service

� Ensure that the service can be managed, operated andsupported in accordance with the requirements andconstraints specified within the Service Design.

Effective Service Transition can significantly improve aService Provider’s ability to handle high volumes ofchange and releases across its customer base. It enablesthe Service Provider to:

� Align the new or changed service with the customer’sbusiness requirements and business operations

� Ensure that customers and users can use the new orchanged service in a way that minimizes value to thebusiness operations.

Specifically, Service Transition adds value to the businessby improving:

� The ability to adapt quickly to new requirements andmarket developments (‘competitive edge’)

� Transition management of mergers, de-mergers,acquisitions and transfer of services

� The success rate of changes and releases for thebusiness

� The predictions of service levels and warranties for newand changed services

� Confidence in the degree of compliance with businessand governance requirements during change

� The variation of actual against estimated and approvedresource plans and budgets

� The productivity of business and customer staffbecause of better planning and use of new andchanged services

� Timely cancellation or changes to maintenancecontracts for hardware and software when componentsare disposed or decommissioned

� Understanding of the level of risk during and afterchange, e.g. service outage, disruption and re-work.

The processes covered in Service Transition (see Figure 6.1)are:

� Transition Planning and Support


� Service Asset and Configuration Management

� Release and Deployment Management

� Service Validation and Testing

� Evaluation

� Knowledge Management.

6.1 TRANSITION PLANNING AND SUPPORT

The goals of Transition Planning and Support are to:

� Plan and coordinate the resources to ensure that therequirements of Service Strategy encoded in ServiceDesign are effectively realized in Service Operations

� Identify, manage and control the risks of failure anddisruption across transition activities.

The objectives of Transition Planning and Support are to:

� Plan and coordinate the resources to establishsuccessfully a new or changed service into productionwithin the predicted cost, quality and time estimates

76 | Service Transition – preparing for change

7238-TSO-ITIL-13 28/8/07 14:01 Page 76

Service Transition – preparing for change | 77

Figure 6.1 The Service Transition process

E3E2E1

Evaluation of a Change or Service (4.6)

Service Transition Planning and Support (4.1)

Oversee management of organization and stakeholder change (5)

BLBLBLBLBL BL BL

Service Asset and Configuration Management (4.3)

Continual Service Improvement

Early Life Support

Knowledge Management (4.7)

Focus of activityrelated toservicetransition

Other ITIL corepublication

ITIL process in thispublication that supportsthe wholeservice life cycle

E

BL

RFC

Point to Evaluate the Service Design

Point to capture Baseline

Request for Change

Release and Deployment Management (4.4)

RFC5RFC4RFC3RFC2RFC1

Change Management (4.2)

RFC6

ServiceStrategy

ServiceDesign

Plan andpreparerelease

Build andtest

Servicetesting and

pilots

Plan andprepare fordeployment

Transfer,deploy,retire

ServiceOperation

Review andclose service

transition

Service Validation and Testing (4.5)

7238-TSO-ITIL-13 28/8/07 14:01 Page 77

� Ensure that all parties adopt the common frameworkof standard re-usable processes and supportingsystems in order to improve the effectiveness andefficiency of the integrated planning and coordinationactivities

� Provide clear and comprehensive plans that enable thecustomer and business change projects to align theiractivities with the Service Transition plans.

The organization should decide the most appropriateapproach to Service Transition based on the size andnature of the core and supporting services, the numberand frequency of releases required, and any special needsof the users – for example, if a phased rollout is usuallyrequired over an extended period of time.

The Service Transition strategy defines the overallapproach to organizing Service Transition and allocatingresources. The aspects to consider are:

� Purpose, goals and objectives of Service Transition

� Context, e.g. service customer, contract portfolios

� Scope – inclusions and exclusions

� Applicable standards, agreements, legal, regulatory andcontractual requirements

� Organizations and stakeholders involved in transition

� Framework for Service Transition

� Criteria

� Identification of requirements and content of the newor changed service

� People

� Approach

� Deliverables from transition activities includingmandatory and optional documentation for each stage

� Schedule of milestones

� Financial requirements – budgets and funding.

Service Design will – in collaboration with customers,external and internal suppliers and other relevantstakeholders – develop the Service Design and document

it in a Service Design Package (SDP). The SDP includes thefollowing information that is required by the ServiceTransition team:

� Applicable service packages (e.g. Core Service Package,Service Level Package)

� Service specifications

� Service models

� Architectural design required to deliver the new orchanged Service including constraints

� Definition and design of each release package

� Detailed design of how the service components will beassembled and integrated into a release package

� Release and deployment plans

� Service Acceptance Criteria.

6.1.1 Planning an individual ServiceTransition

The release and deployment activities should be plannedin stages as details of the deployment might not beknown in detail initially. Each Service Transition planshould be developed from a proven Service Transitionmodel wherever possible. Although Service Designprovides the initial plan, the planner will allocate specificresources to the activities and modify the plan to fit inwith any new circumstances, e.g. a test specialist mayhave left the organization.

A Service Transition plan describes the tasks and activitiesrequired to release and deploy a release into the testenvironments and into production, including:

� Work environment and infrastructure for the ServiceTransition

� Schedule of milestones, handover and delivery dates

� Activities and tasks to be performed

� Staffing, resource requirements, budgets andtimescales at each stage

� Issues and risks to be managed


7238-TSO-ITIL-13 28/8/07 14:01 Page 78

� Lead times and contingency.

Allocating resources to each activity and factoring inresource availability will enable the Service Transitionplanner to work out whether the transition can bedeployed by the required date. If resources are notavailable, it may be necessary to review other transitioncommitments and consider changing priorities. Suchchanges need to be discussed with Change and ReleaseManagement as this may affect other changes that may bedependents or prerequisites of the release.

6.1.2 Integrated planningGood planning and management are essential to deploy arelease across distributed environments and locations intoproduction successfully. An integrated set of transitionplans should be maintained that are linked to lower-levelplans such as release, build and test plans. These plansshould be integrated with the change schedule, releaseand deployment plans. Establishing good-quality plans atthe outset enables Service Transition to manage andcoordinate the Service Transition resources, e.g. resourceallocation, utilization, budgeting and accounting.

An overarching Service Transition plan should include themilestone activities to acquire the release components,package the release, build, test, deploy, evaluate andproactively improve the service through early life support.It will also include the activities to build and maintain theservices and IT infrastructure, systems and environmentsand the measurement system to support the transitionactivities.

6.1.3 Adopting programme and projectmanagement best practices

It is best practice to manage several releases anddeployments as a programme, with each significantdeployment run as a project. The actual deployment maybe carried out by dedicated staff, as part of broader

responsibilities such as operations or through a teambrought together for the purpose. Elements of thedeployment may be delivered through external suppliers,and suppliers may deliver the bulk of the deploymenteffort, for example in the implementation of an off-the-shelf system such as an ITSM support tool.

Significant deployments will be complex projects in theirown right. The steps to consider in planning include therange of elements comprising that service, e.g. people,application, hardware, software, documentation andknowledge. This means that the deployment will containsub-deployments for each type of element comprising theservice.

6.1.4 Reviewing the plansThe planning role should quality review all ServiceTransition, release and deployment plans. Whereverpossible, lead times should include an element ofcontingency and be based on experience rather thanmerely supplier assertion. This applies even more forinternal suppliers where there is no formal contract. Leadtimes will typically vary seasonally and they should befactored into planning, especially for long timeframetransitions, where the lead times may vary between stagesof a transition, or between different user locations.

Before starting the release or deployment, the ServiceTransition planning role should verify the plans and askappropriate questions such as:

� Are these Service Transition and release plans up todate?

� Have the plans been agreed and authorized by allrelevant parties, e.g. customers, users, operations andsupport staff?

� Do the plans include the release dates and deliverablesand refer to related Change Requests, Known Errorsand Problems?


7238-TSO-ITIL-13 28/8/07 14:01 Page 79

� Have the impacts on costs, organizational, technicaland commercial aspects been considered?

� Have the risks to the overall services and operationscapability been assessed?

� Has there been a compatibility check to ensure thatthe Configuration Items that are to be released arecompatible with each other and with ConfigurationItems in the target environments?

� Have circumstances changed such that the approachneeds amending?

� Were the rules and guidance on how to apply itrelevant for current service and release packages?

� Do the people who need to use it understand andhave the requisite skills to use it?

� Is the service release within the SDP and scope of whatthe transition model addresses?

� Has the Service Design altered significantly such that itis no longer appropriate?

� Have potential changes in business circumstances beenidentified?

Proper planning of service transition and support willreduce the need for corrective measures during and afterrelease into live operation. Refer to the Service Transitioncore publication for full details on the Transition Planningand Support process.

6.2 CHANGE MANAGEMENT

The purpose of the Change Management process is toensure that:

� Standardized methods and procedures are used forefficient and prompt handling of all changes

� All changes to Service Assets and Configuration Itemsare recorded in the configuration management system

� Overall business risk is optimized.

The goals of Change Management are to:

� Respond to the customer’s changing businessrequirements while minimizing value and reducingincidents, disruption and re-work

� Respond to the business and IT requests for changethat will align the services with the business needs.

Reliability and business continuity are essential for thesuccess and survival of any organization. Service andinfrastructure changes can have a negative impact on thebusiness through service disruption and delay inidentifying business requirements, but ChangeManagement enables the service provider to add value tothe business by:

� Prioritizing and responding to business and customerchange proposals

� Implementing changes that meet the customers’agreed service requirements while optimizing costs

� Contributing to meet governance, legal, contractualand regulatory requirements

� Reducing failed changes and therefore servicedisruption, defects and re-work

� Delivering change promptly to meet businesstimescales

� Tracking changes through the Service Lifecycle and tothe assets of its customers

� Contributing to better estimations of the quality, timeand cost of change

� Assessing the risks associated with the transition ofservices (introduction or disposal)

� Aiding productivity of staff through minimizingdisruptions due to high levels of unplanned orEmergency Change and hence minimizing serviceavailability

� Reducing the mean time to restore service (MTRS), viaquicker and more successful implementations ofcorrective changes


7238-TSO-ITIL-13 28/8/07 14:01 Page 80

� Liaising with the business change process to identifyopportunities for business improvement.

Policies that support Change Management include:

� Creating a culture of Change Management across theorganization where there is zero tolerance forunauthorized change

� Aligning the service Change Management process withbusiness, project and stakeholder change managementprocesses

� Prioritization of change, e.g. innovation vs preventivevs detective vs corrective change

� Establishing accountability and responsibilities forchanges through the Service Lifecycle

� Segregation of duty controls

� Establishing a single focal point for changes in order tominimize the probability of conflicting changes andpotential disruption to the production environment

� Preventing people who are not authorized to make achange from having access to the productionenvironment

� Integration with other service management processesto establish traceability of change, detect unauthorizedchange and identify change-related incidents

� Change windows – enforcement and authorization forexceptions

� Performance and risk evaluation of all changes thatimpact service capability

� Performance measures for the process, e.g. efficiencyand effectiveness.

6.2.1 The seven Rs of Change ManagementThe following questions must be answered for all changes.Without this information, the impact assessment cannotbe completed, and the balance of risk and benefit to thelive service will not be understood. This could result in thechange not delivering all the possible or expected

business benefits or even having a detrimental,unexpected effect on the live service.

� Who RAISED the change?

� What is the REASON for the change?

� What is the RETURN required from the change?

� What are the RISKS involved in the change?

� What resources are REQUIRED to deliver the change?

� Who is RESPONSIBLE for the build, test andimplementation of the change?

� What is the RELATIONSHIP between this change andother changes?

The Request for Change (RFC) is a key information sourceand the catalyst for the change activities of:

� Create and record

� Review

� Assess and evaluate

� Authorize

� Plan

� Coordinate

� Review

� Close.

Each RFC will follow a selected Change Model that isappropriate for the nature and type of change. ChangeModels are pre-established process flows with thenecessary steps to satisfy the type of change and level ofauthorization needed to properly assess risk and impact.

Three basic Change Models are included in ServiceTransitions which can be adapted to suit individualorganizational circumstances and need.

� Standard Change Model – Used for pre-authorizedrepetitive, low-risk, well-tested changes. Often thesewill be the model used for service operationalmaintenance changes


7238-TSO-ITIL-13 28/8/07 14:01 Page 81

� Normal Change Model – The full model for changesthat must go through assessment, authorization andChange Advisory Board (CAB) agreement beforeimplementation

� Emergency Change Model – A model reserved onlyfor highly critical changes needed to restore failed highavailability or widespread service failure, or that willprevent such a failure from imminently occurring.

Figure 6.2 depicts the high-level flow of a Normal ChangeModel.


Figure 6.2 Normal Change Model

CreateRFC

Changeproposal (optional)

Record theRFC

ReviewRFC

Assess and evaluatechange

AuthorizeChange

Plan updates

Work orders

Initiator

ChangeManagement

ChangeAuthority

ChangeManagement

ready for evaluation

ready for decision

authorized

Update change and configuration inform

ation in CM

S

Work orders

Co-ordinate changeimplementation*

Review and closechange record

ChangeManagement

scheduled

implemented

closed

requested

Evaluation report

AuthorizeChange proposal

*Includes build and test the change

7238-TSO-ITIL-13 28/8/07 14:01 Page 82

6.2.2 Change Advisory BoardThe CAB is a body that exists to support the authorizationof changes and to assist Change Management in theassessment and prioritization of changes. As and when aCAB is convened, members should be chosen who arecapable of ensuring that all changes within the scope ofthe CAB are adequately assessed from both a business anda technical viewpoint.

The CAB may be asked to consider and recommend theadoption or rejection of changes appropriate for higherlevel authorization and then recommendations will besubmitted to the appropriate change authority.

To achieve this, the CAB needs to include people with aclear understanding across the whole range of stakeholderneeds. The Change Manager will normally chair the CABand potential members include:

� Customer(s)

� User manager(s)

� User group representative(s)

� Applications developers/maintainers

� Specialists/technical consultants

� Services and operations staff, e.g. Service Desk, testmanagement, ITSCM, security, capacity

� Facilities/office services staff (where changes may affectmoves/accommodation and vice versa)

� Contractor’s or third parties’ representatives, e.g. inoutsourcing situations.

The Service Transition core publication contains the fullChange Management process.

6.3 ASSET AND CONFIGURATIONMANAGEMENT

Within the human body lie a number of intricate systems.The respiratory, nervous and circulatory systems havedistinct functions, but they also have a critical dependency

on one another. If one system fails, the others willeventually succumb, unless provided additional life-supporting intervention. Services are systems with similarlevels of interdependency. These are service assets whichhave configurations specific to the functions they performand, ultimately, the service they collectively deliver.

No organization can be fully efficient or effective unless itmanages its assets well, particularly those assets that arevital to the running of the customer’s or organization’sbusiness. This process manages the service assets in orderto support the other service management processes.

The goal of optimizing the performance of service assetsand configurations improves the overall serviceperformance and optimizes the costs and risks caused bypoorly managed assets, e.g. service outages, fines, correctlicence fees and failed audits.

Service Asset and Configuration Management (SACM)provides visibility of accurate representations of a service,release, or environment that enable:

� Better forecasting and planning of changes

� Changes and releases to be assessed, planned anddelivered successfully

� Incidents and Problems to be resolved within theservice level targets

� Service levels and warranties to be delivered

� Better adherence to standards, legal and regulatoryobligations (fewer non-conformances)

� More business opportunities as able to demonstratecontrol of assets and services

� Changes to be traceable from requirements

� Creation of the ability to identify the costs for a service.

6.3.1 Configuration ItemsA Configuration Item (CI) is an asset, service component orother item which is, or will be, under the control ofConfiguration Management. CIs may vary widely in


7238-TSO-ITIL-13 28/8/07 14:01 Page 83

complexity, size and type, ranging from an entire serviceor system including all hardware, software, documentationand support staff to a single software module or a minorhardware component. CIs may be grouped and managedtogether, e.g. a set of components may be grouped into arelease. CIs should be selected using established selectioncriteria, grouped, classified and identified in such a waythat they are manageable and traceable throughout theService Lifecycle.

There will be a variety of CIs; the following categories mayhelp to identify them.

� Service Lifecycle CIs such as the Business Case,service management plans, Service Lifecycle plans,Service Design Package, release and change plans, andtest plans. They provide a picture of the ServiceProvider’s services, how these services will bedelivered, what benefits are expected, at what cost,and when they will be realized

� Service CIs such as:

� Service capability assets: management,organization, processes, knowledge, people

� Service resource assets: financial capital, systems,applications, information, data, infrastructure andfacilities, people

� Service model� Service package� Release package� Service acceptance criteria

� Organization CIs – some documentation will definethe characteristics of a CI whereas otherdocumentation will be a CI in its own right and needto be controlled, e.g. the organization’s businessstrategy or other policies that are internal to theorganization but independent of the Service Provider.Regulatory or statutory requirements also form externalproducts that need to be tracked, as do productsshared between more than one group

� Internal CIs comprising those delivered by individualprojects, including tangible (data centre) andintangible assets such as software that are required todeliver and maintain the service and infrastructure

� External CIs such as external customer requirementsand agreements, releases from suppliers or sub-contractors and external services

� Interface CIs that are required to deliver the end-to-end service across a Service Provider Interface (SPI).

6.3.2 Configuration Management SystemTo manage large and complex IT services andinfrastructures, Service Asset and ConfigurationManagement (SACM) requires the use of a supportingsystem known as the Configuration Management System(CMS).

The CMS holds all the information for CIs within thedesignated scope. Some of these items will have relatedspecifications or files that contain the contents of the item,e.g. software, document or photograph. For example, aService CI will include the details such as supplier, cost,purchase date and renewal date for licences andmaintenance contracts and the related documentationsuch as SLAs and underpinning contracts.

The CMS is also used for a wide range of purposes; forexample asset data held in the CMS may be madeavailable to external financial asset management systemsto perform specific asset management process reportingoutside configuration management.

The CMS maintains the relationships between all servicecomponents and any related incidents, problems, knownerrors, change and release documentation and may alsocontain corporate data about employees, suppliers,locations and business units, customers and users.


7238-TSO-ITIL-13 28/8/07 14:01 Page 84

Attributes for Configuration Items

Attributes describe the characteristics of a CI that arevaluable to record and which will support SACM and theITSM processes it supports.

The SACM plan references the configuration informationand data architecture. This includes the attributes to berecorded for each type of asset or CI. Typical attributesinclude:

� Unique identifier

� CI type

� Name/description

� Version (e.g. file, build, baseline, release)

� Location

� Supply date

� Licence details, e.g. expiry date

� Owner/custodian

� Status

� Supplier/source

� Related document masters

� Related software masters

� Historical data, e.g. audit trail

� Relationship type

� Applicable SLA.

These attributes will define specific functional and physicalcharacteristics of each type of asset and CI, e.g. size orcapacity, together with any documentation orspecifications.

The business value of SACM is often not recognized untilthe use of the CMS is used with other servicemanagement processes within the Service Lifecycle. TheCMS is part of a larger Service Knowledge ManagementSystem (see the Service Transition core publication) thatdrives the effectiveness and value of service knowledge.

CI information is critical for responsive service provisionand assists in areas such as:

� Service Desk – impact of service failure, SLA targetsassociated to the service that the CI(s) are supporting,owner and technical support information, recentchanges to the CI to aid in Incident triage

� Event Management – trending of events loggedagainst CI for possible service stability issues

� Incident Management – logging of faults against CIsand ability to see upstream and downstream impacts

� Financial Management – asset and replacementlifecycle information, contributing the service valuationactivities

� Availability and Continuity – identification of point offailure vulnerability through CI relationship andredundancy information in the CMS

� Service Level Management – identifying dependenciesand relationships of components that contribute to anend-to-end service

� Change Management – identification of impact ofchanges to services.


7238-TSO-ITIL-13 28/8/07 14:01 Page 85

6.4 RELEASE AND DEPLOYMENTMANAGEMENT

Effective Release and Deployment Management practicesenable the Service Provider to add value to the business by:

� Delivering change, faster and at optimum cost andminimized risk

� Assuring that customers and users can use the new orchanged service in a way that supports the businessgoals

� Improving consistency in implementation approachacross the business change and service teams,suppliers and customers

� Contributing to meeting auditable requirements fortraceability through Service Transition.

Well-planned and implemented release and deploymentwill make a significant difference to an organization’sservice costs. A poorly designed release or deploymentwill, at best, force IT personnel to spend significantamounts of time troubleshooting problems and managing


Figure 6.3 Service Asset and Configuration Management – interfaces to the lifecycle

Planning, managementresources, time

Management supportWorking relationships

Resources, facilities, CMS andtools

Training and Guidance

Policy, Standards,Strategy,

Service Portfolio,Customer Portfolio,Contract Portfolio,

Contract requirements Requirements Design,

Maintenance, Release,

Deployment, Operations plans

Feedback

Configuration Identification

Configuration Control

StatusAccounting and

Reporting

RFC/change to

CI

Change and Configuration Records and

Documentation

Physical CIs, Test results

Audit/discovery tools

Verification and Audit

Control Configuration Management Plan,

Contract

CI Identification, naming, labelling,

data and documentation

Baseline and Release Id

Updated RFC, updated CI

Status Record/Report Configuration

information and Performance

Action items Confidence

in service and

infrastructure

Managementand Planning

7238-TSO-ITIL-13 28/8/07 14:01 Page 86

complexity. At worst, it can cripple the environment anddegrade the live services.

The goal of Release and Deployment Management is todeploy releases into production and enable effective useof the service in order to deliver value to the customer.

The objective of Release and Deployment Management isto ensure that:

� There are clear and comprehensive release anddeployment plans that enable the customer andbusiness change projects to align their activities withthese plans

� A release package can be built, installed, tested anddeployed efficiently to a deployment group or targetenvironment successfully and on schedule

� A new or changed service and its enabling systems,technology and organization are capable of deliveringthe agreed service requirements, i.e. utilities, warrantiesand service levels

� There is knowledge transfer to enable the customersand users to optimize their use of the service tosupport their business activities

� Skills and knowledge are transferred to operations andsupport staff to enable them to effectively andefficiently deliver, support and maintain the serviceaccording to required warranties and service levels

� There is minimal unpredicted impact on theproduction services, operations and supportorganization

� Customers, users and service management staff aresatisfied with the Service Transition practices andoutputs, e.g. user documentation and training.

A key to Release and Deployment Management is definingthe appropriate release package type for a given type ofrelease. Figure 6.4 illustrates one example of a releasepackage.


Figure 6.4 Example of a release package

Business/OrganizationArchitecture

Service Architecture

ApplicationArchitecture

TechnologyArchitecture

ProductArchitecture

ServicePortfolio

Information and

Data Architecture

Using

Delivery, feedbackand monitoring

Supported by

Manipulatedby

Current Baseline (as-is)

Business/OrganizationArchitecture

Service Architecture

ApplicationArchitecture

TechnologyArchitecture

ProductArchitecture

ServicePortfolio

Information and

Data Architecture

Using

Delivery, feedbackand monitoring

Supported by

Manipulatedby

Target Baseline (to-be)

SA RO1

BA RO1

AA RO1

TA RO1

ReleasePackage

BuildandTest

7238-TSO-ITIL-13 28/8/07 14:01 Page 87

The general aim is to decide the most appropriate release-unit level for each service asset or component. Anorganization may, for example, decide that the release unitfor business critical applications is the completeapplication in order to ensure that testing iscomprehensive. The same organization may decide that amore appropriate release unit for a website is at the pagelevel.

The following factors should be taken into account whendeciding the appropriate level for release units:

� The ease and amount of change necessary to releaseand deploy a release unit

� The amount of resources and time needed to build,test, distribute and implement a release unit

� The complexity of interfaces between the proposedunit and the rest of the services and IT infrastructure

� The storage available in the build, test, distribution andlive environments.

6.5 SERVICE VALIDATION AND TESTINGRELEASES

Effective build and test environment management isessential to ensure that the builds and tests are executedin a repeatable and manageable manner. Inadequatecontrol of these environments means that unplannedchanges can compromise the testing activities and/orcause significant re-work. Dedicated build environmentsshould be established for assembling and building thecomponents for controlled test and deploymentenvironments.

Preparation of the test environments includes building,changing or enhancing the test environments ready toreceive the release.

An IT service is, on most occasions, built from a number oftechnology resources or management assets. In the buildphase, these different blocks, often from different

suppliers, are installed and configured together to createthe solution as designed. Standardization facilitates theintegration of the different building blocks to provide aworking solution and service.

Automating the installation of systems and applicationsoftware onto servers and workstations reduces thedependencies on people and streamlines the procedures.Depending on the release and deployment plans, theinstallation may be performed in advance (for example,if equipment is being replaced) or it may have to occur insitu in the live environment.

The physical infrastructure elements, together with theenvironment in which they will operate, need to be testedappropriately. Part of the testing may be to test thereplication of the infrastructure solution from oneenvironment to another. This gives a better guaranteethat the rollout to the production environment will besuccessful.

Test environments must be actively maintained andprotected using service management best practices. Forany significant change to a service, the question should beasked (as it is for the continued relevance of continuityand capacity plans): ‘If this change goes ahead, will thereneed to be a consequential change to the test data?’During the build and test activities, operations andsupport teams need to be kept fully informed andinvolved as the solution is built to facilitate a structuredtransfer from the project to the operations team.

Figure 6.5 provides an example of service testing throughthe Service Transition stage of the lifecycle.

There is an invisible separation between Change,Configuration, Release and Deployment. Each works handin hand to ensure minimal disruption and risk to thebusiness during service transition. The Service Transitioncore publication contains full details of each of theseimportant processes and guidance on how to implementand use them.


7238-TSO-ITIL-13 28/8/07 14:01 Page 88


Figure 6.5 Service testing and validation

E1 ServiceDesign Evaluation

E2 Service Evaluation prior to Deployment

ServiceRelease

Test

Rele

ase

Pack

age

Test

Valid

ate

Serv

ice

Des

ign

Facilities

*SORT Pilot Pilot

Service Requirement Test

Service Management Test

Operations Test

User Test

Deployment Tests

Verify service assets and components

Evaluation

*Service Operational Readiness Test

E3 ServiceAcceptance Evaluation

prior to Closure

E1 E2 E3

Service DesignRelease Packaging and Build Deployment and Early Life Support

SPI, Contract and Compliance Tests

SLM and reporting

CSI performance measurement

Operations test

User testing(sampling at user locations etc)

Verify environment against expected requirements (inc. configuration audit)

ValidationVerification

ServiceOperationand CSI

7238-TSO-ITIL-13 28/8/07 14:01 Page 89

7238-TSO-ITIL-13 28/8/07 14:01 Page 90

Service Operation 7

7238-TSO-ITIL-13 28/8/07 14:01 Page 91

7238-TSO-ITIL-13 28/8/07 14:01 Page 92

So far, we have learned some of the key concepts of ITILService Management – Strategy, Design and Transition.Each of these has demonstrated how they contribute toservice quality, but it is in Service Operation that thebusiness customer sees the quality of the strategy, thedesign and the transition come to life in everyday use ofthe services.

Service Operation is the phase in the ITIL ServiceManagement Lifecycle that is responsible for business-as-usual activities.

Service Operation can be viewed as the ‘factory’ of IT.This implies a closer focus on the day-to-day activities andinfrastructure that are used to deliver services. Theoverriding purpose of Service Operation is to deliver and

support services. Management of the infrastructure andthe operational activities must always support thispurpose.

Well-planned and implemented processes will be to noavail if the day-to-day operation of those processes is notproperly conducted, controlled and managed. Nor willservice improvements be possible if day-to-day activitiesto monitor performance, assess metrics and gather dataare not systematically conducted during Service Operation.

The purpose of Service Operation is to coordinate andcarry out the activities and processes required to deliverand manage services at agreed levels to business usersand customers. Service Operation is also responsible for

| 93

7 Service Operation

ServiceStrategy

ServiceDesign

ServiceTransition

ServiceOperation

StrategiesPolicies


Objectivesfrom

Requirements

SolutionDesigns

ArchitecturesStandards

SDPs

TransitionPlans

Testedsolutions

SKMS

Requirements The business/customers

Operationalservices

7238-TSO-ITIL-13 28/8/07 14:01 Page 93

the ongoing management of the technology that is usedto deliver and support services.

7.1 BUSINESS VALUE

Each stage in the ITIL Service Management Lifecycleprovides value to business. For example, service value ismodelled in Service Strategy; the cost of the service isdesigned, predicted and validated in Service Design andService Transition; and measures for optimization identifiedin Continual Service Improvement. The operation ofservice is where these plans, designs and optimizations areexecuted and measured. From a customer viewpoint,Service Operation is where actual value is seen.

In all stages of the ITIL Service Management Lifecycle,there are distinct processes, functions and activities whichwork together to deliver the objectives of ServiceOperation. The following sections in this chapter touch on:

The processes of:

� Event Management

� Request Fulfilment

� Incident Management

� Problem Management

� Access Management

The functions of:

� Service Desk

� Technical Management

� IT Operations Management

� Application Management

� Monitoring and Control.

7.2 EVENT MANAGEMENT

An event can be defined as any detectable or discernibleoccurrence that has significance for the management ofthe IT infrastructure or the delivery of IT service and

evaluation of the impact a deviation might cause to theservices. Events are typically notifications created by an ITservice, Configuration Item (CI) or monitoring tool (seeFigure 7.1).

Effective Service Operation is dependent on knowing thestatus of the infrastructure and detecting any deviationfrom normal or expected operation. This is provided bygood monitoring and control systems, which are based ontwo types of tools:

� Active monitoring tools that poll key CIs to determinetheir status and availability. Any exceptions willgenerate an alert that needs to be communicated tothe appropriate tool or team for action

� Passive monitoring tools that detect and correlateoperational alerts or communications generated by CIs.

Event Management can be applied to any aspect ofservice management that needs to be controlled andwhich can be automated. These include:

� Configuration Items:

� Some CIs will be included because they need tostay in a constant state (e.g. a switch on a networkneeds to stay on and Event Management toolsconfirm this by monitoring responses to ‘pings’)

� Some CIs will be included because their statusneeds to change frequently and Event Managementcan be used to automate this and update the CMS(e.g. the updating of a file server)

� Environmental conditions (e.g. fire and smokedetection)

� Software licence monitoring for usage to ensureoptimum/legal licence utilization and allocation

� Security (e.g. intrusion detection)

� Normal activity (e.g. tracking the use of an applicationor the performance of a server).

94 | Service Operation

7238-TSO-ITIL-13 28/8/07 14:01 Page 94

Service Operation | 95


Effective?

Event

Event NotificationGenerated

Event Detected

Event Filtered

Significance?

Event Correlation

Trigger

Event Logged Auto Response Alert

HumanIntervention

IncidentManagement

ProblemManagement

ChangeManagement

Review Actions

Close Event

Incident/Problem/Change?

InformationalInformational ExceptionException

WarningWarning

Change

Problem

Incident

End

Yes

No

7238-TSO-ITIL-13 28/8/07 14:01 Page 95

7.2.1 Value to businessEvent Management’s value to the business is generallyindirect; however it is possible to determine the basis forits value as follows:

� Event Management provides mechanisms for earlydetection of incidents. In many cases it is possible forthe incident to be detected and assigned to theappropriate group for action before any actual serviceoutage occurs

� Event Management makes it possible for some types ofautomated activity to be monitored by exception –thus removing the need for expensive and resource-intensive real-time monitoring, while reducingdowntime

� When integrated into other service managementprocesses (such as, for example, Availability or CapacityManagement), Event Management can signal statuschanges or exceptions that allow the appropriateperson or team to perform early response, thusimproving the performance of the process. This, inturn, will allow the business to benefit from moreeffective and more efficient Service Managementoverall

� Event Management provides a basis for automatedoperations, thus increasing efficiencies and allowingexpensive human resources to be used for moreinnovative work, such as designing new or improvedfunctionality or defining new ways in which thebusiness can exploit technology for increasedcompetitive advantage.

7.3 INCIDENT MANAGEMENT

Incident Management includes any event which disrupts,or which could disrupt, a service. This includes eventswhich are communicated directly by users, either throughthe Service Desk or through an interface from EventManagement to Incident Management tools.

Incidents can also be reported and/or logged by technicalstaff (if, for example, they notice something untoward witha hardware or network component they may report or logan incident and refer it to the Service Desk).

7.3.1 Value to businessIncident Management is highly visible to the business, andit is therefore easier to demonstrate its value than mostareas in Service Operation. For this reason, IncidentManagement is often one of the first processes to beimplemented in service management projects. The addedbenefit of doing this is that Incident Management can beused to highlight other areas that need attention –thereby providing a justification for expenditure onimplementing other processes. Incident Management’svalue to the business includes:

� The ability to detect and resolve Incidents whichresults in lower downtime to the business, which inturn means higher availability of the service. Thismeans that the business is able to exploit thefunctionality of the service as designed

� The ability to align IT activity to real-time businesspriorities. This is because Incident Managementincludes the capability to identify business prioritiesand dynamically allocate resources as necessary

� The ability to identify potential improvements toservices. This happens as a result of understandingwhat constitutes an Incident and also from being incontact with the activities of business operational staff

� The Service Desk can, during its handling of Incidents,identify additional service or training requirementsfound in IT or the business.

7.3.2 Incident modelsMany incidents are not new – they involve dealing withsomething that has happened before and may wellhappen again. For this reason, many organizations will


7238-TSO-ITIL-13 28/8/07 14:01 Page 96

find it helpful to pre-define standard Incident models –and apply them to appropriate Incidents when they occur.

An Incident model is a way of pre-defining the steps thatshould be taken to handle a process (in this case a processfor dealing with a particular type of incident) in an agreedway. Support tools can then be used to manage therequired process. This will ensure that standard incidentsare handled in a pre-defined path and within pre-definedtimescales.

The Incident model should include:

� Steps that should be taken to handle the Incident

� Chronological order these steps should be taken in,with any dependences or co-processing defined

� Responsibilities; who should do what

� Timescales and thresholds for completion of theactions

� Escalation procedures; who should be contacted andwhen

� Any necessary evidence-preservation activities(particularly relevant for security- and capacity-relatedincidents).

The models should be input to the Incident-handlingsupport tools in use and the tools should then automatethe handling, management and escalation of the process.

The Incident Management process is shown in Figure 7.2.

Incident logging

All incidents must be fully logged and date/time stamped,regardless of whether they are raised through a ServiceDesk telephone call or whether automatically detected viaan event alert.

Incident categorization

Part of the initial logging must be to allocate suitableIncident categorization coding so that the exact type ofthe call is recorded. This will be important later when

looking at Incident types/frequencies to establish trendsfor use in Problem Management, Supplier Managementand other ITSM activities.

Incident prioritization

Prioritization can normally be determined by taking intoaccount both the urgency of the Incident (how quickly thebusiness needs a resolution) and the level of impact it iscausing. An indication of impact is often (but not always)the number of users being affected. In some cases, andvery importantly, the loss of service to a single user canhave a major business impact.

Initial diagnosis

If the incident has been routed via the Service Desk, theService Desk Analyst must carry out initial diagnosis,typically while the user is still on the telephone – if thecall is raised in this way – to try to discover the fullsymptoms of the Incident and to determine exactly whathas gone wrong and how to correct it. It is at this stagethat diagnostic scripts and known error information can bemost valuable in allowing earlier and accurate diagnosis.

Incident escalation

Functional escalation – As soon as it becomes clear thatthe Service Desk is unable to resolve the incident itself (orwhen target times for first-point resolution have beenexceeded – whichever comes first!) the incident must beimmediately escalated for further support.

Hierarchic escalation – If incidents are of a serious nature(for example Priority 1 incidents) the appropriate ITmanagers must be notified, for informational purposes atleast. Hierarchic escalation is also used if the ‘Investigationand Diagnosis’ and ‘Resolution and Recovery’ steps aretaking too long or proving too difficult. Hierarchicescalation should continue up the management chain sothat senior managers are aware and can be prepared andtake any necessary action, such as allocating additional


7238-TSO-ITIL-13 28/8/07 14:01 Page 97



Yes

FromEventMgmt

FromWeb

Interface

UserPhoneCall

EmailTechnical

Staff

IncidentIdentification

IncidentCategorization

Service Request? To RequestFulfilment

IncidentPrioritization

Major IncidentProcedure Major Incident?

FunctionalEscalation2/3 Level

HierarchicEscalationNeeded?

ManagementEscalation

Investigation& Diagnosis

Resolutionand Recovery

Incident Closure

IncidentLogging

Yes

No

Yes

InitialDiagnosis

FunctionalEscalationNeeded?

No

End

Yes

Yes No

No

7238-TSO-ITIL-13 28/8/07 14:01 Page 98

resources or involving suppliers/maintainers. Hierarchicescalation is also used when there is contention about towhom the incident is allocated.

Investigation and diagnosis

This will include a variety of activities depending on thetype of incident but should include:

� Establishing exactly what has gone wrong or beingsought by the user

� Understanding the chronological order of events

� Confirming the full impact of the incident, includingthe number and range of users affected

� Identifying any events that could have triggered theincident (e.g. a recent change, some user action?)

� Knowledge searches looking for previous occurrencesby searching previous Incident/Problem Records and/orKnown Error Databases or manufacturers’/suppliers’Error Logs or Knowledge Databases.

Resolution and recovery

When a potential resolution has been identified, thisshould be applied and tested. The specific actions to beundertaken and the people who will be involved in takingthe recovery actions may vary, depending upon the natureof the fault – but could involve:

� Asking the user to undertake directed activities on theirown desktop or remote equipment

� The Service Desk implementing the resolution eithercentrally (say, rebooting a server) or remotely usingsoftware to take control of the user’s desktop todiagnose and implement a resolution

� Specialist support groups being asked to implementspecific recovery actions (e.g. network supportreconfiguring a router)

� A third-party supplier or maintainer being asked toresolve the fault.

Incident closure

The Service Desk should check that the incident is fullyresolved and that the users are satisfied and willing toagree the Incident can be closed. The Service Desk shouldalso check the following:

� Closure categorization. Check and confirm that theinitial Incident categorization was correct or, where thecategorization subsequently turned out to be incorrect,update the record so that a correct closurecategorization is recorded for the Incident – seekingadvice or guidance from the resolving group(s) asnecessary

� User satisfaction survey. Carry out a user satisfactioncall-back or e-mail survey for the agreed percentage ofIncidents

� Incident documentation. Chase any outstandingdetails and ensure that the Incident Record is fullydocumented so that a full historic record at a sufficientlevel of detail is complete

� Ongoing or recurring problem? Determine (inconjunction with resolver groups) whether it is likelythat the incident could recur and decide whether anypreventive action is necessary to avoid this. Inconjunction with Problem Management, raise aProblem Record in all such cases so that preventiveaction is initiated

� Formal closure. Formally close the Incident Record.

7.4 REQUEST FULFILMENT

The term ‘Service Request’ is used as a generic descriptionfor many varying types of demands that are placed uponthe IT department by the users. Many of these are actuallysmall changes – low risk, frequently occurring, low costetc. (e.g. a request to change a password, a request toinstall an additional software application onto a particularworkstation, a request to relocate some items of desktopequipment) or may be just a question requesting


7238-TSO-ITIL-13 28/8/07 14:01 Page 99

information – but their scale and frequent, low-risk naturemeans that they are better handled by a separate process,rather than being allowed to congest and obstruct thenormal Incident and Change Management processes.

The process needed to fulfil a request will vary dependingupon exactly what is being requested – but can usually bebroken down into a set of activities that have to beperformed. Some organizations will be comfortable to letthe Service Requests be handled through their IncidentManagement processes (and tools) – with Service Requestsbeing handled as a particular type of Incident (using ahigh-level categorization system to identify those Incidentsthat are in fact Service Requests).

Note, however, that there is a significant difference here –an Incident is usually an unplanned event whereas aService Request is usually something that can and shouldbe planned!

Therefore, in an organization where large numbers ofService Requests have to be handled, and where theactions to be taken to fulfil those requests are very variedor specialized, it may be appropriate to handle ServiceRequests as a completely separate work stream – and torecord and manage them as a separate record type.

Many Service Requests will be frequently recurring, so apredefined process flow (a model) can be devised toinclude the stages needed to fulfil the request, theindividuals or support groups involved, target timescalesand escalation paths. Service Requests will usually besatisfied by implementing a Standard Change (see theService Transition publication for further details onStandard Changes). The ownership of Service Requestsresides with the Service Desk, which monitors, escalates,dispatches and often fulfils the user request.

7.4.1 Request modelsSome Service Requests will occur frequently and willrequire handling in a consistent manner in order to meetagreed service levels. To assist this, many organizations willwish to create pre-defined Service Request models (whichtypically include some form of pre-approval by ChangeManagement). This is similar in concept to the idea ofIncident models, but applied to Service Requests.

Most requests will be triggered through either a usercalling the Service Desk or a user completing some formof self-help web-based input screen to make their request.The latter will often involve a selection from a portfolio ofavailable request types.

The primary interfaces with Request Fulfilment include:

� Service Desk/Incident Management: many ServiceRequests may come in via the Service Desk and maybe initially handled through the Incident Managementprocess. Some organizations may choose that allRequests are handled via this route – but others maychoose to have a separate process, for reasons alreadydiscussed earlier in this chapter

� A strong link is also needed between RequestFulfilment, Release, Asset and ConfigurationManagement as some requests will be for thedeployment of new or upgraded components that canbe automatically deployed. In such cases the releasecan be pre-defined, built and tested but only deployedupon request by those who want the release. Upondeployment, the CMS will have to be updated toreflect the change. Where appropriate, software licencechecks/updates will also be necessary.

Where appropriate, it will be necessary to relate IT-relatedService Requests to any Incidents or Problems that haveinitiated the need for the Request (as would be the casefor any other type of change).


7238-TSO-ITIL-13 28/8/07 14:01 Page 100

Request Fulfilment depends on the following criticalsuccess factors:

� Agreement of what services will be standardized andwho is authorized to request them. The cost of theseservices must also be agreed. This may be done as partof the SLM process. Any variances of the services mustalso be defined

� Publication of the services to users as part of theService Catalogue. It is important that this part of theService Catalogue must be easily accessed, perhaps onthe intranet, and should be recognized as the firstsource of information for users seeking access to aservice

� Definition of a standard fulfilment procedure for eachof the services being requested. This includes allprocurement policies and the ability to generatepurchase orders and work orders

� A single point of contact which can be used to requestthe service. This is often provided by the Service Deskor through an intranet request, but could be throughan automated request directly into the RequestFulfilment or procurement system

� Self-service tools needed to provide a front-endinterface to the users. It is essential that these integratewith the back-end fulfilment tools, often managedthrough Incident or Change Management.

7.5 PROBLEM MANAGEMENT

ITIL defines a ‘Problem’ as the unknown cause of one ormore Incidents.

Problem Management is the process responsible formanaging the lifecycle of all problems. The primaryobjectives of Problem Management are to preventProblems and resulting Incidents from happening, toeliminate recurring Incidents and to minimize the impactof Incidents that cannot be prevented.

7.5.1 ScopeProblem Management includes the activities required todiagnose the root cause of Incidents and to determine theresolution to those problems. It is also responsible forensuring that the resolution is implemented through theappropriate control procedures, especially ChangeManagement and Release Management.

Problem Management will also maintain informationabout Problems and the appropriate workarounds andresolutions, so that the organization is able to reduce thenumber and impact of Incidents over time. In this respect,Problem Management has a strong interface withKnowledge Management, and tools such as the KnownError Database will be used for both.

Although Incident and Problem Management are separateprocesses, they are closely related and will typically usethe same tools, and may use similar categorization, impactand priority coding systems. This will ensure effectivecommunication when dealing with related Incidents andProblems.

Problem Management consists of two major processes:

� Reactive Problem Management, which is generallyexecuted as part of Service Operation

� Proactive Problem Management which is initiated inService Operation, but generally driven as part ofContinual Service Improvement.

7.5.2 Process

Problem detection

It is likely that multiple ways of detecting problems willexist in all organizations. These will include:

� Suspicion or detection of an unknown cause of one ormore Incidents by the Service Desk, resulting in aProblem Record being raised – the desk may haveresolved the Incident but has not determined a


7238-TSO-ITIL-13 28/8/07 14:01 Page 101


Figure 7.3 The Problem Management process flow

Service DeskEvent

ManagementSupplier orContractor

ProactiveProblem

Management

ProblemDetection

ProblemLogging

Categorization

Prioritization


Workaround?

ChangeManagement Change Needed?

Yes

No

CMS

KnownError

Database

IncidentManagement

Create KnownError Record

Closure

MajorProblem?

Major ProblemReview

End

Resolution

7238-TSO-ITIL-13 28/8/07 14:01 Page 102

definitive cause and suspects that it is likely to recur, sowill raise a Problem Record to allow the underlyingcause to be resolved. Alternatively, it may beimmediately obvious from the outset that an Incident,or Incidents, has been caused by a major problem, so aProblem Record will be raised without delay

� Analysis of an incident by a technical support groupwhich reveals that an underlying problem exists, or islikely to exist

� Automated detection of an infrastructure or applicationfault, using event/alert tools automatically to raise anIncident which may reveal the need for a ProblemRecord

� A notification from a supplier or contractor that aProblem exists that has to be resolved

� Analysis of Incidents as part of proactive ProblemManagement – resulting in the need to raise a ProblemRecord so that the underlying fault can be investigatedfurther.

Problem logging

A cross-reference must be made to the incident(s) whichinitiated the Problem Record – and all relevant detailsmust be copied from the Incident Record(s) to theProblem Record. It is difficult to be exact, as cases mayvary, but typically this will include details such as:

� User details

� Service details

� Equipment details

� Date/time initially logged

� Priority and categorization details

� Incident description

� Details of all diagnostic or attempted recovery actionstaken.

Problem categorization

Problems must be categorized in the same way asIncidents (and it is advisable to use the same codingsystem) so that the true nature of the Problem can beeasily traced in the future and meaningful managementinformation can be obtained.

Problem prioritization

Problems must be prioritized in the same way and for thesame reasons as Incidents – but the frequency and impactof related Incidents must also be taken into account.

Problem prioritization should also take into account theseverity of the Problem. Severity in this context refers tohow serious the Problem is from an infrastructureperspective, for example:

� Can the system be recovered, or does it need to bereplaced?

� How much will it cost?

� How many people, with what skills, will be needed tofix the problem?

� How long will it take to fix the problem?

� How extensive is the problem (e.g. how many CIs areaffected)?

Problem investigation and diagnosis

An investigation should be conducted to try to diagnosethe root cause of the Problem – the speed and nature ofthis investigation will vary depending upon the impact,severity and urgency of the Problem – but the appropriatelevel of resources and expertise should be applied tofinding a resolution commensurate with the priority codeallocated and the service target in place for that prioritylevel.

The CMS must be used to help determine the level ofimpact and to assist in pinpointing and diagnosing theexact point of failure. The Known Error Database (KEDB)


7238-TSO-ITIL-13 28/8/07 14:01 Page 103

should also be accessed and Problem-matchingtechniques (such as keyword searches) should be used tosee if the Problem has occurred before and, if so, to findthe resolution.

It is often valuable to try to recreate the failure, so as tounderstand what has gone wrong, and then to try variousways of finding the most appropriate and cost-effectiveresolution to the Problem. To do this effectively withoutcausing further disruption to the users, a test system willbe necessary that mirrors the production environment.

There are many Problem analysis, diagnosis and solvingtechniques available and much research has been done inthis area. The Service Operation publication details thetypes and how to use them.

Workarounds

In some cases it may be possible to find a workaround tothe Incidents caused by the Problem – a temporary way ofovercoming the difficulties. For example, a manualamendment may be made to an input file to allow aprogram to complete its run successfully and allow abilling process to complete satisfactorily, but it isimportant that work on a permanent resolution continueswhere this is justified – in this example the reason for thefile becoming corrupted in the first place must be foundand corrected to prevent this happening again.

In cases where a workaround is found, it is thereforeimportant that the Problem Record remains open, anddetails of the workaround are always documented withinthe Problem Record.

Raising a Known Error Record

As soon as the diagnosis is complete, and particularlywhere a workaround has been found (even though it maynot yet be a permanent resolution), a Known Error Recordmust be raised and placed in the Known Error Database –

so that if further Incidents or Problems arise, they can beidentified and the service restored more quickly.

However, in some cases it may be advantageous to raise aKnown Error Record even earlier in the overall process –just for information purposes, for example – even thoughthe diagnosis may not be complete or a workaroundfound, so it is inadvisable to set a concrete proceduralpoint exactly when a Known Error Record must be raised.It should be done as soon as it becomes useful to do so!

Problem resolution

Ideally, as soon as a solution has been found, it should beapplied to resolve the Problem – but in reality safeguardsmay be needed to ensure that this does not cause furtherdifficulties. If any change in functionality is required thiswill require an RFC to be raised and approved before theresolution can be applied. If the Problem is very seriousand an urgent fix is needed for business reasons, then anEmergency RFC should be handled by the EmergencyChange Advisory Board (ECAB) to facilitate this urgentaction. Otherwise, the RFC should follow the establishedChange Management process for that type of Change –and the resolution should be applied only when theChange has been approved and scheduled for release. Inthe meantime, the KEDB should be used to help resolvequickly any further occurrences of the Incidents/Problems.

Problem closure

When any change has been completed (and successfullyreviewed), and the resolution has been applied, theProblem Record should be formally closed – as should anyrelated Incident Records that are still open. A check shouldbe performed at this time to ensure that the recordcontains a full historical description of all events – and ifnot, the record should be updated.

The status of any related Known Error Records should beupdated to show that the resolution has been applied.


7238-TSO-ITIL-13 28/8/07 14:01 Page 104

Major Problem review

After every major Problem (as determined by theorganization’s priority system), while memories are stillfresh a review should be conducted to learn any lessonsfor the future. Specifically, the review should examine:

� Those things that were done correctly

� Those things that were done wrong

� What could be done better in the future

� How to prevent recurrence

� Whether there has been any third-party responsibilityand whether follow-up actions are needed.

Such reviews can be used as part of training andawareness activities for support staff – and any lessonslearned should be documented in appropriate procedures,work instructions, diagnostic scripts or Known ErrorRecords. The Problem Manager facilitates the session anddocuments any agreed actions.

Errors detected in the development environment

It is rare for any new applications, systems or softwarereleases to be completely error-free. It is more likely thatduring testing of such new applications, systems orreleases, a prioritization system will be used to eradicatethe more serious faults, but it is possible that minor faultsare not rectified – often because of the balance that has tobe made between delivering new functionality to thebusiness as quickly as possible and ensuring totally fault-free code or components.

Where a decision is made to release something into theproduction environment that includes known deficiencies,these should be logged as Known Errors in the KEDB,together with details of workarounds or resolutionactivities. There should be a formal step in the testingsign-off that ensures that this handover always takes place(see Service Transition publication).

7.6 ACCESS MANAGEMENT

Access Management is the process of granting authorizedusers the right to use a service, while preventing access tonon-authorized users. It has also been referred to as ‘rightsmanagement’ or ‘identity management’ in differentorganizations.

Access Management is effectively the execution of bothAvailability and Information Security Management, in thatit enables the organization to manage the confidentiality,availability and integrity of the organization’s data andintellectual property.

Access Management ensures that users are given the rightto use a service, but it does not ensure that this access isavailable at all agreed times – this is provided byAvailability Management.

Access Management is a process that is executed by allTechnical and Application Management functions and isusually not a separate function. However, there is likely tobe a single control point of coordination, usually in ITOperations Management or on the Service Desk.

Access Management can be initiated by a Service Requestthrough the Service Desk.

7.6.1 Value to business� Controlled access to services ensures that the

organization is able to maintain more effectively theconfidentiality of its information

� Employees have the right level of access to executetheir jobs effectively

� There is less likelihood of errors being made in dataentry or in the use of a critical service by an unskilleduser (e.g. production control systems)

� The ability to audit use of services and to trace theabuse of services

� The ability more easily to revoke access rights whenneeded – an important security consideration


7238-TSO-ITIL-13 28/8/07 14:01 Page 105

� May be needed for regulatory compliance (e.g. SOX,HIPAA, COBIT).

7.6.2 Basic conceptsWhile each user has an individual identity, and each ITservice can be seen as an entity in its own right, it is oftenhelpful to group them together so that they can bemanaged more easily. Sometimes the terms ‘user profile’,‘user template’ or ‘user role’ are used to describe this typeof grouping.

Most organizations have a standard set of services for allindividual users, regardless of their position or job(excluding customers – who do not have any visibility tointernal services and processes). These will include servicessuch as messaging, office automation, desktop support,telephony etc. New users are automatically provided withrights to use these services.

However, most users also have some specialized role thatthey perform. For example, in addition to the standardservices, the user may also perform a marketingmanagement role, which requires that they have access tosome specialized marketing and financial modelling toolsand data.

Some groups may have unique requirements – such asfield or home workers who may have to dial in or usevirtual private network (VPN) connections, with securityimplications that may have to be more tightly managed.

To make it easier for Access Management to provide theappropriate rights, it uses a catalogue of all the roles in theorganization and which services support each role. Thiscatalogue of roles should be compiled and maintained byAccess Management in conjunction with HR and will oftenbe automated in the directory services tools.

In addition to playing different roles, users may alsobelong to different groups. For example, all contractorsmay be required to log their timesheets in a dedicatedtime card system, which is not used by employees. Access

Management will assess all the roles that a user plays aswell as the groups that they belong to and ensure thatthey provide rights to use all associated services.

Note: All data held on users will be subject to dataprotection legislation (this exists in most geographiclocations in some form or other) so should be handledand protected as part of the organization’s securityprocedures.

7.6.3 Lifecycle activitiesWithin Access Management the following lifecycle flow isrecommended:

� Requesting access

� Verification

� Providing rights

� Monitoring identity status

� Logging and tracking access

� Removing or restricting rights.

The Service Operation publication provides the detailedworkflow for each of these activities.

7.7 SERVICE OPERATION FUNCTIONS

7.7.1 Monitoring and controlThe measurement and control of services is based on acontinual cycle of monitoring, reporting and subsequentaction. This cycle is discussed in detail in this sectionbecause it is fundamental to the delivery, support andimprovement of services.

It is also important to note that, although this cycle takesplace during Service Operation, it provides a basis forsetting strategy, designing and testing services andachieving meaningful improvement. It is also the basis forSLM measurement. Therefore, although monitoring isperformed by Service Operation functions, it should not beseen as a purely operational matter. All phases of the


7238-TSO-ITIL-13 28/8/07 14:01 Page 106

Service Lifecycle should ensure that measures and controlsare clearly defined, executed and acted upon.

Figure 7.4 Single monitor control loop

Single monitor control loop

A single activity and its output are measured using a pre-defined norm, or standard, to determine whether it iswithin an acceptable range of performance or quality(Figure 7.4). If not, action is taken to rectify the situation orto restore normal performance.

Typically there are two types of monitor control loops:

� Open-loop systems are designed to perform a specificactivity regardless of environmental conditions. Forexample, a backup can be initiated at a given time andfrequency – and will run regardless of other conditions

� Closed-loop systems monitor an environment andrespond to changes in that environment. For example,in network load balancing a monitor will evaluate thetraffic on a circuit. If network traffic exceeds a certainrange, the control system will begin to route trafficacross a backup circuit. The monitor will continue toprovide feedback to the control system which willcontinue to regulate the flow of network trafficbetween the two circuits.

To help clarify the difference, solving a CapacityManagement problem through over-provisioning is openloop; a load-balancer that detects congestion/failure andredirects capacity is closed loop.

Complex monitor control loop

The monitor control loop in Figure 7.5 is a good basis fordefining how Operations Management works, but withinthe context of ITSM the situation is far more complex. Thefigure illustrates a process consisting of three majoractivities. Each one has an input and an output, and theoutput becomes an input for the next activity.

In this diagram, each activity is controlled by its ownMonitor Control Loop, using a set of norms for thatspecific activity. The process as a whole also has its ownMonitor Control Loop, which spans all the activities andensures that all norms are appropriate and are beingfollowed.

One loop focuses purely on executing a defined standard,and the second evaluates the performance of the processand also the standards whereby the process is executed.An example of this would be if the first set of feedbackloops at the bottom of the diagram represented individualstations on an assembly line and the higher-level looprepresented quality assurance.

The complex monitor control loop is a goodorganizational learning tool (as defined by Chris Argyris(1976), Increasing Leadership Effectiveness, New York:

Norm

Control

Input Activity Output

Compare

Monitor


7238-TSO-ITIL-13 28/8/07 14:01 Page 107

Wiley). The first level of feedback at individual activity levelis concerned with monitoring and responding to data(single facts, codes or pieces of information). The secondlevel is concerned with monitoring and responding toinformation (a collection of a number of facts about whicha conclusion may be drawn). Refer to the ServiceTransition publication for a full discussion on data,information, knowledge and wisdom.

All of this is interesting theory, but does not explain howthe monitor control loop concept can be used to operate

IT services. And especially – who defines the norm? Basedon what has been described so far, monitor control loopscan be used to manage:

� Performance of activities in a process or procedure.Each activity and its related output can potentially bemeasured to ensure that problems with the process areidentified before the process as a whole is completed.For example, in Incident Management, the ServiceDesk monitors whether a technical team has acceptedan Incident in a specified time. If not, the Incident is


Figure 7.5 Complex monitor control loop

Norm

Control Compare

Monitor

Norm

Control

Activity

Compare

Monitor

Norm

Control

Activity

Compare

Monitor

Norm

Control

Activity

Compare

Monitor

Output Input Output InputOutput InputInput

7238-TSO-ITIL-13 28/8/07 14:01 Page 108

escalated. This is done well before the target resolutiontime for that Incident because the aim of escalatingthat one activity is to ensure that the process as wholeis completed in time

� Effectiveness of a process or procedure as a whole.In this case the ‘activity’ box represents the entireprocess as a single entity. For example, ChangeManagement will measure the success of the processby checking whether a change was implemented ontime, to specification and within budget

� Performance of a device. For example, the ‘activity’box could represent the response time of a serverunder a given workload

� Performance of a series of devices. For example, theend user response time of an application across thenetwork.

ITSM monitor control loop

Each activity in a service management process (or eachcomponent used to provide a service) is monitored as partof the Service Operation processes. The operational teamor department responsible for each activity or componentwill apply the monitor control loop as defined in theprocess, and using the norms that were defined duringthe Service Design processes. The role of operationalmonitoring and control is to ensure that the process orservice functions exactly as specified, which is why theyare primarily concerned with maintaining the status quo.

The norms and monitoring and control mechanisms aredefined in Service Design, but they are based on thestandards and architectures defined during ServiceStrategy. Any changes to the organization’s ServiceStrategy, architecture, Service Portfolios or Service LevelRequirements will precipitate changes to what ismonitored and how it is controlled.

The monitor control loops are placed within the context ofthe organization. This implies that Service Strategy willprimarily be executed by business and IT executives with

support from vendor account managers. Service Designacts as the bridge between Service Strategy and ServiceOperation and will typically involve representatives fromall groups. The activities and controls will generally beexecuted by IT staff (sometimes involving users) andsupported by IT managers and the vendors. ServiceImprovement spans all areas, but primarily represents theinterests of the business and its users.

Notice that the second level of monitoring in this complexmonitor control loop is performed by the CSI processesthrough Service Strategy and Service Design. Theserelationships are represented by the numbered arrows inFigure 7.6:

� Arrow 1. In this case CSI has recognized that theservice will be improved by making a change to theService Strategy. This could be the result of thebusiness needing a change to the Service Portfolio, orthat the architecture does not deliver what wasexpected

� Arrow 2. In this case the Service Level Requirementsneed to be adjusted. It could be that the service is tooexpensive; or that the configuration of theinfrastructure needs to be changed to enhanceperformance; or because Operations Management isunable to maintain service quality in the currentarchitecture

� Arrow 3. In this case the norms specified in ServiceDesign are not being adhered to. This could bebecause they are not appropriate or executable, orbecause of a lack of education or a lack ofcommunication. The norms and the lack of complianceneed to be investigated and action taken to rectify thesituation.

There are many different types of monitoring tool anddifferent situations in which each will be used. This sectionfocuses on some of the different types of monitoring thatcan be performed and when they would be appropriate.


7238-TSO-ITIL-13 28/8/07 14:01 Page 109

Active versus passive monitoring:

� Active monitoring refers to the ongoing interrogationof a device or system to determine its status. This typeof monitoring can be resource intensive and is usuallyreserved to proactively monitor the availability of

critical devices or systems; or as a diagnostic stepwhen attempting to resolve an Incident or diagnose aProblem

� Passive monitoring is more common and refers togenerating and transmitting events to a listeningdevice or monitoring agent. Passive monitoring


Figure 7.6 ITSM monitor control loop

Norm

Control Compare

Monitor

Norm

Control Compare

Monitor

Norm

Control Compare

Monitor

333

222111Service Strategy

Portfolios,Standards and Policies

Service Design

Technical Architecturesand Performance

Standards

IT M

anag

emen

t an

d V

endor

Acc

ount

Man

agem

ent

Users

Business Executives and Business Unit Managers

Internal and External Technical Staff and Experts


Service Transition

Output Input OutputOutput InputInput Activity Activity Activity

7238-TSO-ITIL-13 28/8/07 14:01 Page 110

depends on successful definition of events andinstrumentation of the system being monitored (seesection 4.1 of the Service Operation publication).

Reactive versus proactive monitoring:

� Reactive monitoring is designed to request or triggeraction following a certain type of event or failure. Forexample, server performance degradation may triggera reboot, or a system failure will generate an Incident.Reactive monitoring is not only used for exceptions. Itcan also be used as part of normal operationsprocedures, for example a batch job completessuccessfully, which prompts the scheduling system tosubmit the next batch job

� Proactive monitoring is used to detect patterns ofevents which indicate that a system or service may beabout to fail. Proactive monitoring is generally used inmore mature environments where these patterns havebeen detected previously, often several times. Proactivemonitoring tools are therefore a means of automatingthe experience of seasoned IT staff and are often createdthrough the Proactive Problem Management process(see Continual Service Improvement publication).

Operational monitoring and Continual ServiceImprovement

This section has focused on operational monitoring andreporting, but monitoring also forms the starting point forContinual Service Improvement (CSI). This is covered in theContinual Service Improvement publication, but keydifferences are outlined here.

Quality is the key objective of monitoring for CSI.Monitoring will therefore focus on the effectiveness of aservice, process, tool, organization or CI. The emphasis isnot on assuring real-time service performance; rather it ison identifying where improvements can be made to theexisting level of service, or IT performance.

Monitoring for CSI will therefore tend to focus ondetecting exceptions and resolutions. For example, CSI isnot as interested in whether an Incident was resolved, butwhether it was resolved within the agreed time andwhether future Incidents can be prevented.

CSI is not only interested in exceptions, though. If an SLAis consistently met over time, CSI will also be interested indetermining whether that level of performance can besustained at a lower cost or whether it needs to beupgraded to an even better level of performance. CSI maytherefore also need access to regular performance reports.

However, since CSI is unlikely to need, or be able to copewith, the vast quantities of data that are produced by allmonitoring activity, they will most likely focus on aspecific subset of monitoring at any given time. This couldbe determined by input from the business orimprovements to technology.

This has two main implications:

� Monitoring for CSI will change over time. They may beinterested in monitoring the e-mail service one quarterand then move on to look at HR systems in the nextquarter

� This means that Service Operation and CSI need tobuild a process which will help them to agree on whatareas need to be monitored and for what purpose.

7.7.2 Service DeskA Service Desk is a functional unit made up of a dedicatednumber of staff responsible for dealing with a variety ofservice events, often made via telephone calls, webinterface or automatically reported infrastructure events.

The Service Desk is a vitally important part of anorganization’s IT department and should be the singlepoint of contact for IT users on a day-by-day basis – andwill handle all Incidents and Service Requests, usually usingspecialist software tools to log and manage all such events.


7238-TSO-ITIL-13 28/8/07 14:01 Page 111

The value of an effective Service Desk should not beunderrated – a good Service Desk can often compensatefor deficiencies elsewhere in the IT organization; but apoor Service Desk (or the lack of a Service Desk) can givea poor impression of an otherwise very effective ITorganization!

It is therefore very important that the correct calibre ofstaff are used on the Service Desk and that IT managersdo their best to make the Service Desk an attractive placeto work in order to improve staff retention.

The primary aim of the Service Desk is to restore ‘normalservice’ to the users as quickly as possible. In this context‘restoration of service’ is meant in the widest possiblesense. While this could involve fixing a technical fault, itcould equally involve fulfilling a Service Request oranswering a query – anything that is needed to allow theusers to return to working satisfactorily.

Specific responsibilities will include:

� Logging all relevant Incident and Service Requestdetails, allocating categorization and prioritizationcodes

� Providing first-line investigation and diagnosis

� Resolving those Incidents and Service Requests theyare able to

� Escalating Incidents and Service Requests that theycannot resolve within agreed timescales

� Keeping users informed of progress

� Closing all resolved incidents, requests and other calls

� Conducting customer/user satisfaction call-backs/surveys as agreed

� Communication with users – keeping them informedof Incident progress, notifying them of impendingchanges or agreed outages etc.

� Updating the CMS under the direction and approval ofConfiguration Management if so agreed.

The following roles are needed for the Service Desk.

Service Desk manager

In larger organizations where the Service Desk is of asignificant size, a Service Desk manager role may bejustified with the Service Desk supervisor(s) reporting tothem. In such cases this role may take responsibility forsome of the activities listed above and may additionallyperform the following activities:

� Manage the overall desk activities, including thesupervisors

� Act as a further escalation point for the supervisor(s)

� Take on a wider customer-services role

� Report to senior managers on any issue that couldsignificantly impact the business

� Attend Change Advisory Board meetings

� Take overall responsibility for Incident and ServiceRequest handling on the Service Desk. This could alsobe expanded to any other activity taken on by theService Desk – e.g. monitoring certain classes of event.

Note: In all cases, clearly defined job descriptions shouldbe drafted and agreed so that specific responsibilities areknown.

Service Desk supervisor

In very small Service Desks it is possible that the seniorService Desk analyst will also act as the supervisor – but inlarger desks it is likely that a dedicated Service Desksupervisor role will be needed. Where shift hours dictate it,there may be two or more post-holders who fulfil the role,usually on an overlapping basis. The supervisor’s role islikely to include:

� Ensuring that staffing and skill levels are maintainedthroughout operational hours by managing shiftstaffing schedules etc.

� Undertaking HR activities as needed


7238-TSO-ITIL-13 28/8/07 14:01 Page 112

� Acting as an escalation point where difficult orcontroversial calls are received

� Production of statistics and management reports

� Representing the Service Desk at meetings

� Arranging staff training and awareness sessions

� Liaising with senior management

� Liaising with Change Management

� Performing briefings to Service Desk staff on changesor deployments that may affect volumes at the ServiceDesk

� Assisting analysts in providing first-line support whenworkloads are high, or where additional experience isrequired.

Service Desk analysts

The primary Service Desk analyst role is that of providingfirst-level support through taking calls and handling theresulting Incidents or Service Requests using the IncidentReporting and Request Fulfilment processes, in line withthe objectives described earlier.

Super users

Super users are discussed in detail in the section onService Desk staffing in paragraph 6.2.4 of the ServiceOperation publication. In summary, this role will consist ofbusiness users who act as liaison points with IT in generaland the Service Desk in particular. The role of the SuperUser can be summarized as follows:

� To facilitate communication between IT and thebusiness at an operational level

� To reinforce expectations of users regarding whatService Levels have been agreed

� Staff training for users in their area

� Providing support for minor incidents or simplerequest fulfilment

� Involvement with new releases and rollouts.

Metrics should be established so that performance of theService Desk can be evaluated at regular intervals. This isimportant to assess the health, maturity, efficiency,effectiveness and any opportunities to improve ServiceDesk operations.

Metrics for Service Desk performance must be realistic andcarefully chosen. It is common to select those metrics thatare easily available and that may seem to be a possibleindication of performance; however, this can bemisleading. For example, the total number of callsreceived by the Service Desk is not in itself an indicationof either good or bad performance and may in fact becaused by events completely outside the control of theService Desk – for example a particularly busy period forthe organization, or the release of a new version of amajor corporate system.

An increase in the number of calls to the Service Desk canindicate less reliable services over that period of time –but may also indicate increased user confidence in aService Desk that is maturing, resulting in a higherlikelihood that users will seek assistance rather than try tocope alone. For this type of metric to be reliable forreaching either conclusion, further comparison of previousperiods for any Service Desk improvements implementedsince the last measurement baseline, or service reliabilityChanges, Problems etc. to isolate the true cause for theincrease is needed.

Further analysis and more detailed metrics are thereforeneeded and must be examined over a period of time.These will include the call-handling statistics previouslymentioned under telephony, and additionally:

� The first-line resolution rate: the percentage of callsresolved at first line, without the need for escalation toother support groups. This is the figure often quotedby organizations as the primary measure of the Service


7238-TSO-ITIL-13 28/8/07 14:01 Page 113

Desk’s performance – and used for comparisonpurposes with the performance of other Service Desks– but care is needed when making any comparisons

� Average time to resolve an Incident (when resolved atfirst line)

� Average time to escalate an Incident (where first-lineresolution is not possible)

� Average Service Desk cost of handling an Incident

� Percentage of customer or user updates conductedwithin target times, as defined in SLA targets

� Average time to review and close a resolved call

� The number of calls broken down by time of day andday of week, combined with the average call-timemetric, which is critical in determining the number ofstaff required.

7.7.3 Technical ManagementTechnical Management refers to the groups, departmentsor teams that provide technical expertise and overallmanagement of the IT Infrastructure.

Technical Management plays a dual role:

� It is the custodian of technical knowledge andexpertise related to managing the IT infrastructure. Inthis role, Technical Management ensures that theknowledge required to design, test, manage andimprove IT services is identified, developed and refined

� It provides the actual resources to support the ITSMLifecycle. In this role Technical Management ensuresthat resources are effectively trained and deployed todesign, build, transition, operate and improve thetechnology required to deliver and support IT services.

By performing these two roles, Technical Management isable to ensure that the organization has access to theright type and level of human resources to managetechnology and, thus, to meet business objectives.Defining the requirements for these roles starts in ServiceStrategy and is expanded in Service Design, validated in

Service Transition and refined in Continual ServiceImprovement (see other ITIL publications in this series).

Technical Management organization

Technical Management is not normally provided by asingle department or group. One or more technicalsupport teams or departments will be needed to provideTechnical Management and support for the ITinfrastructure. In all but the smallest organizations, wherea single combined team or department may suffice,separate teams or departments will be needed for eachtype of infrastructure being used.

IT Operations Management consists of a number oftechnological areas. Each of these requires a specific set ofskills to manage and operate it. Some skill sets are relatedand can be performed by generalists, whereas others arespecific to a component, system or platform.

The primary criterion of the Technical Managementorganizational structure is that of specialization or divisionof labour. The principle is that people are groupedaccording to their technical skill sets, and that these skillsets are determined by the technology that needs to bemanaged.

This list provides some examples of typical TechnicalManagement teams or departments:

� Mainframe team or department – if one or moremainframe types are still being used by theorganization

� Server team or department – often split again bytechnology types (e.g. Unix server, Wintel server)

� Storage team or department, responsible for themanagement of all data storage devices and media

� Network support team or department, looking after theorganization’s internal WANs/LANs and managing anyexternal network suppliers

� Desktop team or department, responsible for allinstalled desktop equipment


7238-TSO-ITIL-13 28/8/07 14:01 Page 114

� Database team or department, responsible for thecreation, maintenance and support of theorganization’s databases

� Middleware team or department, responsible for theintegration, testing and maintenance of all middlewarein use in the organization

� Directory services team or department, responsible formaintaining access and rights to service elements inthe infrastructure

� Internet or web team or department, responsible formanaging the availability and security of access toservers and content by external customers, users andpartners

� Messaging team or department, responsible for e-mailservices

� IP-based telephony team or department (e.g. VoIP).

7.7.4 Technical Management rolesThe following roles are needed in the TechnicalManagement areas.

Technical managers/team-leaders

A technical manager or team-leader (depending upon thesize and/or importance of the team and the organization’sstructure and culture) may be needed for each of thetechnical teams or departments. The role will:

� Take overall responsibility for leadership, control anddecision-making for the technical team or department

� Provide technical knowledge and leadership in thespecific technical areas covered by the team ordepartment

� Ensure necessary technical training, awareness andexperience levels are maintained within the team ordepartment

� Report to senior management on all technical issuesrelevant to their area of responsibility

� Perform line-management for all team or departmentmembers.

Technical analysts/architects

This term refers to any staff member in TechnicalManagement who performs the activities listed inparagraph 7.7.3, excluding the daily operational actions,which are performed by operators in either Technical or ITOperations Management. Based on this list of genericactivities, the role of technical analysts and architectsincludes:

� Working with users, sponsors, Application Managementand all other stakeholders to determine their evolvingneeds

� Working with Application Management and other areasin Technical Management to determine the highestlevel of system requirements needed to meet therequirements within budget and technologyconstraints

� Defining and maintaining knowledge about howsystems are related and ensuring that dependenciesare understood and managed accordingly

� Performing cost-benefit analyses to determine themost appropriate means to meet the statedrequirements

� Developing operational models that will ensureoptimal use of resources and the appropriate level ofperformance

� Ensuring that the infrastructure is configured to beeffectively managed given the organization’stechnology architecture, available skills and tools

� Ensuring the consistent and reliable performance ofthe infrastructure to deliver the required level of serviceto the business

� Defining all tasks required to manage the infrastructureand ensuring that these tasks are performedappropriately


7238-TSO-ITIL-13 28/8/07 14:01 Page 115

� Input into the design of configuration data required tomanage and track the application effectively.

7.8 IT OPERATIONS MANAGEMENT

In business, the term ‘Operations Management’ is used tomean the department, group or team of peopleresponsible for performing the organization’s day-to-dayoperational activities – such as running the production linein a manufacturing environment or managing thedistribution centres and fleet movements within a logisticsorganization.

Operations Management generally has the followingcharacteristics:

� There is activity to ensure that a device, system orprocess is actually running or working (as opposed tostrategy or planning)

� This is where plans are turned into actions

� The focus is on daily or shorter-term activities,although it should be noted that these activities willgenerally be performed and repeated over a relativelylong period (as opposed to one-off project typeactivities)

� These activities are executed by specialized technicalstaff, who often have to undergo technical training tolearn how to perform each activity

� There is a focus on building repeatable, consistentactions that – if repeated frequently enough at theright level of quality – will ensure the success of theoperation

� This is where the actual value of the organization isdelivered and measured

� There is a dependency on investment in equipment orhuman resources or both

� The value generated must exceed the cost of theinvestment and all other organizational overheads(such as management and marketing costs) if thebusiness is to succeed.

In a similar way, IT Operations Management can bedefined as the function responsible for the ongoingmanagement and maintenance of an organization’s ITinfrastructure to ensure delivery of the agreed level of ITservices to the business.

IT Operations can be defined as the set of activitiesinvolved in the day-to-day running of the IT infrastructurefor the purpose of delivering IT services at agreed levels tomeet stated business objectives.

7.8.1 IT Operations Management roleThe role of Operations Management is to execute theongoing activities and procedures required to manage andmaintain the IT infrastructure so as to deliver and supportIT services at the agreed levels. These are summarizedhere for completeness:

� Operations control, which oversees the execution andmonitoring of the operational activities and events inthe IT infrastructure. This can be done with theassistance of an operations bridge or networkoperations centre. In addition to executing routinetasks from all technical areas, Operations Control alsoperforms the following specific tasks:

� Console management, which refers to definingcentral observation and monitoring capability andthen using those consoles to exercise monitoringand control activities

� Job scheduling, or the management of routinebatch jobs or scripts

� Backup and restore on behalf of all Technical andApplication Management teams and departmentsand often on behalf of users


7238-TSO-ITIL-13 28/8/07 14:01 Page 116

� Print and output management for the collationand distribution of all centralized printing orelectronic output

� Performance of maintenance activities on behalfof Technical or Application Management teams ordepartments

� Facilities management, which refers to themanagement of the physical IT environment, typicallya data centre or computer rooms and recovery sitestogether with all the power and cooling equipment.Facilities Management also includes the coordinationof large-scale consolidation projects, e.g. data centreconsolidation or server consolidation projects. In somecases the management of a data centre is outsourced,in which case Facilities Management refers to themanagement of the outsourcing contract.

The objectives of IT Operations Management include:

� Maintenance of the status quo to achieve stability ofthe organization’s day-to-day processes and activities

� Regular scrutiny and improvements to achieveimproved service at reduced costs, while maintainingstability

� Swift application of operational skills to diagnose andresolve any IT operations failures that occur.

7.9 APPLICATION MANAGEMENT

Application Management is responsible for managingapplications throughout their lifecycle. The ApplicationManagement function is performed by any department,group or team involved in managing and supportingoperational applications. Application Management alsoplays an important role in the design, testing andimprovement of applications that form part of IT services.As such, it may be involved in development projects, butis not usually the same as the applications developmentteams.

Application Management high-level role

Application Management is to applications what TechnicalManagement is to the IT infrastructure. ApplicationManagement plays a role in all applications, whetherpurchased or developed in-house. One of the keydecisions that they contribute to is the decision ofwhether to buy an application or build it (this is discussedin detail in the Service Design publication). Once thatdecision is made, Application Management will play adual role:

� It is the custodian of technical knowledge andexpertise related to managing applications. In this roleApplication Management, working together withTechnical Management, ensures that the knowledgerequired to design, test, manage and improve ITservices is identified, developed and refined

� It provides the actual resources to support the ITSMLifecycle. In this role, Application Management ensuresthat resources are effectively trained and deployed todesign, build, transition, operate and improve thetechnology required to deliver and support IT services.

By performing these two roles, Application Management isable to ensure that the organization has access to theright type and level of human resources to manageapplications and thus to meet business objectives. Thisstarts in Service Strategy and is expanded in ServiceDesign, tested in Service Transition and refined inContinual Service Improvement (see other ITIL publicationsin this series).

Part of this role is to ensure a balance between the skilllevel and the cost of these resources.

In additional to these two high-level roles, ApplicationManagement also performs the following two specific roles:

� Providing guidance to IT Operations about how best tocarry out the ongoing operational management ofapplications. This role is partly carried out during the


7238-TSO-ITIL-13 28/8/07 14:01 Page 117

Service Design process, but it is also a part of everydaycommunication with IT Operations Management asthey seek to achieve stability and optimumperformance

� The integration of the Application Management Lifecycleinto the ITSM Lifecycle. This is discussed below.

The objectives, activities and structures that enableApplication Management to play these roles effectively arediscussed below.

Application Management objectives

The objectives of Application Management are to supportthe organization’s business processes by helping toidentify functional and manageability requirements forapplication software, and then to assist in the design anddeployment of those applications and the ongoingsupport and improvement of those applications.

These objectives are achieved through:

� Applications that are well designed, resilient and cost-effective

� Ensuring that the required functionality is available toachieve the required business outcome

� The organization of adequate technical skills tomaintain operational applications in optimumcondition

� Swift use of technical skills to speedily diagnose andresolve any technical failures that do occur.

Application Management generic activities

While most Application Management teams ordepartments are dedicated to specific applications or setsof applications, there are a number of activities which theyhave in common (see Figure 7.7). These include:

� Identifying the knowledge and expertise required tomanage and operate applications in the delivery of ITservices. This process starts during the Service Strategy

phase, is expanded in detail in Service Design and isexecuted in Service Operation. Ongoing assessmentand updating of these skills are done during ContinualService Improvement

� Initiating training programmes to develop and refinethe skills in the appropriate Application Managementresources and maintaining training records for theseresources

� Recruiting or contracting resources with skills thatcannot be developed internally, or where there areinsufficient people to perform the required ApplicationManagement activities

� Design and delivery of end-user training. Training maybe developed and delivered by either the ApplicationDevelopment or Application Management groups, orby a third party, but Application Management isresponsible for ensuring that training is conducted asappropriate

� Insourcing for specific activities where the requiredskills are not available internally or in the open market,or where it is more cost-efficient to do so

� Definition of standards used in the design of newarchitectures and participation in the definition ofapplication architectures during the Service Strategyprocesses

� Research and development of solutions that can helpexpand the Service Portfolio or which can be used tosimplify or automate IT Operations, reduce costs orincrease levels of IT service

� Involvement in the design and building of newservices. All Application Management teams ordepartments will contribute to the design of thetechnical architecture and performance standards for ITservices. In addition they will also be responsible forspecifying the operational activities required tomanage applications on an ongoing basis


7238-TSO-ITIL-13 28/8/07 14:01 Page 118

� Involvement in projects, not only during the ServiceDesign process, but also for Continual ServiceImprovement or operational projects, such as operatingsystem upgrades, server consolidation projects orphysical moves

� Designing and performing tests for the functionality,performance and manageability of IT services (bearingin mind that testing should be controlled andperformed by an independent tester – see ServiceTransition publication)

� Availability and Capacity Management are dependenton Application Management for contributing to thedesign of applications to meet the levels of servicerequired by the business. This means that modellingand workload forecasting are often done together withTechnical and Application Management resources

� Assistance in assessing risk, identifying critical serviceand system dependencies and defining andimplementing countermeasures

� Managing vendors. Many Application Managementdepartments or groups are the only ones who knowexactly what is required of a vendor and how tomeasure and manage them. For this reason, manyorganizations rely on Application Management tomanage contracts with vendors of specific applications.If this is the case it is important to ensure that theserelationships are managed as part of the SLM process

� Involvement in definition of Event Managementstandards and especially in the instrumentation ofapplications for the generation of meaningful events

� Application Management as a function provides theresources that execute the Problem Managementprocess. It is their technical expertise and knowledgethat is used to diagnose and resolve Problems. It is alsotheir relationship with the vendors that is used toescalate and follow up with vendor support teams ordepartments

� Application Management resources will be involved indefining coding systems that are used in Incident andProblem Management (e.g. Incident Categories)

� Application Management resources are used to supportProblem Management in validating and maintainingthe KEDB together with the Application Developmentteams

� Change Management relies on the technicalknowledge and expertise to evaluate changes, andmany changes will be built by ApplicationManagement teams

� Successful Release Management is dependent oninvolvement from Application Management staff. Infact they are frequently the drivers of the ReleaseManagement process for their applications

� Application Management will define, manage andmaintain attributes and relationships of application CIsin the CMS

� Application Management is involved in the ContinualService Improvement processes, particularly inidentifying opportunities for improvement and then inhelping to evaluate alternative solutions

� Application Management ensures that all system andoperating documentation is up to date and properlyutilized. This includes ensuring that all design,management and user manuals are up to date andcomplete and that Application Management staff andusers are familiar with their contents

� Collaboration with Technical Management onperforming training needs analysis and maintainingskills inventories

� Assisting IT Financial Management to identify the costof the ongoing management of applications

� Involvement in defining the operational activitiesperformed as part of IT Operations Management. ManyApplication Management departments, groups orteams also perform the operational activities as part ofan organization’s IT Operations Management function


7238-TSO-ITIL-13 28/8/07 14:01 Page 119

� Input into, and maintenance of, software configurationpolicies

� Together with software development teams, thedefinition and maintenance of documentation relatedto applications. These will include user manuals,administration and management manuals, as well asany standard operating procedures (SOPs) required tomanage operational aspects of the application.

7.9.1 Application Management roles

Applications managers/team-leaders

An applications manager or team-leader should beconsidered for each of the applications teams ordepartments. The role will:

� Take overall responsibility for leadership, control anddecision-making for the applications team ordepartment

� Provide technical knowledge and leadership in thespecific applications support activities covered by theteam or department


Figure 7.7 Role of Application Management in the application lifecycle

Requirements

Design

Buildand Test

Deploy

Operate

Optimize

IT Service ManagementStrategy, Design,

Transitionand Improvement

Application Development Application Management

7238-TSO-ITIL-13 28/8/07 14:01 Page 120

� Ensure necessary technical training, awareness andexperience levels are maintained within the team ordepartment relevant to the applications beingsupported and processes being used

� Involve ongoing communication with users andcustomers regarding application performance andevolving requirements of the business

� Report to senior management on all issues relevant tothe applications being supported

� Perform line-management for all team or departmentmembers.

Applications analyst/architect

Application analysts and architects are responsible formatching requirements to application specifications.Specific activities include:

� Working with users, sponsors and all other stakeholdersto determine their evolving needs

� Working with Technical Management to determine thehighest level of system requirements needed to meetthe requirements within budget and technologyconstraints

� Performing cost-benefit analyses to determine themost appropriate means to meet the statedrequirement

� Developing operational models that will ensureoptimal use of resources and the appropriate level ofperformance

� Ensuring that applications are designed to beeffectively managed given the organization’stechnology architecture, available skills and tools

� Developing and maintaining standards for applicationsizing, performance modelling etc.

� Generating a set of acceptance test requirements,together with the designers, test engineers and theuser, which determine that all of the high-levelrequirements have been met, in both functionality andmanageability

� Input into the design of configuration data required tomanage and track the application effectively.

7.10 SERVICE OPERATION AND PROJECTMANAGEMENT

Because Service Operation is generally viewed as ‘businessas usual’ and often focused on executing definedprocedures in a standard way, there is a tendency not touse project management processes when they would infact be appropriate. For example, major infrastructureupgrades, or the deployment of new or changedprocedures, are significant tasks where formal projectmanagement can be used to improve control and managecosts/resources.

Using project management to manage these types ofactivity would have the following benefits:

� The project benefits are clearly stated and agreed

� There is more visibility of what is being done and howit is being managed, which makes it easier for other ITgroups and the business to quantify the contributionsmade by operational teams

� This in turn makes it easier to obtain funding forprojects that have traditionally been difficult to costjustify

� Greater consistency and improved quality

� Achievement of objectives results in higher credibilityfor operational groups.


7238-TSO-ITIL-13 28/8/07 14:01 Page 121

7.11 ASSESSING AND MANAGING RISK INSERVICE OPERATION

There will be a number of occasions where it is imperativethat risk assessment to Service Operation is quicklyundertaken and acted upon.

The most obvious area is in assessing the risk of potentialchanges or Known Errors (already covered elsewhere) butin addition Service Operation staff may need to beinvolved in assessing the risk and impact of:

� Failures, or potential failures – either reported by EventManagement or Incident/Problem Management, orwarnings raised by manufacturers, suppliers orcontractors

� New projects that will ultimately result in delivery intothe live environment

� Environmental risk (encompassing IT ServiceContinuity-type risks to the physical environment andlocale as well as political, commercial or industrial-relations related risks)

� Suppliers, particularly where new suppliers are involvedor where key service components are under thecontrol of third parties

� Security risks – both theoretical or actual arising fromsecurity related incidents or events

� New customers/services to be supported.

7.12 OPERATIONAL STAFF IN SERVICEDESIGN AND TRANSITION

All IT groups will be involved during Service Design andService transition to ensure that new components orservices are designed, tested and implemented to providethe correct levels of functionality, usability, availability,capacity etc.

Additionally, Service Operation staff must be involvedduring the early stages of Service Design and ServiceTransition to ensure that when new services reach the liveenvironment they are fit for purpose, from a ServiceOperation perspective, and are supportable in the future.

In this context, ‘supportable’ means:

� Capable of being supported from a technical andoperational viewpoint from within existing orpre-agreed additional resources and skills levels

� Without adverse impact on other existing technical oroperational working practices, processes or schedules

� Without any unexpected operational costs or ongoingor escalating support expenditure

� Without any unexpected contractual or legalcomplications

� No complex support paths between multiple supportdepartments of third-party organizations.


7238-TSO-ITIL-13 28/8/07 14:01 Page 122

Continual ServiceImprovement 8

7238-TSO-ITIL-13 28/8/07 14:01 Page 123

7238-TSO-ITIL-13 28/8/07 14:01 Page 124

Continual Service Improvement (CSI) provides practicalguidance in evaluating and improving the quality ofservices, overall maturity of the ITSM Service Lifecycle andits underlying processes, at three levels within theorganization:

� The overall health of ITSM as a discipline

� The continual alignment of the portfolio of IT serviceswith the current and future business needs

� The maturity of the enabling IT processes required tosupport business processes in a continual ServiceLifecycle model.

8.1 PURPOSE OF CSI

The primary purpose of CSI is to continually align and re-align IT services to the changing business needs byidentifying and implementing improvements to IT servicesthat support business processes. These improvementactivities support the lifecycle approach through Service

| 125

8 Continual Service Improvement

ServiceStrategy

ServiceDesign

ServiceTransition

ServiceOperation

ContinualService

Improvement

StrategiesPolicies


Objectivesfrom

Requirements

SolutionDesigns

ArchitecturesStandards

SDPs

TransitionPlans

Testedsolutions

SKMS

Improvementactions and plans

Requirements The business/customers

Operationalservices

7238-TSO-ITIL-13 28/8/07 14:01 Page 125

Strategy, Service Design, Service Transition and ServiceOperation. In effect, CSI is about looking for ways toimprove process effectiveness and efficiency as well ascost effectiveness.

8.2 CSI OBJECTIVES

� Review, analyse and make recommendations onimprovement opportunities in each lifecycle phase:Service Strategy, Service Design, Service Transition andService Operation

� Review and analyse Service Level achievement results

� Identify and implement individual activities to improveIT service quality and improve the efficiency andeffectiveness of enabling ITSM processes

� Improve cost effectiveness of delivering IT serviceswithout sacrificing customer satisfaction

� Ensure applicable quality management methods areused to support continual improvement activities.

The following activities support a continual processimprovement plan:

� Reviewing management information and trends toensure that services are meeting agreed Service Levels

� Reviewing management information and trends toensure that the output of the enabling ITSM processesare achieving the desired results

� Periodically conducting maturity assessments againstthe process activities and roles associated with theprocess activities to demonstrate areas of improvementor, conversely, areas of concern

� Periodically conducting internal audits verifyingemployee and process compliance

� Reviewing existing deliverables for relevance

� Making ad hoc recommendations for approval

� Conducting periodic customer satisfaction surveys

� Conducting external and internal service reviews toidentify CSI opportunities.

These activities do not happen automatically. They mustbe owned within the IT organization which is capable ofhandling the responsibility and possesses the appropriateauthority to make things happen. They must also beplanned and scheduled on an ongoing basis. By default,‘improvement’ becomes a process within IT with definedactivities, inputs, outputs, roles and reporting. CSI mustensure that ITSM processes are developed and deployed insupport of an end-to-end service management approachto business customers. It is essential to develop anongoing continual improvement strategy for each of theprocesses as well as the services.

As Figure 8.1 shows, there are many opportunities for CSI.The figure also illustrates a constant cycle of improvement.The improvement process can be summarized in six steps:

� Embrace the vision by understanding the high-levelbusiness objectives. The vision should align thebusiness and IT strategies

� Assess the current situation to obtain an accurate,unbiased snapshot of where the organization is rightnow. This baseline assessment is an analysis of thecurrent position in terms of the business, organization,people, process and technology

� Understand and agree on the priorities forimprovement based on a deeper development of theprinciples defined in the vision. The full vision may beyears away but this step provides specific goals and amanageable timeframe

� Detail the CSI plan to achieve higher quality serviceprovision by implementing ITSM processes

� Verify that measurements and metrics are in place toensure that milestones were achieved, processcompliance is high, and business objectives andpriorities were met by the level of service

� Finally, the process should ensure that the momentumfor quality improvement is maintained by assuring thatchanges become embedded in the organization.

126 | Continual Service Improvement

7238-TSO-ITIL-13 28/8/07 14:01 Page 126

8.2.1 Perspectives on benefitsThere are four commonly used terms when discussingservice improvement outcomes:

� Improvements

� Benefits

� ROI (return on investment)

� VOI (value on investment).

Much of the angst and confusion surrounding IT processimprovement initiatives can be traced to the misuse ofthese terms. Below is the proper use:

� Improvements – Outcomes that when compared tothe ‘before’ state, show a measurable increase in adesirable metric or decrease in an undesirable metric

� Example: ABC Corp achieved a 15% reduction infailed changes through implementation of a formalChange Management process

� Benefits – The gains achieved through realization ofimprovements, usually but not always expressed inmonetary terms.

� Example: ABC Corp’s 15% reduction in failedchanges has saved the company £395,000 inproductivity and re-works costs in the first year

Continual Service Improvement | 127

Figure 8.1 Continual Service Improvement model

What is the vision?

Where do we wantto be?

How do we get there?

Did we get there?

Where are we now?

How do we keepthe momentum going?

Service & processimprovement

Measureabletargets

Baselineassessments

Measurements &metrics

Business vision,mission, goals and

objectives

7238-TSO-ITIL-13 28/8/07 14:01 Page 127

� ROI – The difference between the benefit (saving)achieved and the amount expended to achieve thatbenefit, expressed as a percentage. Logically, onewould like to spend a little to save a lot

� Example: ABC Corp spent £200,000 to establish theformal Change Management process that saved£395,000. The ROI at the end of the first year ofoperation was therefore £195,000 or 97.5%

� VOI – The extra value created by establishment ofbenefits that include non-monetary or long-termoutcomes. ROI is a subcomponent of VOI

� Example: ABC Corp’s establishment of a formalChange Management process (which reduced thenumber of failed changes) improved the ability ofABC Corp to respond quickly to changing marketconditions and unexpected opportunities resultingin an enhanced market position. In addition, itpromoted collaboration between business units andthe IT organization and freed up resources to workon other projects that otherwise might not havebeen completed.

8.3 BUSINESS DRIVERS

Businesses are becoming increasingly aware of theimportance of IT as a service provider to not only supportbut also enable business operations. As a result thebusiness leaders of today ask much more pointed anddirect questions regarding the quality of IT services andthe competency and efficiency of their provider. Thishigher level of scrutiny buttresses the expanding need forCSI, meaning that:

� IT does more than enable existing business operations;IT enables business change and is, therefore, anintegral component of the business changeprogramme

� There is additional focus on the quality of IT in termsof reliability, availability, stability, capacity, security and,especially, risk

� IT and IT governance is an integral component incorporate governance

� IT performance becomes even more visible – technicaloutages and customer dissatisfaction increasinglybecome boardroom issues

� IT organizations increasingly find themselves in aposition where they have to not only realize butmanage business-enabling technology and servicesthat deliver the capability and quality demanded bythe business

� IT must demonstrate value for money

� IT within e-business is not only supporting the primarybusiness processes, but is the core of those processes.

8.4 TECHNOLOGY DRIVERS

The rapid pace of technology developments, within whichIT provides solutions, becomes a core component ofalmost every area of business operations. As a result, ITservices must:

� Understand business operations and advise about theshort- and long-term opportunities (and limitations)of IT

� Be designed for agility and nimbleness to allow forunpredictability in business needs

� Accommodate more technological change, with areduced cycle time, for realizing change to match areduced window in the business cycle

� Maintain or improve existing quality of services whileadding or removing technology components

� Ensure that quality of delivery and support matchesthe business use of new technology

� Bring escalating costs under control.


7238-TSO-ITIL-13 28/8/07 14:01 Page 128

8.5 SERVICE MEASUREMENT

Critical elements of a service measurement framework:

� Integrated into business planning

� Focused on business and IT goals and objectives

� Cost-effective

� Balanced in its approach on what is measured

� Able to withstand change.

Performance measures that:

� Are accurate and reliable

� Are well defined, specific and clear

� Are relevant to meeting the objectives

� Do not create a negative behaviour

� Lead to improvement opportunities.

Performance targets that:

� Are SMART.

Defined roles and responsibilities

� Who defines the measures and targets?

� Who monitors and measures?

� Who gathers the data?

� Who processes and analyses the data?

� Who prepares the reports?

� Who presents the reports?

8.5.1 BaselinesAn important beginning point for highlightingimprovement is to establish baselines as markers orstarting points for later comparison. Baselines are alsoused to establish an initial data point to determine if aservice or process needs to be improved. As a result, it isimportant that baselines are documented, recognized andaccepted throughout the organization. Baselines must beestablished at each level: strategic goals and objectives,tactical process maturity, and operational metrics and KPIs.

If a baseline is not initially established the firstmeasurement efforts will become the baseline. That is whyit is essential to collect data at the outset, even if theintegrity of the data is in question. It is better to have datato question than to have no data at all.

8.5.2 Why do we measure?� To validate – monitoring and measuring to validate

previous decisions

� To direct – monitoring and measuring to set directionfor activities in order to meet set targets. It is the mostprevalent reason for monitoring and measuring

� To justify – monitoring and measuring to justify, withfactual evidence or proof, that a course of action isrequired

� To intervene – monitoring and measuring to identify apoint of intervention including subsequent changesand corrective actions.

The four basic reasons to monitor and measure lead tothree key questions: ‘Why are we monitoring andmeasuring?’, ‘When do we stop?’ and ‘Is anyone using thedata?’ To answer these questions, it is important to identifywhich of the above reasons is driving the measurementeffort. Too often, we continue to measure long after theneed has passed. Every time you produce a report youshould ask: ‘Do we still need this?’

8.6 CONTINUAL SERVICE IMPROVEMENTPROCESSES

The Seven-step Improvement Process is illustrated inFigure 8.2.

8.6.1 Step 1 – Define what you shouldmeasure

Compile a list of what you should measure. This will oftenbe driven by business requirements. Don’t try to coverevery single eventuality or possible metric in the world.


7238-TSO-ITIL-13 28/8/07 14:01 Page 129

Make it simple. The number of things you should measurecan grow quite rapidly. So too can the number of metricsand measurements.

Identify and link the following items:

� Corporate vision, mission, goals and objectives

� IT vision, mission, goals and objectives

� Critical success factors

� Service level targets

� Job description for IT staff.

Inputs:

� Service Level Requirements and targets

� Service Catalogue

� Vision and mission statements

� Corporate, divisional and departmental goals andobjectives

� Legislative requirements

� Governance requirements

� Budget cycle

� Balanced Scorecard.

8.6.2 Step 2 – Define what you can measureEvery organization may find that they have limitations onwhat can actually be measured. If you cannot measuresomething then it should not appear in an SLA.

Compile a list of what each tool can currently measurewithout any configuration or customization. Stay awayfrom customizing the tools as much as possible;configuring them is acceptable.


Figure 8.2 Seven-step Improvement Process

Identify• Vision• Strategy• Tactical Goals• Operational Goals

1. Define what youshould measure

7. Implementcorrective action

6. Present and use theinformation, assessmentsummary, action plans, etc.

2. Define what youcan measure

3. Gather the dataWho? How? When?Integrity of data?

4. Process the dataFrequency? Format?System? Accuracy?

5. Analyse the dataRelations? Trends?According to plan?Targets met? Corrective action?

Goals

7238-TSO-ITIL-13 28/8/07 14:01 Page 130

Perform a gap analysis between the two lists. Report thisinformation back to the business, the customers and ITmanagement. It is possible that new tools are required orthat configuration or customization is required to be ableto measure what is required.

Inputs:

� List of what you should measure

� Process flows

� Procedures

� Work instructions

� Technical and user manuals from existing tools

� Existing reports.

8.6.3 Step 3 – Gathering the dataGathering data requires having some form of monitoringin place. Monitoring could be executed using technologysuch as application, system and component monitoringtools or could even be a manual process for certain tasks.

Quality is the key objective of monitoring for ContinualService Improvement. Monitoring will therefore focus onthe effectiveness of a service, process, tool, organization orConfiguration Item (CI). The emphasis is not on assuringreal-time service performance, rather it is on identifyingwhere improvements can be made to the existing level ofservice, or IT performance. Monitoring for CSI will thereforetend to focus on detecting exceptions and resolutions. Forexample, CSI is not as interested in whether an Incidentwas resolved, but whether it was resolved within theagreed time, and whether future Incidents can beprevented.

CSI is not only interested in exceptions, though. If aService Level Agreement is consistently met over time, CSIwill also be interested in determining whether that level ofperformance can be sustained at a lower cost or whetherit needs to be upgraded to an even better level of

performance. CSI may therefore also need access toregular performance reports.

However since CSI is unlikely to need, or be able to copewith, the vast quantities of data that are produced by allmonitoring activity, they will most likely focus on aspecific subset of monitoring at any given time. This couldbe determined by input from the business orimprovements to technology.

When a new service is being designed or an existing onechanged, this is a perfect opportunity to ensure that whatCSI needs to monitor is designed into the servicerequirements (see Service Design publication).

This has two main implications:

� Monitoring for CSI will change over time. They may beinterested in monitoring the e-mail service one quarter,and then move on to look at HR systems in the nextquarter

� This means that Service Operation and CSI need tobuild a process which will help them to agree on whatareas need to be monitored and for what purpose.

It is important to remember that there are three types ofmetrics that an organization will need to collect tosupport CSI activities as well as other process activities.The types of metrics are:

� Technology metrics – these metrics are oftenassociated with component and application-basedmetrics such as performance, availability etc.

� Process metrics – these metrics are captured in theform of CSFs, KPIs and activity metrics for the servicemanagement processes. These metrics can helpdetermine the overall health of a process. Four keyquestions that KPIs can help answer are around quality,performance, value and compliance in following theprocess. CSI would use these metrics as input inidentifying improvement opportunities for eachprocess


7238-TSO-ITIL-13 28/8/07 14:01 Page 131

� Service metrics – these metrics are the results of theend-to-end service. Component/technology metrics areused to compute the service metrics.

As much as possible, you need to standardize the datastructure through policies and published standards. Forexample, how do you enter names in your tools – JohnSmith; Smith, John; or J. Smith? These can be the same ordifferent individuals. Having three different ways ofentering the same name would slow down trend analysisand will severely impede any CSI initiative.

Gathering data is defined as the act of monitoring and datacollection. This activity needs to clearly define the following:

� Who is responsible for monitoring and gathering the data?

� How the data will be gathered?

� When and how often is the data gathered?

� Criteria to evaluate the integrity of the data

The answers will be different for every organization.

Service monitoring allows weak areas to be identified, sothat remedial action can be taken (if there is a justifiablebusiness case), thus improving future service quality.Service monitoring also can show where customer actionsare causing the fault and thus lead to identifying whereworking efficiency and/or training can be improved.

Service monitoring should also address both internal andexternal suppliers since their performance must beevaluated and managed as well.

Service management monitoring helps determine thehealth and welfare of service management processes inthe following manner:

� Process compliance – Are the processes beingfollowed? Process compliance seeks to monitor thecompliance of the IT organization to the new ormodified service management processes and also theuse of the authorized service management tool thatwas implemented

� Quality – How well are the processes working? Monitorthe individual or key activities as they relate to theobjectives of the end-to-end process

� Performance – How fast or slow? Monitor the processefficiency such as throughput or cycle times

� Value – Is this making a difference? Monitor theeffectiveness and perceived value of the process to thestakeholders and the IT staff executing the processactivities.

Monitoring is often associated with automated monitoringof infrastructure components for performance such asavailability or capacity, but monitoring should also beused for monitoring staff behaviour such as adherence toprocess activities, use of authorized tools as well as projectschedules and budgets.

Exceptions and alerts need to be considered during themonitoring activity as they can serve as early warningindicators that services are breaking down. Sometimes theexceptions and alerts will come from tools, but they willoften come from those who are using the service orservice management processes. We don’t want to ignorethese alerts.

Inputs to the gather-the-data activity:

� New business requirements

� Existing SLAs

� Existing monitoring and data capture capability

� Availability and Capacity Plans

� Service Improvement Plans

� Previous trend analysis reports

� List of what you should measure

� List of what you can measure

� Gap analysis report

� List of what to measure

� Customer satisfaction surveys.


7238-TSO-ITIL-13 28/8/07 14:01 Page 132

8.6.4 Step 4 – Processing the dataOnce data is gathered, the next step is to process the datainto the required format. Report-generating technologies aretypically used at this stage as various amounts of data arecondensed into information for use in the analysis activity.The data is also typically put into a format that provides anend-to-end perspective on the overall performance of aservice. This activity begins the transformation of raw datainto packaged information. Use the information to developinsight into the performance of the service and/or processes.Process the data into information (i.e. create logicalgroupings) which provides a better means to analyse thedata – the next activity step in CSI.

The output of logical groupings could be in spreadsheets,reports generated directly from the service managementtool suite, system monitoring and reporting tools, ortelephony tools such as an automatic call distribution tool.

Processing the data is an important CSI activity that is oftenoverlooked. While monitoring and collecting data on a singleinfrastructure component is important, it is also important tounderstand that components impact on the largerinfrastructure and IT service. Knowing that a server was up99.99% of the time is one thing, knowing that no one couldaccess the server is another. An example of processing thedata is taking the data from monitoring of the individualcomponents such as the mainframe, applications, WAN, LAN,servers etc., and processing this into a structure of an end-to-end service from the customer’s perspective.

Key questions that need to be addressed in the processingactivity are:

� What is the frequency of processing the data? Thiscould be hourly, daily, weekly or monthly. Whenintroducing a new service or service managementprocess it is a good idea to monitor and process inshorter intervals than longer intervals. How oftenanalysis and trend investigation activities take placewill drive how often the data is processed

� What format is required for the output? This is alsodriven by how analysis is done and ultimately how theinformation is used

� What tools and systems can be used for processing thedata?

� How do we evaluate the accuracy of the processeddata?

There are two aspects to data gathering. One is automatedand the other is manual. While both are important andcontribute greatly to the measuring process, accuracy is amajor differentiator between the two types. The accuracyof the automated data gathering and processing is not theissue here. The vast majority of CSI-related data will begathered by automated means. Human data gatheringand processing is the issue. It is important for staff toproperly document their compliance activities, to updatelogs and records. Common excuses are that people aretoo busy, that this is not important or that it is not theirjob. On-going communication about the benefits ofperforming administrative tasks is of utmost importance.Tying these administrative tasks to job performance is oneway to alleviate this issue.

Inputs to the processing-the-data activity:

� Data collected through monitoring

� Reporting requirements

� SLAs

� OLAs

� Service Catalogue

� List of metrics, KPI, CSF, objectives and goals

� Report frequency

� Report template.

8.6.5 Step 5 – Analysing the dataYour organization’s Service Desk has a trend of reducedcall volumes consistently over the last four months. Eventhough this is a trend, you need to ask yourself the


7238-TSO-ITIL-13 28/8/07 14:01 Page 133

question: ‘Is this a good trend or a bad trend?’ You don’tknow if the call reduction is because you have reducedthe number of recurring errors in the infrastructure bygood Problem Management activities or if the customersfeel that the Service Desk doesn’t provide any value andthey have started bypassing the Service Desk and goingdirectly to second-level support groups.

Data analysis transforms the information into knowledgeof the events that are affecting the organization. More skilland experience is required to perform data analysis thandata gathering and processing. Verification against goalsand objectives is expected during this activity. Thisverification validates that objectives are being supportedand value is being added. It is not sufficient to simplyproduce graphs of various types but to document theobservations and conclusions looking to answer thefollowing questions:

� Are there any clear trends?

� Are they positive or negative trends?

� Are changes required?

� Are we operating according to plan?

� Are we meeting targets?

� Are corrective actions required?

� Are there underlying structural problems?

� What is the cost of the service gap?

It is interesting to note the number of job titles for ITprofessionals that contain the word ‘analyst’ and evenmore surprising to discover that few of them actuallyanalyse anything. This step takes time. It requiresconcentration, knowledge, skills, experience etc. One ofthe major assumptions is that the automated processing,reporting, monitoring tool has actually done the analysis.Too often people simply point at a trend and say ‘Look,numbers have gone up over the last quarter.’ However,key questions need to be asked, such as:

� Is this good?

� Is this bad?

� Is this expected?

� Is this in line with targets?

Combining multiple data points on a graph may look nicebut the real question is, what does it actually mean.‘A picture is worth a thousand words’ goes the saying. Inanalysing the data an accurate question would be, ‘Whichthousand words?’ To transform this data into knowledge,compare the information from Step 3 against both therequirements from Step 1 and what could realistically bemeasured from Step 2.

Be sure to also compare the clearly defined objectivesagainst the measurable targets that were set in the ServiceDesign, Transition and Operations lifecycle stages.Confirmation needs to be sought that these objectives andthe milestones were reached. If not, have improvementinitiatives been implemented? If so, then the CSI activitiesstart again from the gathering data, processing data andanalysing data steps to identify if the desired improvementin service quality has been achieved. At the completion ofeach significant stage or milestone, a review should beconducted to ensure the objectives have been met. It ispossible here to use the Post-Implementation Review (PIR)from the Change Management process. The PIR willinclude a review of supporting documentation and thegeneral awareness amongst staff of the refined processesor service. A comparison is required of what has beenachieved against the original goals.

During the analysis activity, but after the results arecompiled and analysis and trend evaluation have occurred,it is recommended that internal meetings be held withinIT to review the results and collectively identifyimprovement opportunities. It is important to have theseinternal meetings before you begin presenting and usingthe information which is the next activity of ContinualService Improvement. The result is that IT is a key player in


7238-TSO-ITIL-13 28/8/07 14:01 Page 134

determining how the results and any actions items arepresented to the business.

This puts IT in a better position to formulate a plan ofpresenting the results and any action items to the businessand to senior IT management. Throughout this publicationthe terms ‘service’ and ‘service management’ have beenused extensively. IT is too often focused on managing thevarious systems used by the business, often (butincorrectly) equating service and system. A service isactually made up of systems. Therefore if IT wants to beperceived as a key player, then IT must move from asystems-based organization to a service-basedorganization. This transition will force the improvement ofcommunication between the different IT silos that exist inmany IT organizations.

Performing proper analysis on the data also places thebusiness in a position to make strategic, tactical andoperational decisions about whether there is a need forservice improvement. Unfortunately, the analysis activity isoften not done. Whether it is due to a lack of resourceswith the right skills and/or simply a lack of time is unclear.What is clear is that without proper analysis, errors willcontinue to occur and mistakes will continue to berepeated. There will be little improvement.

Data analysis transforms the information into knowledgeof the events that are affecting the organization. As anexample, a sub-activity of Capacity Management isworkload management. This can be viewed as analysingthe data to determine which customers use what resource,how they use the resource, when they use the resourceand how this impacts the overall performance of theresource. You will also be able to see if there is a trend onthe usage of the resource over a period of time. From anincremental improvement process this could lead to somefocus on demand management, or influencing thebehaviour of customers.

Consideration must be given to the skills required toanalyse from both a technical viewpoint and from aninterpretation viewpoint.

When analysing data, it is important to seek answers toquestions such as:

� Are operations running according to plan? This couldbe a project plan, financial plan, availability, capacityor even IT Service Continuity Management plan

� Are targets defined in SLAs or the Service Cataloguebeing met?

� Are there underlying structural problems that can beidentified?

� Are corrective actions required?

� Are there any trends? If so then what are the trendsshowing? Are they positive trends or negative trends?

� What is leading to or causing the trends?

Reviewing trends over a period of time is anotherimportant task. It is not good enough to see a snapshot ofa data point at a specific moment in time, but to look atthe data points over a period of time. How did we do thismonth compared to last month, this quarter compared tolast quarter, this year compared to last year?

8.6.6 Step 6 – Presenting and using theinformation

The sixth step is to take our knowledge and present it,that is, turn it into wisdom by utilizing reports, monitors,action plans, reviews, evaluations and opportunities.Consider the target audience; make sure that you identifyexceptions to the service, benefits that have beenrevealed, or can be expected. Data gathering occurs at theoperational level of an organization. Format this data intoknowledge that all levels can appreciate and gain insightinto their needs and expectations.

This stage involves presenting the information in a formatthat is understandable, at the right level, provides value,


7238-TSO-ITIL-13 28/8/07 14:01 Page 135

notes exceptions to service, identifies benefits that wererevealed during the time period, and allows thosereceiving the information to make strategic, tactical andoperational decisions. In other words, presenting theinformation in the manner that makes it the most usefulfor the target audience.

Creating reports and presenting information is an activitythat is done in most organizations to some extent oranother; however it often is not done well. For manyorganizations this activity is simply taking the gatheredraw data (often straight from the tool) and reporting thissame data to everyone. There has been no processing andanalysis of the data.

There are usually three distinct audiences:

� The business – Their real need is to understandwhether IT delivered the service they promised at thelevels they promised and if not, what corrective actionsare being implemented to improve the situation

� Senior (IT) management – This group is oftenfocused on the results surrounding CSFs and KPIs suchas, customer satisfaction, actual vs. plan, costing andrevenue targets. Information provided at this levelhelps determine strategic and tactical improvementson a larger scale. Senior (IT) management often wantsthis type of information provided in the form of aBalanced Scorecard or IT scorecard format to see thebig picture at one glance

� Internal IT – This group is often interested in KPIs andactivity metrics that help them plan, coordinate,schedule and identify incremental improvementopportunities.

Now more than ever, IT must invest the time tounderstand specific business goals and translate IT metricsto reflect an impact against these goals. Businesses investin tools and services that affect productivity, and supportshould be one of those services. The major challenge, andone that can be met, is to effectively communicate the

business benefits of a well-run IT support group. Thestarting point is a new perspective on goals, measures,and reporting, and how IT actions affect business results.You will then be prepared to answer the question: ‘Howdoes IT help to generate value for your company?’

Although most reports tend to concentrate on areas wherethings are not going as well as hoped for, do not forget toreport on the good news as well. A report showingimprovement trends is IT services’ best marketing vehicle.It is vitally important that reports show whether CSI hasactually improved the overall service provision and if it hasnot, the actions taken to rectify the situation.

8.6.7 Step 7 – Implementing correctiveaction

Use the knowledge gained to optimize, improve andcorrect services. Managers need to identify issues andpresent solutions. Explain how the corrective actions to betaken will improve the service.

CSI identifies many opportunities for improvementhowever organizations cannot afford to implement all ofthem. Based on goals, objectives and types of servicebreaches, an organization needs to prioritize improvementactivities. Improvement initiatives can also be externallydriven by regulatory requirements, changes incompetition, or even political decisions.

After a decision to improve a service and/or servicemanagement process is made, then the Service Lifecyclecontinues. A new Service Strategy may be defined, ServiceDesign builds the changes, Service Transition implementsthe changes into production and then Service Operationmanages the day-to-day operations of the service and/orservice management processes. Keep in mind that CSIactivities continue through each phase of the ServiceLifecycle.

Each Service Lifecycle phase requires resources to build ormodify the services and/or service management processes,


7238-TSO-ITIL-13 28/8/07 14:01 Page 136

potential new technology or modifications to existingtechnology, potential changes to KPIs and other metricsand possibly even new or modified OLAs/UCs to supportSLAs. Communication, training and documentation arerequired to transition a new/improved service, tool orservice management process into production.

8.6.8 Monitoring and data collectionthroughout the Service Lifecycle

Service Strategy is responsible for monitoring the progressof strategies, standards, policies and architectural decisionsthat have been made and implemented.

Service Design monitors and gathers data associated withcreating and modifying (design efforts of) services andservice management processes. This part of the ServiceLifecycle also measures against the effectiveness andability to measure CSFs and KPIs that were definedthrough gathering business requirements. Service Designalso defines what should be measured. This would includemonitoring project schedules, progress to projectmilestones, and project results against goals andobjectives.

Service Transition develops the monitoring procedures andcriteria to be used during and after implementation.Service Transition monitors and gathers data on the actualrelease into production of services and servicemanagement processes. It is the responsibility of ServiceTransition to ensure that the services and servicemanagement processes are embedded in a way that canbe managed and maintained according to the strategiesand design efforts. Service Transition develops themonitoring procedures and criteria to be used during andafter implementation.

Service Operation is responsible for the actual monitoringof services in the production environment. ServiceOperation plays a large part in the processing activity.Service Operation provides input into what can be

measured and processed into logical groupings as well asdoing the actual processing of the data. Service Operationwould also be responsible for taking the component dataand processing it in a format that will provide a betterend-to-end perspective of the service achievements.

8.6.9 Role of other processes in monitoringand data collection

Service Level Management

SLM plays a key role in the data-gathering activity as SLMis responsible for not only defining business requirementsbut also IT’s capabilities to achieve them.

� One of the first items in defining IT’s capabilities is toidentify what monitoring and data collection activitiesare currently taking place

� SLM then needs to look at what is happening with themonitoring data. Is the monitoring taking place only ata component level and, if so, is anyone looking atmultiple components to provide an end-to-end serviceperformance perspective?

� SLM should also identify who gets the data, whetherany analysis takes place on the data before it ispresented, and if any trend evaluation is undertaken tounderstand the performance over a period of time. Thisinformation will be helpful in following CSI activities

� Through the negotiation process with the business,SLM would define what to measure and which aspectsto report. This would in turn drive the monitoring anddata collection requirements. If there is no capability tomonitor and/or collect data on an item then it shouldnot appear in the SLA. SLM should be a part of thereview process to monitor results

� SLM is responsible for developing and gettingagreement on OLAs and UCs that require internal orexternal monitoring.


7238-TSO-ITIL-13 28/8/07 14:01 Page 137

Availability and Capacity Management

� Provide significant input into existing monitoring anddata collection capabilities, tool requirements to meetnew data collection requirements and ensure theAvailability and Capacity Plans are updated to reflectnew or modified monitoring and data collectionrequirements

� Are accountable for the actual infrastructuremonitoring and data collection activities that takeplace. Therefore roles and responsibilities need to bedefined and the roles filled with properly skilled andtrained staff

� Are accountable for ensuring tools are in place togather data

� Are accountable for ensuring that the actualmonitoring and data collection activities areconsistently performed.

Incident Management and Service Desk

� Incident Management can define monitoringrequirements to support event and incident detectionthrough automation and also has the ability toautomatically open Incident tickets and/or auto-escalate Incident tickets

� Event and Incident monitoring can identify abnormalsituations and conditions which helps with predictingand pre-empting situations and conditions therebyavoiding possible service and component failures

� Monitor response times, repair times, resolution timesand Incident escalations

� As a single point of contact it is important for theService Desk to monitor telephony items such as callvolumes, average speed of answer, call abandonmentrates etc., so that immediate action can be taken whenthere is an increase in calls to the Service Desk. Thiswould also apply to those Service Desks who providesupport via e-mail and via the web.

Security Management

Security Management contributes to monitoring and datacollection in the following manner:

� Defines security monitoring and data collectionrequirements

� Monitors, verifies and tracks the levels of securityaccording to the organizational security policies andguidelines

� Assists in determining effects of security measures ondata monitoring and collection from the perspectivesof confidentiality (accessible only to those whoshould), integrity (data is accurate and not corruptedor not corruptible) and availability (data is availablewhen needed).

Financial Management

Financial Management is responsible for monitoring andcollecting data associated with the actual expenditures vs.budget and is able to provide input on questions such as:Are costing or revenue targets on track? FinancialManagement should also monitor the ongoing cost perservice etc.

In addition Financial Management will provide thenecessary templates to assist CSI to create the budget andexpenditure reports for the various improvement initiativesas well as providing the means to compute the ROI of theimprovements.

8.6.10 Metrics and measurementIn general, a metric is a scale of measurement defined interms of a standard, i.e. in terms of a well-defined unit.The quantification of an event through the process ofmeasurement relies on the existence of an explicit orimplicit metric (see Table 8.1), which is the standard towhich measurements are referenced.


7238-TSO-ITIL-13 28/8/07 14:01 Page 138

Metrics are a system of parameters or ways of quantitativeassessment of a process that is to be measured, alongwith the processes to carry out such measurement. Metricsdefine what is to be measured. Metrics are usuallyspecialized by the subject area, in which case they arevalid only within a certain domain and cannot be directlybenchmarked or interpreted outside it. Generic metrics,however, can be aggregated across subject areas orbusiness units of an enterprise.

8.6.11 Interpreting metricsWhen beginning to interpret the results it is important toknow the data elements that make up the results, thepurpose of producing the results and the expected normalranges of the results.

Simply looking at some results and declaring a trend isdangerous. Figure 8.3 shows a trend that the Service Deskis opening fewer incident tickets over the last few months.One could believe that this is because there are fewerIncidents or perhaps it is because the customers are nothappy with the service that is being provided, so they goelsewhere for their support needs. Perhaps theorganization has implemented a self-help knowledge baseand some customers are now using this service instead ofcontacting the Service Desk. Some investigation isrequired to understand what is driving these metrics.


Table 8.1 Service metric examples

Measure Metric Quality goal Lower limit Upper limit

Schedule

Effort

Cost

Defects

Productivity

Customer satisfaction Customer satisfactionsurvey result

Greater than 8.9 on therange of 1 to 10

Not to be less than8.9 on the range of1 to 10

% variation againstproductivity goal

Within 10% of estimate Not to be less than10% of estimate

Not to exceed 10% ofestimate

% variation againstplanned defect



% variation againstrevised plan







Within 7.5% ofestimate

Not to be less than7.5% of estimate

Not to exceed 7.5% ofestimate

7238-TSO-ITIL-13 28/8/07 14:01 Page 139

8.7 SERVICE REPORTING

A significant amount of data is collated and monitored byIT in the daily delivery of quality service to the business;however, only a small subset is of real interest andimportance to the business. (Figure 8.4 shows theprocess.) The majority of data and its meaning are moresuited to the internal management needs of IT.

The business likes to see a historical representation of thepast period’s performance that portrays their experience;however, it is more concerned with those historical eventsthat continue to be a threat going forward, and how ITintend to militate against such threats.

It is not satisfactory simply to present reports which depictadherence (or otherwise) to SLAs, which in themselves areprone to statistical ambiguity. IT needs to build anactionable approach to reporting, i.e. this is whathappened, this is what we did, this is how we will ensureit doesn’t impact you again, and this is how we areworking to improve the delivery of IT services generally.


Figure 8.3 Number of incident tickets opened over time

16,000

15,500

15,000

14,500

14,000

13,500

13,000

12,500

12,000

11,500

Janu

ary

June

May

April

March

Febr

uary

Number of incidenttickets

Num

ber

of in

cide

nt t

icke

tsop

ened

7238-TSO-ITIL-13 28/8/07 14:01 Page 140


Figure 8.4 Service reporting process

Service Reporting

The Business

IT Liaison, Education and Communication

Define Reporting Policies and Rules

Collate

Business Views

Publish

Translate and Apply

7238-TSO-ITIL-13 28/8/07 14:01 Page 141

7238-TSO-ITIL-13 28/8/07 14:01 Page 142

Complementaryguidance 9

7238-TSO-ITIL-13 28/8/07 14:01 Page 143

7238-TSO-ITIL-13 28/8/07 14:01 Page 144

9.1 ITIL AND OTHER FRAMEWORKS,PRACTICES AND STANDARDS

The IT industry has developed a number of frameworks,method and standards to manage a growing number ofneeds. Organizations can face uncertainty inunderstanding which framework, method or standard ofpractice they need in order to excel at managing ITservices. Some frameworks were developed to addressregulatory and legal compliance, others to streamline orre-engineer practices and most have origins in financialand manufacturing industries.

ITIL and many of these frameworks have a solid harmonyand can co-exist within an organization to meet a rangeof service management needs.

Following are some of the more commonly knownframeworks and standards that have synergy with ITIL.

9.1.1 COBITCOBIT® stands for Control OBjectives for Information andrelated Technology. Originally created in 1995 as an ISaudit framework, COBIT has matured to become an overallIT management framework. COBIT processes andprinciples are often used by IT and SOX auditors. COBIT isgoverned by the IT Governance Institute.

9.1.2 ISO/IEC 20000ISO/IEC 20000:2005 promotes the adoption of anintegrated process approach to effectively delivermanaged services to meet business and customerrequirements. For an organization to function effectivelyit has to identify and manage numerous linked activities.Coordinated integration and implementation of the servicemanagement processes provides ongoing control, greaterefficiency and opportunities for continual improvement.

ISO 20000 is based on the ITIL service managementprocesses.

9.1.3 ISO/IEC 15504Also known as SPICE – Software Process Improvement andCapability dEtermination – it provides a framework for theassessment of process capability. This framework can beused by organizations involved in planning, managing,monitoring, controlling and improving the acquisition,supply, development, operation, evolution and support ofproducts and services. It is also intended for use byassessors in the performance of process assessment, andby organizations involved in the development of processreference models, process assessment models or processassessment processes.

9.1.4 ISO/IEC 19770:2006Developed to enable an organization to prove that it isperforming software asset management (SAM) to astandard sufficient to satisfy corporate governancerequirements and ensure effective support for IT servicemanagement overall. It is intended to align closely to, andto support, ISO/IEC 20000. Good practice in SAM shouldresult in several benefits, and certifiable good practiceshould allow management and other organizations toplace reliance on the adequacy of these processes. Theexpected benefits should be achieved with a high degreeof confidence.

9.1.5 Management of RiskManagement of Risk (M_o_R®) provides an alternativegeneric framework for the management of risk across allparts of an organization – strategic, programme, projectand operational. It incorporates all the activities requiredto identify and control the exposure to any type of risk,

| 145

9 Complementary guidance

7238-TSO-ITIL-13 28/8/07 14:01 Page 145

positive or negative, which may have an impact on theachievement of your organization’s business objectives.

M_o_R provides a framework that is tried, tested andeffective to help you eliminate or manage the risksinvolved in reaching your goals. M_o_R adopts asystematic application of principles, approach andprocesses to the task of identifying, assessing and thenplanning and implementing risk responses.

9.1.6 Project managementPMBOK® (Project Management Body of Knowledge) isowned and authored by the Project Management Institute(PMI).

The Project Management Body of Knowledge is the sum ofknowledge within the profession of project management.As with other professions such as law, medicine andaccounting, the body of knowledge rests with thepractitioners and academics who apply and advance it.The complete Project Management Body of Knowledgeincludes proven traditional practices that are widelyapplied, as well as innovative practices that are emergingin the profession, including published and unpublishedmaterial. As a result, the Project Management Body ofKnowledge is constantly evolving. (Introduction to PMBOK,2004)

PRINCE2™ (PRoject IN Controlled Environments, v2) is astructured project management method owned by theOGC. Structured project management means managingthe project in a logical, organized way, following definedsteps. A structured project management method is thewritten description of this logical, organized approach.

9.1.7 CMMI

CMMi (Capability Maturity Model Integrated) was createdby SEI (Software Engineering Institute) at Carnegie MellonUniversity in 1991. In the beginning CMM was a model fordemonstrating the maturity of software developmentprocesses in the belief that more mature developmentprocesses led to better software. The basic Software CMMmodel has grown and been revised. CMM is now the defacto standard for measuring the maturity of any process.Organizations can be assessed against the CMM modelusing SCAMPI (Standard CMMI Appraisal Method forProcess Improvement).

9.1.8 Six SigmaThe fundamental objective of the Six Sigma methodologyis the implementation of a measurement-based strategythat focuses on process improvement and variationreduction through the application of Six Sigmaimprovement projects. This is accomplished through theuse of two Six Sigma sub-methodologies: DMAIC andDMADV. The Six Sigma DMAIC process (define, measure,analyse, improve, control) is an improvement system forexisting processes falling below specification and lookingfor incremental improvement. The Six Sigma DMADVprocess (define, measure, analyse, design, verify) is animprovement system used to develop new processes orproducts at Six Sigma quality levels. It can also beemployed if a current process requires more than justincremental improvement.

146 | Complementary guidance

7238-TSO-ITIL-13 28/8/07 14:01 Page 146

The ITIL ServiceManagement Model10

7238-TSO-ITIL-13 28/8/07 14:01 Page 147

7238-TSO-ITIL-13 28/8/07 14:01 Page 148

Through the previous chapters we have learned the basicsof the ITIL Service Lifecycle. This chapter helps to bring avisual perspective to what we have learned. The basicconcept of using Service Management Models toimplement and manage services inherently offersnumerous perspectives. Depending on your organizationalcontext, your interpretation of these will have adaptivenuances.

The ITIL Service Management Model has numerous levelsof granularity. For the purposes of learning the basics, thissection will take you through the basic constructs andelements, and offer a look at how the ServiceManagement Model is applied to designing a service. TheITIL Service Lifecycle relies on processes to execute theactivities involved in service management.

The elements within the Service Management Model willvary in depth, adaptation and interpretation amongvarious service organizations depending on circumstance,culture and structure. The Service Management Model isdesigned to be adaptive and organizations can customizethe design and use of ITIL model elements to meet theirunique needs. On its own, without any adaptation, theService Management Model is entirely complete andusable, but many organizations find that they can enhancetheir service capabilities by incorporating their own bestpractices into a hybrid structure. Care should be taken,however, when adapting the Service Management Modelnot to customize it to the point that service managementtechnologies in the consumer market are no longer ableto support your requirements.

Another important concept within the ServiceManagement Model is that not all of the elements arepurely processes. While many elements fit the typicalcharacteristics of a ‘process’, many do not. Elements such

as Availability and Capacity Management do not fitsquarely into a process profile, but are critical elements ofservice management that function across the lifecycle andmust be managed in a formal way.

10.1 MODEL ELEMENT TYPES

The ITIL Service Management Model is comprised of twoelement types: Service Lifecycle governance elements andService Lifecycle operational elements (Figure 10.1).

Figure 10.1 Service Management Model element types

Service Lifecycle governance elements exert influencethroughout the Service Lifecycle and gain feedback from

Service

Strate

gy

Continual Serv

ice

Improvement

Service

Lifecy

cle

Governance e

lements

Service

Design

Service

Transitio

n

Service

Operation

Service

Lifecy

cle

Operational e

lements

| 149

10 The ITIL Service Management Model

7238-TSO-ITIL-13 28/8/07 14:01 Page 149

all stages of the lifecycle. They reside predominantly inService Strategy and Continual Service Improvement.

The lifecycle structure of ITIL leverages process and activityelements throughout various stages of the lifecycle andFigure 10.2 illustrates the reach of each of the governanceand operational elements across the lifecycle.

The illustrations that follow are an excerpt of the full ITILintegrated Service Management Model which is availableon the ITIL Live™ web portal (www.itil-live-portal.com).

A particular scenario has been chosen to illustrate the flowand integration of the Service Management Model andhow the lifecycle flows from the inception of a service toits retirement. The scenario involves a business outcomethat will require a new service to be offered by a Service

Provider. In this scenario the Service Provider could beType I, II or III (refer to section 4.3 for a description ofService Provider types).

Not all of the Service Management Model elements areshown in their entirety in this scenario, but can bereferenced from the web portal in their entire depth andapplication. The use of this scenario is intended to helpyou gain an understanding of the basic practice andprocess elements used across the ITIL Service Lifecycle.The specific sub-process activities and work instructionsare not shown here, but again, can be obtained from theITIL web portal.

150 | The ITIL Service Management Model

Figure 10.2 Service Lifecycle governance and operational elements

Service Lifecycle Governance Processes Service Lifecycle Operational Processes

Continual Service ImprovementProcesses

Service Strategy Processes Service Design Processes Service Operation ProcessesService Transition Processes

Demand Management

IT Financial Management

Service Portfolio Management

Strategy Generation

Availability Management

Capacity Management

Information Security Management

Service Catalogue Management

Service Continuity Management

Service Level Management

Supplier Management

Change Management

Evaluation

Knowledge Management

Release and Deployment Management

Service Asset and Configuration Management

Service Validation and Testing

Transition Planning and Support

Access Management

Event Management

Incident Management

Operation Management

Problem Management

Request Fulfilment

Service Improvement

Service Measurement

Service Reporting

7238-TSO-ITIL-13 28/8/07 14:01 Page 150

10.2 BASIC ELEMENTS

As a Service Provider, the interactions you will have in thedevelopment and delivery of services to the business willdepend on the type of Service Provider you are.

Type I

Figure 10.3 Typical Type I Service Provider interactions

As discussed in earlier sections of this publication, a Type IService Provider (Figure 10.3) is most often the point offocus for the business customer and all IT service needsare managed by the Service Provider using a valuenetwork of partnerships.

Service Provider SubstitutorComplementor

Supplier

Customer

Generic Value Network

The ITIL Service Management Model | 151

7238-TSO-ITIL-13 28/8/07 14:01 Page 151

A Type II Service Provider (Figure 10.4) will often be part ofa shared Service Management Model and will provideservices to a number of business customers and managethe interactions with the business customers and anexternal value network.

A Type III Service Provider (Figure 10.5) is most often anorganization external to the business and interacts withthe value network on behalf of the business customer.

Regardless of the Service Provider type, each will requirethe use of a range of Service Management Model processand practice elements to manage services effectively andmeasure the value provided to the business customer.

Figure 10.6 outlines the main process elements across theService Lifecycle model. They are depicted with a logicalflow pattern; however, they are not always executed in alinear fashion and so this should be taken into account.


Type II

Figure 10.4 Type II Service Provider interactions

Complementor Substitutor

Business Unit A Business Unit B Business Unit C

Business ServicesBusiness Services

Business Customers

Business Services

Company IT Services IT Services IT Services

Business Services

Shared ServiceProvider (Type II)

Service Provider Type II Value Network

Supplier

Business Services

Supplier Services Supplier Services

Supplier Services

7238-TSO-ITIL-13 28/8/07 14:01 Page 152

Each of the start and termination nodes depicts an inputthat triggers the process or an output that triggers anotherprocess.

As an example, Figure 10.6 illustrates that the trigger forthe Service Strategy processes is a desired businessstrategy. The termination of the Service Strategy processesis the chartering of a service and the supply of a ServiceLevel Package, which then triggers the Service Designprocesses, and so on.

Within each process element, a number of main practiceelements accompany each process and are carried outduring the lifecycle. Figure 10.7 illustrates these.

Each of the elements shown is comprised of a variety ofactivities. These are not described here in detail butprovided to illustrate the main practice activities anorganization would expect to execute during the ServiceLifecycle. Details about each of these can be found in theITIL Service Management core lifecycle publications andon the ITIL Live™ web portal (www.itil-live-portal.com).


Type III

Figure 10.5 Type III Service Provider interactions

Complementor SubstitutorExternal ServiceProvider (Type III)

Business ServicesBusiness ServicesBusiness Customers

Company

Business Services

Service Provider Type III Value Network

Supplier

Supplier Services Supplier Services

Supplier Services

7238-TSO-ITIL-13 28/8/07 14:01 Page 153


Figure 10.6 Basic Service Management Model process elements

Business Strategy

StrategyGeneration

FinancialManagement

DemandManagement

ServicePortfolio

Management

Charter Service

Service LevelPackage

ServiceCatalogue

Management

CapacityManagement

AvailabilityManagement

Service LevelManagement

InformationSecurity

Management

SupplierManagement

Service DesignPackage

TransitionPlanning &

Support

ChangeManagement

Service Asset&

ConfigurationManagement

Validation &Testing

Management

Release &DeploymentManagement

EvaluationManagement

ServiceKnowledge

Management

Service Released

Early Life Support

EventManagement

RequestFulfilment

IncidentManagement

ProblemManagement

TechnologyManagement

AccessManagement

OperationsManagement

ServicePerformanceReporting

Service Reporting

ServiceMeasurement

ServiceAnalysis

ServiceReporting

ServiceImprovement

Feedbackthroughout the

lifecycle

IT ServiceContinuity

Management


ITIL Service Lifecycle – Main Process Elements

Service Strategy Service Design ServiceTransition

ServiceOperation

ContinualService

Improvement

Denotes maininput or output

Denotes pre-defined practice,activity or process

element

7238-TSO-ITIL-13 28/8/07 14:01 Page 154

10.3 CREATING A SERVICE

The next series of workflow diagrams will take youthrough the practices, processes and activities of creatinga service. As in the earlier diagrams, these are onlydepicted at the top level of workflow, but they willprovide a solid understanding of the elements required.

10.4 STRATEGY GENERATION

When a business identifies a needed outcome, ServiceStrategy must define a number of supporting elements todeliver it. First, the perspectives, positions, plans andpatterns of actions that help define the market spaces thatthe service will thrive in to deliver business value must beevaluated (see Figure 10.8, taken from the Service Strategy

publication). This is achieved through a strategicassessment, establishing objectives and a resulting servicestrategy. In our chosen scenario – creating a service – notall of these must be executed each and every time.

Assuming we have a Service Portfolio in place, thecreation of a service must be subject to an evaluation ofthe existing services and provider capabilities to determinethe best course of action.

Figure 10.9 illustrates the breadth of a Service Portfolioand the elements that need to be assessed to decide onthe course of action.


Figure 10.7 ITIL Service Lifecycle main practice elements

ITIL Service Lifecycle – Main Practice Elements

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sition

Serv

ice

Oper

atio

n

Continual

Serv

ice

Impro

vem

ent

Required businessoutcome identified

Define themarket

Defineservice

structures

Develop CostModel

Develop theServicePortfolio

DevelopStrategicAssets

CharterService


Designtechnologyarchitecture

Designmanagement

systems &tools

Designmeasurement

systems,methods &

metrics

DesignProcesses

DesignSolutions

CreateServiceDesignPackage


DevelopTransition &Support Plan

CoordinateOrganizationand Service

Change

Plan, Build,Test andValidateServiceRelease

ConductService

Testing andPilots

Transfer,Deploy or

RetireService

Provide EarlyLife Support

Deployed ServiceMonitor &ControlServices

ManageCustomer

requests andcommunication

ManageEvents,

Incidentsproblems

Generatemetrics on

Serviceperformance

Participate instrategy,

design andtransition

ProvideService

PerformanceReports

Service ReportsAnalyze and

trends servicereports

Provide multi-view

assessments &performance

results

ConductService

performancebaselines

Defineservice

benchmarks

Liaise withStrategy,Design,

Operation &Transition

CreateService

ImprovementProgramme

7238-TSO-ITIL-13 28/8/07 14:01 Page 155


Figure 10.8 Forming and formulating a Service Strategy

Strategy generation, evaluation and selection

•

• Service Design requirements

• Service Transition requirements

• Service Operation requirements

Measurement and evaluation

Measurement and evaluation

Analyse external factors

Analyse internal factors

Establish objectives

Determine perspective

Form a position

Craft a plan

Adopt patterns of

action

Strategic assessment

Service Strategy

Continual Service

Improvement

Service Portfolio

Vision

Policies

Plans

Actions

7238-TSO-ITIL-13 28/8/07 14:01 Page 156


Figure 10.9 The Service Portfolio

Third-partycatalogue

Serviceoperation

Retiredservices

Resourcesreleased

Service Catalogue


Marketspaces

Servicedesign

Servicetransition

Serviceconcepts

Return on assetsearned from

Service operation

Resourcesengaged

Customers

Common pool of resources

Service Pipeline

Service Portfolio

Area of circle is proportional to resources currently engaged in the lifecyclephase (Service Portfolio and Financial Management)

7238-TSO-ITIL-13 28/8/07 14:01 Page 157

10.5 DECIDING THE COURSE OF ACTION TOCREATE A NEW SERVICE

10.5.1 Stage 1 – Service Strategy elementsIn Figure 10.10, Service Strategy evaluates the ServicePortfolio to determine if existing capabilities are in placeto create the service and deliver the desired businessoutcomes. Note that other parts of the ITIL ServiceLifecycle are involved during the assessment. For exampleService Design will evaluate the existing Service Catalogueto determine if live services can be tagged to deliver therequired business outcomes. Service Transition becomesinvolved when the new service is designed either fromexisting capabilities in the Service Portfolio or Catalogue,or added to them, and moves to the transition stage ofthe Service Lifecycle.

If during this assessment the business decides that theoptions available cannot be committed to at the time,Continual Service Improvement will review this periodicallyto determine if a future time is appropriate to charter andcreate the service or if there are external catalysts thatmight make it feasible to proceed at a particular point intime as part of a service improvement programme.

10.5.2 Stage 2 – Design the solutionIn this stage, all parts of the Service Lifecycle are involved(Figure 10.11). Each provides input as part of therequirements-gathering stage to ensure that a full service-focused view is understood and leveraged when designingthe service. Examples of the benefits in involving all partsof the Service Provider network are:


Figure 10.10 Stage 1 – Service Strategy elements

Service Strategy – Define Market

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sition

Serv

ice

Oper

atio

n

Continual

Serv

ice

Impro

vem

ent

Identify businessoutcome

Match outcome toservices in ServicePortfolio pipeline

Tag serviceportfolio with

service conceptoutcome

Charter Service

Match outcome toservices in Service

Catalogue

Tag service withoutcome

Negotiate ServiceLevel Agreement

Add to ContractPortfolio

DesignServiceSolution

Prepare forTransition

Review desiredoutcome

periodically or onexception

A good match? New serviceJustified?

Customer willcommit?

A good match?

NoNo

Yes

Yes

Yes

Yes

No

7238-TSO-ITIL-13 28/8/07 14:01 Page 158

� Ability to re-use existing technology and resources inthe operation and support of the new services

� Understanding the impact across the Service Providernetwork of introducing a new service

� Ensuring that the new Service Design is consistent withthe capabilities planned and future investment strategyof the organization.

It is important to note that the Service Design stage of thelifecycle will also consider design activities that ensureAvailability, Capacity, Security, Service Continuity etc. Thisis done during the solution design as part of the fiveaspects of Service Design (refer to the Service Design corepublication). The detailed Service Management Modelelements for these are available on the ITIL Live Webportal (www.itil-live-portal.com).

A full description of these elements and the guidance onexecuting them can be found in the Service Design corepublication.

10.5.3 Stage 3 – Transition the serviceFor a service being built, once the Service Design Package(SDP) has been created during the Service Design stage,the service can be planned, built, tested and deployed.During the Service Transition stage the elements executeddraw from key Service Transition processes:

� Transition Planning and Support


� Service Asset and Configuration Management

� Service Validation and Testing Management

� Release and Deployment Management.


Figure 10.11 Stage 2 – Design service solution

Service Design – Design Service Solution

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sition

Serv

ice

Oper

atio

n

Continual

Serv

ice

Impro

vem

ent


ConductStakeholderInterviews

CompleteRequirements

template

Obtainsignoff

Finalizerequirements

catalogue

Create ServiceDesignPackage

Issue RFI orRFT

Evaluate andprocureservice

Provide inputto

requirements

Service Design Package

Provide inputto

requirements

Provide inputto

requirements

Build or buy?

Requirementssigned off?

BuyBuy

Build Build

YesNo

7238-TSO-ITIL-13 28/8/07 14:01 Page 159

The process workflows for these can be found both in theService Transition core publication and the ITIL Live webportal (www.itil-live-portal.com).

Figure 10.14 shows an example of the ChangeManagement process as it would be executed in thisscenario. It would be included as part of the elementsshown in Figure 10.13, which are an extract from the‘Transition the service’ workflow in Figure 10.12.

The full Change Management process flow for theseelements (Figure 10.14) is taken from the ServiceTransition publication.

Now that the scenario has reached the stage of going intolive operation, there are many interactions and informationflows that are being passed through the various stages ofthe ITIL Service Lifecycle. Figure 10.15 depicts some ofthose interactions from a view during the transition stageof the lifecycle. Note the assortment of data andinformation passing between stages by this point in thecreation of the service.


Figure 10.12 Stage 3 – Transition the service

Service Transition – Transition Service

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sition

Serv

ice

Oper

atio

n

Continual

Serv

ice

Impro

vem

ent


Review &Acceptance of

inputs

Conduct ServiceAcceptance test

Raise RFC &record

configurationbaselines

Assess, evaluate& authorize

change

CoordinateChange

implementation

Build and Test thesolution

Conduct servicepilot

Acceptable?

Passed tests?

No

Yes

Yes

Create ServiceDesign Package

Revise Service Design Package

Design ServiceAcceptance

Criteria

Create servicerelease test criteria

& plan

Service releasepackage test

DeployService

Early life support

No

7238-TSO-ITIL-13 28/8/07 14:01 Page 160


Figure 10.13 Change Management elements

Raise RFC &record

configurationbaselines

Assess, evaluate& authorize

change

CoordinateChange

implementation

Figure 10.14 Normal Change Management process

CreateRFC

Changeproposal (optional)

Record theRFC

ReviewRFC

Assess and evaluatechange

AuthorizeChange

Plan updates

Work orders

Initiator

ChangeManagement

ChangeAuthority

ChangeManagement

ready for evaluation

ready for decision

authorized

Update change and configuration inform

ation in CM

S

Work orders

Coordinate changeimplementation*

Review and closechange record

ChangeManagement

scheduled

implemented

closed

requested

Evaluation report

AuthorizeChange proposal

*Includes build and test the change

7238-TSO-ITIL-13 28/8/07 14:01 Page 161

10.5.4 Stage 4 – Operate the serviceIn our scenario we have now deployed the new serviceand have accepted it into live operation. But the workfrom Strategy, Design and Transition is not done.

Early life support is a critical part of ensuring that what wehave planned, built, tested and installed is producing the

predicted results and meeting the business outcomes westarted with.

Beyond early life support, the service becomes ‘business asusual’ and is continuously monitored and controlled,becoming part of the overall service value to the businesscustomer.


Figure 10.15 Information flows at the Service Transition stage

Service Notification ServiceReleasePackage

Change Request

ServiceReleasePackage

Service TestReport

Updated Service Asset DataRelease Data

Change RequestServiceTransitionImprovementPlan

Service Transition Reports

StrategyData

Service Design Package Transition Plan

Service Provider

Release Data

Information Meta-data Design Data

Release Data

Operation Data

Service DesignProcesses

TransitionPlanning and

Support

Release and Deployment Management Activitieswithin Transition Phase

Service Asset and Configuration Management Activities within Transition Phase

Service Design Activitieswithin Transition Phase

Service Operation Activitieswithin Transition Phase

Knowledge ManagementActivities withinTransition Phase

Change Management

Activitieswithin

TransitionPhase

Service Validation andTesting

Evaluation Activitieswithin Transition Phase Service

OperationProcesses

ServiceStrategyActivities within

TransitionPhase

ServiceLifecycle

GovernanceProcesses

Change Evaluation

Customer

7238-TSO-ITIL-13 28/8/07 14:01 Page 162

The workflow in Figure 10.16 depicts the high-levelactivities within Service Operation. The details of eachprocess element and activity can be found in the ServiceOperation core publication and the ITIL Live™ web portal(www.itil-live-portal.com).

During early life support Service Transition and ServiceOperation work together. As is often the case, a number ofissues with a new service may be uncovered. Dependingupon the nature of these, information should be recordedeither as events, incidents or known errors, and passedalong the workflow accordingly. Service Strategy, ServiceDesign and Continual Service Improvement should be

provided with feedback on the performance of the newservice, any issues that are revealed, how the businesscustomer is adapting to use of the new service, etc.

It is at this stage that the measurement systems andmetrics created at the design stage begin to be generatedand accumulated for service reporting. It is also at thisstage that the quality and value of the new service arerealized since the business is now fully engaged in its use.

A few examples of the full process workflows in ServiceOperation are given in Figures 10.17 and 10.18. The fullintegrated Service Management Model and process flowscan be obtained on the ITIL Live web portal.


Figure 10.16 Stage 4 – Operate the service

Service Operation – Operate Service

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sition

Serv

ice

Oper

atio

nContinual

Serv

ice

Impro

vem

ent

Early Life Supportof live service Monitor & Control

serviceIncident

Management

CustomerSelf Service

Service DeskRequest

Fulfilment

OperationalChange

Management

ProactiveProblemAnalysis

ProblemManagement

ChangeManagement

EventManagement

AccessManagement

IT Operations &Administration

CorrectiveAction &Service

Improvement

Business Interfaceto Service

Management

7238-TSO-ITIL-13 28/8/07 14:01 Page 163



Effective?

Event

Event NotificationGenerated

Event Detected

Event Filtered

Significance?

Event Correlation

Trigger

Event Logged Auto Response Alert

HumanIntervention

IncidentManagement

ProblemManagement

ChangeManagement

Review Actions

Close Event

Incident/Problem/Change?

InformationalInformational ExceptionException

WarningWarning

Change

Problem

Incident

End

Yes

No

7238-TSO-ITIL-13 28/8/07 14:01 Page 164



Yes

FromEventMgmt

FromWeb

Interface

UserPhoneCall

EmailTechnical

Staff

IncidentIdentification

IncidentCategorization

Service Request? To RequestFulfilment

IncidentPrioritization

Major IncidentProcedure Major Incident?

FunctionalEscalation2/3 Level

HierarchicEscalationNeeded?

ManagementEscalation


Resolutionand Recovery

Incident Closure

IncidentLogging

Yes

No

Yes

InitialDiagnosis

FunctionalEscalationNeeded?

No

End

Yes

Yes No

No

7238-TSO-ITIL-13 28/8/07 14:01 Page 165

The new service is now in full operation and much moreinformation is being exchanged within the ITIL ServiceLifecycle. An example of this is provided in Figure 10.19.

10.5.5 Stage 5 – Continual ServiceImprovement

Even a new designed service will undergo improvementsover time. There are many reasons for this. Businessoutcomes change as business needs evolve. Newtechnologies become available that are sought after toimprove services. Competitive forces demand rapidchange capability for both business outcomes and ServiceProviders.

Whatever the reason behind the need for change, theContinual Service Improvement stage offers the means tocast an eye over the performance, utility and warrant ofthe new service on an ongoing basis.

Figure 10.20 illustrates some of the main elements andprocesses involved in service improvement.

The Continual Service Improvement core publicationdocuments the full process elements. With a new service,the activities revolve around ensuring that business valueand expected outcomes are being achieved, andidentifying where there are opportunities to improvefurther. Continual Service Improvement feeds back toevery stage in the Service Lifecycle.


Figure 10.19 Information flow in the Service Operation stage

Operation Management Activities within Operational Phase

ServiceTransitionProcesses

RequestFulfilment

IncidentManagement

ProblemManagement

Activities withinOperation Phase

AccessManagement

EventManagement

Service TransitionActivities withinOperation Phase

ServiceLifecycle

GovernanceProcesses

Service StrategyActivities withinOperation Phase

Service DesignActivities withinOperation Phase

Service Reports

Service Reports

Service OperationImprovement Plan

Service OperationReports

Operation DataOperation Data

Operation Data

Supplier Services Demand

Charge Request

Charge Request

Incidents

Incidents

Incidents

Charge Request

Service Release Package

IT Services

IT Services Demand

Access Request

Events

Supplier Services

Service Provider

Customer

Supplier

7238-TSO-ITIL-13 28/8/07 14:01 Page 166

Figure 10.21 shows the information flow within theprocess elements of Continual Service Improvement.

These five stages form part of a larger, integrated ServiceManagement Model and show how they would be appliedfor the creation of a new service. Organizations shouldthink of the broader picture of the ebb, flow andinteractions within the Service Lifecycle.

Figure 10.22 shows the high-level integrated flowbetween lifecycle stages.

If we think of the main elements involved in the creationof a new service as layers through the lifecycle (Figure10.23), we see the interactions and dependencies neededto ensure that business outcomes and business value aremet.

Readers are encouraged to learn more about theintegrated ITIL Service Management Model by exploringthe core ITIL Service Management publications and visitingthe ITIL Live™ web portal (www.itil-live-portal.com).


Figure 10.20 Stage 5 – Continual Service Improvement

Continual Service Improvement – Review Service Performance

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sition

Serv

ice

Oper

atio

n

Continual

Serv

ice

Impro

vem

ent

Service Reports

Feedback onimprovementopportunities




Analyze andtrends service

reports

Provide multi-view

assessments &performance

results

ConductService

performancebaselines

Defineservice

benchmarks

Liaise withStrategy,Design,

Operation &Transition

CreateService

ImprovementProgramme

7238-TSO-ITIL-13 28/8/07 14:01 Page 167


Figure 10.21 Information flow within Continual Service Improvement

ServiceLifecycle

OperationalProcesses

Service Reporting

Supplier Service Reports

Service Provider

Supplier

Internal Service Reports

ServiceManagement

ServiceImprovement

Service Analysis Supplier Service Improvement Plan

Service Improvement Plans

Service Reports

ServiceStrategyProcesses

IT Strategy

Service Improvement Plan

7238-TSO-ITIL-13 28/8/07 14:01 Page 168


Figure 10.22 Integrated lifecycle elements flow

Define the Metrics Analyze

Continual

Service

Improvement Service

Measurement

Service

ReportingImprove

7 Step Improvement

Baseline & Metrics Data Analysis Corrective Action

Service

Improvement

Plan

Optimize Risk Verify

Service

Transition

Change

Management

Service Asset &

Configuration

Management

Release &

Deployment

Management

Planning & Support

Quality Assurance Service Acceptance Utility and Warranty Decision CapabilityConformance

Validation & Testing Evaluation Knowledge

Service Level

PackageDefine the Market Develop Offerings

Service

StrategyStrategy

Generation

Demand

Management

Service

Portfolio

Management

IT Financial Management

Opportunities & Constraints Cost Models Return on Investment Return on Value

Service

Operation

Operational Change

Stability Optimization Performance Quality for CostMonitor Control Loops

Problem Technology Access

Feedback

Event

ManagementMonitor & ActionIncident

ManagementResolve & Restore

Request

Fulfilment

Service

Design

Availability

Reliabilty Balanced Design Measurement Systems ArchitectureRequirements

Capacity Security Continuity

Compliance

Service

Catalogue

Management

Design SolutionService Level

ManagementNegotiate and Agree

Supplier

Management

Service Design

Package

Early Life

Support

Service

Performance

Reports

7238-TSO-ITIL-13 28/8/07 14:01 Page 169


Figure 10.23 Layered view of the main elements in the Service Lifecycle

Stage 5

– Improve t

he Serv

iceStage 4

– Opera

te the S

erviceSta

ge 3 – T

ransitio

n the Serv

iceStage 2

– Desig

n the Solution

Service

Lifecy

cle

Elements

Stage 1

– Defin

e Marke

t

7238-TSO-ITIL-13 28/8/07 14:01 Page 170

Acronyms

7238-TSO-ITIL-13 28/8/07 14:01 Page 171

7238-TSO-ITIL-13 28/8/07 14:01 Page 172

ACD Automatic Call Distribution

AM Availability Management

AMIS Availability Management Information System

ASP Application Service Provider

BCM Business Capacity Management

BCM Business Continuity Management

BCP Business Continuity Plan

BIA Business Impact Analysis

BRM Business Relationship Manager

BSI British Standards Institution

BSM Business Service Management

CAB Change Advisory Board

CAB/EC Change Advisory Board/EmergencyCommittee

CAPEX Capital Expenditure

CCM Component Capacity Management

CFIA Component Failure Impact Analysis

CI Configuration Item

CMDB Configuration Management Database

CMIS Capacity Management Information System

CMM Capability Maturity Model

CMMI Capability Maturity Model Integration

CMS Configuration Management System

COTS Commercial off the Shelf

CSF Critical Success Factor

CSI Continual Service Improvement

CSIP Continual Service Improvement Plan

CSP Core Service Package

CTI Computer Telephony Integration

DIKW Data-to-Information-to-Knowledge-to-Wisdom

ELS Early Life Support

eSCM-CL eSourcing Capability Model for ClientOrganizations

eSCM-SP eSourcing Capability Model for ServiceProviders

FMEA Failure Modes and Effects Analysis

FTA Fault Tree Analysis

IRR Internal Rate of Return

ISG IT Steering Group

ISM Information Security Management

ISMS Information Security Management System

ISO International Organization forStandardization

ISP Internet Service Provider

IT Information Technology

ITSCM IT Service Continuity Management

ITSM IT Service Management

itSMF IT Service Management Forum

IVR Interactive Voice Response

KEDB Known Error Database

| 173

Acronyms

7238-TSO-ITIL-13 28/8/07 14:01 Page 173

KPI Key Performance Indicator

LOS Line of Service

M_o_R Management of Risk

MTBF Mean Time Between Failures

MTBSI Mean Time Between Service Incidents

MTRS Mean Time to Restore Service

MTTR Mean Time to Repair

NPV Net Present Value

OGC Office of Government Commerce

OLA Operational Level Agreement

OPEX Operational Expenditure

OPSI Office of Public Sector Information

PBA Pattern of Business Activity

PFS Prerequisite for Success

PIR Post-Implementation Review

PSA Projected Service Availability

QA Quality Assurance

QMS Quality Management System

RCA Root Cause Analysis

RFC Request for Change

ROI Return on Investment

RPO Recovery Point Objective

RTO Recovery Time Objective

SAC Service Acceptance Criteria

SACM Service Asset and ConfigurationManagement

SCD Supplier and Contract Database

SCM Service Capacity Management

SDP Service Design Package

SFA Service Failure Analysis

SIP Service Improvement Plan

SKMS Service Knowledge Management System

SLA Service Level Agreement

SLM Service Level Management

SLP Service Level Package

SLR Service Level Requirement

SMO Service Maintenance Objective

SoC Separation of Concerns

SOP Standard Operating Procedures

SOR Statement of requirements

SPI Service Provider Interface

SPM Service Portfolio Management

SPO Service Provisioning Optimization

SPOF Single Point of Failure

TCO Total Cost of Ownership

TCU Total Cost of Utilization

TO Technical Observation

TOR Terms of Reference

TQM Total Quality Management

UC Underpinning Contract

UP User Profile

VBF Vital Business Function

VOI Value on Investment

WIP Work in Progress

174 | Acronyms

7238-TSO-ITIL-13 28/8/07 14:01 Page 174

Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 175

7238-TSO-ITIL-13 28/8/07 14:01 Page 176

The publication names included in parentheses after thename of a term identify where a reader can find moreinformation about that term. This is either because theterm is primarily used by that publication or becauseadditional useful information about that term can befound there. Terms without a publication name associatedwith them may be used generally by several publications,or may not be defined in any greater detail than can befound in the glossary, i.e. we only point readers tosomewhere they can expect to expand on theirknowledge or to see a greater context. Terms withmultiple publication names are expanded on in multiplepublications.

Where the definition of a term includes another term,those related terms are given initial capitals. This isdesigned to help the reader with their understanding bypointing them to additional definitions that are all part ofthe original term they were interested in. The form ‘Seealso Term X, Term Y’ is used at the end of a definitionwhere an important related term is not used with the textof the definition itself.

AcceptanceFormal agreement that an IT Service, Process, Plan or otherDeliverable is complete, accurate, reliable and meets itsspecified Requirements. Acceptance is usually precededby Evaluation or Testing and is often required beforeproceeding to the next stage of a Project or Process. Seealso Service Acceptance Criteria.

Access Management(Service Operation) The Process responsible for allowingUsers to make use of IT Services, data, or other Assets.Access Management helps to protect the Confidentiality,Integrity and Availability of Assets by ensuring that only

authorized Users are able to access or modify the Assets.Access Management is sometimes referred to as RightsManagement or Identity Management.

Account Manager(Service Strategy) A Role that is very similar to BusinessRelationship Manager, but includes more commercialaspects. Most commonly used when dealing with ExternalCustomers.

Accounting(Service Strategy) The Process responsible for identifyingactual Costs of delivering IT Services, comparing thesewith budgeted costs, and managing variance from theBudget.

AccreditedOfficially authorized to carry out a Role. For example anAccredited body may be authorized to provide training orto conduct Audits.

Active Monitoring(Service Operation) Monitoring of a Configuration Item oran IT Service that uses automated regular checks todiscover the current status. See also Passive Monitoring.

ActivityA set of actions designed to achieve a particular result.Activities are usually defined as part of Processes or Plans,and are documented in Procedures.

| 177

Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 177

Agreed Service Time(Service Design) A synonym for Service Hours, commonlyused in formal calculations of Availability. See alsoDowntime.

AgreementA Document that describes a formal understandingbetween two or more parties. An Agreement is not legallybinding, unless it forms part of a Contract. See also ServiceLevel Agreement, Operational Level Agreement.

Alert(Service Operation) A warning that a threshold has beenreached, something has changed, or a Failure hasoccurred. Alerts are often created and managed by SystemManagement tools and are managed by the EventManagement Process.

Analytical Modelling(Service Strategy) (Service Design) (Continual ServiceImprovement) A technique that uses mathematical Modelsto predict the behaviour of a Configuration Item or ITService. Analytical Models are commonly used in CapacityManagement and Availability Management. See alsoModelling.

ApplicationSoftware that provides Functions that are required by an ITService. Each Application may be part of more than one ITService. An Application runs on one or more Servers orClients. See also Application Management, ApplicationPortfolio.

Application Management(Service Design) (Service Operation) The Functionresponsible for managing Applications throughout theirLifecycle.

Application Portfolio(Service Design) A database or structured Document usedto manage Applications throughout their Lifecycle. TheApplication Portfolio contains key Attributes of allApplications. The Application Portfolio is sometimesimplemented as part of the Service Portfolio, or as part ofthe Configuration Management System.

Application Service Provider(Service Design) An External Service Provider that providesIT Services using Applications running at the ServiceProvider’s premises. Users access the Applications bynetwork connections to the Service Provider.

Application Sizing(Service Design) The Activity responsible for understandingthe Resource Requirements needed to support a newApplication, or a major Change to an existing Application.Application Sizing helps to ensure that the IT Service canmeet its agreed Service Level Targets for Capacity andPerformance.

Architecture(Service Design) The structure of a System or IT Service,including the Relationships of Components to each otherand to the environment they are in. Architecture alsoincludes the Standards and Guidelines that guide thedesign and evolution of the System.

Assembly(Service Transition) A Configuration Item (CI) that is madeup of a number of other CIs. For example a Server CI maycontain CIs for CPUs, disks, memory, etc.; an IT Service CImay contain many hardware, software and other CIs. Seealso Component CI, Build.

178 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 178

AssessmentInspection and analysis to check whether a Standard or setof Guidelines is being followed, that Records are accurate,or that Efficiency and Effectiveness targets are being met.See also Audit.

Asset(Service Strategy) Any Resource or Capability. Assets of aService Provider including anything that could contributeto the delivery of a Service. Assets can be one of thefollowing types: Management, Organization, Process,Knowledge, People, Information, Applications,Infrastructure and Financial Capital.

Asset Management(Service Transition) Asset Management is the Processresponsible for tracking and reporting the value andownership of financial Assets throughout their Lifecycle.Asset Management is part of an overall Service Asset andConfiguration Management Process. See also AssetRegister.

Asset Register(Service Transition) A list of Assets that includes theirownership and value. Asset Management maintains theAsset Register.

Attribute(Service Transition) A piece of information about aConfiguration Item. Examples are: name, location, versionnumber and Cost. Attributes of CIs are recorded in theConfiguration Management Database (CMDB). See alsoRelationship.

AuditFormal inspection and verification to check whether aStandard or set of Guidelines is being followed, that

Records are accurate, or that Efficiency and Effectivenesstargets are being met. An Audit may be carried out byinternal or external groups. See also Certification,Assessment.

Authority MatrixSee RACI.

Automatic Call Distribution(Service Operation) Use of Information Technology todirect an incoming telephone call to the most appropriateperson in the shortest possible time. ACD is sometimescalled Automated Call Distribution.

Availability(Service Design) Ability of a Configuration Item or ITService to perform its agreed Function when required.Availability is determined by Reliability, Maintainability,Serviceability, Performance and Security. Availability isusually calculated as a percentage. This calculation is oftenbased on Agreed Service Time and Downtime. It is BestPractice to calculate Availability using measurements ofthe Business output of the IT Service.

Availability Management(Service Design) The Process responsible for defining,analysing, Planning, measuring and improving all aspectsof the Availability of IT services. Availability Management isresponsible for ensuring that all IT Infrastructure, Processes,Tools, Roles etc. are appropriate for the agreed ServiceLevel Targets for Availability.

Availability Management Information System(Service Design) A virtual repository of all AvailabilityManagement data, usually stored in multiple physicallocations.

Glossary | 179

7238-TSO-ITIL-13 28/8/07 14:01 Page 179

Availability Plan(Service Design) A Plan to ensure that existing and futureAvailability Requirements for IT Services can be providedCost Effectively.

Back-outSee Remediation.

Backup(Service Design) (Service Operation) Copying data toprotect against loss of Integrity or Availability of theoriginal.

Balanced Scorecard(Continual Service Improvement) A management tooldeveloped by Drs Robert Kaplan (Harvard Business School)and David Norton. A Balanced Scorecard enables aStrategy to be broken down into Key PerformanceIndicators. Performance against the KPIs is used todemonstrate how well the Strategy is being achieved. ABalanced Scorecard has four major areas, each of whichhas a small number of KPIs. The same four areas areconsidered at different levels of detail throughout theOrganization.

Baseline(Continual Service Improvement) A Benchmark used as areference point. For example:

� An ITSM Baseline can be used as a starting point tomeasure the effect of a Service Improvement Plan

� A Performance Baseline can be used to measurechanges in Performance over the lifetime of an ITService

� A Configuration Management Baseline can be used toenable the IT Infrastructure to be restored to a knownConfiguration if a Change or Release fails.

Benchmark(Continual Service Improvement) The recorded state ofsomething at a specific point in time. A Benchmark can becreated for a Configuration, a Process or any other set ofdata. For example, a benchmark can be used in:

� Continual Service Improvement, to establish thecurrent state for managing improvements

� Capacity Management, to document performancecharacteristics during normal operations.

See also Benchmarking, Baseline.

Benchmarking(Continual Service Improvement) Comparing a Benchmarkwith a Baseline or with Best Practice. The termBenchmarking is also used to mean creating a series ofBenchmarks over time, and comparing the results tomeasure progress or improvement.

Best PracticeProven Activities or Processes that have been successfullyused by multiple Organizations. ITIL is an example of BestPractice.

Brainstorming(Service Operation) A technique that helps a team togenerate ideas. Ideas are not reviewed during theBrainstorming session, but at a later stage. Brainstorming isoften used by Problem Management to identify possiblecauses.

British Standards InstitutionThe UK National Standards body, responsible for creatingand maintaining British Standards. See www.bsi-global.com for more information. See also ISO.

180 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 180

BudgetA list of all the money an Organization or Business Unitplans to receive, and plans to pay out, over a specifiedperiod of time. See also Budgeting, Planning.

BudgetingThe Activity of predicting and controlling the spending ofmoney. Consists of a periodic negotiation cycle to setfuture Budgets (usually annual) and the day-to-daymonitoring and adjusting of current Budgets.

Build(Service Transition) The Activity of assembling a number ofConfiguration Items to create part of an IT Service. Theterm Build is also used to refer to a Release that isauthorized for distribution. For example server Build orlaptop Build. See also Configuration Baseline.

Build Environment(Service Transition) A controlled Environment whereApplications, IT Services and other Builds are assembledprior to being moved into a Test or Live Environment.

Business(Service Strategy) An overall corporate entity orOrganization formed of a number of Business Units. In thecontext of ITSM, the term Business includes public sectorand not-for-profit organizations, as well as companies. AnIT Service Provider provides IT Services to a Customerwithin a Business. The IT Service Provider may be part ofthe same Business as its Customer (Internal ServiceProvider), or part of another Business (External ServiceProvider).

Business Capacity Management (BCM)(Service Design) In the context of ITSM, Business CapacityManagement is the Activity responsible for understanding

future Business Requirements for use in the Capacity Plan.See also Service Capacity Management.

Business Case(Service Strategy) Justification for a significant item ofexpenditure. Includes information about Costs, benefits,options, issues, Risks and possible problems. See also CostBenefit Analysis.

Business Continuity Management(Service Design) The Business Process responsible formanaging Risks that could seriously affect the Business.BCM safeguards the interests of key stakeholders,reputation, brand and value-creating activities. The BCMProcess involves reducing Risks to an acceptable level andplanning for the recovery of Business Processes should adisruption to the Business occur. BCM sets the Objectives,Scope and Requirements for IT Service ContinuityManagement.

Business Continuity Plan(Service Design) A Plan defining the steps required toRestore Business Processes following a disruption. The Planwill also identify the triggers for Invocation, people to beinvolved, communications etc. IT Service Continuity Plansform a significant part of Business Continuity Plans.

Business Customer(Service Strategy) A recipient of a product or a Servicefrom the Business. For example, if the Business is a carmanufacturer then the Business Customer is someone whobuys a car.

Business Impact Analysis(Service Strategy) BIA is the Activity in Business ContinuityManagement that identifies Vital Business Functions andtheir dependencies. These dependencies may includeSuppliers, people, other Business Processes, IT Services etc.

Glossary | 181

7238-TSO-ITIL-13 28/8/07 14:01 Page 181

BIA defines the recovery requirements for IT Services.These requirements include Recovery Time Objectives,Recovery Point Objectives and minimum Service LevelTargets for each IT Service.

Business Objective(Service Strategy) The Objective of a Business Process, orof the Business as a whole. Business Objectives supportthe Business Vision, provide guidance for the IT Strategyand are often supported by IT Services.

Business Operations(Service Strategy) The day-to-day execution, monitoringand management of Business Processes.

Business Perspective(Continual Service Improvement) An understanding of theService Provider and IT Services from the point of view ofthe Business, and an understanding of the Business fromthe point of view of the Service Provider.

Business ProcessA Process that is owned and carried out by the Business. ABusiness Process contributes to the delivery of a productor Service to a Business Customer. For example, a retailermay have a purchasing Process that helps to deliverServices to its Business Customers. Many BusinessProcesses rely on IT Services.

Business Relationship Management(Service Strategy) The Process or Function responsible formaintaining a Relationship with the Business. BusinessRelationship Management usually includes:

� Managing personal Relationships with Businessmanagers

� Providing input to Service Portfolio Management

� Ensuring that the IT Service Provider is satisfying theBusiness needs of the Customers.

This Process has strong links with Service LevelManagement.

Business Relationship Manager(Service Strategy) A Role responsible for maintaining theRelationship with one or more Customers. This Role isoften combined with the Service Level Manager Role. Seealso Account Manager.

Business ServiceAn IT Service that directly supports a Business Process, asopposed to an Infrastructure Service, which is usedinternally by the IT Service Provider and is not usuallyvisible to the Business.

The term Business Service is also used to mean a Servicethat is delivered to Business Customers by Business Units.For example, delivery of financial services to Customers ofa bank, or goods to the Customers of a retail store.Successful delivery of Business Services often depends onone or more IT Services.

Business Service Management(Service Strategy) (Service Design) An approach to themanagement of IT Services that considers the BusinessProcesses supported and the Business value provided.

This term also means the management of BusinessServices delivered to Business Customers.

Business Unit(Service Strategy) A segment of the Business that has itsown Plans, Metrics, income and Costs. Each Business Unitowns Assets and uses these to create value for Customersin the form of goods and Services.

182 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 182

Call(Service Operation) A telephone call to the Service Deskfrom a User. A Call could result in an Incident or a ServiceRequest being logged.

Call Centre(Service Operation) An Organization or Business Unit thathandles large numbers of incoming and outgoingtelephone calls. See also Service Desk.

Call Type(Service Operation) A Category that is used to distinguishincoming requests to a Service Desk. Common call typesare Incident, Service Request and Complaint.

Capability(Service Strategy) The ability of an Organization, person,Process, Application, Configuration Item or IT Service tocarry out an Activity. Capabilities are intangible Assets ofan Organization. See also Resource.

Capability Maturity Model(Continual Service Improvement) The Capability MaturityModel for Software (also known as the CMM and SW-CMM) is a model used to identify Best Practices to helpincrease Process Maturity. CMM was developed at theSoftware Engineering Institute (SEI) of Carnegie MellonUniversity, US. In 2000, the SW-CMM was upgraded toCMMI® (Capability Maturity Model Integration). The SEI nolonger maintains the SW-CMM model, its associatedappraisal methods or training materials.

Capability Maturity Model Integration(Continual Service Improvement) Capability MaturityModel® Integration (CMMI) is a process improvementapproach developed by the Software Engineering Institute(SEI) of Carnegie Melon University, US. CMMI provides

organizations with the essential elements of effectiveprocesses. It can be used to guide process improvementacross a project, a division or an entire organization. CMMIhelps integrate traditionally separate organizationalfunctions, set process improvement goals and priorities,provide guidance for quality processes, and provide apoint of reference for appraising current processes. Seewww.sei.cmu.edu/cmmi for more information. See alsoCMM, Maturity.

Capacity(Service Design) The maximum Throughput that aConfiguration Item or IT Service can deliver whilst meetingagreed Service Level Targets. For some types of CI,Capacity may be the size or volume, for example a diskdrive.

Capacity Management(Service Design) The Process responsible for ensuring thatthe Capacity of IT Services and the IT Infrastructure is ableto deliver agreed Service Level Targets in a Cost Effectiveand timely manner. Capacity Management considers allResources required to deliver the IT Service, and plans forshort-, medium- and long-term Business Requirements.

Capacity Management Information System(Service Design) A virtual repository of all CapacityManagement data, usually stored in multiple physicallocations.

Capacity Plan(Service Design) A Capacity Plan is used to manage theResources required to deliver IT Services. The Plan containsscenarios for different predictions of Business demand, andcosted options to deliver the agreed Service Level Targets.

Glossary | 183

7238-TSO-ITIL-13 28/8/07 14:01 Page 183

Capacity Planning(Service Design) The Activity within Capacity Managementresponsible for creating a Capacity Plan.

Capital Expenditure(Service Strategy) The cost of purchasing something thatwill become a financial Asset, for example computerequipment and buildings. The value of the Asset isDepreciated over multiple accounting periods.

Capital Item(Service Strategy) Synonym for an Asset that is of interestto Financial Management because it is above an agreedfinancial value.

Capitalization(Service Strategy) Identifying major Cost as Capital, eventhough no Asset is purchased. This is done to spread theimpact of the Cost over multiple accounting periods. Themost common example of this is software development,or purchase of a software licence.

CategoryA named group of things that have something incommon. Categories are used to group similar thingstogether. For example, Cost Types are used to groupsimilar types of Cost. Incident Categories are used togroup similar types of Incident, CI Types are used to groupsimilar types of Configuration Item.

CertificationIssuing a certificate to confirm Compliance to a Standard.Certification includes a formal Audit by an independentand Accredited body. The term Certification is also used tomean awarding a certificate to verify that a person hasachieved a qualification.

Change(Service Transition) The addition, modification or removalof anything that could have an effect on IT Services. TheScope should include all IT Services, Configuration Items,Processes, Documentation etc.

Change Advisory Board(Service Transition) A group of people that advises theChange Manager in the assessment, prioritization andscheduling of Changes. This board is usually made up ofrepresentatives from all areas within the IT ServiceProvider, representatives from the Business and ThirdParties such as Suppliers.

Change Case(Service Operation) A technique used to predict the impactof proposed Changes. Change Cases use specific scenariosto clarify the scope of proposed Changes and to help withCost Benefit Analysis. See also Use Case.

Change History(Service Transition) Information about all changes made toa Configuration Item during its life. Change Historyconsists of all those Change Records that apply to the CI.

Change Management(Service Transition) The Process responsible for controllingthe Lifecycle of all Changes. The primary objective ofChange Management is to enable beneficial Changes tobe made, with minimum disruption to IT Services.

Change Model(Service Transition) A repeatable way of dealing with aparticular Category of Change. A Change Model definesspecific pre-defined steps that will be followed for achange of this Category. Change Models may be verysimple, with no requirement for approval (e.g. Password

184 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 184

Reset) or may be very complex with many steps thatrequire approval (e.g. major software release). See alsoStandard Change, Change Advisory Board.

Change Record(Service Transition) A Record containing the details of aChange. Each Change Record documents the Lifecycle of asingle Change. A Change Record is created for everyRequest for Change that is received, even those that aresubsequently rejected. Change Records should referencethe Configuration Items that are affected by the Change.Change Records are stored in the ConfigurationManagement System.

Change RequestSee Request for Change.

Change Schedule(Service Transition) A Document that lists all approvedChanges and their planned implementation dates. AChange Schedule is sometimes called a Forward Scheduleof Change, even though it also contains information aboutChanges that have already been implemented.

Change Window(Service Transition) A regular, agreed time when Changesor Releases may be implemented with minimal impact onServices. Change Windows are usually documented inSLAs.

Charging(Service Strategy) Requiring payment for IT Services.Charging for IT Services is optional, and manyOrganizations choose to treat their IT Service Provider as aCost Centre.

Chronological Analysis(Service Operation) A technique used to help identifypossible causes of Problems. All available data about theProblem is collected and sorted by date and time toprovide a detailed timeline. This can make it possible toidentify which Events may have been triggered by others.

CI Type(Service Transition) A Category that is used to Classify CIs.The CI Type identifies the required Attributes andRelationships for a Configuration Record. Common CITypes include: Hardware, Document, User etc.

ClassificationThe act of assigning a Category to something.Classification is used to ensure consistent managementand reporting. CIs, Incidents, Problems, Changes etc. areusually classified.

ClientA generic term that means a Customer, the Business or aBusiness Customer. For example, Client Manager may beused as a synonym for Account Manager.

The term client is also used to mean:

� A computer that is used directly by a User, for examplea PC, handheld computer or workstation

� The part of a client-server application that the Userdirectly interfaces with. For example an e-mail Client.

Closed(Service Operation) The final Status in the Lifecycle of anIncident, Problem, Change etc. When the Status is Closed,no further action is taken.

Glossary | 185

7238-TSO-ITIL-13 28/8/07 14:01 Page 185

Closure(Service Operation) The act of changing the Status of anIncident, Problem, Change, etc. to Closed.

COBIT(Continual Service Improvement) Control Objectives forInformation and related Technology (COBIT) providesguidance and Best Practice for the management of ITProcesses. COBIT is published by the IT GovernanceInstitute. See www.isaca.org for more information.

Code of PracticeA Guideline published by a public body or a StandardsOrganization, such as ISO or BSI. Many Standards consistof a Code of Practice and a Specification. The Code ofPractice describes recommended Best Practice.

Cold StandbySee Gradual Recovery.

Commercial off the Shelf(Service Design) Application software or Middleware thatcan be purchased from a Third Party.

ComplianceEnsuring that a Standard or set of Guidelines is followed,or that proper, consistent accounting or other practicesare being employed.

ComponentA general term that is used to mean one part ofsomething more complex. For example, a computerSystem may be a component of an IT Service; anApplication may be a Component of a Release Unit.Components that need to be managed should beConfiguration Items.

Component Capacity Management(Service Design) (Continual Service Improvement) TheProcess responsible for understanding the Capacity,Utilization and Performance of Configuration Items. Data iscollected, recorded and analysed for use in the CapacityPlan. See also Service Capacity Management.

Component CI(Service Transition) A Configuration Item that is part of anAssembly. For example, a CPU or memory CI may be partof a Server CI.

Component Failure Impact Analysis(Service Design) A technique that helps to identify theimpact of CI failure on IT Services. A matrix is created withIT Services on one edge and CIs on the other. This enablesthe identification of critical CIs (that could cause the failureof multiple IT Services) and of fragile IT Services (that havemultiple Single Points of Failure).

Computer Telephony Integration(Service Operation) Computer Telephony Integration (CTI)is a general term covering any kind of integration betweencomputers and telephone Systems. It is most commonlyused to refer to Systems where an Application displaysdetailed screens relating to incoming or outgoingtelephone calls. See also Automatic Call Distribution,Interactive Voice Response.

ConcurrencyA measure of the number of Users engaged in the sameOperation at the same time.

Confidentiality(Service Design) A security principle that requires that datashould only be accessed by authorized people.

186 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 186

Configuration(Service Transition) A generic term, used to describe agroup of Configuration Items that work together to deliveran IT Service, or a recognizable part of an IT Service.Configuration is also used to describe the parametersettings for one or more CIs.

Configuration Baseline(Service Transition) A Baseline of a Configuration that hasbeen formally agreed and is managed through the ChangeManagement process. A Configuration Baseline is used asa basis for future Builds, Releases and Changes.

Configuration Control(Service Transition) The Activity responsible for ensuringthat adding, modifying or removing a CI is properlymanaged, for example by submitting a Request forChange or Service Request.

Configuration Identification(Service Transition) The Activity responsible for collectinginformation about Configuration Items and theirRelationships, and loading this information into the CMDB.Configuration Identification is also responsible for labellingthe CIs themselves, so that the correspondingConfiguration Records can be found.

Configuration Item(Service Transition) Any Component that needs to bemanaged in order to deliver an IT Service. Informationabout each CI is recorded in a Configuration Record withinthe Configuration Management System and is maintainedthroughout its Lifecycle by Configuration Management. CIsare under the control of Change Management. CIs typicallyinclude IT Services, hardware, software, buildings, peopleand formal documentation such as Process documentationand SLAs.

Configuration Management(Service Transition) The Process responsible for maintaininginformation about Configuration Items required to deliveran IT Service, including their Relationships. Thisinformation is managed throughout the Lifecycle of the CI.Configuration Management is part of an overall ServiceAsset and Configuration Management Process.

Configuration Management Database(Service Transition) A database used to store ConfigurationRecords throughout their Lifecycle. The ConfigurationManagement System maintains one or more CMDBs, andeach CMDB stores Attributes of CIs, and Relationships withother CIs.

Configuration Management System(Service Transition) A set of tools and databases that areused to manage an IT Service Provider’s Configurationdata. The CMS also includes information about Incidents,Problems, Known Errors, Changes and Releases; and maycontain data about employees, Suppliers, locations,Business Units, Customers and Users. The CMS includestools for collecting, storing, managing, updating andpresenting data about all Configuration Items and theirRelationships. The CMS is maintained by ConfigurationManagement and is used by all IT Service ManagementProcesses. See also Configuration Management Database.

Configuration Record(Service Transition) A Record containing the details of aConfiguration Item. Each Configuration Record documentsthe Lifecycle of a single CI. Configuration Records arestored in a Configuration Management Database.

Configuration Structure(Service Transition) The hierarchy and other Relationshipsbetween all the Configuration Items that comprise aConfiguration.

Glossary | 187

7238-TSO-ITIL-13 28/8/07 14:01 Page 187

Continual Service Improvement(Continual Service Improvement) A stage in the Lifecycleof an IT Service and the title of one of the Core ITILpublications. Continual Service Improvement is responsiblefor managing improvements to IT Service ManagementProcesses and IT Services. The Performance of the ITService Provider is continually measured andimprovements are made to Processes, IT Services and ITInfrastructure in order to increase Efficiency, Effectivenessand Cost Effectiveness. See also Plan-Do-Check-Act.

Continuous Availability(Service Design) An approach or design to achieve 100%Availability. A Continuously Available IT Service has noplanned or unplanned Downtime.

Continuous Operation(Service Design) An approach or design to eliminateplanned Downtime of an IT Service. Note that individualConfiguration Items may be down even though the ITService is Available.

ContractA legally binding Agreement between two or more parties.

Contract Portfolio(Service Strategy) A database or structured Document usedto manage Service Contracts or Agreements between an ITService Provider and their Customers. Each IT Servicedelivered to a Customer should have a Contract or otherAgreement that is listed in the Contract Portfolio. SeeService Portfolio, Service Catalogue.

ControlA means of managing a Risk, ensuring that a BusinessObjective is achieved, or ensuring that a Process isfollowed. Example Controls include Policies, Procedures,

Roles, RAID, door locks etc. A Control is sometimes called aCountermeasure or safeguard. Control also means tomanage the utilization or behaviour of a ConfigurationItem, System or IT Service.

Control Objectives for Information andrelated TechnologySee COBIT.

Control Perspective(Service Strategy) An approach to the management of ITServices, Processes, Functions, Assets etc. There can beseveral different Control Perspectives on the same ITService, Process etc., allowing different individuals orteams to focus on what is important and relevant to theirspecific Role. Example Control Perspectives includeReactive and Proactive management within IT Operations,or a Lifecycle view for an Application Project team.

Control ProcessesThe ISO/IEC 20000 Process group that includes ChangeManagement and Configuration Management.

Core Service(Service Strategy) An IT Service that delivers basicOutcomes desired by one or more Customers. See alsoSupporting Service, Core Service Package.

Core Service Package(Service Strategy) A detailed description of a Core Servicethat may be shared by two or more Service LevelPackages. See also Service Package.

CostThe amount of money spent on a specific Activity, ITService or Business Unit. Costs consist of real cost (money),notional cost such as people’s time, and Depreciation.

188 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 188

Cost Benefit AnalysisAn Activity that analyses and compares the costs and thebenefits involved in one or more alternative courses ofaction. See also Business Case, Net Present Value, InternalRate of Return, Return on Investment, Value onInvestment.

Cost Centre(Service Strategy) A Business Unit or Project to which costsare assigned. A Cost Centre does not charge for Servicesprovided. An IT Service Provider can be run as a CostCentre or a Profit Centre.

Cost EffectivenessA measure of the balance between the Effectiveness andCost of a Service, Process or activity. A Cost EffectiveProcess is one that achieves its Objectives at minimumCost. See also KPI, Return on Investment, Value for Money.

Cost Element(Service Strategy) The middle level of category to whichCosts are assigned in Budgeting and Accounting. Thehighest-level category is Cost Type. For example a CostType of ‘people’ could have cost elements of payroll, staffbenefits, expenses, training, overtime etc. Cost Elementscan be further broken down to give Cost Units. Forexample the Cost Element ‘expenses’ could include CostUnits of Hotels, Transport, Meals etc.

Cost Management(Service Strategy) A general term that is used to refer toBudgeting and Accounting, sometimes used as a synonymfor Financial Management.

Cost Type(Service Strategy) The highest level of category to whichCosts are assigned in Budgeting and Accounting. For

example hardware, software, people, accommodation,external and Transfer. See also Cost Element, Cost Unit.

Cost Unit(Service Strategy) The lowest level of category to whichCosts are assigned, Cost Units are usually things that canbe easily counted (e.g. staff numbers, software licences) orthings easily measured (e.g. CPU usage, electricityconsumed). Cost Units are included within Cost Elements.For example a Cost Element of ‘expenses’ could includeCost Units of hotels, transport, meals etc. See also CostType.

CountermeasureCan be used to refer to any type of Control. The termCountermeasure is most often used when referring tomeasures that increase Resilience, Fault Tolerance orReliability of an IT Service.

Course CorrectionsChanges made to a Plan or Activity that has alreadystarted to ensure that it will meet its Objectives. Coursecorrections are made as a result of Monitoring progress.

CRAMMA methodology and tool for analysing and managingRisks. CRAMM was developed by the UK Government, butis now privately owned. See www.cramm.com for furtherinformation.

Crisis Management(IT Service Continuity Management) Crisis Management isthe Process responsible for managing the widerimplications of Business Continuity. A Crisis Managementteam is responsible for Strategic issues such as managingmedia relations and shareholder confidence, and decideswhen to invoke Business Continuity Plans.

Glossary | 189

7238-TSO-ITIL-13 28/8/07 14:01 Page 189

Critical Success FactorSomething that must happen if a Process, Project, Plan orIT Service is to succeed. KPIs are used to measure theachievement of each CSF. For example a CSF of ‘protect ITServices when making Changes’ could be measured byKPIs such as ‘percentage reduction of unsuccessfulChanges’, ‘percentage reduction in Changes causingIncidents’ etc.

CultureA set of values that is shared by a group of people,including expectations about how people should behave,their ideas, beliefs and practices. See also Vision.

CustomerSomeone who buys goods or Services. The Customer of anIT Service Provider is the person or group that defines andagrees the Service Level Targets. The term Customers isalso sometimes informally used to mean Users, forexample ‘this is a Customer-focused Organization’.

Customer Portfolio(Service Strategy) A database or structured Document usedto record all Customers of the IT Service Provider. TheCustomer Portfolio is the Business Relationship Manager’sview of the Customers who receive Services from the ITService Provider. See also Contract Portfolio, ServicePortfolio.

Dashboard(Service Operation) A graphical representation of overall ITService Performance and Availability. Dashboard imagesmay be updated in real-time, and can also be included inmanagement reports and web pages. Dashboards can beused to support Service Level Management, EventManagement or Incident Diagnosis.

Data-to-Information-to-Knowledge-to-WisdomA way of understanding the relationships between data,information, knowledge and wisdom. DIKW shows howeach of these builds on the others.

Definitive Media Library(Service Transition) One or more locations in which thedefinitive and approved versions of all softwareConfiguration Items are securely stored. The DML may alsocontain associated CIs such as licences anddocumentation. The DML is a single logical storage areaeven if there are multiple locations. All software in theDML is under the control of Change and ReleaseManagement and is recorded in the ConfigurationManagement System. Only software from the DML isacceptable for use in a Release.

DeliverableSomething that must be provided to meet a commitmentin a Service Level Agreement or a Contract. Deliverable isalso used in a more informal way to mean a plannedoutput of any Process.

Demand ManagementActivities that understand and influence Customer demandfor Services and the provision of Capacity to meet thesedemands. At a Strategic level Demand Management caninvolve analysis of Patterns of Business Activity and UserProfiles. At a tactical level it can involve use of DifferentialCharging to encourage Customers to use IT Services at lessbusy times. See also Capacity Management.

Deming CycleSee Plan-Do-Check-Act.

190 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 190

DependencyThe direct or indirect reliance of one Process or Activity onanother.

Deployment(Service Transition) The Activity responsible for movementof new or changed hardware, software, documentation,Process etc. to the Live Environment. Deployment is partof the Release and Deployment Management Process. Seealso Rollout.

Depreciation(Service Strategy) A measure of the reduction in value ofan Asset over its life. This is based on wearing out,consumption or other reduction in the useful economicvalue.

Design(Service Design) An Activity or Process that identifiesRequirements and then defines a solution that is able tomeet these Requirements. See also Service Design.

Detection(Service Operation) A stage in the Incident Lifecycle.Detection results in the Incident becoming known to theService Provider. Detection can be automatic, or can bethe result of a user logging an Incident.

Development(Service Design) The Process responsible for creating ormodifying an IT Service or Application. Also used to meanthe Role or group that carries out Development work.

Development Environment(Service Design) An Environment used to create or modifyIT Services or Applications. Development Environments arenot typically subjected to the same degree of control as

Test Environments or Live Environments. See alsoDevelopment.

Diagnosis(Service Operation) A stage in the Incident and ProblemLifecycles. The purpose of Diagnosis is to identify aWorkaround for an Incident or the Root Cause of aProblem.

Diagnostic Script(Service Operation) A structured set of questions used byService Desk staff to ensure they ask the correct questions,and to help them Classify, Resolve and assign Incidents.Diagnostic Scripts may also be made available to Users tohelp them diagnose and resolve their own Incidents.

Differential ChargingA technique used to support Demand Management bycharging different amounts for the same IT ServiceFunction at different times.

Direct Cost(Service Strategy) A cost of providing an IT Service whichcan be allocated in full to a specific Customer, Cost Centre,Project etc. For example, the cost of providing non-sharedservers or software licences. See also Indirect Cost.

Directory Service(Service Operation) An Application that managesinformation about IT Infrastructure available on a network,and corresponding User access Rights.

Do Nothing(Service Design) A Recovery Option. The Service Providerformally agrees with the Customer that Recovery of this ITService will not be performed.

Glossary | 191

7238-TSO-ITIL-13 28/8/07 14:01 Page 191

DocumentInformation in readable form. A Document may be paperor electronic. For example, a Policy statement, ServiceLevel Agreement, Incident Record, diagram of computerroom layout. See also Record.

Downtime(Service Design) (Service Operation) The time when aConfiguration Item or IT Service is not Available during itsAgreed Service Time. The Availability of an IT Service isoften calculated from Agreed Service Time and Downtime.

DriverSomething that influences Strategy, Objectives orRequirements. For example, new legislation or the actionsof competitors.

Early Life Support(Service Transition) Support provided for a new orChanged IT Service for a period of time after it is Released.During Early Life Support the IT Service Provider mayreview the KPIs, Service Levels and Monitoring Thresholds,and provide additional Resources for Incident and ProblemManagement.

Economies of scale(Service Strategy) The reduction in average Cost that ispossible from increasing the usage of an IT Service orAsset. See also Economies of scope.

Economies of scope(Service Strategy) The reduction in Cost that is allocated toan IT Service by using an existing Asset for an additionalpurpose. For example, delivering a new IT Service fromexisting IT Infrastructure. See also Economies of scale.

Effectiveness(Continual Service Improvement) A measure of whetherthe Objectives of a Process, Service or Activity have beenachieved. An Effective Process or activity is one thatachieves its agreed Objectives. See also KPI.

Efficiency(Continual Service Improvement) A measure of whetherthe right amount of resources have been used to deliver aProcess, Service or Activity. An Efficient Process achieves itsObjectives with the minimum amount of time, money,people or other resources. See also KPI.

Emergency Change(Service Transition) A Change that must be introduced assoon as possible. For example, to resolve a Major Incidentor implement a Security patch. The Change ManagementProcess will normally have a specific Procedure forhandling Emergency Changes. See also Emergency ChangeAdvisory Board (ECAB).

Emergency Change Advisory Board(Service Transition) A sub-set of the Change Advisory Boardthat makes decisions about high-impact EmergencyChanges. Membership of the ECAB may be decided at thetime a meeting is called, and depends on the nature ofthe Emergency Change.

Environment(Service Transition) A subset of the IT Infrastructure that isused for a particular purpose. For example: LiveEnvironment, Test Environment, Build Environment. It ispossible for multiple Environments to share aConfiguration Item, for example Test and LiveEnvironments may use different partitions on a singlemainframe computer. Also used in the term PhysicalEnvironment to mean the accommodation, airconditioning, power system etc.

192 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 192

Environment is also used as a generic term to mean theexternal conditions that influence or affect something.

Error(Service Operation) A design flaw or malfunction thatcauses a Failure of one or more Configuration Items or ITServices. A mistake made by a person or a faulty Processthat affects a CI or IT Service is also an Error.

Escalation(Service Operation) An Activity that obtains additionalResources when these are needed to meet Service LevelTargets or Customer expectations. Escalation may beneeded within any IT Service Management Process, but ismost commonly associated with Incident Management,Problem Management and the management of Customercomplaints. There are two types of Escalation, FunctionalEscalation and Hierarchic Escalation.

eSourcing Capability Model for ClientOrganizations(Service Strategy) A framework to help Organizationsguide their analysis and decisions on Service SourcingModels and Strategies. eSCM-CL was developed byCarnegie Mellon University, US. See also eSourcingCapability Model for Service Providers.

eSourcing Capability Model for ServiceProviders(Service Strategy) A framework to help IT Service Providersdevelop their IT Service Management Capabilities from aService Sourcing perspective. eSCM-SP was developed byCarnegie Mellon University, US. See also eSourcingCapability Model for Client Organizations.

EstimationThe use of experience to provide an approximate value fora Metric or Cost. Estimation is also used in Capacity andAvailability Management as the cheapest and leastaccurate Modelling method.

Evaluation(Service Transition) The Process responsible for assessing anew or Changed IT Service to ensure that Risks have beenmanaged and to help determine whether to proceed withthe Change.

Evaluation is also used to mean comparing an actualOutcome with the intended Outcome, or comparing onealternative with another.

Event(Service Operation) A change of state that has significancefor the management of a Configuration Item or IT Service.

The term Event is also used to mean an Alert ornotification created by any IT Service, Configuration Itemor Monitoring tool. Events typically require IT Operationspersonnel to take actions, and often lead to Incidentsbeing logged.

Event Management(Service Operation) The Process responsible for managingEvents throughout their Lifecycle. Event Management isone of the main Activities of IT Operations.

Exception ReportA Document containing details of one or more KPIs orother important targets that have exceeded definedthresholds. Examples include SLA targets being missed orabout to be missed, and a Performance Metric indicating apotential Capacity problem.

Glossary | 193

7238-TSO-ITIL-13 28/8/07 14:01 Page 193

Expanded Incident Lifecycle(Availability Management) Detailed stages in the Lifecycleof an Incident. The stages are Detection, Diagnosis, Repair,Recovery, Restoration. The Expanded Incident Lifecycle isused to help understand all contributions to the Impact ofIncidents and to Plan how these could be controlled orreduced.

External CustomerA Customer who works for a different Business to the ITService Provider. See also External Service Provider, InternalCustomer.

External MetricA Metric that is used to measure the delivery of IT Serviceto a Customer. External Metrics are usually defined in SLAsand reported to Customers. See also Internal Metric.

External Service Provider(Service Strategy) An IT Service Provider that is part of adifferent Organization to its Customer. An IT ServiceProvider may have both Internal Customers and ExternalCustomers. See also Type III Service Provider.

External SourcingSee Outsourcing.

Facilities Management(Service Operation) The Function responsible for managingthe physical Environment where the IT Infrastructure islocated. Facilities Management includes all aspects ofmanaging the physical Environment, for example powerand cooling, building Access Management, andenvironmental Monitoring.

Failure(Service Operation) Loss of ability to Operate toSpecification, or to deliver the required output. The termFailure may be used when referring to IT Services,Processes, Activities, Configuration Items etc. A Failureoften causes an Incident.

Failure Modes and Effects AnalysisAn approach to assessing the potential Impact of Failures.FMEA involves analysing what would happen after Failureof each Configuration Item, all the way up to the effect onthe Business. FMEA is often used in Information SecurityManagement and in IT Service Continuity Planning.

Fast Recovery(Service Design) A Recovery Option that is also known asHot Standby. Provision is made to Recover the IT Servicein a short period of time: typically less than 24 hours.Immediate Recovery typically uses a dedicated FixedFacility with computer Systems, and software configuredready to run the IT Services. Immediate Recovery may takeup to 24 hours if there is a need to Restore data fromBackups.

FaultSee Error.

Fault Tolerance(Service Design) The ability of an IT Service orConfiguration Item to continue to Operate correctly afterFailure of a Component part. See also Resilience,Countermeasure.

Fault Tree Analysis(Service Design) (Continual Service Improvement) Atechnique that can be used to determine the chain ofevents that leads to a Problem. Fault Tree Analysis

194 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 194

represents a chain of events using Boolean notation in adiagram.

Financial Management(Service Strategy) The Function and Processes responsiblefor managing an IT Service Provider’s Budgeting,Accounting and Charging Requirements.

First-line Support(Service Operation) The first level in a hierarchy of SupportGroups involved in the resolution of Incidents. Each levelcontains more specialist skills, or has more time or otherresources. See also Escalation.

Fishbone DiagramSee Ishikawa Diagram.

Fit for PurposeAn informal term used to describe a Process, ConfigurationItem, IT Service etc. that is capable of meeting itsobjectives or Service Levels. Being Fit for Purpose requiressuitable design, implementation, control and maintenance.

Fixed Cost(Service Strategy) A Cost that does not vary with IT Serviceusage. For example the cost of Server hardware. See alsoVariable Cost.

Fixed Facility(Service Design) A permanent building, available for usewhen needed by an IT Service Continuity Plan. See alsoRecovery Option, Portable Facility.

Follow the Sun(Service Operation) A methodology for using Service Desksand Support Groups around the world to provide seamless24/7 Service. Calls, Incidents, Problems and Service

Requests are passed between groups in different timezones.

FulfilmentPerforming Activities to meet a need or Requirement. Forexample, by providing a new IT Service, or meeting aService Request.

FunctionA team or group of people and the tools they use to carryout one or more Processes or Activities. For example theService Desk.

The term Function also has two other meanings:

� An intended purpose of a Configuration Item, Person,Team, Process or IT Service. For example one Functionof an e-mail Service may be to store and forwardoutgoing mails, one Function of a Business Processmay be to dispatch goods to Customers

� To perform the intended purpose correctly, ‘Thecomputer is Functioning’.

Functional Escalation(Service Operation) Transferring an Incident, Problem orChange to a technical team with a higher level ofexpertise to assist in an Escalation.

Gap Analysis(Continual Service Improvement) An Activity that comparestwo sets of data and identifies the differences. GapAnalysis is commonly used to compare a set ofRequirements with actual delivery. See also Benchmarking.

GovernanceEnsuring that Policies and Strategy are actuallyimplemented, and that required Processes are correctlyfollowed. Governance includes defining Roles and

Glossary | 195

7238-TSO-ITIL-13 28/8/07 14:01 Page 195

responsibilities, measuring and reporting, and takingactions to resolve any issues identified.

Gradual Recovery(IT Service Continuity Management) A Recovery Optionthat is also known as Cold Standby. Provision is made toRecover the IT Service in a period of time greater than 72hours. Gradual Recovery typically uses a Portable or FixedFacility that has environmental support and networkcabling, but no computer Systems. The hardware andsoftware are installed as part of the IT Service ContinuityPlan.

GuidelineA Document describing Best Practice, which recommendswhat should be done. Compliance with a Guideline is notnormally enforced. See also Standard.

Help Desk(Service Operation) A point of contact for Users to logIncidents. A Help Desk is usually more technically focussedthan a Service Desk and does not provide a Single Point ofContact for all interaction. The term Help Desk is oftenused as a synonym for Service Desk.

Hierarchic Escalation(Service Operation) Informing or involving more seniorlevels of management to assist in an Escalation.

High Availability(Service Design) An approach or design that minimizes orhides the effects of Configuration Item Failure on the usersof an IT Service. High Availability solutions are designed toachieve an agreed level of Availability and make use oftechniques such as Fault Tolerance, Resilience and FastRecovery to reduce the number of Incidents, and theImpact of Incidents.

Hot StandbySee Fast Recovery or Immediate Recovery.

Identity(Service Operation) A unique name that is used to identifya User, person or Role. The Identity is used to grant Rightsto that User, person or Roles. Example Identities might bethe username SmithJ or the Role ‘Change manager’.

Immediate Recovery(Service Design) A Recovery Option that is also known asHot Standby. Provision is made to Recover the IT Servicewith no loss of Service. Immediate Recovery typically usesMirroring, Load Balancing and Split Site technologies.

Impact(Service Operation) (Service Transition) A measure of theeffect of an Incident, Problem or Change on BusinessProcesses. Impact is often based on how Service Levelswill be affected. Impact and Urgency are used to assignPriority.

Incident(Service Operation) An unplanned interruption to an ITService or reduction in the Quality of an IT Service. Failureof a Configuration Item that has not yet affected Service isalso an Incident. For example Failure of one disk from amirror set.

Incident Management(Service Operation) The Process responsible for managingthe Lifecycle of all Incidents. The primary Objective ofIncident Management is to return the IT Service toCustomers as quickly as possible.

196 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 196

Incident Record(Service Operation) A Record containing the details of anIncident. Each Incident record documents the Lifecycle ofa single Incident.

Indirect Cost(Service Strategy) A Cost of providing an IT Service, whichcannot be allocated in full to a specific Customer. Forexample, the Cost of providing shared Servers or softwarelicences. Also known as Overhead. See also Direct Cost.

Information Security Management(Service Design) The Process that ensures theConfidentiality, Integrity and Availability of anOrganization’s Assets, information, data and IT Services.Information Security Management usually forms part of anOrganizational approach to Security Management that hasa wider scope than the IT Service Provider, and includeshandling of paper, building access, phone calls etc. for theentire Organization.

Information Security Management System(Service Design) The framework of Policy, Processes,Standards, Guidelines and tools that ensures anOrganization can achieve its Information SecurityManagement Objectives.

Information Security Policy(Service Design) The Policy that governs the Organization’sapproach to Information Security Management.

Information TechnologyThe use of technology for the storage, communication orprocessing of information. The technology typicallyincludes computers, telecommunications, Applications andother software. The information may include Business data,

voice, images, video etc. Information Technology is oftenused to support Business Processes through IT Services.

Infrastructure ServiceAn IT Service that is not directly used by the Business, butis required by the IT Service Provider so they can provideother IT Services. For example directory services, namingservices or communication services.

InsourcingSee Internal Sourcing.

Integrity(Service Design) A security principle that ensures data andConfiguration Items are modified only by authorizedpersonnel and Activities. Integrity considers all possiblecauses of modification, including software and hardwareFailure, environmental Events and human intervention.

Interactive Voice Response(Service Operation) A form of Automatic Call Distributionthat accepts User input, such as key presses and spokencommands, to identify the correct destination forincoming Calls.

Intermediate Recovery(Service Design) A Recovery Option that is also known asWarm Standby. Provision is made to Recover the IT Servicein a period of time between 24 and 72 hours.Intermediate Recovery typically uses a shared Portable orFixed Facility that has Computer Systems and NetworkComponents. The hardware and software will need to beconfigured, and data will need to be restored, as part ofthe IT Service Continuity Plan.

Glossary | 197

7238-TSO-ITIL-13 28/8/07 14:01 Page 197

Internal CustomerA Customer who works for the same Business as the ITService Provider. See also Internal Service Provider, ExternalCustomer.

Internal MetricA Metric that is used within the IT Service Provider toMonitor the Efficiency, Effectiveness or Cost Effectivenessof the IT Service Provider’s internal Processes. InternalMetrics are not normally reported to the Customer of theIT Service. See also External Metric.

Internal Rate of Return(Service Strategy) A technique used to help makedecisions about Capital Expenditure. IRR calculates a figurethat allows two or more alternative investments to becompared. A larger IRR indicates a better investment. Seealso Net Present Value, Return on Investment.

Internal Service Provider(Service Strategy) An IT Service Provider that is part of thesame Organization as its Customer. An IT Service Providermay have both Internal Customers and ExternalCustomers. See also Type I Service Provider, Type II ServiceProvider.

Internal Sourcing(Service Strategy) Using an Internal Service Provider tomanage IT Services. See also Service Sourcing, Type IService Provider, Type II Service Provider.

International Organization forStandardizationThe International Organization for Standardization (ISO) isthe world’s largest developer of Standards. ISO is a non-governmental organization that is a network of the

national standards institutes of 156 countries. Seewww.iso.org for further information about ISO.

International Standards OrganizationSee International Organization for Standardization (ISO).

Internet Service ProviderAn External Service Provider that provides access to theInternet. Most ISPs also provide other IT Services such asweb hosting.

Invocation(Service Design) Initiation of the steps defined in a plan.For example initiating the IT Service Continuity Plan forone or more IT Services.

Ishikawa Diagram(Service Operation) (Continual Service Improvement) Atechnique that helps a team to identify all the possiblecauses of a Problem. Originally devised by Kaoru Ishikawa,the output of this technique is a diagram that looks like afishbone.

ISO 9000A generic term that refers to a number of internationalStandards and Guidelines for Quality ManagementSystems. See www.iso.org for more information. See alsoISO.

ISO 9001An international Standard for Quality ManagementSystems. See also ISO 9000, Standard.

ISO/IEC 17799(Continual Service Improvement) ISO Code of Practice forInformation Security Management. See also Standard.

198 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 198

ISO/IEC 20000ISO Specification and Code of Practice for IT ServiceManagement. ISO/IEC 20000 is aligned with ITIL BestPractice.

ISO/IEC 27001(Service Design) (Continual Service Improvement) ISOSpecification for Information Security Management. Thecorresponding Code of Practice is ISO/IEC 17799. See alsoStandard.

IT Directorate(Continual Service Improvement) Senior Managementwithin a Service Provider, charged with developing anddelivering IT services. Most commonly used in UKGovernment departments.

IT InfrastructureAll of the hardware, software, networks, facilities, etc. thatare required to develop, Test, deliver, Monitor, Control orsupport IT Services. The term IT Infrastructure includes allof the Information Technology but not the associatedpeople, Processes and documentation.

IT Operations(Service Operation) Activities carried out by IT OperationsControl, including Console Management, Job Scheduling,Backup and Restore, and Print and Output Management. ITOperations is also used as a synonym for ServiceOperation.

IT Operations Control(Service Operation) The Function responsible forMonitoring and Control of the IT Services and ITInfrastructure. See also Operations Bridge.

IT Operations Management(Service Operation) The Function within an IT ServiceProvider that performs the daily Activities needed tomanage IT Services and the supporting IT Infrastructure. ITOperations Management includes IT Operations Controland Facilities Management.

IT ServiceA Service provided to one or more Customers by an ITService Provider. An IT Service is based on the use ofInformation Technology and supports the Customer’sBusiness Processes. An IT Service is made up from acombination of people, Processes and technology andshould be defined in a Service Level Agreement.

IT Service Continuity Management(Service Design) The Process responsible for managingRisks that could seriously affect IT Services. ITSCM ensuresthat the IT Service Provider can always provide minimumagreed Service Levels, by reducing the Risk to anacceptable level and Planning for the Recovery of ITServices. ITSCM should be designed to support BusinessContinuity Management.

IT Service Continuity Plan(Service Design) A Plan defining the steps required toRecover one or more IT Services. The Plan will also identifythe triggers for Invocation, people to be involved,communications etc. The IT Service Continuity Plan shouldbe part of a Business Continuity Plan.

IT Service ManagementThe implementation and management of Quality ITServices that meet the needs of the Business. IT ServiceManagement is performed by IT Service Providers throughan appropriate mix of people, Process and InformationTechnology. See also Service Management.

Glossary | 199

7238-TSO-ITIL-13 28/8/07 14:01 Page 199

IT Service Management ForumThe IT Service Management Forum is an independentOrganization dedicated to promoting a professionalapproach to IT Service Management. The itSMF is a not-for-profit membership Organization with representation inmany countries around the world (itSMF Chapters). TheitSMF and its membership contribute to the developmentof ITIL and associated IT Service Management Standards.See www.itsmf.com for more information.

IT Service Provider(Service Strategy) A Service Provider that provides ITServices to Internal Customers or External Customers.

IT Steering GroupA formal group that is responsible for ensuring thatBusiness and IT Service Provider Strategies and Plans areclosely aligned. An IT Steering Group includes seniorrepresentatives from the Business and the IT ServiceProvider.

ITILA set of Best Practice guidance for IT Service Management.ITIL is owned by the OGC and consists of a series ofpublications giving guidance on the provision of Quality ITServices, and on the Processes and facilities needed tosupport them. See www.itil.co.uk for more information.

Job DescriptionA Document that defines the Roles, responsibilities, skillsand knowledge required by a particular person. One JobDescription can include multiple Roles, for example theRoles of Configuration Manager and Change Manager maybe carried out by one person.

Job Scheduling(Service Operation) Planning and managing the executionof software tasks that are required as part of an IT Service.Job Scheduling is carried out by IT OperationsManagement, and is often automated using software toolsthat run batch or online tasks at specific times of the day,week, month or year.

Kano Model(Service Strategy) A Model developed by Noriaki Kano thatis used to help understand Customer preferences. TheKano Model considers Attributes of an IT Service groupedinto areas such as Basic Factors, Excitement Factors,Performance Factors, etc.

Kepner & Tregoe Analysis(Service Operation) (Continual Service Improvement) Astructured approach to Problem solving. The Problem isanalysed in terms of what, where, when and extent.Possible causes are identified. The most probable cause istested. The true cause is verified.

Key Performance Indicator(Service Design) (Continual Service Improvement) A Metricthat is used to help manage a Process, IT Service orActivity. Many Metrics may be measured, but only themost important of these are defined as KPIs and used toactively manage and report on the Process, IT Service orActivity. KPIs should be selected to ensure that Efficiency,Effectiveness and Cost Effectiveness are all managed. Seealso Critical Success Factor.

Knowledge Base(Service Transition) A logical database containing the dataused by the Service Knowledge Management System.

200 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 200

Knowledge Management(Service Transition) The Process responsible for gathering,analysing, storing and sharing knowledge and informationwithin an Organization. The primary purpose ofKnowledge Management is to improve Efficiency byreducing the need to rediscover knowledge. See also Data-to-Information-to-Knowledge-to-Wisdom.

Known Error(Service Operation) A Problem that has a documentedRoot Cause and a Workaround. Known Errors are createdand managed throughout their Lifecycle by ProblemManagement. Known Errors may also be identified byDevelopment or Suppliers.

Known Error Database(Service Operation) A database containing all Known ErrorRecords. This database is created by Problem Managementand used by Incident and Problem Management. TheKnown Error Database is part of the Service KnowledgeManagement System.

Known Error Record(Service Operation) A Record containing the details of aKnown Error. Each Known Error Record documents theLifecycle of a Known Error, including the Status, RootCause and Workaround. In some implementations aKnown Error is documented using additional fields in aProblem Record.

LifecycleThe various stages in the life of an IT Service,Configuration Item, Incident, Problem, Change etc. TheLifecycle defines the Categories for Status and the Statustransitions that are permitted. For example:

� The Lifecycle of an Application includes Requirements,Design, Build, Deploy, Operate, Optimize

� The Expanded Incident Lifecycle includes Detect,Respond, Diagnose, Repair, Recover, Restore

� The Lifecycle of a Server may include: Ordered,Received, In Test, Live, Disposed etc.

Line of Service(Service Strategy) A Core Service or Supporting Servicethat has multiple Service Level Packages. A line of Serviceis managed by a Product Manager and each Service LevelPackage is designed to support a particular marketsegment.

Live(Service Transition) Refers to an IT Service or ConfigurationItem that is being used to deliver Service to a Customer.

Live Environment(Service Transition) A controlled Environment containingLive Configuration Items used to deliver IT Services toCustomers.

Maintainability(Service Design) A measure of how quickly and Effectivelya Configuration Item or IT Service can be restored tonormal working after a Failure. Maintainability is oftenmeasured and reported as MTRS.

Maintainability is also used in the context of Software or ITService Development to mean ability to be Changed orRepaired easily.

Major Incident(Service Operation) The highest Category of Impact for anIncident. A Major Incident results in significant disruptionto the Business.

Glossary | 201

7238-TSO-ITIL-13 28/8/07 14:01 Page 201

Managed Services(Service Strategy) A perspective on IT Services thatemphasizes the fact that they are managed. The termManaged Services is also used as a synonym forOutsourced IT Services.

Management InformationInformation that is used to support decision-making bymanagers. Management Information is often generatedautomatically by tools supporting the various IT ServiceManagement Processes. Management Information oftenincludes the values of KPIs such as ‘Percentage of Changesleading to Incidents’, or ‘first-time fix rate’.

Management of RiskThe OGC methodology for managing Risks. M_o_Rincludes all the Activities required to identify and Controlthe exposure to Risk, which may have an impact on theachievement of an Organization’s Business Objectives. Seewww.m-o-r.org for more details.

Management SystemThe framework of Policy, Processes and Functions thatensures an Organization can achieve its Objectives.

Manual WorkaroundA Workaround that requires manual intervention. ManualWorkaround is also used as the name of a RecoveryOption in which The Business Process Operates withoutthe use of IT Services. This is a temporary measure and isusually combined with another Recovery Option.

Marginal Cost(Service Strategy) The Cost of continuing to provide the ITService. Marginal Cost does not include investment alreadymade, for example the cost of developing new softwareand delivering training.

Market Space(Service Strategy) All opportunities that an IT Service Providercould exploit to meet business needs of Customers. TheMarket Space identifies the possible IT Services that an ITService Provider may wish to consider delivering.

Maturity(Continual Service Improvement) A measure of theReliability, Efficiency and Effectiveness of a Process,Function, Organization etc. The most mature Processesand Functions are formally aligned to Business Objectivesand Strategy, and are supported by a framework forcontinual improvement.

Maturity LevelA named level in a Maturity model such as the CarnegieMellon Capability Maturity Model Integration.

Mean Time Between Failures(Service Design) A Metric for measuring and reportingReliability. MTBF is the average time that a ConfigurationItem or IT Service can perform its agreed Function withoutinterruption. This is measured from when the CI or ITService starts working, until it next fails.

Mean Time Between Service Incidents(Service Design) A Metric used for measuring andreporting Reliability. MTBSI is the mean time from when aSystem or IT Service fails, until it next fails. MTBSI is equalto MTBF + MTRS.

Mean Time To RepairThe average time taken to repair a Configuration Item or ITService after a Failure. MTTR is measured from when the CIor IT Service fails until it is repaired. MTTR does not includethe time required to Recover or Restore. MTTR is sometimesincorrectly used to mean Mean Time to Restore Service.

202 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 202

Mean Time to Restore ServiceThe average time taken to restore a Configuration Item orIT Service after a Failure. MTRS is measured from when theCI or IT Service fails until it is fully restored and deliveringits normal functionality. See also Maintainability, MeanTime to Repair.

Metric(Continual Service Improvement) Something that ismeasured and reported to help manage a Process, ITService or Activity. See also KPI.

Middleware(Service Design) Software that connects two or moresoftware Components or Applications. Middleware isusually purchased from a Supplier, rather than developedwithin the IT Service Provider. See also Off the Shelf.

Mission StatementThe Mission Statement of an Organization is a short butcomplete description of the overall purpose and intentionsof that Organization. It states what is to be achieved, butnot how this should be done.

ModelA representation of a System, Process, IT Service,Configuration Item etc. that is used to help understand orpredict future behaviour.

ModellingA technique that is used to predict the future behaviour ofa System, Process, IT Service, Configuration Item etc.Modelling is commonly used in Financial Management,Capacity Management and Availability Management.

Monitor Control Loop(Service Operation) Monitoring the output of a Task,Process, IT Service or Configuration Item; comparing thisoutput to a predefined Norm; and taking appropriateaction based on this comparison.

Monitoring(Service Operation) Repeated observation of aConfiguration Item, IT Service or Process to detect Eventsand to ensure that the current status is known.

Near-Shore(Service Strategy) Provision of Services from a country nearthe country where the Customer is based. This can be theprovision of an IT Service, or of supporting Functions suchas Service Desk. See also On-shore, Off-shore.

Net Present Value(Service Strategy) A technique used to help makedecisions about Capital Expenditure. NPV compares cashinflows with cash outflows. Positive NPV indicates that aninvestment is worthwhile. See also Internal Rate of Return,Return on Investment.

Notional Charging(Service Strategy) An approach to Charging for IT Services.Charges to Customers are calculated and Customers areinformed of the charge, but no money is actuallytransferred. Notional Charging is sometimes introduced toensure that Customers are aware of the Costs they incur,or as a stage during the introduction of real Charging.

ObjectiveThe defined purpose or aim of a Process, an Activity or anOrganization as a whole. Objectives are usually expressedas measurable targets. The term Objective is also

Glossary | 203

7238-TSO-ITIL-13 28/8/07 14:01 Page 203

informally used to mean a Requirement. See alsoOutcome.

Off the ShelfSee Commercial Off the Shelf.

Office of Government CommerceOGC owns the ITIL brand (copyright and trademark). OGCis a UK Government department that supports the deliveryof the government’s procurement agenda through itswork in collaborative procurement and in raising levels ofprocurement skills and capability with departments. It alsoprovides support for complex public sector projects.

Office of Public Sector InformationOPSI licenses the Crown Copyright material used in theITIL publications. OPSI is a UK Government departmentthat provides online access to UK legislation, licenses there-use of Crown Copyright material, manages theInformation Fair Trader Scheme, maintains theGovernment’s Information Asset Register and providesadvice and guidance on official publishing and CrownCopyright.

Off-shore(Service Strategy) Provision of Services from a locationoutside the country where the Customer is based, often ina different continent. This can be the provision of an ITService, or of supporting Functions such as Service Desk.See also On-shore, Near-shore.

On-shore(Service Strategy) Provision of Services from a locationwithin the country where the Customer is based. See alsoOff-shore, Near-shore.

OperateTo perform as expected. A Process or Configuration Item issaid to Operate if it is delivering the Required outputs.Operate also means to perform one or more Operations.For example, to Operate a computer is to do the day-to-day Operations needed for it to perform as expected.

Operation(Service Operation) Day-to-day management of an ITService, System, or other Configuration Item. Operation isalso used to mean any pre-defined Activity or Transaction.For example loading a magnetic tape, accepting money ata point of sale, or reading data from a disk drive.

OperationalThe lowest of three levels of Planning and delivery(Strategic, Tactical, Operational). Operational Activitiesinclude the day-to-day or short-term Planning or deliveryof a Business Process or IT Service Management Process.The term Operational is also a synonym for Live.

Operational CostCost resulting from running the IT Services. Oftenrepeating payments. For example staff costs, hardwaremaintenance and electricity (also known as ‘currentexpenditure’ or ‘revenue expenditure’). See also CapitalExpenditure.

Operational ExpenditureSee Operational Cost.

Operational Level Agreement(Service Design) (Continual Service Improvement) AnAgreement between an IT Service Provider and anotherpart of the same Organization. An OLA supports the ITService Provider’s delivery of IT Services to Customers. TheOLA defines the goods or Services to be provided and the

204 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 204

responsibilities of both parties. For example there could bean OLA:

� Between the IT Service Provider and a procurementdepartment to obtain hardware in agreed times

� Between the Service Desk and a Support Group toprovide Incident Resolution in agreed times.

See also Service Level Agreement.

Operations Bridge(Service Operation) A physical location where IT Servicesand IT Infrastructure are monitored and managed.

Operations ControlSee IT Operations Control.

Operations ManagementSee IT Operations Management.

Opportunity Cost(Service Strategy) A Cost that is used in deciding betweeninvestment choices. Opportunity Cost represents therevenue that would have been generated by using theResources in a different way. For example the OpportunityCost of purchasing a new Server may include not carryingout a Service Improvement activity that the money couldhave been spent on. Opportunity cost analysis is used aspart of decision-making processes, but is not treated as anactual Cost in any financial statement.

OptimizeReview, Plan and request Changes, in order to obtain themaximum Efficiency and Effectiveness from a Process,Configuration Item, Application etc.

OrganizationA company, legal entity or other institution. Examples ofOrganizations that are not companies include International

Standards Organization or itSMF. The term Organization issometimes used to refer to any entity that has People,Resources and Budgets. For example a Project or BusinessUnit.

OutcomeThe result of carrying out an Activity; following a Process;delivering an IT Service etc. The term Outcome is used torefer to intended results, as well as to actual results. Seealso Objective.

Outsourcing(Service Strategy) Using an External Service Provider tomanage IT Services. See also Service Sourcing, Type IIIService Provider.

OverheadSee Indirect cost

Pain Value Analysis(Service Operation) A technique used to help identify theBusiness Impact of one or more Problems. A formula isused to calculate Pain Value based on the number ofUsers affected, the duration of the Downtime, the Impacton each User, and the cost to the Business (if known).

Pareto Principle(Service Operation) A technique used to prioritizeActivities. The Pareto Principle says that 80% of the valueof any activity is created with 20% of the effort. ParetoAnalysis is also used in Problem Management to prioritizepossible Problem causes for investigation.

PartnershipA relationship between two Organizations that involvesworking closely together for common goals or mutualbenefit. The IT Service Provider should have a Partnership

Glossary | 205

7238-TSO-ITIL-13 28/8/07 14:01 Page 205

with the Business, and with Third Parties who are criticalto the delivery of IT Services. See also Value Network.

Passive Monitoring(Service Operation) Monitoring of a Configuration Item, anIT Service or a Process that relies on an Alert or notificationto discover the current status. See also Active Monitoring.

Pattern of Business Activity(Service Strategy) A Workload profile of one or moreBusiness Activities. Patterns of Business Activity are used tohelp the IT Service Provider understand and plan fordifferent levels of Business Activity. See also User Profile.

Percentage utilization(Service Design) The amount of time that a Component isbusy over a given period of time. For example, if a CPU isbusy for 1,800 seconds in a one-hour period, its utilizationis 50%.

PerformanceA measure of what is achieved or delivered by a System,person, team, Process or IT Service.

Performance Anatomy(Service Strategy) An approach to Organizational Culturethat integrates, and actively manages, leadership andstrategy, people development, technology enablement,performance management and innovation.

Performance Management(Continual Service Improvement) The Process responsiblefor day-to-day Capacity Management Activities. Theseinclude monitoring, threshold detection, Performanceanalysis and Tuning, and implementing changes related toPerformance and Capacity.

Pilot(Service Transition) A limited Deployment of an IT Service,a Release or a Process to the Live Environment. A pilot isused to reduce Risk and to gain User feedback andAcceptance. See also Test, Evaluation.

PlanA detailed proposal that describes the Activities andResources needed to achieve an Objective. For example aPlan to implement a new IT Service or Process. ISO/IEC20000 requires a Plan for the management of each ITService Management Process.

Plan-Do-Check-Act(Continual Service Improvement) A four-stage cycle forProcess management, attributed to Edward Deming. Plan-Do-Check-Act is also called the Deming Cycle.

PLAN: Design or revise Processes that support the ITServices.

DO: Implement the Plan and manage the Processes.

CHECK: Measure the Processes and IT Services, comparewith Objectives and produce reports.

ACT: Plan and implement Changes to improve theProcesses.

Planned Downtime(Service Design) Agreed time when an IT Service will notbe available. Planned Downtime is often used formaintenance, upgrades and testing. See also ChangeWindow, Downtime.

PlanningAn Activity responsible for creating one or more Plans. Forexample, Capacity Planning.

206 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 206

PMBOKA Project management Standard maintained andpublished by the Project Management Institute. PMBOKstands for Project Management Body of Knowledge. Seewww.pmi.org for more information. See also PRINCE2.

PolicyFormally documented management expectations andintentions. Policies are used to direct decisions, and toensure consistent and appropriate development andimplementation of Processes, Standards, Roles, Activities, ITInfrastructure etc.

Portable Facility(Service Design) A prefabricated building, or a largevehicle, provided by a Third Party and moved to a sitewhen needed by an IT Service Continuity Plan. See alsoRecovery Option, Fixed Facility.

Post-Implementation ReviewA Review that takes place after a Change or a Project hasbeen implemented. A PIR determines if the Change orProject was successful, and identifies opportunities forimprovement.

PracticeA way of working, or a way in which work must be done.Practices can include Activities, Processes, Functions,Standards and Guidelines. See also Best Practice.

Prerequisite for SuccessAn Activity that needs to be completed, or a conditionthat needs to be met, to enable successful implementationof a Plan or Process. A PFS is often an output from oneProcess that is a required input to another Process.

Pricing(Service Strategy) Pricing is the Activity for establishinghow much Customers will be Charged.

PRINCE2The standard UK government methodology for Projectmanagement. See www.ogc.gov.uk/prince2 for moreinformation. See also PMBOK.

Priority(Service Transition) (Service Operation) A Category used toidentify the relative importance of an Incident, Problem orChange. Priority is based on Impact and Urgency, and isused to identify required times for actions to be taken. Forexample the SLA may state that Priority 2 Incidents mustbe resolved within 12 hours.

Proactive Monitoring(Service Operation) Monitoring that looks for patterns ofEvents to predict possible future Failures. See also ReactiveMonitoring.

Proactive Problem Management(Service Operation) Part of the Problem ManagementProcess. The Objective of Proactive Problem Managementis to identify Problems that might otherwise be missed.Proactive Problem Management analyses Incident Records,and uses data collected by other IT Service ManagementProcesses to identify trends or significant problems.

Problem(Service Operation) A cause of one or more Incidents. Thecause is not usually known at the time a Problem Recordis created, and the Problem Management Process isresponsible for further investigation.

Glossary | 207

7238-TSO-ITIL-13 28/8/07 14:01 Page 207

Problem Management(Service Operation) The Process responsible for managingthe Lifecycle of all Problems. The primary objectives ofProblem Management are to prevent Incidents fromhappening, and to minimize the Impact of Incidents thatcannot be prevented.

Problem Record(Service Operation) A Record containing the details of aProblem. Each Problem Record documents the Lifecycle ofa single Problem.

ProcedureA Document containing steps that specify how to achievean Activity. Procedures are defined as part of Processes.See also Work Instruction.

ProcessA structured set of Activities designed to accomplish aspecific Objective. A Process takes one or more definedinputs and turns them into defined outputs. A Processmay include any of the Roles, responsibilities, tools andmanagement Controls required to reliably deliver theoutputs. A Process may define Policies, Standards,Guidelines, Activities and Work Instructions if they areneeded.

Process ControlThe Activity of planning and regulating a Process, with theObjective of performing the Process in an Effective,Efficient and consistent manner.

Process ManagerA Role responsible for Operational management of aProcess. The Process Manager’s responsibilities includePlanning and coordination of all Activities required to carryout, monitor and report on the Process. There may be

several Process Managers for one Process, for exampleregional Change Managers or IT Service ContinuityManagers for each data centre. The Process Manager Roleis often assigned to the person who carries out theProcess Owner Role, but the two Roles may be separate inlarger Organizations.

Process OwnerA Role responsible for ensuring that a Process is Fit forPurpose. The Process Owner’s responsibilities includesponsorship, Design, Change Management and continualimprovement of the Process and its Metrics. This Role isoften assigned to the same person who carries out theProcess Manager Role, but the two Roles may be separatein larger Organizations.

Production EnvironmentSee Live Environment.

Profit Centre(Service Strategy) A Business Unit that charges for Servicesprovided. A Profit Centre can be created with the objectiveof making a profit, recovering Costs, or running at a loss.An IT Service Provider can be run as a Cost Centre or aProfit Centre.

Pro-formaA template, or example Document containing exampledata that will be replaced with the real values when theseare available.

ProgrammeA number of Projects and Activities that are planned andmanaged together to achieve an overall set of relatedObjectives and other Outcomes.

208 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 208

ProjectA temporary Organization, with people and other Assetsrequired to achieve an Objective or other Outcome. EachProject has a Lifecycle that typically includes initiation,Planning, execution, Closure etc. Projects are usuallymanaged using a formal methodology such as PRINCE2.

Projected Service Outage(Service Transition) A Document that identifies the effect ofplanned Changes, maintenance Activities and Test Planson agreed Service Levels.

PRojects IN Controlled EnvironmentsSee PRINCE2

Qualification(Service Transition) An Activity that ensures that ITInfrastructure is appropriate, and correctly configured, tosupport an Application or IT Service. See also Validation.

QualityThe ability of a product, Service, or Process to provide theintended value. For example, a hardware Component canbe considered to be of high Quality if it performs asexpected and delivers the required Reliability. ProcessQuality also requires an ability to monitor Effectivenessand Efficiency, and to improve them if necessary. See alsoQuality Management System.

Quality Assurance(Service Transition) The Process responsible for ensuringthat the Quality of a product, Service or Process willprovide its intended Value.

Quality Management System(Continual Service Improvement) The set of Processesresponsible for ensuring that all work carried out by an

Organization is of a suitable Quality to reliably meetBusiness Objectives or Service Levels. See also ISO 9000.

Quick Win(Continual Service Improvement) An improvement Activitythat is expected to provide a Return on Investment in ashort period of time with relatively small Cost and effort.See also Pareto Principle.

RACI(Service Design) (Continual Service Improvement) A Modelused to help define Roles and Responsibilities. RACI standsfor Responsible, Accountable, Consulted and Informed.

Reactive Monitoring(Service Operation) Monitoring that takes action inresponse to an Event. For example submitting a batch jobwhen the previous job completes, or logging an Incidentwhen an Error occurs. See also Proactive Monitoring.

Reciprocal Arrangement(Service Design) A Recovery Option. An agreementbetween two Organizations to share resources in anemergency. For example, Computer Room space or use ofa mainframe.

RecordA Document containing the results or other output from aProcess or Activity. Records are evidence of the fact thatan activity took place and may be paper or electronic. Forexample, an Audit report, an Incident Record, or theminutes of a meeting.

Recovery(Service Design) (Service Operation) Returning aConfiguration Item or an IT Service to a working state.Recovery of an IT Service often includes recovering data toa known consistent state. After Recovery, further steps may

Glossary | 209

7238-TSO-ITIL-13 28/8/07 14:01 Page 209

be needed before the IT Service can be made available tothe Users (Restoration).

Recovery Option(Service Design) A Strategy for responding to aninterruption to Service. Commonly used Strategies are DoNothing, Manual Workaround, Reciprocal Arrangement,Gradual Recovery, Intermediate Recovery, Fast Recovery,Immediate Recovery. Recovery Options may make use ofdedicated facilities, or Third Party facilities shared bymultiple Businesses.

Recovery Point Objective(Service Operation) The maximum amount of data thatmay be lost when Service is Restored after an interruption.Recovery Point Objective is expressed as a length of timebefore the Failure. For example a Recovery Point Objectiveof one day may be supported by daily Backups, and up to24 hours of data may be lost. Recovery Point Objectivesfor each IT Service should be negotiated, agreed anddocumented, and used as requirements for Service Designand IT Service Continuity Plans.

Recovery Time Objective(Service Operation) The maximum time allowed forrecovery of an IT Service following an interruption. TheService Level to be provided may be less than normalService Level Targets. Recovery Time Objectives for each ITService should be negotiated, agreed and documented.See also Business Impact Analysis.

RedundancySee Fault Tolerance.

The term Redundant also has a generic meaning ofobsolete, or no longer needed.

RelationshipA connection or interaction between two people or things.In Business Relationship Management it is the interactionbetween the IT Service Provider and the Business. InConfiguration Management it is a link between twoConfiguration Items that identifies a dependency orconnection between them. For example Applications maybe linked to the Servers they run on, IT Services havemany links to all the CIs that contribute to that IT Service.

Relationship ProcessesThe ISO/IEC 20000 Process group that includes BusinessRelationship Management and Supplier Management.

Release(Service Transition) A collection of hardware, software,documentation, Processes or other Components requiredto implement one or more approved Changes to ITServices. The contents of each Release are managed,tested and deployed as a single entity.

Release and Deployment Management(Service Transition) The Process responsible for bothRelease Management and Deployment.

Release Identification(Service Transition) A naming convention used to uniquelyidentify a Release. The Release Identification typicallyincludes a reference to the Configuration Item and aversion number. For example Microsoft Office 2003 SR2.

Release Management(Service Transition) The Process responsible for Planning,scheduling and controlling the movement of Releases toTest and Live Environments. The primary Objective ofRelease Management is to ensure that the integrity of theLive Environment is protected and that the correct

210 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 210

Components are released. Release Management is part ofthe Release and Deployment Management Process.

Release ProcessThe name used by ISO/IEC 20000 for the Process groupthat includes Release Management. This group does notinclude any other Processes.

Release Process is also used as a synonym for ReleaseManagement Process.

Release Record(Service Transition) A Record in the CMDB that defines thecontent of a Release. A Release Record has Relationshipswith all Configuration Items that are affected by theRelease.

Release Unit(Service Transition) Components of an IT Service that arenormally Released together. A Release Unit typicallyincludes sufficient components to perform a usefulFunction. For example one Release Unit could be aDesktop PC, including Hardware, Software, Licences,Documentation etc. A different Release Unit may be thecomplete Payroll Application, including IT OperationsProcedures and user training.

Release WindowSee Change Window.

Reliability(Service Design) (Continual Service Improvement) Ameasure of how long a Configuration Item or IT Servicecan perform its agreed Function without interruption.Usually measured as MTBF or MTBSI. The term Reliabilitycan also be used to state how likely it is that a Process,Function etc. will deliver its required outputs. See alsoAvailability.

Remediation(Service Transition) Recovery to a known state after a failedChange or Release.

Repair(Service Operation) The replacement or correction of afailed Configuration Item.

Request for Change(Service Transition) A formal proposal for a Change to bemade. An RFC includes details of the proposed Change,and may be recorded on paper or electronically. The termRFC is often misused to mean a Change Record, or theChange itself.

Request Fulfilment(Service Operation) The Process responsible for managingthe Lifecycle of all Service Requests.

Requirement(Service Design) A formal statement of what is needed. Forexample, a Service Level Requirement, a ProjectRequirement or the required Deliverables for a Process. Seealso Statement of requirements.

Resilience(Service Design) The ability of a Configuration Item or ITService to resist Failure or to Recover quickly following aFailure. For example an armoured cable will resist failurewhen put under stress. See also Fault Tolerance.

Resolution(Service Operation) Action taken to repair the Root Causeof an Incident or Problem, or to implement a Workaround.In ISO/IEC 20000, Resolution Processes is the Processgroup that includes Incident and Problem Management.

Glossary | 211

7238-TSO-ITIL-13 28/8/07 14:01 Page 211

Resolution ProcessesThe ISO/IEC 20000 Process group that includes IncidentManagement and Problem Management.

Resource(Service Strategy) A generic term that includes ITInfrastructure, people, money or anything else that mighthelp to deliver an IT Service. Resources are considered tobe Assets of an Organization. See also Capability, ServiceAsset.

Response TimeA measure of the time taken to complete an Operation orTransaction. Used in Capacity Management as a measureof IT Infrastructure Performance, and in IncidentManagement as a measure of the time taken to answerthe phone, or to start Diagnosis.

ResponsivenessA measurement of the time taken to respond tosomething. This could be Response Time of a Transaction,or the speed with which an IT Service Provider respondsto an Incident or Request for Change etc.

Restoration of ServiceSee Restore.

Restore(Service Operation) Taking action to return an IT Service tothe Users after Repair and Recovery from an Incident. Thisis the primary Objective of Incident Management.

Retire(Service Transition) Permanent removal of an IT Service, orother Configuration Item, from the Live Environment.Retired is a stage in the Lifecycle of many ConfigurationItems.

Return on Investment (ROI)(Service Strategy) (Continual Service Improvement) Ameasurement of the expected benefit of an investment. Inthe simplest sense it is the net profit of an investmentdivided by the net worth of the assets invested. See alsoNet Present Value, Value on Investment.

Return to Normal(Service Design) The phase of an IT Service Continuity Planduring which full normal operations are resumed. Forexample, if an alternative data centre has been in use,then this phase will bring the primary data centre backinto operation, and restore the ability to invoke IT ServiceContinuity Plans again.

ReviewAn evaluation of a Change, Problem, Process, Project etc.Reviews are typically carried out at predefined points inthe Lifecycle, and especially after Closure. The purpose ofa Review is to ensure that all Deliverables have beenprovided, and to identify opportunities for improvement.See also Post-Implementation Review.

Rights(Service Operation) Entitlements, or permissions, grantedto a User or Role. For example the Right to modifyparticular data, or to authorize a Change.

RiskA possible event that could cause harm or loss, or affectthe ability to achieve Objectives. A Risk is measured by theprobability of a Threat, the Vulnerability of the Asset tothat Threat, and the Impact it would have if it occurred.

Risk AssessmentThe initial steps of Risk Management. Analysing the valueof Assets to the business, identifying Threats to those

212 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 212

Assets, and evaluating how Vulnerable each Asset is tothose Threats. Risk Assessment can be quantitative (basedon numerical data) or qualitative.

Risk ManagementThe Process responsible for identifying, assessing andcontrolling Risks. See also Risk Assessment.

RoleA set of responsibilities, Activities and authorities grantedto a person or team. A Role is defined in a Process. Oneperson or team may have multiple Roles, for example theRoles of Configuration Manager and Change Manager maybe carried out by a single person.

Rollout(Service Transition) See Deployment.

Most often used to refer to complex or phasedDeployments or Deployments to multiple locations.

Root Cause(Service Operation) The underlying or original cause of anIncident or Problem.

Root Cause Analysis(Service Operation) An Activity that identifies the RootCause of an Incident or Problem. RCA typicallyconcentrates on IT Infrastructure failures.

Running CostsSee Operational Costs.

ScalabilityThe ability of an IT Service, Process, Configuration Item etc.to perform its agreed Function when the Workload orScope changes.

ScopeThe boundary, or extent, to which a Process, Procedure,Certification, Contract etc. applies. For example the Scopeof Change Management may include all Live IT Servicesand related Configuration Items, the Scope of an ISO/IEC20000 Certificate may include all IT Services delivered outof a named data centre.

Second-line Support(Service Operation) The second level in a hierarchy ofSupport Groups involved in the resolution of Incidents andinvestigation of Problems. Each level contains morespecialist skills, or has more time or other resources.

SecuritySee Information Security Management.

Security ManagementSee Information Security Management.

Security PolicySee Information Security Policy.

Separation of Concerns(Service Strategy) An approach to Designing a solution orIT Service that divides the problem into pieces that can besolved independently. This approach separates ‘what’ is tobe done from ‘how’ it is to be done.

Server(Service Operation) A computer that is connected to anetwork and provides software Functions that are used byother Computers.

ServiceDelivering something of value to a Customer that is notgoods (physical things with material value). Examples of

Glossary | 213

7238-TSO-ITIL-13 28/8/07 14:01 Page 213

Services include banking, legal support or e-mail. Service isalso used as a synonym for IT Service.

Service Acceptance Criteria(Service Transition) A set of criteria used to ensure that anIT Service meets its functionality and Quality Requirementsand that the IT Service Provider is ready to Operate thenew IT Service when it has been Deployed. See alsoAcceptance.

Service Analytics(Service Strategy) A technique used in the assessment ofthe Business Impact of Incidents. Service Analytics Modelsthe dependencies between Configuration Items, and thedependencies of IT Services on Configuration Items.

Service AssetAny Capability or Resource of a Service Provider. See alsoAsset.

Service Asset and ConfigurationManagement(Service Transition) The Process responsible for bothConfiguration Management and Asset Management.

Service Capacity Management(Service Design) (Continual Service Improvement) TheActivity responsible for understanding the Performanceand Capacity of IT Services. The Resources used by each ITService and the pattern of usage over time are collected,recorded, and analysed for use in the Capacity Plan. Seealso Business Capacity Management, Resource CapacityManagement.

Service Catalogue(Service Design) A database or structured Document withinformation about all Live IT Services, including those

available for Deployment. The Service Catalogue is theonly part of the Service Portfolio published to Customers,and is used to support the sale and delivery of IT Services.The Service Catalogue includes information aboutdeliverables, prices, contact points, ordering and requestProcesses. See also Contract Portfolio.

Service Continuity ManagementSee IT Service Continuity Management.

Service Contract(Service Strategy) A Contract to deliver one or more ITServices. The term Service Contract is also used to meanany Agreement to deliver IT Services, whether this is alegal Contract or an SLA. See also Contract Portfolio.

Service CultureA Customer-oriented Culture. The major Objectives of aService Culture are Customer satisfaction and helpingCustomers to achieve their Business Objectives.

Service Design(Service Design) A stage in the Lifecycle of an IT Service.Service Design includes a number of Processes andFunctions and is the title of one of the Core ITILpublications. See also Design.

Service Design Package(Service Design) Document(s) defining all aspects of an ITService and its Requirements through each stage of itsLifecycle. A Service Design Package is produced for eachnew IT Service, major Change or IT Service Retirement.

Service Desk(Service Operation) The Single Point of Contact betweenthe Service Provider and the Users. A typical Service Deskmanages Incidents and Service Requests, and also handlescommunication with the Users.

214 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 214

Service Failure Analysis(Service Design) An Activity that identifies underlyingcauses of one or more IT Service interruptions. SFAidentifies opportunities to improve the IT Service Provider’sProcesses and tools, and not just the IT Infrastructure. SFAis a time-constrained, project-like activity, rather than anongoing process of analysis.

Service Hours(Service Design) (Continual Service Improvement) Anagreed time period when a particular IT Service should beavailable. For example, ‘Monday-Friday 08:00 to 17:00except public holidays’. Service Hours should be defined ina Service Level Agreement.

Service Improvement Plan(Continual Service Improvement) A formal Plan toimplement improvements to a Process or IT Service.

Service Knowledge Management System(Service Transition) A set of tools and databases that areused to manage knowledge and information. The SMKSincludes the Configuration Management System, as well asother tools and databases. The SKMS stores, manages,updates and presents all information that an IT ServiceProvider needs to manage the full Lifecycle of IT Services.

Service LevelMeasured and reported achievement against one or moreService Level Targets. The term Service Level is sometimesused informally to mean Service Level Target.

Service Level Agreement(Service Design) (Continual Service Improvement) AnAgreement between an IT Service Provider and aCustomer. The SLA describes the IT Service, documentsService Level Targets and specifies the responsibilities of

the IT Service Provider and the Customer. A single SLAmay cover multiple IT Services or multiple Customers. Seealso Operational Level Agreement.

Service Level Management(Service Design) (Continual Service Improvement) TheProcess responsible for negotiating Service LevelAgreements, and ensuring that these are met. SLM isresponsible for ensuring that all IT Service ManagementProcesses, Operational Level Agreements andUnderpinning Contracts are appropriate for the agreedService Level Targets. SLM monitors and reports on ServiceLevels, and holds regular Customer reviews.

Service Level Package(Service Strategy) A defined level of Utility and Warrantyfor a particular Service Package. Each SLP is designed tomeet the needs of a particular Pattern of Business Activity.See also Line of Service.

Service Level Requirement(Service Design) (Continual Service Improvement) ACustomer Requirement for an aspect of an IT Service. SLRsare based on Business Objectives and are used tonegotiate agreed Service Level Targets.

Service Level Target(Service Design) (Continual Service Improvement) Acommitment that is documented in a Service LevelAgreement. Service Level Targets are based on ServiceLevel Requirements, and are needed to ensure that the ITService design is Fit for Purpose. Service Level Targetsshould be measurable, and are usually based on KPIs.

Service Maintenance Objective(Service Operation) The expected time that a ConfigurationItem will be unavailable due to planned maintenanceActivity.

Glossary | 215

7238-TSO-ITIL-13 28/8/07 14:01 Page 215

Service ManagementService Management is a set of specialized organizationalcapabilities for providing value to Customers in the formof services.

Service Management LifecycleAn approach to IT Service Management that emphasizesthe importance of coordination and Control across thevarious Functions, Processes and Systems necessary tomanage the full Lifecycle of IT Services. The ServiceManagement Lifecycle approach considers the Strategy,Design, Transition, Operation and ContinuousImprovement of IT Services.

Service ManagerA manager who is responsible for managing the end-to-end Lifecycle of one or more IT Services. The term ServiceManager is also used to mean any manager within the ITService Provider. Most commonly used to refer to aBusiness Relationship Manager, a Process Manager, anAccount Manager or a senior manager with responsibilityfor IT Services overall.

Service Operation(Service Operation) A stage in the Lifecycle of an ITService. Service Operation includes a number of Processesand Functions and is the title of one of the Core ITILpublications. See also Operation.

Service Owner(Continual Service Improvement) A Role that isaccountable for the delivery of a specific IT Service.

Service Package(Service Strategy) A detailed description of an IT Servicethat is available to be delivered to Customers. A Service

Package includes a Service Level Package and one or moreCore Services and Supporting Services.

Service Pipeline(Service Strategy) A database or structured Documentlisting all IT Services that are under consideration orDevelopment, but are not yet available to Customers. TheService Pipeline provides a Business view of possible futureIT Services and is part of the Service Portfolio that is notnormally published to Customers.

Service Portfolio(Service Strategy) The complete set of Services that aremanaged by a Service Provider. The Service Portfolio isused to manage the entire Lifecycle of all Services, andincludes three Categories: Service Pipeline (proposed or inDevelopment); Service Catalogue (Live or available forDeployment); and Retired Services. See also ServicePortfolio Management, Contract Portfolio.

Service Portfolio Management(Service Strategy) The Process responsible for managingthe Service Portfolio. Service Portfolio Managementconsiders Services in terms of the Business value that theyprovide.

Service Potential(Service Strategy) The total possible value of the overallCapabilities and Resources of the IT Service Provider.

Service Provider(Service Strategy) An Organization supplying Services toone or more Internal Customers or External Customers.Service Provider is often used as an abbreviation for ITService Provider. See also Type I Service Provider, Type IIService Provider, Type III Service Provider.

216 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 216

Service Provider Interface(Service Strategy) An interface between the IT ServiceProvider and a User, Customer, Business Process or aSupplier. Analysis of Service Provider Interfaces helps tocoordinate end-to-end management of IT Services.

Service Provisioning Optimization(Service Strategy) Analysing the finances and constraints ofan IT Service to decide if alternative approaches to servicedelivery might reduce Costs or improve Quality.

Service Reporting(Continual Service Improvement) The Process responsiblefor producing and delivering reports of achievement andtrends against Service Levels. Service Reporting shouldagree the format, content and frequency of reports withCustomers.

Service Request(Service Operation) A request from a User for information,or advice, or for a Standard Change or for Access to an ITService. For example to reset a password, or to providestandard IT Services for a new User. Service Requests areusually handled by a Service Desk, and do not require anRFC to be submitted.

Service Sourcing(Service Strategy) The Strategy and approach for decidingwhether to provide a Service internally or to outsource itto an External Service Provider. Service Sourcing alsomeans the execution of this Strategy.

Service Sourcing includes:

� Internal Sourcing – Internal or Shared Services usingType I or Type II Service Providers

� Traditional Sourcing – Full Service Outsourcing using aType III Service Provider

� Multi-vendor Sourcing – Prime, Consortium or SelectiveOutsourcing using Type III Service. Providers.

Service Strategy(Service Strategy) The title of one of the Core ITILpublications. Service Strategy establishes an overallStrategy for IT Services and for IT Service Management.

Service Transition(Service Transition) A stage in the Lifecycle of an IT Service.Service Transition includes a number of Processes andFunctions and is the title of one of the Core ITILpublications. See also Transition.

Service Utility(Service Strategy) The Functionality of an IT Service fromthe Customer’s perspective. The Business value of an ITService is created by the combination of Service Utility(what the Service does) and Service Warranty (how well itdoes it). See also Utility.

Service Validation and Testing(Service Transition) The Process responsible for Validationand Testing of a new or Changed IT Service. ServiceValidation and Testing ensures that the IT Service matchesits Design Specification and will meet the needs of theBusiness.

Service Valuation(Service Strategy) A measurement of the total Cost ofdelivering an IT Service, and the total value to the Businessof that IT Service. Service Valuation is used to help theBusiness and the IT Service Provider agree on the value ofthe IT Service.

Service Warranty(Service Strategy) Assurance that an IT Service will meetagreed Requirements. This may be a formal Agreement

Glossary | 217

7238-TSO-ITIL-13 28/8/07 14:01 Page 217

such as a Service Level Agreement or Contract, or may bea marketing message or brand image. The Business valueof an IT Service is created by the combination of ServiceUtility (what the Service does) and Service Warranty (howwell it does it). See also Warranty.

Serviceability(Service Design) (Continual Service Improvement) Theability of a Third-Party Supplier to meet the terms of itsContract. This Contract will include agreed levels ofReliability, Maintainability or Availability for a ConfigurationItem.

Shift(Service Operation) A group or team of people who carryout a specific Role for a fixed period of time. For examplethere could be four shifts of IT Operations Controlpersonnel to support an IT Service that is used 24 hoursa day.

Simulation modelling(Service Design) (Continual Service Improvement) Atechnique that creates a detailed model to predict thebehaviour of a Configuration Item or IT Service. Simulationmodels can be very accurate but are expensive and timeconsuming to create. A simulation model is often createdby using the actual Configuration Items that are beingmodelled, with artificial Workloads or Transactions. Theyare used in Capacity Management when accurate resultsare important. A simulation model is sometimes called aPerformance Benchmark.

Single Point of Contact(Service Operation) Providing a single consistent way tocommunicate with an Organization or Business Unit. Forexample, a Single Point of Contact for an IT ServiceProvider is usually called a Service Desk.

Single Point of Failure(Service Design) Any Configuration Item that can cause anIncident when it fails, and for which a Countermeasure hasnot been implemented. A SPOF may be a person, or astep in a Process or Activity, as well as a Component ofthe IT Infrastructure. See also Failure.

SLAM Chart(Continual Service Improvement) A Service LevelAgreement Monitoring Chart is used to help monitor andreport achievements against Service Level Targets. A SLAMChart is typically colour coded to show whether eachagreed Service Level Target has been met, missed, ornearly missed during each of the previous 12 months.

SMART(Service Design) (Continual Service Improvement) Anacronym for helping to remember that targets in ServiceLevel Agreements and Project Plans should be Specific,Measurable, Achievable, Relevant and Timely.

Snapshot(Service Transition) The current state of a Configuration ascaptured by a discovery tool. Also used as a synonym forBenchmark. See also Baseline.

SourceSee Service Sourcing.

SpecificationA formal definition of Requirements. A Specification maybe used to define technical or Operational Requirements,and may be internal or external. Many public Standardsconsist of a Code of Practice and a Specification. TheSpecification defines the Standard against which anOrganization can be Audited.

218 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 218

StakeholderAll people who have an interest in an Organization,Project, IT Service etc. Stakeholders may be interested inthe Activities, targets, Resources or Deliverables.Stakeholders may include Customers, Partners, employees,shareholders, owners etc.

StandardA mandatory Requirement. Examples include ISO/IEC20000 (an international Standard), an internal securitystandard for Unix configuration, or a government standardfor how financial Records should be maintained. The termStandard is also used to refer to a Code of Practice orSpecification published by a Standards Organization suchas ISO or BSI. See also Guideline.

Standard Change(Service Transition) A pre-approved Change that is lowRisk, relatively common and follows a Procedure or WorkInstruction. For example, password reset or provision ofstandard equipment to a new employee. RFCs are notrequired to implement a Standard Change, and they arelogged and tracked using a different mechanism, such as aService Request. See also Change Model.

Standard Operating Procedures(Service Operation) Procedures used by IT OperationsManagement.

Standby(Service Design) Used to refer to Resources that are notrequired to deliver the Live IT Services, but are available tosupport IT Service Continuity Plans. For example a Standbydata centre may be maintained to support Hot Standby,Warm Standby or Cold Standby arrangements.

Statement of requirements(Service Design) A Document containing all Requirementsfor a product purchase, or a new or changed IT Service.See also Terms of Reference.

StatusThe name of a required field in many types of Record. Itshows the current stage in the Lifecycle of the associatedConfiguration Item, Incident, Problem etc.

Status Accounting(Service Transition) The Activity responsible for recordingand reporting the Lifecycle of each Configuration Item.

Storage Management(Service Operation) The Process responsible for managingthe storage and maintenance of data throughout itsLifecycle.

Strategic(Service Strategy) The highest of three levels of Planningand delivery (Strategic, Tactical, Operational). StrategicActivities include Objective setting and long-term Planningto achieve the overall Vision.

Strategy(Service Strategy) A Strategic Plan designed to achievedefined Objectives.

Super User(Service Operation) A User who helps other Users, andassists in communication with the Service Desk or otherparts of the IT Service Provider. Super Users typicallyprovide support for minor Incidents and training.

Glossary | 219

7238-TSO-ITIL-13 28/8/07 14:01 Page 219

Supplier(Service Strategy) (Service Design) A Third Partyresponsible for supplying goods or Services that arerequired to deliver IT services. Examples of suppliersinclude commodity hardware and software vendors,network and telecom providers, and outsourcingOrganizations. See also Underpinning Contract, SupplyChain.

Supplier and Contract Database(Service Design) A database or structured Document usedto manage Supplier Contracts throughout their Lifecycle.The SCD contains key Attributes of all Contracts withSuppliers, and should be part of the SMKS.

Supplier Management(Service Design) The Process responsible for ensuring thatall Contracts with Suppliers support the needs of theBusiness, and that all Suppliers meet their contractualcommitments.

Supply Chain(Service Strategy) The Activities in a Value Chain carriedout by Suppliers. A Supply Chain typically involvesmultiple Suppliers, each adding value to the product orService.

Support Group(Service Operation) A group of people with technical skills.Support Groups provide the Technical Support needed byall of the IT Service Management Processes. See alsoTechnical Management.

Support Hours(Service Design) (Service Operation) The times or hourswhen support is available to the Users. Typically these arethe hours when the Service Desk is available. Support

Hours should be defined in a Service Level Agreement,and may be different from Service Hours. For example,Service Hours may be 24 hours a day, but the SupportHours may be 07:00 to 19:00.

Supporting Service(Service Strategy) A Service that enables or enhances aCore Service. For example, a Directory Service or a BackupService. See also Service Package.

SWOT Analysis(Continual Service Improvement) A technique that reviewsand analyses the internal strengths and weaknesses of anOrganization and of the external opportunities and threatsthat it faces. SWOT stands for Strengths, Weaknesses,Opportunities and Threats.

SystemA number of related things that work together to achievean overall Objective. For example:

� A computer System including hardware, software andApplications

� A management System, including multiple Processesthat are planned and managed together. For example,a Quality Management System

� A Database Management System or Operating Systemthat includes many software modules that aredesigned to perform a set of related Functions.

System ManagementThe part of IT Service Management that focuses on themanagement of IT Infrastructure rather than Process.

TacticalThe middle of three levels of Planning and delivery(Strategic, Tactical, Operational). Tactical Activities include

220 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 220

the medium-term Plans required to achieve specificObjectives, typically over a period of weeks to months.

Tag(Service Strategy) A short code used to identify a Category.For example tags EC1, EC2, EC3 etc. might be used toidentify different Customer outcomes when analysing andcomparing Strategies. The term Tag is also used to refer tothe activity of assigning Tags to things.

Technical Management(Service Operation) The Function responsible for providingtechnical skills in support of IT Services and managementof the IT Infrastructure. Technical Management defines theRoles of Support Groups, as well as the tools, Processesand Procedures required.

Technical Observation(Continual Service Improvement) A technique used inService Improvement, Problem investigation andAvailability Management. Technical support staff meet tomonitor the behaviour and Performance of an IT Serviceand make recommendations for improvement.

Technical ServiceSee Infrastructure Service.

Technical SupportSee Technical Management.

Tension Metrics(Continual Service Improvement) A set of related Metrics,in which improvements to one Metric have a negativeeffect on another. Tension Metrics are designed to ensurethat an appropriate balance is achieved.

Terms of Reference(Service Design) A Document specifying the Requirements,Scope, Deliverables, Resources and schedule for a Projector Activity.

Test(Service Transition) An Activity that verifies that aConfiguration Item, IT Service, Process etc. meets itsSpecification or agreed Requirements. See also ServiceValidation and Testing, Acceptance.

Test Environment(Service Transition) A controlled Environment used to TestConfiguration Items, Builds, IT Services, Processes etc.

Third PartyA person, group or Business that is not part of the ServiceLevel Agreement for an IT Service, but is required toensure successful delivery of that IT Service. For example, asoftware Supplier, a hardware maintenance company, or afacilities department. Requirements for Third Parties aretypically specified in Underpinning Contracts orOperational Level Agreements.

Third-line Support(Service Operation) The third level in a hierarchy ofSupport Groups involved in the resolution of Incidents andinvestigation of Problems. Each level contains morespecialist skills, or has more time or other resources.

ThreatAnything that might exploit a Vulnerability. Any potentialcause of an Incident can be considered to be a Threat. Forexample a fire is a Threat that could exploit theVulnerability of flammable floor coverings. This term iscommonly used in Information Security Management and

Glossary | 221

7238-TSO-ITIL-13 28/8/07 14:01 Page 221

IT Service Continuity Management, but also applies toother areas such as Problem and Availability Management.

ThresholdThe value of a Metric that should cause an Alert to begenerated, or management action to be taken. Forexample ‘Priority 1 Incident not solved within four hours’,‘more than five soft disk errors in an hour’, or ‘more than10 failed changes in a month’.

Throughput(Service Design) A measure of the number of Transactions,or other Operations, performed in a fixed time. Forexample, 5,000 e-mails sent per hour, or 200 disk I/Os persecond.

Total Cost of Ownership(Service Strategy) A methodology used to help makeinvestment decisions. TCO assesses the full Lifecycle Costof owning a Configuration Item, not just the initial Cost orpurchase price. See also Total Cost of Utilization.

Total Cost of Utilization(Service Strategy) A methodology used to help makeinvestment and Service Sourcing decisions. TCU assessesthe full Lifecycle Cost to the Customer of using an ITService. See also Total Cost of Ownership.

Total Quality Management(Continual Service Improvement) A methodology formanaging continual Improvement by using a QualityManagement System. TQM establishes a Culture involvingall people in the Organization in a Process of continualmonitoring and improvement.

TransactionA discrete Function performed by an IT Service. Forexample transferring money from one bank account to

another. A single Transaction may involve numerousadditions, deletions and modifications of data. Either all ofthese complete successfully or none of them is carried out.

Transition(Service Transition) A change in state, corresponding to amovement of an IT Service or other Configuration Itemfrom one Lifecycle status to the next.

Transition Planning and Support(Service Transition) The Process responsible for Planning allService Transition Processes and coordinating theresources that they require. These Service TransitionProcesses are Change Management, Service Asset andConfiguration Management, Release and DeploymentManagement, Service Validation and Testing, Evaluationand Knowledge Management.

Trend Analysis(Continual Service Improvement) Analysis of data toidentify time-related patterns. Trend Analysis is used inProblem Management to identify common Failures orfragile Configuration Items, and in Capacity Managementas a Modelling tool to predict future behaviour. It is alsoused as a management tool for identifying deficiencies inIT Service Management Processes.

TuningThe Activity responsible for Planning changes to make themost efficient use of Resources. Tuning is part ofPerformance Management, which also includesPerformance monitoring and implementation of therequired Changes.

Type I Service Provider(Service Strategy) An Internal Service Provider that isembedded within a Business Unit. There may be severalType I Service Providers within an Organization.

222 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 222

Type II Service Provider(Service Strategy) An Internal Service Provider thatprovides shared IT Services to more than one BusinessUnit.

Type III Service Provider(Service Strategy) A Service Provider that provides ITServices to External Customers.

Underpinning Contract(Service Design) A Contract between an IT Service Providerand a Third Party. The Third Party provides goods orServices that support delivery of an IT Service to aCustomer. The Underpinning Contract defines targets andresponsibilities that are required to meet agreed ServiceLevel Targets in an SLA.

Unit Cost(Service Strategy) The Cost to the IT Service Provider ofproviding a single Component of an IT Service. Forexample the Cost of a single desktop PC, or of a singleTransaction.

Urgency(Service Transition) (Service Design) A measure of howlong it will be until an Incident, Problem or Change has asignificant Impact on the Business. For example a highImpact Incident may have low Urgency, if the Impact willnot affect the Business until the end of the financial year.Impact and Urgency are used to assign Priority.

Usability(Service Design) The ease with which an Application,product, or IT Service can be used. Usability Requirementsare often included in a Statement of requirements.

Use Case(Service Design) A technique used to define requiredfunctionality and Objectives, and to design Tests. UseCases define realistic scenarios that describe interactionsbetween Users and an IT Service or other System. See alsoChange Case.

UserA person who uses the IT Service on a day-to-day basis.Users are distinct from Customers, as some Customers donot use the IT Service directly.

User Profile(Service Strategy) A pattern of User demand for IT Services.Each User Profile includes one or more Patterns ofBusiness Activity.

Utility(Service Strategy) Functionality offered by a Product orService to meet a particular need. Utility is oftensummarized as ‘what it does’. See also Service Utility.

Validation(Service Transition) An Activity that ensures a new orchanged IT Service, Process, Plan or other Deliverablemeets the needs of the Business. Validation ensures thatBusiness Requirements are met even though these mayhave changed since the original design. See alsoVerification, Acceptance, Qualification, Service Validationand Testing.

Value Chain(Service Strategy) A sequence of Processes that creates aproduct or Service that is of value to a Customer. Eachstep of the sequence builds on the previous steps andcontributes to the overall product or Service. See alsoValue Network.

Glossary | 223

7238-TSO-ITIL-13 28/8/07 14:01 Page 223

Value for MoneyAn informal measure of Cost Effectiveness. Value forMoney is often based on a comparison with the Cost ofalternatives. See also Cost Benefit Analysis.

Value Network(Service Strategy) A complex set of relationships betweentwo or more groups or organizations. Value is generatedthrough exchange of knowledge, information, goods orServices. See also Value Chain, Partnership.

Value on Investment(Continual Service Improvement) A measurement of theexpected benefit of an investment. VOI considers bothfinancial and intangible benefits. See also Return onInvestment.

Variable Cost(Service Strategy) A Cost that depends on how much theIT Service is used, how many products are produced, thenumber and type of Users, or something else that cannotbe fixed in advance. See also Variable Cost Dynamics.

Variable Cost Dynamics(Service Strategy) A technique used to understand howoverall Costs are affected by the many complex variableelements that contribute to the provision of IT Services.

VarianceThe difference between a planned value and the actualmeasured value. Commonly used in FinancialManagement, Capacity Management and Service LevelManagement, but could apply in any area where Plans arein place.

Verification(Service Transition) An Activity that ensures a new orchanged IT Service, Process, Plan or other Deliverableis complete, accurate, reliable and matches its designspecification. See also Validation, Acceptance, ServiceValidation and Testing.

Verification and Audit(Service Transition) The Activities responsible for ensuringthat information in the CMDB is accurate and that allConfiguration Items have been identified and recorded inthe CMDB. Verification includes routine checks that arepart of other processes. For example, verifying the serialnumber of a desktop PC when a User logs an Incident.Audit is a periodic, formal check.

Version(Service Transition) A Version is used to identify a specificBaseline of a Configuration Item. Versions typically use anaming convention that enables the sequence or date ofeach Baseline to be identified. For example PayrollApplication Version 3 contains updated functionality fromVersion 2.

VisionA description of what the Organization intends to becomein the future. A Vision is created by senior managementand is used to help influence Culture and StrategicPlanning.

Vital Business Function(Service Design) A Function of a Business Process that iscritical to the success of the Business. Vital BusinessFunctions are an important consideration of BusinessContinuity Management, IT Service ContinuityManagement and Availability Management.

224 | Glossary

7238-TSO-ITIL-13 28/8/07 14:01 Page 224

VulnerabilityA weakness that could be exploited by a Threat. Forexample an open firewall port, a password that is neverchanged, or a flammable carpet. A missing Control is alsoconsidered to be a Vulnerability.

Warm StandbySee Intermediate Recovery.

Warranty(Service Strategy) A promise or guarantee that a productor Service will meet its agreed Requirements. See alsoService Validation and Testing, Service Warranty.

Work in ProgressA Status that means Activities have started but are not yetcomplete. It is commonly used as a Status for Incidents,Problems, Changes etc.

Work InstructionA Document containing detailed instructions that specifyexactly what steps to follow to carry out an Activity.A Work Instruction contains much more detail than aProcedure and is only created if very detailed instructionsare needed.

Workaround(Service Operation) Reducing or eliminating the Impact ofan Incident or Problem for which a full Resolution is notyet available. For example by restarting a failedConfiguration Item. Workarounds for Problems aredocumented in Known Error Records. Workarounds forIncidents that do not have associated Problem Records aredocumented in the Incident Record.

WorkloadThe Resources required to deliver an identifiable part of anIT Service. Workloads may be categorized by Users, groupsof Users or Functions within the IT Service. This is used toassist in analysing and managing the Capacity,Performance and Utilization of Configuration Items and ITServices. The term Workload is sometimes used as asynonym for Throughput.

Glossary | 225

7238-TSO-ITIL-13 28/8/07 14:01 Page 225

7238-TSO-ITIL-13 28/8/07 14:01 Page 226

Index

TSO-ITIL-13 text 2 28/8/07 18:45 Page 227

Access Management 105–106business value 105–106

Account Manager 109Active Monitoring 94, 110Alert 132Application Architect 15 (Tab)Application Management 117–121

generic activities 118–120, 120 (Fig)objectives 118roles 120–121

Applications analysts/architects 121Application Service Provision (ASP), Service Design,

delivery model options 49 (Tab)Applications managers/team-leaders 120–121Architecture 20 (Fig)ASP (Application Service Provision), Service Design,

delivery model options 49 (Tab)Asset and Configuration Management see Service Asset

and Configuration Management (SACM)Automatic Call Distribution 133Availability and Continuity 85Availability Management 54, 96

costs justification 61, 63 (Fig)elements 61, 62 (Fig)monitoring and data collection 138objectives 60principle 61Service Design 60–64Vital Business Functions identification 61

Availability Management Information System 62 (Fig)Availability Plans 60, 62 (Fig), 138

backup and restore 116Best Practice 4

guidance 5BIA see Business Impact Analysis (BIA)

BPO (Business Process Outsourcing), Service Design,delivery model options 49 (Tab)

Business Capacity Management 57focus 58

Business Continuity Management 66 (Fig)Business Continuity Plans 64business drivers, Continual Service Improvement 128Business Impact Analysis (BIA) 50, 64, 65Business Process Outsourcing (BPO), Service Design,

delivery model options 49 (Tab)Business Relationship Management 51Business Service 48 (Fig), 152 (Fig), 153 (Fig)Business Service Catalogue 50

Capability Maturity Model Integrated (CMMi) 146Capacity Management 50, 54, 96

elements 59 (Fig)monitoring and data collection 138objectives 57Problem Management, open-loop system 107Service Design 55–60

Capacity Management Information System (CMIS) 58Capacity Plans 57, 58, 138Certification, Service Potential increases 39 (Tab)Change Advisory Board (CAB) 82 (Fig), 83Change and Release Management 76, 79Change Management 80–83, 134

Configuration Item information 85elements 161 (Fig)goals 80–81process 160, 161 (Fig)Request approvals 100seven Rs 81supporting policies 81

Change Manager 15 (Tab), 83Change Model, definition 81–82, 82 (Fig)

| 229

Index


Change Process Flow 14Change Requestor 15 (Tab), 83Change Request (RFC) 81CIO/IT Director 15 (Tab)CMMi (Capability Maturity Model Integrated) 146COBIT (Control OBjectives for Information and related

Technology) 145complementary guidance 5, 7, 145–146Compliance 132

core guidance 6, 13–14ISO 20000:2005 35

Component Availability 61Component Capacity Management 58–60

focus 58Confidentiality 66–67Configuration Baseline 160 (Fig), 161 (Fig)Configuration Control 86 (Fig)Configuration Identification 88 (Fig)Configuration Items (CIs) 50, 80, 83–84

attributes 85categories 84Change Management 85Event Management 85, 95Financial Management 85Incident Management 85Service Desk 85

Configuration Management System 38–39, 68, 84–85Configuration Record 88 (Fig)conformance, core guidance 6, 13–14Console Management 116consortium 34 (Tab)Continual Service Improvement (CSI) 19 (Tab), 109,

125–141, 166–167benefits 127–128business drivers 128coordination 21core guidance 6, 12–13elements 154 (Fig), 155 (Fig), 167 (Fig)

information flow 168 (Fig)

integrated flow 169 (Fig)feedback 22 (Fig), 163objectives 126–128, 127 (Fig)operational monitoring 111processes 129–139, 167 (Fig)purpose 125–126, 158service measurement framework 129Service Reporting 140, 141 (Fig)Seven-step Improvement Process see Seven-step

Improvement Processspecialization 21technology drivers 128Value on Investment 127, 128

Continuity Management see IT Service ContinuityManagement (ITSCM)

Contract 40Contract Portfolio 88 (Fig)Control OBjectives for Information and related Technology

(COBIT) 145core guidance 6–7, 11–15

challenges and risks 6Compliance 6, 13–14conformance 6, 13–14Continual Service Improvement 6, 12–13Lifecycle quality control 6, 13Service Design 6, 11–12Service Operation 6, 12Service Strategy 6, 11Service Transition 6, 12technology considerations 6

core of practice 19–21corporate governance 66co-sourcing, Service Design, delivery model

options 49 (Tab)Cost

classifications 38see also Financial Management

dynamics 38metrics 139 (Tab)

230 | Index


Cost Type 38see also Financial Management

Critical Success Factor 26 (Tab)CSI see Continual Service Improvement (CSI)customer(s) 40

perceived benefits 29customer satisfaction, metrics 139 (Tab)

data analysis, Continual Service Improvement 133–135data centre rationalization, Service Potential increases

39 (Tab)data gathering 131–132, 137–138data presentation, Continual Service Improvement

135–136data processing, Continual Service Improvement 133decision-making, improved Service Design 46decision-rights matrix 35defects, metrics 139 (Tab)Deming Quality Cycle 13 (Fig)

see also Plan-Do-Check-Act (PDCA) cycleDeployment Management 76Designing for Recovery 64Development Environment 105Drivers 128

Early Life Support 162–163ECAB (Emergency Change Advisory Board) 104Emergency Change 13–14

Model 82Emergency Change Advisory Board (ECAB) 104Emergency Change Model 82Event Management 94–95

business value 96Configuration Items 85, 95process 95 (Fig), 164 (Fig)

exceptions 132External Service Provider 28External Sourcing see Outsourcing

Facilities Management 117Failure 122feedback systems 21, 22 (Fig), 163Financial Management 36–38

Configuration Items information 85monitoring and data collection 138Service Strategy 36–38Service Valuation 37–38variable cost dynamics 38

Functional Escalation 97

good practice 4governance 15 (Tab), 149–150, 150 (Fig)

corporate 66definition 35domains 35Service Design value 46sourcing 35

guidanceBest Practice 5complementary 5, 7, 145–146core see core guidance

Hierarchic Escalation 97–98historical perspective 3, 5

Incident Management 54, 61, 96–99business value 96Configuration Items 85implementation, Service Potential increases 39 (Tab)incident escalation 97–99, 109incident models 96–99interfaces 100monitoring and data collection 138process 98 (Fig)

flow 165 (Fig)incident closure 99investigation and diagnosis 99prioritization 97

Index | 231


Service Desk function 108–109user satisfaction survey 99

Incident Manager 15 (Tab)Incidents

availability-related 60escalation 97–99, 109models 96–99trends 139, 140 (Fig)

information flowContinual Service Improvement 168 (Fig)Service Operation 166 (Fig)Service Transition 162 (Fig)

Information Security Management (ISM)elements 67–68monitoring and data collection 138process 69 (Fig)Service Design 66–70

Information Security Policy 67, 68, 69Information Technology see under ITInfrastructure Architect 15 (Tab)Insourcing, Service Design, delivery model options 49 (Tab)Internal IT 136Internal Service Provider 27–28ISM see Information Security Management (ISM)ISO 20000:2005 3, 14

complementary guidance 145Compliance 35

ISO 27001 68ISO/IEC 15504 145ISO/IEC 19770:2006 145ISO/IEC 20000 13, 14, 35, 145ITIL 20ITIL Live Web portal 159, 163ITIL Service Management Model 4–7, 19 (Fig), 149–170

complementary guidance 5, 7, 145–146coordination across 21core guidance see core guidancedesign non-linearity 21elements 19–21, 149–153, 170 (Fig)

Continual Service Improvement see Continual Service Improvement (CSI)

governance and operational 150 (Fig)integrated flow 169 (Fig)practice 155 (Fig)process 154 (Fig)Service Design see Service DesignService Operation see Service OperationService Strategy see Service StrategyService Transition see Service Transition

feedback systems 21, 22 (Fig), 163functions 20objectives 5principles 6, 19–20processes 20–21

architecture 20 (Fig)specialization across 21value proposition 4

ITIL web support services 7IT Information Management Forum (ITIMF) 3IT Infrastructure Library (ITIL) 20IT Operations Control 116IT Operations Management 15 (Tab), 107, 116–117

objectives 117role 116–117

IT Service Continuity Management (ITSCM) 64–65lifecycle 66 (Fig)objectives 64–65

IT Service Continuity Planning 50IT Service Management Forum (itSMF) 3IT Service Management (ITSM)

British Standard 15000 3definition 5ITIL framework see ITIL Service Management Modelorigins 3, 5

IT Service Manager 15 (Tab)IT Service Provider see Service ProviderIT Steering 15 (Tab)

see also Governance

232 | Index


Job Scheduling 116

KEDB (Known Error Database) 103–104, 105Key Performance Indicator, Service Level Agreements 55Knowledge Management 150 (Fig), 154 (Fig), 162 (Fig)Knowledge Process Outsourcing (KPO) 49 (Tab)Known Error 122Known Error Database (KEDB) 103–104, 105Known Error Record 104KPO (Knowledge Process Outsourcing) 49 (Tab)

Levels of Service (LOS) 56

Major Incidents 69 (Fig)Management

definition 35senior 136

Management of Risk (M_o_R®) 145–146Mean Time to Restore Service 80metrics 138–139

Cost 139 (Tab)customer satisfaction 139 (Tab)defects 139 (Tab)definition 138interpretation 139process 131productivity 139 (Tab)service 129, 132Service Desk performance 113Service Level Agreements 55technology 131

Middleware 115Monitor Control Loops

complex 107–109, 108 (Fig)ITSM 109–111, 110 (Fig)single 107, 107 (Fig)

monitoring and control 106–111active vs. passive 110–111Continual Service Improvement 111

Monitor Control Loops see Monitor Control Loopsreactive vs. proactive 111

monitoring and data collection 137–138M_o_R® (Management of Risk) 145–146multi-sourcing, Service Design, delivery model options

49 (Tab)

Normal Change Model 82, 82 (Fig)

Operational 149–150, 150 (Fig)operational monitoring see monitoring and controlOperations Control 116Operations Management see IT Operations ManagementOrganizational Configuration Items 84organizational structures, Service Strategy 39–41, 40 (Tab)Outsourcing

selective 34 (Tab)Service Design, delivery model options 49 (Tab)Service Strategy 33–35, 34 (Tab)

Partnership, Service Design, delivery model options49 (Tab)

Passive Monitoring 110–111Patterns of Business Activity (PBA) 56PDCA (Plan-Do-Check-Act) cycle 13 (Fig), 68performance reports 58Plan-Do-Check-Act (PDCA) cycle 13 (Fig), 68PMBOK® (Project Management Body of Knowledge) 146Portfolio Manager 15 (Tab)Post-Implementation Review (PIR) 134practice framework 4–5predictive reports 58principles 6print and output management 117Proactive Monitoring 111Proactive Problem Management 101, 102 (Fig)Problem Management 61, 62, 101–105

open-loop system, Capacity Management 107process 101–103, 102 (Fig)

Index | 233


investigation and diagnosis 103–104logging 103prioritization 103problem resolution and closure 104–105workarounds 104

scope 101Problem-matching techniques 104Problem Record 103Process Compliance 132Process Metrics 131Process Owner 71 (Fig)Production Environment 76, 84, 88, 104, 137productivity, metrics 139 (Tab)profitability 26project management, Service Operation 121Project Management Body of Knowledge (PMBOK®) 146publications 6

Quality 131, 132control, core guidance see core guidanceDeming Quality Cycle 13 (Fig)see also Continual Service Improvement (CSI)

Quality Assurance 169 (Fig)

RACI 35Reactive Monitoring 111Release and Deployment Management 86–88

objectives 87packages 87 (Fig)

reports 136Request approvals, Change Management 100Request for Change (RFC) 81Request Fulfilment 99–101

interfaces 100–101models 100–101

Resource Capacity Management 58Resources, Service Assets 29Return on Investment (ROI)

Continual Service Improvement 127, 128

Service Strategy 35–36, 36 (Fig)Risk Analysis 65Risk Assessment, Service Operation 122Risk Management 122ROI see Return on Investment (ROI)

SACM see Service Asset and Configuration Management(SACM)

SAM (Software Asset Management) 145satisfaction surveys 71schedules, metrics 139 (Tab)SDP (Service Design Package) 78, 159Security see Information Security Management (ISM)security incidents 68–69

see also Information Security Management (ISM)Security Management see Information Security

Management (ISM)Security Policy see Information Security Policysecurity risks 122Service 5Service Acceptance Criteria 160 (Fig)service alignment 46Service Asset and Configuration Management (SACM)

83–85attributes 85business value 85interfaces to lifecycle 86 (Fig), 100

Service Assetsresources 29Service Strategy 28–29utility 28warranty 28

Service Availability 61Service Capacity Management 57–58

focus 58Service Catalogue 33, 50–52

elements 32 (Fig), 51 (Fig)evaluation 158

Service Catalogue Management 50–52

234 | Index


Service Configuration Items 84Service Continuity Management see IT Service Continuity

Management (ITSCM)Service Delivery

coordination 21specialization 21

Service Design 19 (Tab), 45–72aims 46–47Availability Management 60–64business value 46Capacity Management 55–60core guidance 6, 11–12definition 11delivery model options 49

Business Process Outsourcing 49 (Tab)dependencies 48 (Fig)elements 154 (Fig), 155 (Fig)feedback 22 (Fig), 163holistic approach 47identifying requirements 47Information Security Management 66–70integrated flow 169 (Fig)IT Service Continuity Management see IT Service

Continuity Management (ITSCM)models 48monitoring and data collection 137operational staff 122role 136, 158–159, 159 (Fig)Service Catalogue Management 50–52Service Level Management see Service Level

Management (SLM)Supplier Management 70–72

Service Design Package (SDP) 78, 159Service Desk 96, 111–114, 133–134

Configuration Items information 85Incident Management 108–109incident resolution, recovery and closure 99monitoring and data collection 138performance metrics 113

Request Fulfilment 99–101value 111–112

Service Desk Analysts 97, 112, 113Service Desk Manager/staff 15 (Tab), 112Service Desk Supervisor 112–113Service Failure Analysis (SFA) 62–64

objectives 62–64Service Improvement Programme (SIP) 52

integrated flow 169 (Fig)Service Knowledge Management System 12, 48 (Fig)Service Level Agreements (SLAs) 52

customer-based 54metrics 55multi-level 54performance monitoring 55service-based 54wording 54

Service Level Management (SLM) 15 (Tab), 52–55Configuration Items information 85monitoring and data collection 137objectives 52process 53 (Fig)

Service Level Packages (SLPs) 56component-based 56 (Fig)

Service Level Requirements (SLRs) 52, 54, 57, 109Service Level Target 52, 83, 130Service Lifecycle Configuration Items 84Service Management Lifecycle see ITIL Service

Management Modelservice metrics 129, 132service monitoring, process compliance 132Service Operation 15 (Tab), 19 (Tab), 93–122

business value 94coordination 21core guidance 6, 12elements 154 (Fig), 155 (Fig)feedback 22 (Fig)functions 106–116, 136

monitoring and control see monitoring and control

Index | 235


Service Desk see Service DeskTechnical Management see Technical Management

information flow 166 (Fig)integrated flow 169 (Fig)IT Operations Management see IT Operations

Managementmonitoring and data collection 137processes 162–166, 163 (Fig)

Access Management see Access ManagementApplication Management see Application

ManagementEvent Management see Event ManagementIncident Management see Incident ManagementProblem Management see Problem ManagementRequest Fulfilment see Request Fulfilment

project management 121risk assessment/management 122specialization 21

Service Operational Readiness Test 89 (Fig)Service Pipeline 33Service Portfolio 30–33, 31 (Fig), 57

elements 32 (Fig), 50, 157 (Fig)evaluation 158

Service Portfolio Management (SPM) 31, 33 (Fig)Service Potential, increases 38–39, 39 (Tab)Service Provider

capabilities and resources 29 (Fig)External 28Internal 27–28types 27–28, 150

Type I 27–28, 151 (Fig)Type II 28, 152 (Fig)Type III 28, 153 (Fig)

Service ReportingContinual Service Improvement 140, 141 (Fig)

Service Sourcing 33–35External see Outsourcinggovernance 35Internal see Insourcing

structures 34 (Tab)Service Strategy 15 (Tab), 19 (Tab), 25–41, 136

coordination 21core guidance 6, 11definition 11, 25elements 154 (Fig), 155 (Fig), 158, 158 (Fig)

integrated flow 169 (Fig)feedback 22 (Fig), 163Financial Management 36–38formulation 155, 156 (Fig)key concepts 25market space definition 29–30, 30 (Fig)monitoring and data collection 137organizational structures 39–41, 40 (Tab)outsourcing 33–35, 34 (Tab)return on investment 35–36, 36 (Fig)Service Assets 28–29Service Potential increases 38–39, 39 (Tab)Service Provider types see Service Providersourcing governance 35specialization 21strategic assessment 25–27, 26 (Tab)strategic capability development 27

service testing and evaluation, Service Transition 88,89 (Fig)

Service Transition 15 (Tab), 19 (Tab), 75–89aims 75–76business value 76coordination 21core guidance 6, 12elements 154 (Fig), 155 (Fig)feedback 22 (Fig)information flow 162 (Fig)integrated flow 169 (Fig)key concepts 75monitoring and data collection 137operational staff 122processes 76, 77 (Fig), 159–160, 160 (Fig), 163

236 | Index


Asset and Configuration Management see Service Asset and Configuration Management (SACM)

Change Management see Change ManagementRelease and Deployment Management see Release

and Deployment Managementservice testing and evaluation 88, 89 (Fig)Transition Planning and Support see Transition

Planning and Supportrole 136specialization 21strategy 78

Service Transition plan 78–79Service Utility 29Service Validation and Testing 76, 77 (Fig), 88, 150 (Fig),

159, 162 (Fig)Service Valuation

Financial Management 37–38Service Warranty 28Seven-step Improvement Process 129–137, 130 (Fig)

corrective action implementation 136–137data analysis 133–135data gathering 131–132data presentation 135–136data processing 133measurement definitions 129–131

SFA see Service Failure Analysis (SFA)Shared Service Provider 28Shift 113Single Point of Contact 138SIP see Service Improvement Programme (SIP)Six Sigma 146SLAs see Service Level Agreements (SLAs)SLM see Service Level Management (SLM)SLPs see Service Level Packages (SLPs)SLRs see Service Level Requirements (SLRs)Snapshot 126, 135Software Asset Management (SAM) 145software development teams 120

Software Process Improvement and Capability dEtermination (SPICE) 145

Solution Development 15 (Tab)Sourcing see Service SourcingSPICE (Software Process Improvement and Capability

dEtermination) 145SPM (Service Portfolio Management) 31, 33 (Fig)Stakeholder 21, 52, 77 (Fig), 159 (Fig)Standard Change 81–82, 100Standard Change Model 81–82Standard Operating Procedures (SOPs) 120Status Accounting 86 (Fig)strategic assessment, Service Strategy 25–27, 26 (Tab)strategic capability development, Service Strategy 27Super Users 113–114Supplier and Contract Database 70Supplier Management 70–72

objectives 70–71roles and interfaces 71 (Fig)

Supplier Relationship Management 15 (Tab)Support Group 99, 100, 103, 113, 134Supporting Service 50–51, 78

technical analysts/architects 115–116Technical Management 114–116

organization 114–115roles 115–116support staff 15 (Tab)

technical managers/team-leaders 115Technical Service Catalogue 51–52, 51 (Fig)Technical Support see Technical Managementtechnology considerations, core guidance 6technology drivers, Continual Service Improvement 128technology metrics 131Terms of Reference 65Testing/Production Assurance 15 (Tab)thin-client computing 39 (Tab)Third Party 31, 31 (Fig), 99, 105, 155 (Fig)

reduced, Service Design business value 46

Index | 237


training, Service Potential increases 39 (Tab)Transition Planning and Support 76–80, 77 (Fig)

aims 76–78individual plans 78–79integrated planning 79review 79–80

Trend Analysis 132Tuning 57Type III Service Provider 28, 153 (Fig)Type II Service Provider 28, 152 (Fig)Type I Service Provider 27–28, 151 (Fig)

UC (Underpinning Contracts) 47Underpinning Contracts (UCs) 47Unit Cost 28, 22User Profile 106user satisfaction surveys, Incident Management 99Utility, Service Assets 28

Value Chain 26Value for Money 70, 128Value Network 26, 70, 151, 152, 153 (Fig)Value on Investment (VOI), Continual Service Improvement

127, 128value proposition 4Variable Cost Dynamics (VCD) 38Variance 37, 101VCD (Variable Cost Dynamics) 38Verification and Audit 86 (Fig)Virtual Private Network (VPN) connections 106virus-checking software 69Vital Business Functions (VBFs) 61, 65

identification, Availability Management 61VOI see Value on Investment (VOI)VPN (Virtual Private Network) connections 106

Warranty 28web support services 7Workaround 102, 102 (Fig), 104Work Instruction 101, 105, 150Workload 50, 57, 113, 119, 137

analysis 58

238 | Index
