ITIL Book From IBM, IT Service Management

IT Infrastructure Library (ITIL) Foundations v3
Students Training Guide

S150-3100-00
April 2009
Copyright Notice
Copyright 2009 IBM Corporation, including this documentation and all software. All rights
reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement.
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system,
or translated into any computer language, in any form or by any means, electronic, mechanical,
magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any
machine-readable documentation for your own use, provided that each such reproduction shall carry
the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished as
is without warranty of any kind. All warranties on this document are hereby disclaimed, including the
warranties of merchantability and fitness for a particular purpose.
Note to U.S. Government UsersDocumentation related to restricted rightsUse, duplication or
disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.
Trademarks
The following are trademarks of IBM Corporation or Tivoli Systems Inc.: IBM, Tivoli, AIX, Cross-Site,
NetView, OS/2, Planet Tivoli, RS/6000, Tivoli Certified, Tivoli Enterprise, Tivoli Ready, TME. In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli A/S.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in
the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States,
other countries, or both.
Lotus is a registered trademark of Lotus Development Corporation.
PC Direct is a trademark of Ziff Communications Company in the United States, other countries, or
both and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks of Intel Corporation in the
United States, other countries, or both.
SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. For further information, see http://www.setco.org/aboutmark.html.
Other company, product, and service names may be trademarks or service marks of others.
Notices
References in this publication to Tivoli Systems or IBM products, programs, or services do not imply
that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to
these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can
be used instead of the referenced product, program, or service. The evaluation and verification of
operation in conjunction with other products, except those expressly designated by Tivoli Systems or
IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent
applications covering subject matter in this document. The furnishing of this document does not give
you any license to these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.
Printed in Ireland.
Table of Contents
Table of Contents
Preface
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV
IBM Tivoli Technical Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV
Tivoli User Group Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
Course Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
Course Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
Product Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
Unit 1: ITIL Overview

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Lesson 1: History of ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

History of ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Information Technology Infrastructure Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Contents of the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Components of the ITIL Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
ITIL Version 3 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Summary of the Service Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
ITIL Qualifications Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Lesson 2: Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-13

Service Management as a Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Lesson 3: Process and Service Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-17

Process Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Service Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Lesson 4: Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-20

Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Characteristics of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generic Process Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Elements for ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ITIL Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-21
1-22
1-23
1-24
1-25
1-26
Lesson 5: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-27

Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Lesson 6: Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-29

Roles Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Lesson 7: Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-31

Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Phases of Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33
Lesson 8: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-34

Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Copyright IBM Corp. 2009
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Table of Contents
Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Unit 2: Service Strategy

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Lesson 1: Service Strategy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3

Service Strategy Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Purpose of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Service Strategy Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Service Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Elements of Value: Utility and Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
The Four Ps of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Service Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Lesson 2: Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Service Providers 2-14
Internal Service Provider (Type I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Internal Service Provider (Type I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Shared Services Provider (Type II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Shared Services Provider (Type II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Shared Services Provider (Type III) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Shared Services Provider (Type III) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Choosing Service Provider Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Sourcing Approaches and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Lesson 3: The Process of Strategy Generation . . . . . . . . . . . . . . . . . . . . . . .2-25

Strategy Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Main Activities of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Market: Market Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Expansion, Growth, and Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Develop the Offerings and Strategic Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Increasing Service and Performance Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strategic Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strategy Generation, Evaluation, and Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Measurement and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strategy Generation Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Steering Group (ISG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements Requester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Design Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-26
2-27
2-28
2-30
2-32
2-34
2-36
2-37
2-38
2-39
2-40
2-41
2-41
2-41
2-41
2-42
2-42
Lesson 4: The Process of Service Portfolio Management . . . . . . . . . . . . . . .2-43

Service Portfolio Management (SPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Portfolio Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Portfolio Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Portfolio Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Portfolio Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Portfolio Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Portfolio Process Manager (Service Portfolio Manager) . . . . . . . . . . . . . . . . . . . .
II
2-44
2-45
2-47
2-48
2-49
2-49
2-50
2-50
2-50
2-51
2-51
Table of Contents
Service Portfolio Process Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51

Service Portfolio Management Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51
Service Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52
Lesson 5: The Process of Financial Management . . . . . . . . . . . . . . . . . . . . .2-53

Financial Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Financial Management Goals and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Financial Management Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Financial Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Financial Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Valuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demand Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Provisioning and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning Confidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Investment Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Variable Cost Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Financial Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Financial Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Financial Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-54
2-55
2-56
2-57
2-58
2-59
2-61
2-62
2-63
2-64
2-64
2-65
2-65
2-65
2-65
2-66
2-66
2-67
2-68
2-68
2-68
Lesson 6: The Process of Demand Management . . . . . . . . . . . . . . . . . . . . .2-69

Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activity-based Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demand Management Goal and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demand Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Demand Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-70
2-71
2-72
2-73
2-74

Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-78
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79
Unit 3: Service Design

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Lesson 1: Service Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

Service Design Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Five Major Aspects of Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Service Management: The 4 Ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Service Design Package (SDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Contents of SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
The RACI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
RACI-VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Technology Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Lesson 2: Process of Service Catalog Management . . . . . . . . . . . . . . . . . . .3-16

Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Catalog Management Goal and Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Catalog Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Catalog Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-17
3-19
3-20
3-21
III
Table of Contents
Service Catalog Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Service Catalog Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Catalog Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SCM Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Catalog Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-22
3-23
3-25
3-26
3-28
Lesson 3: Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29

Service Level Management (SLM) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Level Agreements, Operational Level Agreements, and Underpinning Contracts . . .
Service Level Agreements, Operational Level Agreements, and Underpinning Contracts . . .
Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operational Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Underpinning Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Level Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SLM Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SLM Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SLM Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Level Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Level Management Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Level Management Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SLM: Key Performance Indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SLM Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Level Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-30
3-32
3-33
3-34
3-36
3-37
3-38
3-39
3-40
3-41
3-42
3-44
3-45
3-47
3-49
3-51
Lesson 4: Process of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . .3-52

Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purpose and Goals of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Benefits of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modeling and Trending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Baselining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trend Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analytical Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capacity Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . .
Capacity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-53
3-54
3-56
3-57
3-58
3-60
3-60
3-60
3-61
3-61
3-61
3-62
3-63
3-64
3-65
3-67
Lesson 5: Process of Availability Management . . . . . . . . . . . . . . . . . . . . . . .3-68

Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability, Reliability, Maintainability, and Serviceability . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Proactive Versus Reactive Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Availability Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IV
3-69
3-71
3-72
3-73
3-75
3-76
3-77
3-78
3-79
3-80
3-81
3-82
3-83
3-84
3-85
3-86
3-87
Table of Contents
Availability Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . 3-89

Availability Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91
Lesson 6: Process of IT Service Continuity Management . . . . . . . . . . . . . . .3-92

IT Service Continuity Management Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93
ITSCM Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94
IT Service Continuity Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95
ITSCM Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96
ITSCM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99
ITSCM Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101
ITSCM Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102
ITSCM KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-103
ITSCM Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-105
Service Continuity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-107
Lesson 7: Process of Information Security Management . . . . . . . . . . . . . . .3-109

Information Security Management (ISM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents of the Information Security Policy (ITP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management Goal and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information Security Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISM Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-110
3-111
3-112
3-114
3-115
3-116
3-117
3-118
3-120
3-121
3-122
3-123
3-125
Lesson 8: Process of Supplier Management . . . . . . . . . . . . . . . . . . . . . . . .3-126

Supplier Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Goal and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplier Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . .
Supplier Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-127
3-128
3-129
3-130
3-131
3-133
3-135
3-136
3-137
3-138
3-140
Lesson 9: Service Design Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-142

IT Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143
Service Design Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-144
Lesson 10: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-146

Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148
Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154
Unit 4: Service Transition

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Lesson 1: Service Transition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

Service Transition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Service Transition Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Value of Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Table of Contents
Service Knowledge Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

SKMS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Service Transition Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Service Transition Lifecycle Stages Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Technology Considerations for Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Knowledge Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Configuration Management System (CMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Lesson 2: Process of Transition Planning and Support . . . . . . . . . . . . . . . . .4-14

Transition Planning and Support Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Transition Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Define Transition Strategy and Lifecycle Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prepare for Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Plan and Coordinate Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Planning and Support Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-15
4-16
4-17
4-18
4-20
4-21
4-21
4-22
4-22
4-24
4-25
4-26
Lesson 3: Process of Change Management . . . . . . . . . . . . . . . . . . . . . . . . .4-28

Change Management Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Types: Normal Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Types: Standard Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Types: Emergency Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Seven Rs of Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Policies Supporting Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Management Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Advisory Board (CAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-29
4-30
4-31
4-32
4-33
4-34
4-36
4-37
4-38
4-39
4-41
4-42
4-43
4-44
4-46
4-48
4-50
4-52
4-53
Lesson 4: Process of Service Asset and Configuration Management . . . . . .4-54

Service Asset and Configuration Management Purpose and Goal . . . . . . . . . . . . . . . . . . . . .
SACM, the Logical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definitive Media Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SACM Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SACM Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SACM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SACM Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SACM Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Asset Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Administrator or Librarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
4-55
4-57
4-58
4-59
4-61
4-62
4-63
4-64
4-65
4-67
4-68
4-69
4-70
4-71
4-72
4-73
Table of Contents
Lesson 5: Process of Release and Deployment Management . . . . . . . . . . . .4-74

Release and Deployment Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release and Deployment Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Factors to Consider for Release Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release and Deployment Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release and Deployment Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service V Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release and Deployment Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . .
Release and Deployment Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release and Deployment Management Challenges, Success Factors, and Risks . . . . . . . . .
Release Packaging and Build Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-75
4-76
4-77
4-78
4-79
4-80
4-82
4-83
4-85
4-86
4-88
4-90
Lesson 6: Process of Service Validation and Testing . . . . . . . . . . . . . . . . . .4-91

Service Validation and Testing Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-92
Objectives of Service Validation and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-93
Service Validation and Testing Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-94
Service Validation and Testing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-95
Service Validation and Testing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-97
Service Validation and Testing Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-98
Service Validation and Testing KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-99
Service Validation and Testing Challenges, Critical Success Factors, and Risks . . . . . . . . . 4-100
Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-102
Lesson 7: Process of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-103

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance and Risk Evaluation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-104
4-105
4-106
4-107
4-108
4-109
4-110
4-111
Lesson 8: Process of Knowledge Management . . . . . . . . . . . . . . . . . . . . . .4-112

Knowledge Management Purpose and Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DIKW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transition Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Management Process Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-113
4-114
4-115
4-116
4-117
4-120
4-120
4-120
4-121
4-122
4-123
Lesson 9: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-124

Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-130
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-132
Unit 5: Service Operation

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Lesson 1: Service Operation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3

Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
VII
Table of Contents
Service Operation Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Service Operation Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Service Operation Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Conflicting Motives in Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
External View of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Internal View of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Stability Versus Responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Balancing Service Cost and Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Service Operation: Reactive versus Proactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Communication in Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Technology Considerations for Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Technology for Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Technology for Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Technology Tools for Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Technology Tools for Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Technology Tools for Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Technology Tools for Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Lesson 2: Process of Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18

Event Management Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . .
Event Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-19
5-21
5-23
5-24
5-26
5-28
5-29
5-31
Lesson 3: Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-32

Incidents Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Time Scales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Major Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Role of Problem Management in Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Urgency, Impact, and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagnosis and Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functional Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hierarchic Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Resolution, Recovery, and Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incident Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . .
Incident Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-33
5-34
5-35
5-36
5-36
5-36
5-37
5-37
5-38
5-40
5-41
5-42
5-44
5-45
5-46
5-47
5-49
5-49
5-50
5-51
5-53
5-55
5-57
5-59
5-60
Lesson 4: Process of Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . .5-61

Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Request Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Request Fulfillment Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Request Fulfillment Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VIII
5-62
5-64
5-65
5-66
Table of Contents
Request Fulfillment Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Request Fulfillment Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Request Fulfillment Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Request Fulfillment KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Request Fulfillment Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . .
Request Fulfillment Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-67
5-68
5-69
5-71
5-72
5-74
Lesson 5: Process of Problem Management . . . . . . . . . . . . . . . . . . . . . . . . .5-75

Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workaround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Known Error Data Base (KEDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reactive versus Proactive Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Management Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problem Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-76
5-78
5-80
5-81
5-82
5-83
5-84
5-85
5-86
5-88
5-90
5-91
5-92
Lesson 6: Process of Access Management . . . . . . . . . . . . . . . . . . . . . . . . . .5-93

Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94
Access Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-95
Access Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-96
Access Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-97
Access Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-98
Access Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-100
Access Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-102
Access Management Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-103
Access Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-104
Lesson 7: The Service Desk Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-105

Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Desk Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Service Desk Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Desk Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Centralized Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Follow-the-Sun Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Desk Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Desk Staffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Desk Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-106
5-108
5-109
5-110
5-110
5-110
5-111
5-111
5-112
5-113
5-115
Lesson 8: Technical Management, Applications Management, and Operations

Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-116
Technical Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Technical Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-117
5-118
5-119
5-121
5-122
5-123
Lesson 9: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-124

Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-130
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132
IX
Table of Contents
Unit 6: Continual Service Improvement

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Lesson 1: Continual Service Improvement Overview . . . . . . . . . . . . . . . . . . . .6-3

Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Continual Service Improvement (CSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
CSI Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Benefits of Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Business and Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Financial Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
IT Organization Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
CSI Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Metrics and Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
CSI Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Continual Service Improvement Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
The Deming Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
The Deming Cycle and CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
The Deming Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
CSI: Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Technology Considerations for CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Lesson 2: The 7-Step Improvement Process . . . . . . . . . . . . . . . . . . . . . . . . .6-21

The 7-Step Improvement Process Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-Step Improvement Process Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CSI Critical Success Factors and KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-Step Improvement Process Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-22
6-24
6-26
6-27
Lesson 3: Process of Service Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-29

Aspects of Service Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementing Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Content and Audience Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Reporting Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Reporting Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reporting Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-30
6-31
6-32
6-33
6-34
6-35
Lesson 4: Process of Service Measurement . . . . . . . . . . . . . . . . . . . . . . . . .6-36

Service Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Measurements for CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Measurement Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Measurement Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-37
6-38
6-39
6-40
6-41
6-42
Lesson 5: Process of Creating a Return on Investment . . . . . . . . . . . . . . . . .6-45

Return on Investment for CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46
Return on Investment Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Lesson 6: Continual Service Improvement Roles . . . . . . . . . . . . . . . . . . . . . .6-49

Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50
Continual Service Improvement Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51

Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.........................................................................
Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-53
6-55
6-56
6-57
Table of Contents
Appendix A: ITIL Glossary

ITIL V3 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Appendix B: ITIL V3 Practice Examination

Practice Examination Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
Tivoli Professional Certification

Special Offer for Having Taken This Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Reasons for Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Role-based Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
When to Attempt a Certification Exam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
Location and Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
Sources of Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
XI
Table of Contents
XII
Preface
Student Guide
20 08 IBM Corporation
XIII
Preface
Course Description
This course presents the basic concepts in ITIL Service Management. The course is
designed to prepare the student for a the ITIL Foundation certificate in IT Service
Management.
The purpose of the ITIL Foundation certificate in IT Service Management is to obtain
knowledge of the ITIL terminology, structure, and basic concepts and to comprehend the
core principles of ITIL practices for Service Management.
The ITIL Foundation certificate in IT Service Management is not intended to enable the
holders of the certificate to apply the ITIL practices for Service Management
independently.
Audience
The target group of the ITIL Foundation certificate in IT Service Management is:
Individuals who require a basic understanding of the ITIL framework and how it
may be used to enhance the quality of IT service management within an
organization.
IT professionals who are working within an organization that has adopted and
adapted ITIL and who need to be informed about and thereafter contribute to an
ongoing service improvement program.
The target group may include, but is not limited to, IT professionals, business managers,
and business process owners.
IBM Tivoli Technical Education

The latest information about IBM Tivoli education offerings can be found online at:
http://www.ibm.com/software/tivoli/education/
Also, if you have any questions about education offerings, send an e-mail to the appropriate
alias for your region:
XIV
Americas: tivamedu@us.ibm.com
Asia Pacific: tivtrainingap@au1.ibm.com
EMEA: tived@uk.ibm.com
Preface
Tivoli User Group Community

You can get even more out of Tivoli software by joining and participating in one of the 91
independently run Tivoli User Groups around the world. Learn about online and in-person
Tivoli User Group opportunities near you at www.tivoli-ug.org.
Course Objectives
IBM Software Group | Tivoli software
Course Objectives
Upon completion of this course, you will be able to:
Define ITIL terminology, structure, and basic concepts including:

ITIL Service Strategy
ITIL Service Design
ITIL Service Transition
ITIL Service Operation
ITIL Continual Service Improvement
Explain the core principles of ITIL practices for Service Management

Describe the ITIL management framework
Successfully complete the ITIL Foundations Practice Certification
Exam in preparation for ITIL Foundations Certification Exam
Course Outline
The following outline is a high-level description of the contents of this course. Each unit
has an overview presentation, and most have a series of student exercises designed to
reinforce the concepts presented. The course contains the following units:

This unit defines service and explains the concept of Service Management as a
practice.
XV
Preface

In this Unit, you will learn more about Service Strategy.

In this unit, you will learn about Service Design.

In this unit, you will learn about Service Transition.

In this unit, you will learn about Service Operation.

In this unit, you will learn about Continual Service Improvement.
XVI
Preface
Typographical Conventions
In this course, the following typographical conventions are used.
Convention
Usage
Bold
Commands, keywords, file names, authorization roles,

URLs, or other information that you must use literally
appear in bold.
Italics
Variables and values that you must provide appear in

italics. Words and phrases that are emphasized also
appear in italics.
Bold Italics
New terms appear in bold italics when they are

defined in the text.
Monospace
Code examples, output, and system messages appear

in a monospace font.
>
In this manual, the arrow character is used as a path

arrow. The arrow indicates the path to the named
window.
Product Information
Product Documentation
In some cases IBM Tivoli product documentation is available in the classroom or on the
Instructor Resources CD. For access to documentation outside the classroom environment,
visit the IBM Web site.
XVII
Preface
XVIII
Unit 1: Information Technology

Infrastructure Library (ITIL) Overview
1-1
Introduction
This unit defines service and explains the concept of Service Management as a practice.
Objectives
Objectives
Upon completion of this unit, you will be able to:
Define and explain the concept of a service
Define and explain the concept of Service Management
Define and distinguish between functions, roles, and
processes
List the characteristics of processes
Explain the process model
Explain the Service Lifecycle
1-2

History of ITIL
Lesson 1: History of ITIL
Lesson 1: History of ITIL
1-3

History of ITIL
History of ITIL
History of ITIL
Developed in the United Kingdom in the 1980s by what is
now called the Office of Government Commerce (OGC)
Further development incorporated public and private
sector best practices (IBM, Microsoft, HP, and others)
ITIL promotes a quality approach to achieving business efficiency and effectiveness in the
use of information systems. ITIL best practices are applicable to all IT organizations, no
matter what their size or what technology they use. Today, ITIL is one of the most widely
accepted approaches to IT Service Management in the world.
Information Technology Infrastructure Library (ITIL) Version 1 contained over 40 books,
which were consolidated into seven books between 1999 and 2006 in ITIL Version 2. ITIL
Version 3 currently consists of five core books. ITIL V3 builds upon ITIL V2 but focuses
on the lifecycle of a service that should be aligned to business needs.
1-4

History of ITIL
Information Technology Infrastructure Library

Information Technology Infrastructure Library

A set of books that describe internationally accepted best
practices for IT infrastructure management
A process-based approach to IT infrastructure
management
A common language for IT management
A framework that is independent of organizational
structures, architectures, or technologies
Each book addresses capabilities having direct impact on the performance of a service
provider.
The structure of the ITIL core is in the form of a lifecycle.
The ITIL core is expected to provide structure, stability, and strength to service
management capabilities with durable principles, methods, and tools.
The best practices guidance in ITIL can be adapted for changes used in various business
environments and organizational strategies.
1-5

History of ITIL
Contents of the Library

Contents of the Library

The five volumes that make up the ITIL lifecycle are:
ITIL Service Strategy
ITIL Service Design
ITIL Service Transition
ITIL Service Operation
ITIL Continual Service Improvement
The ITIL library is a set of books that describe internationally accepted best practices for
IT Service Management, including these practices:
1-6
A process-based approach to IT Service Management
A common language for IT Service Management
A framework that is independent of organizational structures, architectures, or

technologies

History of ITIL
Components of the ITIL Library

Components of the ITIL Library

The ITIL Library has the following components:
The ITIL Core: Best practice guidance applicable to all
types of organizations who provide services to a
business
The ITIL Complementary Guidance: A complementary
set of publications with guidance to specific to industry
sectors, organization types, operating models, and
technology architectures
ITIL promotes a quality approach to achieving business efficiency and effectiveness in the
use of information systems. ITIL best practices are applicable to all IT organizations, no
matter what their size or what technology they use. ITIL is one of the most widely accepted
approaches to IT Service Management in the world.
1-7

History of ITIL
ITIL Version 3 Framework
The ITIL Core documents form the Service Lifecycle. Each publication addresses
capabilities that have direct effect on the performance of a service provider. The ITIL core
is expected to provide structure, stability, and strength to Service Management capabilities
with durable principles, methods, and tools.
The ITIL Lifecycle serves to protect investments and provide the necessary basis for
measurement, learning, and improvement.
1-8

History of ITIL
Summary of the Service Lifecycle

Summary of the Service Lifecycle

The Service Lifecycle contains the elements of:
Strategy
Design
Transition
Operation
Improvement
Strategy
Determine requirements from the business
Design (Overlaps with Strategy)
Design service
Consider warranty attributes (such as availability and capacity)
Create service through development and integration
Transition
Test service
Coordinate Request for Changes (RFCs) to put service into production
Deploy release
Run service pilots
1-9

History of ITIL
Operation (Overlaps with Transition)

Operate and monitor service
Support service
Manage requests
Improvement (Overlaps with Transition and Operation)
1-10
Report service metrics
Identify ROI
Improve services

History of ITIL
ITIL Qualifications Scheme

ITIL Qualifications Scheme

Four Levels:
Foundation Level
Intermediate Level (Lifecycle Stream and Capability Stream)
ITIL Expert
ITIL Master
10
The ITIL Qualification Scheme gives credits for each exam taken. Candidates who have
accumulated a sufficient number of credits can achieve the ITIL Expert in IT Service
Management.Foundation Level.
The Foundation level focuses on knowledge and comprehension to provide a good
grounding in the key concept, terminology, and processes of ITIL.
There are two streams in the Intermediate Level. Both assess your ability to analyze and
apply the concepts of ITIL. Candidates can take units from either of the Intermediate
streams to gain credits towards the Expert Level. The two streams are the Intermediate
Lifecycle Stream and the Intermediate Capability Stream.
The Intermediate Lifecycle Stream includes five individual certificates built around the
following books:
Service Strategy
Service Design
Service Transition
Service Operation
Continual Service Improvement
1-11

History of ITIL
The focus of these modules is on the introduction and implementation of the specific
Lifecycle phase in addition to coverage of the principles, processes, and related activities.
The Intermediate Capability Stream includes four individual certificates loosely based
on the V2 Clustered Practitioner qualifications, but broader in scope in line with the
updated V3 content. It focuses on detailed process implementation and management within
the following cluster groupings:
Operational Support and Analysis: Event, Incident, Request, Problem, Access,

Service Desk, Technical, IT Operations, and Application Management
Service Offerings and Agreements: Portfolio, Service Level, Service Catalog,

Demand, Supplier, and Financial Management
Release, Control and Validation: Change, Release and Deployment, Validation

and Testing, Service Asset and Configuration, Knowledge, Request Management,
and Service Evaluation
Planning, Protection, and Optimization: Capacity, Availability, Continuity,

Security, Demand, and Risk Management.
The ITIL Expert Level in IT Service Management requires successful completion of a

number of Intermediate units in addition to the mandatory Foundation Level and the
Managing Across the Lifecycle capstone course. This course brings together the full
essence of a Lifecycle approach to Service Management and consolidates the knowledge
gained across the qualification scheme.
The ITIL Master Level of the qualification asseses your ability to apply and analyze the
ITIL concepts in new areas. This higher level qualification is currently under development.
The ITIL Managers Bridge certification is for individuals who already have the Managers
Certificate in IT Service Management in an earlier ITIL version, and want to earn the ITIL
Expert in IT Service Management to demonstrate their knowledge of ITIL V3.
1-12

Services
Lesson 2: Services
Lesson 2: Services
1-13

Services
Service Management as a Practice

Service Management as a Practice

ITIL used worldwide to establish and improve capabilities
in Service Management
The wide adoption of good practices in industry is
advantageous because organizations can compare
themselves to peers and close gaps in capabilities and
performance
Sources for good practices include:
Public frameworks
Standards
Proprietary knowledge of organizations and individuals
12
Service Management is defined as a set of specialized organizational capabilities for

providing value to customers in the form of services. The ability to provide these services
is achieved by using the functions and processes for managing services throughout a
lifecycle. Service Management uses specializations in strategy, design, transition,
operation, and continual improvement. At the heart of Service Management, is the ability
to convert resources into critical services. Without Service Management, a service
organization can not be effective.
The ITIL Framework is a source of good practice in Service Management. ITIL is used by
organizations worldwide to establish and improve capabilities in Service Management.
Proprietary knowledge is customized, difficult to obtain access to, and deeply embedded in
an organization. Therefore, it is often preferable to use proven public frameworks and
standards. The ITIL Core provides best practice guidance applicable to all types of
organizations who provide services to a business.
1-14

Services
Services
Services
Service is a way to deliver value to customers by helping
them obtain goals without their ownership of specific
costs and risks
Deliver value to customers
Facilitate outcomes
Result in an increase in the probability of expected
outcome
13
Services deliver value to customers by giving customers what they want without the
ownership of specific costs and risks.
Services facilitate outcomes by enhancing the performance of associated tasks and
reducing the effect of constraints.
1-15

Services
Service Management
Service Management
A set of specialized organizational capabilities that take
the form of:
Processes
Functions
Roles
The core of service management is the act of

transforming resources into valuable services
14
The organizational capabilities of Service Management provide value to customers in the

form of services.
These organizational capabilities are functions and processes for managing services
throughout a lifecycle. They are specialized in strategy, design, transition, operation, and
continual improvement.
The capabilities represent the capacity, competency, and confidence for action of the
service organization.
Without these capabilities, a service organization is merely a bundle of resources that by
itself has relatively low intrinsic value for customers.
1-16

Process and Service Owners
Lesson 3: Process and Service Owners
Lesson 3: Process and Service Owners
1-17

Process Owners
Process Owners
Responsible for ensuring that their processes are
performed according to the agreed-upon and documented
process
Must ensure that the processes meet the aims of their
definitions
16
Duties of Process Owners include the following tasks:
1-18
Documenting and publicizing the process.
Defining the Key Performance Indicators (KPIs) to evaluate the effectiveness and
efficiency of the process.
Reviewing KPIs and taking action required following the analysis.
Improving the effectiveness and efficiency of the process.
Ensuring all relevant staff have the required training in the process and are aware
of their role in the process.
Interacting with line management to ensure that the process receives the needed
staff resources. Line management and Process Owners have complementary tasks.
They must work together to ensure efficient and effective processes. Often line
management ensures the required training of staff.

Service Owners
Service Owners
The Service Owner is responsible to the customer for the
initiation, transition, and ongoing maintenance and
support of a particular service.
17
The Service Owner has the following responsibilities:
Act as primary customer contact for all service-related enquiries and issues.
Ensure that the ongoing service delivery and support meet agreed-upon customer
requirements.
Identify opportunities for service improvements, discuss them with the customer,
and raise the RFC for assessment, if appropriate.
Interact with the appropriate Process Owners throughout the Service Management
Lifecycle.
Solicit required data, statistics, and reports to analyze and to facilitate effective
service monitoring and performance.
Will be accountable to the IT Director for the delivery of the service.
1-19

Processes
Lesson 4: Processes
Lesson 4: Processes
1-20

Processes
Processes
Processes
A structured set of activities designed to accomplish a
specific objective
A process takes one or more inputs and turns them into
defined outputs
A process includes all of the roles, responsibilities, tools,
and management controls required to reliably deliver the
outputs
19
Processes should be defined, documented, and controlled. After they are under control, they
can be repeated, and they become manageable.
Processes are closed-loop systems because they have the following characteristics:
Provide change and transformation toward a goal
Use feedback for self-reinforcing and self-corrective action
It is important to consider the entire process and how one process fits into another.
1-21

Processes
Characteristics of Processes
Characteristics of Processes
Measurable
Specific results
Respond to a specific event or are triggered at specific
times
Deliver its primary results to a customer or stakeholder
20
Processes are measurable and driven by performance. Managers want to measure cost,
quality, and other factors. Practitioners are concerned with duration and productivity.
The reason a process exists is to deliver a specific result. This result must be individually
identifiable and countable. For example, changes can be counted, but it is impossible to
count how many Service Desks were completed.
Every process delivers a primary result to a customer or stakeholder.
A process can be ongoing or iterative, and it should be traceable to a specific trigger.
Functions are often mistaken for processes.
1-22

Processes
Generic Process Elements

Generic Process Elements

Defines how data enters the process
Defines how the data is processed
Defines the output, which is driven by objectives
Measures and reviews the outcome using metrics,
reports, and process improvement
21
Each process should have an owner who is responsible for:
Maintaining the process
Improving the process
Ensuring that the process meets the objectives set for it
The objectives of any IT process should be defined in measurable terms. They should also
be expressed in terms of business benefits and underpinning business strategy and goals.
Service Design should assist each process owner to ensure the following objectives:
All processes use standard terms and templates.
All processes are consistent.
All processes integrate with each other to provide end-to-end integration across all
areas.
If the activities of the process occur with a minimum use of resources, the process is
considered efficient. Process analysis, results, and metrics should be incorporated in regular
management reports and process improvements.
1-23

Processes
Process Elements for ITIL
Data enters the process, is processed, and produces output. The outcome is measured and
reviewed.
A process is always organized around a set of objectives. The main outputs from the process
should be driven by the objectives and should always include process measurements
(metrics), reports, and process improvement.
1-24

Processes
ITIL Processes
ITIL Processes
Version 3 ITIL books focus on the following items:
Sets of processes
The lifecycle of a service
Working with defined processes is the foundation of ITIL
23
It is possible to work more efficiently and effectively by:
Defining the activities of an organization, the necessary inputs
Defining the outputs that will result from the process
Measuring and steering the activities increases this effectiveness.

By adding norms to the process, it is possible to add quality measures to the output.
1-25

Processes
The Process Model

The Process Model

A process model enables understanding and helps to
articulate the distinctive features of a process
Process control can be defined as the activity of planning
and regulating a process, with the objective of performing
a process in an effective, efficient, and consistent manner
24
Degrees of control over processes can be defined. Then, process measurement and metrics
can be built into the process to control and improve it.
1-26

Functions
Lesson 5: Functions
Lesson 5: Functions
1-27

Functions
Functions
Functions
General units of organizations
Specialized to perform certain type work
Responsible for specific outcomes
Self-contained
Capabilities
Resources necessary for performance and outcomes
26
Capabilities include work methods that are internal to the functions. Sample functions
include Technical Management and the Service Desk. These functional units facilitate
multiple processes.
Functions have their own body of knowledge, which is accumulated from experience of the
functional organization.
Functions provide structure and stability to organizations.
1-28

Roles
Lesson 6: Roles
Lesson 6: Roles
1-29

Roles
Roles Defined
Roles
A role refers to a set of connected behaviors or actions
that are performed by a person, team, or group in a
specific context
The scope of their roles, and what triggers them to play
those roles, are defined by the relevant process and
agreed to by their line manager
28
A technical management department can perform the role of Problem Management when
diagnosing the root cause of incidents. This same department could also function in other
roles at different times. For example, they may assess the impact of changes (Change
Management role) or manage the performance of devices under their control (Capacity
Management role).
1-30

Risk
Lesson 7: Risk
Lesson 7: Risk
1-31

Risk
Risk
Risk
Risk is the uncertainty of outcome, whether positive
opportunity or negative threat
Managing risks requires:
Identification of the risk
Control of the exposure to risk, which can affect the
achievement of the business objectives of an
organization
30
The aim is to support better decision-making through a good understanding of risks and
their likely impact.
1-32

Risk
Phases of Risk
Phases of Risk
The two phases of risk include:
1. Risk Analysis
2. Risk Management
31
Risk Analysis is concerned with gathering information about exposure to risk so that the
organization can make appropriate decisions and manage risk appropriately.
Risk Management involves making the following plans:
Having processes in place to monitor risks
Having access to reliable and up-to-date information about risks
Having the right balance of control in place to deal with those risks
Having decision-making processes supported by a framework of risk analysis and

evaluation
1-33

Unit Scenario
Lesson 8: Unit Scenario

Company X wants to create a service catalog. Every organization catalog can be different,
but there are a few common services that a company might start with.
One of these might be requesting access to applications and or systems. Another might be
requesting a project or enhancement to applications maintained by internal or external
development teams.
With v3 ITIL, defining a service is handled through the Service Design, then Transition,
and finally with Services Operations.
The services (Services Catalog) are managed with the Service Management process. The
Business Relationship Manager is the role that assists the business in determining the
services offerings required to meet customer demands.
The output to the service catalog management process is the Service Catalog. It is critical
that the organization make sure the user interface to the service is easy to use. Such an
interface will increase customer receptiveness and lessen usability issues. In addition,
service should be tested to make certain the operations in the back end fulfillment process
are scalable for the volume of requests. These operational processes can be further
researched in the V3 Service Operations book.
The organization develops a business case for every service within the Service Strategy. It
starts by collecting information from all existing services as well as every proposed service.
It then determines the required investment in terms of potential benefits. In addition, it will
define the resources and capabilities required for provisioning and maintaining each
service. During this process, it will be important to consider the constituencies: users, IT
operations, finance leaders, and business leaders.
Service Catalog should be integrated with Request Fulfillment because it can be the
backbone of the organization. In addition, it can be the primary means for business to
interact with and request services from IT.
The catalog is defined within the structure of ITIL of Service Strategy, Design, Transition
and then Operations lifecycle. An individual service life cycle begins with the Service
Pipeline, then is live or available for service, and is finally retired.
1-34

Unit Scenario
Review Questions
1.
2.
Which of the following choices is a way to deliver value to customers by helping

customers obtain their goals without the ownership of specific costs and risks?
a.
Risk management
b.
Service management
c.
Process management
d.
Operation management
Which of the following choices is true about the Process Model?

a.Defines how data enters the process and is processed
3.
b.
Defines the output
c.
Measures and reviews the outcome
d.
All of the above
Which of the following choices is not a characteristic of processes?

a.Measurable
4.
b.
Specific results
c.
Customers
d.
Does not respond to specific events
A set of specialized organizational capabilities for providing value to customers in

the form of services describes which of the following choices?
a.Service Design
5.
b.
c.
Service Management
d.
Service Operation
How do services deliver value to customers?

a.By introducing new products so that customers often have an option to upgrade
b.
By reducing cost for the customers so they will pay less for the same product
c.
By giving customers what they want without the ownership of specific costs
and risks
1-35

Unit Scenario
d.
6.
By making the products of better quality and testing them more rigorously
Which of the following choices is a structured set of activities designed to

accomplish a specific objective?
a.Element
7.
b.
Process
c.
Function
d.
Role
Which of the following choices are general units of organizations specialized to

perform certain types of work?
a.Element
8.
b.
Process
c.
Function
d.
Role
Which of the following choices is a set of connected behaviors or actions that are
performed by a person, team, or group in a specific context?
a.Element
1-36
b.
Process
c.
Function
d.
Role

Unit Scenario
1-37

Unit Scenario
Review Answers
1.
Which of the following choices is a way to deliver value to customers by helping

customers obtain their goals without the ownership of specific costs and risks?
b. Service management
2.
Which of the following choices is true about the Process Model?

d. All of the above
3.
Which of the following choices is not a characteristic of processes?

d. Does not respond to specific events
4.
A set of specialized organizational capabilities for providing value to customers in

the form of services describes which of the following choices?
c. Service Management
5.
How do services deliver value to customers?

c. By giving customers what they want without the ownership of specific costs and
risks
6.
Which of the following choices is a structured set of activities designed to

accomplish a specific objective?
b. Process
7.
Which of the following choices are general units of organizations specialized to

perform certain types of work?
c. Function
8.
Which of the following choices is a set of connected behaviors or actions that are
performed by a person, team, or group in a specific context?
d. Role
1-38

Unit Scenario
Summary
Summary
You should now be able to:
Define and explain the concept of a service
Define and explain the concept of Service Management
Define and distinguish between functions, roles, and
processes
List the characteristics of processes
Explain the process model
Explain the Service Lifecycle
33
1-39

Unit Scenario
1-40
2-1
Introduction
In this Unit, you will learn more about Service Strategy.
Objectives
Objectives
Explain the purpose of Service Strategy
Explain the two elements of value: utility and warranty
Describe the three types of service providers
Explain how to choose between service provider types
Describe the key principles of Service Strategy
Discuss the main Service Strategy processes and
associated activities
2-2

Service Strategy Overview
Lesson 1: Service Strategy Overview
Lesson 1: Service Strategy Overview
2-3

Service Strategy Defined

Service Strategy Defined
Service Strategy is a strategic plan designed to

achieve defined objectives
The Service Strategy defines a clear path to delivering

value to the customer
A healthy business model will describe the defined objectives of the business. A clear
strategy for accomplishing the objectives must be clearly stated to the customer. Otherwise,
the customer will not recognize the increase in value. The Service Strategy defines a clear
path to delivering value to the customer.
Customers are looking for ways to strategically improve their business models. They want
solutions that will break through existing performance barriers. They want to increase
performance without an increase in cost. This kind of improvement provides an opportunity
to offer a solution by providing improved products and services.
2-4

Purpose of Service Strategy

Purpose of Service Strategy

Service providers must have the ability to think and act in
a strategic manner
The achievement of strategic goals or objectives requires
the use of strategic assets
Service Strategy shows how to transform service
management into a strategic asset
Technical knowledge of IT is necessary but not sufficient
Strategy requires knowledge from the disciplines such as
operations management, marketing, finance, information
systems, organizational development, systems dynamics,
and industrial engineering
5
2-5

Service Strategy Objectives

Service Strategy Objectives

Service Strategy seeks to answer the following questions:
What services should we offer and to whom?
How do we differentiate ourselves from competing alternatives?
How do we truly create value for our customers?
How do we capture value for our stakeholders?
How can we make a case for strategic investments?
How can financial management provide visibility and control over value
creation?
How should we define service quality?
How do we choose among different paths for improving service quality?
How do we efficiently allocate resources throughout a portfolio of services?
How do we resolve conflicting demands for shared resources?
6
2-6

Service Model
Service Model
A Service Model performs the following tasks:
Codifies the Service Strategy for a market space
Outlines process and functions needed to create value
Describes how service assets create value for a given
portfolio of contracts
Increases effectiveness in Continual Service
Improvement
Purpose of Service Model:
Define the value to be created in the form of the utility
and the warranty provided to customers.
7
Service Agreements specify the terms and conditions under which such interaction occurs
with commitments and expectations on each side. Interaction means demand connects with
the capacity to serve.
Service Transition evaluates the options or paths for improvements and recommends
solutions that are cost-effective and low risk.
Service Models continually evolve, based on external feedback received from customers
and internal feedback from Service Management processes.
Continual Service Improvement (CSI) processes ensure the feedback to the strategy,
design, transition, and operation processes. Improvements can be made to the structure, the
dynamics of a model, or to both.
2-7

Business Case
Business Case
A business case is a decision support tool and planning
tool that projects the likely consequences of a business
action
The elements of a business case include:
Introduction: Presents business objectives addressed by service
management initiative
Methods and Assumptions: Defines boundaries of business
case, such as time period
Business Impacts: The financial and non-financial business case
results
Risks and Contingencies: The probability that alternative results
will engage
Recommendations: Specific actions recommended
8
The consequences can take on qualitative and quantitative dimensions. A financial

analysis, for example, is frequently central to a good business case.
2-8

Elements of Value: Utility and Warranty

Elements of Value: Utility and Warranty

Utility
Attributes of the service that have a positive effect on
the performance of activities, objects, and tasks
associated with required outcomes
Warranty
The positive effect being available when needed, in
sufficient capacity or magnitude, and dependably
available in terms of continuity and security
Utility is what the customer gets, and warranty is how it is delivered.

Customers cannot benefit from something that is fit for purpose but not fit for use, or vice
versa.
It is useful to separate the logic of utility from the logic of warranty for the purpose of
design, development, and improvement.
Considering all the separate controllable inputs, Service Strategy permits a wide range of
solutions to the problem of creating, maintaining, and increasing value.
2-9

The Four Ps of Service Strategy

The Four Ps of Service Strategy

Perspective: Describes a vision and direction
Position: Describes the decision to adopt a well-defined
stance
Plan: Describes the means of moving from the current
state to a future state
Pattern: Describes a series of consistent decisions and
actions over time
10
After a service provider has a thorough understanding of its service objectives, it is ready
to begin the service lifecycle. The entry points to service strategy are referred to as the Four
Ps. These points identify the different forms a service strategy might take.
A strategic perspective articulates the business philosophy and manner in which services
are provided. CIOs might determine that their businesses most value a certain type of
service provider.
An internal service provider (Type I) restricted to serving one business unit might adopt a
position based on:
2-10
Product knowledge
Customer responsiveness
Value
Cost
Specialized services or broad sets of services

Planning the transition requires answering questions such as:
How can high-value or low-cost services be offered?
How specialized services be offered?
Patterns might be:
A service provider who continually offers specific services with deep expertise is
adopting a high-value or high-end service strategy.
A service provider who continually offers dependable and reliable services is

adopting a high-warranty strategy.
2-11

Service Automation
Service Automation Can

Improve the utility and warranty of services
Improve the quality of service
Reduce costs and reduce risks by reducing complexity and
uncertainty, and by efficiently resolving trade-offs
Handle capacity with fewer restrictions on time of access
Be used to measure the differential impact on service quality
and costs
Handle scheduling, routing, and allocation of resources
Reduce the depreciation of knowledge
11
Automation can have a significant effect on the performance of service assets such as
management, organization, people, process, knowledge, and information.
Service management can benefit from automation in the following areas:
2-12
Design and modeling
Service catalog
Pattern recognition and analysis
Classification, prioritization, and routing
Detection and monitoring
Optimization

Service Providers
Lesson 2: Service Providers
Lesson 2: Service Providers
2-13

Service Providers
Service Providers
Service Providers
Internal Service Provider, Type I
Shared Services Provider, Type II
External Service Provider, Type III
13
There are three types of service providers.
2-14

Service Providers
Internal Service Provider (Type I)
Duplication and waste occur when Type I providers are replicated within the enterprise.
To take advantage of both economy of scale and economy, Type I providers of similar
characteristics are consolidated into a corporate business function.
Internal Service Providers might include functions such as:
Finance
Administration
Logistics
Human resources
IT
2-15

Service Providers


Type I providers are typically business functions
embedded within the business units they serve which
may be part of a larger enterprise or a parent organization
Internal Service Providers provide services required by
the various parts of the business
Type I providers avoid certain costs and risks associated
with conducting business with external parties
15
2-16

Service Providers
Shared Services Provider (Type II)
Shared Service Units (SSUs) can create, grow, and sustain an internal market for their
services and model themselves along the lines of service providers in the open market.
Like corporate business functions, they can use opportunities across the enterprise and
spread their costs and risks across a wider base. However, SSUs have fewer protections in
the areas of strategic value and core competence.
Type II providers benefit from a relatively captive internal market for their services.
However, their customers might still evaluate them in comparison with external service
providers.
Poorly performing Type II providers face the threat of substitution, putting pressure on the
leadership to adopt industry best practices and strive for operational effectiveness.
Industry-leading shared services units have been successfully spun off from their parent
companies as independent businesses competing in the external marketplace.
2-17

Service Providers


Functions such as finance, IT, human resources, and logistics are not
alwa ys at the core of competitive advantage of an organization
Instead, the services of such shared functions are consolidated into
an autonomous special unit called a shared services unit (SSU)
Shared Services Providers are subject to comparisons with external
service providers whose performance they should approximate if not
exceed
Type II can offer lower prices compared to external service providers
by standardizing service offerings across business units and using
market-based pricing to influence demand patterns
17
2-18

Service Providers
Shared Services Provider (Type III)
The experience of Type III providers is not limited to any one enterprise or market.
The breadth and depth of such experience is often the single-most distinctive source of
value for customers.
The breadth comes from serving multiple types of customers or markets.
The depth comes from serving multiples of the same type.
Security is always an issue in shared services environments. When the Type III provider
also provides services to competitors, security becomes a larger concern.
As a counterbalance, Type III providers might reduce systemic risks by transferring them
to external service providers, who spread those risks across a larger value network.
2-19

Service Providers
Shared Services Provider (Type III)

External Service Provider (Type III)

Type III providers can offer competitive prices and drive down unit
costs by consolidating demand
Customers might be motivated to choose a Type III provider because
of access to knowledge, experience, scale, scope, capabilities, and
resources that are either beyond the reach of the organization or
outside the scope of a carefully considered investment portfolio
Business strategies often require reductions in the asset base, fixed
costs, operational risks, or the redeployment of financial assets
Customers who need flexible and lean structures might prefer to buy
services rather than own and operate the assets necessary for
certain business functions and processes
19
2-20

Service Providers
Choosing Service Provider Types

Choosing Service Provider Types

Services may be sourced from each type of service
provider with decisions based on:
Transaction costs
Strategic industry factors
Core competence
Risk management capabilities of the customer
The principles of specialization and coordination costs

apply
20
Examples of transaction costs might include, but are not limited to, the costs of the
following activities:
Finding and selecting qualified providers
Defining requirements
Negotiating agreements
Measuring performance
Managing the relationship with suppliers
Resolving disputes
Making changes or amends to agreements
Some questions an organization might ask when choosing Service Provider Types:
Does the activity require highly specialized assets?
Will they be idle or obsolete if that activity is no longer performed?
How frequently is the activity performed within a period or business cycle? Is it

infrequent or sporadic?
2-21

Service Providers
2-22
How complex is the activity? Is it simple and routine? Is it stable over time with
few changes?
Is it hard to define good performance? Is it hard to measure good performance?
Is it tightly coupled with other activities or assets in the business? Would

separating it increase complexity and cause problems of coordination?

Service Providers
Sourcing Approaches and Options

Sourcing Approaches and Options

Insourcing relies on using internal organizational resources
Outsourcing uses the resources of an external organization
or organizations
Co-sourcing is a combination of insourcing and outsourcing
Partnership or multi-sourcing is an arrangement between two
or more organizations to work together
Business Process Outsourcing (BPO) relocates entire
business functions
Application Service Provision involves formal arrangements
with an Application Service Provider (ASP) organization
21
Insourcing relies on using internal organizational resources in the design, development,

transition, maintenance, operation, and support. The resources can be used in any
combination with new, changed, or revised service or data center operations.
Outsourcing uses the resources of an external organization or organizations in a formal
arrangement. Outsourcing provides a well-defined portion of the design, development,
maintenance, operation, and support of the service. Outsourcing includes services from
Application Service Providers (ASPs).
Co-sourcing combines insourcing and outsourcing to use a number of outsourcing
organizations working together to co-source key elements within the lifecycle. This process
typically involves a number of external organizations working together to design, develop,
change, maintain, operate, and support a portion of a service.
Partnership or multisourcing is an arrangement between two or more organizations to
work together to design, develop, transition, maintain, operate, and support IT services. The
focus here tends to be on strategic partnerships that use critical expertise or market
opportunities.
Business Process Outsourcing (BPO) relocates entire business functions using formal
arrangements between organizations. In BPO, one organization provides and manages the
entire business processes or functions of the other organization in a low cost location.
Common examples are accounting, payroll, and call center operations.
2-23

Service Providers
Application Service Provision involves formal arrangements with an Application Service

Provider (ASP) organization that will provide shared computer-based services to customer
organizations over a network. Applications offered in this way are also sometimes referred
to as on-demand software and applications. Through ASPs, the complexities and costs of
such shared software can be reduced and provided to organizations that otherwise might not
justify the investment.
2-24

The Process of Strategy Generation
Lesson 3: The Process of Strategy

Generation
Lesson 3: The Process of Strategy

Generation
2-25

Strategy Generation
Strategy Generation
Differentiate your services from the competition.
Use existing opportunities: Customers who are not wellsupported represent opportunities for services to be
offered as solutions.
Use new opportunities: New opportunities emerge when

changes in the business environment cause a
previously wellsupported customer to be poorly
supported.
23
Defining the market and understanding the customer includes the following activities:
Service strategies are developed for services offered
Providers differentiate their services from competing alternatives available to

customers
Service management offers services as part of a business strategy
For example:
A software vendor might decide to offer software as a service. The vendor combines their
capabilities in software development with new capabilities in service management. The
vendor also makes use of their capabilities in maintaining software applications to bundle
technical support as part of the core service. By adopting a service-oriented approach
supported by service management capabilities, the vendor has transformed itself into a
service business.
This approach has also been adopted by internal software engineering groups who have
changed from being cost centers to being profit centers.
2-26

Main Activities of Service Strategy

Main Activities of Service Strategy

Define the market
Develop the service offerings
Develop strategic assets
Prepare for implementation
24
Business needs and requirements should be the driving force behind all service solutions
and activities. In addition, Service Strategy must also reflect the strategies and policies of
the service provider organization,
Service Strategy consists of:
Strategies
Policies
Resources and Constraints
Service Level Package (SLP) from Requirements
The key to any successful Service Strategy is to focus on fully satisfying the customers
needs at a sufficient value to the customer.
2-27

Defining the Market: Market Space

Defining the Market: Market Space

A market space is a set of opportunities to deliver value
to the business of a customer through one or more
services.
To meet the needs of future opportunities, Service
Management must further invest in assets such as
process, knowledge, people, applications, and
infrastructure.
25
Services are a means of delivering value to customers by facilitating outcomes customers

need without owning specific costs and risks.
A market space represents a set of opportunities for service providers to deliver value to the
business of a customer through one or more services. Often it is unclear how services create
value for customers. Services are often defined in the terms of resources made available for
customers to use. Service definitions lack clarity on two points:
Context in which such resources are useful
Business outcomes that justify the expense of a service from the customer
perspective of the customer
This problem leads to poor designs, ineffective operation, and lackluster performance in
service contracts. Service improvements are difficult when it is not clear what
improvements are truly required. Customers can understand and appreciate improvements
only within the context of their own business assets, performances, and outcomes. A correct
definition of services takes into account the context in which customers perceive value from
the services.
An outcome-based definition of services ensures that managers plan and implement all
aspects of Service Management. These activities should be completed entirely from the
perspective of what is valuable to the customer. Such an approach ensures that services not
only create value for customers but also capture value for the service provider.
2-28

Solutions that enhance the performance of the customer assets indirectly support positive
outcomes generated by those assets. Such solutions and propositions hold utility for the
business.
Customers perceive benefits in a continued relationship and trust the provider to increase
value and add possibilities of new customers and market spaces. These benefits justify
further investments in Service Management in terms of capabilities and resources which
have a tendency to reinforce each other. Stakeholders might initially trust the provider with
low-value contracts or noncritical services. Service Management responds by delivering
the performance expected of a strategic asset. The performance is rewarded with contract
renewals, new services, and customers. Together these rewards represent a larger value of
business. To handle this increase in value, Service Management must invest further in
assets such as process, knowledge, people, applications, and infrastructure. Successful
learning and growth aids commitments of higher service levels as Service Management is
conditioned to handle bigger challenges. Over time, this cycle results in higher capability
levels and maturity in Service Management, leading to a higher return on assets for the
service provider.
Unless correctly defined, the cost of service assets spent in support of customers assets
might be difficult to account for and recover. Incorrect cost definition leads to situations
where adequate value is created for the customer, but inadequate value is captured for the
provider.
2-29

Expansion, Growth, and Differentiation

Expansion, Growth, and Differentiation

The best opportunities for expansion lie in areas where
an important customer need remains poorly satisfied
Growth in a market space depends on a demonstrated
ability to deliver value and a strong record with existing
customers
Differentiation in market spaces is normally created
through better a better mix of services, superior service
designs, and operational effectiveness
26
Service portfolios should be extended to support areas of opportunity. Usually there is a

need for services to provide certain levels of utility and warranty. However, managers
should not overlook the costs and risks in such areas. There are typically strong reasons
why certain needs of customers remain unfulfilled. Breakthrough performance and
innovation are typically required to successfully deliver value in underserved areas of
opportunity.
The long-term vitality of the service provider rests on supporting customer needs as they
change or grow and exploiting new opportunities that emerge. This analysis identifies
opportunities with current and prospective customers. It also prioritizes investments in
service assets based on their potential to serve market spaces of interest.
Because market spaces are defined in terms of the business needs of customers, service
provider strategies are therefore aligned to customers. For this reason, service providers
must think in terms of market spaces and not simply industry sectors, geographical areas,
or technology platforms. This way of thinking is intuitive to the senior leadership of Type
I providers. They are accustomed to being driven more by the outcomes expected by their
business units than by the traditional market segmentation. When service strategies are
linked to market spaces, it is easier to make decisions about service portfolios, designs,
operations, and long-term improvements. Investments in service assets such as skills sets,
knowledge, processes, and infrastructure are driven by the critical success factors for a
given market space.
2-30

Strategic planning and review includes examining opportunities for growth within current
customers and services.
The best opportunities for service providers lie in areas where an important customer need
is not satisfied. Service portfolios should be extended to support such areas of opportunity.
Extension typically means that there is a need for services to provide certain levels of utility
and warranty. However, managers should not overlook the costs and risks in such areas.
There are typically strong reasons why certain needs of customers remain unfulfilled.
Breakthrough performance and innovation are usually required to successfully deliver
value in underserved areas of opportunity.
Strategic planning and review includes examining opportunities for growth within current
customers and services. Growth in a market space is dependent upon demonstrated ability
to deliver value and a strong record with existing customers.
Differentiation in market spaces is normally created by the following techniques:
Better a better mix of services
Superior service designs
Operational effectiveness that permits efficiency and effectiveness in the delivery

and support of services
With various combinations of factors, there are many ways to create differentiation. Service
Management leads to differentiation in every supported market space by making decisions
on the following topics:
Service design
Transition
Operation
Improvement
2-31

Develop the Offerings and Strategic Assets

Develop the Offerings and Strategic Assets

Services are a means of delivering value to customers by
facilitating outcomes customers need without their owning
specific costs and risks
To meet the needs of future opportunities, Service
Management must further invest in assets such as
Process, Knowledge, People, Applications, and
Infrastructure
Service management as a strategic asset identifies the
key relationships and interactions to have better visibility
and control over the systems and processes they operate
27
Service management as a strategic asset identifies the key relationships and interactions to
have better visibility and control over the systems and processes they operate.
Customers perceive benefits in a continued relationship and trust the provider to increase
value and add possibilities of new customers and market spaces. These benefits justify
further investments in Service Management in terms of capabilities and resources that have
a tendency to reinforce each other. Stakeholders might initially trust the provider with lowvalue contracts or noncritical services.
Service Management responds by delivering the performance expected of a strategic asset.
The performance is rewarded with contract renewals, new services, and customers.
Together these rewards represent a larger value of business. To handle this increase in
value, Service Management must invest further in assets such as process, knowledge,
people, applications, and infrastructure. Successful learning and growth enables
commitments of higher service levels as Service Management is conditioned to handle
bigger challenges. Over time, this cycle results in higher capability levels and maturity in
Service Management, leading to a higher return on assets for the service provider.
Unless properly defined, the cost of service assets spent in support of customers assets can
be difficult to account for and recover. This difficulty leads to situations where adequate
value is created for the customer, but inadequate value is captured for the provider
2-32

To develop Service Management as a strategic asset, define the value network by

identifying the key relationships and interactions. This definition will provide better
visibility and control over the systems and processes they operate. Managers can manage
the complexity of their business environments as customers pursue their own business
models and strategies. Service Management also helps account for all the costs and risks
involved in providing a service or supporting a customer.
Strategic assets are dynamic. They are expected to continue to perform well under changing
business conditions and objectives of their organization. Therefore, strategic assets must
have learning capabilities. Performance in the immediate future should benefit from
knowledge and experience gained from the past. Service Management must operate as a
closed-loop system that systematically creates value for the customer and captures value for
the service provider. An important aspect of Service Management is controlling the
interactions between customer assets and service assets.
2-33

Increasing Service and Performance Potential

Increasing Service and Performance Potential

The capabilities and resources (service assets) of a service provider
represent the service potential or the productive capacity available to
customers through a set of goods and services
Projects that develop or improve capabilities and resources increase
the service potential
The performance potential of services is increased by having the right
mix of services to offer to customers, and designing those services to
have an impact on the business of the customer
The performance potential of services also arises from the removal of
costs and risks from the businesses of the customers
28
The capabilities and resources (service assets) of a service provider represent the service
potential available to customers through a set of services. Projects that develop or improve
capabilities and resources increase the service potential.
Implementation of a Configuration Management system (CMS) leads to improved
visibility and control over the productive capacity of service assets. These assets include
networks, storage, and servers. The configuration management system also helps to quickly
restore such capacity in the event of failures or outages. Those assets are used more
efficiently, and service potential is increased because of capability improvements in
Configuration Management.
Through Configuration Management, all service assets should be identified with the name
of the services to which they add service potential. This identification helps decision
makers arrive at decisions related to service improvement and asset management. Clear
relationships make it easier to ascertain the impact of changes, make business cases for
investments in service assets, and identify opportunities for scale of and scope of
economies. The Configuration Management system identifies critical service assets across
the service portfolio for a given customer or market space.
The services offered by a service provider represent the potential to increase the
performance of customer assets. Without this potential, customers cannot justify procuring
the services. Performance potential of services needs to be defined so that management
decisions are rooted in creating value for customers. This practice avoids many problems
of service businesses where value for customers is harder to define and control. Working
2-34

backwards from the performance potential of customers ensures that service providers are
always aligned with business needs, regardless of how often those needs change.
The performance potential of services is increased primarily by having the right mix of
services. In addition, it is increased by designing those services to have an impact on the
businesses of the customers.
The productive capacity of service assets is transformed into the productive capacity of
customer assets. An important aspect of delivering value for customers through services is
reducing risks for customers. By deciding to use a service, customers often are seeking to
avoid certain risks and costs. Therefore, the performance potential of services also arises
from removing costs and risks from the businesses of the customers.
2-35

Strategic Assessment
Strategic Assessment
Analyze External Factors
Establish Objectives
Analyze Internal Factors
29
Established service providers frequently do not understand their unique differentiators. The
differentiation can come in many forms:
2-36
Barriers to entry, such as the knowledge of the organization regarding the business
of the customer or the broadness of service offerings
Raised switching costs, due to lower cost structures generated through

specialization or service sourcing
A particular attribute not readily found elsewhere, such as:
Product knowledge
Regulatory compliance
Provisioning speeds
Technical capabilities
Global support structures

Setting Objectives
Setting Objectives
Objectives represent the results expected from pursuing
strategies.
Strategies represent the actions to be taken to
accomplish objectives.
Clear objectives provide for consistent decision making,
minimizing any future conflicts. They set forth priorities
and serve as standards.
30
To craft objectives, an organization must:
Understand what outcomes customers want
Determine how best to satisfy the important but under served outcomes
From this understanding, the organization can create metrics to measure how well a service
is performing. These data sources are the primary means by which a service provider
creates value.
2-37

Defining Critical Success Factors

Defining Critical Success Factors

Critical Success Factors are influenced by:
customer needs
business trends
competition
regulatory environment
suppliers
Standards
industry best practices
technologies
31
Identifying critical success factors for a market space is an essential aspect of strategic
planning and development. In each market space, service providers require a core set of
assets in order to support a Customer Portfolio using a Service Portfolio. For example, in
the market space for high-volume, real-time data processing, such as those required by the
financial services industry, service providers must have:
Large-scale computer systems
Highly reliable network infrastructure
Secure facilities
Knowledge of industry regulations
Without these assets, such service units cannot provide the utility and warranty demanded
by customers in that market space.
The dynamic nature of markets, business strategies, and organizations requires critical
success factors be reviewed periodically. In addition, significant events such as changes to
customer portfolios, expansion into new market spaces, changes in the regulatory
environment, and disruptive technologies need to be monitored. For example, the health
care industry has new legislation on the portability and privacy of patient data. This change
alters the critical success factors for all service providers operating in health care market
spaces.
2-38

Strategy Generation, Evaluation, and

Selection
Strategy Generation, Evaluation, and Selection

Determine perspective: Vision
Form a position: Policies
Craft a plan: Plans
Adopt patterns of action: Actions
32
2-39

Measurement and Evaluation

Measurement and Evaluation

Service Strategy
Service Portfolio
Service Design requirements
Service Transition requirements
Service Operation requirements
Continual Service Improvement Strategy
33
2-40

Strategy Generation Roles

Strategy Generation Roles

IT Steering Group (ISG)
Service Owner
Service Sponsor
Requirements Requester
Service Design Team
34
IT Steering Group (ISG)

The IT Steering Group (ISG) sets the direction and strategy for IT Services. It includes
members of senior management from business and IT. The ISG reviews the business and
IT strategies in order to make sure that they are aligned. It also sets priorities of service
development programs and projects.
Service Owner
The Service Owner of each service record contains the role or function currently
accountable for the service, but not for the Service Portfolio Management process.
Service Sponsor
The Service Sponsor is the person or board responsible for budgets and costs related to a
specific service.
2-41

Requirements Requester
The Requirements Requester is the person or group of persons expressing new demands
and requirements to be fulfilled by the IT service provider.
Service Design Team

The Service Design Team is the team associated to all tasks in the context of designing a
service. This team is responsible for creating a Service Design Package.
2-42

The Process of Service Portfolio Management
Lesson 4: The Process of Service Portfolio

Management
Lesson 4: The Process of Service

Portfolio Management
2-43

Service Portfolio Management (SPM)

Service Portfolio Management (SPM)

The Service Portfolio represents the commitments and
investments made by a service provider across all
customers and market spaces
Service portfolios represent the ability and readiness of a
service provider to serve customers and market spaces
Service Portfolio Management is critical to having the
right services available to offer to customers
36
The Service Portfolio represents present contractual commitments, new service

development, and ongoing service improvement programs initiated by Continual Service
Improvement.
The portfolio also includes external vendor services, which are an integral part of service
offerings to customers.
The Service Portfolio represents all the resources presently engaged or being released in
various phases of the Service Lifecycle. Each phase requires resources for completion of
projects, initiatives, and contracts. The phases are also an important governance aspect of
Service Portfolio Management (SPM).
2-44

Service Portfolio Management
The Service Portfolio represents all the resources presently engaged or being released in
various phases of the Service Lifecycle. Entry, progress, and exit are approved only with
approved funding and a financial plan for recovering costs or showing profit, as necessary.
The portfolio should have the right mix of services in the pipeline and catalog to secure the
financial viability of the service provider. The Service Catalog is the only part of the
Service Portfolio that recovers costs or earns profits. The Service Portfolio represents the
commitments and investments made by a service provider across all customers and market
spaces. It represents present contractual commitments, new service development, and
ongoing service improvement programs initiated by Continual Service Improvement.
Service Portfolio Management (SPM) is about maximizing value while managing risks and
costs. The value realization is derived from better service delivery and better customer
experiences. SPM begins by documenting the standardized services of the organization and
therefore has strong links to Service Level Management, particularly the Service Catalog.
Portfolio management helps managers prioritize investments and improve the allocation of
resources. Portfolios instill a certain financial discipline necessary to avoid making
investments that will not yield value. Service portfolios represent the ability and readiness
of a service provider to serve customers and market spaces.
2-45

Through SPM, managers are better able to understand quality requirements and related
delivery costs. They can then seek to reduce costs by alternative means while maintaining
service quality. The SPM journey begins by documenting the standardized services of the
organization and therefore has strong links to Service Level Management, particularly the
Service Catalog.
2-46

Service Portfolio Management Goals

Service Portfolio Management Goals

Every planned and operated service by the provider is
documented.
Every new service must complete a set of standardized
activities and procedures.
Essential information is documented and provided to the
relevant management processes.
Each service and its design package is regularly
reviewed.
Every service is reviewed within the Continual Service
Improvement Process.
Through the service portfolio, an information base for a
service catalog is provided.
38
The purpose of Service Portfolio Management is to create, manage and improve a service
portfolio containing a detailed design package for each IT service.
2-47

Service Portfolio Management Benefits

Service Portfolio Management Benefits

Helping managers prioritize investments and improve the
allocation of resources.
Instilling financial discipline necessary to avoid making
investments that will not yield value.
Representing the ability and readiness of a service
provider to serve customers and market spaces.
39
A Service Portfolio describes the services of a provider in terms of business value. It

outlines business needs and the response to those needs. By definition, business value terms
correspond to marketing terms. Therefore, a Service Portfolio provides a means for
comparing service competitiveness across alternative providers.
A Service Portfolio either clarifies or helps to clarify the following strategic questions:
2-48
Why should a customer buy these services?
Why should they buy these services from us?
What are the pricing or chargeback models?
What are our strengths and weaknesses, priorities and risk?
How should our resources and capabilities be allocated?

Service Portfolio Management Activities

Service Portfolio Management Activities

Define
Analyze
Approve
Charter
40
Service Portfolio Management includes the following activities:
Define
Collect information from all existing services as well as every proposed service. Every
proposed service would include those in a conceptual phase. For example, all services the
organization would provide if it had unlimited resources, capabilities and time. The purpose
of this exercise is to understand the opportunity costs of the existing portfolio. A service
provider needs to understand its limitations. In this way, it is better able to assess if it should
keep doing what it is doing or reallocate its resources and capabilities.
2-49

Analyze
In this phase, the intent of the strategy is designed. During this activity, the following
questions should be answered:
What are the long term goals of the service organization?
What services are required to meet those goals?
What capabilities and resources are required for the organization to achieve those
services?
What are the perspective, position, plan and patterns?
The answers to these questions guide the analysis and the desired outcomes of SPM. The
ability to satisfactorily answer these questions requires the involvement of senior leaders
and subject matter experts.
Approve
In this phase, deliberate approvals or disapprovals of the proposed portfolio take place. In
addition, the corresponding authorization for new services and resources occurs in this
phase.
Charter
In this phase decisions are communicated, resources are allocated, and services are
chartered. This phase should begin with a list of decisions and action items. These are to be
communicated to the organization clearly and unambiguously. These decisions should be
correlated to budgetary decisions and financial plans. Budget allocations should enforce the
allocation of resources.
2-50

Service Portfolio Management Roles

Service Portfolio Management Roles

Service Portfolio Process Manager (Service Portfolio
Manager)
Service Portfolio Process Owner
Service Portfolio Management Team
Service Agent
41
Service Portfolio Process Manager (Service Portfolio Manager)

The Service Portfolio Process Manager manages the entire SPM process. This person is
responsible for the effectiveness and efficiency of the SPM process.
Service Portfolio Process Owner

The Service Portfolio Process Owner is the Initiator of the process. This person is
accountable for defining the strategic goals of the processes. In addition, this person is
responsible for allocating all required process resources.
Service Portfolio Management Team

The members of this team are assigned to complete various activities in the SPM process.
2-51

Service Agent
The Service Agent of each service record contains the role or function responsible for the
current activity or task within the process of Service Portfolio Management. The Service
agent can be changed through a functional escalation, if allowed. This following role is
assigned for each new instance of the Service Portfolio Management process and usually
exist for the entire lifetime of one process instance. Changes in the assignment of this role
is possible. However, the change applies only to a specific process instance, and not to the
process in general.
2-52

The Process of Financial Management
Lesson 5: The Process of Financial

Management
Lesson 5: Financial Management
2-53

Financial Management
Financial Management as a strategic tool is equally
applicable to all three service provider types
Financial Management consists of the following benefits:
Enhanced decision making
Speed of change
Financial compliance and control
Operational control
Value capture and creation
43
Financial Management consists of the function and processes responsible for managing an
IT service providers budgeting, accounting, and charging requirements.
Internal service providers are increasingly asked to operate with the same levels of financial
visibility and accountability as their business unit and external counterparts. Moreover,
technology and innovation have become the core revenue-generating capabilities of many
companies.
Financial Management quantifies, in financial terms, the value of IT Services and the assets
underlying the provisioning of services. In addition, Financial Management provides the
qualification of operational forecasting. A significant portion of Financial Management is
working with IT and the business to identify, document, and agree on the value of the
services being received. Financial Management also contributes to service demand
modeling and management.
2-54

Financial Management Goals and Benefits

Financial Management Goals

To ensure that management of IT Services are cost
effective
To provide full accountability for IT Service expenditures
to the services delivered to customers
To assist management in making decisions on IT
investment by providing detailed business cases for
changes to IT Services
44
Financial Management consists of the following benefits:
Enhanced decision making
Speed of change
Financial compliance and control
Operational control
Value capture and creation
2-55

Financial Management Considerations

Financial Management Considerations

Direct versus indirect costs
Labor costs
Variable cost elements
Translation from cost account data to service value
45
Financial Management must consider several types of costs:
Direct costs are those that are directly attributable to a specific service. Indirect
costs are those that are shared among multiple services. These costs should be
analyzed to identify line items that should be maintained. The data available and
the level of effort required should be considered in this decision.
Labor costs are another key expenditure requiring consideration. Analyzing labor
costs can be difficult because of the complexity and accuracy of time-tracking
systems. Sometimes tracking labor resources assigned across services is not
available. In this case, rules and assumptions must be created for allocation of
these costs. In its simplest form, organizing personnel costs across financial
centers based on a service orientation is a viable method for aligning personnel
costs to services.
Variable cost elements include expenditures that are not fixed. They vary
according to factors such as the number of users or the number of running
instances.
Translation from cost account data to service value is only possible after costs are attributed
to services. Pricing the perceived value portion of a service involves analysis of historical
costs, perceived value-added, and planned demand variances.
2-56

Financial Management Activities

Financial Management Activities

Plan
Analyze
Design
Implement
Measure
46
2-57

Plan
Plan
Address critical questions about the business and IT
culture
Assess the corporate culture and regulatory and
compliance considerations
Identify all internal and external contacts that provide or
receive IT financial information
Clarify IT and business expectations such as:
Deliverables
Chargeback system
Service Catalog implementation and pricing
47
Plan (Continued)
Determine systems that require Financial Management
data
Determine the funding or operating model to be used
Assign responsibilities for the deliverables
Outline activities to be performed
Prepare the organization chart based on activities, size of
data to be, and tools
Prepare policy and operating procedures list
48
2-58

Analyze
Analyze
Gather details around the planning and funding of identified items
Make certain that all processes and information required to produce
deliverables are accounted for
Become familiar with current expenses in preparation for creating
new valuation and funding documents
After completing an accounting of all IT expenditures, perform service
valuation, including:
Producing reports that provide for the first element of valuation pricing of
service assets
Adding that value to each service to calculate the total price for an IT
service
Analyzing and calculating the value-add price
Adjust plans for implementation if necessary

49
Financial analysis includes the following tasks:
Gather details around the planning and funding of identified items.

The most detailed task will be analyzing the data pertaining to service valuation
and demand modeling.
Make certain that all processes and information required to produce deliverables
are accounted for.
IT or the business might hold expectations regarding deliverables. Therefore,
analyze backward to make certain all information required to produce the
expected deliverables are accounted for. This process is part of Financial
Management responsibilities.
Become familiar with current expenses in preparation for creating new valuation
and funding documents.
There might be issues that become apparent after reviewing expenditures. For
example, it might become evident that not all IT payments are collected into one
financial center. However, in order to report and account for services costs, IT
expenditures must be centralized.
2-59

Perform service valuation after an accounting of all IT expenditures has been

completed.
Calculation of the value-add price will require a great amount of input from
Service Level Management, Availability, Security and Capacity Management
Adjust plans for implementation if necessary

If during the analysis phase it becomes apparent that Financial Management
dependent processes are not available, the plans for implementation must be
adjusted. For example, if no IT Services have already been identified, then
valuation will be postponed.
2-60

Design
Design
Processes
Valuation Models
Accounting processes
Chargeback methods
Procedures
Roles and responsibilities
50
The design phase creates the outputs that are expected from a Financial Management
implementation. Working with key contributors and service economics supporters is
essential during this phase. Design is completed using data inputs and translations, reports,
methodologies and models.
2-61

Implement
Implement
Activation of planned processes
Input initially comes from corporate financial systems and
Change Management processes
51
2-62

Measure
Measure
Measures of success should to be provided on financial
trends within funding, valuing and accounting
Audit for any credibility gap between the value being
received and price being paid
Perform regular audits
52
Auditing provides verification that processes are being followed.
2-63

Financial Management Inputs and Outputs

Financial Management Inputs and Outputs

Service Valuation
Demand Modeling
Service Provisioning and Optimization
Planning Confidence
Service Investment Analysis
Accounting
Compliance
Variable Cost Dynamics
53
Service Valuation
Financial Management collects data inputs from across the enterprise. It uses this data to
assist in generating and disseminating information as an output. This information feeds
critical decisions and activities such as service valuation. Service Valuation quantifies, in
financial terms, the funding sought by the business and IT for services delivered, based on
the agreed value of those services. Financial Management calculates and assigns a cost
value to a service or service component. Then, they can be disseminated across the
enterprise once the business customer and IT identify what services are actually desired.
Service Valuation focuses on two key concepts: Provisioning Value and Service Value
Potential. Provisioning Value is the actual underlying cost to IT related to provisioning a
service. This cost includes both tangible and intangible elements. Input comes from
financial systems, and consists of payment for actual resources consumed by IT in the
provisioning of a service. Service Value Potential is the value added component based on
customer perceptions of what it could achieve using its own assets against what the service
organization can provide.
2-64

Demand Modeling
Through the application of Financial Management, the Service Catalog is able to provide
customers with the capability to regulate their demand and prepare budgets. Demand
modeling uses service oriented financial information with factors of demand and supply in
order to model anticipated usage by the business, and provisioning requirements by IT. This
is for identifying funding requirements, variations and drivers of those variations, and to
assist in the management of service demand. In this context, inputs for managing service
demand include pricing and incentive adjustments that are intended to alter customer
consumption patterns.
Service Provisioning and Optimization

Financial Management provides key inputs for Service Provisioning Optimization (SPO).
SPO examines the financial inputs and constraints of service components or delivery
models to determine if alternatives should be explored relating to how a service can be
provisioned differently to make it more competitive in terms of cost or quality.
Planning Confidence
Financial Management tries to ensure that the delivery and consumption of services
receives appropriate funding. Financial Management Planning focuses on demand and
supply variances resulting from business strategy, capacity inputs and forecasting. It does
not focus on individual line item expenditures or business cost accounts. As with planning
for any other business organization, input should be collected from all areas of the IT
organization and the business. The financial requirements act as inputs to critical business
decision making.
Service Investment Analysis

The objective of service investment analysis is to derive a value indication for the total
lifecycle of a service based on:
The value received
Costs incurred during the lifecycle of the service
In Service Investment Analysis, it is best to use an exhaustive inventory of assumptions

rather than a limited set of high-level inputs, in order to generate a more realistic and
accurate view of the investment being made.
2-65

Accounting
Financial Management works with corporate financial systems and service management.
This type of service oriented accounting provides far greater detail regarding service
provisioning and consumption. In addition, it results in generation of data that feeds
directly into the planning process. The functions and accounting characteristics that occur
include:
Service recording: The assignment of a cost entry to the appropriate service.
Cost types: The higher level expenses categories such as hardware, software,
labor, and administration.
Cost classifications: The classifications within services that designate the end
purpose of the cost.
Capital or operational: This classification addresses different accounting

methodologies that are required by the business and regulatory agencies.
Direct or indirect: This designation determines whether a cost will be assigned

directly or indirectly to 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 can consume a portion of the expense.
Fixed or variable: This segregation of costs is based on contractual commitments

of time or price.
Cost units: This is the identified unit of consumption that is accounted for a
particular service or service asset.
Compliance
Compliance relates to the ability to demonstrate that proper and consistent accounting
methods and practices are being employed. This relates to areas such as financial asset
valuation, capitalization practices, revenue recognition, access and security controls.
2-66

Variable Cost Dynamics

Variable Cost Dynamics (VCD) focuses on analyzing:
The many variables that impact service cost
How sensitive those elements are to variability
The related incremental value changes that result
Examples of components that could be used in analysis include:
Number and type of users
Number of software licenses
Cost or operating footprint of data center
Delivery mechanisms
Number and type of resources
The cost of adding one more storage device
The cost of adding one more user license
2-67

Financial Management Roles

Financial Management Roles

Financial Manager
IT Financial Manager
54
Financial Manager
The Financial Manager is responsible for managing an IT service providers budgeting,
accounting and charging requirements.
IT Financial Administrator
The IT Financial Administrator is responsible for:
2-68
Gathering cost and budget data
Administering financial reporting tools
Maintaining cost models
Assembling and producing financial reports

The Process of Demand Management
Lesson 6: The Process of Demand

Management
Lesson 6: The Process of Demand

Management
2-69

Demand Management
Demand Management
Essential that Demand Management techniques be used
Demand Management includes techniques such as:
Off-peak pricing
Volume discounts
Differentiated service levels
56
One process of Service Management that cannot be ignored is Demand Management.

Demand Management is important because customers dont want to pay for unused
resources. Although sometimes it is necessary to have surplus capacity to deliver service
levels, unnecessary idle capacity can be avoided through correct Demand Management. In
addition, inadequate capacity has an adverse effect on the quality and growth of delivered
services. Therefore, it is essential that Demand Management techniques be used.
Consumption and production produce demand in a highly synchronized pattern. The
productive capacity of resources available to a service is adjusted according to demand
forecasts and patterns. Some types of capacity can be quickly increased as required and
released when not in use. The arrival of demand can be influenced using pricing incentives.
However, it is not possible to produce and stock service output before demand actually
materializes.
2-70

Activity-based Demand Management

Activity-based Demand Management

PBA define dynamics of a business and include
interactions with customers, suppliers, partners, and other
stakeholders
Services often directly support PBA
57
Business processes are the primary source of demand for services. Patterns of business
activity (PBA) influence the demand patterns seen by the service providers. It is very
important to study the business activity of the customer to identify, analyze and codify such
patterns. This will provide sufficient basis for Capacity Management. Examine the business
activity and plans of the customer in terms of the demand for supporting services.
Business activities drive demand for services. Customer assets such as People, Processes,
and Applications generate patterns of business activity (PBA). Since PBA generate
revenue, income and costs they account for a large proportion of business outcomes.
Patterns of business activity (PBA) are identified, codified, and shared across process for
clarity and completeness of detail.
One or more attributes such as frequency, volume, location and duration describe business
activity. They are associated with requirements such as security, privacy and latency or
tolerance for delays. This profile of business activity can change over time with changes
and improvements in business processes, people, organization, applications and
infrastructure. PBA are placed under change control.
Each PBA has to be substantially different from another PBA in order to be coded with a
unique reference. Codifying patterns helps multidimensional analysis, using criteria such
as likeness and nearness. This provides efficiency and robustness in developing a catalog
patterns with simplification and standardization. This, in turn, reduces the number of
patterns, makes analysis easier, and avoids complicated solutions.
2-71

Demand Management Goal and Benefits

Demand Management Goal

The goal of demand management is to reduce cost and
create value by being able to predict demand and reduce
idle capacity.
58
Demand Management is a critical aspect of service management. Poorly managed demand

is a source of risk for service providers because of uncertainty in demand.
The benefits of Demand Management include:
2-72
Reducing cost generated by excess capacity
Creating value that provides a basis for cost recovery
Improving quality of services by reducing insufficient capacity
Reducing the uncertainty in demand but cannot entirely eliminate it
Influencing the arrival of demand in specific patterns using Demand Management

techniques such as:
Off-peak pricing
Volume discounts
Differentiated service levels
Predicting demand for services in the service catalog that support the process
Predicting demand for underlying service assets that support those services

Demand Management Activities

Demand Management Activities

Study the business of the customer to identify, analyze,
and codify patterns.
Visualize the business activity and plans in terms of the
demand for supporting services.
Identify, codify, and share patterns of business activity
(PBA) across process for clarity and completeness of
detail.
Construct user profiles (UPs) using one or more
predefined PBAs. UPs represent patterns that are
persistent and correlated.
Associate each user profile with one or more PBAs.
59
User profiles (UP) are based on roles and responsibilities within organizations for people,
and functions and operations for processes and applications. Business processes and
applications are treated as users in many business contexts. Many processes are not actively
executed or controlled by staff or personnel.
Process automation allows for processes to consume services on their own. Processes and
applications can have user profiles.
You construct user profiles using one or more predefined PBAs UPs represent patterns that
are persistent and correlated.
2-73

Demand Management Interfaces

Demand Management Interfaces

Inputs to service management functions and processes:
Service Design
Service Catalog
Service Operation
60
Some of the benefits for analyzing PBAs are in the form of inputs to service management
functions and processes such as:
2-74
Service Design can then optimize designs to suit demand patterns
Service Catalog can map demand patterns to appropriate services
Service Portfolio Management can approve investments in additional capacity,

new services, or changes to services
Service Operation can adjust allocation of resources and scheduling
Service Operation can identify opportunities to consolidate demand by grouping

closely matching demand patterns
Financial Management can approve suitable incentives to influence demand

Unit Scenario

The scenario for Unit 1described the creation of a service that existed inside a Service
Catalog.
Unit 2 discussed the details of why a Service Catalog and services exist. In addition, it
focused on the strategic approach and the theoretical approach to the service delivery of
those services.
For this scenario, company X has decided to bring ITIL concepts and guidelines into its
organization. Service Strategy makes an effective case for the delivery of IT as a service
and for a strategic, analytical, and theoretical approach to such delivery.
An organization might ask where to start if the organization has never implemented any of
the ITIL activities covered.
For an organization just starting on ITIL, it is often recommended that the business looks
at the services there are to manage. In addition, the organization should obtain a solid grasp
of what the business requirements are with respect to each of them.
To achieve this, a Service Catalog can be established. Eventually, the more comprehensive
Service Portfolio of current, under development, and planned services, can be encompassed
in the overall strategic approach to ITIL. Most organizations already are performing the
services that will be identified for the catalog and need to develop the official offering. For
example, the organization must decide the type of service provider the IT department is
within the organization. In addition, the organization must determine the specifics in
regards to utility and warranty. For example, what does the service do (utility), and how
well does it do it (warranty)?
Unit 1 contained a service which was a request for a project or enhancement to applications
maintained by internal or external development teams. It is fairly easy to document the
utility and warranty of these services. However, determining elements such as the Delivery
Model or Services Model can be more challenging. The organization can go with the
approach of co-sourcing, where a combination of in-sourcing and outsourcing is used to
support the service for enhancements to applications.
2-75

Unit Scenario
Review Questions
1.
Which of the following choices is not an objective of Service Strategy?

a.Determining which services to offer and to whom
2.
b.
Determining how to carry out the activities and processes required to deliver
services
c.
Determining how to differentiate your services from competing alternatives
d.
Determining how to create value for your customers
Which of the following activities are included in defining the market and
understanding the customer?
a.Service strategies are developed for services offered.
3.
b.
Providers differentiate their services from competing alternatives available to

customers.
c.
Service management offers services as part of a business strategy.
d.
All of the above.
A software vendor decides to offer software as a service. The vendor combines the
capabilities in software development with new capabilities in service
management. The vendor also uses of the capabilities in maintaining software
applications to bundle technical support as part of the core service. By adopting a
service-oriented approach supported by service management capabilities, the
vendor has transformed into a service business. Of which of the following Service
Strategies is this situation an example?
a.Developing Service Offering
4.
b.
Defining the market
c.
Developing Strategic Assets
d.
Preparing for Implementation
Which of the following items will a Service Model not perform?

a.Codifies the service strategy for a market space
2-76
b.
Documents processes and functions needed to create value
c.
Describes how service assets create value for a portfolio of contracts
d.
Defines nonevolving processes and functions

Unit Scenario
5.
Which is the only part of the Service Portfolio that recovers costs or earns profits?
a.Service Catalog
6.
b.
Service Pipeline
c.
Customers
d.
Service Concepts
Which of the following choices represents all the resources presently engaged or
being released in various phases of the Service Lifecycle?
a.Service Catalog
7.
b.
Service Operation
c.
Service Transition
d.
Service Portfolio
Which of the following choices is the virtual projection of the actual and present
capabilities of the service provider?
a.Service Catalog
8.
b.
Service Operation
c.
Service Transition
d.
Service Portfolio
Which of the following choices is not true about the Service Catalog?
a.It contains items that can be configured.
9.
b.
It is invisible to customers.
c.
It consists of services presently active in the Service Operation phase.
d.
It is useful in developing suitable solutions for customers.
Which of the following choices describes the purpose of Service Portfolio

Management?
a.Maximizes value while managing risks and costs
b.
Permits understanding of quality requirements and related delivery costs
c.
Has strong links to Service Level Management
d.
All of the above
2-77

Unit Scenario
Review Answers
1.
Which of the following choices is not an objective of Service Strategy?

b. Determining how to carry out the activities and processes required to deliver
services
2.
Which of the following activities are included in defining the market and
understanding the customer?
d. All of the above
3.
A software vendor decides to offer software as a service. The vendor combines the
capabilities in software development with new capabilities in service
management. The vendor also uses of the capabilities in maintaining software
applications to bundle technical support as part of the core service. By adopting a
service-oriented approach supported by service management capabilities, the
vendor has transformed into a service business. Of which of the following Service
Strategies is this situation an example?
b. Defining the market
4.
Which of the following items will a Service Model not perform?

d. Defines nonevolving processes and functions
5.
Which is the only part of the Service Portfolio that recovers costs or earns profits?
a. Service Catalog
6.
Which of the following choices represents all the resources presently engaged or
being released in various phases of the Service Lifecycle?
d. Service Portfolio
7.
Which of the following choices is the virtual projection of the actual and present
capabilities of the service provider?
a. Service Catalog
8.
Which of the following choices is not true about the Service Catalog?
b. It is invisible to customers.
9.
Which of the following choices describes the purpose of Service Portfolio

Management?
d. All of the above.
2-78

Unit Scenario
Summary
Summary
Explain the purpose of Service Strategy
Explain the two elements of value: utility and warranty
Describe the three types of service providers
Explain how to choose between service provider types
Describe the key principles of Service Strategy
Discuss the main Service Strategy processes and
62
2-79

Unit Scenario
2-80
3-1
Introduction
In this unit, you will learn about Service Design.
Objectives
Objectives
Explain the key principles and concepts related to
Service Design
Discuss Service Design processes and associated
activities
Describe the Service Design roles
3-2

Service Design Overview
Lesson 1: Service Design Overview
Lesson 1: Service Design Overview
3-3

Service Design Introduction

Service Design Introduction

Main purpose is design of new or changed services being
introduced into the live environment
Service Design emphasizes a holistic approach to all aspects
of design
Design and development of a new application should not be done in isolation. It should
consider the impact on the following elements:
Overall service
Management systems and tools
Architectures
Technology
Service management processes
Necessary measurements and metrics
Such consideration ensures that the functional elements are addressed by the design. In
addition, all of the management and operational requirements will be addressed as a
fundamental part of the design. They will not be added as an afterthought.
When any of the individual elements of design are changed or amended, all other aspects
are considered.
3-4

Five Major Aspects of Service Design

The Five Major Aspects of Service Design

Design of new or changed services
Service Portfolio Design, which includes the Service
Catalog
Technology and architectural design
Process design
Measurement design
The Service Design stage starts with a set of new or changed business requirements and
ends with the development of a service solution. This solution is designed to meet the
documented needs of the business.
This developed solution with its Service Design Pack (SDP) is then passed to Service
Transition. Service Transition will evaluate, build, test, and deploy the new or changed
service. When these transition activities are completed, control of the new or changed
service is transferred to the Service Operation stage of the service lifecycle.
3-5

Service Design
The Business: Separate businesses or business clients with their individual structures and
processes.
SLA: A Service Level Agreement (SLA) is a formal negotiated agreement between
customers and their service provider, or between service providers. It records the common
understanding about services, priorities, responsibilities, and guarantee, with the main
purpose to agree on the level of service.
IT Services: Services rendered for computer-based information systems.
Support Teams: Provide support for hardware, software, and employees. This support
might include supporting local machines and servers.
Service Improvement: Aligns and realigns IT services to changing business needs. This
alignment is accomplished by identifying and implementing improvements to IT services.
At the same time, it strives to make processes more effective and cost efficient.
3-6

Service Strategy: Design and develop Service Management as a strategic asset. It provides
a wider range of solutions to the problem of creating, maintaining, and increasing value.
Service Transition: Sets customer expectations on how the performance and use of new or
changed services can be used to promote business change. In addition, it reduces known
errors and minimizes risks from transitioning new or changed services into production.
Service Operation: Coordinates the activities and processes required to deliver, support,
and manage services at agreed upon levels to business users and customers.
Service Portfolio: Identifies the agreed-upon scope of service
SLM: Service Level Management (SLM) ensures an agreed-upon level of IT service is
provided for all current IT services. In addition, it makes certain that future services are
delivered to agreed-upon targets.
SCM: Service Continuity Management (SCM) is the assessment of business impact and
risk and the provision of resilience, failover, and recovery mechanisms.
Suppliers: Typically external vendors who provide services to the Service Provider.
3-7

Service Management: The 4 Ps

Service Management: The 4 Ps

The implementation of ITIL
Service Management about
preparing and planning use of
the four Ps:
People
Processes
Products (services,
technology, and tools)
Partners (suppliers,
manufacturers, and vendors)
Many designs, plans, and projects fail because of a lack of preparation and management.
3-8

Service Design Package (SDP)


Produced during the design stage for:
Each new service
A major change to a service
Removal of a service
Changes to the Service Design Package itself
The Service Design Package should be produced during the design stage for each new
service, major change to a service, or removal of a service.
3-9

Contents of SDP
Contents of SDP
Business Requirements
Service Functional Requirements
Service Level Requirements
Organizational Readiness Assessment
Service Lifecycle Plan
3-10

The RACI Model

The RACI Model

Responsible: The person or group responsible for
completing a task
Accountable: The individual ultimately held responsible
for the task
Consulted: The person or people whose opinions are
sought
Informed: The person or people who are given updates
on the task
10
Service Design can not be successful unless the roles and responsibilities for each of the
activities are clearly defined. If roles and responsibilities are not clearly defined, the
decision-making process falls apart. One tool that is useful to facilitate clear decision
making processes is the RACI model.
3-11

RACI-VS
RACI-VS
Verifies: Person or group who confirms the accurate
completion of acceptance criteria
Signs Off: Person who finally approves and authorizes
before product release
11
Some organizations use an expanded version of RACI, called RACI-VS. The VS stands for:
Verifies: the person or group that confirms the accurate completion of acceptance criteria
Signs Off: The person with final approval and authorization before product release.
Some organizations use a RASCI model in which the S signifies Supportive. The supportive
role is available when additional resources are necessary to complete the task.
RACI and other decision-making models and tools are important because they can help to
avoid conflicts. In addition, they can save time because roles are defined before the decision
needs to be made.
The roles of the RACI model are placed on a chart with activities, roles, and codes
identified. The following steps should be used to build a RACI chart:
3-12
Identify the activities, tasks, and processes
Identify and define the functional roles involved
Meet and assign the RACI codes
Identify any gaps or overlaps for example, where there are two Vs or no Vs

Distribute the chart and incorporate feedback
Ensure that the allocations are being followed
3-13

Technology Considerations
Technology Considerations for Service Design
Identify the requirements
Identify the products
Apply the selection criteria
Evaluate the products
Develop a short list
Score the products
Rank the products
Select the product
12
When choosing tools for Service Management, it is important to remember that the tool
should support the process. Often times, organizations try to change their processes to fit
the tool. Although it might be necessary to make a few changes in design, the tool should
support the defined process.
Some factors that should be considered when evaluating Service Management tools are:
3-14
Data structure, data handling and integration
Integration of components from various vendors, and the future need to apply new
components
Conformity to international open standards
Flexibility in implementation, usage and data sharing
Usability
Support for monitoring service levels
Ability to support distributed clients with a centralized shared database
Conversion requirements for previously tracked data
Data backup, control, and security

Support options provided by the tool vendor
Scalability at increasing of capacity
3-15

Process of Service Catalog Management
Lesson 2: Process of Service Catalog

Management
Lesson 2: Process of Service Catalog

Management
3-16

Service Catalog Management

Service Catalog Management

The Service Catalog is a central source of data recording
the status of all IT services delivered by the service
provider organization
Service Catalog Management (SCM) process ensures
that a Service Catalog is produced and maintained
containing accurate information on all operational
services and those being prepared to be run operationally
After a service is developed for use by customers, the
service should be added to the Service Catalog
14
Service Catalog Management (SCM) process ensures that a Service Catalog is produced
and maintained. The catalog contains accurate information about all operational services
and those being prepared to be run. SCM provides a single source of consistent information
on all of the agreed-upon services. It also ensures that the catalog is widely available to
those approved to access it.
The catalog should contain:
View of the current IT services from the customers perspective
How the services are intended to be used
Business processes enabled by the services
Levels and quality of service the customer can expect for each service
Details of all operational services being provided
Those services being prepared for transition to the live environment
Summary of their characteristics
Details of the customers
3-17

The Portfolio should contain all of the future requirements for services. The Service
Portfolio is produced as part of Service Strategy and should include participation by those
involved in Service Design, Transition, Operation, and Improvement. After a service is
chartered, being developed for use by customers, Service Design produces the
specifications for the service. At this point the service should be added to the Service
Catalog.
The SCM process produces and maintains the Service Catalog to ensure:
A central, accurate, and consistent source of data
A record of the status of all operational services or services being moved to the
live environment
The Service Catalog has two components:

The Business Service Catalog: This part contains details of all the IT services delivered to
the customer. In addition, it details the relationships to the business units and the business
process that rely on the IT services. This is the customer view of the Service Catalog.
The Technical Service Catalog: This part contains details of all the IT services delivered
to the customer. In addition it details the relationships to all the supporting services, shared
services, components and CIs necessary to support the provision of the service to the
business. This should support the Business Service Catalog and not form part of the
customer view.
3-18

Service Catalog Management Goal and

Objective
Service Catalog Management Goal

The goal of the Service Catalog Management process is
to ensure that a Service Catalog is produced and
maintained, containing accurate information on all
operational and planned services.
15
The purpose of Service Catalog Management is to supply a definitive source of information

on all of the agreed services. In addition, Service Catalog Management should make certain
that the catalog is widely available to approved individuals.
The objective of Service Catalog Management is to manage the information contained
within the Service Catalog. The information should be accurate for all services that are
being run, or being prepared to run, in the live environment. Some of the information it
should include is current details, status, and interfaces and dependencies.
3-19

Service Catalog Management Benefits

Service Catalog Management Benefits

Through the service catalog, all areas of the business can
view an accurate and consistent picture of IT services
Service details Service status.
The Service Catalog is customer focused view of the IT
services in use, how they are intended to be used, the
business processes they facilitate.
Customers can view the levels and quality of service they
can expect for each service
16
3-20

Service Catalog Management Activities

Service Catalog Management Activities

Develop and document a service definition
Develop the contents of the Service Portfolio and Service
Catalog with Service Portfolio Management
Maintain a Service Catalog and its contents
Interface with business and IT Service Continuity Management
on dependencies of business processes with supporting IT
services
Interface with support teams, suppliers, and Configuration
Management on dependencies between IT and supporting
services, components, and CIs
Interface with Business Relationship Management and Service
Level Management so information is aligned to business
17
The Service Catalog Management (SCM) process ensures that a Service Catalog is
produced and maintained. The catalog contains accurate information about all operational
services and those being prepared to be run. SCM provides a single source of consistent
information on all of the agreed-upon services. It also ensures that the catalog is widely
available to those approved to access it.
3-21

Service Catalog Management Inputs

Service Catalog Management Inputs

Business information from the organization
Business Impact Analysis
Business requirements The Service Portfolio
The Configuration Management System
Feedback from all other processes
18
Business information from the organization includes:
Business strategy
IT strategy
Business plans
Financial plans
Information on their current and future requirements from the Service Portfolio
The Business Impact Analysis provides information on the impact, priority, and risk
associated with each service or changes to service requirements.
The business requirements provide details of any agreed, new, or changed business
requirements from the Service Portfolio.
3-22

Service Catalog Management Outputs

Service Catalog Management Outputs

Updates to the Service Portfolio, which should contain the
current status of all services and requirements for
services
Updates to the Service Catalog containing the details and
the current status of every live service provided by the
service provider
19
Many sources of information are relevant to the Service Catalog Management (SCM)
process. These should include:
Business information from the business and IT strategy, plans, and financial plans
of the organization
Information about organizational current and future requirements from the

Service Portfolio
Business impact analysis providing information about the impact, priority, and
risk associated with each service or change to service requirements
Details of any agreed-upon, new, or changed business requirements from the

Service Portfolio
The Service Portfolio
The Configuration Management System (CMS)
Feedback from all other process
Triggers for the SCM process, which are changes in the business requirements
and services. One of the main triggers is a Request For Change (RFC). The
Change Management process includes new services, changes to existing services,
and services being retired.
3-23

The process outputs of SCM include the following items:
The documentation and agreement of a definition of the service
Updates to the Service Portfolio which should contain the current status of all
services and requirements for services
The Service Catalog should contain:
3-24
Details of every active service provided by the service provider or service being
moved into the production environment
Current status of each of these services
Interface dependencies

Service Catalog Management KPIs

Service Catalog Management KPIs

The number of services recorded and managed within the
Service Catalog as a percentage of those being delivered
and transitioned in the live environment
The number of variances detected between the
information contained within the Service Catalog and the
actual situation
20
3-25

SCM Challenges, Success Factors, and Risks

SCM Success Factors

An accurate Service Catalog
User awareness of the services being provided to them
IT staff awareness of the technology supporting the
services
21
The major challenge to Service Catalog Management maintaining an accurate Service

Catalog as part of a Service Portfolio. It is difficult to integrate both the Business Service
Catalog and the Technical Service Catalog as part of an overall Configuration Management
System (CMS) and Service Knowledge Management System (SKMS). The best approach
to this difficulty, is to develop stand-alone spreadsheets or databases before trying to
integrate the Service Catalog and Service Portfolio into the CMS or SKMS. Cooperation
and acceptance by the members of the organization will help facilitate the process. This
acceptance will often support the standardization of the Service Catalog and Service
Portfolio.
The risks associated with the provision of an accurate Service Catalog include:
3-26
Inaccuracy of catalog data Catalog data without appropriate change control
Poor acceptance and usage of the Service Catalog and Service Portfolio
Inaccuracy of service information received from the business, IT and the Service
Portfolio
Lack of tools and resources required to maintain the information
Poor access to accurate Change Management information and processes

Poor access to and support of appropriate and accurate CMS and SKMS
Information that is either too detailed too high a level to maintain or be of any
value
3-27

Service Catalog Manager

Service Catalog Manager

Ensures all operational service and all services being
prepared for operational running are recorded within the
Service Catalog
Ensues all information within Service Catalog is accurate
and up to date
Ensures all information within Service Catalog is
consistent with information within Service Portfolio
Ensues information within Service Catalog is adequately
protected and backed up
22
The main role of the Service Catalog Management Process is Service Catalog Manager.
The Service Catalog Manager has responsibility for producing and maintaining the Service
Catalog.
3-28

Service Level Management
Lesson 3: Service Level Management
Lesson 3: Process of Service Level

Management
3-29

Service Level Management (SLM) Concepts

Service Level Management (SLM) Concepts

SLM is the name given to the processes of planning,
agreeing to, monitoring, and reporting of SLAs, and the
ongoing review of service achievements to ensure that
quality is maintained and improved
An SLA is a written agreement between an IT service
provider and the IT customers, defining the key service
targets and responsibilities of both parties
An Operational Level Agreement (OLA) is an agreement
between an IT service provider and another part of the
same organization, for example, a facilities department
that maintains the air conditioning or network support
team that supports the network service
24
SLM is the name given to the processes of planning, coordinating, drafting, agreeing upon,
monitoring, and reporting of Service Level Agreements (SLAs). It is the ongoing review of
service achievements to ensure that the required and cost-justifiable service quality is
maintained and gradually improved. SLM is concerned with:
Ensuring that current services and SLAs are managed
Ensuring that new requirements are captured
Ensuring that new or changed services and SLAs are developed to match the
business needs and expectations
Service Level Agreements (SLAs) provide the basis for managing the relationship between
the service provider and the customer. SLM provides that central point of focus for a group
of customers, business units or lines of business.
SLM is also responsible for ensuring that all targets and measures agreed upon in SLAs
with the business have the following support:
3-30
Appropriate underpinning Operational Level Agreements (OLAs) or contracts
Internal support units

External partners
External suppliers
An Operational Level Agreement (OLA) is an agreement between an IT service provider

and another part of the same organization that assists with services.
3-31

Service Level Agreements, Operational Level

Agreements, and Underpinning Contracts

Service Level Agreement (SLA)
Key service targets and responsibilities of both parties
Operational Level Agreement (OLA)
Internal departments or organizations
Underpinning Contract (UC)
A contract with an external organization
25
3-32


3-33

Service Level Agreement

Service Level Agreement

A written agreement between an IT service provider and
the IT customers
Defines the key service targets and responsibilities of
both parties in measureable terms
True partnership between IT service provider and
customer
Three SLA structures:
Service-based SLA
Customer-based SLA
Multi-level SLA
27
A Service Level Agreement (SLA) is a written agreement between an IT service provider

and the IT customers. An SLA defines the key service targets and responsibilities of both
parties. The elements of the SLA must be written in measurable terms. The emphasis must
be on agreement. SLAs should not be used as a way of holding one side or the other to
ransom. A true partnership should be developed between the IT service provider and the
customer, so that a mutually beneficial agreement is reached. Otherwise the SLA might
quickly fall into disrepute, with each side blaming the other for perceived faults and
transgressions. The resulting environment will prevent any true service quality
improvements from taking place.
There are three SLA structures that can be developed according to the needs of the
organization.
3-34
Service-based SLA: This is an agreement that covers one service, for all the
customers of that service
Customer-based SLA: This is an agreement with an individual customer group,

covering all the services they use

Multi-level SLA: Such a structure allows SLAs to be kept to a manageable size,

avoids unnecessary duplication, and reduces the need for frequent updates. An
example of this structure would be a three-layer structure such as:
Corporate level: Covering all the generic SLM issues appropriate to every
customer throughout the organization
Customer level: Covering all SLM issues relevant to the particular customer
group or business unit, regardless of the service being used
Service level: Covering all SLM issues relevant to the specific service, in
relation to a specific customer group
3-35

Operational Level Agreement

Operational Level Agreement

Agreement between IT service provider and another part
of the same organization that helps provide services
Should contain targets that underpin those within an SLA
to ensure that targets will not be breached by failure of
the supporting activity
28
An Operational Level Agreement (OLA) is an agreement between an IT service provider

and another part of the same organization that assists with services. Examples of such
divisions include:
Facilities department that maintains the air conditioning
Network support team that supports the network service
An OLA should contain targets that underpin those within an SLA to ensure that targets will
not be breached by failure of the supporting activity.
Formal contracts are appropriate for external supply arrangements that significantly
contribute to the business. Contracts provide binding legal commitments between customer
and supplier. Contracts cover the obligations each organization has to the other from the
first day of the contract. Often contractual obligations extend beyond the end of the
contract. A contract is used as the basis for external supplier agreements where an
enforceable commitment is required. High-value relationships, strategic relationships, or
both are underpinned by formal contracts. The formality and binding nature of a contract
are not at odds with the culture of a partnership agreement, but rather form the basis on
which trust in the relationship might be founded.
3-36

Underpinning Contracts
Underpinning Contracts
Provide binding legal commitments between customer
and supplier
Cover the obligations each organization has to the other
from the first day of the contract
Likely to be structured with the following sections:
Main body containing commercial and legal clauses
Elements of a service agreement
Other related documents, such as schedules
29
An underpinning contract is likely to be structured with the following sections:
The main body containing the commercial and legal clauses
Elements of a service agreement, as described earlier, attached as schedules
Other related documents as schedules, for example:
Security requirements
Business continuity requirements
Mandated technical standards
Migration plans (agreed prescheduled change)
Disclosure agreements
3-37

Service Level Management Goals

Service Level Management (SLM) Goals

Goal is to ensure that an agreed-upon level of IT service
is provided for all current IT services
SLM tries to make sure that future services are delivered
to agreed-upon targets
Proactive measures taken to seek and implement
improvements to the level of service delivered
30
The SLM process works to ensure that all operational services and their performance are
measured in a consistent, professional manner throughout the IT organization. In addition,
it works to guarantee that the services and the reports produced meet the needs of the
business and the customers.
3-38

SLM Objectives
Service Level Management Objectives

Define, document, agree to, monitor, measure, report, and
review the level of IT services provided
Provide and improve relationship and communication with
business and customers
Ensure specific and measurable targets are developed for
all IT services
Monitor and improve customer satisfaction with quality of
service delivered
Ensure IT and customers have a clear and unambiguous
expectation level of service to be delivered
Ensure proactive measures to improve levels of service
delivered are implemented whenever cost justifies it
31
3-39

SLM Benefits
Service Level Management Benefits

Provides a consistent interface to the business for all
service-related issues
Provides the business with the agreed-upon service
targets
Provides the required management information to ensure
that targets have been met
32
Service Level Management (SLM) provides a consistent interface to the business for all
service-related issues. It provides the business with the agreed-upon service targets and the
required management information to ensure that those targets have been met. When targets
are breached, SLM should provide feedback on the cause of the breach. In addition, it
should give details of the actions taken to prevent the breach from recurring. Therefore,
SLM provides a reliable communication channel and a trusted relationship with the
appropriate customers and business representatives.
3-40

SLM Concerns
SLM Concerns
Ensuring that current services and SLAs are managed
Ensuring that new requirements are captured
Ensuring that new or changed services and SLAs are
developed to match the business needs and expectations
33
3-41

Service Level Management Activities
Review meetings must be held on a regular basis with customers to review the service
achievement in the last period and to preview any issues for the coming period. It is normal
to hold such meetings monthly or, as a minimum, quarterly.
Customers and appropriate IT managers should receive reports a few days before service
level reviews. These reports will help facilitate the resolution of any queries or
disagreements before the review meeting. These reports should incorporate details of
performance against all SLA targets and any actions being undertaken to improve service
quality.
The report can include a SLA Monitoring (SLAM) chart at the front to provide an overview
of how achievements have measured up against targets. These are most effective if color
coded red, amber, and green (RAG).
These service reports should detail current performance against targets and historic
information on past performance and trends. Therefore, the impact of improvement actions
can be measured and predicted.
The key activities within the SLM process should include:
3-42
Determine, negotiate, document, and agree upon requirements for new or changed
services in SLRs
Manage and review the requirements throughout the Service Lifecycle into SLAs
for operational services

Monitor and measure service performance achievements of all operational

services against targets within SLAs
Collate, measure and improve customer satisfaction
Produce service reports
Conduct service review and instigate improvements within an overall Service

Improvement Plan (SIP)
Review and revise SLAs, service scope OLAs, contracts, and any other
underpinning agreements
Develop and document contacts and relationships with the business, customers,
and stakeholders
Develop, maintain, and operate procedures for:
Logging, assigning, and resolving all complaints
Logging and distributing compliments
Provide the appropriate management information to aid performance management

and demonstrate service achievement
Provide and maintain up-to-date SLM document templates and standards
3-43

Service Level Management Input

Service Level Management Input

Business information from business strategy, plans, and
financial plans and information about their current and
future requirements of the organization
The Service Portfolio and Service Catalog
Change information from the Change Management
process with a forward schedule of changes and a need
to assess all changes for their impact on all services
35
Many sources of information are relevant to the Service Level Management process. These
should also include:
3-44
Business Impact Analysis that providing information about the impact, priority,
risk, and number of users associated with each service
Business requirements: details of any agreed-upon, new, or changed business

requirements
The strategies, policies, and constraints from Service Strategy
CMS containing information about the relationships between the business

services, the supporting services. and the technology
Customer and user feedback, complaints, and compliments
Other inputs, including:
Advice, information, and input from any of the other processes (such as
Incident Management, Capacity Management, and Availability Management)
Existing SLAs, SLRs, and OLAs
Past service reports on the quality of service delivered

Service Level Management Output

Service Level Management Output

Service reports
Service Improvement Plan (SIP)
Service Quality Plan
Document templates
Service Level Agreements (SLAs)
Service Level Requirements (SLRs)
Operational Level Agreements (OLAs)
Service review meeting minutes and actions
SLA review and service scope review meeting minutes
Revised contracts
36
The outputs of Service Level Management should include:
Service Reports: Reports that provide details of the service levels achieved in
relation to the targets contained within SLAs. These reports should contain details
of all aspects of the service and its delivery, including:
Current and historical performance
Breaches and weaknesses
Major events
Changes planned
Current and predicted workloads
Customer feedback
Improvement plans
Activities
Service Improvement Plan (SIP): Overall program or plan of prioritized

improvement actions, encompassing all services, all processes, associated
impacts, and risks.
3-45

3-46
Service Quality Plan: Plan that encompasses documenting and planning the
overall improvement of service quality.
Document templates: Standard document templates, format, and content for

SLAs, SLRs, and OLAs, aligned with corporate standards.
Service Level Agreements (SLAs): Set of targets and responsibilities that should
be documented and agreed to within an SLA for each operational service.
Service Level Requirements (SLRs): Set of targets and responsibilities should

be documented and agreed within an SLR for each proposed new or changed
service.
Operational Level Agreements (OLAs): Set of targets and responsibilities

should be documented and agreed to within an OLA for each internal support
team.
Reports on OLAs: Reports based on the service levels promised in the operating
level agreement and underpinning contracts.
Service Review Meeting Minutes and Actions: All meetings should be

scheduled on a regular basis; their planned agendas, discussions, and actions
recorded; and their progress documented.
SLA review and Service Scope Review Meeting Minutes: Summaries of

agreed-upon actions and revisions to SLAs and service scope.
Revised Contracts: Changes to SLAs or new SLRs might require existing

underpinning contracts to be changed or new contracts to be negotiated and
agreed upon.

SLM: Key Performance Indicators (KPIs)

SLM: Key Performance Indicators (KPIs)

Number or percentage of service targets being met
Number and severity of service breaches
Improvements in customer satisfaction
37
Key Performance Indicators (KPIs) and metrics can be used to judge the efficiency and
effectiveness of the SLM activities and the progress of the SIP. These metrics should be
developed from the service, customer, and business perspective and should cover both
subjective and objective measurements.
Objective measurements include the following items:
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 measurements include improvements in customer satisfaction.

The SLM process often generates a good starting point for a Service Improvement Plan
(SIP). The Service Review process might inspire this process, but all processes and all areas
of the service provider organization should be involved in the SIP.
When an underlying difficulty has been identified that adversely affects service quality,
SLM must act with Problem Management and Availability Management, instigate a SIP.
They must identify and implement whatever actions are necessary to overcome the
3-47

difficulties and restore service quality. SIP initiatives might also focus on such issues as
user training, service and system testing, and documentation. In these cases, the relevant
people need to be involved and adequate feedback given to make improvements for the
future. At any time, a number of separate initiatives that form part of the SIP might be
running in parallel to address difficulties.
If an organization is outsourcing its Service Delivery to an external vendor, the issue of
service improvement should be discussed at the outset. In addition, it should be covered and
budgeted for in the contract. Otherwise, the supplier has no incentive during the lifetime of
the contract to improve service targets. Incentive is especially lacking if contractual
obligations are already being met and additional expenditure is needed to make the
improvements.
3-48

SLM Challenges, Success Factors, and Risks

SLM Challenges
Serviceability: Ensure that the Service Provider can
actually meet the terms of the SLAs
Utility: Ensure the requirements presented actually
represent the customer needs
Identifying suitable customer representatives with whom
to negotiate who are genuinely able to represent the
views of the customer community
Existing service issues interfere with establishing the
longer term requirements
Staffing at different levels within the customer community
may have different objectives and perceptions
38
One challenge faced by SLM is that of identifying suitable customer representatives with
whom to negotiate. Who owns the service? In some cases, this answer might be obvious. A
single customer manager might be willing to act as the signatory to the agreement. In other
cases, it might require negotiating or cajoling to find a representative volunteer. Volunteers
often want to express their personal views rather than represent a consensus. It might be
necessary for all customers to sign the agreement.
Sometimes customer representatives can genuinely represent the views of the customer
community. Perhaps they frequently meet with a wide selection of customers. This situation
is ideal. Unfortunately, often representatives are from the head office and seldom meet
service customers. In the worst case, SLM might have to perform their own program of
discussions and meetings with customers to ensure that true requirements are identified.
An example of differing needs of an organization:
Regarding negotiating the current and support hours for a large service, an
organization found a discrepancy. This discrepancy was in the required time of
usage between Head Office and the customers of a field office. Head Office (with
a limited user population) wanted service hours covering 8:00 a.m. to 6:00 p.m.,
whereas the field office (with at least 20 times the user population) stated that
starting an hour earlier would be better. However, all offices closed to the public
by 4:00 p.m. at the latest, and would not require a service much after 4:00 p.m.
Head Office was given preference, and so the 8:00 a.m. to 6:00 p.m. hours of
operation were set. The service was put into use and monitored. It was found that
3-49

service extensions were typically requested by the field office to cover the extra
hour in the morning. Actual usage figures showed that the service was not used
after 5:00 p.m., except on very rare occasions. The Service Level Manager was
blamed by the IT staff for having to cover a late shift. In addition, the customer
representative blamed the Service Level Manager for charging for an unused
service that included staff and running costs.
Care should be taken when opening discussions on service levels for the first time. It is
likely that current issues (the failure that occurred yesterday) or long-standing grievances
(that old printer that the company has been trying to get replaced for ages) are likely to be
aired at the outset. Important though these might be, they must not be permitted to interfere
with establishing the longer-term requirements. However, that you might have to address
any issues raised at the outset before you gain the credibility to progress further.
If there has been no previous experience of SLM, then start with a draft SLA. A decision
should be made regarding which service or customers are to be used for the draft. It is
helpful if the selected customer is enthusiastic and wants to participate, perhaps because
they are anxious to see improvements in service quality. The results of an initial customer
perception survey might give pointers to a suitable initial draft SLA.
One difficulty sometimes encountered is that staff at different levels within the customer
community might have different objectives and perceptions. For example, a senior manager
might rarely use a service. The manager might be more interested in issues such as value
for money and output. However, a junior staff member staff might use the service
throughout the day and might be more interested in issues such as responsiveness, usability,
and reliability. It is important that all of the appropriate and relevant customer requirements,
at all levels, are identified and incorporated in SLAs.
The Service Design Package is passed from Service Design to Service Transition. The SDP
details all aspects and requirements of the service. These details are provided through all of
the subsequent stages of the lifecycle of the service.
3-50

Service Level Manager

Service Level Manager

Keeping aware of changing business needs
Ensuring that the current and future service requirements
of customers are identified, understood, and documented
in SLA and SLR documents
Negotiating and agreeing upon levels of service to be
delivered to the customer (either internal or external)
Formally documenting these levels of service in SLAs
Negotiating and agreeing upon OLAs and, in some cases,
other SLAs and agreements that underpin the SLAs with
the customers of the service
39
The main role of the SLM Process is that of the Service Level Manager. The Service Level
Manager ensures that the aims of Service Level Management are met.
3-51

Process of Capacity Management
Lesson 4: Process of Capacity Management
Lesson 4: Process of Capacity

Management
3-52

Capacity Management
Capacity Management
Process that extends across the Service Lifecycle
Supported initially in Service Strategy where decisions
and analysis of business requirements customer
outcomes influence the development of:
Patterns of business activity (PBA)
Levels of service (LOS)
Service level packages (SLPs)
Provides predictive and ongoing capacity indicators

needed to align capacity to demand
41
3-53

Purpose and Goals of Capacity Management

Purpose and Goals of Capacity Management

To provide a point of focus and management for all
capacity-related and performance-related issues for both
services and resources
42
The goals of the Capacity Management process are:
To ensure that cost-justifiable IT capacity in all areas of IT always exists
To ensure that capacity is matched to the current and future agreed-upon needs of
the business in a timely manner
The Capacity Management process should:
3-54
Be the center of all IT performance and capacity issues
Encompass all areas of technology
Consider space planning and environmental systems capacity
Understand the IT and business environments including:
The current business operation and its requirements, through the patterns of
business activity
The future business plans and requirements using the Service Portfolio
The service targets and the current IT service operation though SLAs and
Standard Operating Procedures

All areas of IT technology and its capacity and performance, including

infrastructure, data, environment, and applications
Understand the potential for the delivery of new services
3-55

Capacity Management Objectives

Capacity Management Objectives

Create and maintain a valid Capacity Plan
Give guidance to all other areas of the business and IT
Ensure that service achieves agreed performance targets
Help diagnose and resolve performance and capacity
related incidents and problems
Assess impact of changes on Capacity Plan
Assess impact of changes on performance and capacity
Ensure implementation of proactive performance
improvement measures
43
The objectives of Capacity Management are to:
3-56
Create and maintain a valid Capacity Plan reflecting the current and future needs
of the business
Give guidance to all other areas of the business and IT on capacity and
performance-related issues
Ensure that service achieves or exceeds all agreed performance targets by

managing the performance and capacity of services and resources
Help diagnose and resolve performance-related and capacity-related incidents and

problems
Assess the impact of all changes on the Capacity Plan
Assess the impact of changes on performance and capacity of all services and
resources
Ensure the implementation of proactive performance improvement measures

whenever it is cost-justifiable

Benefits of Capacity Management

Benefits of Capacity Management

Capacity Management provides information on current
and planned resource utilization of individual
components. This assists the organization in making
confident decisions on:
Which components to upgrade
When to upgrade
How much the upgrade will cost
44
Capacity Management ensures that IT resources are appropriately planned and scheduled.
Therefore, the service organization can provide a consistent level of service that is matched
to the current and future needs of the business. These needs are agreed and documented
within SLAs and OLAs.
In conjunction with the business and their plans, Capacity Management provides a
Capacity Plan. This plan outlines the IT resources and funding needed to support the
business plan and a cost justification of that expenditure.
3-57

Capacity Management Activities

Capacity Management Activities

Contains three subprocesses:
Business Capacity Management
Service Capacity Management
Component Capacity Management
45
Capacity Management three subprocesses:
Business Capacity Management: translates business needs and plans into

requirements for service and IT infrastructure. This process ensures that the future
business requirements for IT services are quantified, designed, planned and
implemented on schedule.
Service Capacity Management: focuses on the management, control, and

prediction of the performance lifecycle and capacity of the live, operational IT
services usage and workloads. It ensures that the performance of all services is
monitored and measured. In addition, it ensures that the collected data is recorded,
analyzed and reported.
Component Capacity Management: focuses on the management, control and

prediction of the performance, utilization and capacity of individual IT
technology components. It ensures that all components are monitored and
measured. In addition, it ensures that the collected data is recorded, analyzed and
reported.
Capacity Management contains activities that are both proactive and reactive. The
proactive activities include:
3-58
Preventing performance issues by taking the necessary actions before they occur

Producing trends of the current component utilization
Using trend information to estimate future requirements, and plan for upgrades
and enhancements
Modeling and trending the predicted changes in IT services
Ensuring that upgrades are budgeted, planned and implemented before SLAs and
service targets or performance issues
Improving service performance wherever it is cost justifiable
Adjusting and optimizing the performance of services and components
The reactive activities of Capacity Management include:
Monitoring, measuring, reporting, and reviewing the current performance of both

services and components
Responding to all events that involve capacity, and instigating corrective action
Reacting to and assisting with specific performance issues relating to capacity
All of the information accumulated during these activities should be stored in the Capacity
Management Information System (CMIS). process. Information contained within the
CMIS is stored and analyzed by all the sub-processes of Capacity Management. It is a
repository that holds a number of different types of data, including business, service,
resource or utilization, and financial data, from all areas of technology. The CMIS is
unlikely to be a single database, and probably exists in several physical locations. The data
stored in the CMIS include the following types:
Business data
Service data
Component utilization data
Financial data
3-59

Modeling and Trending

Modeling and Trending

Baselining
Trend Analysis
Analytical Modeling
Simulation Modeling
Application Sizing
46
A prime objective of Capacity Management is to predict the behavior of IT services under

a given volume and variety of work. Modeling is an activity that can be used to beneficial
effect in any of the sub-processes of Capacity Management.
Baselining
The first stage in modeling is to create a baseline model that accurately reflects
performance. When this baseline model has been created, predictive modeling can be done.
If the baseline model is accurate, then the accuracy of the result of the potential failures and
changes can be trusted. Effective Capacity Management, together with modeling
techniques, facilitates Capacity Management to answer questions about what could happen
in various circumstances. For example: What if the throughput of Service A doubles?
Trend Analysis
Trend analysis can be done on the resource utilization and service performance information
that has been collected by the Capacity Management process. Typically, trend analysis only
provides estimates of future resource utilization information.
3-60

Analytical Modeling
Analytical models are representations of the behavior of computer systems using
mathematical techniques. The technique of analytical modeling requires less time and
effort than simulation modeling, but typically it gives less accurate results.
Simulation Modeling
Simulation involves the modeling of discrete events. An example of this is, transaction
arrival rates against a given hardware configuration. This type of modeling can be very
accurate in sizing new applications or predicting the effects of changes on existing
application. However, it can also be very time-consuming and costly.
Application Sizing
The main objective of application sizing is to estimate the resource requirements to support
a proposed change or new service. This estimate will ensure that it meets its required
service levels. To achieve this goal, application sizing has to be an integral part of the
Service Lifecycle.
Application sizing has a finite life span. It is initiated at the design stage for a new service,
or when there is a major change to an existing service, and is completed when the
application is accepted into the live operational environment. Sizing activities should
include all areas of technology related to the applications, and not just the applications
themselves. These areas should include the infrastructure, environment, and data.
Application sizing will often use modeling and trending techniques.
The sizing of the application should be refined as the design and development process
progresses.
3-61

Capacity Management Inputs

Capacity Management Inputs

Business information from the business strategy, plans,
financial plans, and current and future requirements
Service and IT information from Service Strategy, the IT
strategy and plans, and current budgets
Component performance and capacity information from
manufacturers and suppliers
Service performance issues from the Incident and
Problem Management processes with incidents and
problems relating to poor performance
Service information from the SLM process
47
Other sources of input include:
3-62
Financial information from Financial Management Change information from the

Change Management process
Performance information from the Capacity Management Information System

(CMIS) on the current performance of all services and IT infrastructure
components
Information on the relationships between the business, the services, the supporting
services and the technology from the CMS
Workload information from the IT Operations team

Capacity Management Outputs

Capacity Management Outputs

The Capacity Management Information System (CMIS):
holds the information needed by all subprocesses within
Capacity Management
The Capacity Plan: used by all areas of the business and
IT management. It is acted on by the IT service provider
and senior management of the organization to plan the
capacity of the IT infrastructure
Service performance information and reports: used by
many other processes. For example, it assists the
Financial Management process by identifying when
money needs to be budgeted for IT infrastructure
upgrades, or the purchase of new components
48
Further examples of information Capacity Management provides include:
Workload analysis and reports: used by IT Operations to assess and implement

changes in conjunction with Capacity Management
Ad hoc capacity and performance reports: used by all areas of Capacity

Management, IT and the business to analyze and resolve service and performance
issues
Forecasts and predictive reports: used by all areas to analyze, predict and forecast
particular business and IT scenarios and their potential solutions
Thresholds, alerts and events
3-63

Capacity Management KPIs

Capacity Management KPIs

Accurate business forecasts
Knowledge of current and future technologies
Ability to demonstrate cost-effectiveness
Ability to plan and implement the appropriate IT capacity
to match business needs
49
3-64

Capacity Management Challenges, Success

Factors, and Risks
Capacity Management Success Factors

Accurate business forecasts
Knowledge of current and future technologies
Ability to demonstrate cost-effectiveness
Ability to plan and implement the appropriate IT capacity
to match business need
50
Some of the challenges facing Capacity Management are:

Persuading the business to provide information on its strategic business plans
Combining all of the CCM data into an integrated set of information that can be
consistently analyzed to provide usage details for all components of the services
Analyzing the huge amounts of information produced by BCM, SCM and CCM
Some of the major risks associated with Capacity Management include:
A lack of commitment from the business
A lack of appropriate information from the business on future plans and strategies
A lack of senior management commitment
A lack of resources for the Capacity Management process
SCM and CCM performed in isolation
The processes become too bureaucratic or manually intensive
3-65

3-66
The processes focus too much on the technology (CCM) and not enough on the
services (SCM) and the business (BCM)
The reports and information provided do not give the appropriate information to
the customers and the business

Capacity Manager
Capacity Manager
Ensure there is adequate IT capacity to meet required levels of
service
Ensure senior IT management is correctly advised on how to match
capacity and demand
Ensure use of existing capacity is optimized
Identify, with the Service Level Manager, capacity requirements
through discussions with the business users
Understand current usage of infrastructure and IT services
Understand the maximum capacity of each component
Perform sizing on all proposed new services and systems to identify
capacity requirements
Forecast capacity requirements based on business plans, usage
trends, and sizing of new services
51
The main role for the Capacity Management process is that of Capacity Manager. A
Capacity Manager is responsible for ensuring that the goals of Capacity Management are
met.
3-67

Process of Availability Management
Lesson 5: Process of Availability

Management
Lesson 5: Process of Availability

Management
3-68

Availability Management
The Availability Management process ensures that the
level of service availability delivered in all services
matches or exceeds the agreed upon levels in a cost
effective manner
Availability Management provides a point of focus and
management for all availability related issues
Availability Management ensures that availability targets
in all areas are measured and achieved
53
The responsibilities of the Availability Management process include:
Ensuring that the level of service availability delivered in all services matches or
exceeds the current and future agreed-upon needs of the business in a costeffective manner
Providing a point of focus and management for all availability-related issues for
both services and resources
Ensuring that availability targets in all areas are measured and achieved
Availability Management should perform the following activities:
Produce and maintain an appropriate and up-to-date Availability Plan, which

reflects the current and future needs of the business
Provide advice and guidance to all other areas of the business and IT on all
availability-related issues
Ensure that service availability objectives meet or exceed all of their agreed-upon
targets by managing services and resources related to availability performance
Assist with the diagnosis and resolution of availability-related incidents and

problems
3-69

Assess the impact of all changes on the Availability Plan
Assess the performance and capacity of all services and resources
Ensure that proactive measures to improve the availability of services are

implemented whenever the cost justifies it
Like Capacity Management, the Availability Management process and planning must be
involved in all stages of the service lifecycle. The appropriate availability and resilience
should be designed into services and components from the initial design stages. This early
design will ensure that the availability of any new or changed service meet expected targets.
In addition, it will ensure that all existing services and components continue to meet all of
their targets. This concept is the basis of stable service provision.
3-70

Availability, Reliability, Maintainability, and

Serviceability
Availability, Reliability, Maintainability, and Serviceability

Availability: Ability of a service, component, or
Configuration Item (CI) to perform the agreed-upon
function when required
Reliability: Measure of how long a service, component,
or Configuration Item can perform the agreed-upon
function without interruption
Maintainability: Measure of how quickly and effectively a
service, component, or Configuration Item can be
restored to normal working after a failure
Serviceability: Ability of suppliers to meet the terms of
their contracts
54
The reliability of the service can be improved by increasing the reliability of individual
components. In addition, it can be improved by increasing the resilience of the service to
individual component failure. An example is increasing the component redundancy by
using load-balancing techniques. The reliability of the service is often measured and
reported as Mean Time Between Service Incidents (MTBSI) or Mean Time Between
Failures (MTBF).
3-71

Proactive Versus Reactive Availability

Management
Proactive Versus Reactive Availability Management

Proactive Availability Management consists of producing
recommendations, plans and documents, on design
guidelines and criteria for new and changed services and
the continual improvement of service
Proactive Activities are a key part of Service Design and
Reactive Availability Management consists of monitoring,
measuring, analyzing, reporting, and reviewing all
aspects of component and service availability
55
3-72

Availability Management Process
A market space represents a set of opportunities for service providers to deliver value to the
business of a customer through one or more services. Often it is unclear how services create
value for customers. Services are often defined in the terms of resources made available for
customers to use. Service definitions lack clarity on two points:
Context in which such resources are useful
Business outcomes that justify the expense of a service from the customers
perspective
This problem leads to poor designs, ineffective operation, and lackluster performance in
service contracts. Service improvements are difficult when it is not clear where
improvements are truly required. Customers can understand and appreciate improvements
only within the context of their own business assets, performances, and outcomes. A correct
definition of services takes into account the context in which customers perceive value from
the services.
An outcome-based definition of services ensures that managers plan and carry out all
aspects of service management. Service management is performed entirely from the
perspective of what is valuable to the customer. Such an approach ensures that services not
only create value for customers but also capture value for the service provider.
3-73

The Availability Management process continually works to ensure that all operational
services meet their agreed-upon availability targets. In addition it strives to ensure that new
or changed services are designed appropriately to meet their intended targets. Furthermore
these goals are accomplished without compromising the performance of existing services.
In order to achieve this goal, Availability Management should perform the reactive and
proactive activities.
Solutions that enhance the performance of the customer assets indirectly support the
achievement of the outcomes generated by those assets. Such solutions and propositions
hold utility for the business. When that utility is backed by a suitable warranty, customers
are ready to buy. Services are a means of delivering value to customers by facilitating
outcomes customers want without owning specific costs and risks.
3-74

Availability
Availability
Downtime should only be included in this calculation

when it occurs within the Agreed Service Time (AST),
although total downtime should also be recorded and
reported
57
Availability is the ability of a service, component, or configuration item (CI) to perform its
agreed-upon function when required. It is often measured and reported as a percentage.
3-75

Availability Terms
3-76

Reliability
Reliability
Reliability is often measured and reported as

Mean Time Between Service Incidents (MTBSI) or
Mean Time Between Failures (MTBF)
59
Reliability is a measure of how long a service, component, or CI can perform its agreedupon function without interruption. The reliability of the service can be improved by
increasing the reliability of individual components. In addition reliability can be improved
by increasing the resilience of the service to individual component failure. An example is
increasing the component redundancy by using load-balancing techniques.
3-77

Maintainability
Maintainability
Example: A situation where a 24 x 7 service has been running

for a period of 5020 hours with only two breaks, one of 6 hours
and one of 14 hours, would give the following figures:
Availability = (5020 (6 + 14)) / 5020 x 100 = 99.60%
Reliability (MTBSI) = 5020 / 2 = 2510 hours
Reliability (MTBF) = 5020 (6 +14) / 2 = 2500 hours
Maintainability (MTRS) = (6 + 14) / 2 = 10 hours
60
Maintainability is a measure of how quickly and effectively a service, component, or CI can

be restored to normal operation after a failure. It is measured and reported as Mean Time
To Restore Service (MTRS) and should be calculated using the formula shown in the slide.
3-78

Other Availability Terms

Other Availability Terms

Serviceability: The ability of a supplier to meet the terms of their
contract. Often this contract will include agreed-upon levels of
availability, reliability, and maintainability for a supporting service or
component.
High Availability: A characteristic of the IT service that minimizes or
masks the effects of IT component failure to the users of a service.
Fault Tolerance: The ability of an IT service, component, or CI to
continue to operate correctly after failure of a component part.
Continuous Operation: An approach or design to eliminate planned
downtime of an IT service. Note that individual components or CIs
might not be functioning even though the IT service remains
available.
Continuous Av ailability: An approach or design to achieve 100%
availability. A continuously available IT service has no planned or
unplanned downtime.
61
3-79

Availability Management Goals

Availability Management Goals

to ensure that the level of service availability delivered in
all services meets or exceeds the current and future
agreed needs of the business
to ensure delivered services are met or exceeded, costeffectively
62
3-80

Availability Objectives
Availability Management Objectives

Produce and maintain a current and accurate Availability Plan that
reflects current and future needs of the business
Provide advice and guidance to all other areas of the business
and IT on all availability related issues
Ensure that service availability achievements meet or exceed all
agreed targets
Assist with diagnosis and resolution of availability related incidents
and problems
Assess impact of all changes on the Availability Plan and
performance and capacity of all services and resources
Ensure that proactive measures to improve the availability of
services are implemented wherever it can be cost justified
63
3-81

Availability Management Benefits

Availability Management Benefits

Ensures availability of systems and services matches
evolving agreed needs of the business
Ensures IT delivers right levels of service availability
required by the business to satisfy its business objectives
and customers
Results in in customer loyalty
Ensures not only that the availability of any new or
changed service meets its expected targets, but also that
all existing services and components continue to meet all
of their targets
64
3-82

Availability Management Activities

Availability Management Activities

Produce and maintain an appropriate and up-to-date Availability Plan,
which reflects the current and future needs of the business
Provide advice and guidance to all other areas of the business and IT
on all availability-related issues
Ensure service availability objectives meet or exceed all agreed-upon
targets by managing services and resources related to availability
performance
Assist with diagnosis and resolution of availability-related incidents
and problems
Assess impact of all changes on Availability Plan
Assess the performance and capacity of all services and resources
Ensure proactive improvements to availability are implemented
65
The responsibilities of the Availability Management process include:
Ensuring that the level of service availability delivered in all services matches or
exceeds the current and future agreed-upon needs of the business in a costeffective manner
Providing a point of focus and management for all availability-related issues for
both services and resources
Ensuring that availability targets in all areas are measured and achieved
Like Capacity Management, the Availability Management process and planning must be
involved in all stages of the service lifecycle. All stages include strategy and design through
transition and operation to improvement. The appropriate availability and resilience should
be designed into services and components from the initial design stages. This early design
will ensure that the availability of any new or changed service meet expected targets. It will
also ensure that all existing services and components continue to meet all of their targets.
These accomplishments are the basis of stable service provision.
3-83

Availability Management Interfaces

Availability Management Interfaces

Incident and Problem Management
Capacity Management
IT Service Continuity Management
66
Availability Management commences as soon as the availability requirements for an IT

Service are clear enough to be articulated. It is an ongoing process, finishing only when the
IT Service is decommissioned or retired.
The key interfaces that Availability Management has with other processes are as follows:
3-84
Incident and Problem Management: In providing assistance with the resolution

and subsequent, justification, and correction of availability incidents and
problems
Capacity Management: With the provision of resilience and spare capacity
IT Service Continuity Management: With the assessment of business impact

and risk and the provision of resilience, fail-over, and recovery mechanisms
Service Level Management: Assistance with the determining of availability

targets and the investigation and resolution of service and component breaches

Availability Management Inputs

Availability Management Inputs

Business information from the business strategy, plans,
financial plans, and current and future requirements
Business impact information supported by IT services
Previous Risk Analysis and Assessment reports and a
risk register
Service information from the Service Portfolio and the
Service Catalog
Service information: from the SLM process
Financial information: from Financial Management
67
Other sources of information that Availability Management uses include:
Change and release information from the Change Management process
Configuration Management information on the relationships between the

business, the services, the supporting services, and the technology
Service targets from SLAs, SLRs, OLAs and contracts
Component information on the availability, reliability, and maintainability

requirements for the technology components that underpin IT services
Technology information from the CMS on the topology and the relationships
between the components and the assessment of the capabilities of new technology
Past performance from previous measurements, achievements and reports and the
Availability Management Information System (AMIS)
Unavailability and failure information from incidents and problems
3-85

Availability Management Outputs

Availability Management Outputs

The Availability Management Information System (AMIS)
The Availability Plan for the proactive improvement of IT
services and technology
Availability and recovery design criteria and proposed
service targets for new or changed services
Service availability, reliability and maintainability reports
of achievements against targets
Component availability, reliability and maintainability
reports of achievements against targets
Revised risk analysis reviews and reports and an updated
risk register
68
Other outputs produced by Availability Management include:
3-86
Monitoring, management and reporting requirements for IT services and

components
An Availability Management test schedule for testing all availability, resilience

and recovery mechanisms
The planned and preventative maintenance schedules
The Projected Service Outage (PSO) in conjunction with Change and Release
Management
Details of the proactive availability techniques and measures that will be deployed
to provide additional resilience to prevent or minimize the impact of component
failures on the IT service availability
Improvement actions for inclusion within the Service Improvement Plan

Availability Management KPIs

Availability Management KPIs

Types:
KPIs that help to manage availability and reliability of IT
service
KPIs that help to satisfy business needs for access to IT
services
KPIs that help identify availability of IT infrastructure
achieved at optimum costs
69
KPIs that help to manage availability and reliability of IT service include:
Percentage reduction in the unavailability of services and components
Percentage increase in the reliability of services and components
Effective review and follow-up of all SLA, OLA and underpinning contract
breaches
Percentage improvement in overall end-to-end availability of service
Percentage reduction in the number and impact of service breaks
KPIs that help to satisfy business needs for access to IT services include:
Percentage reduction in the unavailability of services
Percentage reduction of the cost of business overtime due to unavailable IT
Percentage reduction in critical time failures
Percentage improvement in business and users satisfied with service by CSS

result
3-87

KPIs that help identify availability of IT infrastructure achieved at optimum costs include:
3-88
Percentage reduction in the cost of unavailability
Percentage improvement in the Service Delivery costs
Timely completion of regular Risk Analysis and system review
Timely completion of regular cost-benefit analysis

Availability Management Challenges, Success

Factors, and Risks
Availability Management Challenges

Meeting the expectations of the customers, the business
and senior management
Maintaining access to the right level of quality information
on the current business need for IT services and its plans
for the future
Integrating all of the availability data into information that
can be analyzed in a consistent manner to provide details
on the availability of all services and components
Convincing the business and senior management of the
investment needed in proactive availability measures
70
The main Critical Success Factors for the Availability Management process are:
Manage availability and reliability of IT service
Satisfy business needs for access to IT services
Availability of IT infrastructure, as documented in SLAs, provided at optimum

costs
Some of the major Risks associated with Availability Management include:
A lack of commitment from the business to the Availability Management process
A lack of commitment from the business and a lack of appropriate information on

future plans and strategies
A lack of senior management commitment to or a lack of resources, budget,or

both for the Availability Management process
The reporting processes becomes too labor intensive
3-89

3-90
The processes focuses too much on the technology and not enough on the services
and the needs of the business
The Availability Management information (AMIS) is maintained in isolation and

is not shared or consistent with other process areas

Availability Manager
Availability Manager
Ensures all existing services deliver the levels of
availability agreed with the business in SLAs
Assists with investigation and diagnosis of all incidents
and problems that cause availability issues or
unavailability of services or components
Participates in the IT infrastructure design, including the
specification of the availability requirements for hardware
and software
Proactively improves service availability wherever
possible and optimizes availability of IT infrastructure
Assists with the assessment and management of risk
71
The main role for the Availability Management process is that of Availability Manager. The
Availability Manager has responsibility for ensuring that the aims of Availability
Management are met.
3-91

Process of IT Service Continuity Management
Lesson 6: Process of IT Service Continuity

Management
Lesson 6: Process of IT Service

Continuity Management
3-92

IT Service Continuity Management Goal

IT Service Continuity Management Goal

Make certain that IT technical facilities and service
facilities can be resumed within the required time frame
These facilities include:
Computer systems
Networks
Applications
Data repositories
Telecommunications
Environment
Technical support
Service Desk
73
Most business processes rely heavily on technology. Therefore, it is critical that IT maintain
a high level of availability. To keep technology available, it is essential to establish risk
reduction measures and recovery options. The purpose of IT Service Continuity
Management (ITSCM) is to maintain the necessary ongoing recovery capability within the
IT services and their supporting components.
ITSCM provides a crucial role in supporting the Business Continuity Planning process. In
many organizations, it is used to increase awareness of continuity and recovery
requirements. In addition, it is often used to justify and implement a Business Continuity
Planning process and Business Continuity Plans.
3-93

ITSCM Objectives
ITSCM Objectives
Maintain IT Service Continuity and IT recovery plans
Complete regular Business Impact Analysis exercises
Conduct regular Risk Analysis and Management exercises
Provide continuity and recovery advices to other areas
Ensure continuity and recovery mechanisms are put in place
Assess impact of all changes on continuity and recovery
plans
Ensure proactive plans are in place when necessary
Negotiate contracts with recovery capability suppliers
74
ITSCM focuses on those events that the business considers significant enough to be
considered a disaster. Less significant events will be dealt with as part of the Incident
Management process. What constitutes a disaster will vary from organization to
organization. The scope of ITSCM within an organization is determined by the
organizational structure, culture, and strategic direction (both business and technology).
This scope is identified in terms of the services provided and how these develop and change
over time.
3-94

IT Service Continuity Management Benefits

IT Service Continuity Management Benefits

Can be used to raise awareness of continuity and
recovery requirements
Can be used to justify and implement a Business
Continuity Planning process and Business Continuity
Plans
Ensures that the recovery arrangements for IT services
are aligned to identified business impacts, risks and
needs
75
ITSCM provides an important role in supporting the Business Continuity Planning process.
3-95

ITSCM Activities
ITSCM Activities
Agree on scope of ITSCM process and policies
Conduct Business Impact Analysis (BIA) of loss of IT
service
Conduct Risk Analysis (RA) to identify possibility and
likelihood of threats to continuity
Develop overall ITSCM strategy
Develop ITSCM plan
Test plans
Operate and maintain plans
76
The ITSCM activities take place in the following stages:

Stage 1: Initiation
3-96
Set the policy. This step should be established and communicated to all affected
members of the organization.
Specify terms of reference and scope: This step includes defining the scope and
responsibilities of all staff in the organization.
Allocate the resources. In this step financial and manpower resources are
allocated.
Define the project organization and control structure. In this step, it is

recommended to use standard project planning methodology.
Agree on project and quality plans.

Stage 2: Requirements and Strategy
Requirements: Perform Business Impact Analysis and risk assessment. The

purpose of a Business Impact Analysis (BIA) is to quantify the impact to the
business that loss of service would have. The BIA identifies:
The form that the damage or loss might take
How the degree of damage or loss is likely to escalate and the time and
severity of the service disruption
The staffing, skills, facilities and services
The time within which minimum levels of staffing, facilities and services
should be recovered
The time within which all required business processes and supporting staff,
facilities and services should be fully recovered
The relative business recovery priority for each of the IT services
Strategy: Following the requirements analysis, the strategy should document the
required risk reduction measures and recovery options to support the business.
This is an assessment of the level of threat and the extent to which an organization
is vulnerable to that threat. Risk Analysis can also be used in assessing and
reducing the chance of normal operational incidents and is a technique used by
Availability Management to ensure the required availability and reliability levels
can be maintained.
Stages one and two are mostly Business Continuity Management (BCM) activities. ITSCM
should only be involved in these stages for the following reasons:
To support the BCM activities
To understand the relationship between the business processes
To understand the impacts caused by loss of IT service
As a result of these initial Business Impact Analysis and Risk Analysis activities, BCM
should produce a Business Continuity Strategy. The first real ITSCM task is to produce an
ITSCM strategy that supports the BCM strategy and its needs.
The Business Continuity Strategy should focus on business processes and associated issues
(for example, business process continuity, staff continuity, buildings continuity).
Stage 3: Implementation
3-97

You can develop an ITSCM strategy that supports the Business Continuity Strategy after
the following tasks have been completed:
You have produced the Business Continuity Strategy.
You have identified the role that IT services will provide within the strategy.
Therefore, cost-effective decisions can be made, considering all the resources needed to
deliver a business process. After the strategy has been approved, the IT Service Continuity
Plans must be produced in line with the Business Continuity Plans. Be sure to properly test
these plans before final implementation.
Stage 4: Ongoing Operation
This stage consists of the following activities:
3-98
Education, awareness, and training
Review
Testing
Change Management
Invocation of the Business Continuity Plans

ITSCM Interfaces
ITSCM Interfaces
IT Service Continuity Management (ITSCM)
Service Level Management (SLM)
Change Management
Legal and Human Resources (HR) Department
Configuration Management
Capacity Management
Supplier Management
77
Incident and Problem Management: This provides assistance with the resolution and
subsequent, justification, and correction of security incidents and problems. The Incident
Management process must include the ability to identify and deal with security incidents.
Service Desk and Service Operation staff must recognize a security incident.
IT Service Continuity Management (ITSCM): ITSCM deals with the assessment of
business impact and risk and the provision of resilience, failover, and recovery
mechanisms. Security is a major issue when continuity plans are tested or invoked. A
working ITSCM plan is a mandatory requirement for ISO27001.
Service Level Management (SLM): SLM provides assistance with the determining of
security requirements and responsibilities. It also ensures their inclusion within SLRs and
SLAs. In addition, SLM promotes the investigation and resolution of service and
component security breaches.
Change Management: ISM should help assess every change for impact on security and
security controls. Also ISM can provide information about unauthorized changes.
Legal and Human Resources (HR) Department: Legal and HR issues must be
considered when investigating security issues.
Configuration Management: Configuration Management gives the ability to provide
accurate asset information to assist with security classifications. Having an accurate
Configuration Management System (CMS) is therefore an extremely useful ISM input.
3-99

Capacity Management: Capacity Management must consider security implications when

selecting and introducing new technology. Security is an important consideration when
procuring any new technology or software.
Financial Management: Financial Management provides adequate funds required to
finance security requirements.
Supplier Management: Supplier Management assists with the joint management of
suppliers and their access to services and systems. In addition, it makes available the terms
and conditions to be included within contracts concerning supplier responsibilities.
Security is often seen as an element of Availability Management with Confidentiality
Integrity and Availability (CIA) being at the essence of Availability and ISM. Also ISM
should work with both Availability Management and IT Service Continuity Management
(ITSCM) to conduct integrated risk assessment and management exercises.
3-100

ITSCM Inputs
ITSCM Inputs
Business information
IT information
A Business Continuity Strategy and a set of Business
Continuity Plans
Service information
Financial information
Configuration Management System
Business Continuity Management and Availability
Management testing schedules
IT Service Continuity Plans and test reports
78
There are many sources of input required by the ITSCM process. Some of them are:
Business information from the business strategy, plans, financial plans, and
current and future requirements
IT information from the IT strategy and plans and current budgets
A Business Continuity Strategy and a set of Business Continuity Plans from all
areas of the business
Financial information from Financial Management
Configuration Management System containing information on the relationships

between the business, the services, the supporting services and the technology
Business Continuity Management and Availability Management testing schedules
IT Service Continuity Plans and test reports from supplier and partners, where
appropriate
3-101

ITSCM Outputs
ITSCM Outputs
A revised ITSCM policy and strategy
A set of ITSCM plans
Supporting plans and contracts with recovery service
providers
Business Impact Analysis exercises and reports
Risk Analysis and Management reviews and reports
An ITSCM testing schedule
ITSCM test scenarios
ITSCM test reports and reviews
79
ITSCM plans include:
Crisis Management plans
Emergency Response plans
Disaster Recovery plans
Business Impact Analysis exercises and reports are produced in conjunction with Business
Continuity Management and the business.
Risk Analysis and Management reviews and reports are produced in conjunction with the
business, Availability Management, and Security Management.
3-102

ITSCM KPIs
ITSCM Key Performance Indicators

Regular audits of the ITSCM Plans
All service recovery targets agreed on and documented in
SLAs
Testing of ITSCM Plans
Regular reviews
Negotiation and management of contracts
Reduction in the risk and impact of possible failure
Notification of the plans
80
ITSCM should include:
Regular audits of the ITSCM Plans to ensure that, at all times, the agreed recovery
requirements of the business can be achieved
All service recovery targets are agreed and documented in SLAs and are
achievable within the ITSCM Plans
Regular and comprehensive testing of ITSCM Plans
Regular reviews are undertaken of the business and IT continuity plans with the
business areas
Negotiation and management of all necessary ITSCM contracts with third party
Overall reduction in the risk and impact of possible failure of IT services
3-103

3-104
Notification throughout the organizations of the plans. This ensures:
Awareness of business impact, needs, and requirements throughout IT
That all IT service areas and staff are prepared and able to respond to an
invocation of the ITSCM Plans
Regular communication of the ITSCM objectives and responsibilities within

the appropriate business and IT service areas

ITSCM Challenges, Critical Success Factors,

and Risks
ITSCM Challenges
providing appropriate plans when there is no BCM
process
ensuring that accurate information is obtained from the
BCM process on the needs, impact and priorities of the
business
ensuring that the ITSCM information and plans are
aligned and integrated with those of the business
keeping them aligned by management and control of
business and IT change
81
The main Critical Success Factors for the ITSCM process are:
IT services are delivered and can be recovered to meet business objectives.
Awareness throughout the organization of the business and IT Service Continuity

Plans.
Some of the major risks associated with ITSCM include:
Lack of commitment from the business to the ITSCM processes and procedures
Lack of commitment from the business and a lack of appropriate information on

future plans and strategies
Lack of senior management commitment or a lack of resources and/or budget for

the ITSCM process
The processes focus too much on the technology issues and not enough on the IT
services and the needs and priorities of the business
3-105

3-106
Risk Analysis and Management are conducted in isolation and not in conjunction
with Availability Management and Security Management
ITSCM plans and information become out-of-date and lose alignment with the
information and plans of the business and BCM

Service Continuity Manager

Service Continuity Manager

Performing Business Impact Analyzes for all existing and
new services
Implementing and maintaining the ITSCM process
Ensuring that all ITSCM plans, risks and activities
underpin and align with all BCM plans, risks and activities
Ensuring the ITSCM plans are capable of meeting the
agreed and documented targets under any circumstances
Performing risk assessment and risk management to
prevent disasters where cost-justifiable and where
practical
Developing and maintaining the continuity strategy
82
The main role for the ITSCM process is that of IT Service Continuity Manager. The IT
Service Continuity Manager has responsibility for ensuring that the aims of ITSCM
Management are met.
Further responsibilities for this role include:
Assessing potential service continuity issues and invoking the Service Continuity
Plan if necessary
Managing the Service Continuity Plan while it is in operation, including fail-over

to a secondary location and restoration to the primary location
Performing post mortem reviews of service continuity tests and invocations, and
instigating corrective actions where required
Developing and managing the ITSCM plans to ensure that, at all times, the
recovery objectives of the business can be achieved
Ensuring that all IT service areas are prepared and able to respond to an
invocation of the continuity plans
Maintaining a comprehensive IT testing schedule, including testing all continuity

plans in line with business requirements and after every major business change
3-107

3-108
Undertaking quality reviews of all procedures and ensuring that these are
incorporated into the testing schedule
Communicating and maintaining awareness of ITSCM objectives within the

business areas supported and IT service areas
Undertaking regular reviews, at least annually, of the Continuity Plans with the
business areas to ensure that they accurately reflect the business needs
Negotiating and managing contracts with providers of third-party recovery

services
Assessing changes for their impact on Service Continuity and Continuity Plans
Attending CAB meetings when appropriate

Process of Information Security Management
Lesson 7: Process of Information Security

Management
Lesson 7: Process of Information

Security Management
3-109

Information Security Management (ISM)

Information Security Management (ISM)

The ISM process aligns IT security with business security
and ensures that information security is effectively
managed in all service and Service Management
activities
ISM manages all aspects of IT and information security
within all areas of IT and Service Management activity
Security must address entire business processes from
end to end and cover the physical and technical aspects
84
The term information is used in a general way and includes data stores, databases, and
metadata. Information security protects the interests of those relying on information, and
the systems and communications that deliver the information. It protects the interests from
harm resulting from failures of availability, confidentiality, and integrity.
To be effective, security must address entire business processes from end to end and cover
the physical and technical aspects. ISM raises the awareness of the need for security within
all IT services and assets throughout the organization. ISM manages all aspects of IT and
information security within all areas of IT and Service Management activity.
ISM provides assurance of business processes by enforcing appropriate security controls in
all areas of IT. In addition, it manages IT risk in line with business and corporate risk
management processes and guidelines.
3-110

Security Framework
Security Framework
Information Security Policy (ITP) and specific security
policies that address each aspect of strategy, controls,
and regulation
Information Security Management System (ISMS),
containing the standards, management procedures and
guidelines supporting the information security policies
A comprehensive security strategy closely linked to the
business objectives, strategies, and plans
A set of security controls to support the ITP
Monitoring processes to ensure compliance and provide
feedback on effectiveness
Training and awareness strategy and plan
85
The Information Security Management process and framework will typically consist of the
following items:
An Information Security Policy (ITP) and specific security policies that address
each aspect of strategy, controls and regulation
An Information Security Management System (ISMS), containing the standards,

management procedures, and guidelines supporting the information security
policies
A comprehensive security strategy closely linked to the business objectives,

strategies, and plans
An effective security organizational structure
A set of security controls to support the ITP
The management of security risks
Monitoring processes to ensure compliance and provide feedback on effectiveness
Communications strategy and plan for security
Training and awareness strategy and plan
3-111

Contents of the Information Security Policy

(ITP)
Contents of the Information Security Policy (ITP)

Use and misuse of IT assets policy
An access control policy
A password control policy
An e-mail policy
An Internet policy
An antivirus policy
An information classification policy
A policy with regard to supplier access of IT service,
information and components
An asset disposal policy
86
Information Security Management activities should be focused on and driven by an overall

Information Security Policy (ITP) and a set of underpinning specific security policies. The
ITP should have the full support of top executive IT management and ideally the support
and commitment of top executive business management. The ITP should cover all areas of
security, be appropriate, meet the needs of the business and include the following items:
3-112
An overall ITP
The use and misuse of IT assets policy
An access control policy
A password control policy
An e-mail policy
An Internet policy
An antivirus policy
An information classification policy
A document classification policy

A remote access policy
A policy with regard to supplier access of IT service, information, and

components
An asset disposal policy
These policies should be widely available to all customers and users. All SLRs, SLAs,
contracts, and agreements should refer to compliance with these policies. The policies
should be authorized by top executive management within the business and IT. Compliance
should be endorsed on a regular basis. All security policies should be reviewed and, when
necessary, revised on at least an annual basis.
3-113

Information Security Process
3-114

Information Security Management Goal and

Objectives
Information Security Management Objectives

Information is available and usable when required and the
systems that provide it can appropriately resist attacks
and recover from or prevent failures (availability)
Information is only observed by, or disclosed to, those
who have a right to know (confidentiality)
Information is complete, accurate, and protected against
unauthorized modification (integrity)
Business transactions as well as information exchanges
between enterprises, or with partners, can be trusted
(authenticity and nonrepudiation)
88
The goal of the Information Security Management (ISM) process is to align IT security
with business security. In addition, it ensures that information security is effectively
managed in all service and Service Management activities.
3-115

Information Security Management Benefits

Information Security Management Benefits

Ensures that an Information Security Policy is maintained
and enforced that fulfills the needs of the Business
Security Policy and the requirements of corporate
governance
Raises awareness of the need for security within all IT
services and assets throughout the organization, ensuring
that the policy is appropriate for the needs of the
organization
Manages all aspects of IT and information security within
all areas of IT and Service Management activity
Provides assurance of business processes by:
enforcing appropriate security controls in all areas of IT
managing IT risk in line with business and corporate risk
management processes and guidelines
89
3-116

Information Security Management Activities

Information Security Management Activities

Production, review and revision of security policy
Communication, implementation, and enforcement of
security policy
Assessment and classification
Monitoring and management of security breaches and
incidents
Schedule and completion
90
The key activities within the ISM process are:
Production, review, and revision of an overall Information Security Policy and a

set of supporting specific policies
Communication, implementation, and enforcement of the security policies
Assessment and classification of all information, assets, and documentation
Implementation, review, revision, and improvement of a set of security controls

and risk assessment and responses
Monitoring and management of all security breaches and major security incidents
Analysis, reporting, and reduction of the volume and impact of security breaches
and incidents
Schedule and completion of security reviews, audits, and penetration tests
3-117

Information Security Management Interfaces

Information Security Management (ISM) Interfaces

Change Management
Legal and Human Resources Department
Capacity Management
Supplier Management
91
Incident and Problem Management: This provides assistance with the resolution and
subsequent, justification, and correction of security incidents and problems. The Incident
Management process must include the ability to identify and deal with security incidents.
Service Desk and Service Operation staff must recognize a security incident.
IT Service Continuity Management: ITSCM deals with the assessment of business impact
and risk and the provision of resilience, failover, and recovery mechanisms. Security is a
major issue when continuity plans are tested or invoked. A working ITSCM plan is a
mandatory requirement for ISO27001.
Service Level Management: SLM provides assistance with the determining of security
requirements and responsibilities. It also ensures their inclusion within SLRs and SLAs. In
addition, SLM promotes the investigation and resolution of service and component security
breaches.
Change Management: ISM should help assess every change for impact on security and
security controls. Also ISM can provide information about unauthorized changes.
Legal and Human Resources Department: Legal and HR issues must be considered
when investigating security issues.
Configuration Management: Configuration Management gives the ability to provide
accurate asset information to assist with security classifications. Having an accurate
Configuration Management System (CMS) is therefore an extremely useful ISM input.
3-118

Capacity Management: Capacity Management must consider security implications
when selecting and introducing new technology. Security is an important

consideration when procuring any new technology or software.
Financial Management: Financial Management provides adequate funds required to

finance security requirements.
Supplier Management: Supplier Management assists with the joint management of
suppliers and their access to services and systems. In addition, it makes available the terms
and conditions to be included within contracts concerning supplier responsibilities.
Security is often seen as an element of Availability Management with Confidentiality
Integrity and Availability (CIA) being at the essence of Availability and ISM. Also ISM
should work with both Availability Management and IT Service Continuity Management
(ITSCM) to conduct integrated risk assessment and management exercises.
3-119

Information Security Management Inputs

Information Security Management Inputs

Corporate governance and business security policies
IT information
Service information
Risk Analysis processes and reports
Details of all security events and breaches
Change information
Details of partner and supplier access
92
3-120
Corporate governance and business security policies and guidelines, security

plans, and risk analysis and responses
IT information from the IT strategy, plans, and current budgets
Service information from the SLM process with details of the services from the
Service Portfolio and the Service Catalog, SLAs, and SLRs
Risk Analysis processes and reports from ISM, Availability Management, and
ITSCM
Details of all security events and breaches from all areas of IT and SM, especially
Incident Management and Problem Management
Change information from the Change Management process to assess all changes
for their impact on security policies, plans, and controls
CMS containing information on the relationships between the business, the

services, supporting services, and the technology
Details of partner and supplier access from Supplier Management and Availability
Management on external access to services and systems

Information Security Management Outputs

Information Security Management Outputs

Information Security Management Policy
Security Management Information System (SMIS)
Revised security risk assessment
A set of security controls
Security audits
Security test schedules and plans
A set of security classifications
Reviews and reports
Policies, processes and procedures
93
An overall Information Security Management Policy with a set of specific

security policies
A Security Management Information System (SMIS) that contains all the

information relating to ISM
Revised security risk assessment processes and reports
A set of security controls with details and risks of the operation and maintenance
Security audits and audit reports
Security test schedules and plans, including security penetration tests and other
security tests and reports
A set of security classifications and a set of classified information assets
Reviews and reports of security breaches and major incidents
Policies, processes, and procedures for managing partners and suppliers and their
access to services and information
3-121

Information Security Management KPIs

Information Security Management KPIs

Percentage decrease in security breaches reported to the
Service Desk
Percentage decrease in the impact of security breaches
and incidents
Decrease in the number of non-conformances of the ISM
process with the business security policy and process
Increase in the acceptance and conformance of security
procedures
Increased support and commitment of senior
management
94
Further Information Security Management KPIs include:
3-122
The number of suggested improvements to security procedures and controls
Decrease in the number of security nonconformance detected during audits and

security testing
Increase in the number of services and processes that conform with security
procedures and controls
Increased awareness of the security policy and its contents, throughout the
organization
Percentage increase in completeness of the technical Service Catalog against IT

components supporting the services
Service Desk supporting all services

ISM Challenges, Success Factors, and Risks

Information Security Management Challenges

Ensuring there is enough support from the business,
business security, and senior management
Ensuring that accurate information is obtained from the
business security process on the needs, risks, impact,
and priorities of the business
Ensuring that the ISM policies, information, and plans are
aligned and integrated with those of the business
Keeping the policy, information, and plans aligned by
management and control of business and IT change
using strict Change Management and Configuration
Management control
95
ISM has the following main critical success factors:
Protection against security violations
Determination of a concise policy, integrated with the needs of the business
Justification of security procedures that are appropriate and supported by senior

management
Education for and marketing of security requirements
Establishment of a mechanism for improvement
Integration of information security in all IT services and ITSM processes
Protection of the availability of services against security incidents
Establishment of clear ownership of the security policies among the customer

community
3-123

Some of the risks that threaten effective ISM include:
3-124
Increasing requirements for availability and robustness
Growing potential for misuse and abuse of information systems affecting privacy
and ethical values
External dangers from hackers, leading to denial of service, virus attacks,

extortion, industrial espionage, and organizational or private data leaks

Security Manager
Security Manager
Managing all aspects of the Information Security Policy
Identifying and classifying IT and information assets
Performing security risk analysis and risk management
Monitoring and managing all security breaches
Reducing impact and volume of security incidents
Ensuring all changes are assessed for impact on security
Ensuring confidentiality, integrity, and availability are
maintained
Ensuring access to services subject to contractual agreements
Acting as a focal point for security issues
96
The Security Manager responsibilities explained in more detail:
Developing, maintaining, and communicating the Information Security Policy
Identifying and classifying IT and information assets (Configuration Items) and

the level of control and protection required
Performing security risk analysis and risk management in conjunction with

Availability and IT Service Continuity Management
Monitoring and managing all security breaches and handling security incidents
and taking remedial action to prevent recurrence wherever possible
Reporting, analyzing, and reducing the impact and volumes of all security
incidents in conjunction with Problem Management
Ensuring that all changes are assessed for impact on all security aspects
Ensuring that the confidentiality, integrity, and availability of the services are
maintained at the levels agreed upon in the SLAs
Ensuring that all access to services by external partners and suppliers is subject to
contractual agreements and responsibilities
3-125

Process of Supplier Management
Lesson 8: Process of Supplier Management
Lesson 8: Process of Supplier

Management
3-126

Supplier Management
Supplier Management
Supplier Management process manages suppliers and
the services they supply, to provide seamless quality of IT
service to the business, ensuring value for money is
obtained
Supplier Management ensures the provision of end-toend, seamless, quality IT services are delivered to the
business and aligned to their expectation
The Supplier and Contracts Database (SCD) records all
supplier and contract details, together with details of the
type of services or products provided by each supplier
98
Supplier Management includes the following points:
Supplier Management process manages suppliers and the services they supply. It
provides seamless quality of IT service to the business, ensuring value for money
is obtained.
Supplier Management ensures the provision of end-to-end, seamless, quality IT

services are delivered to the business and aligned to their expectation.
The Supplier and Contracts Database (SCD) records all details about suppliers,
contracts, and the type of service or products provided by each supplier.
3-127

Supplier Management Goal and Objectives

Supplier Management Objectives

Achieve value for money from supplier and contracts
Ensure that underpinning contracts and agreements with
suppliers are aligned to business needs
Ensure contracts and agreements support and align with
agreed targets in SLRs and SLAs
Manage relationships with suppliers
Manage supplier performance
Negotiate contracts with suppliers and manage them
through their lifecycle
Maintain a supplier policy and a supporting Supplier and
Contract Database (SCD)
99
The Supplier Management process manages suppliers and the services they supply. It
provides seamless quality of IT service to the business, ensuring value for money is
obtained. Supplier Management ensures the provision of end-to-end, seamless, quality IT
services are delivered to the business and aligned to their expectation. The Supplier and
Contracts Database (SCD) records all details about suppliers, contracts, and the type of
service or products provided by each supplier.
The purpose of the Supplier Management process is to receive value for money from
suppliers. In addition, it ensures that suppliers perform to the targets contained within their
contracts and agreements, while conforming to the terms and conditions.
The goal of Supplier Management is to manage suppliers and their services ensuring that
high quality and value is achieved.
3-128

Supplier Management Process
3-129

Supplier Management Benefits

Supplier Management Benefits

Ensures the delivery to the business of quality IT services
that are aligned to expectations.
Aligns with all corporate and all other IT and SM
processes requirements. This ensures that the business
obtains value from supporting supplier services and that
they are aligned with business needs.
101
3-130

Supplier Management Activities

Supplier Management Activities

Identifying business needs and preparation of the
business case
Establishing new suppliers and contracts
Categorizing suppliers and contracts
Managing supplier and contract performance
Managing the end of term
102
Supplier Management should complete the following activities:

Identify the business needs and preparation of the business case. This activity includes:
Producing a Statement of Requirement (SOR) and/or Invitation To Tender

(ITT)
Ensuring conformance to strategy/policy
Preparing the initial business case
Identifying method of purchase or procurement
Establishing evaluation criteria
Evaluating alternative options
Selecting and negotiating contracts, targets, and the terms and conditions
Awarding the contract
3-131

Establishing new suppliers and contracts. This activity includes:
Setting up the supplier service and contract
Transitioning the service
Establishing contacts and relationships
Categorizing suppliers and contracts. This activity includes:
Assessing the supplier and contract
Ensuring changes are progressed through Service Transition
Performing categorization of the supplier
Updating the supplier contract database (SCD)
Maintaining the SCD
Managing the supplier and contract performance. This activity includes:
Managing the operation and delivery of services and products
Monitoring and reporting
Reviewing and improving
Managing the supplier and the relationship
Planning for closures, renewals, and extensions.
Managing the end of term. This activity includes:
3-132
Determining the benefits delivered and ongoing requirements
Renegotiating, renewing, terminating, or transferring

Supplier Management Interfaces

Supplier Management Interfaces

Information Security Management
Problem and Incident Management
103
Events that might trigger Supplier Management activity include:
New or changed corporate governance guidelines
New or changed business and IT strategies, policies, or plans
New or changed business needs, or new or changed services
New or changed requirements within agreements, such as SLRs, SLAs, OLAs, or

contracts
Review and revision of designs and strategies
Periodic activities such as reviewing, revising, or reporting, including review and

revision Supplier Management policies, reports, and plans
Requests from other areas, particularly SLM and Security Management for
assistance with supplier issues
Requirements for new contracts, contract renewals, or contract terminations
Recategorization of suppliers and or contracts
3-133

The key interfaces that Supplier Management with other processes are:
3-134
IT Service Continuity Management (ITSCM): With regard to the management

of continuity service supplier.
SLM: Assistance with the determining of targets, requirements, and

responsibilities. In addition, SLM supports their inclusion in underpinning
agreements and contracts. Such inclusion ensures that they support all SLR and
SLA targets and the investigation of SLA and SLR breaches caused by poor
supplier performance.
ISM: In the management of suppliers and their access to service and systems and
their responsibilities with regards to conformance to ISM policies and
requirements.
Financial Management: To provide adequate funds required to finance Supplier

Management requirements and contracts and to provide advice and guidance on
purchase and procurement matters.
Service Portfolio Management: To ensure that all supporting services and their
details and relationships are accurately reflected within the Service Portfolio.

Supplier Management Inputs

Supplier Management Inputs

Supplier and contracts strategy
Supplier plans and strategies
Supplier and contract performance information
IT information
Contract or supplier performance issues
Financial contract information
Service information
Information from the CMS
104
Supplier and contracts strategy from the Service Strategy processes
Supplier plans and strategies from
Supplier contracts, agreements and targets
Supplier and contract performance information
IT information from the IT strategy, plans, and current budgets
Contract or supplier performance issues from the Incident and Problem

Management processes
Financial contract information from Financial Management
Information from the CMS
3-135

Supplier Management Outputs

Supplier Management Outputs

The Supplier and Contracts Database (SCD). This holds
the information needed by all sub-processes within
Supplier Management.
Supplier and contract performance information and
reports. These are used as to manage the quality of
service provided by suppliers and partners.
Supplier and contract review meeting minutes.
Supplier Service Improvement Plans (SIPs). These are
used to manage the progress of agreed improvement
actions.
Supplier survey reports.
105
3-136

Supplier Management KPIs

Supplier Management KPIs

Business protected from poor supplier performance or
disruption
Supporting services and their targets align with business
needs and targets
Availability of services is not compromised by supplier
performance
Clear ownership and awareness of supplier and
contractual issues
106
Business protected from poor supplier performance or disruption
Increase in the number of suppliers meeting the targets within the contract
Reduction in the number of breaches of contractual targets
Supporting services and their targets align with business needs and targets
Increase in the number of service and contractual reviews held with suppliers
Increase in the number of supplier and contractual targets aligned with SLA
and SLR targets
Availability of services is not compromised by supplier performance
Reduction in the number of service breaches caused by suppliers
Reduction in the number of threatened service breaches caused by suppliers
Clear ownership and awareness of supplier and contractual issues
Increase in the number of suppliers with nominated supplier managers
Increase in the number of contracts with nominated contract managers
3-137

Supplier Management Challenges, Success

Factors, and Risks
Supplier Management Challenges

Dealing with business and IT needs that are constantly
changing
Managing a bad contract
Dealing with lack of expertise within the organization
Being tied into long-term contracts
Relying on supplier for a service delivery
Managing disputes over charges
Dealing more with problems than positive actions
Managing communication issues and personality conflicts
Losing the strategic perspective
107
The Supplier Management process has the following critical success factors:
3-138
Business must be protected from poor supplier performance or disruption
Supporting services and their targets must align with business needs and targets
Service availability must not be compromised by supplier performance
Ownership and awareness of supplier and contractual issues must be clearly

defined

Supplier Management faces the following risks:
Lack of commitment from the business and senior management
Lack of resources
Legacy of badly written and agreed contracts
Inability for suppliers to meet targets or terms and conditions of the contract
Lack of cooperation from suppliers in the Supplier Management process
Upset due to suppliers being are taken over and the resulting changes
Excess of bureaucracy
Poor corporate financial processes
3-139

Supplier Manager
Supplier Manager
Assisting in the development and review of SLAs,
contracts, and agreements
Ensuring IT suppliers and contracts provide value for
money
Ensuring IT supplier processes are consistent and meet
expectations
Maintaining and monitoring a Supplier and Contracts
Database (SCD)
Monitoring all suppliers and contracts on a regular basis
Ensuring that underpinning contracts, agreements, and
SLAs are aligned with those of the business
108
The main role for the Supplier Management process is that of Supplier Manager. The
Supplier Manager has responsibility for ensuring that the aims of Information Supplier
Management are met.
3-140

The Supplier Manager also has the following responsibilities:
Ensuring that interfaces and dependencies between suppliers, supporting services,

and supplier processes are agreed and documented
Ensuring that all roles and relationships between lead and any sub-contracted
suppliers are properly documented
Ensuring that sub-contracted suppliers are meeting their contractual obligations
Performing regular contract and SLA reviews
Updating contracts or SLAs when required
Managing an effective process for dealing with contractual disputes
Managing expected end, early end, or transfer of a service
Monitoring and reporting supplier performance against targets
Identifying and implementing improvement actions as appropriate
Ensuring changes are assessed for impact on suppliers, supporting services, and
contracts
Attending CAB meetings when appropriate
Coordinating and supporting all individual IT supplier and contract managers
3-141

Service Design Roles
Lesson 9: Service Design Roles
Lesson 9: Service Design Roles
3-142

IT Planner
IT Planner
Develop IT plans Manage the implementation progress of
all IT strategies and plans
Develop and maintain the overall set of IT standards,
policies, plans, and strategies
Manage all aspects of IT standards, policy, and strategy
implementation
Recommend policy for the effective use of IT throughout
the organization
Review IT costs
Manage, plan and coordinate IT systems and services
110
An IT Planner is responsible for the production and coordination of IT plans. The IT

Planner also has the following responsibilities:
Evaluate supplier proposals for equipment, software, and services
Identify internal and external factors that influence IT
Manage the planning for the provision and use of IT architectures, products, and
services
Review IT performance Initiate improvement measures
Manage priorities and schedules for the implementation of new or changed IT

service
Assist in formulating plans and making IT procurement decisions
Manage all IT plans
Conduct Post Implementation Reviews (PIRs) in conjunction with Change

Management
3-143

Service Design Manager

Service Design Manager

Ensuring the Service Design Strategies are reflected in
the Service Design practice
Ensuring the Service Designs are produced to meet and
fulfill the documented business requirements
Developing and maintaining all necessary SDPs
Evaluating the effectiveness and efficiency of the Service
Design process
111
The Service Design Manager is responsible for the overall coordination and deployment of
quality solution designs for services and processes.
3-144

The responsibilities of the Service Design Manager also include:
Designing the following aspects of the services:
functional
infrastructure
environment applications
data management
Producing quality and stable designs that meet agreed current and future IT
requirements for:
new or improved services
technology architecture
processes
measurement systems
Developing and maintaining all design documentation, including:
designs
plans
architectures
policies
3-145

Unit Scenario

Unit 1 scenario focused on the creation of a single service. Service Design brings the
organization to the activities and focus of the overall Services Portfolio. The Portfolio is the
full breadth of services offered to the business. These services can exist within any of the
statuses that advise whether the service is available or not.
This scenario will not focus on the creation of the entire portfolio. It will focus on the
creation of another service. The service is personal computer (PC) refresh. Service design
uses the 4 Ps that are a focus for each service. When examining the PC refresh process the
Ps might be:
People: Users, Finance team, IMAC (desktop mobility) team, Software

management
Products: Service request for acquisition of the new equipment, software

distribution tool, asset management tool for recording data
Processes: Service Request, IMAC, and Retirement, Software reconciliation and

Installation, PC wipe of data.
Partners: Suppliers of the PCs, Retirement Company that properly disposes of

PC equipment.
The 4 Ps need to be considered in the creation and definition of single services. The 4 Ps
also need to be considered in the load and level of the effort.
When designing the services, it is important to establish the level of that service and how it
will be monitored and measured. When considering the PC refresh, it might be critical to
monitor approval times, delivery from the supplier, and delivery to the users. In addition, it
will be important to check time and accuracy. For example, check how many incidents or
issues the user needs to resolve with support from the Service desk, or IMAC rework team.
Surveys can be another metric to get feedback from the users to indicate how smoothly the
process was for them. Because all of these can be metrics, it will be important to accompany
them with SLAs to ensure the delivery is meeting expectations. An example would be
delivery being completed 2 weeks from request, with 1 day of interruption of user work
time.
SLAs can often blend together with Availability Management. In this scenario, availability
can be measured or monitored as the level of impact the swap from old PCs to new PC
impacts the users. For example, to have an impact of no more than 8 hours of lost work
time. Another example might be moving to proactive availability, such as pushing a
communication with all necessary data to users that contains a link. This link might provide
a means for the users to agree to a swap out date. Additionally, users might enter the
information about the software and data they expect moved to the new PCs.
3-146

Unit Scenario
As you learned in this unit, information security management becomes important in the
services portfolio. For example, in this case, the data will be cleared from the retiring PC
(person data). In addition, the management of software licenses of, for example, spyware,
or antivirus software is also a big consideration. Furthermore, ensuring PC security of the
old and new PCs is also necessary.
Within Service Design, it is essential to understand how the Process Owners and Service
Owners work into and manage the services throughout their lifecycle. Consider the Process
Owners of Configuration Management, Asset Management, Desktop or IMAC mobility
team, and Change Management. Because this example is a PC process, it might be very
likely be owned by the Desktop Manager.
Because this service interacts with suppliers, it is involved in managing the supplier process
which is actually part of service design. Lastly, it might be necessary to ensure
collaboration with the managers of other areas. For example, if this process was provided
before, but manually and with out proactive processes, then other roles might need to be
involved. These roles help provide automation and ensure effective and fast service to the
user.
If an organization uses services such as PC refresh, they can be combined to create a
complementary set of services that make up the portfolio.
3-147

Unit Scenario
Review Questions
1.
Which of the following choices is the main purpose of the Service Design stage?
a.Minimizes the risks from transitioning the new or changed services to production
2.
b.
Coordinate the activities and process required to deliver services
c.
Design of new or changed services being introduced into the production

environment
d.
Design and develop service management as a strategic asset
Which of the following choices is not one of the five individual aspects of Service
Design?
a.Design of the technology architecture and management systems
3.
b.
Response to the business and IT requests for change
c.
Design of the Service Portfolio, including the Service Catalog
d.
Design of measurement methods and metrics
What type of approach should be adopted for all service design areas to ensure
consistency and integration?
a.Holistic
4.
b.
Transitional
c.
Isolated
d.
Adaptive
Which of the following choices describes the value Service Design provides to the
business?
a.Provides a consistent interface to the business for all service-related issues
5.
b.
Provides the business with the agreed-upon service targets
c.
Provides a reliable communication channel and a trusted relationship with the

appropriate customers and business representatives
d.
All of the above
Which of the following choices are important to Service Management?

a.People
b.
3-148
Processes

Unit Scenario
6.
c.
Products
d.
Partners
e.
All of the above
Which of the following choices includes ensuring that an agreed-upon level of IT

service is provided for all current IT services and that future services are delivered
to agreed-upon targets?
a.Service Catalog Management
7.
b.
c.
d.
Capacity Management
Which of the following choices is not part of the Service Level Management
Process?
a.Ensure that availability targets in all areas are measured and achieved.
8.
b.
Log and manage all complaints and compliments.
c.
Produce service reports.
d.
Determine, negotiate, document, and agree upon the requirements for

services.
Which of the following choices is not a responsibility for a Service Catalog

Manager?
a.Ensuring that all the information within the Service Catalog is accurate and up to
date
9.
b.
Ensuring that all of the information within the Service Catalog is consistent
with the information in the service portfolio
c.
Ensuring that the information within the Service Catalog is adequately

protected and backed up
d.
Ensuring that the current and future service requirements of customers are
identified, understood, and document in SLA and SLR documents
Which of the following choices is not a responsibility for an Availability

Manager?
a.Proactively improves service availability wherever possible and optimizes the
availability of the IT infrastructure
b.
Participates in the IT infrastructure design, including the specification of the

availability requirements for hardware and software
3-149

Unit Scenario
10.
c.
Identifies and classifies IT and information assets (Configuration Items) and

d.
Assists Security and IT Service Continuity Management with the assessment

and management of risk
Which of the following processes has the goal of aligning IT security with
business security and ensure that information security is effectively managed in
all service and Service Management Activities?
a.Information Security Management
11.
b.
Capacity Management
c.
d.
Which of the following processes ensures the provision of end-to-end, seamless,

quality IT services are delivered to the business and aligned to their expectation?
a.Information Security Management
3-150
b.
Supplier Management
c.
d.

Unit Scenario
3-151

Unit Scenario
Review Answers
1.
Which of the following choices is the main purpose of the Service Design stage?
c. design of new or changed services being introduced into the production
environment
2.
Which of the following choices is not one of the five individual aspects of Service
Design?
b. Response to the business and IT requests for change
3.
What type of approach should be adopted for all service design areas to ensure
consistency and integration?
a. Holistic
4.
Which of the following choices describes the value Service Design provides to the
business?
d. All of the above
5.
Which of the following choices are important to Service Management?

d. All of the above
6.
Which of the following choices includes ensuring that an agreed-upon level of IT

service is provided for all current IT services and that future services are delivered
to agreed-upon targets?
b. Service Level Management
7.
Which of the following choices is not part of the Service Level Management
process?
a. Ensure that availability targets in all areas are measured and achieved.
8.
Which of the following choices is not a responsibility for a Service Catalog

Manager?
d. Ensuring that the current and future service requirements of customers are
identified, understood, and document in SLA and SLR documents.
9.
Which of the following choices is not a responsibility for an Availability

Manager?
c. Identifies and classifies IT and information assets (Configuration Items) and
3-152

Unit Scenario
10.
Which of the following processes has the goal of aligning IT security with
business security and ensure that information security is effectively managed in
all service and Service Management Activities?
a. Information Security Management
11.
Which of the following processes ensures the provision of end-to-end, seamless,

quality IT services are delivered to the business and aligned to their expectation?
b. Supplier Management
3-153

Unit Scenario
Summary
Summary
Service Design
Discuss Service Design processes and associated
activities
Describe the Service Design roles
113
3-154
4-1
Introduction
In this unit, you will learn about Service Transition.
Objectives
Objectives
Service Transition
Discuss Service Transition processes and associated
activities
Describe the Service Transition roles
4-2

Service Transition Overview
Lesson 1: Service Transition Overview
Lesson 1: Service Transition Overview
4-3



Service Transition is a change in state, corresponding to
a movement of an IT Service or other Configuration Item.
This change occurs from one lifecycle status to the next.
Service Transition uses all the processes described in the other ITIL parts of the Service
Lifecycle. It uses all the processes because it is responsible for testing them. This testing
occurs either as part of a new or changed service or as part of testing changes to the Service
Management processes.
Service level management is important to ensure that customer expectations are managed
during Service Transition. Incident and problem management are important for handling
incidents and problems during testing, pilot, and deployment activities.
4-4

Service Transition Objectives

Service Transition Objectives

Sets customer expectations on how performance and use
of new or changed services can be used to enable
business change
Enables business change project or customer to integrate
a release into business processes and services
Reduces variations in predicted and actual performance of
transitioned services
Reduces the known errors and minimizes the risks from
transitioning the new or changed services into production
Further objectives of Service Transition include:
To ensure that the new or changed services can be used in accordance with the
requirements and constraints specified within the service requirements
To plan and manage resources to successfully establish a new or changed service

and bring it into production within the predicted cost, quality, and time estimates
To ensure a minimal unpredicted impact on the production services, operations,

and support organization
To increase the customer, user, and Service Management staff satisfaction with the
Service Transition practices, including:
Deployment of the new or changed service
Communications
Release documentation
Training
Knowledge transfer
4-5

4-6
To increase proper use of the services and underlying applications and technology
solutions
To provide clear and comprehensive plans that enable the customer and business
change projects to align their activities with the Service Transition plans

Value of Service Transition

Value of Service Transition

Improves the ability to adapt quickly to new requirements and market
developments
Aids in transition management of mergers, demergers, and
acquisitions
Increases the success rate of changes and releases for the business
Improves predictions of service levels and warranties for new and
changed services
Expedites timely cancellation or changes to maintenance contracts
for both hardware and software when components are disposed of or
decommissioned
Aids understanding the level of risk during and after change, for
example, during service outage, service disruption, or rework
The purpose of Service Transition is to perform the following tasks:
Plan and manage the capacity and resources required to package, build, test, and
deploy a release into production.
Provide a consistent framework for evaluating the service capability and risk
profile before a new or changed service is deployed.
Establish and maintain the integrity of all identified service assets and
configurations as they evolve through the Service Transition stage.
Provide quality knowledge and information. Therefore, Release and Deployment

Management can expedite effective decisions during a release.
Provide efficient repeatable build and installation mechanisms to deploy releases

to the test and production environments.
Ensure that the service can be managed, operated, and supported within the
Service Design requirements and constraints.
4-7

Service Knowledge Management System

Service Knowledge Management System

Under Service Transition, knowledge management is
focused within the Service Knowledge Management
System (SKMS)
The Service Knowledge Management system covers a
wide base of knowledge
Knowledge management is focused within the Service Knowledge Management System

(SKMS).
Underpinning this knowledge is a considerable quantity of data. It will be held in a central
logical repository or Configuration Management System (CMS) and Configuration
Management Database (CMDB).
The Server Knowledge Management system is a broader concept that covers a much wider
base of knowledge, for example:
4-8
The experience of staff
Records of peripheral matters, for example, weather, user numbers, user behavior,
and performance figures of an organization
Supplier and partner requirements, abilities, and expectations
Typical and anticipated user skill levels

SKMS Data
SKMS Data
Gathered within
CMDB
Fed through the
CMS
Goes into the
SKMS
Supports the
informed decision
making process
4-9

Service Transition Strategy

Service Transition Strategy
Defines the overall approach to organizing Service Transition

and allocating resources
Includes:
Purpose
Scope
Organizations and stakeholders
Framework for Service Transition
Criteria
People and roles
Requirements and content

Approach
Schedule of milestones
Deliverables for each stage
Financial requirements
Context
Applicable standards requirements
4-10

Service Transition Lifecycle Stages Example

Service Transition Lifecycle Stages Example

Acquire and test input configuration items (CIs) and
components
Build and test
Service release test
Service operational readiness test
Deployment
Early life support
Review and close service transition
10
4-11

Technology Considerations for Service

Transition
Technology Considerations for Service Transition

Knowledge Management Tools
Configuration Management System (CMS)
11
Technology is extremely important in Service Transition. Designs should include methods

for maintaining and maximizing benefit from the technology used. Two ways in which
Service Transition is supported by technology are by:
Enterprise-wide tools that support the broader systems and processes within
which Service Transition delivers support
Tools targeted more specifically at supporting Service Transition or parts of

Service Transition
Knowledge Management Tools
Knowledge Management tools maintain electronic copies of records and

documents. Records are different from documents because they provide evidence
of activities, rather than intentions.
Document Management: Document Management defines the set of capabilities

to support the following areas for documents and information:
4-12
Storage

Protection
Archiving
Classification
Retirement
Records Management: Records management defines the set of capabilities to

support the following areas for records:
Storage
Protection
Archiving
Classification
Retirement
Content Management: Content management is the capability that manages the

storage, maintenance and retrieval of documents and information of a system or
Web site.
Configuration Management System (CMS)

The CMS contains details about the attributes and the history of each Configuration Items
(CIs) and details of the important relationships between CIs. Many organizations have
some form of Configuration Management in operation, but it is often paper-based. For large
and complex infrastructures, Configuration Management will operate more effectively
when supported by a software tool that is capable of maintaining a CMS.
The Configuration Management System should prevent changes from being made to the IT
infrastructure or service configuration baseline without valid authorization through Change
Management.
4-13

Process of Transition Planning and Support
Lesson 2: Process of Transition Planning

and Support
Lesson 2: Process of Transition

Planning and Support
4-14

Transition Planning and Support Purpose

Transition Planning and Support Purpose

Plan appropriate capacity and resources
Provide support for the Service Transition teams
Plan the changes required while ensuring integrity of all
customer assets
Ensure reporting of Service Transition issues, risks, and
deviations
Coordinate activities across relevant areas
13
4-15

Transition Planning and Support Goals

Transition Planning and Support Goals

Plan and coordinate the resources
Identify, manage, and control the risks of failure and
disruption
14
4-16

Transition Planning and Support Objectives

Transition Planning and Support Objectives

Establish successful plan within the predicted cost, quality
and time estimates
Ensure common adoption of the framework of standard
reusable processes and supporting systems
Provide clear and comprehensive plans that enable
customer and business to align activities with the Service
Transition plans
15
4-17

Service Transition Policy

Service Transition Policy

The release policy should be defined for one or more
services.
All releases should have a unique identifier that can be
used by Configuration Management and the
documentation standards.
The types of release should be defined. Typical Types of
releases include:
Major
Minor
Emergency
16
The Service Design Package includes the following information that is required by the
Service Transition team:
The applicable service packages
The service specifications
The service models
The architectural design required to deliver the new or changed Service including
constraints
The definition and design of each release package
The detailed design of how the service components will be assembled and
integrated into a release package
Release and deployment plans
The Service Acceptance Criteria
The types of release should be defined as this helps to set customer and stakeholder
expectations about the planned releases.
4-18

Typical types of releases include:
Major Releases: This type usually contains large areas of new functionality. They
can include those releases that eliminate temporary fixes to problems. A major
upgrade or release usually supersedes all preceding minor upgrades, releases, and
emergency fixes.
Minor Releases: This type usually contains small enhancements and fixes, some
of which might already have been issued as emergency fixes. A minor upgrade or
release usually supersedes all preceding emergency fixes.
Emergency releases: This type usually contains the corrections to a small number
of known errors. Sometimes it contains an enhancement to meet a high priority
business requirement.
4-19

Transition Planning and Support Benefits

Transition Planning and Support Benefits

Improve ability to deal with considerable amounts of
change and releases
Improve alignment of Service Transition Plans with
changed Project Plans
17
4-20

Transition Planning and Support Activities

Transition Planning and Support Activities

Define Transition Strategy and Lifecycle Stages
Prepare for Service Transition
Plan and Coordinate Service Transition
Provide Transition Process Support
18
The Transition Planning and Support process consists of the following activities.
Define Transition Strategy and Lifecycle Stages

The Service Transition strategy defines the overall approach to organizing Service
Transition and allocating resources. The aspects to consider are:
Purpose, goals and objectives of Service Transition
Context
Scope
Applicable standards, agreements, legal, regulatory, and contractual requirements
Organizations and stakeholders involved in transition
Framework for Service Transition:
Criteria
Identification of requirements and content of the new or changed service
4-21

People
Approach
Deliverables from transition activities including mandatory and optional

documentation for each stage
The Service Design Plan should define the lifecycle stages for a Service
Transition:
Acquire and test input configuration items (CIs) and components
Build and test
Service release test
Service operational readiness test
Deployment
Early life support
Review and close service transition
Prepare for Service Transition
Review and acceptance of inputs from the other service lifecycle stages
Review and check the input deliverables
Identify, raise, and schedule RFCs
Check that the configuration baselines are recorded in Configuration Management

before the start of Service Transition
Check transition readiness
Plan and Coordinate Service Transition
4-22
Develop a Service Transition Plan. A Service Transition plan describes the tasks
and activities required to release and deploy into the test environments and
production.
Maintain an integrated set of transition plans that are linked to lower-level plans
such as release, build and test plans.
Quality review all Service Transition, release, and deployment plans.

Provide Transition Process Support
Provide support for all stakeholders regarding the Service Transition framework
of processes and supporting systems and tools.
Maintain an oversight of the actual transitions against the integrated Service

Transition plans, release, and change schedules.
4-23

Transition Planning and Support Inputs and

Outputs
Transition Planning and Support Inputs and Outputs

Inputs:
An authorized Request for Change (RFC)
A Service Design package
A release package definition and design specification
Service Acceptance Criteria (SAC)
Outputs:
Transition strategy
Integrated set of Service Transition plans
19
4-24

Transition Planning and Support KPIs

Transition Planning and Support KPIs

The percentage of releases that met agreed cost, quality,
scope, and release schedule requirements
Reduced variation of actual versus predicted scope,
quality, cost, and time
Increased customer and user satisfaction with plans and
communications
Reduction in number of issues, risks and delays caused
by inadequate planning
Improved Service Transition success rate
20
Further Transition Planning and Support KPIs include:
Better management information on the predicted versus actual performance and

cost of Service Transition
Improved efficiency and effectiveness of the processes and supporting systems,

tools, knowledge, information and data
Reduction in time and resource to develop and maintain integrated plans and
coordination activities
Project and service team satisfaction with the Service Transition practices
4-25

Transition Planning and Support Roles

Transition Planning and Support Roles

Sometimes, the Service Transition manager is
responsible for planning and support.
However, in some organizations this function might be
performed by a Service Management office or be an IT
planning responsibility.
Either way, this role provides support for the Service
Transition teams and people.
21
The responsibilities include:
4-26
Determining transition planning and support requirements, processes and tools
Maintaining and integrating lower level plans to establish overall integrated

transition plans
Monitoring and managing progress on Service Transition changes, issues, risks

and deviations
Maintaining records and providing management information on resource use,

project progress, and budget data
Managing and coordinating requests for resources
Coordinating Service Transition activities across projects, suppliers and service

teams where appropriate
Publishing Service Transition performance statistics and identifying key areas for
improvement
Undertaking formal quality reviews of transition activities in accordance with the

quality management plan

Managing support for tools and Service Transition processes
Communicating with stakeholders
4-27

Process of Change Management
Lesson 3: Process of Change Management
Lesson 3: Process of Change

Management
4-28

Change Management Scope

Change Management Scope

Service Change is the addition, modification, or removal
of authorized, planned, or supported service or service
component and its associated documentation.
Each organization should define the changes that lie
outside the scope of their service change process.
The scope of Change Management covers changes to
baseline service assets and configuration items across
the whole Service Lifecycle.
23
Service Change will deal primarily with Service Operational Changes, but organizations
can use the service. Change process for strategic changes or portfolio changes if they
choose.
Changes that lie outside the scope of a service change process of an organization might
include:
Changes with significantly wider impacts than service changes, for example,
departmental organization, policies, business operations. These changes will
produce Requests for Change (RFCs) to generate consequential service changes.
Changes at an operational level, such as repair to printers or other routine service

components.
4-29

Service Request
Service Request
A generic description for many varying types of demands
that are placed upon the IT department by the users
The scale and frequent, low-risk nature means that
service requests are better handled by a separate
process, rather than being allowed to congest and
obstruct the normal incident and Change Management
processes
24
Many service requests are actually small changes. Service Requests have the following
characteristics:
Low risk
Frequently occurring
Low cost
Examples of service requests include:
4-30
A request to change a password
A request to install an additional software application onto a particular

workstation
A request to relocate some items of desktop equipment
A question requesting information

Change Request
Change Request
A formal communication seeking an alteration to one or
more Configuration Items
Change requests can take several forms
Different types of change may require different types of
change requests
25
An organization needs to ensure that appropriate procedures and forms are available to
cover the anticipated requests.
Avoiding a bureaucratic approach to documenting a minor change removes some of the
cultural barriers to adopting the change management process.
Some of the forms might be:
A request for change document
A service desk call
A project initiation document
4-31

Change Types
Change Types
Normal
Standard
Emergency
26
4-32

Change Types: Normal Change

Change Types: Normal Change

An ITIL normal change refers to changes that must follow
the complete change management process.
A normal change will proceed through all steps of the
change management process and will eventually be
reviewed by the Change Advisory Board (CAB).
The CAB will provide advice regarding the change to the
person who is deemed responsible to approve or reject
normal changes.
27
4-33

Change Types: Standard Change

Change Types: Standard Change

Change to a service or infrastructure when the change:
Is preauthorized b y Change Management
Has an accepted and established procedure to provide a specific
change requirement
Changes intended to introduce immediately required

business improvements are handled as normal changes,
assessed as having the highest urgency
28
Examples of a standard change type might include:
An upgrade of a computer in order to make use of specific standard and

perpetuated software
Desktop move for single user
Low-impact, routine application change to handle seasonal variation
The crucial elements of a Standard Change are as follows:
4-34
A defined trigger initiates the RFC
The tasks are well-known, documented, and proven
Authority is effectively given in advance
Budgetary approval will typically be preordained or within the control of the

change requester
The change typically has a low risk and always a well-understood risk
Standard Changes should be identified early when building the Change Management
process to promote efficiency. Otherwise, a Change Management implementation can
create unnecessarily high levels of administration and resistance to the Change

Management process. All changes, including Standard Changes, will have details of the
change recorded. For some Standard Changes this record might be different from normal
change records.
Some Standard Changes to Configuration Items (CIs) might be tracked on the asset or CI
lifecycle, particularly where a comprehensive Change Management System (CMS)
provides:
Reports of changes
Current status of changes
Related configuration items
Status of the related CI versions
In these cases, the Change Management and Configuration Management reporting is

integrated. Change Management can have oversight over all changes to service CIs and
release CIs.
4-35

Change Types: Emergency Change

Change Types: Emergency Change

Emergency changes are sometimes required and should
be:
Designed carefully
Tested before use
Can document some details retrospectively

Reserved for changes intended to repair an error in an IT
service
The IT service must be negatively affecting the business
to a high degree
29
The number of emergency changes should be kept to an absolute minimum, because they
are generally more disruptive and prone to failure.
Occasions will occur when emergency changes are essential. Consequently, procedures
should be devised to deal with them quickly, without sacrificing normal management
controls.
If emergency changes are not designed carefully and tested before use, the impact of the
emergency change might be greater than the original.
4-36

Release Unit
Release Unit
Portion of a service or IT infrastructure that is normally
released together according to the release policy of the
organization
The unit can vary, depending on the type or items of
service asset or service component, such as software and
hardware
30
An organization might, for example, decide that the Release Unit for business critical
applications is the complete application. It might do so to ensure that testing is
comprehensive.
The same organization might decide that a more appropriate Release Unit for a Web site is
at the page level.
A release unit to upgrade to a small portion of a sales application might require the entire
site contents to be packaged and released together.
4-37

Seven Rs of Change Management

Seven Rs of Change Management

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, and
implementation of the change?
What is the relationship between this change and other
changes?
31
The questions for the Seven Rs of Change Management must be answered for all changes.
Without this information, the impact assessment cannot be completed, and the balance of
risk and benefit to the live service will not be understood. Without this understanding, the
change might not deliver all of the possible or expected business benefits. The change
might even have an unexpected detrimental effect on the live service.
4-38

Change Management Goals

Change Management Goals

Change Management responds to the changing business
requirements of the customer while reducing incidents,
disruption, and rework
Change Management responds to the business and IT
requests for change
32
The change management process should ensure that changes are recorded and then
evaluated, authorized, prioritized, planned, tested, implemented, documented, and
reviewed in a controlled manner.
Changes arise for a variety of reasons:
Proactive changes. For example, seeking business benefits such as reducing costs
or improving services, or increasing the ease and effectiveness of support.
Reactive changes are a means of resolving errors and of adapting to changing

circumstances, supporting new product lines, and so forth.
Changes should be managed for the following reasons:
To optimize risk exposure (supporting the risk profile required by the business)
To minimize the severity of any impact and disruption
To be successful on the first attempt
To make an appropriate response to all Requests for Change, Change Management should
include an assessment of:
Risk and business continuity
4-39

Change impact
Resource requirements
Change authorization
Business benefit
This assessment is essential to maintain the required balance between the need for change
and the impact of the change.
Each organization should define the changes that lie outside the scope of their service
change process, which typically might include the following changes:
4-40
Changes with significantly wider impacts than service changes, for example,
departmental organization, policies, business operations. These changes will
produce RFCs to generate consequential service changes.
Changes at an operational level, such as repair to printers or other routine service

components.

Change Management Benefits

Change Management Benefits

Prioritizing and responding to change requests
Reducing failed changes and service disruption
Delivering change promptly
Tracking changes through the Service Lifecycle
Contributing to better estimations of the quality, time, and
cost of change
Reducing disruptions due to high levels of unplanned or
emergency changes
Reducing the Mean Time to Restore Service (MTRS)
through quicker and more successful implementations of
corrective changes
33
By managing changes, you manage much of the potential risk that changes can introduce.
Service and infrastructure changes can have a negative impact on the business by disrupting
service and delaying the identification of business requirements. However, Change
Management enables the service provider to perform the following tasks:
Prioritizing and responding to business and customer change proposals
Implementing changes that meet the agreed-upon service requirements of the

customers while optimizing costs
Reducing failed changes resulting in service disruption, defects, and rework
Delivering change promptly to meet business time scales
Tracking changes through the Service Life Cycle and to the assets of its customers
Contributing to better estimations of the quality, time, and cost of change
Assessing the risks associated with the transition of services
Aiding productivity of staff by minimizing disruptions caused by high levels of

unplanned or emergency changes, hence maximizing service availability
Reducing the Mean Time to Restore Service (MTRS) through quicker and more
successful implementations of corrective changes
4-41

Policies Supporting Change Management

Policies Supporting Change Management

Establishing zero tolerance for unauthorized change
Establishing accountability and responsibilities for
changes through the Service Lifecycle
Establishing a single focal point for changes
Preventing people who are not authorized to make a
change from having access to the production environment
Establishing Change Windows: enforcement and
authorization for exceptions
Establishing performance and risk evaluation of all
changes that affect service capability
34
Policies that support change management include:
4-42
Creating a culture of change management across the organization where there is

zero tolerance for unauthorized change
Aligning the service change management process with business, project, and
stakeholder change management processes
Prioritizing change such as innovation, prevention, detection, corrective change
Segregating of duty controls
Establishing a single focal point for changes in order to minimize the probability
of conflicting changes and potential disruption to the production environment
Integrating with other service management processes to establish traceability of

change, detect unauthorized change, and identify change-related incidents
Establishing performance measures for the process, for example, efficiency and
effectiveness

Remediation
Remediation
Before approval, all changes should address the question
of what to do if the change is not successful
There should be a back-out plan, which will restore the
organization to its initial situation
often done through the reloading of a baseline set of CIs, especially
software and data
If change is not reversible, an alternative approach to

remediation is required
35
4-43

Change Management Activities

Change Management Activities
36
Managing individual changes typically include the following activities:
4-44
Create and recording changes
Review Request For Change (RFC) and change proposal
Filter changes (for example, incomplete changes, wrongly routed changes)
Assess and evaluate the change
Establish appropriate level of change authority
Establish relevant areas of interest (such as who should be involved in Change

Advisory Board)
Assess and evaluate the business justification, impact, cost, benefits, and risk of
changes
Request independent evaluation of a change
Authorize the change
Obtain authorization and rejection

Communicate the decision with all stakeholders, in particular the initiator of the
request for change
Plan updates
Coordinate change implementation
Review and close change
Collate the change documentation, for example, baselines and evaluation reports
Review the changes and change documentation
Close the change document when all actions are completed
Throughout all the previous process activities and those described within this section,
information is gathered, recorded in the CMS, and then reported.
4-45

Change Management Interfaces

Change Management Interfaces

Release Management
Asset and Configuration Management
Problem Management
Security Management
Capacity and Demand Management
37
Change and Release Management should be integrated with:
Processes used for organizational programs or projects
Supplier management
Processes and procedures of the supplier
Occasionally a proposed change will potentially have a wider impact on other parts of the
organization (for example, facilities or business operations), or vice versa. Then service
change process must interface appropriately with other processes involved.
Service Management processes might require change and improvements. Many will also
be involved in the impact assessment and implementation of service changes.
Asset and Configuration Management: The Configuration Management System
provides reliable, quick, and easy access to accurate configuration information. This
information helps stakeholders and staff assess the impact of proposed changes and to track
workflow. This information enables the correct asset and service component versions to be
released to the appropriate party or into the correct environment. As changes are
4-46

implemented, the configuration management information is updated. The CMS might also
identify:
Related CI and assets that will be affected by the change, but not included in the
original request
Similar CI and assets that might benefit from similar change
Problem Management: Changes are often required to implement workarounds and to fix
known errors. Problem Management is one of the major sources of Requests for Changes
(RFCs) and also often a major contributor to Change Advisory Board (CAB) discussion.
IT Service Continuity: Procedures and plans should be updated through change
management to ensure that they are accurate, up to date, and distributed to stakeholders.
Security Management: Changes required by security will go through the change
management process and security will be a key contributor to CAB discussion on many
services. Every significant change will be assessed for its potential impact on the security
plan.
Capacity and Demand Management: Poorly managed demand is a source of costs and
risk for service providers because uncertainty is always associated with the demand for
services. Capacity management has an important role in assessing proposed changes, not
only the individual changes but the total impact of changes on service capacity. Changes
arising form capacity management, including those set out in the capacity plan, will be
initiated as RFCs through the change process.
4-47

Change Management Inputs and Outputs

Change Management Inputs and Outputs

Changes can be submitted as an Request For Change
(RFC).
The RFC will often be accompanied by an associated
change proposal.
The change proposal will be based on a change model
and will provide more detail about the specific change
proposed.
38
The inputs for Change Management are:
Policy and strategies for change and release
Request for Change
Change proposal
Plans that include:
4-48
Change
Transition
Release
Deployment
Test
Evaluation
Remediation
Current change schedule and Projected Service Outage (PSO)

Current assets or configuration items
Planned configuration baseline
Test results, test report, and evaluation report
Outputs from the Change Management process are:
Rejected RFCs
Approved RFCs
Change to the services, service, or infrastructure from approved RFCs
New, changed, or disposed assets or configuration items
Change schedule
Revised PSO
Authorized change plans
Change decisions and actions
Change documents and records
Change Management reports
4-49

Change Management Key Performance

Indicators
Change Management Key Performance Indicators

Reduction in the number of disruptions to services
Reduction in the number of unauthorized changes
Reduction in the backlog of change requests
Reduction in the number and percent of unplanned changes
and emergency fixes
Change success rate (percentage of changes deemed
successful at review or number of RFCs approved)
Reduction in the number of failed changes
Average time to implement based on urgency, priority, and
change type
Incidents attributable to changes
39
Change Management must ensure that measures that have specific meaning. It is relatively
easy to count the number of incidents that eventually generate changes. However, it is more
valuable to examine the underlying cause of such changes and identify trends. The
following options would be even better:
Measure the impact of change
Demonstrate reduced disruption over time because of the introduction of Change

Management
Measure the speed and effectiveness with which the IT infrastructure responds to
identified business needs
Measures taken should be linked to business goals, wherever practical, and to cost, service
availability, and reliability. Any predictions should be compared with actual measurements.
The Key Performance Indicators for Change Management include the following
measurements:
4-50
The number of changes implemented to services which met the agreed-upon

requirements of the customer. These requirements will include quality, cost, and
time (expressed as a percentage of all changes).

The benefits of change expressed as value of improvements made + negative

impacts prevented or terminated compared to the costs of the change process.
Reduction in the number of disruptions to services, defects, and rework caused by

inaccurate specification, and poor or incomplete impact assessment.
Reduction in the number of unauthorized changes.
Reduction in the backlog of change requests.
Reduction in the number and percent of unplanned changes and emergency fixes.
Change success rate (percentage of changes deemed successful at review and

number of RFCs approved.)
Reduction in the number of changes when remediation is invoked.
Reduction in the number of failed changes.
Average time to implement based on urgency, priority, and change type.
Incidents attributable to changes.
Percentage accuracy in change estimate.
4-51

Change Manager
Change Manager
Receive, log, and allocate a priority, in collaboration with the initiator,
to all Requests for Change (RFCs). Reject any totally impractical
RFCs.
Chair all Change Advisory Board (CAB) and Emergency Change
Advisory Board (ECAB) meetings, table all RFCs for a CAB meeting,
issue an agenda, and circulate all RFCs to CAB members before
meetings to allow prior consideration.
Determine meeting invitations and allocate specific RFCs (depending
on the nature of the RFC, the changes, and areas of expertise of the
personnel).
After consideration of the advice given b y the CAB or ECAB,
authorize acceptable changes.
Issue Change Schedules through the Service Desk.
Review all implemented changes to ensure that they have met their
objectives. Refer back any that have been reversed or have failed.
40
The main role in Change Management is that of the Change Manager. Some of the main
duties of the Change Manager can be delegated.
4-52

Change Advisory Board (CAB)

Change Advisory Board

Will be composed according to the changes being
considered
Might vary considerably in make up, even across the
range of a single meeting
Should involve suppliers when that is useful
Should reflect both user and customer views
Is likely to include the Problem Manager, Service Level
Manager, and Customer Relations staff for at least part of
the time
41
The Change Advisory Board (CAB) is a body that exists to support the authorization of
changes. The CAB also assists Change Management in the assessment and prioritization of
changes. When a CAB is convened, members should be chosen who are capable of
ensuring that all changes within the scope of the CAB are adequately assessed. These
assessments should come from both a business and a technical viewpoint. When the need
for emergency change arises, there might not be time to convene the full CAB. It is
necessary to identify a smaller organization with authority to make emergency decisions.
This body is the Emergency Change Advisory Board (ECAB).
The CAB might be asked to consider and recommend the adoption or rejection of changes
appropriate for higher level authorization. Then recommendations will be submitted to the
appropriate change authority
4-53

Process of Service Asset and Configuration Management
Lesson 4: Process of Service Asset and

Lesson 4: Process of Service Asset and

4-54

Service Asset and Configuration Management

Purpose and Goal
SACM Purpose and Goal

Service Asset and Configuration Management (SACM)
provides a logical model of the IT infrastructure
SACM correlates IT services and different IT components
(such as physical and logical) needed to deliver services
SACM defines and controls the components of services
and infrastructure and maintaining accurate configuration
records
Service Asset and Configuration Management improves
the service performance and optimizes the costs caused
by poorly managed assets, for example, service outages,
fines, correct license fees, failed audits
43
Service Asset and Configuration Management (SACM) is used for the following reasons:
To protect the integrity of service assets and configuration items (and where
appropriate, those of its customers) through the Service Lifecycle
To place IT assets and designated configuration items within the Service

Lifecycle under configuration management
To ensure the integrity of the assets and configurations required to control the
services and IT infrastructure by establishing and maintaining and accurate a
complete Configuration Management system
To support efficient and effective business and service management processes by

providing accurate information about assets and configuration items.
The goal of Service Asset and Configuration Management is to provide a logical model of
the IT infrastructure. This model correlates IT services and the various IT components
(physical, logical, and so on) needed to deliver these services. It does this by defining and
controlling the components of services and infrastructure and maintaining accurate
configuration records.
4-55

This goal enables an organization to:
Comply with corporate governance requirements
Control the asset base
Optimize the costs
Manage change and releases effectively
Resolve incidents and problems faster
Service Asset and Configuration Management optimizes the performance of service assets
and configurations. In addition, it improves the overall service performance. Furthermore,
it optimizes costs and risks caused by poorly managed assets such as service outages, fines,
correct licence fees, and failed audits.
SACM provides visibility of accurate representations of a service, release, or environment
that ensure the following events occur:
4-56
Better forecasting and planning of changes
Changes and releases to be assessed, planned, and delivered successfully
Incidents and problems to be resolved within the service level targets
Warranties to be delivered
Better adherence to standards, legal, and regulatory obligations (fewer

nonconformances)
More business opportunities because of ability to demonstrate control of assets

and services
Changes to be traceable from requirements
New ability to identify the costs for a service

SACM, the Logical Model

SACM, the Logical Model

Configuration Management delivers a required logical
model of the services, assets, and the infrastructure by
recording the relationships between configuration items
The logical model of Configuration Management is a
single common representation used by all parts of IT
Service management, and beyond, such as HR, Finance,
supplier, and customers
The Configuration Items and related configuration
information can be at varying levels of detail, for example,
an overview of all the services or a detailed level to view
the specification for a service component
44
Configuration Management delivers a required logical model of the services, assets, and the
infrastructure by recording the relationships between configuration items. The real power
of the logical model of the infrastructure of configuration management is that it is the main
model. It is a single common representation used by all parts of IT Service Management,
and beyond, such as Human Resources, Finance, suppliers, and customers.
The configuration items and related configuration information can be at various levels of
detail. For example, it can include an overview of all the services or a detailed view of a
service component specification.
A more detailed level of Configuration Management should be used when the service
provider requires tight control, traceability, and tight coupling of configuration
information.
4-57

Configuration Items
Configuration Items
A Configuration Item (CI) is an asset, service component,
or other item which is, or will be, under the control of
configuration management
Configuration Items can vary widely in complexity, size,
and type
CIs can be an entire service or system including all hardware,
software, documentation, and support staff, a single software
module, or a minor hardware component
Configuration Items can be grouped and managed

together, for example, a set of components grouped into a
release
45
A Configuration Item is an asset, service component, or other item which is, or will be,
under the control of configuration management. Configuration Items might vary widely in
complexity, size, and type, ranging from an entire service or system including all hardware,
software, documentation, and support staff to a single software module or a minor hardware
component.
Configuration Items might be grouped and managed together. An example is a set of
components might be grouped into a release. Configuration Items should be selected using
established selection criteria. In addition, they should be grouped, classified, and identified
to be manageable and traceable throughout the Service Lifecycle.
4-58

Types of Configuration Items

Types of Configuration Items

Service Lifecycle
Service
Organization
Internal
External
46
4-59

There will be a variety of CIs; the following categories can help identify them:
4-60
Service Lifecycle CIs: Include the business case, Service Management plans,
Service Lifecycle plans, Service Design Package, Release and Change plans, Test
plans. They provide a picture of:
The services of the service provider
How these services will be delivered
The benefits that are expected
The cost
The time frame for when they will be realized
Service CIs include:
Service capability assets (management, organization, processes, knowledge,

people)
Service resource assets (financial capital, systems, applications, information,

data, infrastructure and facilities, financial capital, people)
Service Model
Service Package
Release Package
Service Acceptance Criteria
Organization CIs: Some documentation will define the characteristics of a CI.

Other documentation will be a separate CI and need to be controlled. An example
is the business strategy of the organization or other policies that are internal to the
organization but independent of the service provider. Regulatory or statutory
requirements also form external products that need to be tracked, as do products
shared between more than one group.
Internal CIs: Comprise those delivered by individual projects. They include

tangible assets such as a data center. They also include intangible assets such as
software, that are required to deliver and maintain the service and infrastructure.
External CIs: Such as external customer requirements and agreements, releases

from suppliers or subcontractors and external services.



The Configuration Management System (CMS) holds all
the information for CIs within the designated scope, and is
used for wide range of purposes.
CMS maintains the relationships between all service
components and any related incidents, problems, known
errors, change and release documentation
CMS could contain corporate data about employees,
suppliers, locations and business units, customers, and
users
47
Some of these items will have related specifications or files that contain the contents of the
item such as software, documents, or a photograph.
For example, a Service CI will include the details such as:
Supplier
Cost
Purchase date
Renewal date for licenses and maintenance contracts
Related documentation, such as SLAs and Underpinning Contracts
Note: Asset data held in a CMS (CMDB data) might be made available to external financial
Asset Management systems. These systems will perform specific asset management
process reporting outside of Configuration Management.
4-61

Definitive Media Library

Definitive Media Library (DML)

Secure library that stores and protects the definitive
authorized versions of all media CIs
Stores master copies of versions that have passed quality
assurance checks
Contains the master copies of all controlled software (both
purchased and developed) in an organization
Stores master copies of controlled documentation for a
system
Is separate from development, test, or active file-storage
areas
Can consist of one or more software libraries or file-storage
areas
48
The library can consist of one or more software libraries or file-storage areas, separate from
development, test, or active file-storage areas.
4-62

Configuration Baseline
Configuration Baseline
The configuration of a service, product, or infrastructure
that has been formally reviewed and agreed upon
Serves as the basis for further activities and can be
changed only through formal change procedures
Captures the structure, contents, and details of a
configuration
Represents a set of configuration items that are related to
each other
49
4-63

SACM Benefits
SACM Benefits
Optimizes the performance of service assets and
configurations
Improves the overall service performance
Optimizes the costs and risks caused by poorly managed
assets such as:
Service outages
Fines
Correct license fees
Failed audits
50
SACM provides visibility of accurate representations of a service, release, or environment

that facilitates the following events to occur:
4-64
Better forecasting and planning of changes
Changes and releases to be assessed, planned, and delivered successfully
Incidents and problems to be resolved within the service level targets
Warranties to be delivered
Better adherence to standards, legal, and regulatory obligations (fewer

nonconformances)
More business opportunities because of ability to demonstrate control of assets

and services
Changes to be traceable from requirements
New ability to identify the costs for a service

SACM Activities
SACM Activities
Management and Planning
Configuration Identification
Configuration Control
Status Accounting and Reporting
Verification and Audit
51
The activities for Service Asset and Configuration Management include:
Management and Planning: The plans define the specific Configuration

Management activities within the context of the overarching Service Asset and
Configuration Management strategy.
Configuration Identification: Identification includes the following activities:
Define and documenting configuration items and components selection

criteria
Selecting the configuration items and the components
Assigning unique identifiers to configuration items
Specifying the relevant attributes of each configuration item
Specifying when each configuration item is placed under Configuration

Management
Identifying the owner responsible for each configuration item
Configuration Control: This activity ensures that there are adequate control
mechanisms over CIs. During this activity, a record of changes to CIs, versions,
location, and ownership is maintained.
4-65

4-66
Status Accounting and Reporting: The significance of each state should be

defined in terms of what use can be made of the asset or CI in that state. The
organization should perform configuration status accounting and reporting
activities throughout the lifecycle of the service in order to support and facilitate
an efficient Configuration Management process.
Verification and Audit: The activities include a series of reviews or audits to:
Ensure there is conformity between the documented baselines and the actual
business environment
Verify the physical existence of CIs in the organization
Check that the records in the CMS match the physical infrastructure
Check that release and configuration documentation exists before executing a

release

SACM Interfaces
SACM Interfaces
Change Management
Financial management
Problem and Incident Management
52
SACM is the single virtual repository of data and information for IT service management.
Consequently, SACM supports and interfaces with every other process and activity to some
degree. Some of the more noteworthy interfaces are as follows:
Change Management: Identifying impact of proposed changes
Financial Management: Capturing key financial information such as cost,

depreciation methods, owner, and user (for budgeting and cost allocation),
maintenance and repair costs
IT Service Continuity Management (ITSCM): Awareness of assets the business

services depend on, control of key spares and software
Incident Management, Problem Management, or Error Management:

Providing and maintaining key diagnostic information, maintenance and
provision of data to Service Desk
Availability Management: In detection of points of failure
Configuration Control (synonymous with change control): Understanding and

capturing updates to the infrastructure and services
4-67

SACM Key Performance Indicators

SACM KPIs
Percentage improvement in maintenance scheduling over
the life of an asset
Degree of alignment between provided maintenance and
business support
Assets identified as the cause of service failures
Improved speed for incident management to identify faulty
CIs and restore service
Impact of incidents and errors affecting specific CI types
53
Other KPIs for SACM include:
4-68
Percentage re-use and redistribution of under utilized resources and assets
Degree of alignment of insurance premiums with business needs
Ratio of used licenses against paid for licences (should be close to 100%)
Average cost per user for licenses
Achieved accuracy in budgets and charges for the assets utilized by each customer
or business unit
Percentage reduction in business impact of outages and incidents caused by poor

Improved audit compliance

SACM Challenges, Critical Success Factors,

and Risks
SACM Challenges
Convincing technical support staff to adopt a check in and
check out policy
Attracting and justifying funding for SACM,
Overcoming an overemphasis on data collection
Gaining commitment and support from management who
do not understand the importance of SACM to other
processes
54
Some of the Critical Success Factors include:
Establishing valid justification for collecting and maintaining data at the agreed
level of detail
Demonstrating a top-down approach
Setting a justified level of accuracy
Making use of enabling technology to automate the CMS practices and enforce
SACM policies
Some of the Risks to successful SACM include:
Over emphasis on a technical focus, rather than a service and business focus
Degradation configuration information accuracy over time that can cause errors
and be difficult and costly to correct
Not keeping the CMS up to date due to the movement of hardware assets by nonauthorized staff
4-69

Service Asset Manager

Service Asset Manager

Evaluates existing Asset Management systems and the design
Develops Asset Management standards, Asset Management plans,
and procedures
Arranges recruitment and training of staff
Ensures that staff comply with identification standards
Proposes interfaces, agrees to interfaces, or both with Change
Management, Problem Management, Network Management, Release
Management, computer operations, logistics, finance, and
administration functions
Plans population of the Asset DB and manages the Asset DB, central
libraries, and tools
Provides reports, including management reports (indicating
suggested action to deal with current or foreseen shortcomings),
impact analysis reports, and asset status reports
55
4-70

Configuration Manager
Configuration Manager
Evaluates existing Configuration Management Systems (CMS) and
their design
Agrees to CIs to be uniquely identified with naming conventions.
Ensures that staff comply with identification standards for object
types, environments, processes, lifecycles, documentation, versions,
formats, baselines, releases, and templates
Proposes interfaces to and agrees to interfaces with Change
Management, Problem Management, Network Management, Release
Management, computer operations, logistics, finance, and
administration functions
Plans population of the CMS. Manages CMS, central libraries, tools,
common codes and data. Ensures regular maintenance of the CMS
Provides reports, including management reports (indicating
suggested action to deal with current or foreseen shortcomings),
impact analysis reports, and configuration status reports
56
4-71

Configuration Analyst
Configuration Analyst
Proposes scope of the processes and recorded information Develops
Asset and Configuration Management standards, plans, and
procedures
Trains Asset and Configuration Management specialists
Creates Asset and Configuration Management processes and
procedures
Assists in uniquely identifying CIs with naming conventions
Ensures that developers and configuration system users comply with
identification standards
Liaises with the configuration administrator and librarian on
population of the CMS
Manages asset and CMS, central libraries, common codes and data
Uses or provides the asset and CMS to facilitate impact assessment
for RFCs
57
4-72

Configuration Administrator or Librarian

Configuration Administrator or Librarian

Controls the receipt, identification, storage, and withdrawal of all
supported CIs
Provides information on the status of CIs
Numbers, records, stores and distributes Asset and Configuration
Management issues
Assists Asset and Configuration Management to prepare the Asset
and Configuration Management Plan
Creates an identification scheme for Configuration Management
libraries and the Definitive Media Library (DML)
Creates an identification scheme for assets and the Definitive Spares
(DS)
Creates libraries or other storage areas to hold CIs
Assists in the identification of products and CIs
58
Further duties of this role include:
Maintains current status information on CIs
Accepts and records the receipt of new or revised configurations into the
appropriate library
Archives replaced CI copies
Holds the master copies
Administers configuration control process
Produces configuration status accounting reports
Assists in conducting configuration audits
Works with other configuration libraries where CIs are common to other systems
4-73

Process of Release and Deployment Management
Lesson 5: Process of Release and

Deployment Management
Lesson 5: Process of Release and

Deployment Management
4-74

Release and Deployment Management Goals

Release and Deployment Management Goals

To deploy releases into production.
To facilitate effective use of the service in order to deliver
value to the customer.
60
Well-planned and implemented release and deployment makes a significant difference to

the service costs of an organization. A poorly designed release or deployment will, at best,
force IT personnel to spend significant amounts of time troubleshooting problems and
managing complexity. At worst, it can cripple the environment and degrade the live
services.
A Release Unit describes the portion of a service or it infrastructure that is normally
released together according to the release policy of the organization. The unit might vary,
depending on the types or items of service asset or service component, such as software and
hardware.
The general aim is to decide upon the most appropriate Release Unit level for each service
asset or component. An organization might, for example, decide that the Release Unit for
business critical applications is the complete application. They might make this decision to
ensure that testing is comprehensive. The same organization might decide that a more
appropriate Release Unit for a Web site is at the page level.
4-75

Release and Deployment Management

Objectives
Release and Deployment Management Objectives

Ensure clear and comprehensive release and deployment
plans
Ensure a release package can successfully be built,
installed, tested, and deployed
Ensure a new or changed service and its enabling
systems, technology and organization are capable of
delivering the agreed service requirements
Ensure minimal unpredicted impact on production
services, operations, and the support organization
Ensure customers, users, and Service Management staff
are satisfied with the Service Transition practices and
outputs
61
4-76

Release Management Process

Release Management Process

Begins with receipt of an approved RFC to deploy a
Release Package
Deployment commences with receipt of an approved RFC
to deploy a Release Package to a target deployment
group
Deployment is completed with a handover of the new or
changes service to Operations
62
Release and Deployment Management is important to ensure that there are clear release and
deployment plans. In addition, Release and Deployment Management makes sure that
skills and knowledge are transferred to operations and support staff. Furthermore, Release
and Deployment Management makes certain there is minimal unpredicted impact on
production services.
The release process commences with receipt of an approved RFC to deploy a productionready Release Package. Deployment commences with receipt of an approved RFC to
deploy a Release Package to a target deployment group or environment. Examples include
a business unit, customer group, or service unit.
Deployment is completed with a transfer of the new or changed service to Operations. This
transfer occurs when Change Management successfully completes a post implementation
review of the deployment.
4-77

Factors to Consider for Release Units

Factors to Consider for Release Units

The ease and amount of change necessary to release
and 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 proposed unit
and the rest of the services and IT infrastructure
The storage available in the build, test, distribution, and
production environments
63
Factors to consider for release units include:
The ease and amount of change necessary to release and 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 proposed unit and the rest of the
services and IT infrastructure
The storage available in the build, test, distribution, and live environments.
Releases should be uniquely identified according to a scheme defined in the release policy.
The release identification should include a reference to the CIs that it represents and a
version number that will often have two or three parts, for example, emergency fix releases:
Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.
4-78


Benefits
Release and Deployment Management Benefits

Delivers change faster, at optimum cost, and with
minimized risk
Assures that customers and users can use the new or
changed service in a way that supports the business
goals
Improves consistency in implementation approach across
the business
Contributes to meeting auditable requirements for
traceability through Service Transition
64
4-79


Activities
Release and Deployment Management Activities

Planning
Preparing for build, test and deployment
Building and testing
Testing services and conducting pilots
Planning and preparing for deployment
Performing and transfer, deplo yment and retirement
Verifying deployment
Conducting early life support (ELS)
Reviewing and closing services
Reviewing and closing service transitions
65
Some of the sub-activities to these activities include:
Planning:
Developing release and deployment plans
Planning the pass or fail criteria
Building and testing prior to production
Planning release package and build
Deployment planning
Logistics and delivery planning
Financial and commercial planning
Preparing for build, test and deployment
Building and testing
4-80
Using release and build documentation

Acquiring and testing input configuration items and components
Packaging the release
Building and managing test environments
Testing services and conducting pilots
Conducting service rehearsals
Delivering rehearsals
Documenting rehearsals
Taking action after rehearsals
Conducting pilots
Planning and preparing for deployment
Conducting assessments
Developing plans and preparing for deployment
Performing transfer, deployment and retirement
Transferring and transitioning business and organization
Deploying processes and materials
Transferring services
Deploying services
Decommissioning and retiring services
Removing redundant assets
4-81

Service V Model
The left side of the diagram represents the specification of the service requirements down
through the detailed service design.
The right side focuses on the validation activities that are performed using the
specifications defined on the left side.
At each stage on the left side, the equivalent group on the right side is directly involved.
4-82

Release and Deployment Management Inputs

and Outputs
Release and Deployment Management Outputs

Release and deployment plan
Completed RFCs for the release and deployment
activities
Service notification
Updated service catalog with the relevant information
about the new or changed service
67
The release process begins with receipt of an approved RFC to deploy a production-ready
release package. Deployment begins when an approved request to deploy a release package
to a target deployment group or environment is received
4-83

Release and Deployment Management inputs are:
4-84
Authorized RFC
Service level package
Service design package, including service model and service acceptance criteria
(SAC)
IT service continuity plan and related business continuity plan
Service Management and operations plans and standards
Technology and procurement standards and catalogs
Acquired service assets and components and their documentation
Build models and plans
Environment requirements and specifications
Release policy and release design from Service Design
Release and deployment models including template plans
Exit and entry criteria for each stage of release and deployment

Release and Deployment Management KPIs

Release and Deployment Management KPIs

Variance from service performance required by
customers (minimal and reducing)
Number of incidents against the service (low and
reducing)
Increased customer and user satisfaction with the
services delivered
Decreased customer dissatisfaction
68
4-85


Challenges, Success Factors, and Risks
Release and Deployment Management Challenges

Developing standard performance measures and
measurement methods across projects and suppliers
Coping with projects and suppliers with inaccurate
estimated delivery dates resulting in delays in activities
Understanding the different stakeholder perspectives that
strengthen effective risk management
Building a thorough understanding of risks that have
impacted or might impact successful Service Transition
Encouraging a risk management culture where people
share information and take a pragmatic approach to risk
69
Some of the critical success factors in Release and Deployment Management are:
The new or changed service capability and resources are built in the target
environment or deployment group
The new or changed service has been tested against the Service Design
The service capability has been proved in a pilot deployment
Re-usable test models are developed that can be used for regression testing in
future releases
Some of the risks to Release and Deployment Management include:
4-86
Poorly defined scope
Uncommitted staff
Incompetent management
Lack of finances to support the effort
Poorly defined controls

Unclear expectations from stakeholders
Poor communication
Poor decision-making processes
Lack of support from senior management
Lack of contingency plan
Poor design
4-87

Release Packaging and Build Manager

Release Packaging and Build Manager

Establishes the final release configuration (for example,
knowledge, information, hardware, software, and
infrastructure)
Builds the final release delivery
Tests the final delivery before independent testing
Establishes and report outstanding known errors and
workarounds
Provides input to the final implementation sign-off process
70
Release Packaging and Build Management is the flow of work to deliver applications and
infrastructure that meet the Service Design requirements. The flow of work includes:
Establish requirements
Design
Build
Test
Deploy
Operate
Optimize
The Release Packaging and Build Manager cannot perform this role in isolation. This role
will have significant interaction with the following functions, among others:
4-88
Change and Service Asset Configuration Management
Capacity Management

Incident Management
4-89

Deployment Manager
Deployment Manager
Coordinates release documentation and communications,
including training, and customer documentation, service
management, and technical release notes
Plans the deployment in conjunction with Change and
Service Knowledge Management Systems (SKMS) and
Service Asset Configuration Management (SACM)
Provides technical and application guidance and support
throughout the release process, including known errors
and workarounds
Provides feedback on the effectiveness of the release
Records metrics for deployment to ensure within agreedupon Service Level Agreements (SLAs)
71
4-90

Process of Service Validation and Testing
Lesson 6: Process of Service Validation and

Testing
Lesson 6: Process of Service Validation

and Testing
4-91

Service Validation and Testing Purpose

Purpose of Service Validation and Testing

Obtain objective evidence that new or changed service
will support all agreed-upon service levels
Quality assure a release and all its service components
Identify, assess and address issues, errors, and risks
throughout Service Transition
73
Service Validation and Testing ensures that all new and changed services will successfully
achieve their purpose and use. If services are not adequately tested, prior to being
introduced into the live environment, it could lead to a rise in:
4-92
Incidents
Service desk calls
Problems and errors
Costs
Ineffective use of Services

Objectives of Service Validation and Testing

Objectives of Service Validation and Testing

Confirm that the new or changed service or service
offering:
Will deliver the expected outcomes and value for the
customers within projected costs, capacity, and constraints
Will deliver the required performance with desired
constraints removed
Meets certain specifications under the specified terms and
conditions of use
Have been correctly defined in terms of customer and
stakeholder
Requirements
74
In addition to these objectives, any errors or variances should be remedied early in the
Service Lifecycle, a considerably cheaper option than fixing errors in production.
4-93

Service Validation and Testing Benefits

Service Validation and Testing Benefits

Service failures can result in:
Loss of reputation
Loss of money
Loss of time
Injury
Death
Increased degree of confidence in required value and

outcomes
75
For testing to be successful, all parties must understand that it does not give any guarantees.
However, validation and testing provides a measured degree of confidence. The required
degree of confidence varies depending on the business requirements and pressures of an
organization.
4-94

Service Validation and Testing Activities

Service Validation and Testing Activities

Validation and Test Management
Test Planning and Design
Verify Test Plan and Test Design
Prepare the Test Environment
Perform Tests
Evaluate Exit Criteria and Report
Test Clean Up and Closure
76
Validation and Testing activities are not undertaken in a sequence. Service Validation and
Testing activities include:
Validation and Test Management: Test management includes the planning,

control and reporting of activities through the test stages of Service Transition.
These activities include:
Planning the test resources
Prioritizing and scheduling tests
Managing and documenting incidents, problems, errors, nonconformances,

risks, and issues
Monitoring progress and feedback from validation and test activities
Managing incidents, problems, errors, nonconformances, risks, and issues

discovered during transition
Capturing configuration baseline
Testing metrics collection, analysis, reporting, and management
4-95

4-96
Test Planning and Design: This activity begins early in the lifecycle. These
activities include:
Defining required resources
Supporting services including access, security, catering, communications
Scheduling milestones, and delivery dates
Confirming time for consideration of reports and other deliverables
Establishing point and time of delivery and acceptance
Establishing financial requirements and budgets
Verify Test Plan and Test Design: These activities include:
Ensuring that the test model delivers adequate and appropriate test coverage
for the risk profile of the service
Verifying that the test model covers the key integration aspects and interfaces
Validating that the test scripts are accurate and complete
Prepare the Test Environment: The release and deployment processes should
also be used to prepare the test environment when appropriate.
Perform Tests: Carry out and record the results of all tests according to test plans.
All results should be documented.
Evaluate Exit Criteria and Report: Compare actual results to predicted results.
Summarize the results of the test metrics.
Test Clean Up and Closure: Ensure that the test environments are cleaned up or
initialized. Identify areas for improvement.

Service Validation and Testing Interfaces

Service Validation and Testing Interfaces

Works with Service Design to ensure that designs are
valid
Works closely with CSI to feed failure information and
improvement ideas resulting from testing exercises
Service Operation will use maintenance tests to ensure
the continued efficacy of services.
Service Strategy should make sure that testing is include
in budget, resource and profile planning.
77
4-97

Service Validation and Testing Inputs and

Outputs
Service and Validation Testing Inputs

The Service Package
Service Level Package
Service Provider Interface Definitions
Service Design Package
Release and Deployment Plans
Acceptance Criteria
Request for Change Documents
78
The direct output from testing is the report delivered to service evaluation. This report
covers the following information:
4-98
Configuration baseline of the testing environment
Testing carried out (including options chosen and constraints encountered)
Results from those tests
Analysis of the results including:
Comparison of actual results with expected results
Risks identified during testing activities

Service Validation and Testing KPIs

Service and Validation Testing KPIs

Reduction in the impact of incidents and errors
attributable to newly transitioned services
More effective use of resource and involvement from the
customer
Reduced delays in testing that impact the business
Increased mutual understanding of the new or changed
service
Clear understanding of roles and responsibilities
associated with the new or changed service
79
4-99

Service Validation and Testing Challenges,

Critical Success Factors, and Risks
Service and Validation Testing Challenges

The most common challenge to effective testing is the
lack of respect and understanding for the role of testing.
As a result, Testing and Validation often does not receive
adequate funding. This makes it difficult to set up a test
environment that mirrors that of the client.
Lack of staff, skills, and testing tools make it challenging
to complete testing on schedule.
80
Critical success factors for validation and testing include:
4-100
Understanding stakeholder perspectives that support effective risk management

for the change impact assessment and test activities
Building a thorough understanding of risks that have impacted or might impact

successful Service Transition of services and releases
Encouraging a risk management culture where people share information and take
a pragmatic approach to risk
Building quality into every stage of the service lifecycle using a structured
framework such as the V-model
Identifying issues are identified early in the service lifecycle
Testing provides evidence that the service assets and configurations have been
built and implemented correctly
Developing test models that can be used again for regression testing in future
releases

Risks to successful validation and testing include:
Unclear expectations and objectives
Lack of understanding of the risks means that testing is not targeted at critical
elements
Resource shortages introduce delays and have an impact on other Service

Transitions
4-101

Test Manager
Test Manager
Define the test strategy
Design and plan testing conditions, test scripts, and test data sets to
ensure appropriate and adequate coverage and control
Allocate and oversee test resources while implementing test policies
Provide management reporting on test progress, test outcomes,
success rates, issues, and risks
Conduct tests as defined in the test plans and design
Record, analyze, diagnose, report, and manage test events
Manage test environment requirements \
Verify tests conducted by release and deployment teams
Administer test assets and components
81
4-102

Process of Evaluation
Lesson 7: Process of Evaluation
Lesson 7: Process of Evaluation
4-103

Evaluation
Evaluation
The process responsible for assessing a new or changed
IT service to ensure that risks have been managed
Help determine whether to proceed with the change
83
The purpose of evaluation is to provide a consistent and standardized method of

determining the performance of a service change. Evaluation is accomplished in the context
of existing and proposed services and IT infrastructure. The actual performance of a change
is assessed against its predicted performance. Any deviations between the two are analyzed
and managed.
4-104

Objectives of Evaluation
Objectives of Evaluation
Evaluate the intended effects and unintended effects
(depending on constraints) of a service change
Provide good quality outputs so that Change
Management can expedite decision about service change
approval
84
The goal of evaluation is to set achievable stakeholder expectations. In addition, evaluation

hopes to provide effective and accurate information to Change Management. This
information will make sure changes that adversely affect service capability and introduce
risk are not overlooked.
The evaluation process uses the PlanDoCheckAct (PDCA) model to ensure consistency
across all evaluations.
4-105

Evaluation Benefits
Evaluation Benefits
Information will allow a more accurate focus on value in
future service development and Change Management
Continual Service Improvement can use evaluation to
analyze future improvements to the process of change
Enable predictions and measurement of service change
performance
85
4-106

Evaluation Activities
Evaluation Activities
Evaluation of predicted performance
Analyze test plan results
Evaluate risk
Evaluation of actual performance
Develop evaluation report
Complete evaluation report
86
4-107

Evaluation Inputs and Outputs

Evaluation Inputs and Outputs

Inputs for Evaluation include:
Service Package (SP)
Service Acceptance Criteria (SAC)
Test results and report
Evaluation output consist of the evaluation report for
Change Management.
87
4-108

Evaluation KPIs
Evaluation KPIs
Variance from service performance required by
customers (minimal and reducing)
Number of incidents against the service (low and
reducing)
Number of failed designs that have been transitioned
(zero)
Cycle time to perform an evaluation (low and reducing)
88
4-109

Evaluation Challenges
Evaluation Challenges
Developing standard performance measures and methods across
projects and suppliers
Dealing with projects and suppliers inaccurately estimating delivery
dates
Understanding the different stakeholder perspectives that strengthen
effective risk management for the evaluation activities
Assessing the balance between managing and taking risks as it
affects service delivery
Demonstrating less variation in predictions during and after transition
Taking a pragmatic and measured approach to risk
Building a thorough understanding of risks that have impacted or
might impact successful Service Transition
Encouraging a risk management culture where people share
information
89
4-110

Performance and Risk Evaluation Manager

Performance and Risk Evaluation Manager

Uses Service Design and release package to develop the
evaluation plan to input to service testing
Establishes risks and issues associated with all aspects
of the Service Transition
Provides evaluation report to input to Change
Management
90
4-111

Process of Knowledge Management
Lesson 8: Process of Knowledge

Management
Lesson 8: Process of Knowledge

Management
4-112

Knowledge Management Purpose and Goal

Knowledge Management Purpose and Goal

The purpose of Knowledge Management is to ensure that
information is delivered to the appropriate place or
competent person at the right time to facilitate an
informed decision.
The goal of Knowledge Management is to help
organizations improve the quality of management
decisions. It assists in decision making by ensuring that
reliable and secure information is available throughout the
service lifecycle.
92
4-113

Knowledge Management Objectives

Knowledge Management Objectives

Enable service provider to be more efficient, improve
quality of service, increase satisfaction, and reduce cost
Ensure staff understand the value their services provide
to customers and the ways in which this value is realized
Ensuring that, at a given time and location, service
provider staff have adequate information on:
Who is currently using their services
The current states of consumption
Service delivery constraints
Difficulties faced by the customer in fully realizing the benefits
expected from the service
93
4-114

Knowledge Management Benefits

Knowledge Management Benefits

Thorough understanding of new or changed service by
the user, service desk, support staff and supplier
Awareness of the use of the service, and the
discontinuation of previous versions
Establishment of the acceptable risk and confidence
levels associated with the transition
94
4-115

DIKW
DIKW
Knowledge Management is usually displayed within the
DatatoInformationtoKnowledgetoWisdom (DIKW)
structure.
Data is a set of discrete facts about events.
Information comes from providing context to data.
Knowledge is composed of the tacit experiences, ideas,
insights, values, and judgments of individuals.
Wisdom gives the ultimate discernment of the material
and having the application and contextual awareness to
provide a strong common sense judgment.
95
4-116

Knowledge Management Activities

Knowledge Management Activities

Developing a Knowledge Management strategy
Transferring knowledge to other parts of the organization
at specific points in the lifecycle
Establishing data and information requirements
Defining the information architecture
Establishing data and information management
procedures
Evaluating and Improving Knowledge Management
Using the service knowledge management system
96
Service Knowledge Management consists of the following activities.

Developing a Knowledge Management strategy including:
Identifying the governance model
Identifying the organizational changes underway
Identifying planned and consequential changes in roles and responsibilities
Establishing roles and responsibilities and ongoing funding
Identifying policies, processes, procedures and methods for Knowledge

Management
Addressing technology and other resource requirements
Identifying performance measures
Identifying and planning for knowledge identification capture and maintenance
4-117

Transferring knowledge to other parts of organization at specific points in lifecycle
Conducting formal training and developing documentation
Analyzing any knowledge gaps within the organization
Establishing a communications improvement plan if necessary
Establishing data and information requirements
Establishing the designated data and information items, content, form, and reason
Encouraging the use of common and uniform content and format requirements
Establishing data security requirements
Defining user access requirements
Identifying changes
Defining the information architecture
Creating and regularly updating a Service Management information model
Defining stable and optimal information systems
Standardizing data classification schemes across the organization
Establishing data and information management procedures including:
Identifying information to be collected
Maintaining and disseminating information collected
Storing and retrieving data
Establishing authority and responsibility for information and data items
Defining and communicating rights, obligations and commitments for the

retention of, transmission of, and access to information and data items
Establishing backup and recovery of data
Handling collection and retention requirements
Evaluating and Improving Knowledge Management
4-118
Measuring the use of collected information
Evaluating the usefulness of collected information
Identifying irrelevant information

Using the service knowledge management system
Aligning training and knowledge material to the business perspective
4-119

Knowledge Management Inputs and Outputs

Knowledge Management Inputs and Outputs

Service Operations
Operations Staff
Transition Staff
97
Effective Service Knowledge Management depends on the support and delivery by most,
if not all, of those working in and around IT Service Management. Service Knowledge
Management has the following specific inputs and outputs.
Service Operations
Service Knowledge Management will record and analyze errors within the service detected
during transition. These errors, along with consequences and workarounds, will be
communicated to Service Operations.
Operations Staff
Incident management staff, on service desk and second-line support, are the point of
capture for much of the everyday IT Service Management data. They must report their
actions completely in order for Service Knowledge Management to be effective. Problem
management staff will be key users of collected knowledge. They are typically responsible
for the normalization of data capture by means of developing and maintaining scripts
supporting data capture within incident management.
4-120

Transition Staff
Service Transition staff capture data of relevance through all lifecycle phases. Therefore,
they need to be aware of the importance of collecting it accurately and completely.
4-121

Knowledge Management KPIs

Knowledge Management KPIs

Reduction in the user error category of errors due to
targeted knowledge transfer
Lower incident, problem and error resolution times
Enhanced customer experiences such as:
Quicker resolution of a query
Directly resolved issues without external support
Decreased transfer of issues and resolution at lower
staff levels
Reduced time for transition and duration of early life
support
98
4-122

Knowledge Management Process Owner

Knowledge Management Process Owner

The role of the Knowledge Management process owner is
crucial.
This role will design, deliver, and maintain the Knowledge
Management strategy, process, and procedures.
99
The Knowledge Management process owner has the following responsibilities:
Ensures compliance with organization policies and processes
Performs knowledge identification, capture, and maintenance
Identifies, controls and stores pertinent information not available by any other
means
Maintains the controlled knowledge items
Ensures all knowledge items are accessible to those who need them
Monitors publicity regarding the knowledge information
Acts as an advisor to business and IT personnel on Knowledge Management

matters
4-123

Unit Scenario

Unit 4 introduced the management area of Service Transition. Within this area is the
introduction of a service into production and its lifecycle. An example of a lifecycle is from
development to testing. For this scenario, a company is running its financial structure on a
mainframe system. They want to introduce a new financial system into the organization to
take advantage of streamlined processes. This change will lead to increased productivity
and automation of functions that today can be extremely manual and labor intensive.
An introduction of a new financial system might likely come from the head of the financial
department or the operations manager for the IT department. This system initiation might
be because of costly maintenance of the mainframe or lack of skills within the team. In
addition, a request such as this might come from the leadership of the business. Finance
might be unable to provide the type of reporting and analysis necessary to keep up with
market trends and fast changing sales approaches.
The request can come in many forms. However, it is likely to enter the system as a service
change request because the service of providing financials exists but needs altering. A
change to the financial structure of the organization is not one that any business can take
lightly. Thus, a request such as this is likely to go through rigorous approvals, reviews and
analysis. In addition, it might need approval from the board of the organization because of
the cost and level of effort. Transition might not focus on this area. However, it will deal
with the change requests that are necessary to implement this service change.
Change Management will oversee the numerous changes, such as a request for hardware
and software for the new architecture of the new system. This change should undergo
impact, security and data analyses reviews. This unit covered the overall change
management concepts and process. Therefore, there will likely be numerous changes. For
example, the retirement of the mainframe operations which support the existing financials.
Another change might be the establishment of the new software and system to set up
testing, development, and training environments.
ITIL v3 introduced the 7 Rs of change. Example of these might be:
4-124
Raised: Financial VP.
Reason: Current application is not providing the level of financial support to the
business as needed.
Return: Employee efficiencies within the finance team and to the overall business
from Sales to Payroll capabilities
Risks: New system might not be accepted easily; resources will need retraining;
IT team is understaffed and will struggle to implement. Cost analysis was
inaccurate, and it will require added cost to get to production.

Unit Scenario
Resources Required: Hardware, software, subject matter experts with the new
tool set. Resources trained in main frame for change of processes, project team
such as project manager, application designer, and database manager.
Responsible: Development resources such as a consultant team or database and

server administrator who might be responsible for development. Most likely,
users, trainers, and system administrators who handle and own responsibility for
testing and the final implementation. Can be owned by all of those resources. In
addition, the IT operations staff for a smooth transition into production.
Relationship: Relationship to other changes, such as whether there is a year end

or quarter end to be noted, or a sales push for end of year. More tactical examples
include other systems with which the tool set will interface. Any downstream
systems that might need to be changed to accommodate the new general ledger
data or data parameters.
As you learned, service transition does not end at change management. It also encompasses
release and service asset configuration management. Change provides the controls that are
necessary to bring a new application into an organization. However, release and service
asset configuration helps the organization to determine how this will be accomplished. For
example, a release unit of the new system might be payroll versus payables. The purpose
of this release unit is to minimize external facing risks for the first release of the tool set. In
addition, it will also help the organization to quickly revert back to the previous system if
redundancy was planned for at least first release.
As you can imagine, the roles involved in a service change such as this are extensive. The
unit describes the general ITIL service change roles. A more specific example is the
training team assigned to determine necessary training. A further example is the
communications team assigned to help advise the whole organization about the changes to
the new system. Consider other roles such as database administrators who oversee a new
system, or security to ensure system lock down and availability.
This scenario is one example of how Service Transition might be used in an organization.
Most organizations are already performing these types of tasks and efforts. However, it is
typically not structured, regimented, or controlled in the manner that ITIL v3 introduces.
4-125

Unit Scenario
Review Questions
1.
Which of the following are objectives of Service Transition? Choose all that
apply.
a.Ensure that IT and the customers have a clear and unambiguous expectation of the
level of service to be delivered.
2.
b.
Set customer expectations on how the performance and use of the new or
changed service can be used to facilitate business change
c.
Help the business change project or customer to integrate a release into their
business processes and services.
d.
All of the above.
Which of the following describes the value Service Transition provides to the
business? Check all that apply.
a.Improves predictions of service levels and warranties for new and changed
services
3.
b.
Expedites timely cancellation or changes to maintenance contracts for both

hardware and software when components are disposed of or decommissioned
c.
Aids understanding the level of risk during and after change, for example,
service outage, disruption, and rework
d.
All of the above
The IT service must be negatively affecting the business to a high degree to

initiate which type of change?
a.Normal Change
4.
b.
Standard Change
c.
Emergency Change
d.
Service Change
A desktop move for a single user is an example of which of the following

changes?
a.Normal Change
4-126
b.
Standard Change
c.
Emergency Change
d.
Simple Change

Unit Scenario
5.
A portion of a service or IT infrastructure that is normally released together

according to the release policy of the organization is referred to as which of the
following choices?
a.Service Change
6.
b.
Change Request
c.
Configuration Item
d.
Release Unit
What are the seven Rs of Change Management?

a.Questions that must be answered for all changes
7.
b.
A formal policy for Service Transition
c.
An outline for the Change Management process
d.
All of the above
Which is the correct order for service activities in the Service V model?
a.Define Customer and Business Requirements, Design Service Release, Define
Service Requirements, Design Service Solution, Develop Service Solution
8.
b.
Define Customer and Business Requirements, Define Service Requirements,

Design Service Solution, Design Service Release, Develop Service Solution
c.
Define Service Requirements, Define Customer/Business Requirements,

d.
Define Customer and Business Requirements, Define Service Requirements,

Design Service Solution, Develop Service Solution, Design Service Release
Which is the correct order for validation activities in the Service V model?
a.Validate Service Packages, Offerings, and Contracts, Service Acceptance Test,
Service Release Package Test, Component and Assembly Test, Service
Operational Readiness Test
b.
Service Acceptance Test, Validate Service Packages, Offerings, and

Contracts, Service Operational Readiness Test, Service Release Package Test,
Component and Assembly Test
c.
Validate Service Packages, Offerings, and Contracts, Service Acceptance

Test, Service Operational Readiness Test, Service Release Package Test,
Component and Assembly Test
4-127

Unit Scenario
d.
9.
Validate Service Packages, Offerings, and Contracts, Service Acceptance

Test, Service Operational Readiness Test, Component and Assembly Test,
Service Release Package Test
The addition, modification, or removal of authorized, planned, or supported

service or service component and its associated documentation is called which of
the following choices?
a.Standard Change
10.
b.
Change Request
c.
Service Request
d.
Service Change
A formal communication seeks an alteration to one or more Configuration Items.

Which type of change request would this require?
a.Standard Change
11.
b.
Change Request
c.
Service Request
d.
Service Change
Which of the following choices is the goal to provide a logical model of the IT
infrastructure correlating IT services and components needed to deliver these
services? It completes this goal by defining and controlling the components of
services and infrastructure and maintaining accurate configuration records.
a.Service Asset and Configuration Management
12.
b.
c.
Change Management
d.
Service Transition Management
Which of the following choices is the goal of deploying releases into production
and ensuring effective use of the service to deliver value to the customer?
4-128
b.
c.
Change Management
d.

Unit Scenario
4-129

Unit Scenario
Review Answers
1.
Which of the following are objectives of Service Transition? Choose all that
apply.
b. Set customer expectations on how the performance and use of the new or
changed service can be used to facilitate business change
AND
c. Help the business change project or customer to integrate a release into their
business processes and services.
2.
Which of the following describes the value Service Transition provides to the
business? Check all that apply.
d. All of the above
3.
The IT service must be negatively affecting the business to a high degree to

initiate which type of change?
c. Emergency Change
4.
A desktop move for a single user is an example of which of the following

changes?
b. Standard Change
5.
A portion of a service or IT infrastructure that is normally released together

according to the release policy of the organization is referred to as which of the
following choices?
d. Release Unit
6.
What are the seven Rs of Change Management?

a. Questions that must be answered for all changes
7.
Which is the correct order for service activities in the Service V model?
b. Define Customer and Business Requirements, Define Service Requirements,
8.
Which is the correct order for validation activities in the Service V model?
c. Validate Service Packages, Offerings, and Contracts, Service Acceptance Test,
Service Operational Readiness Test, Service Release Package Test, Component
and Assembly Test
4-130

Unit Scenario
9.
The addition, modification, or removal of authorized, planned, or supported

service or service component and its associated documentation is called which of
the following choices?
a. Service Change
10.
A formal communication seeks an alteration to one or more Configuration Items.

Which type of change request would this require?
b. Change Request
11.
Which of the following choices is the goal to provide a logical model of the IT
infrastructure correlating IT services and components needed to deliver these
services? It completes this goal by defining and controlling the components of
services and infrastructure and maintaining accurate configuration records.
a. Service Asset and Configuration Management
12.
Which of the following choices is the goal of deploying releases into production
and ensuring effective use of the service to deliver value to the customer?
b. Release and Deployment Management
4-131

Unit Scenario
Summary
Summary
Service Transition
Discuss Service Transition processes and associated
activities
Describe the Service Transition roles
101
4-132
5-1
Introduction
In this unit, you will learn about Service Operation.
Objectives
Objectives
Service Operation
Discuss Service Operation processes and associated
activities
Describe the Service Operation roles
5-2

Service Operation Overview
Lesson 1: Service Operation Overview
Lesson 1: Service Operation Overview
5-3

Service Operation
Service Operation
The purpose of Service Operations is to coordinate and
to carry out activities and processes required to deliver
and manage services at agreed-upon levels to business
users and customers
5-4

Service Operation Scope

Service Operation: Scope

Service Operation is any activity that forms part of a service is
included in Service Operation. Such activities include those
performed by the Service Provider, an external supplier, and the user
or customer of that service
The services themselves. Any activity that forms part of a service is
included in Service Operation, even if it is performed by:
The service provider
An external supplier
The user or customer of that service
Service Management Processes. The ongoing management and
execution of many Service Management processes are performed in
Service Operation
Many ITIL processes (such as Change Management and Capacity Management) originate
at the Service Design or Service Transition stage of the Service Lifecycle. However, these
processes are in use continually in Service Operation. Some processes are not included
specifically in Service Operation, such as Strategy Definition, the actual design process
itself. These processes focus more on longer-term planning and improvement activities.
Therefore, they are outside the direct scope of Service Operation. However, Service
Operation provides input and influences these regularly as part of the lifecycle of Service
Management.
All services require some form of technology to deliver them. Managing this technology is
not a separate issue, but an integral part of the management of the services themselves.
Regardless of what services, processes, and technology are managed, people determine the
demand for the services and products of organizations. Ultimately, people manage the
technology, processes, and services and are a key part of Service Operation.
5-5

Service Operation Goals

Service Operation: Goals
Service Operation is responsible for ongoing

management of the technology that is used to deliver
and support services
Well-designed and well-implemented processes will be

of little value if daily operation of those processes is not
properly conducted, controlled, and managed
Service improvements will not be possible if daily

activities to monitor performance, assess metrics, and
gather data are not systematically conducted during
Service Operations
Service Operations includes implementation and carrying

out of all ongoing activities required to deliver and
support services
6
Any activity that forms part of a service is included in Service Operation. It does not matter
if the activity is performed by the Service Provider, an external supplier, or the user or
customer of that service.
5-6

Service Operation Value

Service Operation Value

The operation of service is where plans, designs, and
optimizations are implemented and measured
From a customer viewpoint, Service Operation is where
actual value is seen
However, a challenge to Service Operations exists. A service is expected to run within the
budget established earlier in the lifecycle. In reality, however, very few organizations plan
effectively for the costs of ongoing management of services.
Difficulty occurs obtaining funding during the operational phase to fix design flaws or
unforeseen requirements.
Design issues are often left to Incident and Problem Management to resolve, as though they
were purely operational issues.
It can be difficult to obtain funding for tools or actions, including training, that are aimed
at improving the efficiency of Service Operations.
Attempts to optimize the service or manage it more effectively are only seen as successful
if the service has had problems in the past. Some services are taken for granted.
Improvements are perceived as unnecessary and fixing services that are not broken.
5-7

Conflicting Motives in Service Operation

Conflicting Motives in Service Operation

All functions, processes, and activities of a Service Operation are
designed to deliver a specified and agreed-upon level of services
It is possible that a conflict might develop between maintaining the
status quo and adapting to changes in the business and technological
environments
One of key roles of the Service Operation is to deal with this conflict
and to achieve a balance between conflicting sets of priorities
Resolving the conflict and moving toward a best-practice approach
represents an opportunity for growth and improvement
IT organizations might suffer from an imbalance by tending more
toward one extreme or the other
The possibility exists that a conflict might develop between maintaining the status quo and
adapting to changes in the business and technological environments.
Resolving the conflict and moving toward a best practice approach represents an
opportunity for growth and improvement.
5-8

External View of IT
External View of IT
External view is based on services that are delivered. It
is the way in which services are experienced by users
and customers. These people might not always
understand, nor care about, the details of the technology
used to manage those services. All that concerns them is
that the services are delivered as required and agreed
upon.
Potential Weakness: Focusing only on business
requirements results in making promises that cannot be
kept
Focusing on business requirements without considering the methods and logistics required
to deliver the requirements results in making promises that can not be kept.
Service Operations should maintain a balance between an internal IT view and an external
business view.
5-9

Internal View of IT
Internal View of IT
The internal view of IT is the way in which IT components
and systems are managed to deliver the services
Potential Weakness: Focusing only on internal systems
results in expensive services that deliver little value
10
As mentioned before, Service Operations should maintain a balance between an internal IT

view and an external business view.
5-10

Stability Versus Responsiveness

Service Operation: Stability versus Responsiveness

Service Operation must ensure that the IT Infrastructure
is stable and available as designed
Service Operation must meet response requirements
A balance between stability and responsiveness will
require that technologies and processes are adaptive
rather than rigid
11
The function, performance, and architecture of a platform might change over a number of
years. With each change comes an opportunity to provide better levels of service to the
business.
Other changes happen quickly and sometimes under extreme pressure. For example, a
business unit acquires a large contract that requires additional IT services, more capacity,
and faster response times.
5-11

Balancing Service Cost and Quality
Service Operation is required to consistently deliver the agreed-upon level of service.

Service Operation must keep costs and resource utilization at an optimal level. An increase
in the level of quality typically results in an increase in the cost of service. The relationship
between quality and cost of service is not always directly proportional.
For example, improving service availability from 55% to 75% can be straightforward and
might not require a huge investment. However, improving availability of the same service
from 96% to 99.9% might require large investments in high-availability technology,
support staff, and tools.
5-12

Service Operation: Reactive versus Proactive

Service Operation: Reactive versus Proactive

Reactive: A reactive organization does not act unless it is
prompted to do so by an external driver
Proactive: A proactive organization is always looking for
ways to improve the current situation
13
Reactive Risks: Each project is dealt with as though it is the first occurrence. Therefore,
responding to business needs and incidents only after they are reported can cause delivery
of new services to take a long time. Staff turnover tends to be high and morale low, as IT
staff move from project to project without achieving a lasting, stable set of IT services.
Proactive Risks: Proactive behavior is typically seen as positive. However, being too
proactive can be expensive and can result in staff being distracted. Discouraging effort
investment in proactive Service Management can ultimately increase the effort and cost of
reactive activities and further risk stability and consistency in services.
5-13

Communication in Service Operation

Communication in Service Operation

Good communication is needed:
With other IT teams and departments
With users and internal customers
Between the Service Operation teams and departments

themselves
14
In some organizations, communication takes place in meetings. Other organizations prefer

to use e-mail or the communication inherent in their Service Management tools.
One organization might require that all communications regarding changes must be sent by
e-mail. Others might believe that the Service Management tools themselves contain
sufficient information and that e-mails are redundant. Issues can often be prevented or
mitigated with appropriate communication. All communication must have an intended
purpose or a resultant action. Information should not be communicated unless there is a
clear audience.
Good communication is essential for successful Service Operation, just as it is for any other
phase of the lifecycle.
5-14

Technology Considerations for Service

Operation
Technology Considerations for Service Operation

Technology for Event Management
Technology for Incident Management
Technology Tools for Request Fulfillment
Technology Tools for Problem Management
Technology Tools for Access Management
Technology Tools for Service Desk
15
An integrated ITSM technology is needed that includes the following core functions:
Self-help capabilities
Workflow or process engine
Integrated CMS
Discovery, deployment, and licensing technology
Remote control
Diagnostic utilities
Reporting
Dashboards
Integration with business service management
5-15

Technology for Event Management

Technology for Event Management should permit a direct interface into the Incident
Management processes. This interface would be completed by entry into the Incident Log.
In addition, technology for Event Management should include the capability to escalate to
support staff, third-party suppliers, or engineers.
Technology for Incident Management

An integrated ITSM technology is required. In addition, workflow and automated
escalation tools should be used. The target times should be included in support tools, which
should be used to automate the workflow control and escalation paths.
Technology Tools for Request Fulfillment

Integrated ITSM technology is needed so that Service Requests can be linked to incidents
or events that have initiated them.
Technology Tools for Problem Management

The following tools are needed for Problem Management:
Integrated Service Management technology
Integrated Change Management technology
Integrated CMS
An effective Known Error Database
Technology Tools for Access Management

The following tools are needed for Access Management:
5-16
Human Resource Management technology
Access Management features in Applications, Middleware, Operating Systems

and Network Operating Systems
Change Management systems
Request Fulfillment technology

Technology Tools for Service Desk

The following tools are needed for Service Desk
Telephony
Support tools such as:
Known Error Database
Diagnostic scripts
Self-help web Interface
5-17

Process of Event Management
Lesson 2: Process of Event Management
Lesson 2: Process of Event Management
5-18

Event Management Defined

Event Management
An event can be defined as any significant detectable
occurrence.
An occurrence is significant if it affects the management
of the IT infrastructure or the delivery of IT service.
Events are typically notifications created by an IT Service,
Configuration Item (CI), or monitoring tool.
17
Effective Service Operation depends on knowing the status of the infrastructure and
detecting any deviation from normal or expected operation. It is provided by good
monitoring and control systems, which are based on two types of tools:
Active monitoring tools that poll key CIs to determine their status and availability.
Any exceptions will generate an alert that needs to be communicated to the
appropriate tool or team for action.
Passive monitoring tools that detect and correlate operational alerts or

communications generated by CIs.
The ability to detect events, make sense of them, and determine their appropriate control
action is provided by Event Management. Event Management is, therefore, the basis for
Operational Monitoring and Control. In addition, if these events are programmed to
communicate operational information, warnings, and exceptions, they can be used as a
basis for automating many routine Operations Management activities. Some examples of
Event Management:
Executing scripts on remote devices
Submitting jobs for processing
Dynamically balancing the demand for a service across multiple devices to

enhance performance
5-19

Event Management provides the following functions:
5-20
The entry point for the execution of many Service Operation processes and
activities
A method of comparing actual performance and behavior, against design

standards and Service Level Agreements
A basis for Service Assurance and Reporting, and Service Improvement

Event Management Process
There are many different types of events, for example:
Events that signify regular operation:
Notification that a scheduled workload has completed
A user has logged in to use an application
An e-mail has reached its intended recipient
Events that signify an exception:
A user attempts to log on to an application with the incorrect password
An unusual situation has occurred in a business process that might indicate an

exception requiring further business investigation (for example, a Web page
alert indicates that a payment authorization site is unavailable which affects
financial approval of business transactions)
A CPU of a device is above the acceptable utilization rate
A PC scan reveals the installation of unauthorized software
5-21

Events that signify unusual, but not exceptional, operation. These indicate that the
situation might require closer monitoring. In some cases the condition will resolve
itself. An example is an unusual combination of workloads. As the workloads are
completed, normal operation is restored. In other cases, operator intervention
might be required if the situation is repeated or if it continues for too long. These
rules or policies are defined in the monitoring and control objectives for that
device or service. Examples of this type of event are:
The memory utilization of a server reaches within 5% of its highest

acceptable performance level
The completion time of a transaction is 10% longer than normal
Two things are significant about the previous examples:
5-22
There is no definitive rule about exactly what constitutes normal operation,

unusual operation, or an exception. For example, a manufacturer might provide a
benchmark of 75% memory utilization is optimal for application X. However, it
is discovered that under the specific conditions of the organization, response times
begin to degrade above 70% utilization.
Each example relies on the sending and receipt of a message of some type. These
are generally referred to as Event Notifications, and they do not happen without
previous configuration. The next section will explore exactly how events are
defined, generated, and captured.

Event Management Benefits

Event Management Benefits

Provides mechanisms for early detection of incidents
Makes it possible for some types of automated activity to
be monitored by exception
Signal status changes or exceptions that allow the
appropriate person or team to perform early response
Allows the business to benefit from more effective and
more efficient Service Management overall
Provides a basis for automated operations
19
5-23

Event Management Activities

Event Management Activities

Occurrence of event
Notification of event
Detection of event
Event filtering
Categorization of event
Correlation of event
Initiation of a trigger
Selection of response
Review of actions
Closing of event
20
The Event Management process is initiated by an event. Event Management contains the
following activities:
Occurrence of event
Notification of event
Most CIs generate Event notifications using an open standard such as SNMP
(Simple Network Management Protocol).
Event notification should contain meaningful data and target a specific

audience
Detection of event
The event is detected by an agent running on the same system, or transmitted
directly to a management tool that will read and interpret the event.
Event filtering
It is determined whether the event is informational, a warning, or an exception.
5-24
Categorization of event

The event is categorized as being informational, warning, or an exception.
Informational: Informational refers to an event that does not require any action
and does not represent an exception.
Warning: A warning is an event that is generated when a service or device is

approaching a threshold.
Exception: An exception means that a service or device is currently operating

abnormally. This typically means that an SLA an OLA have been breached and
business is being affected. An example of an exception is a server going down.
Correlation of event
The significance of the event and the actions that should be taken is determined.
Initiation of a trigger
If a response is required, it is initiated using a trigger. For example, if a change is
required, a Change Trigger will initiate a Request for Change.
Selection of response: In this activity, responses to the event are chosen. They
could include:
Logging the event
Auto responding to the event
Escalating the event to include human intervention
Initiating the Incident, Problem, or Change Management process
Opening an RFC
Opening or linking to a problem record
Opening an Incident record
Review of actions
Significant events or exceptions are handled and tracked appropriately.
Closing of event
Most events are not opened or closed. However, events that generated an incident,
problem, or change should be formally closed. A link to the appropriate record
from the other process should be included.
5-25

Event Management Interfaces

Event Management Interfaces

Change Management
Capacity and Availability Management
Asset Management
21
Event Management can be initiated by any type of occurrence. The key is to define which
of these occurrences is significant and which need to be acted upon. Triggers include:
Exceptions to any level of CI performance defined in the design specifications,

Operational Level Agreements, or Standard Operating Procedures
Exceptions to an automated procedure or process, for example, a routine change

that has been assigned to a build team has not been completed in time
An exception within a business process that is being monitored by Event

Management
The completion of an automated task or job
A status change in a device or database record
Access of an application or database by a user or automated procedure or job
A situation where a device, database, or application has reached a predefined

threshold of performance
Event Management can interface to any process that requires monitoring and control. It is
especially effective for those processes that do not require real-time monitoring. However,
these processes do require some form of intervention following an event or group of events.
5-26

The primary IT Service Management (ITSM) relationships are with Incident Management,
Problem Management, and Change Management.
Capacity Management and Availability Management are critical in defining which events
are significant. In addition, they define what appropriate thresholds should be and how to
respond to them. In return, Event Management will improve the performance and
availability of services. It will respond to events when they occur and by reporting on actual
events and patterns of events. The reports will be used to determine (by comparison to SLA
targets and KPIs) if some aspect of the infrastructure design or operation can be improved.
Configuration Management can use events to determine the current status of any CI in the
infrastructure. Comparing events with the authorized baselines in the Configuration
Management System (CMS) will help to determine whether unauthorized activity is taking
place in the organizations.
Asset Management can use Event Management to determine the lifecycle status of assets.
For example, an event can be generated to signal that a new asset has been successfully
configured and is now operational.
Events can be a rich source of information that can be processed for inclusion in Knowledge
Management systems. For example, patterns of performance can be correlated with
business activity and used as input into future design and strategy decisions.
Event Management can play an important role in ensuring that potential impact on SLAs is
detected early. In addition, it can ensure that any failures are rectified as soon as possible
so that impacts on service targets are minimized.
5-27

Event Management KPIs

Event Management KPIs

Number of events by category
Number of events by significance
Number and percentage of events that required and had
human intervention
Number and percentage of events that resulted in
incidents or changes
Number and percentage of events caused by existing
problems or known errors
22
Other KPIs for Event Management include:
5-28
Number and percentage of repeated or duplicated events
Number and percentage of events indicating performance issues
Number and percentage of events indicating potential availability issues
Number and percentage of each type of event per platform or application
Number and ratio of events compared with the number of incidents

Event Management Challenges, Critical

Success Factors, and Risks
Event Management Challenges

Obtaining the necessary funding.
Setting the correct level of filtering.
Rolling out of the necessary monitoring agents across the
entire IT infrastructure.
Acquiring the necessary skills at a reasonable cost and in
a reasonable amount of time.
23
The main critical success factors for effective Event Management include:
Illustrating the benefits of effective Event Management in terms of a positive

return on investment.
Achieving the correct level of filtering. There are three keys to the correct level of
filtering:
Integrate Event Management into all Service Management processes where

feasible.
Design new services with Event Management in mind.
Include a formal process to evaluate the effectiveness of filtering.
Planning effectively for the rollout of the monitoring agent software across the
entire IT Infrastructure.
5-29

The main risks associated with Event Management include:
5-30
Failure to obtain adequate funding.
Failure to ensure the correct level of filtering.
Failure to maintain momentum in rolling out the necessary monitoring agents

across the IT Infrastructure.

Event Management Roles

Event Management Roles

Events tend to occur in multiple contexts and for many
different reasons.
It is unusual for an organization to appoint an Event
Manager.
It is important that Event Management procedures are
coordinated to prevent duplication of effort and tools.
24
The Service Desk is responsible for communicating information about this type of incident
to the relevant Technical or Application Management team and, where appropriate, the
user.
Technical and Application Management participates in the instrumentation of the service,
classify events, update correlation engines, and ensure that any auto responses are defined
during Service Design. During Service Transition, they will test the service to ensure that
events are properly generated. In addition, they will ensure that the defined responses are
appropriate. During Service Operation, Technical and Application Management will
typically perform Event Management for the systems under their control.
It is common for Event Monitoring and first-line response to be delegated to IT Operations
Management. Operators for each area are tasked with monitoring events, responding as
required, or ensuring that Incidents are created as appropriate.
5-31

Incident Management
Lesson 3: Incident Management
Lesson 3: Process of Incident

Management
5-32

Incident Management
Incidents Defined
Incidents Defined
Unplanned interruption to an IT service
Reduction in the quality of an IT service
Failure of a configuration item that has not yet affected
service
26
An incident includes failure of a configuration item that has not yet affected service is also
an incident. An example is the failure of one disk from a mirror set.
Incident Management can include handling failures, questions, or queries reported by the
users. Examples of ways incidents can be reported include:
Telephone calls to the Service Desk
Communications from technical staff
Automatic detection and reports by event monitoring tools
Incidents can also be reported, logged, or both, by technical staff. For example, technical
staff notice something unusual with a hardware or network component,. They can report or
log an incident and refer it to the Service Desk. However, all events are not necessarily
incidents. Many classes of events are not related to disruptions at all, but are indicators of
normal operation or are simply informational.
Although both incidents and Service Requests are reported to the Service Desk, they are not
the same. Service Requests do not represent a disruption to agreed-upon service. They
provide a way to meet the needs of the customers and can address an agreed-upon target in
a Service Level Agreement. Service Requests are dealt with by the Request Fulfillment
process.
5-33

Incident Management
Incident Management
Incident Management
Incident Management restores normal service operation
as quickly as possible and minimizes the adverse impact
on business operations, therefore ensuring that the best
possible levels of service quality and availability are
maintained
Normal service operation is defined as service operation
within Service Level Agreement (SLA) limits
27
Incident Management is the process for dealing with all incidents. This process can include:
Failures
Questions
Queries
Incident Management includes any event that disrupts, or that might disrupt, a service. It
includes events which are communicated directly by users, either through the Service Desk
or through an interface from Event Management to Incident Management tools.
5-34

Incident Management
Incident Management Goals

Incident Management Goals

The primary goal of the Incident Management process is
to restore normal Service Operation as quickly as
possible.
Incident Management tries to minimize the adverse
impact on business operations.
Restoring normal Service Operations ensures that the
best possible levels of service quality and availability are
maintained.
28
Normal Service Operation is defined as Service Operation within Service Level

Agreement (SLA) limits.
5-35

Incident Management
Incident Management Terms

Incident Management Terms

Time Scales
Incident Modules
Major Incidents
The role of Problem Management in Incidents
29
Time Scales
Time scales must be agreed upon for all incident-handling stages. These will differ,
depending upon the priority level of the incident. Time scales will be captured as resolution
targets within Operational Level Agreements and Underpinning Contracts. All support
groups should be made fully aware of these time scales. Service management tools should
be used to automate time scales and escalate the incident as required based on predefined
rules.
Incident Modules
Many incidents are not new. They involve deal with something that has happened before
and might happen again. For this reason, many organizations find it helpful to predefine
standard incident models and apply them to appropriate incidents when they occur. An
incident model is a way of predefining the steps that should be taken to handle a process in
an agreed-upon way. Support tools can then be used to manage the required process. This
process will ensure that standard incidents are handled in a predefined path and within
predefined time scales.
5-36

Incident Management
Major Incidents
A separate procedure, with shorter time scales and greater urgency, must be used for major
incidents. A definition of what constitutes a major incident must be agreed upon. In
addition, it must be ideally mapped to the overall incident prioritization system. Then, this
type of incident will be dealt with through the major incident process.
People sometimes use loose terminology or confuse a Major Incident with a problem. In
reality an incident remains an incident forever. It might grow in impact or priority to
become a Major Incident, but an incident never becomes a problem. A problem is the
underlying cause of one or more incidents and always remains a separate entity.
When necessary, the major incident procedure should include the dynamic establishment
of a separate major incident team under the direct leadership of the Incident Manager. This
team is formulated to concentrate on this incident alone to ensure adequate resources and
focus are provided to finding a swift resolution. Sometimes the Service Desk Manager also
fulfills the role of Incident Manager (for example, in a small organization). To avoid time
or priority conflicts, a separate person might need to be designated to lead the team. That
person should ultimately report back to the Incident Manager.
The Role of Problem Management in Incidents

If the cause of the incident needs to be investigated at the same time, then the Problem
Manager will be involved as well. However, the Incident Manager must ensure that service
restoration and underlying cause are kept separate. Throughout the investigation, the
Service Desk ensures that all activities are recorded and users are kept fully informed of
progress.
5-37

Incident Management
Incident Management Process Flow
All incidents must be fully logged and stamped with date and time, regardless of their
origin. They might be raised through a Service Desk telephone call or automatically
detected through an event alert. A separate Incident Record must be logged for each
additional incident handled. This record ensures that an historical record is kept and credit
is given for the work performed. All relevant information relating to the nature of the
incident must be logged so that a full historical record is maintained. If the incident has to
be referred to other support groups, they will have all the relevant information to assist
them.
The information needed for each incident is likely to include the following items:
5-38
Unique reference number
Incident categorization (often broken down into between two and four levels of
subcategories)
Incident urgency
Incident impact
Incident prioritization

Incident Management
Date and time recorded
Name and ID of the person or group recording the incident
Method of notification (telephone, automatic, e-mail, in person, and so on)
Name, department, telephone, location of user
Callback method (telephone, mail, and so on)
Description of symptoms
Incident status (active, waiting, closed and so on)
Related Configuration Item
Support group or person to which the Incident is allocated
Related problem or known error
Activities undertaken to resolve the incident
Resolution date and time
Closure category
Closure date and time
Part of the initial logging must allocate suitable incident categorization coding so that the
exact type of the call is recorded. This code will be important later when looking at incident
types and frequencies. Therefore, trends for use in Problem Management, Supplier
Management, and other ITSM activities can be established. Multilevel categorization is
available in most tools, typically to three or four levels of granularity. For example, an
incident might be defined as one of the following categories:
Hardware
Server
Memory Board
Cell Card Failure
Software
Application
5-39

Incident Management
Incident Process Flow

Incident Process Flow

All incidents must be fully logged, date stamped, and time
stamped, regardless of whether they are raised through a
Service Desk
All relevant information relating to the nature of the
incident must be logged
A suitable incident categorization coding should record
the exact type of the call
Every incident should have an appropriate prioritization
code
31
5-40

Incident Management
Incident Management Benefits

Incident Management Benefits

Incident Management is highly visible to the business
Incident Management is often one of the first processes to
be implemented in Service Management projects
Incident Management detects and resolves incidents
results in lower downtime to the business
Incident Management identifies potential improvements to
services
32
The value of Incident Management includes:
The ability to detect and resolve incidents results in lower downtime to the
business, which in turn means higher availability of the service. The business is
then able to use the functionality of the service as designed.
The ability to align IT activity to real-time business priorities. Incident

Management includes the capability to identify business priorities and
dynamically allocate resources as necessary.
The ability to identify potential improvements to services. This ability is a result

of understanding what constitutes an Incident. In addition it comes from being in
contact with the activities of Business operational staff.
The Service Desk can, during their handling of incidents, identify additional
service or training requirements found in IT or the business.
Incident Management is highly visible to the business. It is, therefore, easier to demonstrate
the value than most areas in Service Operation. For this reason, Incident Management is
often one of the first processes to be implemented in Service Management projects. An
added benefit is that Incident Management can be used to highlight other areas that need
attention. Therefore, justification for expenditure on implementing other processes is
provided.
5-41

Incident Management
Incident Management Activities

Incident Management Activities

Incident Identification
Incident Logging
Incident Categorization
Incident Prioritization
Investigation and Diagnosis
Escalation
Resolution and Recovery
Incident Closure
33
Incident Identification
All key components should be monitored so that failures or potential failures

are detected early. Early detection ensures that Incident Management can be
started quickly.
Incidents should be resolved before they have an impact on users.
Incident Logging
All incidents must be fully logged, date stamped, and time stamped. Logging
should occur for incidents that are raised through a Service Desk call and
those automatically detected by an event alert.
Incident Categorization
Initial logging should include allocation of suitable incident categorization coding
so that the exact type of the call is recorded.
Logging the incident must include agreement and allocation of an appropriate
prioritization code.
5-42
Investigation and Diagnosis

Incident Management
Escalation
The Service Desk should keep the user informed of any relevant escalation that
takes place. It should ensure the Incident Record is updated accordingly to keep a
full history of actions.
Resolution and Recovery

The Service Desk should be able to provide some help fairly quickly and resolve
service requests for some informational requests. However, if a fault is being
reported, this is an incident and likely to require some degree of investigation and
diagnosis.
Incident Closure
The Service Desk should check that the incident is fully resolved. In addition, it
should be determined that users are satisfied and willing to agree that the incident
can be closed.
Some of these activities are discussed further in the following pages.
5-43

Incident Management
Prioritization can normally be determined by taking into
account both:
The urgency of the incident (how quickly the business
needs a resolution)
The level of impact it is causing
34
Every incident should have an appropriate prioritization code. This code will determine
how the incident is handled both by support tools and support staff.
An indication of impact is often, but not always, the number of users being affected. In
some cases, the loss of service to a single user can have a major business impact. It all
depends upon who is trying to do what. Therefore, numbers alone are not enough to
evaluate overall priority.
5-44

Incident Management
Incident Priorities
Priorities
35
Priority 1: Significant damage, must be recovered immediately

Priority 2: Limited damage, should be recovered immediately
Priority 3: Significant damage, does not need to be recovered immediately
Priority 4: Limited damage, does not need to be recovered immediately
5-45

Incident Management
Urgency, Impact, and Priority

Urgency, Impact, and Priority

Priority
The required sequence of Incident resolution
Priority = Impact x Urgency
Impact
The extent to which an incident leads to a departure from
expected service operations, such as the number of users or CIs
affected
Urgency
The required speed of resolving an Incident
36
Priority = Impact x Urgency
5-46

Incident Management
Diagnosis and Investigation

Diagnosis and Investigation

The Service Desk Operator must carry out initial
diagnosis, typically while the user is still on the telephone
If possible, the Service Desk Operator will resolve the
incident while the user is still on the telephone and close
the incident if the resolution is successful
In the case of incidents where the user is just seeking
information, the Service Desk should be able to provide it
quickly and resolve the service request
If the Service Desk cannot resolve the issue, the Service
Desk will begin functional escalation to the next level of
support
37
If the incident has been routed through the Service Desk, the Service Desk Operator must
carry out initial diagnosis. This diagnosis typically occurs while the user is still on the
telephone. If the call is raised in this way, the operator tries to discover the full symptoms
of the incident. In addition, the operator tries to determine exactly what has gone wrong and
how to correct it. It is at this stage that diagnostic scripts and known error information can
be most valuable in facilitating earlier and accurate diagnosis.
If possible, the Service Desk Operator will resolve the incident while the user is still on the
telephone. In addition, the operator will close the incident if the resolution is successful.
Sometimes the Service Desk Operator cannot resolve the incident while the user is still on
the telephone. However, there is a prospect that the Service Desk might be able to resolve
it within the agreed-upon time limit without assistance from other support groups. In this
case, they should inform the user of their intentions, give the user the incident reference
number, and attempt to find a resolution.
In some incidents the user is just seeking information. In this case, the Service Desk should
be able to provide the information fairly quickly and resolve the service request. However,
if a fault is being reported, it is an incident and likely to require some degree of investigation
and diagnosis.
Each of the support groups involved with the incident handling will investigate and
diagnose what has gone wrong. All such activities (including details of any actions taken
to try and resolve or re-create the incident) should be fully documented in the incident
5-47

Incident Management
record. This documentation ensures that a complete historical record of all activities is
maintained at all times.
Valuable time can often be lost if investigative and diagnostic action (or indeed resolution
or recovery actions) are performed serially. Where possible, such activities should be
performed in parallel to reduce overall time scales, and support tools should be designed
and selected to permit this parallel action. However, care should be taken to coordinate
activities, particularly resolution or recovery activities. Otherwise, the actions of different
groups might conflict or further complicate a resolution.
5-48

Incident Management
Incident Escalation
Incident Escalation
Functional Escalation
Hierarchical Escalation
38
Functional Escalation
Sometimes it becomes clear that the Service Desk cannot resolve the incident themselves.
In addition, sometimes the target times for first point resolution have been exceeded. In
either case, the incident must be immediately escalated for further support. If the
organization has a second-level support group, the Service Desk should refer the incident
to them. However, sometimes it is obvious that the incident will need deeper technical
knowledge. Also, there are times when the second-level group has not been able to resolve
the incident within agreed-upon target times. In either of these cases, the incident must be
immediately escalated to the appropriate third-level support group.
Note: Third-level support groups might be internal, but they might also be third parties such
as software suppliers or hardware manufacturers.
The rules for escalation and handling of incidents must be agreed upon in Operational Level
Agreements (OLAs) and Underpinning Contracts (UCs). Rules must exist for internal and
external support groups.
5-49

Incident Management
Hierarchic Escalation
If incidents are of a serious nature (for example, priority 1 incidents), the appropriate IT
managers must be notified, for informational purposes at least. Hierarchic escalation is also
used if the Investigation and Diagnosis or Resolution and Recovery steps are taking too
long. They are also used if the steps are proving to be too difficult. Hierarchic escalation
should continue up the management chain so that senior managers are aware, can be
prepared, and take any necessary action, such as allocating additional resources or
involving suppliers. Hierarchic escalation is also used when there is contention about to
whom the Incident is allocated. Hierarchic escalation can be initiated by the affected users
or customer management as they see fit. Therefore, it is important to make IT managers
aware so that they can anticipate and prepare for any such escalation.
The exact levels and time scales for both functional and hierarchic escalation need to:
Be agreed upon
Take into account Service Level Agreement targets
Be embedded within support tools
The tools can then be used to police and control the process flow within agreed-upon time
scales.
The Service Desk should keep the user informed of any relevant escalation that takes place.
In addition, the service desk should ensure the incident record is updated accordingly. This
record will keep a full history of actions.
5-50

Incident Management
Incident Resolution, Recovery, and Closure

Incident Resolution, Recovery, and Closure

Even when a resolution has been found, sufficient testing
must be performed to ensure that recovery action is
complete and that the service has been fully restored to
the users
The incident record must be updated accordingly with all
relevant information and details so that a full history is
maintained
The resolving group should return the incident to the
Service Desk for closure action
It might make sense, for example, to agree that if the
incident recurs within one working day, it can be reopened. After one working day, a new incident must be
raised, but linked to the previous incidents
39
When a potential resolution has been identified this should be applied and tested. The
specific recovery actions and the people who will be involved them might vary, depending
upon the nature of the fault.
In some cases it might be necessary for two or more groups to take separate, though perhaps
coordinated, recovery actions for a resolution. In such cases, Incident Management must
coordinate the activities and interact with all parties involved.
Regardless of the actions taken, or who does them, the incident record must be updated
accordingly. The update should include all relevant information and details. This update
ensures that a full history is maintained. The resolving group should pass the incident back
to the Service Desk for closure action.
The Service Desk should check that the incident is fully resolved. In addition it should
check that the users are satisfied and willing to agree that the incident can be closed.
Some organizations might use an automatic closure period on specific, or even all,
incidents. For example, the incident will be automatically closed after two working days if
no further contact is made by the user. When this approach is considered, it must first be
fully discussed and agreed upon with the users. It also needs to be widely publicized so that
all users and IT staff are aware of the method. It might be inappropriate to use this method
for certain types of incidents, such as Major Incident or those involving VIPs. Despite all
adequate care, sometimes incidents recur, even though they have been formally closed.
Because of such cases, it is wise to have predefined rules regarding if and when an incident
5-51

Incident Management
can be re-opened. It might make sense, for example, to agree that if the incident recurs
within one working day then it can be reopened. However, beyond this point a new incident
must be raised, but it should be linked to the previous incidents.
5-52

Incident Management
Incident Management Interfaces

Incident Management Interfaces

Problem Management
Change Management
Capacity Management
Service Level Management (SLM)
40
Problem Management: Incident Management forms part of the overall process of dealing
with problems in the organization. Incidents are often caused by underlying problems,
which must be solved to prevent the incident from recurring. Incident Management
provides a point where incidents are reported.
Configuration Management: This role provides the data used to identify and track the
progress of solving incidents. Uses of the Configuration Management System (CMS)
include:
Identifying faulty equipment
Assessing the impact of an incident
Identifying the users affected by potential problems
The CMS contains information about which categories of incident should be assigned to
which support group. In turn, Incident Management can maintain the status of faulty CIs.
It can also assist Configuration Management to audit the infrastructure when working to
resolve an incident.
Change Management: Where a change is required to implement a workaround or
resolution, the change needs to be logged as a Request for Change (RFC). It is then sent
through Change Management. In turn, Incident Management is able to detect and resolve
incidents that arise from failed changes.
5-53

Incident Management
Capacity Management: Incident Management provides a trigger for performance

monitoring where there seems to be a performance problem. Capacity Management might
develop workarounds for incidents.
Availability Management: Availability Management will use Incident Management data
to determine the availability of IT services and look at where the incident lifecycle can be
improved.
Service Level Management (SLM): The ability to resolve incidents in a specified time is
a key part of delivering an agreed-upon level of service. Incident Management enables
SLM to define measurable responses to service disruptions. It also provides reports that
help SLM to review SLAs objectively and regularly. In particular, Incident Management is
able to assist in defining where services are at their weakest. Therefore, SLM can define
actions as part of the Service Improvement Program (SIP). (See the Continual Service
Improvement book for more details). SLM defines the acceptable levels of service within
which Incident Management works, including:
5-54
Incident response times
Impact definitions
Target fix times
Service definitions, which are mapped to users
Rules for requesting services
Expectations for providing feedback to users

Incident Management
Incident Management Inputs

Incident Management Inputs

Incident Management Tools
Incident Records
41
Most information used in Incident Management comes from the following sources:
The Incident Management tools, which contain information about:
Incident and problem history
Incident categories
Action taken to resolve incidents
Diagnostic scripts
Incident Records, which include the following data:
Unique reference number
Incident classification
Date and time of recording and any subsequent activities
Name and identity of the person recording and updating the Incident Record
Name, organization, and contact details of affected users
Description of the incident symptoms
5-55

Incident Management
5-56
Details of any actions taken to try to diagnose, resolve, or re-create the

incident
Incident category, impact, urgency, and priority
Relationship with other incidents, problems, changes or Known Errors
Closure details

Incident Management
Incident Management Key Performance

Indicators
Incident Management Key Performance Indicators

Total numbers of Incidents (as a control measure)
Number and percentage of major incidents
Mean elapsed time to achieve incident resolution or circumvention,
broken down by impact code
Percentage of incidents handled within agreed-upon response time
(Incident response-time targets may be specified in SLAs, for
example, by impact and urgency codes)
Number of incidents reopened and as a percentage of the total
Percentage of incidents closed by the Service Desk without reference
to other levels of support (often referred to as first point of contact)
42
The metrics that should be monitored and reported upon to judge the efficiency and
effectiveness of the Incident Management process, and its operation, will include:
Total numbers of Incidents (as a control measure)
Breakdown of incidents at each stage (for example logged, WIP, or closed)
Size of current incident backlog
Number and percentage of major incidents
Mean elapsed time to achieve Incident resolution or circumvention, broken down

by impact code
Percentage of Incidents handled within agreed response time (incident responsetime targets might be specified in SLAs, for example, by impact and urgency
codes)
Average cost per incident
Number of incidents reopened and as a percentage of the total
Number and percentage of incidents incorrectly assigned
5-57

Incident Management
Number and percentage of incidents incorrectly categorized
Percentage of Incidents closed by the Service Desk without reference to other

levels of support (often referred to as first point of contact)
Number and percentage of Incidents processed per Service Desk agent
Number and percentage of Incidents resolved remotely, without the need for a
visit
Number of incidents handled by each Incident Model
Break-down of incidents by time of day, to help pinpoint peaks and ensure

matching of resources
Reports should be produced under the authority of the Incident Manager. This person
should draw up a schedule and distribution list. These actions should be done in
collaboration with the Service Desk and support groups handling incidents. Distribution
lists should at least include IT services management and specialist support groups.
Consider also making the data available to users and customers, for example, through SLA
reports.
5-58

Incident Management
Incident Management Challenges, Success

Factors, and Risks
Incident Management Challenges

Detecting incidents as early as possible
Convincing all staff (technical teams as well as users) that
all incidents must be logged
Encouraging the use of self-help Web-based capabilities
(which can speed up assistance and reduce resource
requirements)
Availability of information about problems and known
errors
Integration into the Configuration Management System
Integration into the Service Level Management process
43
Critical Success Factors of Incident Management include:
A quality Service Desk.
Clearly defined targets from SLAs.
Skilled and customer oriented support staff at all stages of the process.
Integrated support tools to drive and control the process.
Well defined agreements that influence and shape the correct behavior of all
support staff.
Risks to successful Incident Management include:
Improperly trained or unavailable resources.
Inadequate support tools to raise alerts and prompt progress.
Inadequate tools or lack of integration.
Poorly aligned or non-existent OLAs or underpinning contracts.
5-59

Incident Management
Incident Manager
Incident Manager
Driving the efficiency and effectiveness of the Incident Management
process
Producing management information
Managing the work of incident support staff (first line and second line)
Monitoring the effectiveness of Incident Management and making
recommendations for improvement
Developing and maintaining the Incident Management systems
Managing major incidents
Developing and maintaining the Incident Management process and
procedures
44
The main role of Incident Management is that of the Incident Manager. In many
organizations the role of Incident Manager is assigned to the Service Desk supervisor. In
larger organizations with high volumes, a separate role might be necessary. In both cases,
it is important to give the Incident Manager the authority to manage incidents effectively
through the first, second, and third lines.
5-60

Process of Request Fulfillment
Lesson 4: Process of Request Fulfillment
Lesson 4: Process of Request Fulfillment
5-61

Request Fulfillment
Request Fulfillment
Request Fulfillment is the process of dealing with Service
Requests from the users
Service Requests are a generic description for varying
types of demands that are placed upon the IT department
by the users
The scale and frequent, low-risk nature of Service
Requests mean that they are better handled by a process
separate from Change Management or Incident
Management
46
The term Service Request is used as a generic description for varying types of demands that
are placed upon the IT department by the users. Many of these demands are actually small
changes that are low risk, frequently occurring, and low cost. Examples of these changes
are:
A request to install an additional software application onto a particular

workstation
a question requesting information.
Their scale and frequent, low-risk nature means that they are better handled by a separate
process. Otherwise, they might congest and obstruct the normal incident and change
management processes.
Request Fulfillment is the processes of dealing with service requests from the users. The
objectives of Request Fulfillment process include:
5-62
To provide a channel for users to request and receive standard services for which a
predefined approval and qualification process exists

To provide information to users and customers about the availability of services

and the procedure for obtaining them
To source and deliver the components of requested standard services (for

example, licenses and software media)
To assist with general information, complaints, or comments
The value of Request Fulfillment is to provide quick and effective access to standard
services. Business staff can use these services to improve their productivity or the quality
of business services and products.
Request Fulfillment effectively reduces the bureaucracy involved in requesting and
receiving access to existing or new services. Therefore, it also reducing the cost of
providing these services. Centralizing fulfillment also increases the level of control over
these services. This in turn can help reduce costs through centralized negotiation with
suppliers, and can also help to reduce the cost of support.
5-63

Service Request Examples

Service Request Examples

Service Requests are typically small changes that are low
risk, frequently occurring, and low cost
Examples:
A request to install an additional software application
onto a particular workstation
47
5-64

Request Fulfillment Objectives

Request Fulfillment Objectives

To provide a channel for users to request and receive
standard services for which a predefined approval and
qualification process exists
To provide information to users and customers about the
availability of services and the procedure for obtaining
them
To source and deliver the components of requested
standard services (for example, licenses and software
media)
To assist with general information, complaints, or
comments
48
5-65

Request Fulfillment Benefits

Request Fulfillment Benefits

Provides quick and effective access to standard services.
Business staff can use this access to improve their
productivity or the quality of business services and
products.
Effectively reduces the bureaucracy involved in
requesting and receiving access to existing or new
services.
Reduces the cost of providing these services.
Centralizing fulfillment increases the level of control over
these services. This control can reduce costs through
centralized negotiation with suppliers and can also reduce
the cost of support.
49
5-66

Request Fulfillment Activities

Request Fulfillment Activities

Menu Selection
Financial Approval
Other Approval
Fulfillment
50
The Request Fulfillment process has the following activities:
Menu Selection:
Users should be offered a menu type selection using a web interface to select and
input details of Service Requests from a pre-defined list. Then, appropriate
expectations can be set by giving target delivery or implementation target dates.
Financial Approval:
The cost of fulfilling the request must first be established.
Other Approval:
In some cases, further approval might be needed.
Fulfillment:
Some simpler requests might be completed by the Service Desk. Others might
have to be forwarded to specialist groups or suppliers for fulfillment
5-67

Request Fulfillment Interfaces

Request Fulfillment Interfaces

Service Desk and Incident Management
Release Management
51
5-68

Request Fulfillment Inputs

Request Fulfillment Inputs

Service Requests
Requests for Change
The Service Portfolio
Security Policies
52
The Request Fulfillment process requires input from the following sources:
Service Requests for information about:
The service is being requested and when it was requested
The requestor and authorizer of the service
The process that will be used to fulfil the request
The person assigned the request
The action that was taken and when it was taken
The date and time when the request was logged as well as the date and time of
all actions taken
Closure details
Requests for Change when the Request Fulfillment process is initiated by an RFC
5-69

5-70
The Service Portfolio which will identify the scope of the agreed Service Request
to be identified
Security Policies will prescribe any controls to be executed or adhered to when

providing the service

Request Fulfillment KPIs

Request Fulfillment KPIs

Total number of Service Requests
Breakdown of service requests at each stage
Size of current backlog of outstanding Service Requests
Mean elapsed time for handling each type of Service
Request
Number and percentage of Service Requests completed
within agreed target times
Average cost per type of Service Request
Level of client satisfaction with the handling of Service
Requests
53
5-71

Request Fulfillment Challenges, Critical

Success Factors, and Risks
Request Fulfillment Challenges

Clearly defining and documenting the type of requests
that will be handled within the Request Fulfillment
process
Clearly defining and documenting the type of requests
that will either go through the Service Desk and those that
will need to go through formal Change Management
Establishing self-help front-end capabilities that allow the
users to interface successfully with the Request
Fulfillment process
54
Request Fulfillment has the following critical success factors:
Agreement about the services that will be standardized, the authorization process,
and the cost
Publication of the services to users as part of the Service Catalog
Definition of a standard fulfillment procedure for each of the services being

requested
Identification of a single point of contact which can be used to request the service
Provision of the self-service tools to provide a front-end interface to the users
Request Fulfillment can encounter the following risks:
5-72
Poorly defined scope, where people are unclear about exactly what the process is
expected to handle
Poorly designed or implemented user interfaces so that users have difficulty

raising the requests that they need

Badly designed or operated back-end fulfillment processes that can't handle the
requests being made
Inadequate monitoring capabilities so that accurate metrics cannot be gathered
5-73

Request Fulfillment Roles

Request Fulfillment Roles

Service Desk and Incident Management staff initially
handle Service Requests.
Eventual fulfillment will be undertaken by the appropriate
Service Operation teams or departments or by external
suppliers.
Often, Facilities Management, Procurement, and other
business areas aid in the fulfillment of the Service
Request.
In most cases there will be no need for additional roles to
be created.
55
5-74

Process of Problem Management
Lesson 5: Process of Problem Management
Lesson 5: Process of Problem

Management
5-75

Problem Management
Problem Management
A problem is the unknown cause of one or more incidents
Problem Management includes the activities required to
diagnose the root cause of incidents and to determine the
resolution to those problems
Problem Management will also maintain information about
problems and the appropriate workarounds and resolutions
Problem Management works together with Incident
Management and Change Management to ensure that IT
service availability and quality is increased
57
ITIL defines a problem as the unknown cause of one or more incidents.

Problem Management is the process responsible for managing the lifecycle of all problems.
Problem Management prevents problems and resulting incidents from happening,
eliminates recurring incidents, and minimizes the impact of incidents that cannot be
prevented.
Problem Management includes the activities required to diagnose the root cause of
incidents and to determine the resolution to those problems. It is also responsible for
ensuring that the resolution is implemented through the appropriate control procedures,
especially Change Management and Release Management.
Problem Management will also maintain information about problems and the appropriate
workarounds and resolutions. Then the organization can reduce the number and impact of
incidents over time. In this respect Problem Management has a strong interface with
Knowledge Management. Tools such as the Known Error Database will be used for both.
Although Incident Management and Problem Management are separate processes, they are
closely related. In addition, they will typically use the same tools. Furthermore, they might
also use similar categorization, impact, and priority coding systems. This similarity will
ensure effective communication when dealing with related incidents and problems.
5-76

Problem Management works with Incident Management and Change Management to

ensure that IT service availability and quality is increased. When incidents are resolved,
information about the resolution is recorded. Over time, this information is used to shorten
the resolution time and identify permanent solutions, reducing the number of incidents and
their resolution time. The result is less downtime and less disruption to business critical
systems.
5-77

Problem Management Concepts

Problem Management Concepts

Reactive Problem Management, which is generally
implemented as part of Service Operation
Proactive Problem Management, which is initiated in
Service Operation but generally driven as part of
Known Error Database allows storage of previous
knowledge of incidents and problems, and how they were
overcome, to allow quicker diagnosis and resolution if
they recur
58
Problem Management consists of two major processes:
Reactive Problem Management, which is generally performed as part of Service

Operation
Proactive Problem Management, which is initiated in Service Operation, but

generally operates as part of Continual Service Improvement
Creating a Known Error Record in the Known Error Database ensures quicker diagnosis.
In addition, the creation of a Problem Model for handling such problems in the future might
be helpful. This concept is similar to the idea of Incident Models, but applied to problems
and incidents.
The Known Error record should hold exact details of the fault and the symptoms that
occurred. It should also contain precise details of any workaround or resolution that can
restore the service and resolve the problem. An incident count will also be useful to
determine the frequency with which incidents are likely to recur and influence priorities.
Care should be taken to avoid duplication of records, the same problem described in two or
more ways as separate records. To avoid repetition, the Problem Manager should be the
only person able to enter a new record. Other support groups should be permitted, indeed
encouraged, to propose new records. However, these should be examined by the Problem
Manager before entry to the KEDB.
5-78

The KEDB should be used during the incident and problem diagnosis phases to speed up
the resolution process. New records should be added as quickly as possible when a new
problem has been identified and diagnosed. All support staff should be fully trained and
know the value that the KEDB can offer and the way it should be used. They should be able
to readily retrieve and use data.
5-79

Workaround
Workaround
A workaround is a temporary way of overcoming a
difficulty
When a workaround is found, it is therefore important that
the:
Problem record remains open
Details of the workaround are documented within the problem
record
59
In some cases it might be possible to find a workaround to the incidents caused by the
problem.
An example of a workaround would be:
A manual amendment is made to an input file to permit a program to complete the
run successfully. In addition, it ensures the billing process completes
satisfactorily. However, it is important that work on a permanent resolution
continues when justified. In this example, the reason why the file became
corrupted in the first place must be found and corrected to prevent this situation
from happening again.
5-80

Known Error Data Base (KEDB)

Known Error Data Base (KEDB)

The purpose of a Known Error Data Base (KEDB) is to
Store previous knowledge of incidents and problems
Record how incidents and problems were overcome
Diagnose and resolve recurring incidents or problems
quicker
The known error record should hold precise details of the
following items:
The fault and the symptoms that occurred
Any workaround or resolution action that can be taken
to restore the service or resolve the problem
An incident count is also useful
60
A Known Error is a problem for which a cause has been identified.

A Known Error Record in the Known Error Database ensures quicker diagnosis. In
addition, the creation of a Problem Model for handling such problems in the future can be
helpful. Problem Models are similar in concept to the idea of Incident Models, but they can
be applied to problems and incidents.
As soon as the diagnosis is complete, a known error record must be raised and placed in the
Known Error Database. An immediate record is particularly important when a workaround
has not been found. Even a temporary workaround, one that is not yet a permanent
resolution, has value in restoring service. When a record exists, future similar incidents or
problems can be identified and the service restored more quickly.
In some cases you might want to create a known error record even earlier in the overall
process. Even if just for informational purposes, the diagnosis might not be complete, or a
workaround implemented, it can still be useful.
It is not advisable to try to set a specific procedural point exactly when a known error record
must be raised. The point should be set as soon as it becomes useful.
The incident count can be used to determine the frequency with which incidents are likely
to recur and, therefore, influence priorities.
5-81

Reactive versus Proactive Problem

Management
Problem Management consists of two major processes:
Reactive Problem Management, which is generally performed as part of Service

Operation
Proactive Problem Management, which is initiated in Service Operation, but

generally operates as part of Continual Service Improvement
Notice how the Reactive side of the illustration tends to be solving current problems.
Toward the right on the continuum, the Proactive approach to problem management has
more management and strategies to avoid problems.
5-82

Problem Management Process
This chart shows the Problem Management process flow. Though there can be variations
depending on the problems, most problems will be managed through a similar flow process.
5-83

Problem Management Objectives

Problem Management Objectives

Prevent problems and resulting incidents from happening
Eliminate recurring incidents
Minimize the impact of incidents that cannot be prevented
63
5-84

Problem Management Benefits

Problem Management Benefits

Problem Management works with Incident Management
and Change Management to ensure that IT service
availability and quality are increased.
When incidents are resolved, information about the
resolution is recorded.
64
Some other benefits of Problem Management are:
Higher availability of IT services
Higher productivity of business and IT staff
Reduced expenditure on workarounds or fixes that do not work
Reduction in cost of effort in fire-fighting or resolving repeat incidents
5-85

Problem Management Activities

Problem Management Activities

Problem Detection
Problem Logging
Problem Categorization
Problem Prioritization
Problem Investigation and Diagnosis
Workaround Identification
Known Error Record Introduction
Problem Resolution
Problem Closure
Major Problem Review
Development Environment Error Detection and Logging
65
The activities of the Problem Management process are:
5-86
Problem Detection: There are frequently a variety of ways to detect problems.

Frequent and regular analysis of problem data must be performed to identify any
trends.
Problem Logging: Regardless of the detection method, all the relevant details of
the problem must be recorded so that a full historic record exists. This must be
date and time stamped to allow suitable control and escalation.
Problem Categorization: Problems must be categorized in the same way as

incidents
Problem Prioritization: Problems must be prioritized in the same way as

incidents, but the frequency and impact of related incidents must also be taken
into account
Problem Investigation and Diagnosis: An investigation should be conducted to

try to diagnose the root cause of the problem
Workaround Identification: In some cases it might be possible to find a

workaround to the incidents caused by the problem

Known Error Record Introduction: As Known Error Record must be

introduced and placed in the Known Error Database so that if further incidents or
problems arise, they can be easily identified and corrected
Problem Resolution: Ideally, as soon as a solution has been found, it should be

applied to resolve the problem
Problem Closure: When any change has been completed and reviewed, and the
resolution has been applied, the Problem Record should be formally closed
Major Problem Review: After every major problem, while memories are still
fresh, a review should be conducted to learn any lessons for the future
Development Environment Error Detection and Logging: When something is

released into the production environment that includes known deficiencies, they
should be logged as Known Errors in the KEDB
5-87

Problem Management Interfaces

Problem Management Interfaces

Change Management
Capacity Management: Some problems require investigation b y
Capacity Management teams and techniques, for example,
performance issues. It also assists in assessing proactive measures.
Problem Management provides management information relative to
the quality of decisions made during the Capacity Planning process
IT Service Continuity
66
Problem Management interfaces with the following groups:
5-88
Change Management: Problem Management ensures that all resolutions or

workarounds that require a change to a CI are submitted through Change
Management through an RFC. Change Management will monitor the progress of
these changes and keep Problem Management advised. Problem Management is
also involved in rectifying the situation caused by failed changes.
Configuration Management: Problem Management uses the CMS to identify

faulty CIs and also to determine the impact of problems and resolutions. The CMS
can also be used to form the basis for the KEDB and hold or integrate with the
problem records.
Release and Deployment Management: This area is responsible for

implementing problem fixes out into the live, or production, environment. It also
assists in ensuring that the associated known errors are transferred from the
development Known Error Database into the live, or active, Known Error
Database. Problem Management will assist in resolving problems caused by faults
during the release process.
Availability Management: This area is involved with determining how to reduce

downtime and increase uptime. As such it has a close relationship with Problem
Management, especially the proactive areas. Much of the management

information available in Problem Management will be communicated to

Availability Management.
Capacity Management: Some problems will require investigation by Capacity

Management teams and techniques, such as performance issues. Capacity
Management will also assist in assessing proactive measures. Problem
Management provides management information relative to the quality of
decisions made during the Capacity Planning process.
IT Service Continuity: Problem Management acts as an entry point into IT

Service Continuity Management. It occurs when a significant problem is not
resolved before it starts to have a major impact on the business.
Service Level Management: The occurrence of incidents and problems affects

the level of service delivery measured by Service Level Management. Problem
Management contributes to improvements in service levels, and their
management information is used as the basis of some of the SLA review
components. Service Level Management also provides parameters within which
Problem Management works. Parameters can include impact information and the
effect on services of proposed resolutions and proactive measures.
Financial Management: This area assists in assessing the impact of proposed

resolutions or workarounds, and pain value analysis. Problem Management
provides management information about the cost of resolving and preventing
problems. This information is used as input into the budgeting and accounting
systems and Total Cost of Ownership calculations.
5-89

Problem Management KPIs

Problem Management KPIs

The total number of problems recorded in the period
The percentage of problems resolved within SLA targets
The percentage of problems not resolved within SLA targets
The number and percentage of problems that exceeded their target
resolution times
The backlog of outstanding problems and the trend
The average cost of handling a problem
The number of major problems
The percentage of Major Problem Reviews successfully performed
The number of Known Errors added to the KEDB
The percentage accuracy of the KEDB (from audits of the database)
67
5-90

Problem Management Critical Success

Factors
Problem Management Critical Success Factors

Linking Incident and Problem Management tools
Relating Incident and Problem Records
Ensuring an effective working relationship between all the staff lines
Making sure that business impact is well understood by all staff
working on problem resolution
Using all Knowledge and Configuration Management resources
available
Ongoing training of technical staff in technical aspects of their job
Ongoing training of technical staff in business implications of the
services they support and the processes they use
68
5-91

Problem Manager
Problem Manager
Smaller organizations might not be able to justify a fulltime employee for this role.
It can be combined with other roles in such cases.
The role of Problem Management must not be left only to
technical staff.
A single point of coordination and an owner of the
Problem Management process is essential.
69
This role will coordinate all problem management activities and will have specific
responsibility for the following duties:
5-92
Works with all problem resolution groups to ensure swift resolution of problems
within SLA targets.
Owns the Known Error Database. Acts as the gatekeeper for the inclusion of all
Known Errors and management of search algorithms.
Formally closes all problem records.
Works with suppliers and contractors to ensure that external vendors fulfill their
contractual obligations to resolve problems.
Manages and documents all follow up activities relating to major problem

reviews.

Process of Access Management
Lesson 6: Process of Access Management
Lesson 6: Process of Access

Management
5-93

Access Management
Access Management
Access Management is the process of controlling which
users can and cannot use a service
Some organizations refer to it as Rights Management or
Identity Management
Access Management is the process that helps users use
the services that are documented in the Service Catalog.
71
The Access Management process and the related policies are likely to be defined and
maintained by Information Security Management. It is completed by the various Service
Operation functions.
5-94

Access Management Concepts

Access Management Concepts

Access
Identity
Rights or privileges
Services or service groups
Directory Services
72
Access: The level and extent of a services operation or data that a user is entitled to use.
Identity: The information about a user that distinguishes that person as a unique individual
and which verifies their status within the organization.
Rights or privileges: The actual settings whereby a user is provided access to a service or
group of services. Typical rights, or levels of access, include read, write, execute, change,
delete.
Services or service groups: It is not effective to provide access to each service for each
user separately. It is more efficient to grant each user, or group of users, access to a set of
services at the same time.
Directory Services: A specific type of tool that is used to manage access and rights.
5-95

Access Management Goals

Access Management Goals

Grant the right to users to be able to use a service or
group of services.
Execute policies and actions defined in Security and
Availability Management.
Help the organization to manage the confidentiality,
availability and integrity of the organizations data and
intellectual property.
Provide a user with access to a service
Ensure that the service is available at the agreed upon
times.
73
5-96

Access Management Benefits

Access Management Benefits

Leads to more effective control of confidentiality of
information
Gives employees the level of access necessary to
complete their jobs
Protects against unskilled users making errors in data
entry or in the use of a critical service
Gives the ability to audit service use and trace the abuse
Grants the ability to revoke access rights when needed
Enables organization to comply with regulations (for
example: SOX, HIPAA, COBIT)
74
5-97

Access Management Activities

Access Management Activities

Requesting Access
Verifying Access
Providing Rights
Monitoring Identity Status
Removing or Restricting Rights
75
The process of Access Management includes the following activities:

Requesting Access: Access (or restriction) can be requested using one of any number of
mechanisms, including:
A standard request generated by the Human Resource system
A Request for Change
A Service Request submitted through the Request Fulfillment system
The execution of a pre-authorized script or option
Verifying Access: Access Management needs to verify every request for access to an IT
service from two perspectives:
That the user requesting access is who they say they are
That they have a legitimate requirement for that service
Providing Rights: Access Management does make IT service access decisions, but
executes the policies and regulations defined during Service Strategy and Service Design
5-98

Monitoring Identity Status: As users work in the organization, their roles change and so
also do their needs to access services. Examples of changes include:
Job changes
Promotions or demotions
Transfers
Resignation or death
Retirement
Disciplinary action
Dismissals
Removing or Restricting Rights: Access Management will execute the decisions and
policies made during Service Strategy and Design and also decisions made by managers in
the organization
5-99

Access Management Interfaces

Access Management Interfaces

Human Resource
Information Security Management
Change Management
76
Access Management is triggered by a request for a user or users to access a service or group
of services. This could originate from any of the following:
An RFC
A Service Request
A request from the appropriate Human Resources Management personnel
A request from the manager of a department
Access Management should be linked to the Human Resource processes to verify the
identity of the users. In addition, this interface can ensure that they are entitled to the
services being requested.
Information Security Management is a key driver for Access Management as it will provide
the security and data protection policies and tools needed to execute Access Management.
Change Management plays an important role as the means to control the actual requests for
access. This is because any request for access to a service is a change, although it is usually
processed as a Standard Change or Service Request. SLM maintains the agreements for
access to each service including:
5-100
The criteria for who is entitled to access each service

The cost of the access
The level of access that will be will be granted to different types of user
There is also a strong relationship between Access Management and Configuration

Management. The CMS can be used for data storage and interrogated to determine current
access details.
5-101

Access Management KPIs

Access Management KPIs

Number of requests for access
Instances of access granted, by service, user, and
department
Instances of access granted by department or individual
granting rights
Number of incidents requiring a reset of access rights
Number of incidents caused by incorrect access settings
77
5-102

Access Management Critical Success Factors

Access Management Critical Success Factors

The ability to verify the identity of a user
The ability to verify the identity of the approving person or body
The ability to verify that a user qualifies for access to a specific
service
The ability to link multiple access rights to an individual user
The ability to determine the status of the user at any time
The ability to manage changes to a users access requirements
The ability to restrict access rights to unauthorized users
The use of a database of all users and the rights that they have been
granted
78
5-103

Access Management Roles

Access Management Roles

Since Access Management is an execution of Security
and Availability Management, these two areas will be
responsible for defining the appropriate roles.
It is unusual for an organization to appoint an Access
Manager.
It is important that there is a single Access Management
process and a single set of policies related to managing
rights and access.
This process and the related policies are likely to be
defined and maintained by Information Security
Management. They will probably be executed by the
various Service Operation functions.
79
5-104

The Service Desk Function
Lesson 7: The Service Desk Function
Lesson 7: The Service Desk Function
5-105

Service Desk
Service Desk
A Service Desk deals with a variety of service events,
often made through telephone calls, Web interface, or
automatically reported infrastructure events
The nature, type, size, and location of a Service Desk will
vary, depending upon the type of business, number of
users, geography, complexity of calls, scope of services,
and many other factors
81
A Service Desk is a functional unit made up of a dedicated number of staff responsible for
dealing with a variety of service events. These events are often made through telephone
calls, Web interface, or automatically reported infrastructure events. The Service Desk is a
vitally important part of the IT Department of an organization. The Service Desk should be
the single point of contact for IT users on a day-to-day basis. The Service Desk will handle
all incidents and service requests, typically using specialist software tools to log and
manage all such events.
A good Service Desk can often compensate for deficiencies elsewhere in the IT
organization. However, a poor Service Desk, or the lack of one, can give a poor impression
of an IT organization.
Providing the correct caliber of staff for the Service Desk is important. To improve staff
retention, IT managers should do their best to make the desk an attractive place to work.
The exact nature, type, size, and location of a Service Desk will vary, depending upon the
many factors, including those listed:
5-106
Type of business
Number of users
Geography

Complexity of calls
Scope of services
5-107

Service Desk Responsibilities

Service Desk Responsibilities

Logging all relevant incidents and service requests
Assigning categorization and prioritization codes
Providing first-line investigation and diagnosis
Escalating incidents and service requests that they
cannot resolve within agreed upon time scales
Keeping users informed of progress
82
The primary aim of the Service Desk is to restore normal service to the users as quickly as
possible. In this context, restore normal service is meant in the widest possible sense. For
example, restoration can involve fixing a technical fault, fulfilling a service request, or
answering a query. The phrase means to do anything that is needed to ensure the users to
satisfactorily return to work.
Specific responsibilities will include:
5-108
Logging all relevant incident and service request details, allocating categorization
and prioritization codes
Providing first-line investigation and diagnosis
Resolving all the incidents and service requests that they can
Escalating incidents and service requests that they cannot resolve within the
agreed-upon time scales
Keeping users informed of progress
Closing all resolved incidents, requests, and other calls
Conducting customer and user satisfaction callbacks and surveys as agreed upon
Communicating with users and keeping them informed of incident progress,

notifying them of impending changes or agreed-upon outages


83
The main function of the Service Desk is to restore the normal service to the users as
quickly as possible. Restoring to normal service can include repairing a technical fault, or
fulfilling a service request, or answering a query. It involves whatever is needed to help the
users to return to an agreed-upon level of work.
5-109

Service Desk Organizational Structures


Local Service Desk
Centralized Service Desk
Virtual Service Desk
Follow-the-Sun Service Desk
84
Local Service Desk

A Local Service Desk is where a desk is collocated within, or physically close to the user
community it serves. Physical proximity often aids communication and gives a clearly
visible presence, which some users like. However, Local Service Desks can often be
inefficient and expensive. Staff wait to deal with incidents, and the volume and arrival rate
of calls might not justify the staff dedicated to this function.
Centralized Service Desk

It is possible to reduce the number of Local Service Desks by merging them into a single
location or into a smaller number of locations. This merging is done by drawing the staff
into one or more centralized Service Desk structures. This practice can be more efficient
and cost effective:
5-110
Fewer overall staff members deal with a higher volume of calls.
Staff can develop higher skill levels. More frequent occurrence of events provides
greater familiarization with their resolution.

It might still be necessary to maintain some form of local presence to handle physical
support requirements. However, such staff can be managed and deployed from the central
desk.
Virtual Service Desk

Often, personnel might be located in a number of geographical or structural locations.
However, it is possible in these situations to give the impression of a single, centralized
Service Desk. Technology, particularly the Internet, and corporate support tools can help
build this illusion. These technologies and tools permit the following practices to meet user
demand:
Telecommuting from home
Secondary support group
Off-shoring
Outsourcing
Any combination of the previous items.
Note: Safeguards are needed in all of these circumstances to ensure consistency and
uniformity in service quality and cultural terms.
Follow-the-Sun Service Desk

Some global or international organizations might want to combine two or more of their
geographically dispersed service desks to provide a 24-hour follow-the-sun service desk.
For example, a Service Desk in the Asia-Pacific region can handle calls during standard
office hours. At the end of this period, they can transfer responsibility for any open
incidents to a European-based desk. That desk handles these calls and their own incidents
during the European business day. Then the European desk transfers its open incidents to a
U.S.-based desk, which in turn transfers responsibility back to the Asia-Pacific desk to
complete the cycle.
5-111

This image illustrates types of Service Desks and covers Local, Centralized, and Virtual
applications of the Service Desk.
Local Service Desk: Service desk is co-located within or physically close to the user
community it serves. This location often aids communication and gives a clearly visible
presence. Some users like this approach. However, it can often be inefficient and expensive
to resource. Staff are tied up waiting to deal with incidents when the volume, and arrival
rate of calls might not be justified.
Centralized Service Desk: Service desks are merged into a single location or into a smaller
number of locations. This merging is done by drawing the staff into one or more centralized
Service Desk structures. This setup can be more efficient and cost-effective. It leads to
fewer overall staff to deal with a higher volume of calls. It can also lead to higher skill levels
through great familiarization because of more frequent occurrence of events.
Virtual Service Desk: Virtual Service Desk uses technology, particularly the Internet, and
the use of corporate support tools. It is possible to give the impression of a single,
centralized Service Desk. In fact, the personnel might be spread or located in any number
or type of geographical or structural locations.
Local User: A user who is at the same physical location as the Service Desk.
Remote User: This user and the Service Desk are at physically separate locations.
5-112

Service Desk Staffing

Service Desk Staffing

An organization must ensure that the correct number of
staff are available
Call rates vary at different times and the service desk
must be staffed to meet demand
An organization must decide on the level and range of
skills it requires of its service desk staff
Training and retention are critical factors for a Service
Desk
Super Users act as liaison points with IT in general and
the Service Desk in particular
86
An organization must ensure that the correct number of staff are available at any time to
match business demand. Call rates can be volatile. Often in the same day, the arrival rate
might go from very high to very low and back again. An organization must decide on the
level and range of skills it requires of service desk staff. It must then ensure that these skills
are available at the appropriate times. A range of skill options are possible. These options
include:
A call-logging service where staff need only basic technical skills
A technical service desk including the most technically skilled staff in the
organization
All Service Desk staff should be adequately trained before they take calls. IT managers
need to recognize the importance of the Service Desk and its staff and give the Service Desk
special attention. Any significant loss of staff can be disruptive and lead to inconsistent
service. Therefore, efforts should be made to make the Service Desk an attractive place to
work.
Many organizations find it useful to appoint or designate a number of Super Users
throughout the user community. These Super Users act as liaison points with IT in general
and the Service Desk in particular. Super Users can be given some additional training and
awareness and used as a conduit for communications flow in both directions. They can filter
requests and issues raised by the user community, in some cases even going as far as to raise
incidents or requests themselves. This practice can help prevent incident storms, when a
5-113

key service or component fails and affects many users. Super Users can also transmit
information from the Service Desk outward quickly.
5-114

Service Desk Metrics

Service Desk Metrics

The first-line resolution rate: the percentage of calls
resolved at first line, without the need for escalation to
other support groups
Average time to resolve an incident
Average time to escalate an incident
Percentage of customer or user updates conducted within
target times, as defined in SLA targets
Average time to review and close a resolved call
87
Metrics should be established so that the performance of the Service Desk can be evaluated
at regular intervals. Regular evaluation is important to assess the health, maturity,
efficiency, and effectiveness of Service Desk operations. In addition, it helps awareness of
opportunities to improve Service Desk operations.
Detailed metrics are needed and must be examined over a period of time. These will include
the call-handling statistics previously mentioned in telephony, and the following metrics:
The first-line resolution rate: the percentage of calls resolved at first line, without
the need for escalation to other support groups
Average time to resolve an incident (when resolved at first line)
Average time to escalate an incident (where first-line resolution is not possible)
Average Service Desk cost of handling an incident
Percentage of customer or user updates conducted within target times, as defined

in SLA targets
Average time to review and close a resolved call
The number of calls broken down by time of day and day of week, combined with
average call time, is a critical in determining the number of staff required
5-115

Technical Management, Applications Management, and Operations Management Functions
Lesson 8: Technical Management,

Applications Management, and
Operations Management Functions
Lesson 8: Technical Management, Application

Management, and Operations Management
Functions
5-116

Technical Management
Technical Management
Technical Management ensures that the knowledge
required to design, test, manage, and improve IT services
is identified, developed, and refined
Technical Management ensures that resources are
effectively trained and deployed to design, build,
transition, operate, and improve the technology required
to deliver and support IT services
89
Technical Management function performs a dual role:
It is the custodian of technical knowledge and expertise related to managing the IT

Infrastructure. In this role Technical Management ensures that the knowledge
required to design, test, manage, and improve IT services is identified, developed,
and refined.
It provides the actual resources to support the IT Service Management Lifecycle.

In this role, Technical Management ensures that resources are effectively trained
and deployed. These resources will design, build, change, operate, and improve
the technology required to deliver and support IT services.
By performing these two roles, Technical Management is able to ensure that the
organization has access to the right type and level of human resources to manage
technology. Therefore, it is able to meet business objectives. Part of this role is also to
ensure a balance between the skill level, utilization, and the cost of these resources.
Technical Management has an additional but important role. It is to provide guidance to IT
Operations regarding how best to maintain the ongoing operational management of
technology.
5-117

Technical Management Objectives

Technical Management Objectives

Help plan, implement, and maintain a stable technical
infrastructure to support the business processes of the
organization through:
Well-designed, highly resilient, cost-effective technical
topology
Adequate technical skills to maintain the technical
infrastructure in optimum condition
The swift use of technical skills to quickly diagnose and
resolve any technical failures that do occur
90
The objectives of Technical Management are to help plan, implement, and maintain a stable
technical infrastructure to support the business processes of the organization through:
5-118
Well-designed, highly resilient, cost-effective technical topology
Adequate technical skills to maintain the technical infrastructure in optimum

condition
The swift use of technical skills to quickly diagnose and resolve any technical
failures that do occur

Application Management
Application Management
Application Management plays a role in all applications,
whether purchased or developed in-house.
One of the key decisions to which they contribute is the
decision of whether to buy an application or build it.
After that decision is made, Application Management
performs a dual role.
91
In the first role, Application Management is the custodian of technical knowledge and
expertise related to managing applications. In this role Application Management, working
together with Technical Management, ensures that the knowledge required to design, test,
manage, and improve IT services is identified, developed, and refined.
In the second role, Application Management provides the actual resources to support the IT
Service Management Lifecycle. In this role Application Management ensures that
resources are effectively trained and deployed to perform the following functions when
developing technology required to deliver and support IT services:
Design
Build
Transition
Operate
Improve
By performing these two roles, Application Management is able to ensure that the
organization has access to the right type and level of human resources to manage
applications. Therefore, the organization is able to meet business objectives. This function
5-119

starts in Service Strategy, expands in Service Design, is tested in Service Transition, and is
refined in Continual Service Improvement.
5-120

Application Management Objectives

Application Management Objectives

To support the business processes of the organization by
helping to identify functional and manageability
requirements for application software.
To assist in the design and deployment of those
applications and the ongoing support and improvement of
those applications.
92
These objectives are achieved through the following items:
Applications that are well-designed, resilient, and cost-effective
The assurance that the necessary functionality is available to achieve the required
business outcome
The organization of adequate technical skills to maintain operational applications

in optimum condition
Swift use of technical skills to quickly diagnose and resolve any technical failures
that do occur
5-121

Operations Management
Operations Management
The Operations Management function implements the
ongoing activities and procedures required to manage
and maintain the IT infrastructure.
These activities facilitate the delivery and support IT
services at the agreed-upon levels
93
These activities include:
5-122
Operations Control, which oversees implementing and monitoring of IT

infrastructure operational activities and events. An Operations Bridge or Network
Operations Center can assist with this activity.
Console Management, which refers to defining central observation and

monitoring capability and then using those consoles to monitor and control
activities.
Facilities Management, which refers to the management of the physical IT

environment, typically a data center or computer rooms and recovery sites
together with all the power and cooling equipment. Facilities Management also
includes the coordination of large-scale consolidation projects, for example, data
center consolidation or server consolidation projects.
IT Operations Management is responsible primarily for maintaining existing

stability. The stability of the IT infrastructure and consistency of IT services is a
primary concern of IT Operations. IT Operations Management must be able to
continually adapt to and keep pace with business requirements and demand. IT
Operations Management can challenge current methods and ways of thinking.

Operations Management Objectives

Operations Management Objectives

Daily maintenance to sustain stability of the day-to-day
processes and activities of the organization
Regular scrutiny and improvements to achieve improved
service at reduced costs, while maintaining stability
Swift application of operational skills to diagnose and
resolve any IT operations failures that occur
94
5-123

Unit Scenario

When many organizations think of ITIL, they think of Service Operations. It is typical in
the industry that businesses or IT departments start with Services Operations when they
begin the ITIL journey or discipline. Creating a single scenario for these functions and
management areas is not very helpful. Therefore, several will be created to illustrate the
information presented in this unit.
Incident management and event management actions are typically handled by the Service
Desk function. Most organizations have Service Desks. However, they can often be
confused with help desks. Recognizing the differences between these two areas is simply a
matter of maturity of processes and the acceptance of ITIL into the organization.
The Service Desk team is often the single point of focus when a user needs to:
Generate a service request
Log an incident
Gain information
A frequent example is users stating they cannot log in to their e-mail. This Service Request
can be an incident, depending on the issue. This situation can become a problem if the
incident is not quickly solved or proves to be shown of a greater challenge. Examples are:
If the user can not log in because a disk is out of space and system is shut down
If the system was quarantined because of a security breach that is under

investigation
Alternatively, perhaps the user is a contractor hired to assist with the installation of the
financial system. The user might have called to acquire an e-mail account. The user was
then told to request a service. ITIL v3 calls this a Service Offering.
Events that are typically driven through automated system alerts can also be classified as
an incident. Examples:
The security software or spyware sent a red alert to the incident tool set to alert of
a concern
The e-mail database server sent an alert of disk space running out
These alerts are then worked or moved through automation to a team assigned to work the
issue. This team must bring service back into the availability mandated by the Service Level
Agreement.
5-124

Unit Scenario
This unit described problem management. Consider for a moment the examples here and
what might bring them into focus or scrutiny by the problem team. Perhaps it is the
frequency for which they have occurred. For example, the e-mail system has run out of
space before, or the spyware has alerted the system several days before. In these cases, if
the problem team was focused on analysis and proactive problem management, they will
see frequency as an issue. Perhaps it is time to allocate additional disk space or to change
archive settings. Or, perhaps the spyware has located an exposed hacker risk, or is simply
not adequate for the current version. These things being investigated through a problem
record for research and resolution will move into the Problem Management space.
Service Operations consist of standard roles within organizations such as service desk
manager and service desk staff. However, not all organizations have problem managers.
Some organizations have size and staff issues. Some are not yet mature in their ITIL
adoption to have established true ITIL problem management. As an organization develops
and begins the path to Service Operations, it is critical to establish roles and ownership.
These roles ensure that the business benefits from the full value of the processes. They will
be able to move into the continual service improvement processes, when they have aligned
the organizations roles towards ITIL.
5-125

Unit Scenario
Review Questions
1.
The goal of which of the following choices is to deploy releases into production
and to ensure effective use of the service in order to deliver value to the customer?
2.
b.
c.
Change Management
d.
Which of the following choices are conflicting balances in Service Operation?

Select all that apply.
a.Quality versus Cost of Service
3.
b.
Stability versus Responsiveness
c.
Reactive versus Proactive
d.
IT Services versus Technology Components
Which of the following choices deals with any occurrence that has significance
for the management of the IT infrastructure or the delivery of IT service?
a.Event Management
4.
b.
Problem Management
c.
Incident Management
d.
Access Management
Which of the following roles deals with an unplanned interruption to an IT

service, reduction in the quality of an IT service, or failure of a configuration item
that has not yet affected service?
a.Event Management
5-126
b.
Problem Management
c.
Incident Management
d.
Access Management

Unit Scenario
5.
Which of the following roles deals with the unknown cause of one or more
incidents?
a.Event Management
6.
b.
Problem Management
c.
Incident Management
d.
Access Management
Which of the following roles manages the overall desk activities and acts as
further escalation point for the supervisors?
a.Problem Manager
7.
b.
Incident Manager
c.
Service Desk Manager
d.
Service Desk Analyst
Which of the following roles provides first-level support through taking calls and
handling the resulting incidents or service requests?
a.Problem Manager
8.
b.
Incident Manager
c.
d.
Which of the following roles monitors the effectiveness of Incident Management

and making recommendations for improvement?
a.Problem Manager
9.
b.
Incident Manager
c.
d.
Which of the following roles owns the Known Error Database and acts as the
gatekeeper for the inclusion of all Known Errors?
a.Problem Manager
b.
Incident Manager
c.
5-127

Unit Scenario
d.
10.
Which of the following management functions acts as the custodian of technical

knowledge and expertise related to managing the IT Infrastructure?
a.Application Management Function
11.
b.
IT Operations Management Function
c.
Technical Management Function
d.
Service Desk Function

knowledge and expertise related to managing applications?
12.
b.
c.
d.
Which of the following management functions has the role of implementing the
ongoing activities and procedures required to manage and maintain the IT
infrastructure?
5-128
b.
c.
d.

Unit Scenario
5-129

Unit Scenario
Review Answers
1.
The goal of which of the following choices is to deploy releases into production
and to ensure effective use of the service in order to deliver value to the customer?
b. Release and Deployment Management
2.
Which of the following are conflicting balances in Service Operation? Select all
that apply.
a. Quality versus Cost of Service
b. Stability versus Responsiveness
c. Reactive versus Proactive
d. IT Services versus Technology Components
3.
Which of the following choices deals with any occurrence that has significance
for the management of the IT infrastructure or the delivery of IT service?
a. Event Management
4.
Which of the following roles deals with an unplanned interruption to an IT

service, reduction in the quality of an IT service, or failure of a configuration item
that has not yet affected service?
c. Incident Management
5.
Which of the following roles deals with the unknown cause of one or more
incidents?
b. Problem Management
6.
Which of the following roles manages the overall desk activities and acts as
further escalation point for the supervisors?
c. Service Desk Manager
7.
Which of the following roles provides first-level support through taking calls and
handling the resulting incidents or service requests?
d. Service Desk Analyst
8.
Which of the following roles monitors the effectiveness of Incident Management

and making recommendations for improvement?
b. Incident Manager
9.
5-130
Which of the following roles owns the Known Error Database and acts as the
gatekeeper for the inclusion of all Known Errors?

Unit Scenario
a. Problem Manager
10.

knowledge and expertise related to managing the IT Infrastructure?
a. Technical Management Function
11.

knowledge and expertise related to managing applications?
a. Application Management Function
12.
Which of the following management functions has the role of implementing the
ongoing activities and procedures required to manage and maintain the IT
infrastructure?
b. IT Operations Management Function
5-131

Unit Scenario
Summary
Summary
Service Operation
Discuss Service Operation processes and associated
activities
Describe the Service Operation roles
96
5-132
Unit 6: Continual Service

Improvement
6-1
Introduction
In this unit, you will learn about Continual Service Improvement.
Objectives
Objectives
Discuss Continual Service Improvement processes and
Describe the Continual Service Improvement roles
6-2

Continual Service Improvement Overview
Lesson 1: Continual Service Improvement

Overview

Overview
6-3



Continual Service Improvement (CSI) provides feedback
and control between the functions and processes within
and across the elements of the Service Lifecycle
The dominant pattern in the lifecycle is the sequential progress. This progress goes from
Service Strategy through Service Design, Service Transition, Service Operation and back
to Service Strategy through CSI. However, that is not the only pattern of action. Every
element of the lifecycle provides points for feedback and control, which are channeled
through CSI.
6-4

Continual Service Improvement (CSI)

Continual Service Improvement (CSI)

Continual Service Improvement aligns and realigns IT
services to changing business needs by identifying and
implementing improvements to IT services
Improvement activities support the Service Lifecycle
through Service Strategy, Service Design, Service
Transition, and Service Operation
CSI strives to make processes more effective, efficient,
and cost-effective
6-5

CSI Objectives
Continual Service Improvement Objectives

Review, analyze, and make recommendations on improvement
opportunities in each lifecycle phase: Service Strategy, Service
Design, Service Transition, and Service Operation
Review and analyze Service Level Achievement results
Identify and implement individual activities to improve IT Service
Quality and improve efficiency and effectiveness of enabling the IT
Service Management (ITSM) processes
Improve cost effectiveness of delivering IT services without sacrificing
customer satisfaction
Ensure applicable quality management methods are used to support
continual improvement activities
6-6

Benefits of Continual Service Improvement

Benefits of Continual Service Improvement

Business and Customer Benefits
Financial Benefits
IT Organization Internal Benefits
6-7

Business and Customer Benefits

Benefits of CSI: Business and Customer

Overall improved quality of business operations
More reliable business support provided by Incident
Management, Problem Management, and Change
Management processes
Increased staff productivity because of increased
reliability and availability of IT services
Better working relationships between customers and the
IT service provider
6-8

Financial Benefits
Benefits of CSI: Financial

Cost-effective provision of IT services
Cost-justified IT infrastructure and services
Reduced costs for implementing changes
Reduced business impact due to IT changes
Improved service reliability, stability, and thus availability
Improved resource allocation and utilization
6-9

IT Organization Benefits
Benefits of CSI: IT Organization

Improved metrics and management reporting
Alignment of cost structure with business needs
Defined roles and responsibilities
10
6-10

CSI Key Terms

CSI Key Terms

Goals and Objectives
Baselines
Key Performance Indicators (KPIs)
Metrics
Governance
11
Goals and Objectives: the inputs and outputs of a process are identified
Baselines: the current performance of the process is recorded as a starting point or baseline
level
Key Performance Indicators (KPIs): set to measure against and determine the quality of
the service
Metrics: measurements are taken and compared to the determined KPIs
Governance: External and internal requirements for services which help shape goals and
objectives
6-11

Metrics and Measurement

Metrics and Measurement

Metrics are a system of parameters or ways of
quantitative assessment of a process that is to be
measured, along with the processes to carry out such
measurement.
Metrics define what is to be measured.
Three types:
Technology Metrics
Process Metrics
Service Metrics
12
It is important to remember that there are three types of metrics that an organization will
need to collect to support CSI activities as well as other process activities. The types of
metrics are:
6-12
Technology metrics: These metrics are often associated with component and
application based metrics such as performance and availability.
Process metrics: These metrics are captured in the form of CSFs, KPIs, and
activity metrics for the service management processes. These metrics can help
determine the overall health of a process. Four key questions that KPIs can help
answer are around quality, performance, value, and compliance of following the
process. CSI would use these metrics as input in identifying improvement
opportunities for each process.
Service metrics: These metrics are the results of the end-to-end service.
Component metrics are used to compute the service metrics.

CSI Principles
CSI Principles
For all services and the underlying ITSM processes,
service improvement must focus on:
Increasing the efficiency
Maximizing the effectiveness
Optimizing the cost
13
The only way to focus on these principles is to ensure that improvement opportunities are
identified throughout the entire service lifecycle.
6-13

Continual Service Improvement Model

Continual Service Improvement Model
14
The primary purpose of CSI is to continually align and realign IT services to the changing
business needs. This alignment is done by identifying and implementing improvements to
IT services that support business processes. These improvement activities support the
lifecycle approach through Service Strategy, Service Design, Service Transition and
Service Operation. In effect, CSI searches for ways to improve process effectiveness,
efficiency, and cost effectiveness.
6-14

The Deming Cycle

The Deming Cycle

W. Edwards Deming is best known for his management
philosophy leading to:
Higher quality
Increased productivity
More competitive position
The four key stages of the Deming Cycle or Circle are:
Plan
Do
Check
Act
15
The goal of CSI in using the Deming Cycle is steady, ongoing improvement.
6-15

The Deming Cycle and CSI

The Deming Cycle and CSI

The Deming Cycle is critical at two points in CSI:
Implementation of CSIs
Application of CSI to services and service management
processes
16
At implementation, all four stages of the Deming Cycle are used. With ongoing
improvement, CSI draws on the check and act stages to monitor, measure, review and
implement initiatives.
6-16

The Deming Cycle
The Deming Cycle consists of cycles of Planning, Acting, Checking the results, and Doing
actions that improve the process. Over time the goal of the Deming Cycle is steady
improvement of processes.
6-17

CSI: Governance
Continual Service Improvement: Governance

Enterprise Governance describes a framework that covers:
Corporate governance
Business management
Corporate governance is about promoting:

Corporate fairness
Transparency
Accountability
IT governance consists of:

Leadership
Organizational structures
Processes
18
Enterprise governance describes a framework that covers both the corporate governance
and the business management aspects of the organization. Enterprise governance also
considers the whole picture to ensure that strategic goals are aligned and good management
is achieved.
The most recent and highly visible example of a renewed emphasis on corporate
governance is the Sarbanes-Oxley Act (SOX) of 2002 in the United States. Created in the
aftermath of fraudulent behavior by corporate giants, SOX includes the following
provisions:
Requires corporations to engage in corporate fairness
Mandates complete transparency of transactions
Holds executives accountable for any material deficiencies
IT governance ensures that the IT of an organization sustains and extends the strategies and
objectives of that organization.
IT departments and organizations must now comply with new rules and legislation and
continually demonstrate their compliance through successful independent audits by
external organizations.
6-18

Technology Considerations for CSI

Technology Considerations for CSI

CSI activities require software tools.
These tools:
Support the monitoring and reporting on IT services and
ITSM processes.
Will be used for data gathering, monitoring, analysis,
and reporting for services.
Assist in determining the efficiency and effectiveness of
the IT Service Management processes.
19
Tools that support CSI activities include:
IT service management suites
Systems and network management tools
Event management tools
Automated incident and problem resolution tools
Automated incident and problem resolution tools
Service Request and fulfillment tools
Performance management tools
Application and service performance monitoring tools
Statistical analysis tools
Version control Software
Configuration Management software
Test management software
6-19

6-20
Security Management tools
Project and portfolio management tools
Financial Management tools
Business intelligence and reporting tools

The 7-Step Improvement Process
Lesson 2: The 7-Step Improvement Process
Lesson 2: The 7-Step Improvement

Process
6-21

The 7-Step Improvement Process Activities

The 7-Step Improvement Process Activities

1. Define what you should measure
2. Define what you can measure
3. Gather the data
4. Process the data
5. Analyze the data
6. Present and use the information for assessment,
summary, and action plans
7. Implement corrective action
21
The 7-Step Improvement Process for Continual Service Improvement ensures that you
identify what you actually measure and where you find that information. The 7-Step
Improvement Process consists of the following steps:
6-22
1.
Define what you should measure.

This step is extremely important, but it is often skipped. Service Strategy and
Service Design should have defined this already. CSI looks at this again, from the
perspective of where things stand now. This helps to define the ideal condition for
both the Business and IT.
2.
Define what you can measure.

CSI performs a gap analysis using the identified and implemented service level
requirements and IT capabilities and the available budgets to pinpoint areas for
improvement. In addition, the question of how to achieve these improvements is
answered. If customers and IT do not define achievable measurement and
reporting requirements, it is highly unlikely that the customer will be satisfied.
3.
Gather the data.

To evaluate the success or failure of the goals and objectives, data is gathered
(typically through Service Operations). Data gathering includes answering the
questions: Who? What? When? Can the integrity of the data be trusted?
4.
Process the data.

In this step, time frames are coordinated, unaligned data is rationalized and made

consistent, and gaps in data are identified. The goal is to sort and compare data
from many sources. After the data is rationalized, analysis can begin. This step
includes answering questions about frequency, format, system, and accuracy.
5.
Analyze the data.

In this step, the data is analyzed. Service gaps, trends, and impact on business is
identified. Questions that are answered in this step relate to data relations, trends,
plans, targets, and corrective action.
6.
Present and use the information for assessment, summary, and action plans.
In this step, the results of the improvement efforts are presented to all the
stakeholders. In addition, suggestions for future endeavors are suggested.
7.
Implement corrective action.

The corrective actions that need to be taken to improve the service are
communicated and explained to the organization. Following this step, the
organization establishes a new baseline and the cycle begins anew.
6-23

7-Step Improvement Process Interfaces

7-Step Improvement Process Interfaces

Service Strategy
Service Design
Service Transition
Service Operation
Service Level
Availability and Capacity
Incident Management and Service Desk
Security Management
22
In order to support improvement activities it is important to have CSI integrated within each
lifecycle stage including the underlying processes residing in each lifecycle phase. Some of
the integration of the process with the lifecycle stages and Service Management processes
include:
Service Strategy: Responsible for monitoring the progress of strategies, standards, policies
and architectural decisions that have been made and implemented.
Service Design: Monitors and gathers data associated with creating and modifying (design
efforts) of services and service management processes.
Service Transition: Develops the monitoring procedures and criteria to be used during and
after implementation.
Service Operation: Responsible for the actual monitoring of services in the production
environment. Service Operation plays a large part in the processing activity. It provides
input into what can be measured and processed into logical groupings as well as doing the
actual processing of the data.
Service Level Management: SLM plays a key role in the data gathering activity as SLM
is responsible for not only defining business requirements but also the capabilities of IT to
achieve them.
6-24

Availability Management and Capacity Management: Provide significant input into

existing monitoring and data collection capabilities, tool requirements to meet new data
collection requirements and ensuring the Availability and Capacity Plans are updated to
reflect new or modified monitoring and data collection requirements.
Incident Management and Service Desk: Incident Management can define monitoring
requirements to support event and incident detection. It does this through automation. It
also has the ability to automatically open incident tickets and automatically escalate
incident tickets. As a single point of contact it is important for the Service Desk to monitor
telephony items
Security Management: Defines security monitoring and data collection requirements.
Monitors, verifies, and tracks the levels of security according to the organizational security
policies and guidelines. Assists in determining effects of security measures on the data
monitoring and collection.
Financial Management: Financial Management provides the necessary templates to assist
CSI to create the budget and expenditure reports for the various improvement initiatives as
well as providing the means to compute the ROI of the improvements.
The 7-Step Improvement Process also interfaces with these and other processes in
monitoring and data collection, measuring the data, analyzing the data, presenting and
using the information, and implementing corrective action.
6-25

CSI Critical Success Factors and KPIs

7-Step Improvement Process Critical Performance Factors

and KPIs
Opinions on number of CSFs and KPIs to define are
varied.
Some recommended no more than two to three KPIs
defined per CSF at any given time and that a service or
process has no more that two to three CSFs associated
with it at any given time.
Others recommend four to five.
When considering the number of services, the upper limit
can be overwhelming.
23
It is recommended that in the early stages of a CSI program only two to three KPIs for each
CSF are defined, monitored and reported. As the maturity of a service and service
management processes increase, additional KPIs can be added. Based on what is important
to the business and IT management, the KPIs can change over a period of time. Also, keep
in mind that as service management processes are implemented this will often change the
KPIs of other processes.
Contributions from the key roles identified in Service Design, Service Transition and
Service Operation, each of which has very specific goals to meet. Ultimately, the quality of
the service will be determined by how well each role meets its goals, and by how well those
sometimes conflicting goals are managed along the way. That makes it crucial that
organizations find some way of measuring performance by applying a set of metrics to
each goal.
6-26

7-Step Improvement Process Roles

7-Step Improvement Process Roles

Different roles and titles for each step
24
Step 1: Define what you should measure: Roles for this step include individuals involved
with decision making from IT and the business. These individuals understand the internal
and external factors that influence the measured elements to support the business,
governance, and regulatory legislation. Titles for these roles might be: service manager,
service owner, service level manager, CSI manager, process owner, process managers,
customers, business and IT analysts, and senior IT managers.
Step 2: Define what you can measure: Roles for this step internal and external providers
who understand the capabilities of the measuring processes, procedures, tools and staff.
Titles for these roles might be: service manager, service owner, process owner, process
managers, internal and external providers.
Step 3: Gathering the data: Roles for this step include individuals involved in day-to-day
process activities within the Service Transition and Service Operation lifecycle phases.
Titles for these roles might be: service desk staff, technical management staff, application
management staff, IT security staff.
Step 4: Processing the data: Roles for this step include individuals involved in day-to-day
process activities within the Service Transition and Service Operation lifecycle phases.
Titles for these roles might be: service desk staff, technical management staff, application
management staff, IT security staff.
6-27

Step 5: Analyzing the data: Roles for this step include internal and external providers who
understand the capabilities of the measuring processes, procedures, tools, and staff. Titles
for these roles might be: service owner, process owner, process managers, business/IT
analysts, senior IT analysts, supervisors, and team leaders.
Step 6: Presenting and using the information: Roles for this step include internal and
external providers who understand the capabilities of the service and the underpinning
processes and possess good communication skills. Key personnel involved with decision
making from both IT and the business. Titles for these roles might be: CSI manager, service
owner, service manager, service level manager, process owner, process managers,
customers, business and IT analysts, senior IT managers, internal and external providers.
Step 7: Implementing corrective action: Roles for this step include internal and external
service providers. Titles for these roles might include: CSI manager, service owner, service
manager, service level manager, process owner, process managers, customers, business and
IT analysts, senior IT managers, internal and external providers.
6-28

Process of Service Reporting
Lesson 3: Process of Service Reporting
Lesson 3: Process of Service Reporting
6-29

Aspects of Service Reporting

Aspects of Service Reporting

Identifying the purpose
Identifying the target audience
Identifying the use for the report
26
It is important to the business to see a historical representation of the past periods

performance. However, it is mostly concerned with the historical events that continue to be
a threat going forward. It is also concerned with how IT intends to safeguard against such
threats.
IT should build an approach to reporting that leads to action. That is, reporting should focus
on:
6-30
This is what happened.
This is what we did.
This is how we will ensure it does not impact you again.
This is how we are working to improve the delivery of IT services generally.

Implementing Reporting
Implementing Reporting
Target audiences and the related business views on the
service delivered
Agree on what to measure and report
Agree on definitions of all terms and boundaries
Define basis of all calculations
Define reporting schedules
Provide access to reports and medium to be used
Schedule meetings to review and discuss reports
27
6-31

Content and Audience Considerations

Content and Audience Considerations

Make clear which policies and rules have been applied for
each report
Translate flat historical data into meaningful business
views
Annotate around the key questions, threats, mitigations
and improvements
Make reporting customizable and automated
Select medium that is accessible
Shape reports to meet changing business needs
28
6-32

Service Reporting Benefits

Service Reporting Benefits

the targeted recipient having clear and relevant
information
information accessible in a medium chosen by the
recipient
reporting that details the delivery of IT into the customer
environment within their boundaries
information that is not clouded by the data related to the
delivery of IT into other areas of the business
29
6-33

Service Reporting Activities

Service Reporting Activities

Targeted audiences and the related business views on
the service delivered
Agreement on what to measure and what to report on
Agreed definitions of all terms and boundaries
Basis of all calculations
Reporting schedules
Access to reports and medium to be used
Meetings scheduled to review and discuss reports
30
The key to effect Service Reporting is to take the time to define and agree on how reporting
will be implemented with the business and Service Design.
6-34

Reporting Analyst
Reporting Analyst
Participates in CSI meetings and Service Level
Management meetings
Consolidates data
Produces trends
Produces reports on service or system performance
31
One of the key roles for CSI is that of Reporting Analyst. The Reporting Analyst will often
work in concert with the Service Level Management roles. The reporting analyst reviews
and analyzes data from components, systems and sub-systems in order to obtain a true endto-end service achievement. The reporting analyst identifies trends and establishes if the
trends are positive or negative. This information is then used in the presenting of the data.
The Reporting Analyst has the following responsibilities:
Participates in CSI meetings and Service Level Management meetings to ensure

the validity of the reporting metrics, notification thresholds, and overall solution
Consolidates data from multiple sources
Produces trends and identifies:
Whether the trends are positive or negative
What their impact is likely to be
If the trends are predictable for the future
Produces reports on service or system performance based on the negotiated OLAs

and SLAs and improvement initiatives
6-35

Process of Service Measurement
Lesson 4: Process of Service Measurement
Lesson 4: Process of Service

Measurement
6-36

Service Measurement
Service Measurement
Service Measurement is the ability to predict and report
service performance against the established target of
achievements of an end-to-end service
Service Measurement requires someone to:
Take the individual measurements
Combine individual measurements to provide a view of the true
customer experience
The measuring process must regularly confirm that:

The data being collected and collated is still required
Measurements are adjusted where necessary
33
Service Measurement is the ability to predict and report service performance against the
established target of achievements of an end-to-end service.
One of key set of activities of the Continual Service Improvement is to measure, analyze,
and report on IT services and ITSM results. Measurements will, of course, produce data.
This data should be analyzed over time to produce a trend. The trend will tell a story that
can be positive or negative.
Measurements of this kind must have ongoing relevance. Information that was important
to know last year might not be pertinent this year.
6-37

Measurements for CSI

Measurements for Continual Service Improvement

Measurements are performed to:
Validate
Direct
Justify
Intervene
34
The four basic reasons to monitor and measure lead to three key questions:
1.
Why monitor and measure?
2.
When can monitoring and measuring of this item be stopped?
3.
Is anyone using this data?
Every time you produce a report, ask yourself, Is this report still needed and used by
anyone? Reasons to continue producing a report might include:
6-38
To validate: Monitoring and measuring to validate previous decisions.
To direct: Monitoring and measuring to set direction for activities in order to

meet set targets. It is the most prevalent reason for monitoring and measuring.
To justify: Monitoring and measuring to justify, with factual evidence or proof,

that a course of action is required.
To intervene: Monitoring and measuring to identify a point of intervention,

including subsequent changes and corrective actions.

Baselines
Baselines
An important beginning point for highlighting improvement
is to establish baselines as markers or starting points for
later comparison
Baselines are also used to establish an initial data point
to determine if a service or process needs to be improved
Baselines must be documented, recognized, and
accepted throughout the organization
35
Baselines must be established at each level: strategic goals and objectives, tactical process
maturity, operational metrics, and Key Performance Indicators (KPIs).
6-39

Types of Metrics
Types of Metrics
Technology metrics
Process metrics
Service metrics
36
Information for measuring is gathered from IT Service Management tools, monitoring

tools, reporting tools, investigation tools, existing reports, and other sources.
Technology metrics are often associated with component-based and application based
metrics such as performance, availability, and so on.
Process measurements can help determine the overall health of a process. Key Performance
Indicators (KPIs) can help answer questions about quality, performance, value, and
compliance in following the process.
Service Metrics are the results of the end-to-end service. Component or technology metrics
are used to compute the Service Metrics.
6-40

Service Measurement Objective

Service Measurement Objective

For IT to measure and report against an end-to-end
service
37
Service measurement requires someone to take the individual measurements and combine
them to provide a view of the true customer experience.
For services most organizations use three basic measurements:
Availability of the service
Reliability of the service
Performance of the service
6-41

Service Measurement Activities

Service Measurement Activities

Defining what to measure
Setting targets
Defining process measurement
Creating a measurement framework grid
Using measurement and metrics
Creating scorecards and reports
38
Defining what to measure

Effective service measures concentrate on a few vital, meaningful indicators that are
economical, quantitative, and usable for the desired results. Some common measurements
include:
Service levels
Customer satisfaction
Business impact
Supplier performance
Setting targets
Targets set by management are quantified objectives to be attained. They express the aims
of the service or process at any level and provide the basis for the identification of problems
and early progress towards solutions and improvement opportunities.
6-42

Defining process measurement

Define what to measure at the process activity level. Some key activity metrics to capture
are:
Number of urgent changes
Number of failed urgent changes
Unauthorized changes that failed
Creating a measurement framework grid

Create a framework grid that will lay out the high-level goals. It will also define which KPIs
will support the goal and which category the KPI addresses. KPI categories can be
classified as the following categories:
Compliance
Quality
Performance
Value
Using measurement and metrics
Identify whether the results that are being shown make sense.
Do not jump to conclusions without analyzing the possible causes for the results.
Look at measurements as a whole but also analyze trends and provide

interpretation of the meaning of the metrics and measures.
Creating scorecards and reports
Reports and scorecards should be linked to overall strategy and goals. Using a
Balanced Scorecard approach is one way to manage this alignment.
When creating reports it is important to know their purpose and the details that are
required.
Before starting the design of any report it is also important to know the following:
Who is the target audience of the report?
How will the report be used?
Who is responsible for creating the report?
6-43

6-44
How will the report be created?
How frequently is the report to be created?
What information will be produced, shared, or exchanged?

Process of Creating a Return on Investment
Lesson 5: Process of Creating a Return on

Investment
Lesson 5: Process of Creating a Return

on Investment
6-45

Return on Investment for CSI

Return on Investment for CSI

One of the keys for measuring and reporting is to be able
to define improvement opportunities that will create a
Return on Investment for the business.
Most organizations need proof that process improvement
will be beneficial for the business in terms of increased
productivity and cost.
Creating a Return on Investment (ROI) must take into
consideration the investment cost and the gains to the
organization.
40
It is important to recognize that an investment in CSI, and realizing its benefits, can vary.
They can depend on the customer base, size of IT, and the maturity of the ITIL process
implemented. In addition, benefits will cross existing organizational boundaries and true
benefits can only be captured in collaboration with the users, customers, and ITIL process
owners.
A baseline must be established for all future measurements to be meaningful.
Measurements can often reflect a single picture or point in time. However, analyzing these
pictures over time will help identify trends. These trends, in turn, help identify areas of
improvement. The first measurement is the baseline. It is essential that the same
measurements be used consistently to establish trend patterns.
While the initial identification of benefits is an estimate of those likely to be realized by the
proposed process improvement initiative, there is also a need to subsequently measure the
benefits actually achieved.
6-46

Return on Investment Activities

Creating a Return on Investment Activities

Creating an ROI statement
Establishing the business case
Measuring the benefits achieved
41
The activities associated with the Return on Investment process are creating and ROI
statement, establishing the business case, and measuring the beneifits achieved.
Creating an ROI Statement
Calculating internal resource costs. These costs will be internal resource costs,
tool costs, consulting costs, and others.
Defining what the organization will gain. These returns are often difficult to
define.
Defining the cost of lost productivity. Availability is a good measure to understand

the cost of lost productivity, downtown, or of being unable to complete a business
transaction. Things to look at in terms of availability include:
Impact by minutes lost.
Impact by business transaction.
Defining the cost to downtime.
6-47

Establishing the Business Case

The Business Case should identify the reasons for starting a service or process
improvement initiative. The focus should not only be on ROI but also on the business value
that service improvement brings to the organization and its customers. Examples of
business value measures are:
Time to market
Customer retention
Inventory carrying cost
Market share
Measuring the Benefits Achieved

Determine the current or anticipated concern of the organization with respect to IT.
Estimate the cost if the status quo were to remain. Estimate the savings that could be
realized if the ITSM processes were put in place or improved upon.
6-48

Continual Service Improvement Roles

Roles

Roles
6-49

Service Manager
Service Manager
Provides leadership on development of business case
and product line strategy and architecture, new service
deployment, and lifecycle management schedules
Performs Service Cost Management activities
Manages various objectives to achieve goals and
financial commitments of organization
Creates an imaginative organization
43
The key responsibilities of a Service Manager are as follows:
6-50
Provide leadership on the development of business case and product line strategy
and architecture, new service deployment and lifecycle management schedules.
Perform Service Cost Management activities in close partnership with other

organizations such as Operations, Engineering, and Finance. Many of these
organizations are held to strict internal supplier agreements.
Manage various and sometimes conflicting objectives to achieve the goals and
financial commitments of the organization.
Create an imaginative organization that encourages high performance and

innovative contributions from members within a rapidly changing environment.

Continual Service Improvement Manager

Continual Service Improvement Manager

Works with Service Owner to identify and prioritize
improvement opportunities
Works with Service Level Manager to ensure monitoring
requirements are defined
Works with Service Level Manager to identity Service
Improvement Programs
Ensures that monitoring tools are in place to gather data
Defines and reports on CSI Critical Success Factors, Key
Performance Indicators, and CSI activity metrics
44
The key responsibilities of the Continual Service Improvement Manager are as follows:
Communicates the vision of CSI across the IT organization
Works with Service Owner to identify and prioritize improvement opportunities
Works with the Service Level Manager to ensure that monitoring requirements are
defined
Works with the Service Level Manager to identity Service Improvement

Programs
Ensures that monitoring tools are in place to gather data
Ensures baseline data is captured for comparing with improvement data
Defines and reports on CSI Critical Success Factors, Key Performance Indicators,
and CSI activity metrics
Identifies other frameworks, models, and standards that will support CSI activities
Presents recommendations to Senior Management for improvement
Identifies and delivers process improvements in critical business areas across

Manufacturing and relevant divisions
6-51

Unit Scenario

As an organization attempts to adopt ITIL methodology, it begins to align processes,
persons, and tools to meet this new model. During this time, it is important to not forget that
Continual Improvement is critical to the business. Continual Improvement is crucial even
at the design phase of the first step of accepting ITIL. No single business can integrate ITIL
methodology overnight. In addition, business and markets change. Such changes cause a
service to adapt in order to continue to support the business.
Continual Service Improvement (CSI) enables the organization to review the maturity level
of processes. In addition, it measures the level of influence IT and Operations has on the
overall business. If the business is focused on selling something, IT can determine how they
are:
Assisting the business to sell better
Shortening a sales cycle
Facilitating the ordering process in terms of speed and accuracy
CSI facilitates adjustments to processes for better data gathering at the appropriate steps. In
the previous example of the financial system being implemented, CSI should be put in place
immediately at point of production. One task will be to review or document how the users
are actually using the tool set. Another task will be to see if any gaps of usability were
missed during design and testing.
CSI can assist the business to implement processes in a semi-automated fashion. Then the
review process can determine where automation truly can assist and improve efficiencies
and reduce manual activities. These types of reviews help drive resources to seek ways to
reduce cost and focus spending on what will facilitate increased revenue. Returning to the
financial system example, after it is put in place, a CSI is set up to review the payables
functions. The review might bring out that today a payables resource must enter suppliers
manually. Although that was appropriate at the initial stages, business has expanded and
additional suppliers and vendors are being added at a very strong pace. Through CSI, it is
determined that it is time to automate an interface to the system. This automation will help
suppliers to enter their own information through a secured Web site or link. This
automation will reduce manual entry and facilitate better control for payment. Then, pay
out will not occur too soon or too late. Thus, contract breaches and penalties are avoided.
6-52

Unit Scenario
Review Questions
1.
Which of the following choices comprise the Deming Model?

a.Plan, Do, Check, Act
2.
b.
Plan, Manage, Do, Act
c.
Plan, Do, Check, Revise
d.
Plan, Do, Check, Evaluate
Which of the following choices represent the business value for performing
measurements?
a.Validate
3.
b.
Direct
c.
Justify
d.
Intervene
e.
All of the Above
Which of the following choices are used to establish an initial data point to
determine if a service or process needs to be improved?
a.Measurements
4.
b.
Baselines
c.
Reports
d.
KPIs
Which type of metrics is often associated with component-based and application

based metrics such as performance and availability?
a.Technology
b.
Process
c.
Service
d.
Management
6-53

Unit Scenario
5.
Which type of metrics can help answer questions about quality, performance,
value, and compliance in following the process?
a.Technology
6.
b.
Process
c.
Service
d.
Management
Which type of metrics are the results of the end-to-end service?

a.Technology
6-54
b.
Process
c.
Service
d.
Management

Unit Scenario
6-55

Unit Scenario
Review Answers
1.
Which of the following choices comprise the Deming Model?

a. Plan, Do, Check, Act
2.
Which of the following choices represent the business value for performing
measurements?
e. All of the Above
3.
Which of the following choices are used to establish an initial data point to
determine if a service or process needs to be improved?
b. Baselines
4.
Which type of metrics is often associated with component-based and application

based metrics such as performance and availability?
a. Technology
5.
Which type of metrics can help answer questions about quality, performance,
value, and compliance in following the process?
b. Process
6.
Which type of metrics are the results of the end-to-end service?

c. Service
6-56

Unit Scenario
Summary
Summary
Discuss Continual Service Improvement processes and
Describe the Continual Service Improvement roles
46
6-57

Unit Scenario
6-58

The following pages contain the Glossary of Terms and Definitions V3.1.24, published
30 May 2007.
This glossary can be freely downloaded. See http://www.get-best-practice.co.uk/
glossaries.aspx for details of licence terms.
ITIL Glossary Crown Copyright Office of Government Commerce. Reproduced with the
permission of the Controller of HMSO and the Office of Government Commerce.
ITIL is a Registered Trade Mark, and a Registered Community Trade Mark of the Office
of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.
A-1
ITIL V3 Glossary
Acceptance: Formal agreement that an IT Service, Process, Plan, or other Deliverable is
complete, accurate, Reliable and meets its specified Requirements. Acceptance is usually
preceded by Evaluation or Testing and is often required before proceeding to the next stage
of a Project or Process. See Service Acceptance Criteria.
Access Management (Service Operation) The Process responsible for allowing Users 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
Rights Management or Identity Management.
Account Manager (Service Strategy) A Role that is very similar to Business Relationship
Manager, but includes more commercial aspects. Most commonly used when dealing with
External Customers.
Accounting (Service Strategy) The Process responsible for identifying actual Costs of
delivering IT Services, comparing these with budgeted costs, and managing variance from
the Budget.
Accredited Officially authorized to carry out a Role. For example an Accredited body may
be authorized to provide training or to conduct Audits.
Active Monitoring (Service Operation) Monitoring of a Configuration Item or an IT
Service that uses automated regular checks to discover the current status. See Passive
Monitoring.
Activity A set of actions designed to achieve a particular result. Activities are usually
defined as part of Processes or Plans, and are documented in Procedures.
Agreed Service Time (Service Design) A synonym for Service Hours, commonly used in
formal calculations of Availability. See Downtime.
Agreement A Document that describes a formal understanding between two or more
parties. An Agreement is not legally binding, unless it forms part of a Contract. See Service
Level Agreement, Operational Level Agreement.
Alert (Service Operation) A warning that a threshold has been reached, something has
changed, or a Failure has occurred. Alerts are often created and managed by System
Management tools and are managed by the Event Management Process.
Analytical Modeling (Service Strategy) (Service Design) (Continual Service
Improvement) A technique that uses mathematical Models to predict the behavior of a
Configuration Item or IT Service. Analytical Models are commonly used in Capacity
Management and Availability Management. See Modeling.
A-2
Application Software that provides Functions that are required by an IT Service. Each
Application may be part of more than one IT Service. An Application runs on one or more
Servers or Clients. See Application Management, Application Portfolio.
Application Management (Service Design) (Service Operation) The Function responsible
for managing Applications throughout their Lifecycle.
Application Portfolio (Service Design) A database or structured Document used to
manage Applications throughout their Lifecycle. The Application Portfolio contains key
Attributes of all Applications. The Application Portfolio is sometimes implemented as part
of the Service Portfolio, or as part of the Configuration Management System.
Application Service Provider (ASP) (Service Design) An External Service Provider that
provides IT Services using Applications running at the Service Provider's premises. Users
access the Applications by network connections to the Service Provider.
Application Sizing (Service Design) The Activity responsible for understanding the
Resource Requirements needed to support a new Application, or a major Change to an
existing Application. Application Sizing helps to ensure that the IT Service can meet its
agreed Service Level Targets for Capacity and Performance.
Architecture (Service Design) The structure of a System or IT Service, including the
Relationships of Components to each other and to the environment they are in. Architecture
also includes the Standards and Guidelines which guide the design and evolution of the
System.
Assembly (Service Transition) A Configuration Item that is made up from a number of
other CIs. For example a Server CI may contain CIs for CPUs, Disks, Memory etc.; an IT
Service CI may contain many Hardware, Software and other CIs. See Component CI,
Build.
Assessment Inspection and analysis to check whether a Standard or set of Guidelines is
being followed, that Records are accurate, or that Efficiency and Effectiveness targets are
being met. See Audit.
Asset (Service Strategy) Any Resource or Capability. Assets of a Service Provider include
anything that could contribute to the delivery of a Service. Assets can be one of the
following types: Management, Organization, Process, Knowledge, People, Information,
Applications, Infrastructure, and Financial Capital.
Asset Management (Service Transition) Asset Management is the Process responsible for
tracking and reporting the value and ownership of financial Assets throughout their
Lifecycle. Asset Management is part of an overall Service Asset and Configuration
Management Process. See Asset Register.
Asset Register (Service Transition) A list of Assets, which includes their ownership and
value. The Asset Register is maintained by Asset Management.
A-3
Attribute (Service Transition) A piece of information about a Configuration Item.

Examples are name, location, Version number, and Cost. Attributes of CIs are recorded in
the Configuration Management Database (CMDB). See Relationship.
Audit Formal inspection and verification to check whether a Standard or set of Guidelines
is being followed, that Records are accurate, or that Efficiency and Effectiveness targets are
being met. An Audit may be carried out by internal or external groups. See Certification,
Assessment.
Authority Matrix Synonym for RACI.
Automatic Call Distribution (ACD) (Service Operation) Use of Information Technology
to direct an incoming telephone call to the most appropriate person in the shortest possible
time. ACD is sometimes called Automated Call Distribution.
Availability (Service Design) Ability of a Configuration Item or IT Service to perform its
agreed Function when required. Availability is determined by Reliability, Maintainability,
Serviceability, Performance, and Security. Availability is usually calculated as a
percentage. This calculation is often based on Agreed Service Time and Downtime. It is
Best Practice to calculate Availability using measurements of the Business output of the IT
Service.
Availability Management (Service Design) The Process responsible for defining,
analyzing, Planning, measuring and improving all aspects of the Availability of IT
Services. Availability Management is responsible for ensuring that all IT Infrastructure,
Processes, Tools, Roles etc are appropriate for the agreed Service Level Targets for
Availability.
Availability Management Information System (AMIS) (Service Design) A virtual
repository of all Availability Management data, usually stored in multiple physical
locations. See Service Knowledge Management System.
Availability Plan (Service Design) A Plan to ensure that existing and future Availability
Requirements for IT Services can be provided Cost Effectively.
Back-out Synonym for Remediation.
Backup (Service Design) (Service Operation) Copying data to protect against loss of
Integrity or Availability of the original.
Balanced Scorecard (Continual Service Improvement) A management tool developed by
Drs. Robert Kaplan (Harvard Business School) and David Norton. A Balanced Scorecard
enables a Strategy to be broken down into Key Performance Indicators. Performance
against the KPIs is used to demonstrate how well the Strategy is being achieved. A
Balanced Scorecard has 4 major areas, each of which has a small number of KPIs. The same
4 areas are considered at different levels of detail throughout the Organization.
A-4
Baseline (Continual Service Improvement) A Benchmark used as a reference point. For

example: An ITSM Baseline can be used as a starting point to measure the effect of a
Service Improvement Plan
A Performance Baseline can be used to measure changes in Performance over the lifetime
of an IT Service
A Configuration Management Baseline can be used to enable the IT Infrastructure to be
restored to a known Configuration if a Change or Release fails
Benchmark (Continual Service Improvement) The recorded state of something at a
specific point in time. A Benchmark can be created for a Configuration, a Process, or any
other set of data. For example, a benchmark can be used in:
Continual Service Improvement To establish the current state for managing

improvements.
Capacity Management To document Performance characteristics during normal

operations.
See Benchmarking, Baseline.
Benchmarking (Continual Service Improvement) Comparing a Benchmark with a

Baseline or with Best Practice. The term Benchmarking is also used to mean creating a
series of Benchmarks over time, and comparing the results to measure progress or
improvement.
Best Practice Proven Activities or Processes that have been successfully used by multiple
Organizations. ITIL is an example of Best Practice.
Brainstorming (Service Design) A technique that helps a team to generate ideas. Ideas are
not reviewed during the Brainstorming session, but at a later stage. Brainstorming is often
used by Problem Management to identify possible causes.
British Standards Institution (BSI) The UK National Standards body, responsible for
creating and maintaining British Standards. See http://www.bsi-global.com for more
information. See ISO.
Budget A list of all the money an Organization. or Business Unit plans to receive, and plans
to pay out, over a specified period of time. See Budgeting, Planning.
Budgeting The Activity of predicting and controlling the spending of money. Consists of
a periodic negotiation cycle to set future Budgets (usually annual) and the day-to-day
monitoring and adjusting of current Budgets.
Build (Service Transition) The Activity of assembling a number of Configuration Items to
create part of an IT Service. The term Build is also used to refer to a Release that is
authorized for distribution. For example Server Build or laptop Build. See Configuration
Baseline.
Build Environment (Service Transition) A controlled Environment where Applications,
IT Services and other Builds are assembled prior to being moved into a Test or Live
Environment.
A-5
Business (Service Strategy) An overall corporate entity or Organization. formed of a

number of Business Units. In the context of ITSM, the term Business includes public sector
and not-for-profit organizations., as well as companies. An IT Service Provider provides IT
Services to a Customer within a Business. The IT Service Provider may be part of the same
Business as their Customer (Internal Service Provider), or part of another Business
(External Service Provider).
Business Capacity Management (BCM) (Service Design) In the context of ITSM,
Business Capacity Management is the Activity responsible for understanding future
Business Requirements for use in the Capacity Plan. See Service Capacity Management.
Business Case (Service Strategy) Justification for a significant item of expenditure.
Includes information about Costs, benefits, options, issues, Risks, and possible problems.
See Cost Benefit Analysis.
Business Continuity Management (BCM) (Service Design) The Business Process
responsible for managing Risks that could seriously impact the Business. BCM safeguards
the interests of key stakeholders, reputation, brand and value creating activities. The BCM
Process involves reducing Risks to an acceptable level and planning for the recovery of
Business Processes should a disruption to the Business occur. BCM sets the Objectives,
Scope and Requirements for IT Service Continuity Management.
Business Continuity Plan (BCP) (Service Design) A Plan defining the steps required to
Restore Business Processes following a disruption. The Plan will also identify the triggers
for Invocation, people to be involved, communications etc. IT Service Continuity Plans
form a significant part of Business Continuity Plans.
Business Customer (Service Strategy) A recipient of a product or a Service from the
Business. For example if the Business is a car manufacturer then the Business Customer is
someone who buys a car.
Business Impact Analysis (BIA) (Service Strategy) BIA is the Activity in Business
Continuity Management that identifies Vital Business Functions and their dependencies.
These dependencies may include Suppliers, people, other Business Processes, IT Services
etc. BIA defines the recovery requirements for IT Services. These requirements include
Recovery Time Objectives, Recovery Point Objectives and minimum Service Level
Targets for each IT Service.
Business Objective (Service Strategy) The Objective of a Business Process, or of the
Business as a whole. Business Objectives support the Business Vision, provide guidance
for the IT Strategy, and are often supported by IT Services.
Business Operations (Service Strategy) The day-to-day execution, monitoring and
management of Business Processes.
Business Perspective (Continual Service Improvement) An understanding of the Service
Provider and IT Services from the point of view of the Business, and an understanding of
the Business from the point of view of the Service Provider.
A-6
Business Process A Process that is owned and carried out by the Business. A Business
Process contributes to the delivery of a product or Service to a Business Customer. For
example, a retailer may have a purchasing Process which helps to deliver Services to their
Business Customers. Many Business Processes rely on IT Services.
Business Relationship Management (Service Strategy) The Process or Function
responsible for maintaining a Relationship with the Business. BRM usually includes:
Managing personal Relationships with Business managers
Providing input to Service Portfolio Management
Ensuring that the IT Service Provider is satisfying the Business needs of the
Customers This Process has strong links with Service Level Management.
Business Relationship Manager (BRM) (Service Strategy) A Role responsible for

maintaining the Relationship with one or more Customers. This Role is often combined
with the Service Level Manager Role. See Account Manager.
Business Service An IT Service that directly supports a Business Process, as opposed to an
Infrastructure Service which is used internally by the IT Service Provider and is not usually
visible to the Business. The term Business Service is also used to mean a Service that is
delivered to Business Customers by Business Units. For example delivery of financial
services to Customers of a bank, or goods to the Customers of a retail store. Successful
delivery of Business Services often depends on one or more IT Services.
Business Service Management (BSM) (Service Strategy) (Service Design) An approach
to the management of IT Services that considers the Business Processes supported and the
Business value provided. This term also means the management of Business Services
delivered to Business Customers.
Business Unit (Service Strategy) A segment of the Business which has its own Plans,
Metrics, income and Costs. Each Business Unit owns Assets and uses these to create value
for Customers in the form of goods and Services.
Call (Service Operation) A telephone call to the Service Desk from a User. A Call could
result in an Incident or a Service Request being logged.
Call Center (Service Operation) An Organization. or Business Unit which handles large
numbers of incoming and outgoing telephone calls. See Service Desk.
Call Type (Service Operation) A Category that is used to distinguish incoming requests to
a Service Desk. Common Call Types are Incident, Service Request and Complaint.
Capability (Service Strategy) The ability of an Organization., person, Process,
Application, Configuration Item or IT Service to carry out an Activity. Capabilities are
intangible Assets of an Organization. See Resource.
Capability Maturity Model (CMM) (Continual Service Improvement) The Capability
Maturity Model for Software (also known as the CMM and SW-CMM) is a model used to
A-7
identify Best Practices to help increase Process Maturity. CMM was developed at the
Software Engineering Institute (SEI) of Carnegie Mellon University. In 2000, the SWCMM was upgraded to CMMI (Capability Maturity Model Integration). The SEI no
longer maintains the SW-CMM model, its associated appraisal methods, or training
materials.
Capability Maturity Model Integration (CMMI) (Continual Service Improvement)
Capability Maturity Model Integration (CMMI) is a process improvement approach
developed by the Software Engineering Institute (SEI) of Carnegie Melon University.
CMMI provides organizations with the essential elements of effective processes. It can be
used to guide process improvement across a project, a division, or an entire organization.
CMMI helps integrate traditionally separate organizational functions, set process
improvement goals and priorities, provide guidance for quality processes, and provide a
point of reference for appraising current processes. See http://www.sei.cmu.edu/cmmi/ for
more information. See CMM, Continuous Improvement, Maturity.
Capacity (Service Design) The maximum Throughput that a Configuration Item or IT
Service can deliver whilst meeting agreed Service Level Targets. For some types of CI,
Capacity may be the size or volume, for example a disk drive.
Capacity Management (Service Design) The Process responsible for ensuring that the
Capacity of IT Services and the IT Infrastructure is able to deliver agreed Service Level
Targets in a Cost Effective and timely manner. Capacity Management considers all
Resources required to deliver the IT Service, and plans for short, medium and long term
Business Requirements.
Capacity Management Information System (CMIS) (Service Design) A virtual
repository of all Capacity Management data, usually stored in multiple physical locations.
See Service Knowledge Management System.
Capacity Plan (Service Design) A Capacity Plan is used to manage the Resources required
to deliver IT Services. The Plan contains scenarios for different predictions of Business
demand, and costed options to deliver the agreed Service Level Targets.
Capacity Planning (Service Design) The Activity within Capacity Management
responsible for creating a Capacity Plan.
Capital Expenditure (CAPEX) (Service Strategy) The Cost of purchasing something that
will become a financial Asset, for example computer equipment and buildings. The value
of the Asset is Depreciated over multiple accounting periods.
Capital Item (Service Strategy) An Asset that is of interest to Financial Management
because it is above an agreed financial value.
Capitalization (Service Strategy) Identifying major Cost as capital, even though no Asset
is purchased. This is done to spread the impact of the Cost over multiple accounting
periods. The most common example of this is software development, or purchase of a
software license.
A-8
Category A named group of things that have something in common. Categories are used
to group similar things together. For example Cost Types are used to group similar types of
Cost. Incident Categories are used to group similar types of Incident, CI Types are used to
group similar types of Configuration Item.
Certification Issuing a certificate to confirm Compliance to a Standard. Certification
includes a formal Audit by an independent and Accredited body. The term Certification is
also used to mean awarding a certificate to verify that a person has achieved a qualification.
Change (Service Transition) The addition, modification or removal of anything that could
have an effect on IT Services. The Scope should include all IT Services, Configuration
Items, Processes, Documentation etc.
Change Advisory Board (CAB) (Service Transition) A group of people that advises the
Change Manager in the Assessment, prioritization and scheduling of Changes. This board
is usually made up of representatives from all areas within the IT Service Provider, the
Business, and Third Parties such as Suppliers.
Change Case (Service Operation) A technique used to predict the impact of proposed
Changes. Change Cases use specific scenarios to clarify the scope of proposed Changes and
to help with Cost Benefit Analysis. See Use Case.
Change History (Service Transition) Information about all changes made to a
Configuration Item during its life. Change History consists of all those Change Records that
apply to the CI.
Change Management (Service Transition) The Process responsible for controlling the
Lifecycle of all Changes. The primary objective of Change Management is to enable
beneficial Changes to be made, with minimum disruption to IT Services.
Change Model (Service Transition) A repeatable way of dealing with a particular Category
of Change. A Change Model defines specific pre-defined steps that will be followed for a
Change of this Category. Change Models may be very simple, with no requirement for
approval (e.g. Password Reset) or may be very complex with many steps that require
approval (e.g. major software Release). See Standard Change, Change Advisory Board.
Change Record (Service Transition) A Record containing the details of a Change. Each
Change Record documents the Lifecycle of a single Change. A Change Record is created
for every Request for Change that is received, even those that are subsequently rejected.
Change Records should reference the Configuration Items that are affected by the Change.
Change Records are stored in the Configuration Management System.
Change Request Synonym for Request for Change.
Change Schedule (Service Transition) A Document that lists all approved Changes and
their planned implementation dates. A Change Schedule is sometimes called a Forward
Schedule of Change, even though it also contains information about Changes that have
already been implemented.
A-9
Change Window (Service Transition) A regular, agreed time when Changes or Releases
may be implemented with minimal impact on Services. Change Windows are usually
documented in SLAs.
Charging (Service Strategy) Requiring payment for IT Services. Charging for IT Services
is optional, and many Organizations. choose to treat their IT Service Provider as a Cost
Center.
Chronological Analysis (Service Operation) A technique used to help identify possible
causes of Problems. All available data about the Problem is collected and sorted by date and
time to provide a detailed timeline. This can make it possible to identify 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 and Relationships for a Configuration Record. Common
CI Types include: hardware, Document, User etc.
Classification The act of assigning a Category to something. Classification is used to
ensure consistent management and reporting. CIs, Incidents, Problems, Changes etc. are
usually classified.
Client A generic term that means a Customer, the Business or a Business Customer. For
example Client Manager may be used as a synonym for Account Manager. The term client
is also used to mean:
A computer that is used directly by a User, for example a PC, Handheld

Computer, or Workstation.
The part of a Client-Server Application that the User directly interfaces with. For
example an email Client.
Closed (Service Operation) The final Status in the Lifecycle of an Incident, Problem,
Change etc. When the Status is Closed, no further action is taken.
Closure (Service Operation) The act of changing the Status of an Incident, Problem,
Change etc. to Closed.
COBIT (Continual Service Improvement) Control Objectives for Information and related
Technology (COBIT) provides guidance and Best Practice for the management of IT
Processes. COBIT is published by the IT Governance Institute. See http://www.isaca.org/
for more information.
Code of Practice A Guideline published by a public body or a Standards Organization.,
such as ISO or BSI. Many Standards consist of a Code of Practice and a Specification. The
Code of Practice describes recommended Best Practice.
Cold Standby Synonym for Gradual Recovery.
Commercial off the Shelf (COTS) (Service Design) Application software or Middleware
that can be purchased from a Third Party.
A-10
Compliance Ensuring that a Standard or set of Guidelines is followed, or that proper,

consistent accounting or other practices are being employed.
Component A general term that is used to mean one part of something more complex. For
example, a computer System may be a component of an IT Service, an Application may be
a Component of a Release Unit. Components that need to be managed should be
Configuration Items.
Component Capacity Management (CCM) (Service Design) (Continual Service
Improvement) The Process responsible for understanding the Capacity, Utilization, and
Performance of Configuration Items. Data is collected, recorded and analyzed for use in the
Capacity Plan. See Service Capacity Management.
Component CI (Service Transition) A Configuration Item that is part of an Assembly. For
example, a CPU or Memory CI may be part of a Server CI.
Component Failure Impact Analysis (CFIA) (Service Design) A technique that helps to
identify the impact of CI failure on IT Services. A matrix is created with IT Services on one
edge and CIs on the other. This enables the identification of critical CIs (that could cause
the failure of multiple IT Services) and of fragile IT Services (that have multiple Single
Points of Failure).
Computer Telephony Integration (CTI) (Service Operation) CTI is a general term
covering any kind of integration between computers and telephone Systems. It is most
commonly used to refer to Systems where an Application displays detailed screens relating
to incoming or outgoing telephone calls. See Automatic Call Distribution, Interactive
Voice Response.
Concurrency A measure of the number of Users engaged in the same Operation at the
same time.
Confidentiality (Service Design) A security principle that requires that data should only be
accessed by authorized people.
Configuration (Service Transition) A generic term, used to describe a group of
Configuration Items that work together to deliver an IT Service, or a recognizable part of
an IT Service. Configuration is also used to describe the parameter settings for one or more
CIs.
Configuration Baseline (Service Transition) A Baseline of a Configuration that has been
formally agreed and is managed through the Change Management process. A
Configuration Baseline is used as a basis for future Builds, Releases and Changes.
Configuration Control (Service Transition) The Activity responsible for ensuring that
adding, modifying or removing a CI is properly managed, for example by submitting a
Request for Change or Service Request.
Configuration Identification (Service Transition) The Activity responsible for collecting
information about Configuration Items and their Relationships, and loading this
A-11
information into the CMDB. Configuration Identification is also responsible for labeling
the CIs themselves, so that the corresponding Configuration Records can be found.
Configuration Item (CI) (Service Transition) Any Component that needs to be managed
in order to deliver an IT Service. Information about each CI is recorded in a Configuration
Record within the Configuration Management System and is maintained throughout its
Lifecycle by Configuration Management. CIs are under the control of Change
Management. CIs typically include IT Services, hardware, software, buildings, people, and
formal documentation such as Process documentation and SLAs.
Configuration Management (Service Transition) The Process responsible for
maintaining information about Configuration Items required to deliver an IT Service,
including their Relationships. This information is managed throughout the Lifecycle of the
CI. Configuration Management is part of an overall Service Asset and Configuration
Management Process.
Configuration Management Database (CMDB) Service Transition) A database used to
store Configuration Records throughout their Lifecycle. The Configuration Management
System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and
Relationships with other CIs.
Configuration Management System (CMS) (Service Transition) A set of tools and
databases that are used to manage an IT Service Provider's Configuration data. The CMS
also includes information about Incidents, Problems, Known Errors, Changes and
Releases; and may contain data about employees, Suppliers, locations, Business Units,
Customers and Users. The CMS includes tools for collecting, storing, managing, updating,
and presenting data about all Configuration Items and their Relationships. The CMS is
maintained by Configuration Management and is used by all IT Service Management
Processes. See Configuration Management Database, Service Knowledge Management
System.
Configuration Record (Service Transition) A Record containing the details of a
Configuration Item. Each Configuration Record documents the Lifecycle of a single CI.
Configuration Records are stored in a Configuration Management Database.
Configuration Structure (Service Transition) The hierarchy and other Relationships
between all the Configuration Items that comprise a Configuration.
Continual Service Improvement (CSI) (Continual Service Improvement) A stage in the
Lifecycle of an IT Service and the title of one of the Core ITIL publications. Continual
Service Improvement is responsible for managing improvements to IT Service
Management Processes and IT Services. The Performance of the IT Service Provider is
continually measured and improvements are made to Processes, IT Services and IT
Infrastructure in order to increase Efficiency, Effectiveness, and Cost Effectiveness. See
Plan-Do-Check-Act.
Continuous Availability (Service Design) An approach or design to achieve 100%
Availability. A Continuously Available IT Service has no planned or unplanned Downtime.
A-12
Continuous Operation (Service Design) An approach or design to eliminate planned

Downtime of an IT Service. Note that individual Configuration Items may be down even
though the IT Service is Available.
Contract A legally binding Agreement between two or more parties.
Contract Portfolio (Service Strategy) A database or structured Document used to manage
Service Contracts or Agreements between an IT Service Provider and their Customers.
Each IT Service delivered to a Customer should have a Contract or other Agreement which
is listed in the Contract Portfolio. See Service Portfolio, Service Catalogue.
Control A means of managing a Risk, ensuring that a Business Objective is achieved, or
ensuring that a Process is followed. Example Controls include Policies, Procedures, Roles,
RAID, door-locks etc. A control is sometimes called a Countermeasure or safeguard.
Control also means to manage the utilization or behavior of a Configuration Item, System
or IT Service.
Control Objectives for Information and related Technology (COBIT) See COBIT.
Control Perspective (Service Strategy) An approach to the management of IT Services,
Processes, Functions, Assets etc. There can be several different Control Perspectives on the
same IT Service, Process etc., allowing different individuals or teams to focus on what is
important and relevant to their specific Role. Example Control Perspectives include
Reactive and Proactive management within IT Operations, or a Lifecycle view for an
Application Project team.
Control Processes The ISO/IEC 20000 Process group that includes Change Management
and Configuration Management.
Core Service (Service Strategy) An IT Service that delivers basic Outcomes desired by one
or more Customers. See Supporting Service, Core Service Package.
Core Service Package (CSP) (Service Strategy) A detailed description of a Core Service
that may be shared by two or more Service Level Packages. See Service Package.
Cost The amount of money spent on a specific Activity, IT Service, or Business Unit. Costs
consist of real cost (money), notional cost such as people's time, and Depreciation.
Cost Benefit Analysis An Activity that analyses and compares the Costs and the benefits
involved in one or more alternative courses of action. See Business Case, Net Present
Value, Internal Rate of Return, Return on Investment, Value on Investment.
Cost Center (Service Strategy) A Business Unit or Project to which Costs are assigned. A
Cost Center does not charge for Services provided. An IT Service Provider can be run as a
Cost Center or a Profit Center
Cost Effectiveness A measure of the balance between the Effectiveness and Cost of a
Service, Process or activity, A Cost Effective Process is one which achieves its Objectives
at minimum Cost. See KPI, Return on Investment, Value for Money.
A-13
Cost Element (Service Strategy) The middle level of category to which Costs are assigned
in Budgeting and Accounting. The highest level category is Cost Type. For example a Cost
Type of people? could have cost elements of payroll, staff benefits, expenses, training,
overtime etc. Cost Elements can be further broken down to give Cost Units. For example
the Cost Element expenses? could include Cost Units of Hotels, Transport, Meals etc.
Cost Management (Service Strategy) A general term that is used to refer to Budgeting and
Accounting, sometimes used as a synonym for Financial Management
Cost Type (Service Strategy) The highest level of category to which Costs are assigned in
Budgeting and Accounting. For example hardware, software, people, accommodation,
external and Transfer. See Cost Element, Cost Type.
Cost Unit (Service Strategy) The lowest level of category to which Costs are assigned,
Cost Units are usually things that can be easily counted (e.g. staff numbers, software
licenses) or things easily measured (e.g. CPU usage, Electricity consumed). Cost Units are
included within Cost Elements. For example a Cost Element of expenses? could include
Cost Units of Hotels, Transport, Meals etc. See Cost Type.
Countermeasure Can be used to refer to any type of Control. The term Countermeasure
is most often used when referring to measures that increase Resilience, Fault Tolerance or
Reliability of an IT Service.
Course Corrections Changes made to a Plan or Activity that has already started, to ensure
that it will meet its Objectives. Course corrections are made as a result of Monitoring
progress.
CRAMM A methodology and tool for analyzing and managing Risks. CRAMM was
developed by the UK Government, but is now privately owned. Further information is
available from http://www.cramm.com/
Crisis Management The Process responsible for managing the wider implications of
Business Continuity. A Crisis Management team is responsible for Strategic issues such as
managing media relations and shareholder confidence, and decides when to invoke
Business Continuity Plans.
Critical Success Factor (CSF) Something that must happen if a Process, Project, Plan, or
IT Service is to succeed. KPIs are used to measure the achievement of each CSF. For
example a CSF of "protect IT Services when making Changes" could be measured by KPIs
such as "percentage reduction of unsuccessful Changes", "percentage reduction in Changes
causing Incidents" etc.
Culture A set of values that is shared by a group of people, including expectations about
how people should behave, ideas, beliefs, and practices. See Vision.
Customer Someone who buys goods or Services. The Customer of an IT Service Provider
is the person or group who defines and agrees the Service Level Targets. The term
Customers is also sometimes informally used to mean Users, for example "this is a
Customer focused Organization.".
A-14
Customer Portfolio (Service Strategy) A database or structured Document used to record

all Customers of the IT Service Provider. The Customer Portfolio is the Business
Relationship Manager's view of the Customers who receive Services from the IT Service
Provider. See Contract Portfolio, Service Portfolio.
Dashboard (Service Operation) A graphical representation of overall IT Service
Performance and Availability. Dashboard images may be updated in real-time, and can also
be included in management reports and web pages. Dashboards can be used to support
Service Level Management, Event Management or Incident Diagnosis.
Data-to-Information-to-Knowledge-to-Wisdom (DIKW) A way of understanding the
relationships between data, information, knowledge, and wisdom. DIKW shows how each
of these builds on the others.
Definitive Media Library (DML) (Service Transition) One or more locations in which the
definitive and approved versions of all software Configuration Items are securely stored.
The DML may also contain associated CIs such as licenses and documentation. The DML
is a single logical storage area even if there are multiple locations. All software in the DML
is under the control of Change and Release Management and is recorded in the
Configuration Management System. Only software from the DML is acceptable for use in
a Release.
Deliverable Something that must be provided to meet a commitment in a Service Level
Agreement or a Contract. Deliverable is also used in a more informal way to mean a
planned output of any Process.
Demand Management Activities that understand and influence Customer demand for
Services and the provision of Capacity to meet these demands. At a Strategic level Demand
Management can involve analysis of Patterns of Business Activity and User Profiles. At a
Tactical level it can involve use of Differential Charging to encourage Customers to use IT
Services at less busy times. See Capacity Management.
Deming Cycle Synonym for Plan Do Check Act.
Dependency The direct or indirect reliance of one Process or Activity upon another.
Deployment (Service Transition) The Activity responsible for movement of new or
changed hardware, software, documentation, Process, etc to the Live Environment.
Deployment is part of the Release and Deployment Management Process. See Rollout.
Depreciation (Service Strategy) A measure of the reduction in value of an Asset over its
life. This is based on wearing out, consumption or other reduction in the useful economic
value.
Design (Service Design) An Activity or Process that identifies Requirements and then
defines a solution that is able to meet these Requirements. See Service Design.
Detection (Service Operation) A stage in the Incident Lifecycle. Detection results in the
Incident becoming known to the Service Provider. Detection can be automatic, or can be
the result of a User logging an Incident.
A-15
Development (Service Design) The Process responsible for creating or modifying an IT

Service or Application. Also used to mean the Role or group that carries out Development
work.
Development Environment (Service Design) An Environment used to create or modify IT
Services or Applications. Development Environments are not typically subjected to the
same degree of control as Test Environments or Live Environments. See Development.
Diagnosis (Service Operation) A stage in the Incident and Problem Lifecycles. The
purpose of Diagnosis is to identify a Workaround for an Incident or the Root Cause of a
Problem.
Diagnostic Script (Service Operation) A structured set of questions used by Service 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 to help them diagnose
and resolve their own Incidents.
Differential Charging A technique used to support Demand Management by charging
different amounts for the same IT Service Function at different times.
Direct Cost (Service Strategy) A cost of providing an IT Service which can be allocated
in full to a specific Customer, Cost Center, Project etc. For example cost of providing nonshared servers or software licenses. See Indirect Cost.
Directory Service (Service Operation) An Application that manages information about IT
Infrastructure available on a network, and corresponding User access Rights.
Do Nothing (Service Design) A Recovery Option. The Service Provider formally agrees
with the Customer that Recovery of this IT Service will not be performed.
Document Information in readable form. A Document may be paper or electronic. For
example a Policy statement, Service Level Agreement, Incident Record, diagram of
computer room layout. See Record.
Downtime (Service Design) (Service Operation) The time when a Configuration Item or
IT Service is not Available during its Agreed Service Time. The Availability of an IT
Service is often calculated from Agreed Service Time and Downtime.
Driver Something that influences Strategy, Objectives or Requirements. For example new
legislation or the actions of competitors.
Early Life Support (Service Transition) Support provided for a new or Changed IT
Service for a period of time after it is Released. During Early Life Support the IT Service
Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide
additional Resources for Incident and Problem Management.
Economies of scale (Service Strategy) The reduction in average Cost that is possible from
increasing the usage of an IT Service or Asset. See Economies of Scope.
A-16
Economies of scope (Service Strategy) The reduction in Cost that is allocated to an IT

Service by using an existing Asset for an additional purpose. For example delivering a new
IT
Effectiveness (Continual Service Improvement) A measure of whether the Objectives of a
Process, Service or Activity have been achieved. An Effective Process or Activity is one
that achieves its agreed Objectives. See KPI.
Efficiency (Continual Service Improvement) A measure of whether the right amount of
resources have been used to deliver a Process, Service or Activity. An Efficient Process
achieves its Objectives with the minimum amount of time, money, people or other
resources. See KPI.
Emergency Change (Service Transition) A Change that must be introduced as soon as
possible. For example to resolve a Major Incident or implement a Security patch. The
Change Management Process will normally have a specific Procedure for handling
Emergency Changes. See Emergency Change Advisory Board (ECAB).
Emergency Change Advisory Board (ECAB) (Service Transition) A sub-set of the
Change Advisory Board who make decisions about high impact Emergency Changes.
Membership of the ECAB may be decided at the time a meeting is called, and depends on
the nature of the Emergency Change.
Environment (Service Transition) A subset of the IT Infrastructure that is used for a
particular purpose. For Example: Live Environment, Test Environment, Build
Environment. It is possible for multiple Environments to share a Configuration Item, for
example Test and Live Environments may use different partitions on a single mainframe
computer. Also used in the term Physical Environment to mean the accommodation, air
conditioning, power system etc. Environment is also used as a generic term to mean the
external conditions that influence or affect something.
Error (Service Operation) A design flaw or malfunction that causes a Failure of one or
more Configuration Items or IT Services. A mistake made by a person or a faulty Process
that impacts a CI or IT Service is also an Error.
Escalation (Service Operation) An Activity that obtains additional Resources when these
are needed to meet Service Level Targets or Customer expectations. Escalation may be
needed within any IT Service Management Process, but is most commonly associated with
Incident Management, Problem Management and the management of Customer
complaints. There are two types of Escalation, Functional Escalation and Hierarchic
Escalation.
eSourcing Capability Model for Client Organizations (eSCM-CL) (Service Strategy) A
framework to help Organizations. guide their analysis and decisions on Service Sourcing
Models and Strategies. eSCM-CL was developed by Carnegie Mellon University. See
eSCM-SP.
eSourcing Capability Model for Service Providers (eSCM-SP) (Service Strategy) A
framework to help IT Service Providers develop their IT Service Management Capabilities
A-17
from a Service Sourcing perspective. eSCM-SP was developed by Carnegie Mellon

University. See eSCM-CL.
Estimation The use of experience to provide an approximate value for a Metric or Cost.
Estimation is also used in Capacity and Availability Management as the cheapest and least
accurate Modeling method.
Evaluation (Service Transition) The Process responsible for assessing a new or Changed
IT Service to ensure that Risks have been managed and to help determine whether to
proceed with the Change. Evaluation is also used to mean comparing an actual Outcome
with the intended Outcome, or comparing one alternative with another.
Event (Service Operation) A change of state which has significance for the management of
a Configuration Item or IT Service. The term Event is also used to mean an Alert or
notification created by any IT Service, Configuration Item or Monitoring tool. Events
typically require IT Operations personnel to take actions, and often lead to Incidents being
logged.
Event Management (Service Operation) The Process responsible for managing Events
throughout their Lifecycle. Event Management is one of the main Activities of IT
Operations.
Exception Report A Document containing details of one or more KPIs or other important
targets that have exceeded defined Thresholds. Examples include SLA targets being missed
or about to be missed, and a Performance Metric indicating a potential Capacity problem.
Expanded Incident Lifecycle (Availability Management) Detailed stages in the Lifecycle
of an Incident. The stages are Detection, Diagnosis, Repair, Recovery, Restoration. The
Expanded Incident Lifecycle is used to help understand all contributions to the Impact of
Incidents and to Plan how these could be controlled or reduced.
External Customer A Customer who works for a different Business to the IT Service
Provider. See External Service Provider, Internal Customer.
External Metric A Metric that is used to measure the delivery of IT Service to a Customer.
External Metrics are usually defined in SLAs and reported to Customers. See Internal
Metric.
External Service Provider (Service Strategy) An IT Service Provider which is part of a
different Organization. to their Customer. An IT Service Provider may have both Internal
Customers and External Customers. See Type III Service Provider.
External Sourcing Synonym for Outsourcing.
Facilities Management (Service Operation) The Function responsible for managing the
physical Environment where the IT Infrastructure is located. Facilities Management
includes all aspects of managing the physical Environment, for example power and cooling,
building Access Management, and environmental Monitoring.
A-18
Failure (Service Operation) Loss of ability to Operate to Specification, or to deliver the

required output. The term Failure may be used when referring to IT Services, Processes,
Activities, Configuration Items etc. A Failure often causes an Incident.
Failure Modes and Effects Analysis (FMEA) An approach to assessing the potential
Impact of Failures. FMEA involves analyzing what would happen after Failure of each
Configuration Item, all the way up to the effect on the Business. FMEA is often used in
Information Security Management and in IT Service Continuity Planning.
Fast Recovery (Service Design) A Recovery Option which is also known as Hot Standby.
Provision is made to Recover the IT Service in a short period of time, typically less than 24
hours. Fast Recovery typically uses a dedicated Fixed Facility with computer Systems, and
software configured ready to run the IT Services. Immediate Recovery may take up to 24
hours if there is a need to Restore data from Backups.
Fault Synonym for Error.
Fault Tolerance (Service Design) The ability of an IT Service or Configuration Item to
continue to Operate correctly after Failure of a Component part. See Resilience,
Countermeasure.
Fault Tree Analysis (FTA) (Service Design) (Continual Service Improvement) A
technique that can be used to determine the chain of Events that leads to a Problem. Fault
Tree Analysis represents a chain of Events using Boolean notation in a diagram.
Financial Management (Service Strategy) The Function and Processes responsible for
managing an IT Service Provider's Budgeting, Accounting and Charging Requirements.
First-line Support (Service Operation) The first level in a hierarchy of Support Groups
involved in the resolution of Incidents. Each level contains more specialist skills, or has
more time or other Resources. See Escalation.
Fishbone Diagram Synonym for Ishikawa Diagram.
Fit for Purpose An informal term used to describe a Process, Configuration Item, IT
Service etc. that is capable of meeting its Objectives or Service Levels. Being Fit for
Purpose requires suitable Design, implementation, Control and maintenance.
Fixed Cost (Service Strategy) A Cost that does not vary with IT Service usage. For
example the cost of Server hardware. See Variable Cost.
Fixed Facility (Service Design) A permanent building, available for use when needed by
an IT Service Continuity Plan. See Recovery Option, Portable Facility.
Follow the Sun (Service Operation) A methodology for using Service Desks and Support
Groups around the world to provide seamless 24 * 7 Service. Calls, Incidents, Problems and
Service Requests are passed between groups in different time zones.
Fulfillment Performing Activities to meet a need or Requirement. For example by
providing a new IT Service, or meeting a Service Request.
A-19
Function A team or group of people and the tools they use to carry out one or more
Processes or Activities. For example the Service 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 Function of an Email Service may be to store and
forward outgoing mails, one Function of a Business Process may be to dispatch
goods to Customers.
To perform the intended purpose correctly, "The computer is Functioning"
Functional Escalation (Service Operation) Transferring an Incident, Problem or Change

to a technical team with a higher level of expertise to assist in an Escalation.
Gap Analysis (Continual Service Improvement) An Activity which compares two sets of
data and identifies the differences. Gap Analysis is commonly used to compare a set of
Requirements with actual delivery. See Benchmarking.
Governance Ensuring that Policies and Strategy are actually implemented, and that
required Processes are correctly followed. Governance includes defining Roles and
responsibilities, measuring and reporting, and taking actions to resolve any issues
identified.
Gradual Recovery (Service Design) A Recovery Option which is also known as Cold
Standby. Provision is made to Recover the IT Service in a period of time greater than 72
hours. Gradual Recovery typically uses a Portable or Fixed Facility that has environmental
support and network cabling, but no computer Systems. The hardware and software are
installed as part of the IT Service Continuity Plan.
Guideline A Document describing Best Practice, that recommends what should be done.
Compliance to a guideline is not normally enforced. See Standard.
Help Desk (Service Operation) A point of contact for Users to log Incidents. A Help Desk
is usually more technically focused than a Service Desk and does not provide a Single Point
of Contact for all interaction. The term Help Desk is often used as a synonym for Service
Desk.
Hierarchic Escalation (Service Operation) Informing or involving more senior levels of
management to assist in an Escalation.
High Availability (Service Design) An approach or Design that minimizes or hides the
effects of Configuration Item Failure on the Users of an IT Service. High Availability
solutions are Designed to achieve an agreed level of Availability and make use of
techniques such as Fault Tolerance, Resilience and fast Recovery to reduce the number of
Incidents, and the Impact of Incidents.
Hot Standby Synonym for Fast Recovery or Immediate Recovery.
A-20
Identity (Service Operation) A unique name that is used to identify a User, person or Role.
The Identity is used to grant Rights to that User, person, or Role. Example identities might
be the username SmithJ or the Role "Change manager".
Immediate Recovery (Service Design) A Recovery Option which is also known as Hot
Standby. Provision is made to Recover the IT Service with no loss of Service. Immediate
Recovery typically uses mirroring, load balancing and split site technologies.
Impact (Service Operation) (Service Transition) A measure of the effect of an Incident,
Problem or Change on Business Processes. Impact is often based on how Service Levels
will be affected. Impact and Urgency are used to assign Priority.
Incident (Service Operation) An unplanned interruption to an IT Service or a reduction in
the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted
Service is also an Incident. For example Failure of one disk from a mirror set.
Incident Management (Service Operation) The Process responsible for managing the
Lifecycle of all Incidents. The primary Objective of Incident Management is to return the
IT Service to Users as quickly as possible.
Incident Record (Service Operation) A Record containing the details of an Incident. Each
Incident record documents the Lifecycle of a single Incident.
Indirect Cost (Service Strategy) A Cost of providing an IT Service which cannot be
allocated in full to a specific Customer. For example Cost of providing shared Servers or
software licenses. Also known as Overhead. See Direct Cost.
Information Security Management (ISM) (Service Design) The Process that ensures the
Confidentiality, Integrity and Availability of an Organization.'s Assets, information, data
and IT Services. Information Security Management usually forms part of an Organizational
approach to Security Management which has a wider scope than the IT Service Provider,
and includes handling of paper, building access, phone calls etc., for the entire
Organization.
Information Security Management System (ISMS) (Service Design) The framework of
Policy, Processes, Standards, Guidelines and tools that ensures an Organization. can
achieve its Information Security Management Objectives.
Information Security Policy (Service Design) The Policy that governs the
Organization.s approach to Information Security Management.
Information Technology (IT) The use of technology for the storage, communication or
processing of information. The technology typically includes computers,
telecommunications, Applications and other software. The information may include
Business data, voice, images, video, etc. Information Technology is often used to support
Business Processes through IT Services.
Infrastructure Service An IT Service that is not directly used by the Business, but is
required by the IT Service Provider so they can provide other IT Services. For example
Directory Services, naming services, or communication services.
A-21
Insourcing Synonym for Internal Sourcing.

Integrity (Service Design) A security principle that ensures data and Configuration Items
are only modified by authorized personnel and Activities. Integrity considers all possible
causes of modification, including software and hardware Failure, environmental Events,
and human intervention.
Interactive Voice Response (IVR) (Service Operation) A form of Automatic Call
Distribution that accepts User input, such as key presses and spoken commands, to identify
the correct destination for incoming Calls.
Intermediate Recovery (Service Design) A Recovery Option which is also known as
Warm Standby. Provision is made to Recover the IT Service in a period of time between
24 and 72 hours. Intermediate Recovery typically uses a shared Portable or Fixed Facility
that has computer Systems and network Components. The hardware and software will need
to be configured, and data will need to be restored, as part of the IT Service Continuity Plan.
Internal Customer A Customer who works for the same Business as the IT Service
Provider. See Internal Service Provider, External Customer.
Internal Metric A Metric that is used within the IT Service Provider to Monitor the
Efficiency, Effectiveness or Cost Effectiveness of the IT Service Provider's internal
Processes. Internal Metrics are not normally reported to the Customer of the IT Service. See
External Metric.
Internal Rate of Return (IRR) (Service Strategy) A technique used to help make
decisions about Capital Expenditure. IRR calculates a figure that allows two or more
alternative investments to be compared. A larger IRR indicates a better investment. See Net
Present Value, Return on Investment.
Internal Service Provider (Service Strategy) An IT Service Provider which is part of the
same Organization. as their Customer. An IT Service Provider may have both Internal
Customers and External Customers. See Type I Service Provider, Type II Service Provider,
Insource.
Internal Sourcing (Service Strategy) Using an Internal Service Provider to manage IT
Services. See Service Sourcing, Type I Service Provider, Type II Service Provider.
International Organization for Standardization (ISO) The International Organization for
Standardization (ISO) is the world's largest developer of Standards. ISO is a nongovernmental organization which is a network of the national standards institutes of 156
countries. Further information about ISO is available from http://www.iso.org/
International Standards Organization. See International Organization for
Standardization (ISO)
Internet Service Provider (ISP) An External Service Provider that provides access to the
Internet. Most ISPs also provide other IT Services such as web hosting.
A-22
Invocation (Service Design) Initiation of the steps defined in a plan. For example initiating
the IT Service Continuity Plan for one or more IT Services.
Ishikawa Diagram (Service Operation) (Continual Service Improvement) A technique
that helps a team to identify all the possible causes of a Problem. Originally devised by
Kaoru Ishikawa, the output of this technique is a diagram that looks like a fishbone.
ISO 9000 A generic term that refers to a number of international Standards and Guidelines
for Quality Management Systems. See http://www.iso.org/ for more information. See ISO.
ISO 9001 An international Standard for Quality Management Systems. See ISO 9000,
Standard.
ISO/IEC 17799 (Continual Service Improvement) ISO Code of Practice for Information
Security Management. See Standard.
ISO/IEC 20000 ISO Specification and Code of Practice for IT Service Management. ISO/
IEC 20000 is aligned with ITIL Best Practice.
ISO/IEC 27001 (Service Design) (Continual Service Improvement) ISO Specification for
Information Security Management. The corresponding Code of Practice is ISO/IEC 17799.
See Standard.
IT Directorate (Continual Service Improvement) Senior Management within a Service
Provider, charged with developing and delivering IT services. Most commonly used in UK
Government departments.
IT Infrastructure All of the hardware, software, networks, facilities etc. that are required
to Develop, Test, deliver, Monitor, Control or support IT Services. The term IT
Infrastructure includes all of the Information Technology but not the associated people,
Processes and documentation.
IT Operations (Service Operation) Activities carried out by IT Operations Control,
including Console Management, Job Scheduling, Backup and Restore, and Print and
Output Management. IT Operations is also used as a synonym for Service Operation.
IT Operations Control (Service Operation) The Function responsible for Monitoring and
Control of the IT Services and IT Infrastructure. See Operations Bridge.
IT Operations Management (Service Operation) The Function within an IT Service
Provider which performs the daily Activities needed to manage IT Services and the
supporting IT Infrastructure. IT Operations Management includes IT Operations Control
and Facilities Management.
IT Service A Service provided to one or more Customers by an IT Service Provider. An IT
Service is based on the use of Information Technology and supports the Customer's
Business Processes. An IT Service is made up from a combination of people, Processes and
technology and should be defined in a Service Level Agreement.
A-23
IT Service Continuity Management (ITSCM) (Service Design) The Process responsible

for managing Risks that could seriously impact IT Services. ITSCM ensures that the IT
Service Provider can always provide minimum agreed Service Levels, by reducing the Risk
to an acceptable level and Planning for the Recovery of IT Services. ITSCM should be
designed to support Business Continuity Management.
IT Service Continuity Plan (Service Design) A Plan defining the steps required to
Recover one or more IT Services. The Plan will also identify the triggers for Invocation,
people to be involved, communications etc. The IT Service Continuity Plan should be part
of a Business Continuity Plan.
IT Service Management (ITSM) The implementation and management of Quality IT
Services that meet the needs of the Business. IT Service Management is performed by IT
Service Providers through an appropriate mix of people, Process and Information
Technology. See Service Management.
IT Service Management Forum (itSMF) The IT Service Management Forum is an
independent Organization. dedicated to promoting a professional approach to IT Service
Management. The itSMF is a not-for-profit membership Organization. with representation
in many countries around the world (itSMF Chapters). The itSMF and its membership
contribute to the development of ITIL and associated IT Service Management Standards.
See http://www.itsmf.com/ for more information.
IT Service Provider (Service Strategy) A Service Provider that provides IT Services to
Internal Customers or External Customers.
IT Steering Group (ISG) A formal group that is responsible for ensuring that Business
and IT Service Provider Strategies and Plans are closely aligned. An IT Steering Group
includes senior representatives from the Business and the IT Service Provider.
ITIL A set of Best Practice guidance for IT Service Management. ITIL is owned by the
OGC and consists of a series of publications giving guidance on the provision of Quality
IT Services, and on the Processes and facilities needed to support them. See http://
www.itil.co.uk/ for more information.
Job Description A Document which defines the Roles, responsibilities, skills and
knowledge required by a particular person. One Job Description can include multiple
Roles, for example the Roles of Configuration Manager and Change Manager may be
carried out by one person.
Job Scheduling (Service Operation) Planning and managing the execution of software
tasks that are required as part of an IT Service. Job Scheduling is carried out by IT
Operations Management, and is often automated using software tools that 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 that is used to help
understand Customer preferences. The Kano Model considers Attributes of an IT Service
grouped into areas such as Basic Factors, Excitement Factors, Performance Factors etc.
A-24
Kepner & Tregoe Analysis (Service Operation) (Continual Service Improvement) A

structured approach to Problem solving. The Problem is analyzed in terms of what, where,
when and extent. Possible causes are identified. The most probable cause is tested. The true
cause is verified.
Key Performance Indicator (KPI) (Continual Service Improvement) A Metric that is
used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but
only the most important of these are defined as KPIs and used to actively manage and report
on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency,
Effectiveness, and Cost Effectiveness are all managed. See Critical Success Factor.
Knowledge Base (Service Transition) A logical database containing the data used by the
Service Knowledge Management System.
Knowledge Management (Service Transition) The Process responsible for gathering,
analyzing, storing and sharing knowledge and information within an Organization. The
primary purpose of Knowledge Management is to improve Efficiency by reducing the need
to rediscover knowledge. See Data-to-Information-to-Knowledge-to-Wisdom, Service
Knowledge Management System.
Known Error (Service Operation) A Problem that has a documented Root Cause and a
Workaround. Known Errors are created and managed throughout their Lifecycle by
Problem Management. Known Errors may also be identified by Development or Suppliers.
Known Error Database (KEDB) (Service Operation) A database containing all Known
Error Records. This database is created by Problem Management and used by Incident and
Problem Management. The Known Error Database is part of the Service Knowledge
Management System.
Known Error Record (Service Operation) A Record containing the details of a Known
Error. Each Known Error Record documents the Lifecycle of a Known Error, including the
Status, Root Cause and Workaround. In some implementations a Known Error is
documented using additional fields in a Problem Record.
Lifecycle The various stages in the life of an IT Service, Configuration Item, Incident,
Problem, Change etc. The Lifecycle defines the Categories for Status and the Status
transitions 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.
A-25
Line of Service (LOS) (Service Strategy) A Core Service or Supporting Service that has
multiple Service Level Packages. A line of Service is managed by a Product Manager and
each Service Level Package is designed to support a particular market segment.
Live (Service Transition) Refers to an IT Service or Configuration Item that is being used
to deliver Service to a Customer.
Live Environment (Service Transition) A controlled Environment containing Live
Configuration Items used to deliver IT Services to Customers.
Maintainability (Service Design) A measure of how quickly and Effectively a
Configuration Item or IT Service can be restored to normal working after a Failure.
Maintainability is often measured and reported as MTRS. Maintainability is also used in
the context of Software or IT Service Development to mean ability to be Changed or
Repaired easily.
Major Incident (Service Operation) The highest Category of Impact for an Incident. A
Major Incident results in significant disruption to the Business.
Managed Services (Service Strategy) A perspective on IT Services which emphasizes the
fact that they are managed. The term Managed Services is also used as a synonym for
Outsourced IT Services.
Management Information Information that is used to support decision making by
managers. Management Information is often generated automatically by tools supporting
the various IT Service Management Processes. Management Information often includes the
values of KPIs such as "Percentage of Changes leading to Incidents", or "first time fix rate".
Management of Risk (MoR) The OGC methodology for managing Risks. MoR includes
all the Activities required to identify and Control the exposure to Risk which may have an
impact on the achievement of an Organization.s Business Objectives. See http://www.mo-r.org/ for more details.
Management System The framework of Policy, Processes and Functions that ensures an
Organization. can achieve its Objectives.
Manual Workaround A Workaround that requires manual intervention. Manual
Workaround is also used as the name of a Recovery Option in which The Business Process
Operates without the use of IT Services. This is a temporary measure and is usually
combined with another Recovery Option.
Marginal Cost (Service Strategy) The Cost of continuing to provide the IT Service.
Marginal Cost does not include investment already made, for example the cost of
developing new software and delivering training.
Market Space (Service Strategy) All opportunities that an IT Service Provider could
exploit to meet business needs of Customers. The Market Space identifies the possible IT
Services that an IT Service Provider may wish to consider delivering.
A-26
Maturity (Continual Service Improvement) A measure of the Reliability, Efficiency and

Effectiveness of a Process, Function, Organization. etc. The most mature Processes and
Functions are formally aligned to Business Objectives and Strategy, and are supported by
a framework for continual improvement.
Maturity Level A named level in a Maturity model such as the Carnegie Mellon
Capability Maturity Model Integration.
Mean Time Between Failures (MTBF) (Service Design) A Metric for measuring and
reporting Reliability. MTBF is the average time that a Configuration Item or IT Service can
perform its agreed Function without interruption. This is measured from when the CI or IT
Service starts working, until it next fails.
Mean Time Between Service Incidents (MTBSI) (Service Design) A Metric used for
measuring and reporting Reliability. MTBSI is the mean time from when a System or IT
Service fails, until it next fails. MTBSI is equal to MTBF + MTRS.
Mean Time To Repair (MTTR) The average time taken to repair a Configuration Item
or IT Service after a Failure. MTTR is measured from when the CI or IT Service fails until
it is Repaired. MTTR does not include the time required to Recover or Restore. MTTR is
sometimes incorrectly used to mean Mean Time to Restore Service.
Mean Time to Restore Service (MTRS) The average time taken to Restore a
Configuration Item or IT Service after a Failure. MTRS is measured from when the CI or
IT Service fails until it is fully Restored and delivering its normal functionality. See
Maintainability, Mean Time to Repair.
Metric (Continual Service Improvement) Something that is measured and reported to help
manage a Process, IT Service or Activity. See KPI.
Middleware (Service Design) Software that connects two or more software Components
or Applications. Middleware is usually purchased from a Supplier, rather than developed
within the IT Service Provider. See Off the Shelf.
Mission Statement The Mission Statement of an Organization. is a short but complete
description of the overall purpose and intentions of that Organization. It states what is to be
achieved, but not how this should be done.
Model A representation of a System, Process, IT Service, Configuration Item etc. that is
used to help understand or predict future behavior
Modeling A technique that is used to predict the future behavior of a System, Process, IT
Service, Configuration Item etc. Modeling 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 this output to a predefined norm; and taking
appropriate action based on this comparison.
A-27
Monitoring (Service Operation) Repeated observation of a Configuration Item, IT Service

or Process to detect Events and to ensure that the current status is known.
Near-Shore (Service Strategy) Provision of Services from a country near the country
where the Customer is based. This can be the provision of an IT Service, or of supporting
Functions such as Service Desk. See On-shore, Off-shore.
Net Present Value (NPV) (Service Strategy) A technique used to help make decisions
about Capital Expenditure. NPV compares cash inflows to cash outflows. Positive NPV
indicates that an investment is worthwhile. See 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 are informed of the charge, but no money is
actually transferred. Notional Charging is sometimes introduced to ensure that Customers
are aware of the Costs they incur, or as a stage during the introduction of real Charging.
Objective The defined purpose or aim of a Process, an Activity or an Organization. as a
whole. Objectives are usually expressed as measurable targets. The term Objective is also
informally used to mean a Requirement. See Outcome.
Off the Shelf Synonym for Commercial Off the Shelf.
Office of Government Commerce (OGC) OGC owns the ITIL brand (copyright and
trademark). OGC is a UK Government department that supports the delivery of the
government's procurement agenda through its work in collaborative procurement and in
raising levels of procurement skills and capability with departments. It also provides
support for complex public sector projects.
Office of Public Sector Information (OPSI) OPSI license the Crown Copyright material
used in the ITIL publications. They are a UK Government department who provide online
access to UK legislation, license the re-use of Crown copyright material, manage the
Information Fair Trader Scheme, maintain the Governments Information Asset Register
and provide advice and guidance on official publishing and Crown copyright.
Off-shore (Service Strategy) Provision of Services from a location outside the country
where the Customer is based, often in a different continent. This can be the provision of an
IT Service, or of supporting Functions such as Service Desk. See On-shore, Near-shore.
On-shore (Service Strategy) Provision of Services from a location within the country
where the Customer is based. See Off-shore, Near-shore.
Operate To perform as expected. A Process or Configuration Item is said 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 IT Service, System, or other
Configuration Item. Operation is also used to mean any pre-defined Activity or
A-28
Transaction. For example loading a magnetic tape, accepting money at a point of sale, or
reading data from a disk drive.
Operational The lowest of three levels of Planning and delivery (Strategic, Tactical,
Operational). Operational Activities include the day-to-day or short term Planning or
delivery of a Business Process or IT Service Management Process. The term Operational is
also a synonym for Live.
Operational Cost Cost resulting from running the IT Services. Often repeating payments.
For example staff costs, hardware maintenance and electricity (also known as "current
expenditure" or "revenue expenditure"). See Capital Expenditure.
Operational Expenditure (OPEX) Synonym for Operational Cost.
Operational Level Agreement (OLA) (Service Design) (Continual Service
Improvement) An Agreement between an IT Service Provider and another part of the same
Organization. An OLA supports the IT Service Provider's delivery of IT Services to
Customers. The OLA defines the goods or Services to be provided and the responsibilities
of both parties. For example there could be an OLA:
between the IT Service Provider and a procurement department to obtain

hardware in agreed times
between the Service Desk and a Support Group to provide Incident Resolution in
agreed times. See Service Level Agreement.
Operations Bridge (Service Operation) A physical location where IT Services and IT

Infrastructure are monitored and managed.
Operations Control Synonym for IT Operations Control.
Operations Management Synonym for IT Operations Management.
Opportunity Cost (Service Strategy) A Cost that is used in deciding between investment
choices. Opportunity Cost represents the revenue that would have been generated by using
the Resources in a different way. For example the Opportunity Cost of purchasing a new
Server may include not carrying out a Service Improvement activity that the money could
have been spent on. Opportunity cost analysis is used as part of a decision making
processes, but is not treated as an actual Cost in any financial statement.
Optimize Review, Plan and request Changes, in order to obtain the maximum Efficiency
and Effectiveness from a Process, Configuration Item, Application etc.
Organization. A company, legal entity or other institution. Examples of Organizations.
that are not companies include International Standards Organization. or itSMF. The term
Organization. is sometimes used to refer to any entity which has People, Resources and
Budgets. For example a Project or Business Unit.
A-29
Outcome The result of carrying out an Activity; following a Process; delivering an IT

Service etc. The term Outcome is used to refer to intended results, as well as to actual
results. See Objective.
Outsourcing (Service Strategy) Using an External Service Provider to manage IT
Services. See Service Sourcing, Type III Service Provider.
Overhead Synonym for Indirect cost
Pain Value Analysis (Service Operation) A technique used to help identify the Business
Impact of one or more Problems. A formula is used to calculate Pain Value based on the
number of Users affected, the duration of the Downtime, the Impact on each User, and the
cost to the Business (if known).
Pareto Principle (Service Operation) A technique used to prioritize Activities. The Pareto
Principle says that 80% of the value of any Activity is created with 20% of the effort. Pareto
Analysis is also used in Problem Management to prioritize possible Problem causes for
investigation.
Partnership A relationship between two Organizations. which involves working closely
together for common goals or mutual benefit. The IT Service Provider should have a
Partnership with the Business, and with Third Parties who are critical to the delivery of IT
Services. See Value Network.
Passive Monitoring (Service Operation) Monitoring of a Configuration Item, an IT
Service or a Process that relies on an Alert or notification to discover the current status. See
Active Monitoring.
Pattern of Business Activity (PBA) (Service Strategy) A Workload profile of one or more
Business Activities. Patterns of Business Activity are used to help the IT Service Provider
understand and plan for different levels of Business Activity. See User Profile.
Percentage Utilization (Service Design) The amount of time that a Component is busy
over a given period of time. For example, if a CPU is busy for 1800 seconds in a one hour
period, its utilization is 50%
Performance A measure of what is achieved or delivered by a System, person, team,
Process, or IT Service.
Performance Anatomy (Service Strategy) An approach to Organizational Culture that
integrates, and actively manages, leadership and strategy, people development, technology
enablement, performance management and innovation.
Performance Management (Continual Service Improvement) The Process responsible for
day-to-day Capacity Management Activities. These include Monitoring, Threshold
detection, Performance analysis and Tuning, and implementing Changes related to
Performance and Capacity.
A-30
Pilot (Service Transition) A limited Deployment of an IT Service, a Release or a Process

to the Live Environment. A Pilot is used to reduce Risk and to gain User feedback and
Acceptance. See Test, Evaluation.
Plan A detailed proposal which describes the Activities and Resources needed to achieve
an Objective. For example a Plan to implement a new IT Service or Process. ISO/IEC
20000 requires a Plan for the management of each IT Service Management Process.
Plan-Do-Check-Act (Continual Service Improvement) A four stage cycle for Process
management, attributed to Edward Deming. Plan-Do-Check-Act is also called the Deming
Cycle. PLAN: Design or revise Processes that support the IT Services. DO: Implement the
Plan and manage the Processes. CHECK: Measure the Processes and IT Services, compare
with Objectives and produce reports ACT: Plan and implement Changes to improve the
Processes.
Planned Downtime (Service Design) Agreed time when an IT Service will not be
available. Planned Downtime is often used for maintenance, upgrades and testing. See
Change Window, Downtime.
Planning An Activity responsible for creating one or more Plans. For example, Capacity
Planning.
PMBOK A Project management Standard maintained and published by the Project
Management Institute. PMBOK stands for Project Management Body of Knowledge. See
http://www.pmi.org/ for more information. See PRINCE2.
Policy Formally documented management expectations and intentions. Policies are used
to direct decisions, and to ensure consistent and appropriate development and
implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.
Portable Facility (Service Design) A prefabricated building, or a large vehicle, provided
by a Third Party and moved to a site when needed by an IT Service Continuity Plan. See
Recovery Option, Fixed Facility.
Post Implementation Review (PIR) A Review that takes place after a Change or a Project
has been implemented. A PIR determines if the Change or Project was successful, and
identifies opportunities for improvement.
Practice A way of working, or a way in which work must be done. Practices can include
Activities, Processes, Functions, Standards and Guidelines. See Best Practice.
Prerequisite for Success (PFS) An Activity that needs to be completed, or a condition that
needs to be met, to enable successful implementation of a Plan or Process. A PFS is often
an output from one Process that is a required input to another Process.
Pricing (Service Strategy) The Activity for establishing how much Customers will be
Charged.
PRINCE2 The standard UK government methodology for Project management. See http:/
/www.ogc.gov.uk/prince2/ for more information. See PMBOK.
A-31
Priority (Service Transition) (Service Operation) A Category used to identify the relative
importance of an Incident, Problem or Change. Priority is based on Impact and Urgency,
and is used to identify required times for actions to be taken. For example the SLA may
state that Priority2 Incidents must be resolved within 12 hours.
Proactive Monitoring (Service Operation) Monitoring that looks for patterns of Events to
predict possible future Failures. See Reactive Monitoring.
Proactive Problem Management (Service Operation) Part of the Problem Management
Process. The Objective of Proactive Problem Management is to identify Problems that
might otherwise be missed. Proactive Problem Management analyses Incident Records,
and uses data collected by other IT Service Management Processes to identify trends or
significant Problems.
Problem (Service Operation) A cause of one or more Incidents. The cause is not usually
known at the time a Problem Record is created, and the Problem Management Process is
responsible for further investigation.
Problem Management (Service Operation) The Process responsible for managing the
Lifecycle of all Problems. The primary Objectives of Problem Management are to prevent
Incidents from happening, and to minimize the Impact of Incidents that cannot be
prevented.
Problem Record (Service Operation) A Record containing the details of a Problem. Each
Problem Record documents the Lifecycle of a single Problem.
Procedure A Document containing steps that specify how to achieve an Activity.
Procedures are defined as part of Processes. See Work Instruction.
Process A structured set of Activities designed to accomplish a specific Objective. A
Process takes one or more defined inputs and turns them into defined outputs. A Process
may include any of the Roles, responsibilities, tools and management Controls required to
reliably deliver the outputs. A Process may define Policies, Standards, Guidelines,
Activities, and Work Instructions if they are needed.
Process Control The Activity of planning and regulating a Process, with the Objective of
performing the Process in an Effective, Efficient, and consistent manner.
Process Manager A Role responsible for Operational management of a Process. The
Process Manager's responsibilities include Planning and co-ordination of all Activities
required to carry out, monitor and report on the Process. There may be several Process
Managers for one Process, for example regional Change Managers or IT Service Continuity
Managers for each data center The Process Manager Role is often assigned to the person
who carries out the Process Owner Role, but the two Roles may be separate in larger
Organizations.
Process Owner A Role responsible for ensuring that a Process is Fit for Purpose. The
Process Owners responsibilities include sponsorship, Design, Change Management and
continual improvement of the Process and its Metrics. This Role is often assigned to the
A-32
same person who carries out the Process Manager Role, but the two Roles may be separate
in larger Organizations.
Production Environment Synonym for Live Environment.
Profit Center (Service Strategy) A Business Unit which charges for Services provided. A
Profit Center can be created with the objective of making a profit, recovering Costs, or
running at a loss. An IT Service Provider can be run as a Cost Center or a Profit Center
Pro-forma A template, or example Document containing example data that will be
replaced with the real values when these are available.
Program A number of Projects and Activities that are planned and managed together to
achieve an overall set of related Objectives and other Outcomes.
Project A temporary Organization., with people and other Assets required to achieve an
Objective or other Outcome. Each Project has a Lifecycle that typically includes initiation,
Planning, execution, Closure etc. Projects are usually managed using a formal methodology
such as PRINCE2.
Projected Service Outage (PSO) (Service Transition) A Document that identifies the
effect of planned Changes, maintenance Activities and Test Plans on agreed Service
Levels.
Projects IN Controlled Environments (PRINCE2) See PRINCE2
Qualification (Service Transition) An Activity that ensures that IT Infrastructure is
appropriate, and correctly configured, to support an Application or IT Service. See
Validation.
Quality The ability of a product, Service, or Process to provide the intended value. For
example, a hardware Component can be considered to be of high Quality if it performs as
expected and delivers the required Reliability. Process Quality also requires an ability to
monitor Effectiveness and Efficiency, and to improve them if necessary. See Quality
Management System.
Quality Assurance (QA) (Service Transition) The Process responsible for ensuring that
the Quality of a product, Service or Process will provide its intended Value.
Quality Management System (QMS) (Continual Service Improvement) The set of
Processes responsible for ensuring that all work carried out by an Organization. is of a
suitable Quality to reliably meet Business Objectives or Service Levels. See ISO 9000.
Quick Win (Continual Service Improvement) An improvement Activity which is expected
to provide a Return on Investment in a short period of time with relatively small Cost and
effort. See Pareto Principle.
RACI (Service Design) (Continual Service Improvement) A Model used to help define
Roles and Responsibilities. RACI stands for Responsible, Accountable, Consulted and
Informed. See Stakeholder.
A-33
Reactive Monitoring (Service Operation) Monitoring that takes action in response to an

Event. For example submitting a batch job when the previous job completes, or logging an
Incident when an Error occurs. See Proactive Monitoring.
Reciprocal Arrangement (Service Design) A Recovery Option. An agreement between
two Organizations. to share resources in an emergency. For example, Computer Room
space or use of a mainframe.
Record A Document containing the results or other output from a Process or Activity.
Records are evidence of the fact that an Activity took place and may be paper or electronic.
For example, an Audit report, an Incident Record, or the minutes of a meeting.
Recovery (Service Design) (Service Operation) Returning a Configuration Item or an IT
Service to a working state. Recovery of an IT Service often includes recovering data to a
known consistent state. After Recovery, further steps may be needed before the IT Service
can be made available to the Users (Restoration).
Recovery Option (Service Design) A Strategy for responding to an interruption to Service.
Commonly used Strategies are Do Nothing, Manual Workaround, Reciprocal
Arrangement, Gradual Recovery, Intermediate Recovery, Fast Recovery, Immediate
Recovery. Recovery Options may make use of dedicated facilities, or Third Party facilities
shared by multiple Businesses.
Recovery Point Objective (RPO) (Service Operation) The maximum amount of data that
may be lost when Service is Restored after an interruption. Recovery Point Objective is
expressed as a length of time before the Failure. For example a Recovery Point Objective
of one day may be supported by daily Backups, and up to 24 hours of data may be lost.
Recovery Point Objectives for each IT Service should be negotiated, agreed and
documented, and used as Requirements for Service Design and IT Service Continuity
Plans.
Recovery Time Objective (RTO) (Service Operation) The maximum time allowed for
recovery of an IT Service following an interruption. The Service Level to be provided may
be less than normal Service Level Targets. Recovery Time Objectives for each IT Service
should be negotiated, agreed and documented. See Business Impact Analysis.
Redundancy Synonym for Fault Tolerance. The term Redundant also has a generic
meaning of obsolete, or no longer needed.
Relationship A connection or interaction between two people or things. In Business
Relationship Management it is the interaction between the IT Service Provider and the
Business. In Configuration Management it is a link between two Configuration Items that
identifies a dependency or connection between them. For example Applications may be
linked to the Servers they run on, IT Services have many links to all the CIs that contribute
to them.
Relationship Processes The ISO/IEC 20000 Process group that includes Business
Relationship Management and Supplier Management.
A-34
Release (Service Transition) A collection of hardware, software, documentation, Processes

or other Components required to implement one or more approved Changes to IT Services.
The contents of each Release are managed, Tested, and Deployed as a single entity.
Release and Deployment Management (Service Transition) The Process responsible for
both Release Management and Deployment.
Release Identification (Service Transition) A naming convention used to uniquely identify
a Release. The Release Identification typically includes a reference to the Configuration
Item and a version number. For example Microsoft Office 2003 SR2.
Release Management (Service Transition) The Process responsible for Planning,
scheduling and controlling the movement of Releases to Test and Live Environments. The
primary Objective of Release Management is to ensure that the integrity of the Live
Environment is protected and that the correct Components are released. Release
Management is part of the Release and Deployment Management Process.
Release Process The name used by ISO/IEC 20000 for the Process group that includes
Release Management. This group does not include any other Processes. Release Process is
also used as a synonym for Release Management Process.
Release Record (Service Transition) A Record in the CMDB that defines the content of a
Release. A Release Record has Relationships with all Configuration Items that are affected
by the Release.
Release Unit (Service Transition) Components of an IT Service that are normally Released
together. A Release Unit typically includes sufficient Components to perform a useful
Function. For example one Release Unit could be a Desktop PC, including Hardware,
Software, Licenses, Documentation etc. A different Release Unit may be the complete
Payroll Application, including IT Operations Procedures and User training.
Release Window Synonym for Change Window.
Reliability (Service Design) (Continual Service Improvement) A measure of how long a
Configuration Item or IT Service can perform its agreed Function without interruption.
Usually measured as MTBF or MTBSI. The term Reliability can also be used to state how
likely it is that a Process, Function etc. will deliver its required outputs. See Availability.
Remediation (Service Transition) Recovery to a known state after a failed Change or
Release.
Repair (Service Operation) The replacement or correction of a failed Configuration Item.
Request for Change (RFC) (Service Transition) A formal proposal for a Change to be
made. An RFC includes details of the proposed Change, and may be recorded on paper or
electronically. The term RFC is often misused to mean a Change Record, or the Change
itself.
Request Fulfillment (Service Operation) The Process responsible for managing the
Lifecycle of all Service Requests.
A-35
Requirement (Service Design) A formal statement of what is needed. For example a

Service Level Requirement, a Project Requirement or the required Deliverables for a
Process. See Statement of Requirements.
Resilience (Service Design) The ability of a Configuration Item or IT Service to resist
Failure or to Recover quickly following a Failure. For example, an armored cable will resist
failure when put under stress. See Fault Tolerance.
Resolution (Service Operation) Action taken to repair the Root Cause of an Incident or
Problem, or to implement a Workaround. In ISO/IEC 20000, Resolution Processes is the
Process group that includes Incident and Problem Management.
Resolution Processes The ISO/IEC 20000 Process group that includes Incident
Management and Problem Management.
Resource (Service Strategy) A generic term that includes IT Infrastructure, people, money
or anything else that might help to deliver an IT Service. Resources are considered to be
Assets of an Organization. See Capability, Service Asset.
Response Time A measure of the time taken to complete an Operation or Transaction.
Used in Capacity Management as a measure of IT Infrastructure Performance, and in
Incident Management as a measure of the time taken to answer the phone, or to start
Diagnosis.
Responsiveness A measurement of the time taken to respond to something. This could be
Response Time of a Transaction, or the speed with which an IT Service Provider responds
to an Incident or Request for Change etc.
Restoration of Service See Restore.
Restore (Service Operation)Taking action to return an IT Service to the Users after Repair
and Recovery from an Incident. This is the primary Objective of Incident Management.
Retire (Service Transition) Permanent removal of an IT Service, or other Configuration
Item, from the Live Environment. Retired is a stage in the Lifecycle of many Configuration
Items.
Return on Investment (ROI) (Service Strategy) (Continual Service Improvement) A
measurement of the expected benefit of an investment. In the simplest sense it is the net
profit of an investment divided by the net worth of the assets invested. See Net Present
Value, Value on Investment.
Return to Normal (Service Design) The phase of an IT Service Continuity Plan during
which full normal operations are resumed. For example, if an alternate data center has been
in use, then this phase will bring the primary data center back into operation, and restore
the ability to invoke IT Service Continuity Plans again.
Review An evaluation of a Change, Problem, Process, Project etc. Reviews are typically
carried out at predefined points in the Lifecycle, and especially after Closure. The purpose
A-36
of a Review is to ensure that all Deliverables have been provided, and to identify
opportunities for improvement. See Post Implementation Review.
Rights (Service Operation) Entitlements, or permissions, granted to a User or Role. For
example the Right to modify particular data, or to authorize a Change.
Risk A possible Event that could cause harm or loss, or affect the ability to achieve
Objectives. A Risk is measured by the probability of a Threat, the Vulnerability of the Asset
to that Threat, and the Impact it would have if it occurred.
Risk Assessment The initial steps of Risk Management. Analyzing the value of Assets to
the business, identifying Threats to those Assets, and evaluating how Vulnerable each
Asset is to those Threats. Risk Assessment can be quantitative (based on numerical data) or
qualitative.
Risk Management The Process responsible for identifying, assessing and controlling
Risks. See Risk Assessment.
Role A set of responsibilities, Activities and authorities granted to a person or team. A Role
is defined in a Process. One person or team may have multiple Roles, for example the Roles
of Configuration Manager and Change Manager may be carried out by a single person.
Rollout (Service Transition) Synonym for Deployment. Most often used to refer to
complex or phased Deployments or Deployments to multiple locations.
Root Cause (Service Operation) The underlying or original cause of an Incident or
Problem.
Root Cause Analysis (RCA) (Service Operation) An Activity that identifies the Root
Cause of an Incident or Problem. RCA typically concentrates on IT Infrastructure failures.
See Service Failure Analysis.
Running Costs Synonym for Operational Costs
Scalability The ability of an IT Service, Process, Configuration Item etc. to perform its
agreed Function when the Workload or Scope changes.
Scope The boundary, or extent, to which a Process, Procedure, Certification, Contract etc.
applies. For example the Scope of Change Management may include all Live IT Services
and related Configuration Items, the Scope of an ISO/IEC 20000 Certificate may include
all IT Services delivered out of a named data center
Second-line Support (Service Operation) The second level in a hierarchy of Support
Groups involved in the resolution of Incidents and investigation of Problems. Each level
contains more specialist skills, or has more time or other Resources.
Security See Information Security Management
Security Management Synonym for Information Security Management
A-37
Security Policy Synonym for Information Security Policy

Separation of Concerns (SoC) (Service Strategy) An approach to Designing a solution or
IT Service that divides the problem into pieces that can be solved independently. This
approach separates "what" is to be done from "how" it is to be done.
Server (Service Operation) A computer that is connected to a network and provides
software Functions that are used by other computers.
Service A means of delivering value to Customers by facilitating Outcomes Customers
want to achieve without the ownership of specific Costs and Risks.
Service Acceptance Criteria (SAC) (Service Transition) A set of criteria used to ensure
that an IT Service meets its functionality and Quality Requirements and that the IT Service
Provider is ready to Operate the new IT Service when it has been Deployed. See
Acceptance.
Service Analytics (Service Strategy) A technique used in the Assessment of the Business
Impact of Incidents. Service Analytics Models the dependencies between Configuration
Items, and the dependencies of IT Services on Configuration Items.
Service Asset Any Capability or Resource of a Service Provider. See Asset.
Service Asset and Configuration Management (SACM) (Service Transition) The
Process responsible for both Configuration Management and Asset Management.
Service Capacity Management (SCM) (Service Design) (Continual Service
Improvement) The Activity responsible for understanding the Performance and Capacity
of IT Services. The Resources used by each IT Service and the pattern of usage over time
are collected, recorded, and analyzed for use in the Capacity Plan. See Business Capacity
Management, Component Capacity Management.
Service Catalogue (Service Design) A database or structured Document with information
about all Live IT Services, including those available for Deployment. The Service
Catalogue is the only 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
about deliverables, prices, contact points, ordering and request Processes. See Contract
Portfolio.
Service Continuity Management Synonym for IT Service Continuity Management.
Service Contract (Service Strategy) A Contract to deliver one or more IT Services. The
term Service Contract is also used to mean any Agreement to deliver IT Services, whether
this is a legal Contract or an SLA. See Contract Portfolio.
Service Culture A Customer oriented Culture. The major Objectives of a Service Culture
are Customer satisfaction and helping the Customer to achieve their Business Objectives.
A-38
Service Design (Service Design) A stage in the Lifecycle of an IT Service. Service Design
includes a number of Processes and Functions and is the title of one of the Core ITIL
publications. See Design.
Service Design Package (Service Design) Document(s) defining all aspects of an IT
Service and its Requirements through each stage of its Lifecycle. A Service Design
Package is produced for each new IT Service, major Change, or IT Service Retirement.
Service Desk (Service Operation) The Single Point of Contact between the Service
Provider and the Users. A typical Service Desk manages Incidents and Service Requests,
and also handles communication with the Users.
Service Failure Analysis (SFA) (Service Design) An Activity that identifies underlying
causes of one or more IT Service interruptions. SFA identifies opportunities to improve the
IT Service Provider's Processes and tools, and not just the IT Infrastructure. SFA is a time
constrained, project-like activity, rather than an ongoing process of analysis. See Root
Cause Analysis.
Service Hours (Service Design) (Continual Service Improvement) An agreed time period
when a particular IT Service should be Available. For example, "Monday-Friday 08:00 to
17:00 except public holidays". Service Hours should be defined in a Service Level
Agreement.
Service Improvement Plan (SIP) (Continual Service Improvement) A formal Plan to
implement improvements to a Process or IT Service.
Service Knowledge Management System (SKMS) (Service Transition) A set of tools and
databases that are used to manage knowledge and information. The SKMS includes the
Configuration Management System, as well as other tools and databases. The SKMS
stores, manages, updates, and presents all information that an IT Service Provider needs to
manage the full Lifecycle of IT Services.
Service Level Measured and reported achievement against one or more Service Level
Targets. The term Service Level is sometimes used informally to mean Service Level
Target.
Service Level Agreement (SLA) (Service Design) (Continual Service Improvement) An
Agreement between an IT Service Provider and a Customer. The SLA describes the IT
Service, documents Service Level Targets, and specifies the responsibilities of the IT
Service Provider and the Customer. A single SLA may cover multiple IT Services or
multiple Customers. See Operational Level Agreement.
Service Level Management (SLM) (Service Design) (Continual Service Improvement)
The Process responsible for negotiating Service Level Agreements, and ensuring that these
are met. SLM is responsible for ensuring that all IT Service Management Processes,
Operational Level Agreements, and Underpinning Contracts, are appropriate for the agreed
Service Level Targets. SLM monitors and reports on Service Levels, and holds regular
Customer reviews.
A-39
Service Level Package (SLP) (Service Strategy) A defined level of Utility and Warranty
for a particular Service Package. Each SLP is designed to meet the needs of a particular
Pattern of Business Activity. See Line of Service.
Service Level Requirement (SLR) (Service Design) (Continual Service Improvement) A
Customer Requirement for an aspect of an IT Service. SLRs are based on Business
Objectives and are used to negotiate agreed Service Level Targets.
Service Level Target (Service Design) (Continual Service Improvement) A commitment
that is documented in a Service Level Agreement. Service Level Targets are based on
Service Level Requirements, and are needed to ensure that the IT Service design is Fit for
Purpose. Service Level Targets should be SMART, and are usually based on KPIs.
Service Maintenance Objective (Service Operation) The expected time that a
Configuration Item will be unavailable due to planned maintenance Activity.
Service Management Service Management is a set of specialized organizational
capabilities for providing value to customers in the form of services.
Service Management Lifecycle An approach to IT Service Management that emphasizes
the importance of coordination and Control across the various Functions, Processes, and
Systems necessary to manage the full Lifecycle of IT Services. The Service Management
Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous
Improvement of IT Services.
Service Manager A manager who is responsible for managing the end-to-end Lifecycle of
one or more IT Services. The term Service Manager is also used to mean any manager
within the IT Service Provider. Most commonly used to refer to a Business Relationship
Manager, a Process Manager, an Account Manager or a senior manager with responsibility
for IT Services overall.
Service Operation (Service Operation) A stage in the Lifecycle of an IT Service. Service
Operation includes a number of Processes and Functions and is the title of one of the Core
ITIL publications. See Operation.
Service Owner (Continual Service Improvement) A Role which is accountable for the
delivery of a specific IT Service.
Service Package (Service Strategy) A detailed description of an IT Service that is available
to be delivered to Customers. A Service Package includes a Service Level Package and one
or more Core Services and Supporting Services.
Service Pipeline (Service Strategy) A database or structured Document listing all IT
Services that are under consideration or Development, but are not yet available to
Customers. The Service Pipeline provides a Business view of possible future IT Services
and is part of the Service Portfolio which is not normally published to Customers.
A-40
Service Portfolio (Service Strategy) The complete set of Services that are managed by a
Service Provider. The Service Portfolio is used to manage the entire Lifecycle of all
Services, and includes three Categories: Service Pipeline (proposed or in Development);
Service Catalogue (Live or available for Deployment); and Retired Services. See Service
Portfolio Management, Contract Portfolio.
Service Portfolio Management (SPM) (Service Strategy) The Process responsible for
managing the Service Portfolio. Service Portfolio Management considers Services in terms
of the Business value that they provide.
Service Potential (Service Strategy) The total possible value of the overall Capabilities and
Resources of the IT Service Provider.
Service Provider (Service Strategy) An Organization. supplying Services to one or more
Internal Customers or External Customers. Service Provider is often used as an
abbreviation for IT Service Provider. See Type I Service Provider, Type II Service
Provider, Type III Service Provider.
Service Provider Interface (SPI) (Service Strategy) An interface between the IT Service
Provider and a User, Customer, Business Process, or a Supplier. Analysis of Service
Provider Interfaces helps to coordinate end-to-end management of IT Services.
Service Provisioning Optimization (SPO) (Service Strategy) Analyzing the finances and
constraints of an IT Service to decide if alternative approaches to Service delivery might
reduce Costs or improve Quality.
Service Reporting (Continual Service Improvement) The Process responsible for
producing and delivering reports of achievement and trends against Service Levels. Service
Reporting should agree the format, content and frequency of reports with Customers.
Service Request (Service Operation) A request from a User for information, or advice, or
for a Standard Change or for Access to an IT Service. For example to reset a password, or
to provide standard IT Services for a new User. Service Requests are usually handled by a
Service Desk, and do not require an RFC to be submitted. See Request Fulfillment
Service Sourcing (Service Strategy) The Strategy and approach for deciding whether to
provide a Service internally or to Outsource it to an External Service Provider. Service
Sourcing also means the execution of this Strategy. Service Sourcing includes:
Internal Sourcing - Internal or Shared Services using Type I or Type II Service

Providers.
Traditional Sourcing - Full Service Outsourcing using a Type III Service Provider.
Multivendor Sourcing - Prime, Consortium or Selective Outsourcing using Type

III Service Providers.
Service Strategy (Service Strategy) The title of one of the Core ITIL publications. Service
Strategy establishes an overall Strategy 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 and Functions and is the title of one of the Core
ITIL publications. See Transition.
A-41
Service Utility (Service Strategy) The Functionality of an IT Service from the Customer's
perspective. The Business value of an IT Service is created by the combination of Service
Utility (what the Service does) and Service Warranty (how well it does it). See Utility.
Service Validation and Testing (Service Transition) The Process responsible for
Validation and Testing of a new or Changed IT Service. Service Validation and Testing
ensures that the IT Service matches its Design Specification and will meet the needs of the
Business.
Service Valuation (Service Strategy) A measurement of the total Cost of delivering an IT
Service, and the total value to the Business of that IT Service. Service Valuation is used to
help the Business and the IT Service Provider agree on the value of the IT Service.
Service Warranty (Service Strategy) Assurance that an IT Service will meet agreed
Requirements. This may be a formal Agreement such as a Service Level Agreement or
Contract, or may be a marketing message or brand image. The Business value of an IT
Service is created by the combination of Service Utility (what the Service does) and Service
Warranty (how well it does it). See Warranty.
Serviceability (Service Design) (Continual Service Improvement) The ability of a Third
Party Supplier to meet the terms of their Contract. This Contract will include agreed levels
of Reliability, Maintainability or Availability for a Configuration Item.
Shift (Service Operation) A group or team of people who carry out a specific Role for a
fixed period of time. For example there could be four shifts of IT Operations Control
personnel to support an IT Service that is used 24 hours a day.
Simulation Modeling (Service Design) (Continual Service Improvement) A technique that
creates a detailed Model to predict the behavior of a Configuration Item or IT Service.
Simulation Models can be very accurate but are expensive and time consuming to create.
A Simulation Model is often created by using the actual Configuration Items that are being
modeled, with artificial Workloads or Transactions. They are used in Capacity
Management when accurate results are important. A simulation model is sometimes called
a Performance Benchmark.
Single Point of Contact (Service Operation) Providing a single consistent way to
communicate with an Organization. or Business Unit. For example, a Single Point of
Contact for an IT Service Provider is usually called a Service Desk.
Single Point of Failure (SPOF) (Service Design) Any Configuration Item that can cause
an Incident when it fails, and for which a Countermeasure has not been implemented. A
SPOF may be a person, or a step in a Process or Activity, as well as a Component of the IT
Infrastructure. See Failure.
SLAM Chart (Continual Service Improvement) A Service Level Agreement Monitoring
Chart is used to help monitor and report achievements against Service Level Targets. A
SLAM Chart is typically color coded to show whether each agreed Service Level Target
has been met, missed, or nearly missed during each of the previous 12 months.
A-42
SMART (Service Design) (Continual Service Improvement) An acronym for helping to

remember that targets in Service Level Agreements and Project Plans should be Specific,
Measurable, Achievable, Relevant and Timely.
Snapshot (Service Transition) The current state of a Configuration as captured by a
discovery tool. Also used as a synonym for Benchmark. See Baseline.
Source See Service Sourcing.
Specification A formal definition of Requirements. A Specification may be used to define
technical or Operational Requirements, and may be internal or external. Many public
Standards consist of a Code of Practice and a Specification. The Specification defines the
Standard against which an Organization. can be Audited.
Stakeholder All people who have an interest in an Organization., Project, IT Service etc.
Stakeholders may be interested in the Activities, targets, Resources, or Deliverables.
Stakeholders may include Customers, Partners, employees, shareholders, owners, etc. See
RACI.
Standard A mandatory Requirement. Examples include ISO/IEC 20000 (an international
Standard), an internal security Standard for Unix configuration, or a government Standard
for how financial Records should be maintained. The term Standard is also used to refer to
a Code of Practice or Specification published by a Standards Organization. such as ISO or
BSI. See Guideline.
Standard Change (Service Transition) A pre-approved Change that is low Risk, relatively
common and follows a Procedure or Work Instruction. For example password reset or
provision of standard equipment to a new employee. RFCs are not required to implement a
Standard Change, and they are logged and tracked using a different mechanism, such as a
Service Request. See Change Model.
Standard Operating Procedures (SOP) (Service Operation) Procedures used by IT
Operations Management.
Standby (Service Design) Used to refer to Resources that are not required to deliver the
Live IT Services, but are available to support IT Service Continuity Plans. For example a
Standby data center may be maintained to support Hot Standby, Warm Standby or Cold
Standby arrangements.
Statement of requirements (SOR) (Service Design) A Document containing all
Requirements for a product purchase, or a new or changed IT Service. See Terms of
Reference.
Status The name of a required field in many types of Record. It shows the current stage in
the Lifecycle of the associated Configuration Item, Incident, Problem etc.
Status Accounting (Service Transition) The Activity responsible for recording and
reporting the Lifecycle of each Configuration Item.
A-43
Storage Management (Service Operation) The Process responsible for managing the
storage and maintenance of data throughout its Lifecycle.
Strategic (Service Strategy) The highest of three levels of Planning and delivery (Strategic,
Tactical, Operational). Strategic Activities include Objective setting and long term
Planning to achieve the overall Vision.
Strategy (Service Strategy) A Strategic Plan designed to achieve defined Objectives.
Super User (Service Operation) A User who helps other Users, and assists in
communication with the Service Desk or other parts of the IT Service Provider. Super Users
typically provide support for minor Incidents and training.
Supplier (Service Strategy) (Service Design) A Third Party responsible for supplying
goods or Services that are required to deliver IT services. Examples of suppliers include
commodity hardware and software vendors, network and telecom providers, and
Outsourcing Organizations. See Underpinning Contract, Supply Chain.
Supplier and Contract Database (SCD) (Service Design) A database or structured
Document used to manage Supplier Contracts throughout their Lifecycle. The SCD
contains key Attributes of all Contracts with Suppliers, and should be part of the Service
Knowledge Management System.
Supplier Management (Service Design) The Process responsible for ensuring that all
Contracts with Suppliers support the needs of the Business, and that all Suppliers meet their
contractual commitments.
Supply Chain (Service Strategy) The Activities in a Value Chain carried out by Suppliers.
A Supply Chain typically involves multiple Suppliers, each adding value to the product or
Service. See Value Network.
Support Group (Service Operation) A group of people with technical skills. Support
Groups provide the Technical Support needed by all of the IT Service Management
Processes. See Technical Management.
Support Hours (Service Design) (Service Operation) The times or hours when support is
available to the Users. Typically this is the 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 Support Hours
may be 07:00 to 19:00.
Supporting Service (Service Strategy) A Service that enables or enhances a Core Service.
For example a Directory Service or a Backup Service. See Service Package.
SWOT Analysis (Continual Service Improvement) A technique that reviews and analyses
the internal strengths and weaknesses of an Organization. and the external opportunities
and threats which it faces SWOT stands for Strengths, Weaknesses, Opportunities and
Threats.
A-44
System A number of related things that work together to achieve an overall Objective. For
example:
A computer System including hardware, software and Applications.
A management System, including multiple Processes that are planned and

managed together. For example a Quality Management System.
Database Management System or Operating System that includes many software

modules that are designed to perform a set of related Functions.
System Management The part of IT Service Management that focuses on the management
of IT Infrastructure rather than Process.
Tactical The middle of three levels of Planning and delivery (Strategic, Tactical,
Operational). Tactical Activities include the medium term Plans required to achieve
specific Objectives, 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 to identify different Customer outcomes when analyzing and
comparing Strategies. The term Tag is also used to refer to the Activity of assigning Tags
to things.
Technical Management (Service Operation) The Function responsible for providing
technical skills in support of IT Services and management of the IT Infrastructure.
Technical Management defines the Roles of Support Groups, as well as the tools, Processes
and Procedures required.
Technical Observation (TO) (Continual Service Improvement) A technique used in
Service Improvement, Problem investigation and Availability Management. Technical
support staff meet to monitor the behavior and Performance of an IT Service and make
recommendations for improvement.
Technical Service Synonym for Infrastructure Service.
Technical Support Synonym for Technical Management.
Tension Metrics (Continual Service Improvement) A set of related Metrics, in which
improvements to one Metric have a negative effect on another. Tension Metrics are
designed to ensure that an appropriate balance is achieved.
Terms of Reference (TOR) (Service Design) A Document specifying the Requirements,
Scope, Deliverables, Resources and schedule for a Project or Activity.
Test (Service Transition) An Activity that verifies that a Configuration Item, IT Service,
Process, etc. meets its Specification or agreed Requirements. See Service Validation and
Testing, Acceptance.
Test Environment (Service Transition) A controlled Environment used to Test
Configuration Items, Builds, IT Services, Processes etc.
A-45
Third Party A person, group, or Business who is not part of the Service Level Agreement
for an IT Service, but is required to ensure successful delivery of that IT Service. For
example a software Supplier, a hardware maintenance company, or a facilities department.
Requirements for Third Parties are typically specified in Underpinning Contracts or
Operational Level Agreements.
Third-line Support (Service Operation) The third level in a hierarchy of Support Groups
involved in the resolution of Incidents and investigation of Problems. Each level contains
more specialist skills, or has more time or other Resources.
Threat Anything that might exploit a Vulnerability. Any potential cause of an Incident can
be considered to be a Threat. For example a fire is a Threat that could exploit the
Vulnerability of flammable floor coverings. This term is commonly used in Information
Security Management and IT Service Continuity Management, but also applies to other
areas such as Problem and Availability Management.
Threshold The value of a Metric which should cause an Alert to be generated, or
management action to be taken. For example "Priority1 Incident not solved within 4 hours",
"more than 5 soft disk errors in an hour", or "more than 10 failed changes in a month".
Throughput (Service Design) A measure of the number of Transactions, or other
Operations, performed in a fixed time. For example 5000 emails sent per hour, or 200 disk
I/Os per second.
Total Cost of Ownership (TCO) (Service Strategy) A methodology used to help make
investment decisions. TCO assesses the full Lifecycle Cost of owning a Configuration
Item, not just the initial Cost or purchase price. See Total Cost of Utilization.
Total Cost of Utilization (TCU) (Service Strategy) A methodology used to help make
investment and Service Sourcing decisions. TCU assesses the full Lifecycle Cost to the
Customer of using an IT Service. See Total Cost of Ownership.
Total Quality Management (TQM) (Continual Service Improvement) A methodology for
managing continual Improvement by using a Quality Management System. TQM
establishes a Culture involving all people in the Organization. in a Process of continual
monitoring and improvement.
Transaction A discrete Function performed by an IT Service. For example transferring
money from one bank account to another. A single Transaction may involve numerous
additions, deletions and modifications of data. Either all of these complete successfully or
none of them is carried out.
Transition (Service Transition) A change in state, corresponding to a movement of an IT
Service or other Configuration Item from one Lifecycle status to the next.
A-46
Transition Planning and Support (Service Transition) The Process responsible for
Planning all Service Transition Processes and coordinating the resources that they require.
These Service Transition Processes are Change Management, Service Asset and
Configuration Management, Release and Deployment Management, Service Validation
and Testing, Evaluation, and Knowledge Management.
Trend Analysis (Continual Service Improvement) Analysis of data to identify time related
patterns. Trend Analysis is used in Problem Management to identify common Failures or
fragile Configuration Items, and in Capacity Management as a Modeling tool to predict
future behavior It is also used as a management tool for identifying deficiencies in IT
Service Management Processes.
Tuning The Activity responsible for Planning Changes to make the most efficient use of
Resources. Tuning is part of Performance Management, which also includes Performance
Monitoring and implementation of the required Changes.
Type I Service Provider (Service Strategy) An Internal Service Provider that is embedded
within a Business Unit. There may be several Type I Service Providers within an
Organization.
Type II Service Provider (Service Strategy) An Internal Service Provider that provides
shared IT Services to more than one Business Unit.
Type III Service Provider (Service Strategy) A Service Provider that provides IT Services
to External Customers.
Underpinning Contract (UC) (Service Design) A Contract between an IT Service
Provider and a Third Party. The Third Party provides goods or Services that support
delivery of an IT Service to a Customer. The Underpinning Contract defines targets and
responsibilities that are required to meet agreed Service Level Targets in an SLA.
Unit Cost (Service Strategy) The Cost to the IT Service Provider of providing a single
Component of an IT Service. For example the Cost of a single desktop PC, or of a single
Transaction.
Urgency (Service Transition) (Service Design) A measure of how long it will be until an
Incident, Problem or Change has a significant Impact on the Business. For example a high
Impact Incident may have low Urgency, if the Impact will not 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 Requirements are often included in a Statement of Requirements.
Use Case (Service Design) A technique used to define required functionality and
Objectives, and to Design Tests. Use Cases define realistic scenarios that describe
interactions between Users and an IT Service or other System. See Change Case.
User A person who uses the IT Service on a day-to-day basis. Users are distinct from
Customers, as some Customers do not use the IT Service directly.
User Profile (UP) (Service Strategy) A pattern of User demand for IT Services. Each User
Profile includes one or more Patterns of Business Activity.
Utility (Service Strategy) Functionality offered by a Product or Service to meet a particular
need. Utility is often summarized as "what it does". See Service Utility.
A-47
Validation (Service Transition) An Activity that ensures a new or changed IT Service,

Process, Plan, or other Deliverable meets the needs of the Business. Validation ensures that
Business Requirements are met even though these may have changed since the original
Design. See Verification, Acceptance, Qualification, Service Validation and Testing.
Value Chain (Service Strategy) A sequence of Processes that creates a product or Service
that is of value to a Customer. Each step of the sequence builds on the previous steps and
contributes to the overall product or Service. See Value Network.
Value for Money An informal measure of Cost Effectiveness. Value for Money is often
based on a comparison with the Cost of alternatives. See Cost Benefit Analysis.
Value Network (Service Strategy) A complex set of Relationships between two or more
groups or organizations. Value is generated through exchange of knowledge, information,
goods or Services. See Value Chain, Partnership.
Value on Investment (VOI) (Continual Service Improvement) A measurement of the
expected benefit of an investment. VOI considers both financial and intangible benefits.
See Return on Investment.
Variable Cost (Service Strategy) A Cost that depends on how much the IT Service is used,
how many products are produced, the number and type of Users, or something else that
cannot be fixed in advance. See Variable Cost Dynamics.
Variable Cost Dynamics (Service Strategy) A technique used to understand how overall
Costs are impacted by the many complex variable elements that contribute to the provision
of IT Services.
Variance The difference between a planned value and the actual measured value.
Commonly used in Financial Management, Capacity Management and Service Level
Management, but could apply in any area where Plans are in place.
Verification (Service Transition) An Activity that ensures a new or changed IT Service,
Process, Plan, or other Deliverable is complete, accurate, Reliable and matches its Design
Specification. See Validation, Acceptance, Service Validation and Testing.
Verification and Audit (Service Transition) The Activities responsible for ensuring that
information in the CMDB is accurate and that all Configuration Items have been identified
and recorded in the CMDB. Verification includes routine checks that are part of other
Processes. For example, verifying the serial number 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 specific Baseline of a
Configuration Item. Versions typically use a naming convention that enables the sequence
or date of each Baseline to be identified. For example Payroll Application Version 3
contains updated functionality from Version 2.
A-48
Vision A description of what the Organization. intends to become in the future. A Vision
is created by senior management and is used to help influence Culture and Strategic
Planning.
Vital Business Function (VBF) (Service Design) A Function of a Business Process which
is critical to the success of the Business. Vital Business Functions are an important
consideration of Business Continuity Management, IT Service Continuity Management
and Availability Management.
Vulnerability A weakness that could be exploited by a Threat. For example an open
firewall port, a password that is never changed, or a flammable carpet. A missing Control
is also considered to be a Vulnerability.
Warm Standby Synonym for Intermediate Recovery.
Warranty (Service Strategy) A promise or guarantee that a product or Service will meet
its agreed Requirements. See Service Validation and Testing, Service Warranty.
Work in Progress (WIP) A Status that means Activities have started but are not yet
complete. It is commonly used as a Status for Incidents, Problems, Changes etc.
Work Instruction A Document containing detailed instructions that specify exactly what
steps to follow to carry out an Activity. A Work Instruction contains much more detail than
a Procedure and is only created if very detailed instructions are needed.
Workaround (Service Operation) Reducing or eliminating the Impact of an Incident or
Problem for which a full Resolution is not yet available. For example by restarting a failed
Configuration Item. Workarounds for Problems are documented in Known Error Records.
Workarounds for Incidents that do not have associated Problem Records are documented
in the Incident Record.
Workload The Resources required to deliver an identifiable part of an IT Service.
Workloads may be Categorized by Users, groups of Users, or Functions within the IT
Service. This is used to assist in analyzing and managing the Capacity, Performance and
Utilization of Configuration Items and IT Services. The term Workload is sometimes used
as a synonym for Throughput.
A-49
A-50
Appendix B: ITIL V3 Practice

Examination
In this section you can take a practice ITIL Foundations v3 examination. Doing well on this
examination does not guarantee that you will pass the certification examination. However,
it should give you a good indication of the areas that require further study.
1. What is the best description for the ITIL V3 core?
a. An operations lifecycle
b. An IT Management lifecycle
c. A Service lifecycle
d. An Infrastructure lifecycle
2. Which aspect of Service Design is missing from the following list?
The design of services
The design of Service Management systems and tool
The design of technology architecture and management systems
The design of the processes required
a. The design of functions

b. The design of Service Level Agreements
c. The design of applications
d. The design of measurement systems, methods, and metrics
3. Which of the following roles is responsible for identifying opportunities for
improvement?
1. Service Owner
2. Continual Service Improvement (CSI) Manager
3. Process Owner
a. 1 and 2 only
b. 1 and 3 only
c. All of the above
d. 2 and 3 only
B-1
4. Learning and improvement is the primary concern of which of the following

elements of the Service Lifecycle?
a. Service Strategy, Service Design, Service Transition, Service Operation, and
b. Service Strategy, Service Transition, and Service Operation
c. Service Operation and Continual Service Improvement
d. Continual Service Improvement
5. Which of the following statements is the most appropriate approach to carrying
out Service Operations?
a. The internal IT view is most important as Service Operations has to monitor
and manage the infrastructure.
b. Service Operations should maintain a balance between an internal IT view
and an external business view.
c. The external business view is the most important because Service Operations
is the place where value is realized and the customer obtains the benefit of the
services.
d. IT Operations does not take an internal or external view as they execute
processes defined by Service Design.
6. Which of the following statements about the Service Desk are correct?
1. The Service Desk is a function that provides a means of communication

between IT and its users for all operational issues.
2. The Service Desk is always the owner of the Incident Management process.
a. 2 only
b. 1 only
c. All of the above
d. None of the above
7. How does an organization use resources and capabilities in creating value?
a. They are used to create value in the form of output for Production
Management.
b. They are used to create value in the form of goods and services.
c. They are used to create value to the IT organization for Service Support.
d. They are used to create value to the IT organization for Service Delivery.
B-2
8. In which core publication can you find detailed descriptions of the following
items?
Demand Management
a. Service Operations
b. Service Strategy
c. Service Transition
9. Which of the following statements best describes the role of communication
during Service Operation?
a. Communication is defined as part of all processes and is performed in Service
Operation.
b. Communication is a separate process that must be defined and executed with
Service Operation.
c. Good communication is essential for successful Service Operation, just as it
is for any other phase of the lifecycle.
d. Communication is more important in Service Operation than in any other
stage of the Service Lifecycle.
10. A Process Owner is responsible for which of the following items?
a. Purchasing tools to support the process
b. Ensuring that targets specified in an SLA are met
c. Carrying out activities defined in the process
d. Monitoring and improving the process
11. For what purpose is Demand Management primarily used?
a. Increase customer value
b. Eliminate excess capacity needs
c. Increase the value of IT
d. Align business with IT cost
B-3
12. Which of the following statements is not an advantage of organizing Continual

Service Improvement (CSI) using the RACI model?
a. Facilitates clear communication and workflow practice across all parties
involved in the CSI program
b. Clarifies the roles and responsibilities of individual in the CSI program that
might otherwise be overlapping and confusing
c. Identifies where internal Service Level Agreements (SLAs) can be
established to implement CSI
d. Provides a clear focus for matching the CSI processes to financial planning
13. Which of the following statements are objectives of the Release and Deployment
Management process?
1. To ensure there are clear release and deployment plans
2. To ensure that skills and knowledge are transferred to operations and

support staff
3. To ensure there is minimal unpredicted impact on production services
4. To provide cost justifiable IT capacity that is matched to the needs of the

business
a. 1, 2, and 3 only
b. All of the above
c. 1 and 3 only
d. 1, 3 and 4 only
14. Which of the following questions is not answered by Service Portfolio
Management?
a. How should the resources and capabilities be allocated?
b. What opportunities are there in the market?
c. Why should a customer buy these services?
d. What are the pricing or chargeback models?
B-4
15. Which of the following statements are not included in Access Management?
1. Verifying the identity of users requesting access to services
2. Setting the rights or privileges of systems to permit access to authorized

users
3. Defining security policies for system access
4. Monitoring the availability of systems that users should have access to
a. 2 and 4 only
b. 1 and 3 only
c. 2 and 3 only
d. 1 and 2 only
16. What task is not the responsibility of Application Management?
a. Documenting and maintaining the technical skills required to manage and
support applications
b. Managing applications through their lifecycle
c. Assisting in the decision to build or buy new software
d. Developing operational functionality required by the business
17. If something cannot be measured, it should not be documented within which of
the following items?
a. The Glossary of Terms
b. A Service Level Agreement
c. An Incident Management record
d. A Configuration Item (CI)
18. What is the purpose of the Request Fulfillment process?
a. Dealing with Service Requests from the users
b. Making sure all requests within an IT organization are fulfilled
c. Ensuring fulfillment of Change Requests
d. Making sure the Service Level Agreement is met
B-5
19. Which of the following areas can technology help to support during the Service
Transition phase of the lifecycle?
1. Data mining and workflow tools
2. Measurement and reporting systems
3. Release and Deployment technology
4. Process Design
a. 1, 2, and 3 only
b. 1, 3, and 4 only
c. 2, 3, and 4 only
d. All of the above
20. Which of the following statements is correct about good practice?
a. It can be used to drive an organization forward.
b. It is something that is in wide industry use.
c. It is always documented in international standards.
d. It is always based on ITIL.
B-6
Practice Examination Answer Key

The Correct answers to the following questions appear in bold text.
1. What is the best description for the ITIL V3 core?
a. An operations lifecycle
b. An IT Management lifecycle
c. A Service lifecycle
d. An Infrastructure lifecycle
2. Which aspect of Service Design is missing from the following list?
The design of services
The design of Service Management systems and tool
The design of technology architecture and management systems
The design of the processes required
a. The design of functions

b. The design of Service Level Agreements
c. The design of applications
d. The design of measurement systems, methods, and metrics
3. Which of the following roles is responsible for identifying opportunities for
improvement?
1. Service Owner
2. Continual Service Improvement (CSI) Manager
3. Process Owner
a. 1 and 2 only
b. 1 and 3 only
c. All of the above
d. 2 and 3 only
B-7
4. Learning and improvement is the primary concern of which of the following

elements of the Service Lifecycle?
a. Service Strategy, Service Design, Service Transition, Service Operation, and
b. Service Strategy, Service Transition, and Service Operation
c. Service Operation and Continual Service Improvement
5. Which of the following statements is the most appropriate approach to carrying
out Service Operations?
a. The internal IT view is most important as Service Operations has to monitor
and manage the infrastructure.
b. Service Operations should maintain a balance between an internal IT view
and an external business view.
c. The external business view is the most important because Service Operations
is the place where value is realized and the customer obtains the benefit of the
services.
d. IT Operations does not take an internal or external view as they execute
processes defined by Service Design.
6. Which of the following statements about the Service Desk are correct?
1. The Service Desk is a function that provides a means of communication

between IT and its users for all operational issues.
2. The Service Desk is always the owner of the Incident Management process.
a. 2 only
b. 1 only
c. All of the above
d. None of the above
7. How does an organization use resources and capabilities in creating value?
a. They are used to create value in the form of output for Production
Management.
b. They are used to create value in the form of goods and services.
c. They are used to create value to the IT organization for Service Support.
d. They are used to create value to the IT organization for Service Delivery.
B-8
8. In which core publication can you find detailed descriptions of the following
items?
Demand Management
a. Service Operations
b. Service Strategy
c. Service Transition
9. Which of the following statements best describes the role of communication
during Service Operation?
a. Communication is defined as part of all processes and is executed in Service
Operation.
b. Communication is a separate process that needs to be defined and executed
with Service Operation.
c. Good communication is essential for successful Service Operation, just as it
is for any other phase of the lifecycle.
d. Communication is more important in Service Operation than in any other
stage of the Service Lifecycle.
10. A Process Owner is responsible for which of the following items?
a. Purchasing tools to support the process
b. Ensuring that targets specified in an SLA are met
c. Carrying out activities defined in the process
d. Monitoring and improving the process
11. For what purpose is Demand Management primarily used?
a. Increase customer value
b. Eliminate excess capacity needs
c. Increase the value of IT
d. Align business with IT cost
B-9
12. Which of the following statements is not an advantage of organizing Continual

Service Improvement (CSI) using the RACI model?
a. Facilitates clear communication and workflow practice across all parties
involved in the CSI program
b. Clarifies the roles and responsibilities of individual in the CSI program which
might otherwise be overlapping and confusing
c. Identifies where internal Service Level Agreements (SLAs) can be
established to implement CSI
d. Provides a clear focus for matching the CSI processes to financial planning
13. Which of the following statements are objectives of the Release and Deployment
Management process?
1. To ensure there are clear release and deployment plans
2. To ensure that skills and knowledge are transferred to operations and

support staff
3. To ensure there is minimal unpredicted impact on production services
4. To provide cost justifiable IT capacity that is matched to the needs of the

business
a. 1, 2, and 3 only
b. All of the above
c. 1 and 3 only
d. 1, 3, and 4 only
14. Which of the following questions is not answered by Service Portfolio
Management?
a. How should the resources and capabilities be allocated?
b. What opportunities are there in the market?
c. Why should a customer buy these services?
d. What are the pricing or chargeback models?
B-10
15. Which of the following statements are not included in Access Management?
1. Verifying the identity of users requesting access to services
2. Setting the rights or privileges of systems to permit access to authorized

users
3. Defining security policies for system access
4. Monitoring the availability of systems that users should have access to
a. 2 and 4 only
b. 1 and 3 only
c. 2 and 3 only
d. 1 and 2 only
16. What task is not the responsibility of Application Management?
a. Documenting and maintaining the technical skills required to manage and
support Applications
b. Managing applications through their lifecycle
c. Assisting in the decision to build or buy new software
d. Developing operational functionality required by the business
17. If something cannot be measured, it should not be documented within which of
the following items?
a. The Glossary of Terms
b. A Service Level Agreement
c. An Incident Management record
d. A Configuration Item (CI)
18. What is the purpose of the Request Fulfillment process?
a. Dealing with Service Requests from the users
b. Making sure all requests within an IT organization is fulfilled
c. Ensuring fulfillment of Change Requests
d. Making sure the Service Level Agreement is met
B-11
19. Which of the following areas can technology help to support during the Service
Transition phase of the lifecycle?
1. Data mining and workflow tools
2. Measurement and reporting systems
3. Release and Deployment technology
4. Process Design
a. 1, 2, and 3 only
b. 1, 3, and 4 only
c. 2, 3, and 4 only
d. All of the above
20. Which of the following statements is correct about good practice?
a. It can be used to move an organization forward.
b. It is something that is in wide industry use.
c. It is always documented in international standards.
d. It is always based on ITIL.
B-12

As an individual, becoming a Tivoli Certified
Professional has helped me to progress further in
my career and gain job satisfaction. To the
company, it has helped build up the confidence
and trust to the customer. At the end of the day,
you win, the company wins, and the customer
wins.
Special Offer for Having Taken This Course

Now through 31 January 2009: For having completed this course, you are entitled to a 15%
discount on your next exam at any Thomson Prometric testing center worldwide. Use this
special promotion code when registering online or by telephone to receive the discount:
15CSWR. (This offer might be withdrawn. Check with the testing center as described later
in this section.)
Reasons for Certification
It is a demonstration of value to your customer through increased overall

performance with shorter time cycles to deliver applications.
Technical certifications assist technical professionals to obtain more visibility to

potential customers.
Differentiate your skills and knowledge from other non-IBM Certified

professionals.
Role-based Certification
All IBM certifications are based on job roles. They focus on a job a person must do with a
product, not just the products features and functions. The job roles used by Tivoli
Professional Certification include:
IBM Certified Advanced Deployment Professional
IBM Certified Deployment Professional
IBM Certified Administrator
IBM Certified Solution Advisor
IBM Certified Specialist
IBM Certified Operator
When to Attempt a Certification Exam

After completing this course, you should review the test objectives and sample test on the
IBM Certification Web site (URL follows) that correspond with the exam you want to take.
Exams are based on real-world and hands-on experience for the specific certification role.
As an example, for the Deployment Certifications a general guideline is to play a major role
in at least two product deployments, so that you have as much hands-on experience working
with the product as possible before you attempt a deployment exam. Exam questions are
written by experts in the deployment of this product and most of the material covered is
taken from their experience working with the product in real world commercial
environments. You will find supplemental readings and other study material on the Web
site as well.
Location and Cost

All IBM certification exams are available at Thomson Prometric testing centers worldwide.
In addition, testing is offered at a discount or for free at many IBM conferences and events,
including many Tivoli User Group (TUG) meetings. Exam costs vary in different parts of
the world. See the Thomson Prometric Web sites for the exact cost at the testing center you
plan to use.
IBM employees receive a special discount if they take an exam using the PRIME tool at
any IBM location.
A PRIME proctor is required and not all locations have proctors. For more information and
a current list of proctors, see the PRIME URL that follows.
Sources of Additional Information
II
The Tivoli Certification Program

http://www.ibm.com/certify/ or e-mail at certify@us.ibm.com
The Tivoli Certification e-Newsletter (sent out monthly)

Subscribe at tivcert@us.ibm.com
Tivoli Certification Study Guides

http://www.redbooks.ibm.com (search for certification study guide)
Tivoli Support Technical Exchange Calls

http://www.ibm.com/software/sysmgmt/products/support/
supp_tech_exch.html
Tivoli Certification Study Groups

Send an e-mail inquiry to tivcert@us.ibm.com
Thomson Prometric testing centers

http://www.prometric.com
IBM PRIME testing and proctor information (IBM employees only)

http://w3-103.ibm.com/software/xl/portal/
viewcontent?type=doc&srcID=XT&docID=P101658X09146A52

ITIL Book From IBM, IT Service Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ITIL Book From IBM, IT Service Management

Uploaded by

Copyright:

Available Formats

IT Infrastructure Library (ITIL) Foundations v3

Students Training Guide

Unit 1: ITIL Overview

Lesson 1: History of ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

Lesson 2: Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-13

Lesson 3: Process and Service Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-17

Lesson 4: Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-20

Lesson 5: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-27

Lesson 6: Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-29

Lesson 7: Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-31

Lesson 8: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-34

Copyright IBM Corp. 2009

IT Infrastructure Library (ITIL) Foundations v3

Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38

Unit 2: Service Strategy

Lesson 1: Service Strategy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3

Lesson 2: Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13

Lesson 3: The Process of Strategy Generation . . . . . . . . . . . . . . . . . . . . . . .2-25

Lesson 4: The Process of Service Portfolio Management . . . . . . . . . . . . . . .2-43

IT Infrastructure Library (ITIL) Foundations v3

Copyright IBM Corp. 2009

Service Portfolio Process Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51

Lesson 5: The Process of Financial Management . . . . . . . . . . . . . . . . . . . . .2-53

Lesson 6: The Process of Demand Management . . . . . . . . . . . . . . . . . . . . .2-69

Lesson 7: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-75

Unit 3: Service Design

Lesson 1: Service Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

Lesson 2: Process of Service Catalog Management . . . . . . . . . . . . . . . . . . .3-16

IT Infrastructure Library (ITIL) Foundations v3

Service Catalog Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lesson 3: Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29

Lesson 4: Process of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . .3-52

Lesson 5: Process of Availability Management . . . . . . . . . . . . . . . . . . . . . . .3-68

IT Infrastructure Library (ITIL) Foundations v3

Copyright IBM Corp. 2009

Availability Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . 3-89

Lesson 6: Process of IT Service Continuity Management . . . . . . . . . . . . . . .3-92

Lesson 7: Process of Information Security Management . . . . . . . . . . . . . . .3-109

Lesson 8: Process of Supplier Management . . . . . . . . . . . . . . . . . . . . . . . .3-126

Lesson 9: Service Design Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-142

Lesson 10: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-146

Unit 4: Service Transition

Lesson 1: Service Transition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3

IT Infrastructure Library (ITIL) Foundations v3

Service Knowledge Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

Lesson 2: Process of Transition Planning and Support . . . . . . . . . . . . . . . . .4-14

Lesson 3: Process of Change Management . . . . . . . . . . . . . . . . . . . . . . . . .4-28

Lesson 4: Process of Service Asset and Configuration Management . . . . . .4-54

IT Infrastructure Library (ITIL) Foundations v3

Copyright IBM Corp. 2009

Lesson 5: Process of Release and Deployment Management . . . . . . . . . . . .4-74

Lesson 6: Process of Service Validation and Testing . . . . . . . . . . . . . . . . . .4-91

Lesson 7: Process of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-103

Lesson 8: Process of Knowledge Management . . . . . . . . . . . . . . . . . . . . . .4-112

Lesson 9: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-124

Unit 5: Service Operation

Lesson 1: Service Operation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3

IT Infrastructure Library (ITIL) Foundations v3

Service Operation Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

Lesson 2: Process of Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18

Lesson 3: Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-32

Lesson 4: Process of Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . .5-61

IT Infrastructure Library (ITIL) Foundations v3