ITIL 2011 Foundation Handbook

ITIL 2011
Foundation
PEOPLECERT Accredited Training Organization (ATO), PMI Global Registered

Education Provider (REP), and Microsoft Learning Partner
Registered
Education
Provider
Project
Management
Institute
KnowledgeWoods ITIL 2011 Foundation HandBook

Published by
KnowledgeWoods Consulting Pvt. Ltd.
New Delhi, INDIA
Published Version- 1.0: October 2014
Copyright 2014 by KnowledgeWoods Consulting, New Delhi - INDIA.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scaning or otherwise, without
either the prior written permission of the Publisher, or proper authorization.
I
MODULE
INTRODUCTION
Table of Contents
Module
1.
Title
Page
Introduction............................................................................ 3 - 43
1. Assessment ....................................................................... 45 - 47
2.
Service Life Cycle..................................................................... 49 - 84

2. Assessment ....................................................................... 85 - 87
3.
Service Strategy....................................................................... 89 - 129

3. Assessment ....................................................................... 131 - 133
4.
Service Design......................................................................... 135 - 230

4. Assessment ....................................................................... 231 - 235
5.
Service Transition.................................................................... 237 - 311

5. Assessment ....................................................................... 313 - 317
6.
Service Operation.................................................................... 319 - 413

6. Assessment ....................................................................... 415 - 419
7.
Continual Service Improvement.............................................. 421 - 444

7. Assessment ....................................................................... 445 - 448
Activities.................................................................................. 449- 458

Job Aids.................................................................................... 459 - 469
Sample Exams Paper................................................................ 471 - 495
Answers................................................................................... 497 - 507
Axelos Limited 2014. All rights reserved. Material is reproduced under license from AXELOS
ITIL is a registered trademark of AXELOS Limited.
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
INTRODUCTION
Co
INTRODUCTION
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
siti o
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
n
Tra
MODULE
INTRODUCTION
I
MODULE
INTRODUCTION
Learning Objectives
At the end of this module, participants will be able to:
1. Describe and explain the concept of Service and IT Service
Management.
2. Describe and explain the concept of Best Practice.
3. Describe Internal and External Services, Internal and External
Customers.
4. Describe the concept of Service Provider and explain Service
Provider types.
5. Describe Process Model and Process Characteristics.
6. Identify and Describe Functions and Roles in an organization.
7. Define RACI.
I
MODULE
INTRODUCTION
Basics
1. Business-IT Alignment
2. Best Practice and ITIL
3. Sources and Enablers of Best Practice
4. Why is ITIL successful?
5. Definition of Service
6. Definition of IT Service Management
I
MODULE
INTRODUCTION
What is IT? The meaning of IT changes with Context
01
02
IT as Component: IT is a collection of systems, applications

and infrastructures which are components or
subassemblies of a larger product.
IT as Organization: IT is an organization with its own set

of capabilities and resources. IT organizations can be of
various types such as business functions, shared services
units and enterprise-level core units.
03
IT as Service: IT is a category of services utilized by business.

The services are typically IT applications and infrastructure that
are packaged and offered by internal IT organizations
or external service providers
04
IT as Asset: IT is a category of business assets that provide

a stream of benefits to their business owners, including
but not limited to, revenue, income and profit. IT costs
are treated as investments.
What is IT? The meaning of IT changes with Context

Information technology (IT) is a commonly used term that changes meaning depending
on the different perspectives that a business organization or people may have of it. A key
challenge is to recognize and balance these perspectives when communicating the value of IT
service management (ITSM) and understanding the context for how the business sees the IT
organization. Some of these meanings are:
1.
IT is a collection of systems, applications and infrastructures which are components

or subassemblies of a larger product. They enable or are embedded in processes and
services.
2.
IT is an organization with its own set of capabilities and resources. IT organizations

can be of various types such as business functions, shared services units and enterpriselevel core units.
I
MODULE
INTRODUCTION
3.
IT is a category of services utilized by business. The services are typically IT applications

and infrastructure that are packaged and offered by internal IT organizations or external
service providers. IT costs are treated as business expenses.
4.
IT is a category of business assets that provide a stream of benefits for their owners,
including, but not limited to, revenue, income and profit. IT costs are treated as
investments. Every IT organization should act as a service provider, using the principles
of service management to ensure that they deliver the outcomes required by their
customers.
I
MODULE
INTRODUCTION
Business IT Alignment
1. In simple terms, the alignment between IT and business means
that IT delivers what business needs to their satisfaction and also
is able to play a strategic role in shaping new business strategy.
2. An underlying assumption is that this feat is achieved in a cost
effective manner with a relentless pursuit of absorbing new
technology opportunities for business benefits.
3. IT and business affect each other and, therefore, there is a need
for a closer alignment between the two.
I
MODULE
INTRODUCTION
Definition of Best Practice & ITIL

Best Practice
Proven activities or processes that have been successfully used by
multiple organizations. ITIL is an example of Best Practice.
What is ITIL?
ITIL is part of a suite of best-practice publications for IT service
management (ITSM). ITIL provides guidance to service providers on
the provision of quality IT services, and on the processes, functions
and other capabilities needed to support them.
Definition of Best Practice & ITIL

What is ITIL?
ITIL is part of a suite of best-practice publications for IT service management (ITSM). ITIL
provides guidance to service providers on the provision of quality IT services, and on the
processes, functions and other capabilities needed to support them. ITIL is used by many
hundreds of organizations around the world and offers best-practice guidance to all types of
organization that provide services. ITIL is not a standard that has to be followed; it is guidance
that should be read and understood, and used to create value for the service provider and its
customers. Organizations are encouraged to adopt ITIL best practices and to adapt them to
work in their specific environments in ways that meet their needs.
I
MODULE
INTRODUCTION
ITIL is successful because it describes practices that enable organizations to deliver benefits,
return on investment and sustained success. ITIL is adopted by organizations to enable them
to:
i.
Deliver value for customers through services.
ii. Integrate the strategy for services with the business strategy and customer needs.
iii. Measure, monitor and optimize IT services and service provider performance.
iv. Manage the IT investment and budget.
v.
Manage risk.
vi. Manage knowledge.

vii. Manage capabilities and resources to deliver services effectively and efficiently.
viii. Enable adoption of a standard approach to service management across the enterprise.
ix. Change the organizational culture to support the achievement of sustained success.
x. Improve the interaction and relationship with customers.
xi. Coordinate the delivery of goods and services across the value network.
xii. Optimize and reduce costs.
10
I
MODULE
INTRODUCTION
Sources and Enabler of Best Practice
Sources
(generate)
Standards
Employees
Industry practices
Customers
Academic research
Suppliers
Training and education
Advisers
Internal experience
Drivers
(filter)
Enablers
(aggregate)
Technologies
Substitutes
Competition
Regulators
Compliance
Customers
Commitments
Scenarios
(filter)
Knowledge fit for business

Objectives, context and purpose
Sources and Enabler of Best Practice

Organizations benchmark themselves against peers and seek to close gaps in capabilities.
One way to close such gaps is the adoption of good practices in wide industry use. There are
several sources for good practices including public frameworks, standards, and the proprietary
knowledge of organizations and individuals
1.
Public frameworks and standards are attractive when compared with proprietary
knowledge:
2.
Proprietary knowledge is deeply embedded in organizations and therefore difficult to

adopt, replicate, or transfer even with the cooperation of the owners. Such knowledge
is often in the form of tacit knowledge, which is inextricable and poorly documented.
Proprietary knowledge is customized for the local context and specific business needs to
the point of being idiosyncratic. Unless the recipients of such knowledge have matching
circumstances, the knowledge may not be as effective in use.
11
I
MODULE
INTRODUCTION
3.
Owners of proprietary knowledge expect to be rewarded for their longterm investments.

They may make such knowledge available only under commercial terms through
purchases and licensing agreements.
4.
Publicly available frameworks and standards such as ITIL, LEAN, Six Sigma, COBIT,
CMMI,PRINCE2, PMBOK, ISO 9000, ISO/IEC 20000 and ISO/IEC 27001 are validated
across a diverse set of environments and situations rather than the limited experience
of a single organization. They are subject to broad review across multiple organizations
and disciplines, and vetted by diverse sets of partners, suppliers and competitors.
5.
The knowledge of public frameworks is more likely to be widely distributed among a

large community of professionals through publicly available training and certification.
It is easier for organizations to acquire such knowledge through the labour market.
Ignoring public frameworks and standards can needlessly place an organization at a

disadvantage. Organizations should cultivate their own proprietary knowledge on top of a
body of knowledge based on public frameworks and standards. Collaboration and coordination
across organizations become easier on the basis of shared practices and standards.
12
I
MODULE
INTRODUCTION
Why is ITIL successful?

ITIL embraces a practical approach to service by adapting a common framework of
practices that unite all areas of IT service provision towards a single aim that of
delivering value to the business.
Vendor-neutral ITIL service management practices are applicable in any IT organization because
they are not based on any particular technology platform or industry type. ITIL is currently
owned by AXELOS Ltd and is not tied to any commercial proprietary practice or solution.
Non-prescriptive ITIL offers robust, mature and time tested practices that have applicability to
all types of service organizations. It continues to be useful and relevant in public and private
sectors, internal and external service providers, small, medium and large enterprises, and
within any technical environment.
Best practice ITIL represents the learning experiences and thought leadership of the worlds
best-in-class service providers.
ITIL is successful because it describes practices that enable organizations to deliver benefits, return on
investment and sustained success.
Why is ITIL successful?

ITIL embraces a practical approach to service management do what works. And what works
is adapting a common framework of practices that unite all areas of IT service provision
towards a single aim that of delivering value to the business. The following list defines the
key characteristics of ITIL that contribute to its global success:
1.
Vendor-neutral ITIL service management practices are applicable in any IT organization

because they are not based on any particular technology platform or industry type. ITIL
is ITIL is currently owned by AXELOS Ltd and is not tied to any commercial proprietary
practice or solution.
13
I
MODULE
INTRODUCTION
1.
Non-prescriptive ITIL offers robust, mature and time-tested practices that have
applicability to all types of service organization. It continues to be useful and relevant
in public and private sectors, internal and external service providers, small, medium and
large enterprises, and within any technical environment. Organizations should adopt
ITIL and adapt it to meet the needs of the IT organization and their customers.
2.
Best practice ITIL represents the learning experiences and thought leadership of the
worlds best-in-class service providers.
14
I
MODULE
INTRODUCTION
Service - Definition
1. Services are a means of delivering value to customers by facilitating
the outcomes customers want to achieve without the ownership of
specific costs and risks. Services facilitate outcomes by enhancing
the performance of associated tasks and reducing the effect of
constraints.
2. Customer satisfaction is very important. Customers need to
be satisfied with the level of service and feel confident in the
ability of the service provider to continue providing that level of
service or even improving it over time.
Service - Definition
Services: Services are a means of delivering value to customers by facilitating the outcomes
customers want to achieve without the ownership of specific costs and risks. Services
facilitate outcomes by enhancing the performance of associated tasks and reducing the
effect of constraints. These constraints may include regulation, lack of funding or capacity, or
technology limitations. The end result is an increase in the probability of desired outcomes.
While some services enhance performance of tasks, others have a more direct impact they
perform the task itself.
The preceding paragraph is not just a definition, as it is a recurring pattern found in a wide
range of services. Patterns are useful for managing complexity, costs, flexibility and variety.
They are generic structures useful to make an idea applicable in a wide range of environments
and situations. In each instance the pattern is applied with variations that make the idea
effective, economical or simply useful in that particular case.
15
I
MODULE
INTRODUCTION
Customer satisfaction is also important. Customers need to be satisfied with the level of
service and feel confident in the ability of the service provider to continue providing that level
of service or even improving it over time. The difficulty is that customer expectations keep
shifting, and a service provider that does not track this will soon find itself losing business. ITIL
Service Strategy is helpful in understanding how this happens, and how a service provider can
adapt its services to meet the changing customer environment. Services can be discussed in
terms of how they relate to one another and their customers, and can be classified as core,
enabling or enhancing.
16
I
MODULE
INTRODUCTION
IT Service management
1. 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.
2. IT Service: A service provided by an IT service provider. An IT
service is made up of a combination of information technology,
people and process.
IT Service management
ITSM must be carried out effectively and efficiently. Managing IT from a business perspective
enables organizational high performance and value creation. A good relation between an IT
service provider and its customers relies on the customer receiving an IT service that meets
its needs, at an acceptable level of performance and at a cost that customer can afford.
The IT service provider needs to work out how to achieve a balance between these three
areas, and communicate with the customer if there is anything that prevents it from being
able to deliver the required IT service at the agreed level of performance or price.
17
I
MODULE
INTRODUCTION
Outcome
Outcome: The result of carrying out an activity, following a process,
or delivering an IT service etc. The term is used to refer to intended
results, as well as to actual results
An outcome-based definition of service moves IT organizations
beyond businessIT alignment towards businessIT integration.
Internal dialogue and discussion on the meaning of services is
an elementary step towards alignment and integration with a
customers business.
Outcome
An outcome-based definition of service moves IT organizations beyond businessIT alignment
towards businessIT integration. Internal dialogue and discussion on the meaning of services
is an elementary step towards alignment and integration with a customers business .
Customer outcomes become the ultimate concern of business relationship managers instead
of the gathering of requirements, which is necessary but not sufficient. Requirements are
generated for internal coordination and control only after customer outcomes are well
understood. Customers seek outcomes but do not wish to have accountability or ownership
of all the associated costs and risks. All services must have a budget when they go live and this
must be managed. The service cost is reflected in financial terms such as return on investment
(ROI) and total cost of ownership (TCO). The customer will only be exposed to the overall cost
or price of a service, which will include all the providers costs and risk mitigation measures
(and any profit margin if appropriate). The customer can then judge the value of a service
based on a comparison of cost or price and reliability with the desired outcome.
18
I
MODULE
INTRODUCTION
Service Provider and IT Service Provider

1. Service Provider: An organization supplying services to one or
more internal or external customers.
2. IT Service Provider: A service provider that provides IT services
to internal or external services.

ITSM concepts are often described in the context of only one of these types and as if only one
type of IT service provider exists or is used by a given organization. In reality most organizations
have a combination of IT service providers. In a single organization it is possible that some IT
units are dedicated to a single business unit, and yet others have been outsourced or depend
on external service providers.
Many IT organizations who traditionally provide services to internal customers find that they
are dealing directly with external users because of the online services that they provide.
19
I
MODULE
INTRODUCTION
Types of Service Providers

There are three main types of service provider
Type I (Internal Service Provider)
An internal service provider that is embedded within a business unit.
There may be several Type I service providers within an organization.
Type II (Shared Services Unit)

An internal service provider that provides shared IT services to more
than one business unit.
Type III (External Service Provider)

A service provider that provides IT services to external customers.
Types of Service Providers

IT service provider: A service provider that provides IT services to internal or external
customers.
Service providers: There are three main types of service provider. While most aspects of
service management apply equally to all types of service provider, other aspects such as
customers, contracts, competition, market spaces, revenue and strategy take on different
meanings depending on the specific type. The three types are:
1.
Type I internal service provider An internal service provider that is embedded within
a business unit. There may be several Type I service providers within an organization.
20
I
MODULE
INTRODUCTION
1.
Type II shared services unit An internal service provider that provides shared IT services
to more than one business unit.
2.
Type III external service provider A service provider that provides IT services to external
customers.
ITSM concepts are often described in the context of only one of these types and as if only one
type of IT service provider exists or is used by a given organization. In reality most organizations
have a combination of IT service providers. In a single organization it is possible that some IT
units are dedicated to a single business unit, others provide shared services, and yet others
have been outsourced or depend on external service providers.
Many IT organizations who traditionally provide services to internal customers find that they
are dealing directly with external users because of the online services that they provide. ITIL
Service Strategy provides guidance on how the IT organization interacts with these users, and
who owns and manages the relationship with them.
21
I
MODULE
INTRODUCTION
Type I Internal Service Provider

Corporate
Corporate Business
Function
Marketing
R&D Strategic
Planning
Government
affairs
Coatings
(BU)
Plastics
(BU)
Textiles
(BU)
Human
Resources
Finance and
admin
Customer Care
IT
Human
Resources
Finance
and admin
Customer Care
IT
Human
Resources
Finance
and admin
Customer Care
IT
Type I Internal Service Provider

An internal service provider that is embedded within a business unit. There may be several
Type I service providers within an organization.
In the figures shown above, all the service providers under Coating BU, Plastics BU and Textiles
BU are Internal Service Providers. They provide services to their Business Unit. In other words
each business unit has its own service provider. Type I service providers are service providers
that are dedicated to, and often embedded within, an individual business unit. The business
units themselves may be part of a larger enterprise or parent organization.
22
I
MODULE
INTRODUCTION
Type II Shared Services Unit

Corporate
Corporate
Business Function
Coatings
(BU)
Plastics
(BU)
Textiles
(BU)
Business Services
(SSU)
Service
Catalogue
Service
Catalogue
Human Resources
Finance and
Administration
Customer Care
Service
Catalogue
Logistics
Service
Catalogue
Service
Catalogue
Information
Technology
BU: Business Unit
SSU: Shared Services Unit
Type II Shared Services Unit

An internal service provider that provides shared IT services to more than one business unit.
Functions such as finance, IT, human resources, and logistics are not always at the core of an
organizations competitive advantage. Hence, they need not be maintained at the corporate
level where they demand the attention of the chief executives team. Instead, the services
of such shared functions are consolidated into an autonomous special unit called a shared
services unit (SSU). In the above diagram IT is shown as a single department with a service
catalogue available to multiple business units.
23
I
MODULE
INTRODUCTION
Type III External Service Provider

Corporate
Corporate
Business Function
Coatings
(BU)
Plastics
(BU)
Textiles
(BU)
External
Providers
Alpha Co.
Beta Inc.
Service
Catalogue
Service
Catalogue
Service
Catalogue
Gamma Ltd
Service
Catalogue
Delta Plc
Service
Catalogue
Type III External Service Provider

A service provider that provides IT services to external customers.
The business strategies of customers sometimes require capabilities readily available from a
Type III provider. The additional risks that Type III providers assume over Type I and Type II are
justified by increased flexibility and freedom to pursue opportunities. Type III providers can offer
competitive prices and drive down unit costs by consolidating demand. Certain business strategies
are not adequately served by internal service providers such as Type I and Type II. Customers may
pursue sourcing strategies requiring services from external providers. The motivation may be
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.
24
I
MODULE
INTRODUCTION
Stakeholders in Service Management

Stakeholders have an interest in an organization, project or
service etc. and may be interested in the activities, targets,
resources or deliverables from service management.
Examples: Organizations, service providers, customers,
consumers, partners, employees
Within the service provider organization there are many
different stakeholders including the functions, groups and
teams that deliver the services. There are also many different
stakeholders external to the service provider organization.
Examples: customers, users, suppliers.
Stakeholders in Service Management

Stakeholders have an interest in an organization, project or service etc. and may be interested
in the activities, targets, resources or deliverables from service management. Examples
include organizations, service providers, customers, consumers, users, partners, employees,
shareholders, owners and suppliers. The term organization is used to define a company,
legal entity or other institution. It is also used to refer to any entity that has people, resources
and budgets for example, a project or business.
Within the service provider organization there are many different stakeholders including
the functions, groups and teams that deliver the services. There are also many stakeholders
external to the service provider organization, for example:
1.
Customers Those who buy goods or services. The customer of an IT service provider is
the person or group who defines and agrees the service level targets. This term is also
sometimes used informally to mean user for example, This is a customer-focused
organization.
25
I
MODULE
INTRODUCTION
2.
Users Those who use the service on a day-today basis. Users are distinct from customers,
as some customers do not use the IT service directly.
3.
Suppliers Third parties 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.
26
I
MODULE
INTRODUCTION
Internal and External customers

There is a difference between customers who work in the same organization as the IT
service provider, and customers who work for another organization
Internal customers are people or departments who work in the same organization as
the service provider.
For Example: the marketing department is an internal customer of the IT organization
because it uses IT services
External customers are people who are not employed by the organization, or
organizations that are separate legal entities, that purchase services from the service
provider in terms of a legally binding contract or agreement.
For example: an airline might obtain consulting services from a large consulting firm.
Two-thirds of the contract value is paid in cash, and one-third is paid in air tickets at an
equivalent value.
Internal and External Customers

Regardless of how consistently customers and consumers are treated, they are not all the
same. There is a difference between customers who work in the same organization as the
IT service provider, and customers who work for another organization. Internal customers
are people or departments who work in the same organization as the service provider. For
example, the marketing department is an internal customer of the IT organization because
it uses IT services. The head of marketing and the CIO both report to the chief executive
officer (CEO). If IT charges for its services, the money paid is an internal transaction in the
organizations accounting system i.e. not real revenue.
External customers are people who are not employed by the organization, or organizations
that are separate legal entities, that purchase services from the service provider in terms of
a legally binding contract or agreement. When the service provider charges for services they
are paid with real money, or through an exchange of services or products.
27
I
MODULE
INTRODUCTION
For example, an airline might obtain consulting services from a large consulting firm. Twothirds of the contract value is paid in cash, and one-third is paid in air tickets at an equivalent
value.
Dealing with External Customers: Many IT organizations who traditionally provide services to
internal customers find that they are dealing directly with external customers because of the
online services that they provide. It is important that the service strategy clearly identifies
how the IT organization interacts with these customers, and who owns and manages the
relationship with them.
It is very important to note that both internal and external customers must be provided
with the agreed level of service, with the same levels of customer service. The way in which
services are designed, transitioned, delivered and improved, however, is often quite different.
The difference between internal and external customers is a theme throughout this publication,
and the differences between them will be make the investments. It is money that belongs to
the organization they both work for, and is not revenue. What business outcomes will this
investment drive, and how will this specific location achieve these objectives more effectively
than the cheaper location? In this case the service provider has an important check-andbalance role to play, while the customer is required to demonstrate what the return will be
on the investment, and to justify to senior management why the cheaper alternative is not
acceptable.
28
I
MODULE
INTRODUCTION
Internal and External Services

Services
Internal
Services
External
Services
Internal services are delivered between

departments or business units in the
same organization.
External services are delivered to

external customers.
The reason for differentiating between internal and external services is to

differentiate between services that support an internal activity, and those
that actually achieve business outcomes.

Just as there are internal and external customers, there are internal and external services.
Internal services are delivered between departments or business units in the same organization.
External services are delivered to external customers. The reason for differentiating between
internal and external services is to differentiate between services that support an internal
activity, and those that actually achieve business outcomes. The difference may not appear
to be significant at first, since the activity to deliver the services is often similar. However, it
is important to recognize that internal services have to be linked to external services before
their contribution to business outcomes can be understood and measured.
Note on external customer-facing services: Internal IT organizations are not the only providers
of external services to customers. Outsourcers, internet service providers and cloud service
providers are all examples of organizations that are in the business of providing external
services and the technology departments providing these services are business units,
supported by internal IT service providers.
29
I
MODULE
INTRODUCTION

External
Customer
External
Customer
The Business
Business Unit
(Internal Customer)
External
Customer
External
Customer
External
Customer
External
Customer
Business Unit
(Internal Customer)
IT
IT Department
IT Department
IT Department
External customer-facing services

IT Services
Internal customer-facing services

Supporting services (internal)
Business services and products provided by other business units

IT services: An IT service is a service that is 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 customers business processes. It is made up of a combination of people, processes and
technology.
A business process can be distributed across technologies and applications, span geographies,
have many users and yet still reside wholly in the data centre. To integrate business processes,
IT frequently employs bottom-up integration, stitching together a patchwork of technology
and application components that were never designed to interact at the business process
layer. What begins as an elegant top-down business design frequently deteriorates into a
disjointed and inflexible IT solution, disconnected from the goals of the business.
30
I
MODULE
INTRODUCTION
A better strategy for supporting these business processes is to start by defining the outcomes
and then identifying the IT services that support them, and after that defining how supporting
services will be aligned to support the entire chain of dependencies.
Business services and products provided by other business units: A business service is defined
as 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. Although IT is not
directly responsible for the businesss services and products, it is responsible for providing IT
services which will enable the outcomes to be met. Thus it is important that IT knows what
these services are, how the business uses IT services and how these services are measured.
This will directly impact the way in which ITs contribution to the organization is met. One
way of doing this is to define the business activities needed to produce the outcomes as vital
business functions.
31
I
MODULE
INTRODUCTION
Definition of Process and Process Characteristics
Measurability
Process: A process is a structured set of

activities designed takes one or more
defined inputs and turns them into
defined outputs.
Specific results
Customers
Responsiveness
Processes define actions, dependencies

and sequence. Well- defined processes
can improve productivity within and
across organizations and functions.
Process characteristics include:
Process characteristics include
Definition of Process and Process Characteristics

Definition: Process: A process is a structured set of activities designed takes one or more
defined inputs and turns them into defined outputs. Processes define actions, dependencies
and sequence. Well-defined processes can improve productivity within and across
organizations and functions.
Processes define actions, dependencies and sequence. Well-defined processes can improve
productivity within and across organizations and functions. Process characteristics include:
1.
Measurability: We are able to measure the process in a relevant manner. It is performance

driven. Managers want to measure cost, quality and other variables while practitioners
are concerned with duration and productivity.
32
I
MODULE
INTRODUCTION
1.
Specific results: The reason a process exists is to deliver a specific result. This result
must be individually identifiable and countable.
2.
Customers: Every process delivers its primary results to a customer or stakeholder.

Customers may be internal or external to the organization, but the process must meet
their expectations.
3.
Responsiveness to specific triggers: While a process may be ongoing or iterative, it

should be traceable to a specific trigger.
33
I
MODULE
INTRODUCTION
Process Model
Process control
Process owner
Triggers
Process policy
Process
Process feedback
Process
Process metrics
Process
inputs
Process
procedures
Process roles
Process
improvements
Process work
Process
outputs
Including process
Reports and
reviews
Process enables
Process
Process resources
Process Model
A process is organized around a set of objectives. The main outputs from the process should
be driven by the objectives and should include process measurements (metrics), reports and
process improvement.
The output produced by a process has to conform to operational norms that are derived
from business objectives. If products conform to the set norm, the process can be considered
effective If the activities of the process are carried out with a minimum use of resources, the
process can also be considered efficient.
Inputs are data or information used by the process and may be the output from another
process. A process, or an activity within a process, is initiated by a trigger. A trigger may be the
arrival of an input or other event. For example, the failure of a server may trigger the event
management and incident management processes.
34
I
MODULE
INTRODUCTION
Processes
A process is organized around a set of objectives.
The main outputs from the process should be driven by the objectives and should
include process measurements (metrics), reports and process improvement.
Inputs are data or information used by the process and may be the output from
another process.
A process may include any of the roles, responsibilities, tools and management
controls required to deliver the outputs reliably.
A process may include any of the roles, responsibilities, tools and management
controls required to deliver the outputs reliably.
Processes
A process may include any of the roles, responsibilities, tools and management controls
required to deliver the outputs reliably. A process may define policies, standards, guidelines,
activities and work instructions if they are needed. Processes, once defined, should be
documented and controlled. Once under control, they can be repeated and managed. Process
measurement and metrics can be built into the process to control and improve the process.
Process analysis, results and metrics should be incorporated in regular management reports
and process improvements.
35
I
MODULE
INTRODUCTION
Organizing for IT Service Management - Functions, Roles

A function is a team or group of people and the tools or other resources
they use to carry out one or more processes or activities.
In smaller organizations, one person
or group can perform multiple
functions for example, a technical
management department could
also incorporate the service desk
function.
In larger organizations, a function

may be broken out and performed
by several departments, teams
and groups, or it may be embodied
within a single organizational unit
(e.g. the service desk).
Role
A role is a set of responsibilities, activities and authorities granted to a person or team. A role
is defined in a process or function. 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.
Organizing for IT Service Management - Functions, Roles

Roles: A number of roles need to be performed during the service lifecycle. The core ITIL
publications provide guidelines and examples of role descriptions. These are not exhaustive
or prescriptive, and in many cases roles will need to be combined or separated. Organizations
should take care to apply this guidance in a way that suits their own structure and objectives.
Roles are often confused with job titles but it is important to realize that they are not the
same. Each organization will define appropriate job titles and job descriptions which suit their
needs, and individuals holding these job titles can perform one or more of the required roles. It
should also be recognized that a person may, as part of their job assignment, perform a single
task that represents participation in more than one process. For example, a technical analyst
who submits a request for change (RFC) to add memory to a server to resolve a performance
problem is participating in activities of the change management process at the same time as
taking part in activities of the capacity management and problem management processes.
36
I
MODULE
INTRODUCTION
Functions: A function is a team or group of people and the tools or other resources they
use to carry out one or more processes or activities. In larger organizations, a function may
be broken out and performed by several departments, teams and groups, or it may be
embodied within a single organizational unit (e.g. the service desk). In smaller organizations,
one person or group can perform multiple functions for example, a technical management
department could also incorporate the service desk function.
37
I
MODULE
INTRODUCTION
Function
Group A group is a number of people who are similar in some way. Groups are usually not
formal organizational structures, but are very useful in defining common processes across
the organization for example, ensuring that all people who resolve incidents complete the
incident record in the same way.
Team A team is a more formal type of group. These are people who work together to achieve
a common objective, but not necessarily in the same organizational structure.
Department Departments are formal organizational structures which exist to perform a

specific set of defined activities on an ongoing basis. Departments have a hierarchical reporting
structure with managers who are usually responsible for the execution of the activities
Division A division refers to a number of departments that have been grouped together,
often by geography or product line. A division is normally self-contained.
Function
For the service lifecycle to be successful, an organization will need to clearly define the roles
and responsibilities required to undertake the processes and activities involved in each lifecycle
stage. These roles will need to be assigned to individuals, and an appropriate organization
structure of teams, groups or functions will need to be established and managed. These are
defined as follows:
Group A group is a number of people who are similar in some way. In ITIL, groups refer to
people who perform similar activities even though they may work on different technologies
or report into different organizational structures or even different companies. Groups are
usually not formal organizational structures, but are very useful in defining common processes
across the organization for example, ensuring that all people who resolve incidents complete
the incident record in the same way.
38
I
MODULE
INTRODUCTION
Team A team is a more formal type of group. These are people who work together to achieve
a common objective, but not necessarily in the same organizational structure. Team members
can be co-located, or work in multiple locations and operate virtually. Teams are useful for
collaboration, or for dealing with a situation of a temporary or transitional nature. Examples
of teams include project teams, application development teams (often consisting of people
from several different business units) and incident or problem resolution teams.
Department Departments are formal organizational structures which exist to perform
a specific set of defined activities on an ongoing basis. Departments have a hierarchical
reporting structure with managers who are usually responsible for the execution of the
activities and also for day-to-day management of the staff in the department.
Division A division refers to a number of departments that have been grouped together,
often by geography or product line. A division is normally self-contained.
39
I
MODULE
INTRODUCTION
RACI Model
RACI is an acronym for the four main roles of :
Responsible: The person or people responsible
for getting the job done. Works on the activity.
The Doer
Accountable: Only one person can be accountable

for each task/Activity to avoid blames. The person
with YES & NO Authority.
Consulted: In the Loop for decision making.The

people who are consulted and whose opinions
are sought.
Informed: Keep Posted. The people who are

kept up-do-date on progress.
RACI helps in defining Roles and Responsibilities in relation to process and activities.
Director service
Management
Service level
Manager
Problem
Manager
Security
Manager
Procurement
Manager
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
RACI Model
When designing a service or a process, it is imperative that all the roles are clearly defined. A
trademark of high-performing organizations is the ability to make the right decisions quickly
and execute them effectively. Whether the decision involves a strategic choice or a critical
operation, being clear on who has input, who decides and who takes action will enable the
organization to move forward rapidly.
A key characteristic of a process is that all related activities need not necessarily be limited
to one specific organizational unit. Service asset and configuration management process
activities, for example, can be conducted in departments such as computer operations, system
40
I
MODULE
INTRODUCTION
programming, application management, network management, systems development and

even non-IT departments such as procurement, warehouse or accounting. Since services,
processes and their component activities run through an entire organization, the individual
activities should be clearly mapped to well-defined roles. The roles and activities are
coordinated by process managers. Once detailed procedures and work instructions have
been developed, an organization must map the defined roles and the activities of the process
to its existing staff. Clear definitions of accountability and responsibility are critical success
factors (CSFs) for any improvement activity. Without this, roles and responsibilities within
the new process can be confusing, and individuals will revert to the way weve always done
it before the new procedures were put in place.
41
I
MODULE
INTRODUCTION
Summary
1. Business IT Alignment
2. Service and IT Service Management.
3. Internal and External Customers
4. Internal and External Services
5. Process and Characteristics
6. RACI
42
I
MODULE
INTRODUCTION
Additional Readings
1. David Nickels, IT Business Alignment: What we know
that we still do not know, 7th Annual conference of the
Southern Association of Information Systems, 2004.
2. Mary Nugent, The Four Phases of IT/Business Alignment,
CIO update, December 2004.
3. Jerry N Luftman, Raymond Papp, and Tom Brier, Enablers
and Inhibiters of Business IT Alignment, Communications
of AIS, Vol I, Article 11, March 1999.
4. Henderson and Venkataraman, Strategic Alignment:
Leveraging information Technology for transforming
organizations, IBM Systems Journal, pp.472-484, 1993.
5. Management by Process, John Jeston, Elsevier Publishing.
43
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
INTRODUCTION
44
I
MODULE
INTRODUCTION
Assessment
45
I
MODULE
INTRODUCTION
1.
Which of the following statements about processes is CORRECT?

1. All processes must have an owner.
2. A Process takes one or more inputs and turns them into defined outputs.
a. 1 only
b. 2 only
c. Both of the above
d. Neither of the above
2.
The RACI Model ensures which combination of the following roles is allocated for
processes?
a. Responsible, Accountable, Consulted, Informed
b. Responsible, Achievable, Consulted, Informed.
c. Realistic, Accountable, Consulted, Informed.
d. Responsible, Accountable, Corrected, Informed.
3.
Service Management is a set of specialized organizational capabilities for providing

value to customers in the form of services. These specialized organizational capabilities
include which of the following?
a. Application and Infrastructure
b. Functions and Processes
c. Service Pipeline and Catalogue
d. Market and Customers
4.
A Process owner has been identified with and I in a RACI matrix. Which of the following
would be expected of them?
a. Tell others about the progress of an activity
b. Perform an activity
c. Be kept up to date on the progress of an activity
d. Manage an activity.
46
I
MODULE
INTRODUCTION
5.
What should a service always deliver to customers?

a. Applications
b. Infrastructure
c. Value
d. Resources
6.
A process owner is responsible for which of the following?

1. Documenting the process
2. Defining the process Key Performance Indicators
3. Improving the process
4. Performing all activities involved in a process.
a. 1,3 and 4 only
b. All of the above
c. 1,2 and 3 only
d. 1,2 and 4 only
7.
Which of the following is NOT a benefit of using Frameworks and standards?

a. Knowledge of Public Frameworks is more likely to be widely distributed.
b. They are always free ensuring they can be implemented quickly
c. They are validated across a wide range of environments making them more robust
d. They make collaboration between organizations easier by giving a common language.
8.
Which of the following statements about processes is CORRECT?

1. A process is always organized around a set of objectives.
2. A process should be documented.
a. 1 only
b. 2 only
47
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE LIFE CYCLE
48
Co
SERVICE LIFE CYCLE
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
Tra
n
siti o
49
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
2
MODULE
SERVICE LIFE CYCLE
Learning Objectives
After completion of this module participants will be able to:
Identify all the phases of the ITIL Service Lifecycle.
Identify and Understand the Purpose, Objectives and
Scope of Service Strategy, Service Design, Service Transition,
Service Operation and Continual Service Improvement.
50
2
MODULE
SERVICE LIFE CYCLE
ITIL Service Lifecycle

ITIL Service Lifecycle is an approach to IT Service Management that
emphasizes the need and importance of coordination and control
across the various functions, processes, and systems necessary to
manage the full Lifecycle of IT services.
The Service Lifecycle provides insight into:
The way Service Management is structured.
The way various components are linked to each other.
The impact that changes in one component will have on
other components.
ITIL Service Lifecycle

ITIL is part of a suite of best-practice publications for IT service management (ITSM). ITIL
provides guidance to service providers on the provision of quality IT services, and on the
processes, functions and other capabilities needed to support them. ITIL is used by many
hundreds of organizations around the world and offers best-practice guidance to all types of
organization that provide services. ITIL is not a standard that has to be followed; it is guidance
that should be read and understood, and used to create value for the service provider and its
customers. Organizations are encouraged to adopt ITIL best practices and to adapt them to
work in their specific environments in ways that meet their needs.
ITIL is the most widely recognized framework for ITSM in the world. In the 20 years since
it was created, ITIL has evolved and changed its breadth and depth as technologies and
business practices have developed. ISO/IEC 20000 provides a formal and universal standard
for organizations seeking to have their service management capabilities audited and certified.
While ISO/IEC 20000 is a standard to be achieved and maintained, ITIL offers a body of
knowledge useful for achieving the standard. In 2007, the second major refresh of ITIL was
51
2
published in response to significant advancements in technology and emerging challenges
for IT service providers. New models and architectures such as outsourcing, shared services,
utility computing, cloud computing, virtualization, web services and mobile commerce have
become widespread within IT. The process-based approach of ITIL was augmented with the
service lifecycle to address these additional service management challenges. In 2011, as part
of its commitment to continual improvement, the Cabinet Office published this update to
improve consistency across the core publications.
The ITIL framework is based on the five stages of the service lifecycle with a core publication
providing best-practice guidance for each stage. This guidance includes key principles, required
processes and activities, organization and roles, technology, associated challenges, critical
success factors and risks. The service lifecycle uses a hub-and-spoke design, with service
strategy at the hub, and service design, transition and operation as the revolving lifecycle
stages or spokes. Continual service improvement surrounds and supports all stages of the
service lifecycle. Each stage of the lifecycle exerts influence on the others and relies on them
for inputs and feedback. In this way, a constant set of checks and balances throughout the
service lifecycle ensures that as business demand changes with business need, the services
can adapt and respond effectively.
Co
In addition to the core publications, there is also a complementary set of ITIL publications
providing guidance specific to industry sectors, organization types, operating models and
technology architectures.
i nu
nt
e
al S
rvice
Improveme
nt
Service De
sig
n

n
siti o
52
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
n
Tra
MODULE
SERVICE LIFE CYCLE
2
MODULE
SERVICE LIFE CYCLE
Service Strategy Purpose and Objectives

Purpose
The purpose of the service strategy stage of the service lifecycle is to define
the perspective, position, plans and patterns that a service provider needs
to be able to execute to meet an organizations business outcomes.
Objectives
An understanding of what strategy is
A clear identification of the definition of services and the customers
who use them
The ability to define how value is created and delivered
A means to identify opportunities to provide services and how to
exploit them
Service Strategy Purpose and Objectives
The purpose of the service strategy stage of the service lifecycle is to define the
perspective, position, plans and patterns that a service provider needs to be able to execute
to meet an organizations business outcomes.
The objectives of service strategy include providing:
An understanding of what strategy is.
A clear identification of the definition of services and the customers who use them.
The ability to define how value is created and delivered.
A means to identify opportunities to provide services and how to exploit them.
53
2
MODULE
SERVICE LIFE CYCLE
A clear service provision model, that articulates how services will be delivered and
funded, and to whom they will be delivered and for what purpose.
The means to understand the organizational capability required to deliver the strategy.
Documentation and coordination of how service assets are used to deliver services, and
how to optimize their performance.
Processes that define the strategy of the organization, which services will achieve the
strategy, what level of investment will be required, at what levels of demand and the
means to ensure a working relationship exists between the customer and service provider.
54
2
MODULE
SERVICE LIFE CYCLE
Service Strategy Scope

Scope:
Service Strategy is intended for use by both internal and external service
providers, and includes guidance for organizations which are required
to offer IT services as a profitable business, as well as those which are
required to offer IT services to other business units within the same
organization at no profit.
Two aspects of strategy are:

Defining a strategy whereby a service provider will deliver services to
meet a customers business outcomes.
Defining a strategy for how to manage those services.
Service Strategy Scope

Scope: ITIL Service Strategy starts by defining and discussing the generic principles and
processes of service management, and these generic principles are then applied consistently
to the management of IT services. This intended for use by both internal and external service
providers, and includes guidance for organizations which are required to offer IT services as a
profitable business, as well as those which are required to offer IT services to other business
units within the same organization at no profit.
Two aspects of strategy are covered in ITIL Service Strategy:
Defining a strategy whereby a service provider will deliver services to meet a customers
business outcomes.
Defining a strategy for how to manage those services.
55
2
MODULE
SERVICE LIFE CYCLE
Service Strategy Value to Business

Adopting and implementing standard and consistent approaches
for service strategy will:
Support the ability to link activities performed by the service provider
to outcomes that are critical to internal or external customers.
Enable the service provider to have a clear understanding of what
types and levels of service will make its customers successful and
then organize itself optimally to deliver and support those services.
Enable the service provider to respond quickly and effectively to
changes in the business environment, ensuring increased competitive
advantage over time.
Service Strategy Value to Business

Value to business: Selecting and adopting the best practice as recommended in this publication
will assist organizations in delivering significant benefits. Adopting and implementing standard
and consistent approaches for service strategy will:
Support the ability to link activities performed by the service provider to outcomes that
are critical to internal or external customers. As a result, the service provider will be seen
to be contributing to the value (and not just the costs) of the organization.
Enable the service provider to have a clear understanding of what types and levels of
service will make its customers successful and then organize itself optimally to deliver
and support those services. The service provider will achieve this through a process of
defining strategies and services, ensuring a consistent, repeatable approach to defining
how value will be built and delivered that is accessible to all stakeholders.
56
2
MODULE
SERVICE LIFE CYCLE
Enable the service provider to respond quickly and effectively to changes in the business
environment, ensuring increased competitive advantage.
Support the creation and maintenance of a portfolio of quantified services that will
enable the business to achieve positive return on its investment in services.
Facilitate functional and transparent communication between the customer and the
service provider, so that both have a consistent understanding of what is required and
how it will be delivered.
Provide the means for the service provider to organize itself so that it can provide services
in an efficient and effective manner.
57
2
MODULE
SERVICE LIFE CYCLE
Service Design Purpose and Objectives

Purpose of the Service Design
To design IT services, together with the governing IT practices, processes
and policies, to realize the service providers strategy and to facilitate the
introduction of these services into supported environments ensuring quality
service delivery, customer satisfaction and cost effective service provision.
Objective of Service Design

To design IT services so effectively that minimal improvement during their
lifecycle will be required.
Service Design Purpose and Objectives

Purpose of service design: To design IT services, together with the governing IT practices,
processes and policies, to realize the service providers strategy and to facilitate the introduction
of these services into supported environments ensuring quality service delivery, customer
satisfaction and cost effective service provision
Objective of Service Design: The objective of service design is to design IT services so
effectively that minimal improvement during their lifecycle will be required. However,
continual improvement should be embedded in all service design activities to ensure that
solutions and designs become even more effective over time, and to identify changing trends
in the business that may offer improvement opportunities. Service design activities can be
periodic or exception based when they may be triggered by a specific business need or event.
58
2
MODULE
SERVICE LIFE CYCLE
Service Design - Scope
Provides guidance for the design of appropriate and innovative IT

services to meet current and future agreed business requirements.
Service design enforces the principle that the initial Service Design
should be driven by a number of factors, including the functional
requirements, the requirements within the SLAs, the business
benefits and the overall design constraints.
Accomplishment of this activity during the service design stage will ensure
marginal issues arising during the stages of the service life cycle.
Service Design - Scope

Scope: ITIL service design provides guidance for the design of appropriate and innovative IT
services to meet current and future agreed business requirements. It describes the principles
of Service Design and looks at identifying, defining and aligning the IT solution with the
business requirements. It also introduces the concept of the Service Design Package and
looks at selecting the appropriate Service Design model. The publication also discusses the
fundamentals of the design processes and the five aspects of the design.
Service design enforces the principle that the initial Service Design should be driven by a
number of factors, including the functional requirements, the requirements within the
Service Level Agreements (SLAs), the business benefits and the overall design constraints.
These processes are utilized by all other stages of the Service Lifecycle, and other processes
are taken into account by Service Design. However, it is here that Design Coordination, Service
59
2
MODULE
SERVICE LIFE CYCLE
Catalogue Management; Service Level Management, Capacity Management, Availability

Management, IT Service Continuity Management, Information Security Management and
Supplier Management.
All processes within the service lifecycle must be linked closely together for managing,
designing, supporting and maintaining the services, the IT infrastructure, the environment,
the application and the data.
60
2
MODULE
SERVICE LIFE CYCLE
Service Design - Value to Business

The following benefits result from good Service Design practice:
Reduced Total Cost of Ownership (TCO)
Improved quality of service
Improved consistency of service
Easier implementation of new or changed services
Improve service alignment
Improve service performance
Service Design - Value to Business

Selecting and adopting the best practice as recommended in this publication will assist
organizations in delivering significant benefits. With good service design, it is possible to
deliver quality, cost-effective services and to ensure that the business requirements are being
met consistently. Adopting and implementing standard and consistent approaches for service
design will:
Reduced Total Cost of Ownership (TCO): cost of ownership can only be minimized if all
aspects of services, processes and technology are designed properly and implemented
against the design
Improved consistency of service: as services are designed within the corporate strategy,
architectures and constraints
61
2
MODULE
SERVICE LIFE CYCLE
Easier implementation of new or changed services: as there is integrated and full Service
Design and the production of comprehensive SDPs
Improved service alignment: involvement from the conception of the service, ensuring
that new or changed services match business needs, with services designed to meet
Service Level Requirements
More effective service performance: with incorporation and recognition of Capacity,
Financial Availability and IT Service Continuity Plans
Improved IT governance: assist with the implementation and communication of a set of
controls for effective governance of IT
More effective Service Management and IT processes: processes will be designed with
optimal quality and cost-effectiveness
Improved information and decision-making: more comprehensive and effective
measurements and metrics will enable better decision-making and continual improvement
of Service Management practices in the design stage of the Service Lifecycle.
Improve quality of service: Both service and operational quality will be enhanced through
services that are better designed to meet the required outcomes of the customer.
Improve alignment with customer values and strategies: For organizations with
commitments to concepts such as green IT or that establish strategies such as the use
of cloud technologies, service design will ensure that all areas of services and service
management are aligned with these values and strategies.
62
2
MODULE
SERVICE LIFE CYCLE
Service Transition Purpose and Objectives

Purpose
To ensure that new, modified or retired services meet the
expectations of the business as documented in the service strategy
and service design stages of the Lifecycle.
Objectives
Plan and manage service changes efficiently and effectively.
Manage risks related to new, changed or retired services.
Ensure that service changes create the expected business value.
Successfully deploy service releases into supported environments.
Service Transition Purpose and Objectives

Purpose and objectives of service Transition: The purpose of the service transition stage of
the service lifecycle is to ensure that new, modified or retired services meet the expectations
of the business as documented in the service strategy and service design stages of the lifecycle.
The objectives of service transition are to:
Plan and manage service changes efficiently and effectively
Manage risks relating to new, changed or retired services
Successfully deploy service releases into supported environments
Set correct expectations on the performance and use of new or changed services
63
2
MODULE
SERVICE LIFE CYCLE
Ensure that service changes create the expected business value

Provide good-quality knowledge and information about services and service assets.
In order to achieve these objectives, there are many things that need to happen during the
service transition lifecycle stage. These include:
Planning and managing the capacity and resources required to manage service transitions
Implementing a rigorous framework for evaluating service capabilities and risk profiles
before new or changed services are deployed
Establishing and maintaining the integrity of service assets
Providing efficient repeatable mechanisms for building, testing and deploying services
and releases
Ensuring that services can be managed, operated and supported in accordance with
constraints specified during the service design stage of the service lifecycle.
64
2
MODULE
SERVICE LIFE CYCLE
Service Transition - Scope

Scope
Provides guidance for the development and improvement of
capabilities for transitioning new and changed services into
supported environments, including release planning, building,
testing, evaluation and deployment.
Consideration is given to
Managing the complexity associated with changes to services and
service management processes
Allowing for innovation while minimizing the unintended
consequences of change
Introducing new services
Service Transition - Scope

Scope: ST provides guidance for the development and improvement of capabilities for
transitioning new and changed services into the production environment, including release
planning building, testing, evaluation and deployment. The guidance focuses on how to ensure
the requirements of Service Strategies, set out in Service Design, are effectively realized in
Service Operations while controlling the risks of failure and disruption.
Consideration is given to:
Managing the complexity associated with changes to services and Service Management
processes
Allowing for innovation while minimizing the unintended consequences of change
The introduction of new services
65
2
MODULE
SERVICE LIFE CYCLE
Changes to existing services, e.g. expansion, reduction, change of supplier, acquisition or

disposal of sections of user base or suppliers, change of requirements or skills availability
De-commissioning and discontinuation of services, applications or other service
components
Transfer of services to and from other service providers.
Guidance on transferring the control of services includes transfer in the following
circumstances:
Out to a new supplier, e.g. outsourcing, off-shoring
From one supplier to another
Back in from a supplier, e.g. insourcing
To or from an external service provider
Moving to a shared service provision (e.g. partial outsource of some processes)
Multiple suppliers, e.g. smart-sourcing
Joint venture
Partnering
Down-sizing, up-sizing (right-sizing)
Merger and acquisition.
In reality, circumstances generate a combination of several of the above options at any one
time and in any one situation. The scope also includes the transition of changes in the service
providers service management capabilities that will impact on the ways of working, the
organization, people, projects and third parties involved in service management.
66
2
MODULE
SERVICE LIFE CYCLE
Service Transition - Value to Business

Adopting and implementing standard and consistent approaches for service
transition will:
Enable projects to estimate the cost, timing, resource requirement
and risks associated with the ST stage more precisely
Result in higher volumes of successful change
Easier for people to adopt and follow
Ensure that new or changed services will be maintainable and
cost-effective
Improve control of service assets and configurations.
Value to business:
Selecting and adopting the best practices in this publication will assist organizations in delivering
significant benefits. It will help readers to set up service transition and the processes that
support it, and to make effective use of those processes to facilitate the effective transitioning
of new, changed or decommissioned services. Adopting and implementing standard and
consistent approaches for Service Transition will:
Enable projects to estimate the cost, timing, resource requirement and risks associated
with the Service Transition stage more accurately.
Result in higher volumes of successful change.
Be easier for people to adopt and follow.
67
2
MODULE
SERVICE LIFE CYCLE
Enable Service Transition assets to be shared and re-used across projects and services.
Reduce delays from unexpected clashes and dependencies, e.g. in test environments.
Reduce the effort spent on managing the Service Transition test and pilot environments.
Improve expectation setting for all stakeholders involved in Service Transition including
customers, users, suppliers, partners and projects.
Increase confidence that the new or changed service can be delivered to specification
without unexpectedly affecting other services or stakeholders.
Ensure that new or changed services will be maintainable and cost effective.
Improve control of service assets and configurations.
68
2
MODULE
SERVICE LIFE CYCLE
Service Operation Purpose and Objectives

Purpose
To coordinate and carry out the activities and processes required to deliver
and manage services at agreed levels to business users and customers.
Ongoing management of the technology that is used to deliver and
support services.
Objectives
Maintain business satisfaction and confidence in IT through effective and
efficient delivery and support of agreed IT service.
Minimize the impact of service outage on days-to-days business activities.
Ensure that access to agreed IT services is only provided to those
authorized to receive those services.

Purpose: The purpose of Service Operation is to coordinate and carry out the activities
and processes required to deliver and manage services at agreed levels to business users
and customers. Service Operation is also responsible for the 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 the day-today
operation of those processes is not properly conducted, controlled and managed. Nor will
service improvements be possible if day-to-day activities to monitor performance, assess
metrics and gather data are not systematically conducted during Service Operation.
Staff involved in the service operation stage of the service lifecycle should have processes
and support tools in place that allow them to have an overall view of service operation and
delivery (rather than just the separate components, such as hardware, software applications
69
2
MODULE
SERVICE LIFE CYCLE
and networks, that make up the end-to-end service from a business perspective). These
processes and tools should also detect any threats or failures to service quality. As services
may be provided, in whole or in part, by one or more partner/supplier organizations, the
service operation view of the end-to-end service should be extended to encompass external
aspects of service provision. When necessary, shared or interfacing processes and tools
should be deployed to manage cross-organizational workflows.
70
2
MODULE
SERVICE LIFE CYCLE
Service Operation - Scope
The guidance provided by Service Operation includes:

The Services Themselves
Service Management Processes
Technology
People

Scope: ITIL Service Operation describes the processes, functions, organization and tools used
to underpin the ongoing activities required to deliver and support services.
The services themselves: Activities that form part of a service are included in service
operation, whether it is performed by the service provider, an external supplier or the
user or customer of that service.
Service management processes: The ongoing management and execution of the many
service management processes that are performed in service operation. Even though
a number of ITIL processes (such as change and capacity management) originate at the
service design or service transition stage of the service lifecycle, they are in use continually
in service operation. Some processes are not included specifically in service operation,
such as strategy management for IT services and the actual design process itself. These
71
2
MODULE
SERVICE LIFE CYCLE
processes focus more on longer term planning and improvement activities, which are
outside the direct scope of service operation; however, service operation provides input
and influences these processes regularly as part of the lifecycle of service management.
Technology: 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. Therefore a large part of ITIL Service Operation is concerned with
the management of the infrastructure used to deliver services.
People: Regardless of what services, processes and technology are managed, they are
all about people. It is people who drive the demand for the organizations services and
products and it is people who decide how this will be done. Ultimately, it is people who
manage the technology, processes and services. Failure to recognize this will result
(and has resulted) in the failure of service management activities.
72
2
MODULE
SERVICE LIFE CYCLE
Service Operation - Value to Business

Adopting and implementing standard and consistent approaches
for service operation will
Reduce unplanned labour and costs for both the business and IT
through optimized handling of service outages and identification of
their root causes.
Reduce the duration and frequency of service outages which will
allow the business to take full advantage of the value created by the
services they are receiving.
Meet the goals and objectives of the organizations security policy by
ensuring that IT services will be accessed only by those authorized
to use them
Value to business: Selecting and adopting the best practice as recommended in this publication
will assist organizations in delivering significant benefits.
Adopting and implementing standard and consistent approaches for service operation will:
Reduce unplanned labour and costs for both the business and IT through optimized
handling of service outages and identification of their root causes.
Reduce the duration and frequency of service outages which will allow the business to
take full advantage of the value created by the services they are receiving.
Provide operational results and data that can be used by other ITIL processes to improve
services continually and provide justification for investing in ongoing service improvement
activities and supporting technologies.
73
2
MODULE
SERVICE LIFE CYCLE
Meet the goals and objectives of the organizations security policy by ensuring that
IT services will be accessed only by those authorized to use them.
Provide quick and effective access to standard services which business staff can use to
improve their productivity or the quality of business services and products.
Provide a basis for automated operations, thus increasing efficiencies and allowing
expensive human resources to be used for more innovative work, such as designing
new or improved functionality or defining new ways in which the business can exploit
technology for increased competitive advantage.
74
2
MODULE
SERVICE LIFE CYCLE
Continual service Improvement - Purpose

The purpose of CSI is to IT services with changing business needs by identifying
and implementing improvements to IT services that support business processes.
CSI is always seeking ways to improve service effectiveness, process
effectiveness and cost effectiveness.
Measurement of performance is important factor, consider the following sayings about
measurement and management:
You cannot manage

what you cannot
control.
You cannot control

what you cannot
measure.
You cannot measure

what you cannot
define.

The purpose and objectives of CSI: The purpose of CSI is to IT services with changing business
needs 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. CSI is always seeking ways
to improve service effectiveness, process effectiveness and cost effectiveness.
Consider the following saying about measurements and management:
You cannot manage what you cannot control.
You cannot control what you cannot measure.
You cannot measure what you cannot define.
75
2
MODULE
SERVICE LIFE CYCLE
If service and processes are not implemented, managed and supported using clearly defined
goals, objectives and relevant measurements that lead to actionable improvements, the
business will suffer. Depending upon the criticality of a specific IT service to the business,
the organization could lose productive hours, experience higher costs, loss of reputation or,
perhaps, even a business failure. That is why it is critically important to understand what to
measure, why it is being measured and what the successful outcome should be.
76
2
MODULE
SERVICE LIFE CYCLE
Continual service Improvement - Objectives

Objectives:
Review and analyse Service Level Achievement results.
Identify and implement individual activities to improve IT service quality and
improve the efficiency and effectiveness of enabling 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.
Ensure that processes have clearly defined objectives and measurements that leads
to actionable improvement.
Continual service Improvement - Objectives:

Review, analyse and make recommendations on improvement opportunities in each
lifecycle phase: Service Strategy, Service Design, Service Transition and Service Operation.
Review and analyse Service Level Achievement results.
Identify and implement individual activities to improve IT service quality and improve the
efficiency and effectiveness of enabling ITSM processes.
Improve cost effectiveness of delivering IT services without sacrificing customer
satisfaction.
77
2
MODULE
SERVICE LIFE CYCLE
Ensure applicable quality management methods are used to support continual

improvement activities.
Ensure that processes have clearly defined objectives and measurements that leads to
actionable improvement
Understand what to measure, why it is being measured and what the successful outcome
should be.
78
2
MODULE
SERVICE LIFE CYCLE
Continual service Improvement - Scope

There are four main areas that CSI needs to address:
The overall health of ITSM as a discipline
The continual alignment of the portfolio of IT services with the

current and future business needs
The maturity of the enabling IT processes for each service in a
continual service lifecycle model.
Continual improvement of all aspects of the IT service and the
service assets that support them
Continual service Improvement - Scope

Scope: ITIL Continual Service Improvement provides guidance in four main areas:
The overall health of ITSM as a discipline
The continual alignment of the portfolio of IT services with the current and future
business needs
The maturity of the enabling IT processes for each service in a continual service
lifecycle model.
Continual improvement of all aspects of the IT service and the service assets that
support them.
79
2
MODULE
SERVICE LIFE CYCLE
To implement CSI successfully it is important to understand the different activities that can be
applied to CSI. The following activities support a continual process improvement plan:
Reviewing management information and trends to ensure that services are meeting
agreed service levels
Reviewing management information and trends to ensure that the output of the enabling
ITSM processes are achieving the desired results
Periodically conducting maturity assessments against the process activities and roles
associated with the process activities to demonstrate areas of improvement or, conversely,
areas of concern
Periodically conducting internal audits verifying employee and process compliance
Reviewing existing deliverables for relevance
Making ad-hoc recommendations for approval
Periodically proposing recommendations for improvement opportunities
Periodically conducting customer satisfaction surveys
Conducting external and internal service reviews to identify CSI opportunities
Measurements and identifying the values created by CSI improvements
These activities do not happen automatically. They must be owned within the IT organization
which is capable of handling the responsibility and possesses the appropriate authority to
make things happen. They must also be planned and scheduled on an ongoing basis. By
default, improvement becomes a process within IT with defined activities, inputs, outputs,
roles and reporting. CSI must ensure that ITSM processes are developed and deployed in
support of an end-to-end service management approach to business customers. It is essential
to develop an ongoing continual improvement strategy for each of the processes as well as
the services.
80
2
MODULE
SERVICE LIFE CYCLE
The deliverables of CSI must be reviewed on an ongoing basis to verify completeness,

functionality and feasibility to ensure that they remain relevant and do not become stale
and unusable. It is also important to ensure that monitoring of quality indicators and metrics
will identify areas for process improvement. Since any improvement initiative will more than
likely necessitate changes, specific improvements will need to follow the defined ITIL Change
Management process
81
2
MODULE
SERVICE LIFE CYCLE
Value CSI Provide to Business

Adopting and implementing standards and consistent
approaches for CSI will:
Lead to gradual and continual improvement in service quality, where
justified
Ensure that IT service remain continuously aligned to business
requirements
Result in gradual improvement in cost effectiveness through the
reduction in costs and / or the capability to handle more work at the
same time.
Value CSI Provide to Business

Value to business: Selecting and adopting the best practice as recommended will assist
organization in delivering significant benefits. It will help readers to set up CSI and the
process that supports it, and to make effective use of the process to facilitate the effective
improvement of service quality.
Adopting and implementing standards and consistent approaches for CSI will:
Lead to gradual and continual improvement in service quality, where justified.
Ensure that IT service remain continuously aligned to business requirements.
82
2
MODULE
SERVICE LIFE CYCLE
Result in gradual improvement in cost and / or the capability to handle more work at the
same time.
Use monitoring and reporting to identify opportunities for improvement in a lifecycle
stages and in all process.
Identify opportunities for improvements in organizational structures, resourcing
capabilities, partners, technology, staff skills and training, and communications.
83
2
MODULE
SERVICE LIFE CYCLE
Summary
IT Service Management that give emphasis to the need and significance of
coordination and control across the various processes, functions, and systems
necessary to manage the full Lifecycle of IT services.
The service strategy stage of the service lifecycle is to define the perspective,
position, plans and patterns that a service provider needs to be able to execute
to meet an organizations business outcomes
The Service Design state of the lifecycle is design IT services, together with the
governing IT practices, processes and policies, to realize the service providers
strategy and to facilitate the introduction of these services into supported
environments ensuring quality service delivery, customer satisfaction and cost
effective service provision.
The service transition stage of the service lifecycle is to ensure that new, modified
or retired services meet the expectations of the business as documented in the
service strategy and service design stages of the Lifecycle
Service Operation is to coordinate and carry out the activities and processes
required to deliver and manage services at agreed levels to business users and
customers.
CSI is to continually align and re-align IT services to the changing business needs
by identifying and implementing improvements to IT services that support
business processes.
84
2
MODULE
SERVICE LIFE CYCLE
Assessment
85
2
MODULE
SERVICE LIFE CYCLE
1.
Which stage of the service lifecycle is most concerned with defining policies and
objectives?
a. Service Design
b. Service Transition.
c. Service Strategy
d. Service Operation
2.
Service Transition contains detailed descriptions of which processes?

a. Change Management, Service Asset and Configuration Management, Release and
Deployment Management.
b. Change Management, Capacity Management, Event Management, Service Request
Management.
c. Service Level Management, Service Portfolio Management, Event Management,
and Service Request Management.
d. Service Asset and Configuration Management, Release & Deployment, Request
Fulfilment Management.
3.
In which core publications can you find description of Service Catalogue Management,
Information Security Management, Supplier Management.
a. Service Design
b. Service Transition.
c. Service Strategy
86
2
MODULE
SERVICE LIFE CYCLE
4.
Which of the following are goals of Service Operations?

1. To coordinate and carry out the activities and processes required to deliver and
manage services at agreed levels to the business.
2. The successful release of services into the live environment.
a. 1 only
b. 2 only
c. Both of the above.
d. Neither of the above.
5.
Which of the following provides guidance on the design and development of services
and service management processes?
a. Service Operation
b. CSI
c. Service Design
d. Service Transition
87
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
88
Co
SERVICE STRATEGY
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
Tra
n
siti o
89
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
3
MODULE
SERVICE STRATEGY
Learning Objectives
At the end of this module participants will be able to:
Understand and explain the key concept of Service Strategy.
Understand how Service Strategy processes contribute to the
Service Lifecycle.
Understand the Key Principle of Service Strategy.
Understand and explain the Purpose , Objectives and Scope of:
Service Portfolio Management.
Demand Management.
Financial Management for IT Services.
Business Relationship Management.
90
3
MODULE
SERVICE STRATEGY
Service Strategy
Service Strategy provides best-practice guidance for the service strategy
stage of the ITIL service lifecycle.
Service Strategy provides guidance on how to view service management
not only as an organizational capability but as a strategic asset. It describes
the principles underpinning the practice of service management which
are useful for developing service management policies, guidelines and
processes across the ITIL service lifecycle.
The purpose of the service strategy stage of the service lifecycle is to define
the perspective, position, plans and patterns that a service provider needs
to be able to execute to meet an organizations business outcomes.
91
3
MODULE
SERVICE STRATEGY
Generic Concepts - Utility and Warranty

Fit for Purpose functionality
offered by a product or service
to meet a particular need.
UTILITY
Performance supported?
OR
T/F
Constraints removed?
Value Created
AND
Available enough?
T/F
Capacity enough?
AND
Connuous enough?
Secure enough?
Fit for Use a promise or

guarantee that availability,
capacity, continuity, and
security are all meeting
customer expectations.
T/F
WARRANTY
T: True
F: False
Generic Concepts - Utility and Warranty

Customers cannot benefit from something that is fit for purpose but not fit for use, and vice
versa. The value of a service is therefore only delivered when both utility and warranty are
designed and delivered. Figure above illustrates the logic that a service has to have both
utility and warranty to create value. Utility is used to improve the performance of the tasks
required to achieve an outcome, or to remove constraints that prevent the task from being
performed adequately (or both). Warranty requires the service to be available, continuous
and secure and to have sufficient capacity for the service to perform at the required level. If
the service is both fit for purpose and fit for use, it will create value.
It should be noted that the elements of warranty in the figure are not exclusive. It is possible
to define other components of warranty, such as usability, which refers to how easy it is for
the user to access and use the features of the service to achieve the desired outcomes. The
warranty aspect of the service needs to be designed at the same time as the utility aspect in
92
3
MODULE
SERVICE STRATEGY
order to deliver the required value to the business. Attempts to design warranty aspects after
a service has been deployed can be expensive and disruptive.
Information about the desired business outcomes, opportunities, customers, utility and
warranty of the service is used to develop the definition of a service. Using anoutcomebased definition helps to ensure that managers plan and execute all aspects of service
management from the perspective of what is valuable to the customer.
93
3
MODULE
SERVICE STRATEGY
Service Assets - Resources and Capabilities

CAPABILITIES
RESOURCES
Management
Financial capital
Organization
Infrastructure
Processes
Applications
Knowledge
Information
People(experience, skills
and relationships)
People
(number of employees)
Capabilities : The ability of an organization, person, process, application, Configuration

Item, or IT service to carry out an activity. Capabilities are intangible assets and cannot
produce value by themselves, without adequate and appropriate resources.
Resources: Include IT infrastructure, people, money, or anything else that might help
deliver an IT service. Typically, resources are tangible assets and are relatively easier
to acquire than capabilities.
Service Assets - Resources and Capabilities

Assets, Resources and Capabilities: The service relationship between service providers and
their customers revolves around the use of assets both those of the service provider and
those of the customer. Each relationship involves an interaction between the assets of each
party. Many customers use the service they receive from a service provider to build and deliver
services or products of their own and then deliver them on to their own customers. In these
cases, what the service provider considers to be the customer asset would be considered to
be a service asset by their customer. Without customer assets, there is no basis for defining
the value of a service. The performance of customer assets is therefore a primary concern for
service management.
94
3
MODULE
SERVICE STRATEGY
There are two types of asset used by both service providers and customers resources
and capabilities. Organizations use them to create value in the form of goods and services.
Resources are direct inputs for production. Capabilities represent an organizations ability
to coordinate, control and deploy resources to produce value. Capabilities are typically
experience-driven, knowledge-intensive, information-based and firmly embedded within an
organizations people, systems, processes and technologies. It is relatively easy to acquire
resources compared to capabilities.
95
3
MODULE
SERVICE STRATEGY
Types of Services
Core, enabling and enhancing services
All services, whether internal or external, can be further classified in terms of how they
relate to one another and their customers. Services can be classified as core, enabling
or enhancing and examples of these services are provided in table in next page.
Enabling services could be

Aid offered by loan officers in assessing working capital needs and
collateral
The application-processing service
Flexible disbursement of loan funds
Types of Services
Core, enabling and enhancing services: All services, whether internal or external, can be
further classified in terms of how they relate to one another and their customers. To illustrate
this in another context, the core services of a bank could be providing financial capital to
small and medium enterprises. Value is created for the banks customers only when the bank
can provide financial capital in a timely manner (after having evaluated all the costs and risk
of financing the borrower). Enabling services could be:
Aid offered by loan officers in assessing working capital needs and collateral.
The application-processing service.
Flexible disbursement of loan funds.
A bank account into which the borrower can electronically transfer funds.
96
3
MODULE
SERVICE STRATEGY
As basic factors, enabling services only give the provider an opportunity to serve the
customer. Enabling services are necessary for customers to use the core services satisfactorily.
Customers generally take such services for granted, and do not expect to be additionally
charged for the value of such services. Examples of commonly offered enabling services are
service desks, payment, registration and directory services.
97
3
MODULE
SERVICE STRATEGY
Examples of core, enabling and enhancing services
IT services
(office automation)
IT services
(benefits tracking)
Core service
Enabling service
Enhancing service
Word processing
Download and
installation of
updates
Document publication
to professional printer
for highquality
brochure
A portal that provides

a user friendly frontend access to the
benefits tracking
service.
Customers can
create and manage a
fitness or weight loss
programme. Customers
who show progress in
their programme are
awarded a discount on
their premiums.
Employees of a company
can monitor the status
of their benefits (such
as health insurance and
retirement accounts).
Examples of core, enabling and enhancing services

In most markets, enabling services will allow the minimum requirements for operation,
although many provide the foundation for differentiation, but it is the enhancing services that
will provide the differentiation itself the excitement factor. Examples of enhancing services
are more difficult to provide, particularly because they tend to drift over time to be subsumed
into core or enabling services. In other words, what is exciting to a customer today becomes
expected if it is always delivered.
An example is the provision of a broadband internet service in a hotel room. A few years ago
the provision of a chargeable broadband service might have been regarded as a differentiator
(this hotel offers this service, other comparative hotels do not). As more and more hotels
started to offer this service, customers came to regard it as essential so it became an
enabling service. Hotels then started to offer free broadband internet services so for a
time this was an enhancing service, but that is now more common, and is quickly becoming
a necessary (and thus enabling) service. For some travellers this service has actually become
part of the core, in the same way, say, as an en-suite bathroom.
98
3
MODULE
SERVICE STRATEGY
Service Portfolio Management

The purpose of service portfolio management is to ensure that the service
provider has the right mix of services to balance the investment in IT with the
ability to meet business outcomes.
Objectives:
Provide a process and mechanisms to enable an organization to
investigate and decide on which services to provide, based on an
analysis of the potential return and acceptable level of risk.
Maintain the definitive portfolio of services provided, articulating
the business needs each service meets and the business outcomes
it supports.
Provide a mechanism for the organization to evaluate how services
enable it to achieve its strategy, and to respond to changes in its
internal or external environments.

Purpose and objectives: The purpose of service portfolio management is to ensure that the
service provider has the right mix of services to balance the investment in IT with the ability
to meet business outcomes. It tracks the investment in services throughout their lifecycle
and works with other service management processes to ensure that the appropriate returns
are being achieved. In addition, it ensures that services are clearly defined and linked to the
achievement of business outcomes, thus ensuring that all design, transition and operation
activities are aligned to the value of the services.
The objectives of service portfolio management are to:
Provide a process and mechanisms to enable an organization to investigate and decide
on which services to provide, based on an analysis of the potential return and acceptable
level of risk.
99
3
MODULE
SERVICE STRATEGY
Maintain the definitive portfolio of services provided, articulating the business needs
each service meets and the business outcomes it supports.
Provide a mechanism for the organization to evaluate how services enable it to achieve
its strategy, and to respond to changes in its internal or external environments.
Control which services are offered, under what conditions and at what level of investment.
Track the investment in services throughout their lifecycle, thus enabling the organization
to evaluate its strategy, as well as its ability to execute against that strategy.
Analyse which services are no longer viable and when they should be retired.
100
3
MODULE
SERVICE STRATEGY
Service Portfolio Management Purpose and Objectives

Scope
All services a service provider
plans to deliver, those currently
delivered and those that have
been withdrawn from service.
The primary concern of service

portfolio management is
whether the service provider
is able to generate value from
the services. Service portfolio
management will therefore
track investments in services
and compare them to the
desired business outcomes.
Service Portfolio Management Purpose and Objectives

Scope: The scope of service portfolio management is all services a service provider plans
to deliver, those currently delivered and those that have been withdrawn from service. The
primary concern of service portfolio management is whether the service provider is able
to generate value from the services. Service portfolio management will therefore track
investments in services and compare them to the desired business outcomes.
Internal service providers will need to work with the business units in the organization to link
each service to the business outcomes before they can compare investment with returns.
External service providers tend to evaluate value more directly, as each service needs to be
able to generate revenue directly, or support revenue-generating services. The generation
of revenue in an efficient manner will, in turn, facilitate profitability. Service portfolio
management evaluates the value of services throughout their lifecycles, and must be able
to compare what newer services have offered over the retired services they have replaced.
101
3
MODULE
SERVICE STRATEGY
Service Portfolio Management Concepts Overview

The Service Portfolio Represents
The commitments and investments made by a service provider across all customers
and market spaces.
Present contractual commitments, new service development and ongoing service
improvement plans initiated by CSI.
The portfolio also includes third-party services, which are an integral part of service
offerings to customers.
Some third-party services are visible to the customers (e.g. desktop repairs) while
others are not (e.g. wide area networking services).
Service portfolio is the complete set of services that is managed by a service provider.
Service Portfolio Management Concepts Overview

The service portfolio: 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 plans
initiated by CSI. The portfolio also includes third-party services, which are an integral part of
service offerings to customers. Some third-party services are visible to the customers (e.g.
desktop repairs) while others are not (e.g. wide area networking services).
In other words, the service portfolio is the complete set of services that is managed by a
service provider. The service portfolio also identifies those services in a conceptual stage,
namely all services the organization would provide if it had unlimited resources, capabilities
and funding. This documentation exercise facilitates understanding of the opportunity costs
of the existing portfolio and better fiscal discipline. If a service provider understands what it
cannot do, then it is better able to assess if it should keep doing what it is doing or re-allocate
its resources and capabilities.
102
3
MODULE
SERVICE STRATEGY
The Service Portfolio

Service porolio
Service
pipeline
Rered
services
Service catalogue
Configuraon management system
Customer
porolio
Applicaon
porolio
Supplier and contract

management informaon
system
Customer
agreement
porolio
Project
porolio
CMDB
Figure above illustrates the components of Service Portfolio

Service Pipeline: Is a database or structured document listing all services that are under
consideration or development, but are not yet available to customers. It also includes major
investment opportunities, such as data center relocation or virtualization project. This
is because these investments have to be traced to the delivery of services and the value
realized. The service pipeline provides a business view of possible future services and is part
of the service portfolio that is not normally published to customers.
Service Catalogue: Is 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 process.
103
3
MODULE
SERVICE STRATEGY
Retired Services: Some services in the service portfolio are phased out or retired. There is
a decision to be made by each organization, following a service review, on when to move a
service from catalogue to retired. Some organizations do this when the service is no longer
available to new customers, even though the service is still being delivered to existing
customers. Other organizations will only move the service out of the catalogue when it is no
longer delivered to any customers.
104
3
MODULE
SERVICE STRATEGY
Demand Management
The Purpose of demand management is to understand, anticipate
and influence customer demand for services and to work with
capacity management to ensure the service provider has capacity
to meet this demand.
Objectives
Identify and analyse patterns of business activity to understand
the levels of demand that will be placed on a service
Define and analyse user profiles to understand the typical profiles
of demand for services from different types of user.
Ensure that services are designed to meet the patterns of business
activity and the ability to meet business outcomes.
Demand Management
The purpose of demand management is to understand, anticipate and influence customer
demand for services and to work with capacity management to ensure the service provider
has capacity to meet this demand. Demand management works at every stage of the lifecycle
to ensure that services are designed, tested and delivered to support the achievement of
business outcomes at the appropriate levels of activity.
This is where the service provider has the opportunity to understand the customer needs and
feed these into the service strategies to realize the service potential of the customer and to
differentiate the services to the customers.
105
3
MODULE
SERVICE STRATEGY
The objectives of demand management are to:
Identify and analyse patterns of business activity to understand the levels of demand
that will be placed on a service.
Define and analyse user profiles to understand the typical profiles of demand for services
from different types of user.
Ensure that services are designed to meet the patterns of business activity and the ability
to meet business outcomes.
Work with capacity management to ensure that adequate resources are available at
the appropriate levels of capacity to meet the demand for services, thus maintaining a
balance between the cost of service and the value that it achieves.
Anticipate and prevent or manage situations where demand for a service exceeds the
capacity to deliver it.
Gear the utilization of resources that deliver services to meet the fluctuating levels of
demand for those services.
106
3
MODULE
SERVICE STRATEGY
Demand Management
Scope
The scope of the demand management process is to identify and
analyse the patterns of business activity that initiate demand for
services, and to identify and analyse how different types of user
influence the demand for services.
Demand management activities should include:
Identifying and analysing patterns of business activity associated with
services
Identifying user profiles and analysing their service usage patterns
Identifying, agreeing and implementing measures to influence demand
together with capacity management
Demand Management
Scope: The scope of the demand management process is to identify and analyse the patterns
of business activity that initiate demand for services, and to identify and analyse how
different types of user influence the demand for services. Demand management activities
should include:
Identifying and analysing patterns of business activity associated with services.
Identifying user profiles and analysing their service usage patterns.
107
3
MODULE
SERVICE STRATEGY
Identifying, agreeing and implementing measures to influence demand together with

capacity management. This is sometimes called the management of demand. This could
be in situations where service demand exceeds capacity, and where capacity increases
are not feasible (e.g. differential charging, incentives, penalties).
It could also be in situations where a new service has been launched and IT wishes to encourage
users to use it more. Also, it could be used to reduce demand in peak utilization times and
shift it to less active times thus more efficiently balancing overall utilization levels. Demand
management is active in every stage of the service lifecycle, and works closely with several
other processes. One of the closest of these is capacity management. The fundamental
difference between demand and capacity management is shown in next page.
108
3
MODULE
SERVICE STRATEGY
Comparison of Demand Management and Capacity Management

Demand management
Capacity management
Purpose
Identify, analyse and influence

customer demand for services and
the capacity to meet this demand
Ensure that current and future

capacity requirements of services
are provided cost effectively, and
that services are performing at the
agreed level
Focus
Anticipating the demand for services

based on user profiles and patterns
of business activity, and identifying
the means to influence that demand
to achieve an optimal balance
between investment and business
outcome achievement
Understanding the current and

future requirements for resources
and capabilities and ensuring that
these are designed, tested and
managed to meet the demand on
services
Major
Activities
Identifying patterns of business

activity, user profiles and the
resulting demand on services.
Anticipating increases or decreases
in demand, and identifying strategies
for dealing with these. Influencing
demand through incentives,
penalties or differential charging
Producing a capacity plan to ensure

the investment in the appropriate
levels of capacity. Ensuring optimal
use and performance of resources.
Evaluating the impact of new or
changed resources and capabilities
on existing performance levels
Comparison of Demand Management and Capacity Management

At first glance the scopes of capacity and demand management seem to overlap, and it might
appear that demand management is just one aspect of capacity management. However,
this is an oversimplification of both processes. Both are concerned with achieving the same
business outcomes, and both are concerned with optimizing investment, but the processes
themselves are different. To generalize, demand management focuses primarily on the
business and user aspects of providing services, whereas capacity management focuses
primarily on the resourcing and technology aspects.
109
3
MODULE
SERVICE STRATEGY
Demand Management Key Concept

Patterns of Business Activity
Services are designed to enable business activities, which in turn
achieve business outcomes.
Patterns of business activity (PBA) represent the dynamics of the
business and include interactions with customers, suppliers, partners
and other stakeholders.
Once a PBA has been identified, a PBA profile should be drawn up and details about
the PBA documented. The following items need to be documented:
Classification This
indicates the type of
PBA, and could refer
to where it originates
(user or automated),
Attributes Such as
frequency, volume,
location and
duration.
Requirements Such
as performance,
security, availability,
privacy, latency or
tolerance for delays.
Service asset requirements

Design teams will draft
a utilization profile for
each PBA in terms of what
resources it uses, when and
how much of each resource
Demand Management Key Concept

Patterns of business activity: Services are designed to enable business activities, which in
turn achieve business outcomes. Thus every time a business activity is performed, it generates
demand for services. Customer assets such as people, processes and applications all perform
business activities, and because of the way these assets are organized or because of the tasks
they are completing, this activity will tend to be performed in patterns. These patterns of
business activity (PBA) represent the dynamics of the business and include interactions with
customers, suppliers, partners and other stakeholders.
Since PBA operate in a dynamic environment, they are often dynamic themselves. However,
since services often directly support one or more PBA, and since PBA achieve business
outcomes it is important that they are properly understood and aligned to services. This
requires that they have to be properly defined and documented and changes properly
controlled. Once a PBA has been identified, a PBA profile should be drawn up and details
about the PBA documented. The following items need to be documented:
110
3
MODULE
SERVICE STRATEGY
Classification This indicates the type of PBA, and could refer to where it originates (user
or automated), the type and impact of outcomes supported, and the type of workload
supported.
Attributes Such as frequency, volume, location and duration.
Requirements Such as performance, security, availability, privacy, latency or tolerance for
delays.
Service asset requirements Design teams will draft a utilization profile for each PBA in terms
of what resources it uses, when and how much of each resource. If the quantity of resources
is known, and the pattern of utilization is known, the capacity management process will be
able to ensure that resources are available to meet the demand provided it stays within the
forecast range.
111
Demand Management
Example B:
Consulng
company
550
Number of mesheet transacons
MODULE
SERVICE STRATEGY
Example B weekly PBA: Consultants

need access to a timesheet system to
track their activities so that customers
can be billed. Most consultants wait
until the end of the week to complete
their timesheets. Some consultants
record their activities daily.
500
450
400
350
300
250
200
150
100
50
Time (days)
Demand Management
Figure illustrates a PBA.
In example B in Figure a consulting company relies on a timesheet service to bill consultants
time. Since most consultants complete their timesheets for the entire week at the end of
the week, the later it is in the week the more critical the service, and the more it is utilized.
Consultants may need to be encouraged to log their time at the end of each day, or the
beginning of the next day.
112
3
MODULE
SERVICE STRATEGY
Business Activity Influences Patterns of Demand

for Services
Demand paern
Paern of
business
acvity
Business
process
Service
process
Service belt
Capacity
management
plan
Delivery schedule
Incenves and
penales to influence
consumpon
Demand
management
113
3
MODULE
SERVICE STRATEGY
Financial Management for IT Services Purpose and Objectives

The purpose of financial management for IT services is to secure the
appropriate level of funding to design, develop and deliver services that
meet the strategy of the organization.
At the same time this is a gatekeeper that ensures that the service
provider does not commit to services that they are not able to provide.
Objectives
Defining and maintaining a framework to identify, manage and
communicate the cost of providing services.
Evaluating the financial impact of new or changed strategies on the
service provider.
Securing funding to manage the provision of services.
Financial Management for IT Services Purpose and Objectives

Purpose: The purpose of financial management for IT services is to secure the appropriate level
of funding to design, develop and deliver services that meet the strategy of the organization.
At the same time financial management for IT services is a gatekeeper that ensures that the
service provider does not commit to services that they are not able to provide. Financial
management for IT services identifies the balance between the cost and quality of service
and maintains the balance of supply and demand between the service provider and their
customers.
For example, a customer asks an internal service provider to provide a service at a certain
level. If the service provider is able to quantify the initial investment and ongoing costs of that
service, the customer can make a decision as to whether that service will provide sufficient
value to cover the costs. If the internal service provider is not able to quantify the costs, then
they will be put under significant pressure to deliver the service at the highest possible level.
114
3
MODULE
SERVICE STRATEGY
The objectives of financial management for IT services include:

Defining and maintaining a framework to identify, manage and communicate the cost of
providing services.
Evaluating the financial impact of new or changed strategies on the service provider.
Securing funding to manage the provision of services.
Facilitating good stewardship of service and customer assets to ensure the organization
meets its objectives. This should be done together with service asset and configuration
management and knowledge management.
Understanding the relationship between expenses and income and ensuring that the two
are balanced according to the organizations financial policies.
Managing and reporting expenditure on service provision on behalf of the organizations
stakeholders.
Executing the financial policies and practices in the provision of services.
Accounting for money spent on the creation, delivery and support of services.
Forecasting the financial requirements for the organization to be able to meet its
service commitments to its customers, and compliance with regulatory and legislative
requirements.
Where appropriate, defining a framework to recover the costs of service provision from
the customer.
115
3
MODULE
SERVICE STRATEGY
Financial Management for IT Services - Scope

Scope: Financial management is normally a well established and
well-understood part of any organization.
Professional accountants manage dedicated finance departments,
which set financial policies, budgeting procedures, financial reporting
standards, accounting practices and revenue generation or cost recovery
rules. In an IT context, financial management is often a separate function
either reporting to the CIO or the chief financial officer (CFO), but with
some form of functional reporting between the two areas.
Financial Management for IT Services - Scope

Scope: Financial management is normally a well established and well-understood part of any
organization. Professional accountants manage dedicated finance departments, which set
financial policies, budgeting procedures, financial reporting standards, accounting practices
and revenue generation or cost recovery rules. In an IT context, financial management is
often a separate function either reporting to the CIO or the chief financial officer (CFO), but
with some form of functional reporting between the two areas. Regardless of where the
function is actually situated in the organization, financial management for IT services is a
specialized area that requires an understanding of the world of finance and business as well
as the world of technology.
A common misunderstanding is that all accountants are the same without understanding
that there are different specializations in accounting. Specifically, financial management for
IT services requires accountants with a good understanding of cost accounting a discipline
often found in manufacturing environments. It is important that the correct skills are specified
when hiring a person to manage IT finances.
116
3
MODULE
SERVICE STRATEGY
Financial policies and practices within IT must be consistent with those of the rest of the
organization. This is not only a requirement of most financial management legislation,
regulations and best practice, but it also facilitates better communication and reporting
between IT and other business units.
117
3
MODULE
SERVICE STRATEGY
Financial Management for IT Services - Processes

Financial management consists of three main processes:
Budgeting This is the process of predicting and controlling the income and
expenditure of money within the organization. Budgeting consists of a
periodic negotiation cycle to set budgets (usually annual) and the monthly
monitoring of the current budgets.
Accounting This is the process that enables the IT organization to account
fully for the way its money is spent (particularly the ability to identify costs by
customer, by service and by activity). It usually involves accounting systems,
including ledgers, charts of accounts, journals etc. and should be overseen
by someone trained in accountancy.
Charging This is the process required to bill customers for the services
supplied to them. This requires sound IT accounting practices and systems.
Financial Management for IT Services - Processes

In internal service providers financial management plays a translational role between
corporate financial systems and service management. The result of a service-oriented
accounting function is that far greater detail and understanding is achieved regarding service
provision and consumption, and the generation of data that feeds directly into the planning
process. Financial management consists of three main processes:
Budgeting This is the process of predicting and controlling the income and expenditure of
money within the organization. Budgeting consists of a periodic negotiation cycle to set
budgets (usually annual) and the monthly monitoring of the current budgets.
118
3
MODULE
SERVICE STRATEGY
Accounting This is the process that enables the IT organization to account fully for the way
its money is spent (particularly the ability to identify costs by customer, by service and by
activity). It usually involves accounting systems, including ledgers, charts of accounts, journals
etc. and should be overseen by someone trained in accountancy.
Charging This is the process required to bill customers for the services supplied to them. This
requires sound IT accounting practices and systems.
There are two distinct cycles associated with accounting, budgeting and charging:
A planning cycle (annual), where cost projections and workload forecasting form a basis
for cost calculations and price setting
An operational cycle (monthly or quarterly) where costs are monitored and checked
against budgets, bills are issued and revenue collected.
119
3
MODULE
SERVICE STRATEGY
Financial Management for IT Services Business Case

Business case
A business case is a decision support and planning tool that projects
the likely consequences of a business action.
The consequences can take on qualitative and quantitative dimensions.
A financial analysis, for example, is frequently central to a good business
case.
Financial Management for IT Services Business Case

Business case: A business case is a decision support and planning tool that projects the likely
consequences of a business action. The consequences can take on qualitative and quantitative
dimensions. A financial analysis, for example, is frequently central to a good business case.
The structure of a business case varies from organization to organization. What they all have
in common is a detailed analysis of business impact or benefits. Business impact is in turn
linked to business objectives. A business objective is the reason for considering a service
management initiative in the first place. Objectives should start broadly.
120
3
MODULE
SERVICE STRATEGY
For example:
The business objectives for commercial provider organizations are usually the objectives
of the business itself, including financial and organizational performance.
The business objectives of an internal service provider should be linked to the business
objectives of the business unit to which the service is being provided, and the overall
corporate objectives.
The business objectives for not-for-profit organizations are usually the objectives for the
constituents, population or membership served as well as financial and organizational
performance.
121
3
MODULE
SERVICE STRATEGY
Business Relationship Management

The purpose of the business relationship management process is two-fold:
To establish and maintain a business relationship between the service provider
and the customer based on understanding the customer and their business needs.
Objectives
Ensure that the service provider understands the customers
perspective of service
Ensure high levels of customer satisfaction
Establish and maintain a constructive relationship between the
service provider and the customer

Purpose and objectives: The purpose of the business relationship management process is
two-fold:
To establish and maintain a business relationship between the service provider and the
customer based on understanding the customer and their business needs.
To identify customer needs and ensure that the service provider is able to meet these needs
as business needs change over time and between circumstances. Business relationship
management ensures that the service provider understands these changing needs.
Business relationship management also assists the business in articulating the value of
a service. Put another way, business relationship management ensures that customer
expectations do not exceed what they are willing to pay for, and that the service provider
is able to meet the customers expectations before agreeing to deliver the service.
122
3
MODULE
SERVICE STRATEGY
The objectives of business relationship management include:

Ensure that the service provider understands the customers perspective of service, and
is therefore able to prioritize its services and service assets appropriately.
Ensure high levels of customer satisfaction, indicating that the service provider is meeting
the customers requirements.
Establish and maintain a constructive relationship between the service provider and the
customer based on understanding the customer and their business drivers.
Identify changes to the customer environment that could potentially impact the type,
level or utilization of services provided.
Identify technology trends that could potentially impact the type, level or utilization of
services provided.
Establish and articulate business requirements for new services or changes to existing
services.
Ensure that the service provider is meeting the business needs of the customer.
Work with customers to ensure that services and service levels are able to deliver value.
Mediate in cases where there are conflicting requirements for services from different
business units.
Establish formal complaints and escalation processes for the customer.
123
3
MODULE
SERVICE STRATEGY
Business Relationship Management - Scope

Scope: For internal service providers business relationship management is typically
executed between a senior representative from IT (larger organizations may have
dedicated BRMs) and senior managers (customers) from the business units.
In external service providers business relationship management is often executed
by a separate and dedicated function of BRMs or account managers each one
dedicated to a customer, or group of smaller customers.
The process must focus on understanding and communicating:
Business outcomes that the customer wants to achieve.
Services that are currently offered to the customer, and the way in which they
are used by the customer.
Technology trends that could impact current services and the customer, and
the nature of the potential impact.
Business Relationship Management - Scope

Scope: For internal service providers business relationship management is typically executed
between a senior representative from IT (larger organizations may have dedicated BRMs) and
senior managers (customers) from the business units. Here the emphasis is on aligning the
objectives of the business with the activity of the service provider.
In external service providers business relationship management is often executed by a
separate and dedicated function of BRMs or account managers each one dedicated to a
customer, or group of smaller customers. The emphasis here is on maximizing contract value
through customer satisfaction. Business relationship management focuses on understanding
how services meet customer requirements. To achieve this, the process must focus on
understanding and communicating:
Business outcomes that the customer wants to achieve
Services that are currently offered to the customer, and the way in which they are used
by the customer
124
3
MODULE
SERVICE STRATEGY
The way in which services are currently offered including who is responsible for the
services, what levels of service have been agreed, the quality of services delivered and
any changes that are anticipated
Technology trends that could impact current services and the customer, and the nature
of the potential impact
Levels of customer satisfaction, and what action plans have been put in place to deal
with the causes of dissatisfaction
How to optimize services for the future
How the service provider is represented to the customer. This at times means raising
concerns around commitments that the business made to IT but is not meeting.
125
3
MODULE
SERVICE STRATEGY
Difference Between BRM and SLM

Service Level Management
Purpose
To establish and maintain a business

relationship between the service
provider and the customer based on
understanding the customer and their
business needs.
To identify customer needs (utility and
warranty) and ensure that the service
provider is able to meet these needs.
To negotiate service level

agreements (warranty terms)
with customers and ensure that
all service management processes,
operational level agreements
and underpinning contracts are
appropriate for the agreed service
level targets.
Focus
Strategic and tactical the focus is on

the overall relationship between the
service provider and their customer,
and which services the service provider
will deliver to meet customer needs.
Tactical and operational the focus

is on reaching agreement on the
level of service that will be delivered
for new and existing services, and
whether the service provider was
able to meet those agreements.
Primary
measure
Customer satisfaction, also an

improvement in the customers
intention to better use and pay for the Achieving agreed levels of
service. Another metric is whether service (which leads to customer
customers are willing to recommend satisfaction).
the service to other (potential)
customers.
Difference Between BRM and SLM

From the above points, it is clear that business relationship management depends on a
number of other service management processes and functions. For example, the mapping
of business outcomes and services is done in service portfolio management. Service level
management provides information about the levels of services agreed and achieved.
Configuration management provides a mapping of infrastructure, applications, services,
service owners and customers. Capacity management provides information about utilization
levels and the potential impacts of new technologies.
126
3
MODULE
SERVICE STRATEGY
Unless the relationships between business relationship management and other service
management processes are clearly identified, there is potential for confusion about the
boundaries between them. The main criterion for setting these boundaries is that business
relationship management focuses on the actual relationship between the service provider
and its customers and the levels of customer satisfaction, whereas the other processes focus
on the services themselves, and the extent to which they meet the stated requirements.
This does not mean that business relationship management is unconcerned with the services
themselves, but that it focuses on the overall extent to which the service provider is meeting
the customers needs. It also does not mean that other processes are not concerned with
customer satisfaction, but that they focus on the quality of services and on specific actions
they can take to meet customer expectations for those services. A good example of the
difference between business relationship management and other service management
processes is that of service level management.
Both these processes involve regular interfaces with customers and both are concerned with
ongoing reviews of service and service quality. However, the two processes have different
purposes and the nature and content of the customer interface is different.
It should also be noted that business relationship management is not just concerned with
service delivery and support, but also with the design and building of services. This means
that business relationship management is the primary process for strategic communication
with customers for all departments in the service provider, including application development
teams within the service providers organization.
127
3
MODULE
SERVICE STRATEGY
Governance and IT Governance

Enterprise
Governance
Corporate
Governance
i.e. conformance
Business
Governance
i.e. performance
Value Creation
Resource
Utilization
Accountability
Assurance
Governance and IT Governance

A governance framework is a categorized and structured set of documents that clearly
articulate the strategy, policies and plans of the organization.
IT Governance does not exist as a separate area. Since IT is part of the organization, it cannot
be governed in a different way from the rest of the organization. ISO 38550 refers to corporate
governance and not IT governance.
Although IT governance is not separate from corporate governance, it is important that IT
executives have input into how corporate governance will specify how IT is governed. This is
usually done through steering committee, which also defines IT strategy and is involved in all
major decisions regarding IT and its role in the organization.
As member of the executive of directors the CIO will ensure that the corporate strategies,
policies, rules, and plans include a high level overview of how IT will be governed.
128
3
MODULE
SERVICE STRATEGY
Summary
Defining a strategy whereby a service provider will deliver services to meet a
customers business outcomes and how to manage those services.
Value is defined not only strictly in terms of the customers business outcomes; it
is also highly dependent on customers perceptions and preferences. Perceptions
are influenced by attributes of a service, present or prior experiences with similar
attributes and relative capability of competitors and other peers.
Service Strategy process includes Service Portfolio Management, Demand
Management, Financial Management and Business Relation Management.
Business case, a decision support and planning tool that projects the likely
consequences of a business action. The consequences can take on qualitative
and quantitative dimensions.
BRM and SLM both these processes involve regular interfaces with customers
and both are concerned with ongoing reviews of service and service quality.
However, the two processes have different purposes and the nature and content
of the customer interface is different.
129
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE STRATEGY
130
3
MODULE
SERVICE STRATEGY
Assessment
131
3
MODULE
SERVICE STRATEGY
1.
Which of the following processes contributes MOST to quantifying the financial value
of IT services and assets?
a. Service Level Management
b. Financial Management
c. Demand Management
2.
Which of the following is concerned with fairness and transparency?

a. Capacity Management.
b. IT Governance
c. Service Design
d. Service Level Management.
3.
Which of the following is the MOST accurate definition of Business case?

a. A decision making instrument that plans for the likely consequences of a business
action.
b. A decision making, support and planning instrument that plans for the likely
consequences of a business action.
c. A decision making instrument that helps to file a case in the court of law.
d. All of the above
4.
Which of the following is a MAJOR activity of Demand Management?

a. Increasing customer value
b. Understanding patterns of business activity
c. Increasing the value of IT
d. Aligning the business with IT cost
132
3
MODULE
SERVICE STRATEGY
5.
Which of the following statements is CORRECT about patterns of demand generated by

the customers business?
a. They are driven by patterns of business activity
b. It is impossible to predict how they behave
c. It is impossible to influence demand patterns
d. They are driven by the delivery schedule generated by Capacity Management
6.
Which of the following questions is NOT answered by information in the Service

Portfolio?
a. How should our 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?
7.
Which of the following are the two primary elements that create value for customers?
a. Value on Investment
b. Customer and User satisfaction
c. Understanding Service Requirements and Warranty
d. Utility and Warranty
133
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE DESIGN
134
Co
SERVICE DESIGN
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
Tra
n
siti o
135
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
4
MODULE
SERVICE DESIGN
Learning Objectives
After completion of this module participants will be able to:
Understand and explain the key concepts of Service Design.
Explain how Service Design contributes to the Service Lifecycle.
Understand the key principles and models of Service Design.
Explain the high-level objectives, scope, basic concepts and process activities
of the following processes:

Explain the Objectives, scope and basic concepts of :

Service Catalogue Management
Availability Management
Information Security Management
Supplier Management
Capacity Management
IT Service Continuity Management
136
4
MODULE
SERVICE DESIGN
Service Design Processes

These processes are principally responsible for providing key information
for the design of new or changed service solutions. The processes are:
Design Coordination
Capacity Management
IT Service Continuity Management (ITSCM)
Supplier Management
Service Design Processes

There are no situations within IT service provision with either internal or external service
providers where there are no processes in the service design area. All IT service provider
organizations already have some elements of their approach to the five aspects of service
design in place, no matter how basic. Before starting on the implementation or the
improvement of activities and processes, a review should be conducted of what elements are
in place and working successfully. Many service provider organizations already have mature
processes in place for designing IT services and solutions.
In order to develop effective and efficient service solutions that meet the current and evolving
requirements of the business as well as the needs of IT, it is essential that the inputs and
needs of all other areas and processes are considered and reviewed within each of the service
design activities. This will ensure that all service solutions are consistent and compatible with
existing solutions and will meet the expectations of the customers and users. Critical facets
of the key processes should be consolidated into all of the service design activities, o that all
inputs are automatically referenced every time a new or changed service solution is produced.
137
4
MODULE
SERVICE DESIGN
The Service Design package

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 :
Every New Service
Major Change
IT Service Retirement
This pack is passed from Service Design to Service Transition and details
all aspects of the service and its requirements through all of the
subsequent stages of its lifecycle.
The Service Design package

A Service Design Package or SDP should be produced during the design stage, for each new
service, major change to a service or removal of a service or changes to the Service Design
Package itself. This pack is then passed from Service Design to Service Transition and details
all aspects of the service and its requirements through all of the subsequent stages of its
lifecycle.
138
4
MODULE
SERVICE DESIGN
The Four Ps of Service Design

Service Management implementation is about preparing and planning the
effective and efficient use of the four Ps.
P
People
People Skills
People competencies involved in providing IT services
Processes
Process
Roles
Responsibilities involved in providing IT services
Products
Technology
Tools used in the provision of these services
Partners
Suppliers
Manufacturers
Vendors used to assist in these services
139
4
MODULE
SERVICE DESIGN
Overview of Service Design

The business
Business service A
Business service B
B usiness
Bu sin
essess
Business
Proc
3 3
Proces s1
2 2
process
Business service C
B usiness
Bu sin
ess
Business
Pro
cess 5 6 6
Proce ss4
5
process
SLAs
Service A
Bu sin ess
B usin
ess
Business
Pro
cess 8 9 9
Pro cess7
8
process
IT service provider
Service
strategy
Service management
process
Service management
process
Service
operaon
Connual
service
improvement
Support teams
Design of management
informaon systems and tools
Service design
Design of processes
Service
transion
Service management
process
Service management
process
Service management
process
Service knowledge
management system
Design of service soluons

Design of technology
architectures and
management architectures
Service
porolio
Service
catalogue
Design of measurement
methods and metrics
Suppliers
Overview of Service Design

All designs and design activities need to be driven principally by the business needs and
requirements of the organization. Within this context they must also reflect the needs of the
strategies, plans and policies produced by Service Strategy processes.
The key output of the Service Design stage is the design of service solutions to meet the
changing requirements of the business. However, when designing these solutions, input
from many different areas needs to be considered within the various activities involved in
designing the service solution, from identifying and analysing requirements, through to
building a solution and SDP to hand over to Service Transition.
140
4
MODULE
SERVICE DESIGN
In order to develop effective and efficient service solutions that meet and continue to meet
the requirements of the business and the needs of IT, it is essential that all the inputs and
needs of all other areas and processes are reconsidered within each of the Service Design
activities, as illustrated in Figure. This will ensure that all service solutions are consistent and
compatible with existing solutions and will meet the expectations of the customers and users.
This will most effectively be achieved by consolidating these facets of the key processes into
all of these Service Design activities, so that all inputs are automatically referenced every
time a new or changed service solution is produced.
141
4
MODULE
SERVICE DESIGN
Five Aspects of Service Design

There are five
individuals aspects
of service design
and the aspects are
the design of:
Service solutions for new or changed services.
Management information system and tools.
Technology architectures and management architectures.
The process required.
Measurement methods and metrics.
It is important that holistic, results driven approach to all aspects of design is adopted,
and that when changing or amending any of the individual elements of design are
considered.
Five Aspects of Service Design

Holistic service design: There are five individuals aspects of service design and the aspects
are the design of:
Service solutions for new or changed services:There are many activities that have to be
completed within the Service Design stage for a new or changed service. A formal and
structured approach is required to produce the new service at the right cost, functionality,
quality and within the right time frame.
The areas that need to be considered within the design of the service solution should include:
Analyse the agreed business requirements
Review the existing IT services and infrastructure and produce alternative service solutions,
with a view to re-using or exploiting existing components and services wherever possible
142
4
MODULE
SERVICE DESIGN
Design the service solutions to the new requirements, including their constituent
components, in terms of the following, and document this design:
The facilities and functionality required, and information required for the monitoring
of the performance of the service or process.
The business processes supported, dependencies, priorities, criticality and impact of
the service, together with the business benefits that will be delivered by the service.
Business cycles and seasonal variations, and the related business transaction levels,
service transaction levels, the numbers and types of users and anticipated future
growth, and the business continuity requirements.
Service Level Requirements and service level targets and the necessary service
measuring, reporting and reviewing activities.
The timescales involved and the planned outcomes from the new service and the
impact on any existing services.
The requirements for testing, including any User Acceptance Testing (UAT) and
responsibilities for managing the test results.
Ensure that the contents of the Service Acceptance Criteria (SAC) are incorporated and
the required achievements planned into the initial design.
Evaluate and cost alternative designs, highlighting advantages as well as disadvantages
of the alternatives.
Agree the expenditure and budgets.
Re-evaluate and confirm the business benefits, including the Return on Investment
(RoI) from the service, including identification and quantification of all service costs and
all business benefits and increased revenues. The costs should cover the Total Cost of
Ownership (TCO) of the service and include start-up costs such as design costs, transition
costs, project budget, and all ongoing operational costs including management, support
and maintenance.
Agree the preferred solution and its planned outcomes and targets (Service Level
Requirement (SLR)).
143
4
MODULE
SERVICE DESIGN
Management information system and tools: The most effective way of managing all aspects
of services through their lifecycle is by using appropriate management systems and tools
to support and automate efficient processes. The Service Portfolio is the most critical
management system used to support all processes and describes a providers services in
terms of business value. It articulates business needs and the providers response to those
needs. By definition, business value terms correspond to market terms, providing a means
for comparing service competitiveness across alternative providers.
The Design of Technology and Management architectures and tools required to provide
services: The architectural design activities within an IT organization are concerned with
providing the overall strategic blueprints for the development and deployment of an IT
infrastructure a set of applications and data that satisfy the current and future needs of
the business. Although these aspects underpin the delivery of quality IT services, they alone
cannot deliver quality IT services, and it is essential that the people, process and partner/
supplier aspects surrounding these technological components (products) are also considered.
In essence, architectural design can be defined as:
The development and maintenance of IT policies, strategies, architectures, designs,
documents, plans and processes for the deployment and subsequent operation and
improvement of appropriate IT services and solutions throughout an organization.
The design of the process needed to design, transition, operate and improve services:
A process is 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. A process may also define or revise policies, standards, guidelines, activities,
processes, procedures and work instructions if they are needed. 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.
The design of Measurement systems, methods and metrics for services, the architectures
and constituent components: In order to manage and control the design processes, they
144
4
MODULE
SERVICE DESIGN
have to be monitored and measured. This is true for all aspects of the design processes.
Measurements and metrics are covered in detail in the Continual Service Improvement
publication. This section covers those aspects that are particularly relevant and appropriate
to measuring the quality of the design processes and their deliverables.
The process measurements selected need to be appropriate for the capability and maturity
of the processes being measured. Immature processes are not capable of supporting
sophisticated measurements, metrics and measurement methods. There are four types of
metrics that can be used to measure the capability and performance of processes:
Progress: milestones and deliverables in the capability of the process.
Compliance: compliance of the process to governance requirements, regulatory requirements
and compliance of people to the use of the process.
Effectiveness: the accuracy and correctness of the process and its ability to deliver the right
result.
Efficiency: the productivity of the process, its speed, throughput and resource utilization.
145
4
MODULE
SERVICE DESIGN
Design Coordination Process

Purpose
The purpose of the design coordination process is to ensure the goals
and objectives of the service design stage are met by providing and
maintaining a single point of coordination and control for all activities
and processes within this stage of the service lifecycle.
Objectives
Coordinate all design activities across projects, changes, suppliers and support
teams, and manage schedules, resources and conflicts where required.
Plan and coordinate the resources and capabilities required to design new or
changed services.
Produce service design packages (SDPs) based on service charters and change
requests.
Ensure that appropriate service designs and/or SDPs are produced and that
they are handed over to service transition as agreed.

Purpose and objectives: The purpose of the design coordination process is to ensure the
goals and objectives of the service design stage are met by providing and maintaining a single
point of coordination and control for all activities and processes within this stage of the
service lifecycle.
The objectives of the design coordination process are to:
Ensure the consistent design of appropriate services, service management information
systems, architectures, technology, processes, information and metrics to meet current
and evolving business outcomes and requirements.
146
4
MODULE
SERVICE DESIGN
Coordinate all design activities across projects, changes, suppliers and support teams,
and manage schedules, resources and conflicts where required.
Plan and coordinate the resources and capabilities required to design new or changed
services.
Produce service design packages (SDPs) based on service charters and change requests.
Ensure that appropriate service designs and/or SDPs are produced and that they are
handed over to service transition as agreed.
Manage the quality criteria, requirements and handover points between the service
design stage and service strategy and service transition.
Ensure that all service models and service solution designs conform to strategic,
architectural, governance and other corporate requirements.
Improve the effectiveness and efficiency of service design activities and processes.
Ensure that all parties adopt a common framework of standard, reusable design practices
in the form of activities, processes and supporting systems, whenever appropriate.
Monitor and improve the performance of the service design lifecycle stage.
147
4
MODULE
SERVICE DESIGN

Scope
The scope of the design coordination process includes all design
activity, particularly all new or changed service solutions that are
being designed for transition into (or out of, in the case of a service
retirement) the live environment.
The Design coordination process includes:
Assisting and supporting each project or other change through all the service
design activities and processes
Maintaining policies, guidelines, standards, budgets, models, resources and
capabilities for service design activities and processes.
Coordinating, prioritizing and scheduling of all service design resources to
satisfy conflicting demands from all projects and changes.

Scope: The scope of the design coordination process includes all design activity, particularly
all new or changed service solutions that are being designed for transition into (or out of,
in the case of a service retirement) the live environment. Some design efforts will be part
of a project, whereas others will be managed through the change process alone without
a formally defined project. Some design efforts will be extensive and complex while others
will be simple and swift. Not every design activity requires the same level of rigor to ensure
success, so a significant number of design efforts will require little or no individual attention
from the design coordination process.
Most design coordination process activity focuses around those design efforts that are part
of a project, as well as those that are associated with changes of defined types. Typically, the
changes that require the most attention from design coordination are major changes, but any
change that an organization believes could benefit from design coordination may be included.
148
4
MODULE
SERVICE DESIGN
Each organization should define the criteria that will be used to determine the level of rigour
or attention to be applied in design coordination for each design. Some organizations take
the perspective that all changes, regardless of how small in scope, have a design stage, as
it is important that all changes have clear and correct plans for how to implement them. In
this perspective, the lifecycle stage of service design still occurs, even if the designs for simple
standard changes are usually pre-built and are reused frequently and quickly. Sometimes the
stage is quite complex and long and sometimes it is simply a rapid check that the right design
(procedure) is being used. Other organizations take the perspective that only changes that
fit certain criteria, such as those associated with a project or major change, have a formal
service design stage. In this perspective, changes that fail to meet the agreed criteria may be
considered out of the scope of this process.
Whichever perspective is adopted by an organization, the end result should be more
successful changes that deliver the required business outcomes with minimal disruption
or other negative impacts on business operations. If an organizations approach produces
that result, then the organization is performing design coordination correctly. The design
coordination process includes:
Assisting and supporting each project or other change through all the service design
activities and processes.
Maintaining policies, guidelines, standards, budgets, models, resources and capabilities
for service design activities and processes.
Coordinating, prioritizing and scheduling of all service design resources to satisfy
conflicting demands from all projects and changes.
Planning and forecasting the resources needed for the future demand for service design
activities.
Reviewing, measuring and improving the performance of all service design activities and
processes.
Ensuring that all requirements are appropriately addressed in service designs, particularly
utility and warranty requirements.
Ensuring the production of service designs and/ or SDPs and their handover to service
transition.
149
4
MODULE
SERVICE DESIGN
The design coordination process does not include:
Responsibility for any activities or processes outside of the design stage of the service
lifecycle.
Responsibility for designing the detailed service solutions themselves or the production
of the individual parts of the SDPs. These are the responsibility of the individual projects
or service management processes.
150
4
MODULE
SERVICE DESIGN

Purpose
The Purpose: To provide and maintain a single source of consistent
information on all operational services and those being prepared to
be run operationally.
Objectives
Manage the information contained within the service catalogue.
Ensure that the service catalogue is accurate and reflects the current details,
status, interfaces and dependencies of all services that are being run, or being
prepared to run, in the live environment, according to the defined policies.
Ensure that the service catalogue is made available to those approved to
access it in a manner that supports their effective and efficient use of service
catalogue information.

The purpose of the service catalogue management process is to provide and maintain a
single source of consistent information on all operational services and those being prepared
to be run operationally, and to ensure that it is widely available to those who are authorized
to access it.
The objectives of the service catalogue management process are to:
Manage the information contained within the service catalogue.
Ensure that the service catalogue is accurate and reflects the current details, status,
interfaces and dependencies of all services that are being run, or being prepared to run,
in the live environment, according to the defined policies.
151
4
MODULE
SERVICE DESIGN
Ensure that the service catalogue is made available to those approved to access it in a
manner that supports their effective and efficient use of service catalogue information.
Ensure that the service catalogue supports the evolving needs of all other service
management processes for service catalogue information, including all interface and
dependency information.
152
4
MODULE
SERVICE DESIGN

Scope
The scope of the service catalogue management process is to provide
and maintain accurate information on all services that are being
transitioned or have been transitioned to the live environment.
The service catalogue management process covers:
Contribution to the definition of services and service packages.
Development and maintenance of service and service package descriptions
appropriate for the service catalogue.
Production and maintenance of an accurate service catalogue.

Scope: The scope of the service catalogue management process is to provide and maintain
accurate information on all services that are being transitioned or have been transitioned
to the live environment. The services presented in the service catalogue may be listed
individually or, more typically, some or all of the services may be presented in the form of
service packages.
The service catalogue management process covers:
Contribution to the definition of services and service packages.
Development and maintenance of service and service package descriptions appropriate
for the service catalogue.
Production and maintenance of an accurate service catalogue.
153
4
MODULE
SERVICE DESIGN
Interfaces, dependencies and consistency between the service catalogue and the overall
service portfolio.
Interfaces and dependencies between all services and supporting services within the
service catalogue and the CMS.
Interfaces and dependencies between all services, and supporting components and
configuration items (CIs) within the service catalogue and the CMS.
The service catalogue management process does not include:
Detailed attention to the capturing, maintenance and use of service asset and configuration
data as performed through the service asset and configuration management process.
Detailed attention to the capturing, maintenance and fulfilment of service requests as
performed through request fulfilment.
154
4
MODULE
SERVICE DESIGN
Service Catalogue - Two View Structure

The service catalogue
Business
process 2
Business
process 1
Service A
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. Service
. . . . . . . . . 1. . . .
. . . .. .. .. .. .. .. .. .. .. .. .. .. ..
Service C
Service B
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. Service
. . . . . . . . .2. . . .
. . . .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. Service
. . . . . . . . . 3. . . .
. . . .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. ..Service
. . . . . . . . 4. . . .
. . . . .. .. .. .. .. .. .. .. .. .. .. ..
Business
process 3
Business/customer
service catalogue view
Service D
Service E
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. Service
. . . . . . . . . 5. . . .
. . . .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. Service
. . . . . . . . . 6. . . .
. . . .. .. .. .. .. .. .. .. .. .. .. .. ..
Technical/supporng service catalogue view

Links to related
informaon
Service assets/configuraon records
Key
= Customer
.....
facing services ... ... ... ... ... = Supporng services
Service Catalogue - Two View Structure

The structure and presentation of the service catalogue should support the uses to which it
will be put, taking into consideration the different, sometimes conflicting needs of different
audiences. Not every service is of interest to every person or group. Not every piece of
information about a service is of interest to every person or group. When service providers
have many customers or serve many businesses, there may be multiple service catalogue
views projected from the service portfolio. When initially completed, the Service Catalogue
may consist of a matrix, table or spreadsheet.
155
4
MODULE
SERVICE DESIGN
Many organizations integrate and maintain their Service Portfolio and Service Catalogue as
part of their CMS. By defining each service as a Configuration Item (CI) and, where appropriate,
relating these to form a service hierarchy, the organization is able to relate events such as
incidents and RFCs to the services affected, thus providing the basis for service monitoring
and reporting using an integrated tool (e.g. list or give the number of incidents affecting
this particular service). It is therefore essential that changes within the Service Portfolio and
Service Catalogue are subject to the Change Management process. The Service Catalogue
can also be used for other Service Management purposes (e.g. for performing a Business
Impact Analysis (BIA) as part of IT Service Continuity Planning, or as a starting place for redistributing workloads, as part of Capacity Management). The cost and effort of producing
and maintaining the catalogue, with its relationships to the underpinning technology
components, is therefore easily justifiable. If done in conjunction with prioritization of the
BIA, then it is possible to ensure that the most important services are covered first.
Some organizations maintain a service catalogue that includes only the customer-facing
services, while others maintain information only on the supporting services. The preferred
situation adopted by the more mature organizations maintains both types of service within a
single service catalogue, which is in turn part of a totally integrated service portfolio. (More
information on the design and contents of a service catalogue is contained in Appendix G.)
Some organizations project more than two views. There is no correct or suggested number of
views an organization should project. The number of views projected will depend upon the
audiences to be addressed and the uses to which the catalogue will be put.
156
4
MODULE
SERVICE DESIGN
Service Catalogue - Three View Structure

The service catalogue
Wholesale service catalogue view

Wholesale
customer 1
Service A
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. Service
.. .. .. .. .. .. .. .. 1.. .. .. ..
................
Retail service catalogue view
Wholesale
customer 2
Service D
Service C
Service B
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. ..Service
.. .. .. .. .. .. .. .. 2.. .. .. ..
................
Retail
customer 2
Retail
customer 1
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. ..Service
.. .. .. .. .. .. .. .. 3.. .. .. ..
................
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. Service
.. .. .. .. .. .. .. .. 4.. .. .. ..
................
Service E
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. ..Service
.. .. .. .. .. .. .. ..5.. .. .. ..
................
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. ..Service
.. .. .. .. .. .. .. ..6.. .. .. ..
................
Links to related
informaon
Service assets/configuraon records
Key
= Customer
facing services
... ... ... ... ... = Supporng services

.....
Service Catalogue - Three View Structure

Wholesale customer view This contains details of all the IT services delivered to wholesale
customers (customer-facing services), together with relationships to the customers they
support.
Retail customer view This contains details of all the IT services delivered to retail customers
(customer-facing services), together with relationships to the customers they support.
Supporting services view This contains details of all the supporting IT services, together with
relationships to the customer-facing services they underpin and the components, CIs and other
supporting services necessary to support the provision of the service to the customers.
157
4
MODULE
SERVICE DESIGN
The preferred situation adopted by the more mature organizations maintains both aspects
within a single Service Catalogue, which is part of a totally integrated Service Management
activity and Service Portfolio. The Business Service Catalogue facilitates the development of
a much more proactive or even pre-emptive SLM process, allowing it to develop more into
the field of Business Service Management. The Technical Service Catalogue is extremely
beneficial when constructing the relationship between services, SLAs, OLAs and other
underpinning agreements and components, as it will identify the technology required to
support a service and the support group(s) that support the components. The combination
of a Business Service Catalogue and a Technical Service Catalogue is invaluable for quickly
assessing the impact of incidents and changes on the business.
Note in this example how customer-facing service C appears in both the wholesale view
and the retail view. It is also possible that the different views might reflect hierarchical
relationships beyond one level of customer and one level of supporting service. Services are
also likely to be packaged and then service packages will be shown in the appropriate service
catalogue view(s).
The customer-facing service catalogue view facilitates the development of a much more
proactive or even pre-emptive service level management (SLM) process and supports
close business alignment with clearly defined relationships between services and SLAs. The
supporting service catalogue view is extremely beneficial when constructing the relationship
between services, SLAs, operational level agreements (OLAs) and other underpinning
agreements and components, as it will identify the technology required to support a service
and the support group(s) that support the components. The combination of all views is
invaluable for quickly assessing the impact of incidents and changes on the business.
There is no single correct way to structure and deploy a service catalogue. Each service
provider organization will consider its goals, objectives and uses for the service catalogue
and create a structure that will meet its current and evolving needs appropriately.
158
4
MODULE
SERVICE DESIGN
Service Catalogue Management - Roles

Service Catalogue Management Process Manager:
The service catalogue management process managers responsibilities
typically include:
Carrying out the generic process manager role for the service catalogue
management process.
Coordinating interfaces between service catalogue management and other
processes, especially service asset and configuration management, and release
and deployment management.
Ensuring that all operational services and all services being prepared for
operational running are recorded within the service catalogue.
Ensuring that all the information within the service catalogue is accurate and
up to date.
Service Catalogue Management - Roles

Service Catalogue Management Roles: This describes a number of roles that need to be
performed in support of the service catalogue management process. These roles are not job
titles, and each organization will have to define appropriate job titles and job descriptions
depending on its needs.
Service Catalogue Management Process Owner: The service catalogue management process
owners responsibilities typically include:
Carrying out the generic process owner role for the service catalogue management
process.
Working with other process owners to ensure there is an integrated approach to the design
and implementation of service catalogue management, service portfolio management,
service level management and business relationship management.
159
4
MODULE
SERVICE DESIGN
Service Catalogue Management Process Manager: The service catalogue

management process managers responsibilities typically include:
Carrying out the generic process manager role for the service catalogue management
process.
Coordinating interfaces between service catalogue management and other processes,
especially service asset and configuration management, and release and deployment
management.
Ensuring that all operational services and all services being prepared for operational
running are recorded within the service catalogue.
Ensuring that all the information within the service catalogue is accurate and up to date.
Ensuring that appropriate views of the service catalogue are maintained and made
available to those for whom they are targeted.
Ensuring that all the information within the service catalogue is consistent with the
information within the service portfolio.
Ensuring that the information within the service catalogue is adequately protected and
backed up.
160
4
MODULE
SERVICE DESIGN

Purpose
The purpose of the SLM process is to ensure that all current and planned
IT services are delivered to agreed achievable targets. This is accomplished
through a constant cycle of negotiating, agreeing, monitoring, reporting on
and reviewing IT service targets and achievements, and through instigation
of actions to correct or improve the level of service delivered.
Objectives
Define, document, agree, monitor, measure, report and review the level of IT
services provided and instigate corrective measures whenever appropriate.
Provide and improve the relationship and communication with the business
and customers in conjunction with business relationship management.
Ensure that specific and measurable targets are developed for all IT services.
Monitor and improve customer satisfaction with the quality of service
delivered.

Purpose and objectives: The purpose of the SLM process is to ensure that all current and
planned IT services are delivered to agreed achievable targets. This is accomplished through
a constant cycle of negotiating, agreeing, monitoring, reporting on and reviewing IT service
targets and achievements, and through instigation of actions to correct or improve the level
of service delivered.
The objectives of SLM are to:
Define, document, agree, monitor, measure, report and review the level of IT services
provided and instigate corrective measures whenever appropriate.
161
4
MODULE
SERVICE DESIGN
Provide and improve the relationship and communication with the business and
customers in conjunction with business relationship management.
Ensure that specific and measurable targets are developed for all IT services.
Monitor and improve customer satisfaction with the quality of service delivered.
Ensure that IT and the customers have a clear and unambiguous expectation of the level
of service to be delivered.
Ensure that even when all agreed targets are met, the levels of service delivered are
subject to proactive, cost-effective continual improvement.
162
4
MODULE
SERVICE DESIGN

Scope
SLM should provide a point of regular contact and communication to the
customers and business managers of an organization in relation to service
levels.
SLM needs to manage the expectation and perception of the business,
customers and users and ensure that the quality (warranty) of service
delivered by the service provider is matched to those expectations and needs.
SLM should also produce and agree SLRs for all planned new or changed
services that document warranty requirements.
This will enable SLM to ensure that all the services and components are
designed and delivered to meet their targets in terms of business needs. The
SLM process should include:

Scope: SLM should provide a point of regular contact and communication to the customers
and business managers of an organization in relation to service levels. In this context, it
should represent the IT service provider to the business, and the business to the IT service
provider. This activity should encompass both the use of existing services and the potential
future requirements for new or changed services. SLM needs to manage the expectation and
perception of the business, customers and users and ensure that the quality (warranty) of
service delivered by the service provider is matched to those expectations and needs. In order
to do this effectively, SLM should establish and maintain SLAs of service provided to meet the
targets and quality measurements contained within the SLAs. SLM should also produce and
agree SLRs for all planned new or changed services that document warranty requirements.
163
4
MODULE
SERVICE DESIGN
This will enable SLM to ensure that all the services and components are designed and
delivered to meet their targets in terms of business needs. The SLM process should include:
Cooperation with the business relationship management process: this includes
development of relationships with the business as needed to achieve the SLM process
objectives.
Negotiation and agreement of future service level requirements and targets, and the
documentation and management of SLRs for all proposed new or changed services.
Negotiation and agreement of current service level requirements and targets, and the
documentation and management of SLAs for all operational services.
Development and management of appropriate OLAs to ensure that targets are aligned
with SLA targets.
Review of all supplier agreements and underpinning contracts with supplier management
to ensure that targets are aligned with SLA targets.
Proactive prevention of service failures, reduction of service risks and improvement in
the quality of service, in conjunction with all other processes.
Reporting and management of all service level achievements and review of all SLA
breaches.
Periodic review, renewal and/or revision of SLAs, service scope and OLAs as appropriate.
Identifying improvement opportunities for inclusion in the CSI register.
Reviewing and prioritizing improvements in the CSI register.
Instigating and coordinating SIPs for the management, planning and implementation of
service and process improvements.
164
4
MODULE
SERVICE DESIGN
The SLM process does not include:

Negotiation and agreement of requirements for service functionality (utility), except to
the degree functionality influences a service level requirement or target. SLAs typically
describe key elements of the services utility as part of the service description, but SLM
activity does not include agreeing what the utility will be.
Detailed attention to the activities necessary to deliver service levels that are accounted
for in other processes such as availability management and capacity management.
Negotiation of underpinning supplier contracts and agreements. This is part of the
supplier management process to which SLM provides critical input and consultation.
165
4
MODULE
SERVICE DESIGN
Service Level Management - Agreements
SLA
A formal signed agreement between a Customer and a service Provider in

which service provision (responsibilities) is described and achievable targets
are stipulated and bounded.
OLA
An Operating Level Agreement (OLA) is also an SLA but is an agreement

between an IT Service Provider and another part of the same organization
that assists with the provision of services for instance a facilities department
that maintains the air conditioning or network support team that supports
the network service.
UC
Underpinning Contract is a contract with a third party in support of the

delivery of an agreed IT service to a customer. The UC defines targets and
responsibilities that are required to meet agreed service level targets in an
SLA/OLA.
Service Level Management - Agreements

An SLA is a written agreement between an IT service provider and the IT customer(s),
defining the key service targets and responsibilities of both parties. The emphasis must be on
agreement, and 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 could quickly fall into
disrepute and a blame culture could develop that would prevent any true service quality
improvements from taking place.
An OLA is an agreement between an IT service provider and another part of the same
organization that assists with the provision of services for instance, a facilities department
that maintains the air conditioning, or 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.
166
4
MODULE
SERVICE DESIGN
The terminology used in the ITIL book is expressed from the point of view of the IT service
provider , particularly as it relates to underpinning contracts and agreements. When an IT
service provider engages a third party supplier to provide goods or services that are needed
for the provision of service to customers, it is important that both parties have clear and
unambigous expectation of how the supplier will meet the IT service provide requirements.
This is accompanied by documenting the terms of engagement in an agreement of some
sort and this agreement supports or underpins the service level targets in the SLA with
customer. If the agreement is legally binding it is referred to as contract or more precisely an
underpinning contract.
167
4
MODULE
SERVICE DESIGN
SLA Frameworks Three Types

Service-based SLA
This is where an SLA covers one service, for all the customers of that service for
example, an SLA may be established for an organizations email service, covering 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 SLAs
Some organizations have chosen to adopt a multilevel SLA structure. For example, a
three-layer structure might look as follows:
Corporate level: This will cover all the generic SLM issues appropriate to every customer
throughout the organization. These issues are likely to be less volatile, so updates are
less frequently required.
Customer level: This will cover all SLM issues relevant to the particular customer group
or business unit, regardless of the service being used.
Service level: This will cover all SLM issues relevant to the specific service, in relation to
a specific customer group (one for each service covered by the SLA).
SLA Frameworks Three Types

SLA frameworks: Using the service catalogue as an aid, SLM must design the most appropriate
SLA structure to ensure that all services and all customers are covered in a manner best suited
to the organizations needs. There are a number of potential options, including the following.
Service-based SLA: This is where an SLA covers one service, for all the customers of that
service for example, an SLA may be established for an organizations email service, covering
all the customers of that service. This may appear fairly straightforward. However, difficulties
may arise if the specific requirements of different customers vary for the same service,
or if characteristics of the infrastructure mean that different service levels are inevitable
168
4
MODULE
SERVICE DESIGN
(e.g. head office staff may be connected via a high speed LAN, while local offices may have
to use a lower-speed WAN line). In such cases, separate targets may be needed within the
one agreement.
Difficulties may also arise in determining who should be the signatories to such an agreement.
However, where common levels of service are provided across all areas of the business (for
example, email or telephony), the service-based SLA can be an efficient approach to use.
Multiple classes of service (for example, gold, silver and bronze) can also be used to increase
the effectiveness of service-based SLAs.
Customer-based SLA: This is an agreement with an individual customer group, covering
all the services they use. For example, agreements may be reached with an organizations
finance department covering, say, the finance system, the accounting system, the payroll
system, the billing system, the procurement system, and any other IT systems that they use.
Customers often prefer such an agreement, as all of their requirements are covered in a
single document. Only one signatory is normally required, which simplifies this issue.
Hints and tips: A combination of either customer- or service based SLA structures might be
appropriate, providing all services and customers are covered, with no overlap or duplication.
Multi-level SLAs: Some organizations have chosen to adopt a multilevel SLA structure. For
example, a three-layer structure might look as follows:
Corporate level: This will cover all the generic SLM issues appropriate to every customer
throughout the organization. These issues are likely to be less volatile, so updates are less
frequently required.
169
4
MODULE
SERVICE DESIGN
Service Level Management Process - Actitvities

Business unit A
Business
process
SLA(s)
Business
process
Service A
SLR(s)
SLM
Service
catalogue
Determine, document
and agree requirements
for new services SLRs
and make SLAs
Monitor service
performance against
SLA and produce
service reports
Develop contacts and

relaonships, record
and manage complaints
and compliments
Conduct service
reviews and insgate
improvements within
overall SIP
Collate, measure and

improve customer
sasfacon
Service
reports
Review and revise SLAs,

service scope and
underpinning
agreements
OLAs
Business
relaonship
management
The business
Business unit B
Assist with the

service catalogue and
maintain document
templates
Design SLA
frameworks and
document procedures
and standards
Provide
management
informaon
Underpinning
contracts
Suppliers
Teams
(ii)
Support team
(I)
(ii)
Supplier management
Supplier
(I)
Service Level Management - Activities

Determine, negotiate, document and agree requirements for new or changed services in SLRs,
and manage and review them through 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.
170
4
MODULE
SERVICE DESIGN
Conduct service review, identifying improvement opportunities for inclusion in the CSI register
and managing appropriate SIPs.
Review and revise SLAs, service scope and OLAs.
Develop and document contacts and relationships with the business, customers and
stakeholders.
Develop, maintain and operate procedures for logging, actioning and resolving all complaints,
and for logging and distributing compliments.
Logging and managing all complaints and compliments.
Provide the appropriate management information to aid performance management and
demonstrate service achievement.
Assisting supplier management to review and revise underpinning contracts and agreements.
171
4
MODULE
SERVICE DESIGN
Service Level Management - Roles

Service Level Management Process Manager
Carrying out the generic process manager role for the service level
management process.
Coordinating interfaces between service level management and other
processes, especially service catalogue management, service portfolio
management, business relationship management and supplier management.
Ensuring that the current and future service level requirements (service
warranty) of customers are identified, understood and documented in SLA
and service level requirements (SLR) documents.
Negotiating and agreeing levels of service to be delivered with the customer
(either internal or external); formally documenting these levels of service
in SLAs.
Service Level Management - Roles

Service Level Management Roles: This describes a number of roles that need to be performed
in support of the service level management process. These roles are not job titles, and each
organization will have to define appropriate job titles and job descriptions depending on its
needs.
Service Level Management Process Owner: The service level management process owners
responsibilities typically include:
Carrying out the generic process owner role for the service level management process.
Liaising with the business relationship management process owner to ensure proper
coordination and communication between the two processes.
172
4
MODULE
SERVICE DESIGN
and implementation of service catalogue management, service portfolio management,
service level management and business relationship management.
Service Level Management Process Manager: The service level management process
managers responsibilities typically include:
Carrying out the generic process manager role for the service level management process.
Coordinating interfaces between service level management and other processes,
especially service catalogue management, service portfolio management, business
relationship management and supplier management.
Keeping aware of changing business needs.
Ensuring that the current and future service level requirements (service warranty)
of customers are identified, understood and documented in SLA and service level
requirements (SLR) documents.
Negotiating and agreeing levels of service to be delivered with the customer (either
internal or external); formally documenting these levels of service in SLAs.
Negotiating and agreeing OLAs and, in some cases, other SLAs and agreements that
underpin the SLAs with the customers of the service.
Assisting with the production and maintenance of an accurate service portfolio, service
catalogue, application portfolio and the corresponding maintenance procedures.
Ensuring that targets agreed within underpinning contracts are aligned with SLA and SLR
targets.
Ensuring that service reports are produced for ach customer service and that breaches of
SLA targets are highlighted, investigated and actions taken to prevent their recurrence.
Ensuring that service performance reviews are scheduled, carried out with customers
regularly and documented, with agreed actions progressed.
Ensuring that improvement initiatives identified in service reviews are acted on and
progress reports are provided to customers.
173
4
MODULE
SERVICE DESIGN
Reviewing service scope, SLAs, OLAs and other agreements on a regular basis, ideally at
least annually.
Ensuring that all changes are assessed for their impact on service levels, including SLAs,
OLAs and underpinning contracts, including attendance at change advisory board (CAB)
meetings if appropriate.
Identifying all customers and other key stakeholders to involve in SLR, SLA and OLA
negotiations.
Developing relationships and communication with customers, key users and other
stakeholders.
Defining and agreeing complaints and their recording, management, escalation (where
necessary) and resolution.
Definition recording and communication of all complaints.
Measuring, recording, analysing and improving customer satisfaction.
174
4
MODULE
SERVICE DESIGN
Purpose
The purpose of the availability management process is to ensure that the level
of availability delivered in all IT services meets the agreed availability needs
and/or service level targets in a cost-effective and timely manner.
Objectives
Produce and maintain an appropriate and up-to-date availability plan
that 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 achievements meet all their agreed targets
by managing services and resources-related availability performance.
Purpose and objectives: The purpose of the availability management process is to ensure
that the level of availability delivered in all IT services meets the agreed availability needs
and/or service level targets in a cost-effective and timely manner. Availability management is
concerned with meeting both the current and future availability needs of the business.
Availability management defines, analyses, plans, measures and improves all aspects of
the availability of IT services, ensuring that all IT infrastructure, processes, tools, roles etc.
are appropriate for the agreed availability service level targets. It provides a point of focus
and management for all availability- related issues, relating to both services and resources,
ensuring that availability targets in all areas are measured and achieved.
175
4
MODULE
SERVICE DESIGN
The objectives of availability management are to:

Produce and maintain an appropriate and up-to-date availability plan that reflects the
current and future needs of the business.
Provide advice and guidance to all other areas of the business and IT on all availabilityrelated issues.
Ensure that service availability achievements meet all their agreed targets by managing
services and resources-related availability performance.
Assist with the diagnosis and resolution of availability-related incidents and problems.
Assess the impact of all changes on the availability plan and the availability of all services
and resources.
Ensure that proactive measures to improve the availability of services are implemented
wherever it is cost-justifiable to do so.
Availability management should ensure the agreed level of availability is provided. The
measurement and monitoring of IT availability is a key activity to ensure availability levels are
being met consistently.
Availability management should look to continually optimize and proactively improve the
availability of the IT infrastructure, the services and the supporting organization, in order
to provide cost-effective availability improvements that can deliver business and customer
benefits.
176
4
MODULE
SERVICE DESIGN
Availability Management Process

Scope
The scope of the availability management process covers the design,
implementation, measurement, management and improvement of IT service
and component availability.
Reactive activities
Proactive activities
These involve the monitoring,

measuring, analysis and management
of all events, incidents and problems
involving unavailability. These activities
are principally performed as part of the
operational roles.
These involve the proactive

planning, design and improvement
of availability. These activities are
principally performed as part of the
design and planning roles.
Availability management to ensure that all the services and components are designed
and delivered to meet their targets in terms of agreed business needs.
Availability Management Process

Scope: The scope of the availability management process covers the design, implementation,
measurement, management and improvement of IT service and component availability.
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 availability management process includes two key
elements:
Reactive activities: These involve the monitoring, measuring, analysis and management of
all events, incidents and problems involving unavailability. These activities are principally
performed as part of the operational roles.
Proactive activities: These involve the proactive planning, design and improvement of
availability. These activities are principally performed as part of the design and planning roles.
177
4
MODULE
SERVICE DESIGN
Availability management needs to understand the service and component availability

requirements from the business perspective in terms of the:
Current business processes, their operation and requirements.
Future business plans and requirements.
Service targets and the current IT service operation and delivery.
IT infrastructure, data, applications and environment and their performance.
Business impacts and priorities in relation to the services and their usage.
Understanding all of this will enable availability management to ensure that all the services
and components are designed and delivered to meet their targets in terms of agreed business
needs. The availability management process:
Should be applied to all operational services and technology, particularly those covered
by SLAs. It can also be applied to those IT services deemed to be business-critical,
regardless of whether formal SLAs exist.
Should be applied to all new IT services and for existing services where SLRs or SLAs have
been established.
Should be applied to all supporting services and the partners and suppliers (both internal
and external) that form the IT support organization as a precursor to the creation of
formal agreements.
Should consider all aspects of the IT services and components and supporting
organizations that may impact availability, including training, skills, process effectiveness,
procedures and tools.
178
4
MODULE
SERVICE DESIGN
Aspects of Availability - Availability & Reliability

Availability: The ability of a service, component or CI to perform its agreed function
when required. It is often measured and reported as a percentage.

Note that downtime should only be included in the following calculation when
it occurs within the agreed service time (AST). However, total down time should also
be recorded and reported.
Availability(%) = Agreed Service time (AST) - Downtime

AST
*100
Reliability: Reliability is a measure of how long a service, component or CI can perform

its agreed function without interruption. The reliability of the service can be improved
by increasing the reliability of individual components or by increasing the resilience of
the service to individual component failure (i.e. increasing the component redundancy,
for example by using load-balancing techniques).
Reliability (MTBSI in hours) = Agreed time hours (AST) / Number of breaks

Reliability (MTBF in hours) = Available time in Hours Total Downtime in Hours
Number of Breaks
Aspects of Availability - Availability & Reliability

Availability: Availability is the ability of a service, component or CI to perform its agreed
function when required. It is often measured and reported as a percentage. Note that
downtime should only be included in the following calculation when it occurs within the
agreed service time (AST). However, total down time should also be recorded and reported.
Reliability: Reliability is a measure of how long a service, component or CI can perform
its agreed function without interruption. The reliability of the service can be improved by
increasing the reliability of individual components or by increasing the resilience of the service
179
4
MODULE
SERVICE DESIGN
to individual component failure (i.e. increasing the component redundancy, for example
by using load-balancing techniques). It is often measured and reported as the mean time
between service incidents (MTBSI) or mean time between failures (MTBF):
Reliability (MTBSI in hours) = Agreed time hours (AST) / Number of breaks
Reliability (MTBF in hours) = Available time in Hours Total Downtime in Hours / Number
of breaks
180
4
MODULE
SERVICE DESIGN
Aspects of Availability - Maintainability & Serviceability

Maintainability: Maintainability is a measure of how quickly and effectively
a service, component or CI can be restored to normal working after a
failure. It is measured and reported as the mean time to restore service
(MTRS) and should be calculated using the following formula:

Maintainability (MTRS in hours) = Total downtime in hours / Number
of service breaks
The downtime in MTRS covers all the contributory factors that make the
service, component or CI unavailable.
Serviceability: Serviceability is the ability of a third-party supplier to
meet the terms of its contract. This contract will include agreed levels of
availability, reliability and/or maintainability for a supporting service or
component.
Aspects of Availability - Maintainability & Serviceability

Maintainability: Maintainability is a measure of how quickly and effectively a service,
component or CI can be restored to normal working after a failure. It is measured and reported
as the mean time to restore service (MTRS) and should be calculated using the following
formula:
Maintainability (MTRS in hours) = Total downtime in hours / Number of service breaks
MTRS should be used to avoid the ambiguity of the more common industry term mean time
to repair (MTTR), which in some definitions includes only repair time, but in others includes
181
4
MODULE
SERVICE DESIGN
recovery time. The downtime in MTRS covers all the contributory factors that make the
service, component or CI unavailable:
Time to record
Time to respond
Time to resolve
Time to physically repair or replace
Time to recover
Serviceability: Serviceability is the ability of a third-party supplier to meet the terms of its
contract. This contract will include agreed levels of availability, reliability and/or maintainability
for a supporting service or component. These aspects and their interrelationships are
illustrated in Figure 4.8.
Although the principal service target contained within SLAs for customers and the business
is availability, as illustrated in Figure 4.8, some customers also require reliability and
maintainability targets to be included in the SLA as well. Where these are included they
should relate to end-to-end service reliability and maintainability, whereas the reliability and
maintainability targets contained in OLAs and contracts relate to component and supporting
service targets and can often include availability targets relating to the relevant components
or supporting services.
182
4
MODULE
SERVICE DESIGN
Vital Business Function (VBF)

Vital business function: The term vital business function (VBF) is used to
reflect the part of a business process that is critical to the success of the
business. An IT service may support a number of business functions that
are less critical.

For example, an automated teller machine (ATM) or cash dispenser
service VBF would be the dispensing of cash. However, the ability to obtain
a statement from an ATM may not be considered as vital. This distinction
is important and should influence availability design and associated costs.
Vital Business Function (VBF)

Vital business function: The term vital business function (VBF) is used to reflect the part of
a business process that is critical to the success of the business. An IT service may support
a number of business functions that are less critical. For example, an automated teller
machine (ATM) or cash dispenser service VBF would be the dispensing of cash. However, the
ability to obtain a statement from an ATM may not be considered as vital. This distinction is
important and should influence availability design and associated costs. The more vital the
business function generally, the greater the level of resilience and availability that needs to be
incorporated into the design required in the supporting IT services. For all services, whether
VBFs or not, the availability requirements should be determined by the business and not by
IT. The initial availability targets are often set at too high a level, and this leads to either overpriced services or an iterative discussion between the service provider and the business to
agree an appropriate compromise between the service availability and the cost of the service
and its supporting technology.
183
4
MODULE
SERVICE DESIGN
Certain VBFs may need special designs, which are now being used as a matter of course
within service design plans, incorporating:
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 maybe down even though the IT service
remains available.
Continuous availability An approach or design to achieve 100% availability. A continuously
available IT service has no planned or unplanned downtime.
184
4
MODULE
SERVICE DESIGN
Availability Management - Activities

Reacve acvies
Monitor, measure,
analyse, report and review
service and
component availability
Availability
management
informaon
system (AMIS)
Invesgate all service

and component
unavailability and insgate
remedial acon
Availability
management
reports
Proacve acvies
Risk assessment
and management
Risk assessment
and management
Implement
cost-jusfiable
countermeasures
Review all new and

changed services and
test all availability and
resilience mechanisms
Availability
plan
Availability
design criteria
Availability
tesng
schedule
Connual review
and improvement
Availability Management - Activities

Reactive activities: The reactive aspect of availability management involves work to ensure
that current operational services and components deliver the agreed levels of availability and
to respond appropriately when they do not. The reactive activities include:
Monitoring, measuring, analysing, reporting and reviewing service and component availability
Investigating all service and component unavailability and instigating remedial action. This
includes looking at events, incidents and problems involving unavailability.
185
4
MODULE
SERVICE DESIGN
These activities are primarily conducted within the service operation stage of the service
lifecycle and are linked into the monitoring and control activities and incident management
processes.
Proactive activities: The proactive activities of availability management involve the work
necessary to ensure that new or changed services can and will deliver the agreed levels
of availability and that appropriate measurements are in place to support this work. They
include producing recommendations, plans and documents on design guidelines and criteria
for new and changed services, and the continual improvement of service and reduction of risk
in existing services wherever it can be cost-justified. These are key aspects to be considered
within service design activities. Proactive activities include:
Planning and designing new or changed services:
Determining the VBFs, in conjunction with the business and ITSCM.
Determining the availability requirements from the business for a new or enhanced IT
service and formulating the availability and recovery design criteria for the supporting IT
components.
Defining the targets for availability, reliability and maintainability for the IT infrastructure
components that underpin the IT service to enable these to be documented and agreed
within SLAs, OLAs and contracts.
Performing risk assessment and management activities to ensure the prevention and/or
recovery from service and component Unavailability.
Designing the IT services to meet the availability and recovery design criteria and
associated agreed service levels.
Establishing measures and reporting of availability, reliability and maintainability that
reflect the business, user and IT support organization perspectives.
Risk assessment and management:
Determining the impact arising from IT service and component failure in conjunction
with ITSCM and, where appropriate, reviewing the availability design criteria to provide
additional resilience to prevent or minimize impact to the business
186
4
MODULE
SERVICE DESIGN
Implementing cost-justifiable countermeasures, including risk reduction and recovery

mechanisms
Reviewing all new and changed services and testing all availability and resilience mechanisms
Continual reviewing and improvement:
Producing and maintaining an availability plan that prioritizes and plans IT availability
improvements.
187
4
MODULE
SERVICE DESIGN
Availability Management - Role

Availability Management Process Manager
Carrying out the generic process manager role for the availability management
process.
Coordinating interfaces between availability management and other processes,
especially service level management, capacity management, IT service continuity
management and information security management.
Ensuring that all existing services deliver the levels of availability agreed with the
business in SLAs.
Ensuring that all new services are designed to deliver the levels of availability
required by the business, and validation of the final design to meet the minimum
levels of availability as agreed by the business for IT services.
Availability Management - Role

Availability Management Roles: This describes a number of roles that need to be performed
in support of the availability management process. These roles are not job titles, and each
organization will have to define appropriate job titles and job descriptions depending on
its needs.
Availability Management Process Owner: The availability management process owners
Carrying out the generic process owner role for the availability management process
Working with managers of all functions to ensure acceptance of the availability
management process as the single point of coordination for all availability-related issues,
regardless of the specific technology involved
188
4
MODULE
SERVICE DESIGN
Working with other process owners to ensure there is an integrated approach to the
design and implementation of availability management, service level management,
capacity management, IT service continuity management and information security
management.
Availability Management Process Manager: The availability management process manager
Carrying out the generic process manager role for the availability management process.
Ensuring that all new services are designed to deliver the levels of availability required by
the business, and validation of the final design to meet the minimum levels of availability
as agreed by the business for IT services.
Assisting with the investigation and diagnosis of all incidents and problems that cause
availability issues or unavailability of services or components.
Participating in the IT infrastructure design, including specifying the availability
requirements for hardware and software.
Specifying the requirements for new or enhanced event management systems for
automatic monitoring of availability of IT components.
Specifying the reliability, maintainability and serviceability requirements for components
supplied by internal and external suppliers.
Being responsible for monitoring actual IT availability achieved against SLA targets, and
providing a range of IT availability reporting to ensure that agreed levels of availability,
reliability and maintainability are measured and monitored on an ongoing basis.
Proactively improving service availability wherever possible, and optimizing the
availability of the IT infrastructure to deliver cost-effective improvements that deliver
tangible benefits to the business.
Creating, maintaining and regularly reviewing an availability management information
system and a forward-looking availability plan, aimed at improving the overall availability
of IT services and infrastructure components, to ensure that existing and future business
availability requirements can be met.
189
4
MODULE
SERVICE DESIGN
Ensuring that the availability management process, its associated techniques and
methods are regularly reviewed and audited, and that all of these are subject to continual
improvement and remain fit for purpose.
Creating availability and recovery design criteria to be applied to new or enhanced
infrastructure design.
Working with financial management for IT services, ensuring the levels of IT availability
required are cost-justified.
Maintaining and completing an availability testing schedule for all availability mechanisms.
Ensuring that all availability tests and plans are tested after every major business change.
Assisting security and IT service continuity management with the assessment and
management of risk.
Assessing changes for their impact on all aspects of availability, including overall service
availability and the availability plan.
Attending CAB meetings when appropriate.
190
4
MODULE
SERVICE DESIGN
Capacity Management
Purpose:
The purpose of the capacity management process is to ensure that the capacity of
IT services and the IT infrastructure meets the agreed capacity and performancerelated requirements in a cost-effective and timely manner.
Objectives:
Produce and maintain an appropriate and up-to-date capacity 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 capacity- and performance-related issues.
Ensure that service performance achievements meet all of their agreed
targets by managing the performance and capacity of both services and
resources.
Capacity Management
Purpose and objectives: The purpose of the capacity management process is to ensure that the
capacity of IT services and the IT infrastructure meets the agreed capacity and performancerelated requirements in a cost-effective and timely manner. Capacity management is
concerned with meeting both the current and future capacity and performance needs of the
business.
The objectives of capacity management are to:
Produce and maintain an appropriate and up-to-date capacity 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 capacity- and
performance-related issues.
191
4
MODULE
SERVICE DESIGN
Ensure that service performance achievements meet all of their agreed targets by
managing the performance and capacity of both services and resources.
Assist with the diagnosis and resolution of performance- and capacity-related incidents
and problems.
Assess the impact of all changes on the capacity plan, and the performance and capacity
of all services and resources.
Ensure that proactive measures to improve the performance of services are implemented
192
4
MODULE
SERVICE DESIGN
Capacity Management Process

Scope:
The capacity management process should be the focal point for all IT
performance and capacity issues. Capacity management considers all
resources required to deliver the IT service, and plans for short-, mediumand long-term business requirements.
The process should encompass all areas of technology, both hardware
and software, for all IT technology components and environments.
The scheduling of human resources, staffing levels, skill levels and
capability levels should therefore be included within the scope of capacity
management.
Capacity Management Process

Scope: The capacity management process should be the focal point for all IT performance
and capacity issues. Capacity management considers all resources required to deliver the IT
service, and plans for short-, medium- and long-term business requirements.
The process should encompass all areas of technology, both hardware and software, for all
IT technology components and environments. Capacity management should also consider
space planning and environmental systems capacity. Capacity management could consider
human resource capacity here a lack of human resources could result in a breach of SLA or
OLA targets, a delay in the end-to-end performance or service response time, or an inability
to meet future commitments and plans (e.g. overnight data backups not completed in time
because no operators were present to load required media). In general, human resource
management is a line management responsibility, although the staffing of a service desk
should use identical capacity management techniques. The scheduling of human resources,
staffing levels, skill levels and capability levels should therefore be included within the scope
of capacity management.
193
4
MODULE
SERVICE DESIGN
The capacity management process should include:

Monitoring patterns of business activity through performance, utilization and throughput
of IT services and the supporting infrastructure, environmental, data and applications
components and the production of regular and ad hoc reports on service and component
capacity and performance.
Undertaking tuning activities to make the most efficient use of existing IT resources.
Understanding the agreed current and future demands being made by the customer for
IT resources, and producing forecasts for future requirements.
Influencing demand in conjunction with the financial management for IT services and
demand management processes.
Producing a capacity plan that enables the service provider to continue to provide
services of the quality defined in SLAs and that covers a sufficient planning timeframe to
meet future service levels required as defined in the service portfolio and SLRs.
Assisting with the identification and resolution of any incidents and problems associated
with service or component capacity or performance.
The proactive improvement of service or component performance, wherever it is cost
justifiable and meets the needs of the business.
Capacity management also includes understanding the potential for the delivery of new
services. New technology needs to be understood and, if appropriate, used to innovate and
deliver the services required by the customer. Capacity management should recognize that
the rate of technological change will probably increase and that new technology should be
harnessed to ensure that the IT services continue to satisfy changing business expectations.
A direct link to the service strategy and service portfolio is needed to ensure that emerging
technologies are considered in future service planning.
Capacity management has a close, two-way relationship with the service strategy and
planning processes within an organization. On a regular basis, the long-term strategy of
an organization is encapsulated in an update of the business plans. The service strategy
will reflect the business plans and strategy, which are developed from the organizations
194
4
MODULE
SERVICE DESIGN
understanding of the external factors such as the competitive marketplace, economic

outlook and legislation, and its internal capability in terms of manpower, delivery capability
etc. Often a shorter-term tactical plan or business change plan is developed to implement
the changes necessary in the short to medium term to progress the overall business plan and
service strategy. Capacity management needs to understand the short-, medium- and longterm plans of the business and IT while providing information on the latest ideas, trends and
technologies being developed by the suppliers of computing hardware and software.
The organizations business plans drive the specific IT service strategy, the contents of which
capacity management needs to be familiar with, and to which capacity management needs
to have had significant and ongoing input. The right level of capacity at the right time is
critical. Service strategy plans will be helpful to capacity planning by identifying the timing for
acquiring and implementing new technologies, hardware and software.
Capacity management is responsible for ensuring that IT resources are planned and scheduled
to provide a consistent level of service that is matched to the current and future needs of the
business, as agreed and documented within SLAs and OLAs. In conjunction with the business
and its plans, capacity management provides a capacity plan that outlines the IT resources
and funding needed to support the business plan, together with a cost justification of that
expenditure.
195
4
MODULE
SERVICE DESIGN
Capacity Management Processes

Service portfolio
Business
requirements
Business
capacity management
SLA/SLR
IT service
design
Service
capacity management
Review current capacity

and performance
Improve current service

and component capacity
Assess, agree and

document new
requirements and capacity
Component capacity
management
Capacity management
information system
(CMIS)
Capacity and
performance
reports
Forecasts
Capacity plan
Plan new capacity
Capacity
management tools
Capacity Management Processes

Business capacity management: The business capacity management sub process translates
business needs and plans into requirements for service and IT infrastructure, ensuring that
the future business requirements for IT services are quantified, designed, planned and
implemented in a timely fashion. This can be achieved by using the existing data on the
current resource utilization by the various services and resources to trend, forecast, model or
predict future requirements. These future requirements come from the service strategy and
service portfolio detailing new processes and service requirements, changes, improvements,
and also the growth in the existing services.
Service capacity management: The service capacity management sub-process focuses on the
management, control and prediction of the end-to-end performance and capacity of the live,
operational IT services usage and workloads. It ensures that the performance of all services,
as detailed in service targets within SLAs and SLRs, is monitored and measured, and that
196
4
MODULE
SERVICE DESIGN
the collected data is recorded, analysed and reported. Wherever necessary, proactive and
reactive action should be instigated, to ensure that the performance of all services meets
their agreed business targets. This is performed by staff with knowledge of all the areas of
technology used in the delivery of end-to-end service, and often involves seeking advice from
the specialists involved in component capacity management. Wherever possible, automated
thresholds should be used to manage all operational services, to ensure that situations where
service targets are breached or threatened are rapidly identified and cost-effective actions to
reduce or avoid their potential impact are implemented.
Component capacity management: The component capacity management sub process
focuses on the management, control and prediction of the performance, utilization and
capacity of individual IT technology components. It ensures that all components within
the IT infrastructure that have finite resource are monitored and measured, and that the
collected data is recorded, analysed and reported. Again, wherever possible, automated
thresholds should be implemented to manage all components, to ensure that situations
where service targets are breached or threatened by component usage or performance are
rapidly identified, and cost-effective actions to reduce or avoid their potential impact are
implemented.
Capacity plan: This is used by all areas of the business and IT management, and is acted on
by the IT service provider and senior management of the organization to plan the capacity
of the IT infrastructure. It also provides planning input to many other areas of IT and the
business. It contains information on the current usage of service and components, and
plans for the development of IT capacity to meet the needs in the growth of both existing
service and any agreed new services. The capacity plan should be actively used as a basis for
decision-making. Too often, capacity plans are created and never referred to or used.
197
4
MODULE
SERVICE DESIGN
Capacity Manager Role

The capacity manager (process managers )responsibilities typically include:
Carrying out the generic process manager role for the capacity
management process.
Coordinating interfaces between capacity management and
other processes, especially service level management, availability
management, IT service continuity management and information
security management.
Ensuring that there is adequate IT capacity to meet required levels of
service, and that senior IT management is correctly advised on how to
match capacity and demand and to ensure that use of existing capacity
is optimized.
Capacity Manager Role
Capacity management process manager: The capacity management process managers
Carrying out the generic process manager role for the capacity management process.
Coordinating interfaces between capacity management and other processes, especially
service level management, availability management, IT service continuity management
and information security management.
Ensuring that there is adequate IT capacity to meet required levels of service, and that
senior IT management is correctly advised on how to match capacity and demand and to
ensure that use of existing capacity is optimized.
Identifying, with the service level manager, capacity requirements through discussions
with the business users.
198
4
MODULE
SERVICE DESIGN
Understanding the current usage of the infrastructure and IT services, and the maximum
capacity of each component.
Performing sizing on all proposed new services and systems, possibly using modelling
techniques, to ascertain capacity requirements.
Forecasting future capacity requirements based on business plans, usage trends, sizing
of new services etc.
Production, regular review and revision of the capacity plan, in line with the organizations
business planning cycle, identifying current usage and forecast requirements during the
period covered by the plan.
Ensuring that appropriate levels of monitoring of resources and system performance are
set.
Analysis of usage and performance data, and reporting on performance against targets
contained in SLAs.
Raising incidents and problems when breaches of capacity or performance thresholds are
detected, and assisting with the investigation and diagnosis of capacity-related incidents
and problems.
Identifying and initiating any tuning to be carried out to optimize and improve capacity
or performance.
Identifying and implementing initiatives to improve resource usage for example,
demand management techniques.
Assessing new technology and its relevance to the organization in terms of performance
and cost.
Being familiar with potential future demand for IT services and assessing this on
performance service levels.
Ensuring that all changes are assessed for their impact on capacity and performance and
attending CAB meetings when appropriate.
199
4
MODULE
SERVICE DESIGN
Producing regular management reports that include current usage of resources, trends
and forecasts.
Sizing all proposed new services and systems to determine the computer and network
resources required, to determine hardware utilization, performance service levels and
cost implications.
Assessing new techniques and hardware and software products for use by capacity
management that might improve the efficiency and effectiveness of the process.
Testing performance of new services and systems.
Preparing reports on service and component performance against targets contained in
SLAs.
Maintaining a knowledge of future demand for IT services and predicting the effects of
demand on performance service levels.
Determining performance service levels that are maintainable and cost-justified.
Recommending tuning of services and systems, and making recommendations to
IT management on the design and use of systems to help ensure optimum use of all
hardware and operating system software resources.
Acting as a focal point for all capacity and performance issues.
200
4
MODULE
SERVICE DESIGN

Purpose
The purpose of the IT service continuity management process is to support
the overall business continuity management (BCM) process by ensuring
that, by managing the risks that could seriously affect IT services, the IT
service provider can always provide minimum agreed business continuityrelated service levels.
Objectives
Produce and maintain a set of IT service continuity plans that support
the overall business continuity plans of the organization.
Complete regular BIA exercises to ensure that all continuity plans are
maintained in line with changing business impacts and requirements.
Provide advice and guidance to all other areas of the business and IT on
all continuity-related issues.

Purpose and objectives: The purpose of the IT service continuity management process is
to support the overall business continuity management (BCM) process by ensuring that, by
managing the risks that could seriously affect IT services, the IT service provider can always
provide minimum agreed business continuity-related service levels.
In support of and alignment with the BCM process, ITSCM uses formal risk assessment and
management techniques to:
Reduce risks to IT services to agreed acceptable levels.
Plan and prepare for the recovery of IT services.
201
4
MODULE
SERVICE DESIGN
The objectives of ITSCM are to:

Produce and maintain a set of IT service continuity plans that support the overall business
continuity plans of the organization.
Complete regular BIA exercises to ensure that all continuity plans are maintained in line
with changing business impacts and requirements.
Conduct regular risk assessment and management exercises to manage IT services within
an agreed level of business risk in conjunction with the business and the availability
management and information security management processes.
Provide advice and guidance to all other areas of the business and IT on all continuityrelated issues.
Ensure that appropriate continuity mechanisms are put in place to meet or exceed the
agreed business continuity targets.
Assess the impact of all changes on the IT service continuity plans and supporting
methods and procedures.
Ensure that proactive measures to improve the availability of services are implemented
Negotiate and agree contracts with suppliers for the provision of the necessary recovery
capability to support all continuity plans in conjunction with the supplier management
process.
202
4
MODULE
SERVICE DESIGN

Scope
ITSCM primarily considers the IT assets and configurations that support
the business processes.
ITSCM focuses on those events that the business considers significant
enough to be treated as 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 impact of a loss of a business process, such as financial loss, damage

to reputation or regulatory breach, is measured through a BIA exercise,
which determines the minimum critical requirements.

Scope: ITSCM focuses on those events that the business considers significant enough to
be treated as 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 impact of a loss of a business process, such as financial loss, damage to reputation or
regulatory breach, is measured through a BIA exercise, which determines the minimum critical
requirements. The specific IT technical and service requirements are supported by ITSCM. The
scope of ITSCM within an organization is determined by the organizational structure, culture
and strategic direction (both business and technology) in terms of the services provided and
how these develop and change over time.
203
4
MODULE
SERVICE DESIGN
ITSCM primarily considers the IT assets and configurations that support the business
processes. If (following a disaster) it is necessary to relocate to an alternative working location,
provision will also be required for items such as office and personnel accommodation,
copies of critical paper records, courier services and telephone facilities to communicate
with customers and third parties. The scope will need to take into account the number and
location of the organizations offices and the services performed in each.
ITSCM does not usually directly cover longer term risks such as those from changes in business
direction, diversification, restructuring, major competitor failure, and so on. While these
risks can have a significant impact on IT service elements and their continuity mechanisms,
there is usually time to identify and evaluate the risk and include risk mitigation through
changes or shifts in business and IT strategies, thereby becoming part of the overall business
and IT change management programme.
Similarly, ITSCM does not usually cover minor technical faults (for example, non-critical
disk failure), unless there is a possibility that the impact could have a major impact on the
business. These risks would be expected to be covered mainly through the service desk and
the incident management process, or resolved through the planning associated with the
processes of availability management, problem management, change management, service
asset and configuration management and business as usual operational management. The
ITSCM process includes:
The agreement of the scope of the ITSCM process and the policies adopted
BIA to quantify the impact loss of IT service would have on the business
Risk assessment and management the risk identification and risk assessment to identify
potential threats to continuity and the likelihood of the threats becoming reality.
This also includes taking measures to manage the identified threats where this can be cost
justified. The approach to managing these threats will form the core of the ITSCM strategy
and plans
Production of an overall ITSCM strategy that must be integrated into the BCM strategy.
This can be produced following the BIA and the development of the risk assessment,
and is likely to include elements of risk reduction as well as selection of appropriate and
comprehensive recovery options.
204
4
MODULE
SERVICE DESIGN
Production of an ITSCM plan, which again must be integrated with the overall BCM plans.
Testing of the plans.
Ongoing operation and maintenance of the plans.
205
4
MODULE
SERVICE DESIGN

Business Impact Analysis
The purpose of a BIA is to quantify the impact to the business that loss of
service would have. This impact could be a hard impact that can be precisely
identified such as financial loss or soft impact such as public relations,
moral, health and safety or loss of competitive advantage.
The BIA identifies:
The form that the damage or
loss may take for example:
Lost income
How the degree of damage

or loss is likely to escalate
after a service disruption
The time within which

minimum levels of staffing,
facilities and services should
be recovered
Additional costs
Damaged reputation

Business Impact Analysis: The purpose of a BIA is to quantify the impact to the business
that loss of service would have. This impact could be a hard impact that can be precisely
identified such as financial loss or soft impact such as public relations, moral, health
and safety or loss of competitive advantage. The BIA will identify the most important services
to the organization and will therefore be a key input to the strategy. The BIA identifies:
The form that the damage or loss may take for example:
Lost income
Additional costs
Damaged reputation
206
4
MODULE
SERVICE DESIGN
Loss of goodwill
Loss of competitive advantage
Breach of law, health and safety regulations
Risk to personal safety
Immediate and long-term loss of market share
Political, corporate or personal embarrassment
Loss of operational capability, for example, in a command and control environment
How the degree of damage or loss is likely to escalate after a service disruption, and the
times of the day, week, month or year when disruption will be most severe.
The staffing, skills, facilities and services (including the IT services) necessary to enable
critical and essential business processes to continue operating at a minimum acceptable
level.
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.
207
4
MODULE
SERVICE DESIGN

Risk Assessment
This is an assessment of the level of threat and the extent to which an
organization is vulnerable to that threat.
Risk assessment 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.
Risk assessment is also a key aspect of information security management.
Risk assessment is the assessment of risks that may give rise to service disruption or
security violation.
Risk Management is concerned with identifying appropriate risk responses or cost
justifiable counter measures to combat those risks.

Risk Assessment: The second driver in determining ITSCM requirements is the likelihood that
a disaster or other serious service disruption will actually occur. This is an assessment of
the level of threat and the extent to which an organization is vulnerable to that threat. Risk
assessment 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. Risk assessment is also a key aspect of
information security management.
A number of risk assessment and management methods are available for both the commercial
and government sectors. Risk assessment is the assessment of the risks that may give rise
to service disruption or security violation. Risk management is concerned with identifying
appropriate risk responses or cost-justifiable countermeasures to combat those risks.
208
4
MODULE
SERVICE DESIGN
A standard methodology, such as the Management of Risk (M_o_R), should be used to assess
and manage risks within an organization. The M_o_R framework is described in greater detail
in Appendix M. Conducting a formal risk assessment using M_o_R or another structured
method will typically result in a risk profile, containing many risks that are outside the defined
level of acceptable risk. Following the risk assessment it is possible to determine appropriate
risk responses or risk reduction measures (ITSCM mechanisms) to manage the risks, i.e.
reduce the risk to an acceptable level or mitigate the risk. Wherever possible, appropriate
risk responses should be implemented to reduce either the impact or the likelihood, or both,
of these risks from manifesting themselves. In the context of ITSCM, there are a number of
risks that need to be taken into consideration.
IT service continuity strategy: The results of the BIA and the risk assessment will enable
appropriate business and IT service continuity strategies to be produced in line with the
business needs. The strategy will be an optimum balance of risk reduction and recovery or
continuity options. This includes consideration of the relative service recovery priorities and
the changes in relative service priority for the time of day, day of the week, and monthly
and annual variations. Those services that have been identified as high impacts in the short
term within the BIA will want to concentrate efforts on preventive risk reduction methods
for example, through full resilience and fault tolerance while an organization that has low
short-term impacts would be better suited to comprehensive recovery options.
209
4
MODULE
SERVICE DESIGN

The Purpose of the information security management process is to align IT
security with business security and ensure that the confidentiality, integrity and
availability of the organizations assets, information, data and IT services always
matches the agreed needs of the business.
Objective
The objective of information security management is to protect the interests of
those relying on information, and the systems and communications that deliver
the information, from harm resulting from failures of confidentiality, integrity
and availability.

Purpose and objectives: The purpose of the information security management process is
to align IT security with business security and ensure that the confidentiality, integrity and
availability of the organizations assets, information, data and IT services always matches the
agreed needs of the business.
The objective of information security management is to protect the interests of those relying
on information, and the systems and communications that deliver the information, from harm
210
4
MODULE
SERVICE DESIGN
resulting from failures of confidentiality, integrity and availability. For most organizations, the
security objective is met when:
Information is observed by or disclosed to only those who have a right to know
(confidentiality).
Information is complete, accurate and protected against unauthorized modification
(integrity).
Information is available and usable when required, and the systems that provide it can
appropriately resist attacks and recover from or prevent failures (availability).
Business transactions, as well as information exchanges between enterprises, or with
partners, can be trusted (authenticity and nonrepudiation).
211
4
MODULE
SERVICE DESIGN

Scope
The information security management process should be the focal point for
all IT security issues, and must ensure that an information security policy is
produced, maintained and enforced that covers the use and misuse of all IT
systems and services.

Information security management needs to understand the total IT and
business security environment, including the:
Business security policy and plans
Current business operation and its
security requirements
Future business plans and requirements
Legislative and regulatory requirements
Obligations and responsibilities with regard
to security contained within SLAs
The business and IT risks and their
management.

Scope: The information security management process should be the focal point for all IT
security issues, and must ensure that an information security policy is produced, maintained
and enforced that covers the use and misuse of all IT systems and services. Information
security management needs to understand the total IT and business security environment,
including the:
212
4
MODULE
SERVICE DESIGN
Business security policy and plans.

Current business operation and its security requirements.
Future business plans and requirements.
Legislative and regulatory requirements.
Obligations and responsibilities with regard to security contained within SLAs.
The business and IT risks and their management.
Understanding all of this will enable information security management to ensure that all the
current and future security aspects and risks of the business are cost-effectively managed.
Prioritization of confidentiality, integrity and availability must be considered in the context of
business and business processes. The primary guide to defining what must be protected and
the level of protection has to come from the business. To be effective, security must address
entire business processes from end to end and cover the physical and technical aspects. Only
within the context of business needs and risks can management define security.
The information security management process should include:
The production, maintenance, distribution and enforcement of an information security
policy and supporting security policies.
Understanding the agreed current and future security requirements of the business and
the existing business security policy and plans.
Implementation of a set of security controls that support the information security policy
and manage risks associated with access to services, information and systems.
Documentation of all security controls, together with the operation and maintenance of
the controls and their associated risks.
Management of suppliers and contracts regarding access to systems and services, in
conjunction with supplier management.
213
4
MODULE
SERVICE DESIGN
Management of all security breaches, incidents and problems associated with all systems
and services
The proactive improvement of security controls, and security risk management and the
reduction of security risks
Integration of security aspects within all other ITSM processes.
To achieve effective information security governance, management must establish and
maintain an information security management system (ISMS) to guide the development
and management of a comprehensive information security programme that supports the
business objectives.
214
4
MODULE
SERVICE DESIGN

Information Security Policy
The information security policy should have the full support of top executive
IT management and ideally the support and commitment of top executive
business management.
The policy should cover all areas of security, be appropriate, meet the needs of
the business and should include:
Use and misuse of IT
assets policy
A document
classification policy
A remote access
policy
An access control
policy
An information
classification policy
An asset disposal
policy
A password control
policy
An anti-virus policy
A records retention
policy
An email policy
An internet policy

Activities should be focused on and driven by an overall information security policy and a set
of underpinning specific security policies. The information security policy should have the
full support of top executive IT management and ideally the support and commitment of top
executive business management.
215
4
MODULE
SERVICE DESIGN
The policy should cover all areas of security, be appropriate, meet the needs of the business
and should include:
An overall information security policy.
Use and misuse of IT assets policy.
An access control policy.
A password control policy.
An email policy.
An internet policy.
An anti-virus policy.
An information classification policy.
A document classification policy.
A remote access policy.
A policy with regard to supplier access to IT service, information and components.
A copyright infringement policy for electronic material.
An asset disposal policy.
A records retention policy.
In most cases, these policies should be widely available to all customers and users, and
their compliance should be referred to in all SLRs, SLAs, OLAs, underpinning contracts and
agreements. The policies should be authorized by top executive management within the
business and IT, and compliance with them should be endorsed on a regular basis. All security
policies should be reviewed and, where necessary, revised on at least an annual basis.
216
4
MODULE
SERVICE DESIGN
Supplier Management Process

Purpose
The purpose of the supplier management process is to obtain value for
money from suppliers and to provide seamless quality of IT service to the
business by ensuring that all contracts and agreements with suppliers
support the needs of the business and that all suppliers meet their
contractual commitments.
Objectives
Obtain value for money from suppliers and contracts.
Manage relationships with suppliers Manage supplier performance.
Negotiate and agree contracts with suppliers and manage them
through their lifecycle.

Purpose and objectives: TThe purpose of the supplier management process is to obtain value
for money from suppliers and to provide seamless quality of IT service to the business by
ensuring that all contracts and agreements with suppliers support the needs of the business
and that all suppliers meet their contractual commitments.
The main objectives of the supplier management process are to:
Obtain value for money from suppliers and contracts.
Ensure that contracts with suppliers are aligned to business needs, and support and align
with agreed targets in SLRs and SLAs, in conjunction with SLM.
Manage relationships with suppliers Manage supplier performance.
Negotiate and agree contracts with suppliers and manage them through their lifecycle.
Maintain a supplier policy and a supporting supplier and contract management

information system (SCMIS).
217
4
MODULE
SERVICE DESIGN

Scope
The supplier management process should include the management of all
suppliers and contracts needed to support the provision of IT services to the
business.
Each service provider should have formal processes for the management of all
suppliers and contracts.
The supplier management process should include:
Maintenance of an
SCMIS

evaluation and
selection

categorization and risk
assessment
Contract review,
renewal and
termination
Development,
negotiation and
agreement of contracts

Scope: The supplier management process should include the management of all suppliers
and contracts needed to support the provision of IT services to the business. Each service
provider should have formal processes for the management of all suppliers and contracts.
However, the processes should adapt to cater for the importance of the supplier and/or
the contract and the potential business impact on the provision of services. Many suppliers
provide support services and products that independently have a relatively minor, and fairly
indirect, role in value generation, but collectively make a direct and important contribution
218
4
MODULE
SERVICE DESIGN
to value generation and the implementation of the overall business strategy. The greater the
contribution the supplier makes to business value, the more effort the service provider should
put into the management of the supplier and the more that supplier should be involved in
the development and realization of the business strategy. The smaller the suppliers value
contribution, the more likely it is that the relationship will be managed mainly at an operational
level, with limited interaction with the business. It may be appropriate in some organizations,
particularly large ones, to manage internal teams and suppliers, where different business
units may provide support of key elements.
The supplier management process should include:
Implementation and enforcement of the supplier policy.
Maintenance of an SCMIS.
Supplier and contract categorization and risk assessment.
Supplier and contract evaluation and selection.
Development, negotiation and agreement of contracts.
Contract review, renewal and termination.
Management of suppliers and supplier performance.
Identification of improvement opportunities for inclusion in the CSI register, and the
implementation of service and supplier improvement plans.
Maintenance of standard contracts, terms and conditions.
Management of contractual dispute resolution.
Management of sub-contracted suppliers.
IT supplier management often has to comply with organizational or corporate standards,
guidelines and requirements, particularly those of corporate legal, finance and purchasing.
219
4
MODULE
SERVICE DESIGN
In order to ensure that suppliers provide value for money and meet their service targets,
the relationship between each supplier should be owned by an individual within the service
provider organization. However, a single individual may own the relationship for one or
many suppliers. To ensure that relationships are developed in a consistent manner and that
suppliers performance is appropriately reviewed and managed, roles need to be established
for a supplier management process owner and a contracts manager. In smaller organizations,
these separate roles may be combined into a single responsibility.
220
Supplier Categorization
Value and importance
MODULE
SERVICE DESIGN
High
Opera onal
Medium
suppliers
Low
Commodity
suppliers
Strategic
suppliers
Tac cal
suppliers
Opera onal
suppliers
Low
Medium
High
Risk and impact
Supplier Categorization
The supplier management process should be adaptive and managers should spend more time
and effort managing key suppliers than less important suppliers. This means that some form
of categorization scheme should exist within the supplier management process to categorize
the supplier and their importance to the service provider and the services provided to the
business.
Suppliers can be categorized in many ways, but one of the best methods for categorizing
suppliers is based on assessing the risk and impact associated with using the supplier, and the
221
4
MODULE
SERVICE DESIGN
value and importance of the supplier and its services to the business. The amount of time
and effort spent managing the supplier and the relationship can then be appropriate to its
categorization:
Strategic For significant partnering relationships that involve senior managers sharing
confidential strategic information to facilitate long-term plans. These relationships
would normally be managed and owned at a senior management level within the service
provider organization, and would involve regular and frequent contact and performance
reviews. These relationships would probably require involvement of service strategy and
service design resources, and would include ongoing specific improvement programmes
(e.g. a network service provider supplying worldwide networks service and their support).
Tactical For relationships involving significant commercial activity and business interaction.
These relationships would normally be managed by middle management and would
involve regular contact and performance reviews, often including ongoing improvement
programmes (e.g. a hardware maintenance organization providing resolution of server
hardware failures).
Operational For suppliers of operational products or services. These relationships would
normally be managed by junior operational management and would involve infrequent
but regular contact and performance reviews (e.g. an internet hosting service provider,
supplying hosting space for a low-usage, low-impact website or internally used IT service).
Commodity For suppliers providing low-value and/or readily available products and
services, which could be alternatively sourced relatively easily (e.g. paper or printer
cartridge suppliers).
Strategically important supplier relationships are given the greatest focus. It is in these cases
that supplier managers have to ensure that the culture of the service provider organization is
extended into the supplier domain so that the relationship works beyond the initial contract.
The rise in popularity of outsourcing, and the increase in the scope and complexity of some
sourcing arrangements, has resulted in a diversification of types of supplier relationship. At
a strategic level, it is important to understand the options that are available so that the most
suitable type of supplier relationship can be established to gain maximum business benefit
and evolves in line with business needs.
222
4
MODULE
SERVICE DESIGN
A number of factors, from the nature of the service to the overall cost, determine the
importance of a supplier from a business perspective. As shown later, the greater the business
significance of a supplier relationship, the more the business needs to be involved in the
management and development of a relationship. A formal categorization approach can help
to establish this importance.
223
4
MODULE
SERVICE DESIGN
Roles Process Practitioner

A process practitioner is responsible for carrying out one or more
process activities.
Carrying out one or more activities of a process.
Working with other stakeholders, such as their manager, co-workers,
users and customers, to ensure that their contributions are effective.
Ensuring that inputs, outputs and interfaces for their activities are
correct.
Creating or updating records to show that activities have been carried
out correctly.
Roles Process Practitioner

Process practitioner role: A process practitioner is responsible for carrying out one or more
process activities.
In some organizations, and for some processes, the process practitioner role may be combined
with the process manager role; in others there may be large numbers of practitioners carrying
out different parts of the process. The process practitioners responsibilities typically include:
Carrying out one or more activities of a process.
Understanding how their role contributes to the overall delivery of service and creation
of value for the business.
Working with other stakeholders, such as their manager, co-workers, users and customers,
to ensure that their contributions are effective.
Ensuring that inputs, outputs and interfaces for their activities are correct.
Creating or updating records to show that activities have been carried out correctly.
224
4
MODULE
SERVICE DESIGN
Roles Process Owner

The process owner is responsible for ensuring that all activities defined
within the process are undertaken and is responsible for:
Sponsoring, designing and change managing the process and its
metrics.
Defining the process strategy.
Assisting with process design.
Ensuring that appropriate process documentation is available and
current.
Defining appropriate policies and standards to be employed
throughout the process.
Roles Process Owner
Some more roles of process owner:
Sponsoring, designing and change managing the process and its metrics.
Defining process strategy.
Assisting with process design.
Ensuring that appropriate process documentation is available and current.
Periodically auditing the process to ensure compliance to policy and standards.
Communicating process information or changes as appropriate to ensure awareness.
225
4
MODULE
SERVICE DESIGN
Providing process resources to support activities required throughout the Service

Management lifecycle.
Ensuring process technicians have the required knowledge and the required technical
and business understanding to deliver the process, and understand their role in the
process.
Reviewing opportunities for process enhancements and for improving the efficiency
and effectiveness of the process.
Addressing issues with the running of the process.
Providing input to the ongoing service improvement plan.
226
4
MODULE
SERVICE DESIGN
Roles Process Manager

The process managers accountabilities include:
Working with the process owner to plan and coordinate all process
activities.
Ensuring that all activities are carried out as required throughout the
service lifecycle.
Appointing people to the required roles.
Managing resources assigned to the process.
Working with service owners and other process managers to ensure
the smooth running of services.
Roles Process Manager

Generic Process manager Role: 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.
The process managers accountabilities include:
Working with the process owner to plan and coordinate all process activities.
Ensuring that all activities are carried out as required throughout the service lifecycle.
Appointing people to the required roles.
Managing resources assigned to the process.
227
4
MODULE
SERVICE DESIGN
Working with service owners and other process managers to ensure the smooth running
of services.
Monitoring and reporting on process performance.
Working with the CSI manager and process owner to review and prioritize improvements
in the CSI register.
Making improvements to the process implementation.
228
4
MODULE
SERVICE DESIGN
Service Design Tools

There are many tools that may be used to assist with the design of
services.
These tools and techniques help in:
Hardware Design
Software Design
Environmental Design
Process Design
Data Design
229
4
MODULE
SERVICE DESIGN
Summary
Service Design Overview

4 Ps of Service Design
Vital Business Function
Service Design Package
Five aspect of Service Design
Agreements, SLA Frameworks
Processes
Roles Process Manager, Process Owner and Practitioner
230
4
MODULE
SERVICE DESIGN
Assessment
231
4
MODULE
SERVICE DESIGN
1.
Which of the following would commonly be in a contract underpinning an IT service?

1. Market Information
2. Contract description and scope
3. Responsibilities and dependencies.
a. 1 and 2 only
b. 1 and 3 only
c. 2 and 3 only
d. None of the above.
2.
Availability Management is directly responsible for the availability of which of the

following:
a. IT services and components
b. IT services and Business Processes.
c. Components and Business Processes.
d. IT services, Components and Business Processes.
3.
Service Design emphasizes the importance of Four Ps, which of the following is a correct
list of these Four Ps?
a. People, Perceptions, Products and Partners
b. People, Perspectives, Products and Partners
c. People, Portfolio, Products and Partners
d. People, Processes, Products and Partners
4.
Which process is responsible for discussing reports with customers showing whether
services have met their targets?
a. Continual Service Improvement
b. Business Relationship Management
c. Service Level Management
d. Availability Management.
232
4
MODULE
SERVICE DESIGN
5.
Which process is responsible for managing relationships with vendors?

a. Change Management
b. Service Portfolio Management.
c. Supplier Management
d. Continual Service Improvement
6.
Which process contains the Business, Service and Component sub-processes?

a. Capacity Management
b. Incident Management
c. Service Level Management.
d. Financial Management.
7.
What are the three Service Provider Models?

a. Internal Service Provider, Internal Service Operations Provider, External Service
Provider
b. Internal Service Provider, Shared Service Unit, External Service Provider
c. In-sourced Service Provider, Shared Service Provider, External Service Provider
d. Internal Service Provider, Outsourced third party, External Service Provider
8.
Which of the following does not provide guidance on what needs to be protected by
Information Security Management?
a. IT Management
b. Service Desk Manager
c. Business Management.
d. The Change Manager
233
4
MODULE
SERVICE DESIGN
9.
Which of the following is a valid type of Service Level Agreement?

a. Priority based SLA
b. Technology based SLA
c. Location based SLA
d. Customer based SLA
10. The main goal of Availability Management is ?

a. To monitor and report availability of services and components.
b. To ensure that all targets in SLAs are met.
c. To guarantee availability levels for services and components.
d. To ensure that service availability matches or exceeds the agreed needs of the
business.
11. Which of the following statement about Supplier Management are INCORRECT?
a. Supplier Management negotiates Operational Level agreements with internal groups
to support the delivery of services.
b. Supplier Management ensures that suppliers meet business expectations.
c. Supplier Management maintains information in a Supplier and Contract database.
d. Supplier Management negotiates External agreements to support the delivery of
services
12. Which of the following are the business requirements for IT Availability? (tick 3 correct
of the four below)
a. Required service hours, i.e. when the service is to be provided.
b. An assessment of relative importance of different working periods
c. Portfolio Management Practices of the business.
d. Conditions under which the business consider the IT service unavailable.
234
4
MODULE
SERVICE DESIGN
13. Serviceability is an element of Availability Management. How is it best defined?

a. Prevention of failure.
b. The ability to restore services or components back to normal operation.
c. The percentage of agreed service hours for which the service is available.
d. The support which external suppliers can be contracted to provide for parts of the
IT infrastructure.
14. Given the following formula: Availability percentage = ((i-ii)/iii)*100, What should be
filled in for i, ii and iii?
a. i Reliability ii Duration of fault iii Agreed Service time
b. i Reliability ii Duration of fault iii Resilience
c. i Maintainability ii Resilience iii Resilience
d. i Maintainability ii Resilience iii Maintainability
e. i Agreed Service time ii Duration of fault iii Agreed Service time
235
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE TRANSITION
236
SERVICE TRANSITION
Co
SERVICE TRANSITION
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
Tra
n
siti o
237
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
5
MODULE
SERVICE TRANSITION
Learning Objectives
After the completion of this module participants will be able to:

Understand how Service Transition contributes to the Service Lifecycle.
Define and explain key concepts in Service Transition.
Understand and account for the key principles and models of Service
Transition.
Explain the objectives, scope, basic concepts, and activities of :
Change Management Process.
Explain the objectives and scope of the following processes:
Release and Deployment Management
Knowledge Management
Service Asset and Configuration Management
Transition Planning and Support
238
5
MODULE
SERVICE TRANSITION
Optimizing Service Transition

The service transition lifecycle stage and release plans need to be aligned
with the business, service management and IT strategies and plans. Typical
metrics that can be used in measuring this alignment are:
Increased percentage of service transition plans that are aligned with
the business, IT, service management strategies and plans.
Percentage of customer and stakeholder organizations or units that
have a clear understanding of the service transition practice and its
capabilities.
Percentage of service lifecycle budget allocated to service transition
activities.
Optimizing Service Transition:

In order to be effective and efficient, service transition must focus on delivering what the
business requires as a priority and doing so within financial and other resource constraints.
The service transition lifecycle stage and release plans need to be aligned with the business,
service management and IT strategies and plans. Typical metrics that can be used in measuring
this alignment are:
Increased percentage of service transition plans that are aligned with the business, IT,
service management strategies and plans.
Percentage of customer and stakeholder organizations or units that have a clear
understanding of the service transition practice and its capabilities.
Percentage of service lifecycle budget allocated to service transition activities.
239
5
MODULE
SERVICE TRANSITION
Quality rating of the plans including adherence to a structured approach, compliance

with the plan templates and completeness of the plans.
Percentage of planning meetings where stakeholders have participated.
Percentage of service transition plans that are aligned with the service transition policies.
Percentage of strategic and tactical projects that adopt the service transition service
practices.
Percentage of release planning documents that are quality assured by staff working in
service transition roles.
240
5
MODULE
SERVICE TRANSITION
Transition planning and Support Process

Purpose
The purpose of the transition planning and support process is to
provide overall planning for service transitions and to coordinate the
resources that they require.
Objectives
Plan and coordinate the resources to ensure that the requirements
of service strategy encoded in service design are effectively
realized in service operation.
Coordinate activities across projects, suppliers and service teams
where required.
Establish new or changed services into supported environments
within the predicted cost, quality and time estimates.

Purpose: The purpose of the transition planning and support process is to provide overall
planning for service transitions and to coordinate the resources that they require.
Objectives:
Plan and coordinate the resources to ensure that the requirements of service strategy
encoded in service design are effectively realized in service operation.
Coordinate activities across projects, suppliers and service teams where required.
Establish new or changed services into supported environments within the predicted
cost, quality and time estimates.
241
5
MODULE
SERVICE TRANSITION
Establish new or modified management information systems and tools, technology and
management architectures, service management processes, and measurement methods
and metrics to meet requirements established during the service design stage of the
lifecycle.
Ensure that all parties adopt the common framework of standard re-usable processes and
supporting systems in order to improve the effectiveness and efficiency of the integrated
planning and coordination activities.
Provide clear and comprehensive plans that enable customer and business change
projects to align their activities with the service transition plans.
Identify, manage and control risks, to minimize the chance of failure and disruption
across transition activities; and ensure that service transition issues, risks and deviations
are reported to the appropriate stakeholders and decision makers.
Monitor and improve the performance of the service transition lifecycle stage.
242
5
MODULE
SERVICE TRANSITION

Scope
Maintaining policies, standards and models for service transition
activities and processes.
Guiding each major change or new service through all the service
transition processes.
Coordinating the efforts needed to enable multiple transitions to
be managed at the same time.
Prioritizing conflicting requirements for service transition
resources.

Scope: The scope of transition planning and support includes:
Maintaining policies, standards and models for service transition activities and processes.
Guiding each major change or new service through all the service transition processes.
Coordinating the efforts needed to enable multiple transitions to be managed at the
same time.
Prioritizing conflicting requirements for service transition resources.
243
5
MODULE
SERVICE TRANSITION
Planning the budget and resources needed to fulfil future requirements for service
transition.
Reviewing and improving the performance of transition planning and support activities.
Ensuring that service transition is coordinated with programme and project management,
service design and service development activities.
Transition planning and support is not responsible for detailed planning of the build, test
and deployment of individual changes or releases; these activities are carried out as part of
change management and release and deployment management.
244
5
MODULE
SERVICE TRANSITION
Change Management Process

Purpose
The purpose of the change management process is to control the
lifecycle of all changes, enabling beneficial changes to be made with
minimum disruption to IT services.
Objective
Respond to the customers changing business requirements
Respond to the business and IT requests for change that will align
the services with the business needs.
Ensure that changes are recorded and evaluated and that authorized
changes are planned, tested, implemented, documented and
reviewed in a controlled manner.

Purpose: The purpose of the change management process is to control the lifecycle of all
changes, enabling beneficial changes to be made with minimum disruption to IT services.
Objectives:
Respond to the customers changing business requirements while maximizing value and
reducing incidents, disruption and re-work.
Respond to the business and IT requests for change that will align the services with the
business needs.
245
5
MODULE
SERVICE TRANSITION
Ensure that changes are recorded and evaluated, and that authorized changes are
prioritized, planned, tested, implemented, documented and reviewed in a controlled
manner.
Ensure that all changes to configuration items are recorded in the configuration
management system.
Optimize overall business risk it is often correct to minimize business risk, but sometimes
it is appropriate to knowingly accept a risk because of the potential benefit.
246
5
MODULE
SERVICE TRANSITION

Scope
The scope should include changes to all architectures, processes,
tools, metrics and documentation, as well as changes to IT
services and other configuration items.
All changes must be recorded and managed in a controlled way.
It covers all changes to any of the five aspects of service design.

Scope: Change can be defined in many ways. The ITIL definition of a change is the addition,
modification or removal of anything that could have an effect on IT services. The scope should
include changes to all architectures, processes, tools, metrics and documentation, as well as
changes to IT services and other configuration items.
All changes must be recorded and managed in a controlled way. The scope of change
management covers changes to all configuration items across the whole service lifecycle,
whether these CIs are physical assets such as servers or networks, virtual assets such as
virtual servers or virtual storage, or other types of asset such as agreements or contracts. It
also covers all changes to any of the five aspects of service design:
Service solutions for new or changed services, including all of the functional requirements,
resources and capabilities needed and agreed
247
5
MODULE
SERVICE TRANSITION
Management information systems and tools, especially the service portfolio, for the
management and control of services through their lifecycle.
Technology architectures and management architectures required to provide
the services .
Processes needed to design, transition, operate and improve the services.
Measurement systems, methods and metrics for the services, the architectures, their
constituent components and the processes.
248
5
MODULE
SERVICE TRANSITION
Scope of Change Management and Release &

Deployment Management
Business
Service provider
Supplier
Strategic
change
Manage the
business
Manage IT services
Manage the
suppliers
business
Taccal
change
Manage the
business
processes
Service
porolio
Manage
external
services
Service
operaons
External
operaons
Service
change
Operaonal
change
Manage
business
operaons
Scope of Change Management and Release & Deployment Management

Each organization should define the changes that lie outside the scope of its change
management process. Typically these might include:
Changes with significantly wider impacts than service changes, e.g. departmental
organization, policies and business operations these changes would produce RFCs to
generate consequential service changes.
Changes at an operational level such as repair to printers or other routine service
components.
Figure above shows the typical scope of a change management process for an IT organization
and how it interfaces with the business and suppliers at strategic, tactical and operational
249
5
MODULE
SERVICE TRANSITION
levels. It covers interfaces to internal and external service providers where there are
shared assets and configuration items that need to be under change management. Change
management must interface with business change management and with the suppliers
change management (to the right in the figure). This may be an external supplier within a
formal change management system, or the project change mechanisms within an internal
development project.
The service portfolio provides a clear definition all current, planned and retired services.
Understanding the service portfolio helps all parties involved in the service transition to
understand the potential impact of the new or changed service on current services and other
new or changed services.
Strategic changes are brought in via service strategy and the service portfolio management
process in the form of change proposals. Changes to a service will be brought in via service
design, continual service improvement, service level management and service catalogue
management. Corrective change, resolving errors detected in services, will be initiated from
service operation and may route via support or external suppliers into a formal RFC.
Change management is not responsible for coordinating all of the service management
processes to ensure the smooth implementation of projects. This activity is carried out by
transition planning and support.
250
5
MODULE
SERVICE TRANSITION

Value to Business
Service and infrastructure changes an have a negative impact on the
business through service disruption and delay in identifying business
requirements, but change management enables the service provider
to add value to the business by:
Protecting the business, and other services, while making
required changes.
Implementing changes that meet the customers agreed service
requirements while optimizing Costs.
Contributing to meet governance, legal, contractual and
regulatory requirements by providing auditable evidence of
change management activity.

Value to business: Reliability and business continuity are essential for the success and
survival of any organization. Service and infrastructure changes an have a negative impact on
the business through service disruption and delay in identifying business requirements, but
change management enables the service provider to add value to the business by:
Protecting the business, and other services, while making required changes.
Implementing changes that meet the customers agreed service requirements while
optimizing Costs.
251
5
MODULE
SERVICE TRANSITION
Contributing to meet governance, legal, contractual and regulatory requirements

by providing auditable evidence of change management activity. This includes better
alignment with ISO/IEC 20000, ISO/IEC 38500 and COBIT where these have been adopted.
Reducing failed changes and therefore service disruption, defects and re-work.
Reducing the number of unauthorized changes, leading to reduced service disruption
and reduced time to resolve change-related incidents.
Delivering change promptly to meet business timescales.
Tracking changes through the service lifecycle and to the assets of its customers.
Contributing to better estimates of the quality, time and cost of change.
Assessing the risks associated with the transition of services (introduction or disposal).
Improving productivity of staff by minimizing disruptions caused by high levels of
unplanned or emergency change and hence maximizing service availability.
Reducing the mean time to restore service (MTRS), via quicker and more successful
implementations of corrective changes.
Liaising with the business change process to identify opportunities for business
improvement.
Example of IT service-initiated business change: In the retail industry, bar-coding of goods
coupled with bar-code readers at the checkout was initially introduced to deliver savings
by removing the need to label every item, automating stock control, speeding customer
throughput and reducing checkout staff.
Suggestions from IT to the business resulted in making use of this facility to power innovative
concepts such as buy one get one free and capturing data on each individuals purchasing
habits. The reliance on IT services and underlying information technology is now so complex
that considerable time can be spent on:
Assessing the impact of business change on IT.
Analysing the impact of a service or IT change on the business.
252
5
MODULE
SERVICE TRANSITION
Notifying affected parties (of what is proposed, planned and implemented).

Recording and maintaining accurate change, configuration, and release and deployment
records.
Managing and resolving incidents caused by change.
Identifying the problems that continually arise which require more change.
Introducing new ideas and technology that cause even more change.
There are therefore considerable cost savings and efficiencies to be gained from wellstructured and planned changes and releases. As there is so much focus today on enterprise
risk management, change management is a key process that comes under the scrutiny of
auditors.
253
5
MODULE
SERVICE TRANSITION

Change Management Policies
Increasing the success rate of changes and releases requires executive support
for implementing a culture that sets stakeholder expectations about changes
and releases and reduces unplanned work.
Policies that support change management include:
Creating a culture of change management across the organization where
there is zero tolerance for unauthorized change.
Aligning the change management process with business, project and
stakeholder change management processes.
Ensuring that changes create business value and that the benefits
for the business created by each change are measured and reported
Prioritization of change.
e.g. innovation versus preventive versus detective versus corrective change.

Policies: Increasing the success rate of changes and releases requires executive support for
implementing a culture that sets stakeholder expectations about changes and releases and
reduces unplanned work. Pressure will be applied to reduce timescales and meet deadlines;
to cut budgets and operating costs; and to compromise testing. This must not be done without
due diligence to governance and risk. The service transition management team will be called
on from time to time to make a no go decision and not implement a required change. There
must be policies and standards defined which make it clear to the internal and external
providers what must be done and what the consequences of non-adherence to policy will be.
254
5
MODULE
SERVICE TRANSITION
Policies that support change management include:

Creating a culture of change management across the organization where there is zero
tolerance for unauthorized change.
Aligning the change management process with business, project and stakeholder change
management processes.
Ensuring that changes create business value and that the benefits for the business created
by each change are measured and reported Prioritization of change, e.g. innovation
versus preventive versus detective versus corrective change.
Establishing accountability and responsibilities for changes through the service lifecycle.
Segregation of duty controls.
Establishing a single focal point for changes in order to minimize the likelihood of
conflicting changes and potential disruption to supported environments.
Preventing people who are not authorized to make a change from having access to
supported environments.
Integration with other service management processes to establish traceability of change,
detect unauthorized change and identify change-related incidents.
Change windows enforcement and authorization for exceptions.
Performance and risk evaluation of all changes that impact service capability.
Performance measures for the process, e.g. efficiency and effectiveness.
255
5
MODULE
SERVICE TRANSITION
Change Management - Generic Concepts and

Definitions
Definition of Service Change
The addition, modification or removal of anything that could have
an effect on IT services. The scope should include changes to all
architectures, processes, tools, metrics and documentation, as well
as changes to IT services and other configuration items.
256
5
MODULE
SERVICE TRANSITION
Change Management - Generic Concepts and Definitions

There are three different types of service change:
Standard Change:
A pre-authorized change that is low risk, relatively common and follows a procedure
or work instruction.
Emergency Change:
A change that must be implemented as soon as possible, for example to resolve a
major incident or implement a security patch.
Normal Change:
Any service change that is not a standard change or an emergency change.
Changes are often categorized as Major, Significant or minor, depending on the level of
cost and risk involved, and on the scope and relationship to other changes.

Change request: A change request is a formal communication seeking an alteration to
one or more configuration items. This could take several forms, e.g. a request for change
document, service desk call or project initiation document. Different types of change may
require different types of change request. For example, a major change may require a
change proposal, which is usually created by the service portfolio management process. 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.
There are three different types of service change:
Standard change A pre-authorized change that is low risk, relatively common and follows
a procedure or work instruction.
257
5
MODULE
SERVICE TRANSITION
Emergency change A change that must be implemented as soon as possible,

for example to resolve a major incident or implement a security patch.
Normal change Any service change that is not a standard change or an
emergency change.
Changes are often categorized as major, significant or minor, depending on the
level of cost and risk involved, and on the scope and relationship to other changes.
This categorization may be used to identify an appropriate change authority.
258
5
MODULE
SERVICE TRANSITION

Request for Change (RFC):
A request for change a formal proposal for a change to be made. It 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.
Change Record:
A record containing the details of a 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.
Remediation Planning:
Actions taken to recover after a failed change or release. Remediation may include backout, invocation of service continuity plans, or other actions designed to enable the business
process to continue.

RFC: A request for change a formal proposal for a change to be made. It 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.
Change record : 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 may be stored in
the configuration management system or elsewhere in the service knowledge management
system.
Remediation planning: Actions taken to recover after a failed change or release. Remediation
may include back-out, invocation of service continuity plans, or other actions designed to
enable the business process to continue.
259
5
MODULE
SERVICE TRANSITION
No change should be authorized without having explicitly addressed the question of what
to do if it is not successful. Ideally, there will be a back out plan, which will restore the
organization to its initial state, often through the reloading of a baselined set of CIs, especially
software and data. However, not all changes are reversible, in which case an alternative
approach to remediation is required. This remediation may require a revisiting of the change
itself in the event of failure, or may be so severe that it requires invoking the organizations
business continuity plan. Only by considering what remediation options are available before
instigating a change, and by establishing that the remediation is viable (e.g. it is successful
when tested), can the risk of the proposed change be determined and appropriate
decisions taken.
Change implementation plans should include milestones and other triggers for implementation
of remediation in order to ensure that there is sufficient time in the agreed change window
for back-out or other remediation when necessary.
260
5
MODULE
SERVICE TRANSITION

Change Proposals
Change Proposals are submitted to change management before chartering new or changed
service in order to ensure that potential conflicts for resources or other issues are identified.
Major changes that involve significant cost, risk or organizational impact will usually be
initiated through the service portfolio management process.
The change proposal should include:

A high-level description of the new, changed or retired service, including business
outcomes to be supported, and utility and warranty to be provided.
A full business case including risks, issues and alternatives, as well as budget and
financial expectations.
An outline schedule for design and implementation of the change.

Change proposals: Major changes that involve significant cost, risk or organizational impact
will usually be initiated through the service portfolio management process. Before the new
or changed service is chartered it is important that the change is reviewed for its potential
impact on other services, on shared resources, and on the change schedule.
Change proposals are submitted to change management before chartering new or changed
services in order to ensure that potential conflicts for resources or other issues are identified.
Authorization of the change proposal does not authorize implementation of the change but
simply allows the service to be chartered so that service design activity can commence. A
change proposal is used to communicate a high-level description of the change. This change
proposal is normally created by the service portfolio management process and is passed to
change management for authorization. In some organizations, change proposals may be
created by a programme management office or by individual projects. The change proposal
should include:
261
5
MODULE
SERVICE TRANSITION
A high-level description of the new, changed or retired service, including business

outcomes to be supported, and utility and warranty to be provided.
A full business case including risks, issues and alternatives, as well as budget and financial
expectations.
An outline schedule for design and implementation of the change.
Change management reviews the change proposal and the current change schedule,
identifies any potential conflicts or issues and responds to the change proposal by either
authorizing it or documenting the issues that need to be resolved. When the change proposal
is authorized, the change schedule is updated to include outline implementation dates for
the proposed change.
After the new or changed service is chartered, RFCs will be used in the normal way to request
authorization for specific changes. These RFCs will be associated with the change proposal
so that change management has a view of the overall strategic intent and can prioritize and
review these RFCs appropriately.
262
5
MODULE
SERVICE TRANSITION

Change Models:
A change model is a way of predefining the steps that should be taken to handle
a particular type of change in an agreed way.
The change model includes:

Steps that should be taken to handle the change, including handling
issues and unexpected events.
The chronological order in which these steps should be taken, with
any dependences or co-processing defined.
Responsibilities who should do what.

Change models and workflows: Organizations will find it helpful to predefine change models
and apply them to appropriate changes when they occur. A change model is a way of
predefining the steps that should be taken to handle a particular type of change in an agreed
way. Support tools can then be used to manage the required process. This will ensure that
such changes are handled in a predefined path and to predefined timescales. Changes that
require specialized handling could be treated in this way, such as:
Emergency changes that may have different authorization and may be documented
retrospectively.
Changes to mainframe software that may require specific sequences of testing and
Implementation .
263
5
MODULE
SERVICE TRANSITION
Implementation of security patches for desktop operating systems that require specific
testing and guaranteed deployment to large numbers of targets, some of which may not
be online
Service requests that may be authorized and implemented with no further involvement
from change management.
The change model includes:
Steps that should be taken to handle the change, including handling issues and
unexpected events.
The chronological order in which these steps should be taken, with any dependences or
co-processing defined.
Responsibilities who should do what (including identification of those change
authorities who will authorize the change and who will decide whether formal change
evaluation is needed).
Timescales and thresholds for completion of the actions.
Escalation procedures who should be contacted and when.
These models are usually input to the change management support tools; the tools then
automate the handling, management, reporting and escalation of the process.
264
5
MODULE
SERVICE TRANSITION

Change Advisory Board
A change advisory board (CAB) is a body that exists to support the authorization of changes
and to assist change management in the assessment, prioritization and scheduling of
changes.
It is important to emphasize that a CAB:

Will be composed of different stakeholders depending on the changes being
considered.
May vary considerably in makeup, even across the range of a single meeting.
Should involve suppliers when that would be useful, for example:
Should reflect both users and customers views.

Change advisory board: A change advisory board (CAB) is a body that exists to support the
authorization of changes and to assist change management in the assessment, prioritization
and scheduling of changes. A CAB is often the change authority for one or more change
categories, but in some organizations the CAB just plays an advisory role. In a large organization
there may be many different CABs with a global CAB that is responsible for the most significant
changes and other CABs supporting different business units, geographies or technologies. It
is important that each CAB has full visibility of all changes that could have an impact on the
services and configuration items within its control. For each CAB meeting, members should
be chosen who are capable of ensuring that all changes within the scope of the CAB are
adequately assessed from both a business and a technical viewpoint.
A CAB may be asked to consider and recommend the adoption or rejection of changes
appropriate for higher-level authorization, and then recommendations will be submitted to
the appropriate change authority. To achieve this, the CAB needs to include people with a
265
5
MODULE
SERVICE TRANSITION
clear understanding across the whole range of stakeholder needs. Some of these may be
permanent members of the CAB; others will be invited to participate when they are needed
because of the particular changes that are being discussed.
The change manager will normally chair the CAB, and potential members include
Customer(s).
User manager(s).
User group representative(s).
Business relationship managers.
Service owners.
Applications developers/maintainers.
Specialists and/or technical consultants.
Services and operations staff, e.g. service desk, test management, IT service continuity
management, information security management, capacity management .
Facilities/office services staff (where changes may affect moves/accommodation and
vice versa).
Contractors or third parties representatives, e.g. in outsourcing situations.
Other parties as applicable to specific circumstances (e.g. police if traffic disruptions are
likely, marketing if public products could be affected).
It is important to emphasize that a CAB:
Will be composed of different stakeholders depending on the changes being considered.
May vary considerably in makeup, even across the range of a single meeting.
266
5
MODULE
SERVICE TRANSITION
Should involve suppliers when that would be useful, for example:

The external service provider if a significant part of the service is outsourced.
The hardware service provider when considering major firmware upgrades.
Should reflect both users and customers views.
Is likely to include the problem manager and service level manager and customer relations
staff for at least part of the time.
When the need for emergency change arises, i.e. there may 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 an emergency change advisory board (ECAB). Change procedures
should specify how the composition of the CAB and ECAB will be determined in each instance,
based on the criteria listed above and any other criteria that may be appropriate to the
business. This is intended to ensure that the composition of the CAB will be flexible in order
to represent business interests properly when major changes are proposed. It will also ensure
that the composition of the ECAB will provide the ability, both from a business perspective
and from technical standpoint, to make appropriate decisions in any conceivable eventuality.
A practical tip worth bearing in mind is that a CAB should have stated and agreed evaluation
criteria. This will assist in the change assessment activities, acting as a template or framework
by which members can assess each change.
267
5
MODULE
SERVICE TRANSITION
Change Management Concepts

Emergency changes:
Emergency changes are sometimes required and should be designed carefully and tested as
much as possible before use, or the impact of the emergency change may be greater than
the original incident. Details of emergency changes may be documented retrospectively.
Change Schedule:
A document that lists all authorized changes and their planned implementation dates, as
well as the estimated dates of longer-term changes.
A change schedule is sometimes called a forward schedule of change, even though it also
contains information about changes that have already been implemented.
Projected Service Outage (PSO):

A document that identifies the effect of planned changes, maintenance activities and test
plans on agreed service levels.
Change Management Concepts

Emergency changes: Emergency changes are sometimes required and should be designed
carefully and tested as much as possible before use, or the impact of the emergency change
may be greater than the original incident. Details of emergency changes may be documented
retrospectively.
The number of emergency changes proposed should be kept to an absolute minimum, because
they are generally more disruptive and prone to failure. All changes likely to be required
should, in general, be foreseen and planned, bearing in mind the availability of resources to
build and test the changes. Nevertheless, occasions will occur when emergency changes are
essential and so procedures should be devised to deal with them quickly, without sacrificing
normal management controls.
The emergency change procedure is reserved for changes intended to repair an error in an
IT service that is negatively impacting the business to a high degree. Changes intended to
268
5
MODULE
SERVICE TRANSITION
introduce immediately required business improvements are handled as normal changes,

assessed as having the highest urgency. If a change is needed urgently (because of poor
planning or sudden changes in business requirements) this should be treated as a normal
change but given the highest priorit.
Change Schedule: A document that lists all authorized changes and their planned
implementation dates, as well as the estimated dates of longer-term changes. A change
schedule is sometimes called a forward schedule of change, even though it also contains
information about changes that have already been implemented. The change schedule
contains details of all the changes authorized for implementation and their proposed
implementation dates. It also contains estimated dates of longer-term major changes that
have been authorized as change proposals.
269
Change Management Activities

Role
Create RFC
Change
iniator
Change
proposal
(oponal)
Record RFC
Change
management
Change
management
Acvies assigned to the role change management

may be carried out by a change praconer, a change
authority or the change management process owner ,
depending on organizaonal design
Change
management
Rejected
Change
authority
Rejected
*Acvies to plan, create and deploy releases

are part of the release and deployment
management process
Change
management
Change
authority
Change
management
Requested
Review RFC
Ready for evaluaon
Assess and
evaluate change
Ready for decision
Authorize change
build and test
Work flows
Authorized
Coordinate change
build and test*
Created
Authorize change
deployment
Work flows
Update informaon in CMS
MODULE
SERVICE TRANSITION
Scheduled
Coordinate change
deployment*
Implemented
Review and close
change record
Work flows
Closed
Change Management Activities are:

Create and record the RFC
Review RFC and change proposal:
Filter changes (e.g. incomplete or wrongly routed changes)
Assess and evaluate the change:
Establish the appropriate level of change authority
Establish relevant areas of interest (i.e. who should be involved in the CAB)
270
5
MODULE
SERVICE TRANSITION
Evaluate the business justification, impact, cost, benefits and risk of changes
Submit a Request for evaluation to initiate activity from change evaluation process.
Authorize the change:
Obtain authorization/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, e.g. baselines and evaluation reports
Review the change(s) and change documentation
Ensure the details of lessons learned have been entered into the service knoweldge
management system
Close the change document when all actions are completed.have been authorized as
change proposals.
271
5
MODULE
SERVICE TRANSITION
Change Authorization Model

Communicaons, Communicaons,
decisions
escalaon for RFCs,
and acons
risks, issues
Change
authority
Level of
risk/impact
Level 1
Business
execuve board
High cost/risk
change requires
decision from
execuves
Level 2
IT
management board
or IT steering group
Change impacts
mulple services or
organizaonal
divisions
Level 3
CAB or
ECAB
Change which
only affects local
or service group
Level 4
Change manager
Low -risk change
Level 5
Local authorizaon
Standard change
Change Authorization Model:

Change Authorization: Formal authorization is obtained for each change from a change
authority that may be a role, person or a group of people. The levels of authorization for
a particular type of change should be judged by the type, size, risk and potential business
impact of the change, e.g. changes in a large enterprise that affect several distributed sites
may need to be authorized by a higher-level change authority such as a global CAB or the
board of directors. The culture of the organization dictates, to a large extent, the manner in
which changes are authorized. Hierarchical structures may well impose many levels of change
authorization, while flatter structures could allow a more streamlined approach. A degree of
272
5
MODULE
SERVICE TRANSITION
delegated authority may exist within an authorization level, e.g. delegating authority to a
change manager according to preset parameters relating to:
Anticipated business risk.
Financial implications.
Scope of the change (e.g. internal effects only, within the finance service, specific
outsourced services).
An example of a change authorization hierarchy is shown in above Figure. Each organization
should formally document its own change authorization hierarchy, which may be very
different to the example shown here. All change authorities should be documented in the
CMS. If change assessment at level 2, 3 or 4 detects higher levels of risk, the authorization
request is escalated to the appropriate higher level for the assessed level of risk. The use
of delegated authority from higher levels to local levels must be accompanied by trust in
the judgement, access to the appropriate information and supported by management. The
level at which change is authorized should rest where accountability for accepting risk and
remediation exist. Should disputes arise over change authorization or rejection, there should
be a right of appeal to the higher level. Changes that have been rejected should be formally
reviewed and closed.
273
5
MODULE
SERVICE TRANSITION
Change Management Roles

Change Management Process Manager:
The change management process managers responsibilities
typically include:
Carrying out the generic process manager role for the change
management process
Planning and managing support for change management tools
and processes
Maintaining the change schedule and projected service outage
Change Management Roles

Change Management Roles: This section describes a number of roles that need to be
performed in support of the change management process. These roles are not job titles, and
each organization will have to define appropriate job titles and job descriptions for its needs.
Change Management Process Owner: The change management process owners
Carrying out the generic process owner role for the change management process.
Designing change authority hierarchy and criteria for allocating RFCs to change authorities.
Designing change models and workflows.
274
5
MODULE
SERVICE TRANSITION
Working with other process owners to ensure that there is an integrated approach to
the design and implementation of change management, service asset and configuration
management, release and deployment management, and service validation and testing.
Change Management Process Manager: The change management process managers
Carrying out the generic process manager role for the change management process.
Planning and managing support for change management tools and processes.
Maintaining the change schedule and projected service outage.
Coordinating interfaces between change management and other processes especially
service asset and configuration management and release and deployment management.
275
5
MODULE
SERVICE TRANSITION
Service Assets and Configuration Management Process

Purpose:
The purpose of the SACM process is to ensure that the assets required to deliver
services are properly controlled, and that accurate and reliable information
about those assets is available when and where it is needed.
Objectives:
Ensure that assets under the control of the IT organization are identified,
controlled and properly cared for throughout their lifecycle.
Identify, control, record, report, audit and verify services and other
configuration items (CIs).
Maintain accurate configuration information on the historical, planned
and current state of services and other CIs.

Purpose: The purpose of the SACM process is to ensure that the assets required to deliver
services are properly controlled, and that accurate and reliable information about those
assets is available when and where it is needed. This information includes details of how the
assets have been configured and the relationships between assets.
The objectives of SACM are to:
Ensure that assets under the control of the IT organization are identified, controlled and
properly cared for throughout their lifecycle.
Account for, manage and protect the integrity of CIs through the service lifecycle by
working with change management to ensure that only authorized components are used
and only authorized changes are made.
276
5
MODULE
SERVICE TRANSITION
Ensure the integrity of CIs and configurations required to control the services by
establishing and maintaining an accurate and complete configuration management
system (CMS).
Maintain accurate configuration information on the historical, planned and current state
of services and other CIs.
Support efficient and effective service management processes by providing accurate
configuration information to enable people to make decisions at the right time for
example, to authorize changes and releases.
277
5
MODULE
SERVICE TRANSITION

Scope: The scope of SACM includes management of the complete lifecycle
of every CI. Service asset and configuration management ensures that
CIs are identified, baseline and maintained and that changes to them are
controlled.
It also ensures that releases into controlled environments and operational
use are done on the basis of formal authorization.
The scope includes interfaces to internal and external service providers where there
are assets and configuration items that need to be controlled, e.g. shared assets.
Most organizations have a process that tracks and reports the value and ownership
of fixed assets throughout their lifecycle. This process is usually called fixed asset
management or financial asset management.

Scope: Service assets that need to be managed in order to deliver services are known as
configuration items (CIs). Other service assets may be required to deliver the service, but
if they cannot be individually managed then they are not configuration items. Every CI is a
service asset, but many service assets are not CIs. For example, a server will be both a CI and
an asset; the knowledge used by an experienced service desk person to manage incidents
is an important asset but is not a CI. Also, information that is stored on the server but is
not under the control of change management may be a very valuable asset, but it is not a
configuration item. It is important to note that many virtual assets, such as a virtual servers or
networks, may be CIs and require the same management control as physical assets.
278
5
MODULE
SERVICE TRANSITION
The scope of SACM includes management of the complete lifecycle of every CI. Service asset
and configuration management ensures that CIs are identified, baselined and maintained
and that changes to them are controlled. It also ensures that releases into controlled
environments and operational use are done on the basis of formal authorization. It provides
a configuration model of the services and service assets by recording the relationships
between configuration items. SACM may cover on-IT assets, work products used to develop
the services and CIs required to support the service that would not be classified as assets by
other parts of the business.
279
5
MODULE
SERVICE TRANSITION
Service Asset and Configuration Management - Basic

concepts
Service Asset is any resource or capability that could contribute to the delivery
of a service.
Examples of service assets include a virtual server, a physical server, a software
licence, a piece of information stored in a service management system, or some
knowledge in the head of a senior manager.
Configuration Item (CI) is a service asset that needs to be managed in order to

deliver an IT service. All CIs are service assets, but many service assets are not
configuration items.
Examples of configuration items are a server or a software licence. Every CI
must be under the control of change management.
Service Asset and Configuration Management - Basic concepts

Service Asset is any resource or capability that could contribute to the delivery of a service.
Examples of service assets include a virtual server, a physical server, a software licence, a
piece of information stored in a service management system, or some knowledge in the head
of a senior manager.
Configuration Item (CI) is a service asset that needs to be managed in order to deliver an
IT service. All CIs are service assets, but many service assets are not configuration items.
Examples of configuration items are a server or a software licence. Every CI must be under the
control of change management.
280
5
MODULE
SERVICE TRANSITION

concepts
Configuration Record is a set of attributes and relationships about a CI.

Configuration records are stored in a configuration management database
(CMDB) and managed with a configuration management system (CMS).
Configuration Management Database (CMDB): A database used to store

configuration records throughout their lifecycle. The configuration management
system maintains one or more configuration management databases, and each
database stores attributes of configuration items, and relationships with other
configuration items.

Configuration Record is a set of attributes and relationships about a CI. Configuration
records are stored in a configuration management database (CMDB) and managed with a
configuration management system (CMS). It is important to note that CIs are not stored in a
CMDB; configuration records describe CIs that are stored in the CMDB.
Configuration Management Database (CMDB): A database used to store configuration
records throughout their lifecycle. The configuration management system maintains one
or more configuration management databases, and each database stores attributes of
configuration items, and relationships with other configuration items.
Example of multiple configuration management databases: In the commonly encountered
partially outsourced service provider, some elements of service management will be
outsourced while others will remain in house, and different elements may be outsourced
to different external suppliers. For example, the network and hardware support may be
281
5
MODULE
SERVICE TRANSITION
handled by supplier A, environment and facilities management by supplier B, and multiple

applications suppliers and incident management handled internally. The service desk will
access information to assist them from the CMS, but that system will derive its data input
from discrete repositories each one a CMDB owned and maintained by the three parties,
but working together to supply a single consistent information set. Ideally, the service desk
will have access to a single federated CMDB.
282
5
MODULE
SERVICE TRANSITION

concepts
Configuration Management System (CMS)
To manage large and complex IT services and infrastructures, service asset and
configuration management requires the use of a supporting system known as
the configuration management system (CMS).
Example of relationships between the CMS and SKMS
SKMS
The CMS is
part of the
SKMS
Configuraon
records are
stored in
CMDBs in
the CMS
Some CIs (such as

SLAs or release
plans) are in the
SKMS
CMS
Each configuraon
record points to and
describes a CI
Other CIs (such as

users and servers)
are outside the
SKMS

Configuration Management System: To manage large and complex IT services and
infrastructures, service asset and configuration management requires the use of a supporting
system known as the configuration management system (CMS).
The CMS holds all the information about CIs within the designated scope. Some of these items
will have related specifications or files that contain the contents of the item (e.g. software,
283
5
MODULE
SERVICE TRANSITION
document or photograph), and these should be stored in the SKMS. For example, a service
CI will include the details such as supplier, cost, purchase date and renewal date for licences
and maintenance contracts; related documentation such as SLAs and underpinning contracts
will be in the SKMS.
Figure above shows the relationship between configuration records, stored in the CMS, and
the actual CIs, which may be stored in the SKMS or may be physical assets outside the SKMS.
Changes to every configuration item must be authorized by change management and all
updates must include updates to the relevant configuration records. In some organizations,
authority to modify CIs within the SKMS is assigned to configuration librarians, who are also
responsible for modifying the configuration records in the CMS. In other organizations there
is a separation of duties to ensure that no one person can update both the asset in the SKMS
and the corresponding configuration record in the CMS.
284
5
MODULE
SERVICE TRANSITION

concepts
The Definitive Media Library (DML) is defined as one or more
locations in which the definitive and approved versions of all
software CIs are securely stored.
May also contain associated CIs, such as licenses and documentation.
Is a single logical storage area even if there are multiple locations.
Uses software, which is under the control of Change and Release Management
and recorded in the CMS.
Is the sole provider of software for use in a Release
Physical CIs
Electronic CIs

The Definitive Media Library: The Definitive Media Library (DML) is the secure library in
which the definitive authorized versions of all media CIs are stored and protected. It stores
master copies of versions that have passed quality assurance checks. This library may in reality
consist of one or more software libraries or file-storage areas, separate from development,
test or live file-store areas. It contains the master copies of all controlled software in an
organization. The DML should include definitive copies of purchased software (along with
licence documents or information), as well as software developed on site. Master copies of
controlled documentation for a system are also stored in the DML in electronic form.
285
5
MODULE
SERVICE TRANSITION
Release and Deployment Management Process

Purpose:
The purpose of the release and deployment management process is to plan,
schedule and control the build, test and deployment of releases, and to deliver
new functionality required by the business while protecting the integrity of
existing services.
Objectives:
Define and agree release and deployment management plans with
customers and stakeholders.
Create and test release packages that consist of related configuration
items that are compatible with each other.
Ensure that all release packages can be tracked, installed, tested, verified
and/or uninstalled or backed out if appropriate.

Purpose: The purpose of the release and deployment management process is to plan, schedule
and control the build, test and deployment of releases, and to deliver new functionality
required by the business while protecting the integrity of existing services.
Objectives:
Define and agree release and deployment management plans with customers and
stakeholders.
Create and test release packages that consist of related configuration items that are
compatible with each other.
Ensure that the integrity of a release package and its constituent components is maintained
throughout the transition activities, and that all release packages are stored in a DML and
recorded accurately in the CMS.
286
5
MODULE
SERVICE TRANSITION
Deploy release packages from the DML to the live environment following an agreed plan
and schedule.
Ensure that all release packages can be tracked, installed, tested, verified and/or
uninstalled or backed out if appropriate.
Ensure that organization and stakeholder change is managed during release and
deployment activities.
Ensure that a new or changed service and its enabling systems, technology and
organization are capable of delivering the agreed utility and warranty.
Record and manage deviations, risks and issues related to the new or changed service
and take necessary corrective action.
Ensure that there is knowledge transfer to enable the customers and users to optimize
their use of the service to support their business activities.
Ensure that skills and knowledge are transferred to service operation functions to enable
them to effectively and efficiently deliver, support and maintain the service according to
required warranties and service levels.
287
5
MODULE
SERVICE TRANSITION

Scope:
The processes, systems and functions to package, build, test and deploy a release
into live use, establish the service specified in the service design package, and
formally hand the service over to the service operation functions.
The scope includes all configuration items required to implement a release, for example:
Physical assets such as a server or network .

Virtual assets such as a virtual server or virtual storage.
Applications and software.
Training for users and IT staff.
Services, including all related contracts and agreements.

Scope: The scope of release and deployment management includes the processes, systems
and functions to package, build, test and deploy a release into live use, establish the service
specified in the service design package, and formally hand the service over to the service
operation functions. The scope includes all configuration items required to implement a
release, for example:
Physical assets such as a server or network.
Virtual assets such as a virtual server or virtual storage.
Applications and software.
288
5
MODULE
SERVICE TRANSITION
Training for users and IT staff.

Services, including all related contracts and agreements.
Although release and deployment management is responsible for ensuring that appropriate
testing takes place, the actual testing is carried out as part of the service validation and testing
process. Release and deployment management is not responsible for authoring changes,
and requires authorization from change management at various stages in the lifecycle of a
release.
289
5
MODULE
SERVICE TRANSITION
Release Units & Release Packages

Release Unit:
A release unit describes the portion of a service or IT infrastructure
that is normally released as a single entity according to the
organizations release policy.
Release Package:
A release package is a set of configuration items that will be built,
tested and deployed together as a single release.
Release unit and release package:

A release unit describes the portion of a service or IT infrastructure that is normally released
as a single entity according to the organizations release policy. The unit may vary, depending
on the type(s) or item(s) of service asset or service component such as software and hardware.
The general aim is to decide the most appropriate release-unit level for each service asset or
component. An organization may, for example, decide that the release unit for business-critical
applications is the complete application in order to ensure that testing is comprehensive.
The same organization may decide that a more appropriate release unit for a website is at
the page level. A release package is a set of configuration items that will be built, tested
and deployed together as a single release. Each release will take the documented release
units into account when designing the contents of the release package. It may sometimes be
necessary to create a release package that contains only part of one or more release units,
but this would only happen in exceptional circumstances.
290
5
MODULE
SERVICE TRANSITION
Example of Release Unit
IT service A
A1
A2
A3
A2.1
A2.2
A3.1
A2.1.1
Example of Release Unit:

Figure above gives a simplified example showing an IT service made up of systems and service
assets, which are in turn made up of service components. The actual components to be
released on a specific occasion may include one or more release units, or exceptionally may
include only part of a release unit. These components are grouped together into a release
package for that specific release.
291
5
MODULE
SERVICE TRANSITION
Example of a release package

A release package may be a single release unit or a structured set of
release units such as the one shown in Figure 4.19.
Release
package A9
V1.0
User
documentaon
Web client
Customer
service A
Applicaon
release unit
Database
Change
Release
Documentaon
Central server
Soware
SSA
SSB
SSAU1
A3.1
SSAU2
SSAU3
SSAU4
Example of a release package:

The following factors should be taken into account when deciding the appropriate level for
release units:
The ease and amount of change necessary to release 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.
292
5
MODULE
SERVICE TRANSITION
The storage available in the build, test, distribution and live environments.
A release package may be a single release unit or a structured set of release units such
as the one shown in Figure 4.19. A release package may contain only part of one or more
release units. This would only happen in exceptional circumstances, for example when
creating an emergency release. The example in Figure 4.19 shows an application with its
user documentation and a release unit for each technology platform. On the right there
is the customer service asset that is supported by two supporting services SSA for the
infrastructure service and SSB for the application service. These release units will contain
information about the service, its utilities and warranties and release documentation. Often
there will be different ways of designing a release package, and consideration should be given
to establishing the most appropriate method for the identifiable circumstances, stakeholders
and possibilities. Where possible, release packages should be designed so that some release
units can be removed if they cause issues in testing.
293
5
MODULE
SERVICE TRANSITION
RDM Release Policy

Release policy:
The release policy should be defined for one or more services and
include:
The roles and responsibilities at each stage in the release and
deployment process.
The expected frequency for each type of release.
The approach for accepting and grouping changes into a release.
The mechanism to automate the build, installation and release
distribution processes to improve re-use, repeatability and efficiency.
RDM Release Policy

The release policy should be defined for one or more services and include:
The unique identification, numbering and naming conventions for different types of
release together with a description.
The roles and responsibilities at each stage in the release and deployment management
process.
The requirement to only use software assets from the definitive media library.
The expected frequency for each type of release.
The approach for accepting and grouping changes into a release, e.g. how enhancements
are prioritized for inclusion.
294
5
MODULE
SERVICE TRANSITION
The mechanism to automate the build, installation and release distribution processes to
improve re-use, repeatability and efficiency.
How the configuration baseline for the release is captured and verified against the actual
release contents, e.g. hardware, software, documentation and knowledge.
Exit and entry criteria and authority for acceptance of the release into each Service
Transition stage and into the controlled test, training, disaster recovery and production
environments.
Criteria and authorization to exit early life support and handover to Service Operations.
A release that consists of many different types of service assets may involve many people,
often from different organizations. The typical responsibilities for handover and acceptance of
a release should be defined and then they can be modified as required for specific transitions.
The main roles and responsibilities at points of handover should be defined to ensure that
everyone understands their role and level of authority and those of others involved in the
release and deployment process. 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 as this helps to set customer and stakeholder expectations about the
planned releases.
A typical example is:
Major releases, normally containing large areas of new functionality, some of which may
eliminate temporary fixes to problems. A major upgrade or release usually supersedes all
preceding minor upgrades, releases and emergency fixes.
Minor releases, normally containing small enhancements and fixes, some of which
may already have been issued as emergency fixes. A minor upgrade or release usually
supersedes all preceding emergency fixes.
Emergency releases, normally containing the corrections to a small number of known
errors or sometimes an enhancement to meet a high priority business requirement.
A release policy may say, for example, that only strict emergency fixes will be issued in
between formally planned releases of enhancements and non-urgent corrections.
295
5
MODULE
SERVICE TRANSITION
Release and Deployment Models

Release and Deployment Model:
Service Design will select the most suitable release and deployment
models that include the approach, mechanisms, processes, procedures
and resources required to build test and deploy the release and with in
budget.
Release and deployment model define:

Release structure.
Exit and entry criteria, including mandatory and optional deliverables.
Controlled environments required to build and test the release for each
release level.
The roles and responsibilities for each configuration item at each release level.
Release and Deployment Models

A service may be deployed into the production environment in a number of ways. Service
Design will select the most suitable release and deployment models that include the approach,
mechanisms, processes, procedures and resources required to build and deploy the release
on time and within budget.
The release methods during the early build and test stages may differ significantly from live
operations so plan ahead to ensure that appropriate release methods are adopted at the
appropriate time.
296
5
MODULE
SERVICE TRANSITION
Release and deployment models define:

Release structure the overall structure for building a release package and the target
environments.
The exit and entry criteria including mandatory and optional deliverables and
documentation for each stage.
Controlled environments required to build and test the release for each release level;
there will be multiple logical and physical environments through the Service Transition
stage mapped to different physical environments available to the transition team.
The roles and responsibilities for each configuration item at each release level.
The release promotion and configuration baseline model.
Template release and deployment schedules.
Supporting systems, tools and procedures for documenting and tracking all release and
deployment activities.
The handover activities and responsibilities for executing the handover and acceptance
for each stage of release and deployment.
297
5
MODULE
SERVICE TRANSITION
Release and Deployment Options
Big Bang: The new or changed

serviced is deployed to all user
areas in one operation, when
consistency of service across
the organization is considered
important.
Phased Approach: The service

is deployed to a part of the
user base initially and then
this operation is repeated for
subsequent parts of the user
base via scheduled roll out
plan.
Release and Deployment Options

Deployment Options: Big bang option the new or changed service is deployed to all user
areas in one operation. This will often be used when introducing an application change and
consistency of service across the organization is considered important.
Phased approach the service is deployed to a part of the user base initially, and then this
operation is repeated for subsequent parts of the user base via a scheduled rollout plan.
This will be the case in many scenarios such as in retail organizations for new services being
introduced into the stores environment in manageable phases.
298
5
MODULE
SERVICE TRANSITION
Phased Approach
Head Office
Release 1
Branch 1
Release 2
Release 1
Rel. 3
R. 3
Release 2
Branch 2
Release 1
Release 2
Branch 3
Release 1
Release 2
Month
A phased roll - out across several geographical locaons
299
5
MODULE
SERVICE TRANSITION
Deployment Options Push and Pull approach

Push Approach:
The service component is deployed from the center and pushed out
to the target locations. In terms of service deployment delivering
updated service components to all users either in big bang or
phased form constitutes push.
Pull Approach
Software releases where the software is made available in a central
location but users are free to pull the software down to their own
location at a time of their choosing or when a user workstation
restarts.
Deployment Options Push and Pull approach

A push approach is used where the service component is deployed from the centre and
pushed out to the target locations. In terms of service deployment, delivering updated service
components to all users either in big-bang or phased form constitutes push, since the new
or changed service is delivered into the users environment at a time not of their choosing.
A pull approach is used for software releases where the software is made available in a central
location but users are free to pull the software down to their own location at a time of their
choosing or when a user workstation restarts. The use of pull updating a release over the
internet has made this concept significantly more pervasive. A good example is virus signature
updates, which are typically pulled down to update PCs and servers when it best suits the
customer; however at times of extreme virus risk this may be overridden by a release that is
pushed to all known users.
300
5
MODULE
SERVICE TRANSITION
Phases of Release and Deployment Management

Change management
Auth
Auth
Authorize
release planning
Authorize
build and test
Release and
deployment
planning
Release
build and
test
Auth
Auth
Auth
Auth
Auth
Authorize
deployment/
transfer/rerement
Authorize
ceck- in to DML
Deployment
Post
Implementaon
review
Review and
close
Deployment
Deployment
Deployment
Auth
Phases of Release and Deployment Management

Four phases of Release and Deployment management:
Release and Deployment Planning: Plans for creating and deploying the release are created.
This phase starts with change management authorization to plan a release and ends with
change management authorization to create the release.
Release build and test: The release package is built, tested, and checked into DML. This phase
starts with change management authorization to build the release and ends with chagne
management authorization for baselined release package to be checked into DML by service
asset and configuration management. This phase only happens once for each release.
301
5
MODULE
SERVICE TRANSITION
Deployment: The release package in the DML is deployed to the live environment. This phase
starts with change management authorization to deploy the release package to one or more
target environments and ends with handover to service operation functions and early life
support. There may be many separate deployment phases for each release, depending on
the planned deployment options.
Review and close: Experience and feedback are captured, performance targets and
achievements are reviewed and lessons are learned.pushed to all known users.
302
5
MODULE
SERVICE TRANSITION
Knowledge Management Process

Purpose
The purpose of the knowledge management process is to share
perspectives, ideas, experience and information; to ensure that these are
available in the right place at the right time to enable informed decisions;
and to improve efficiency by reducing the need to rediscover knowledge.
Objectives
Improve the quality of management decision making by ensuring that
reliable and secure knowledge.
Enable the service provider to be more efficient and improve quality
of service.
Maintain a service knowledge management system (SKMS) that
provides controlled access to knowledge.

Purpose: The purpose of the knowledge management process is to share perspectives,
ideas, experience and information; to ensure that these are available in the right place at the
right time to enable informed decisions; and to improve efficiency by reducing the need to
rediscover knowledge.
Objectives:
Improve the quality of management decision making by ensuring that reliable and secure
knowledge, information and data is available throughout the service lifecycle.
Enable the service provider to be more efficient and improve quality of service, increase
satisfaction and reduce the cost of service by reducing the need to rediscover knowledge.
303
5
MODULE
SERVICE TRANSITION
Ensure that staff have a clear and common understanding of the value that their services
provide to customers and the ways in which benefits are realized from the use of those
services.
Maintain a service knowledge management system (SKMS) that provides controlled
access to knowledge, information and data that is appropriate for each audience.
Gather, analyse, store, share, use and maintain knowledge, information and data
throughout the service provider organization.
304
5
MODULE
SERVICE TRANSITION

Scope
Knowledge management is a whole lifecycle-wide process in that it is
relevant to all lifecycle stages and hence is referenced throughout ITIL
from the perspective of each publication.
Inclusions: Knowledge management includes oversight of the management
of knowledge, the information and data from which that knowledge
derives.
Exclusions: Detailed attention to the capturing, maintenance and use of
configuration data is set out.

Scope: Knowledge management is a whole lifecycle-wide process in that it is relevant to
all lifecycle stages and hence is referenced throughout ITIL from the perspective of each
publication. It is dealt with to some degree within other ITIL publications, but this section
sets out the basic concept, from a service transition focus.
Inclusions: Knowledge management includes oversight of the management of knowledge,
the information and data from which that knowledge derives.
Exclusions: Detailed attention to the capturing, maintenance and use of configuration data is
set out.
305
5
MODULE
SERVICE TRANSITION
Knowledge Management - DIKW Model

Context
Wisdom
Why?
Knowledge
How?
Informaon
Who, what,
When, where?
Data
Understanding
Knowledge Management - DIKW Model

The Data-to-Information-to-Knowledge-to-Wisdom structure: Knowledge Management
is typically displayed within the Data-to-Information-to- Knowledge-to-Wisdom (DIKW)
structure. The use of these terms is set out below.
Data is a set of discrete facts about events. Most organizations capture significant amounts
of data in highly structured databases such as Service Management and Configuration
Management tools/systems and databases. An example of data is the data and time at which
an incident was logged.
Information: Comes from providing context to data. Information is typically stored in semi
structured content such as documents, email and multimedia. An example of information is
the average time to close priority 2 incidents. This information is created by combining data
from the start time, end time and priority of many incidents.
306
5
MODULE
SERVICE TRANSITION
Knowledge is composed of the tacit experiences, ideas, insights, values and judgments of
individuals. People gain knowledge both from their own and from their peers expertise,
as well as from the analysis of information (and data). Through the synthesis of these
elements, new knowledge is created. Knowledge is dynamic and context based. Knowledge
puts information into an ease of use form, which can facilitate decision making. In Service
Transition this knowledge is not solely based on the transition in progress, but is gathered
from experience of previous transitions, awareness of recent and anticipated changes and
other areas that experienced staff will have been unconsciously collecting for some time.
An example of knowledge is that the average time to close priority 2 incidents has increased
by about 10% since a new version of the service was released.
Wisdom makes use of knowledge to create value through correct and well-informed decisions.
Wisdom involves having the application and contextual awareness to provide strong common
sense judgement. An example of wisdom is recognizing that the increase in time to close
priority 2 incidents is due to poor-quality documentation for the new version of the service.
307
5
MODULE
SERVICE TRANSITION
Service Transition Process

Relationship Between CMDB, CMS and SKMS
Service knowledge
management system
Support for decisions

Support for delivery of services
Configura
on management system
Configura
on management
database
Service Transition Process

The service knowledge management system: Specifically within IT service management,
knowledge management will be focused within the service knowledge management
system (SKMS), which is concerned, as its name implies, with knowledge. Underpinning
this knowledge will be a considerable quantity of data, which will also be held in the SKMS.
One very important part of the SKMS is the configuration management system (CMS). The
CMS describes the attributes and relationships of configuration items, many of which are
themselves knowledge, information or data assets stored in the SKMS.
Figure is a very simplified illustration of the relationship of the three levels, with configuration
data being recorded within the CMDB, and feeding through the CMS into the SKMS. The
SKMS supports delivery of the services and informed decision-making. The SKMS will contain
308
5
MODULE
SERVICE TRANSITION
many different types of data, information and knowledge. Examples of items that should be
stored in an SKMS include:
The service portfolio.
The configuration management system (CMS).
The definitive media library (DML).
Service level agreements (SLAs), contracts and operation level agreements (OLAs).
The information security policy.
The supplier and contract management information system (SCMIS), including suppliers
and partners requirements, abilities and expectations.
The experience of staff.
Records of peripheral matters, e.g. weather, user numbers and behavior, organizations
performance figures.
Suppliers and partners requirements, abilities and expectations.
Typical and anticipated user skill levels.
The capacity plan and capacity management information system (CMIS).
The availability plan and availability management information system (AMIS).
Service continuity invocation procedure.
Service reports.
A discussion forum where practitioners can ask questions, answer each others questions,
and search for previous questions and answers.
An indexed and searchable repository of project plans from previous projects.
309
5
MODULE
SERVICE TRANSITION
A known error database provided by a vendor which lists common issues in their product
and how to resolve them.
Skills register, and typical and anticipated user skill levels.
Diagnostic scripts.
A managed set of web-based training courses.
Weather reports, needed to support business and IT decision-making (for example, an
organization may need to know whether rain is likely at the time of an outdoor event).
Customer/user personal information, for example to support a blind user who needs to
have specific support from the service desk.
Many of these knowledge and information assets are configuration items. Changes to CIs
must be under the control of the change management process, and details of their attributes
and relationships will be documented in the CMS.
310
5
MODULE
SERVICE TRANSITION
Summary
Optimizing Service Transition
Change Management
Change Proposal, Change Types, CAB, RFC, Change Record
CI, CMDB, CMS, DML,
Release Unit, Deployment Options, Release Model
DIKW, SKMS
311
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE TRANSITION
312
5
MODULE
SERVICE TRANSITION
Assessment
313
5
MODULE
SERVICE TRANSITION
1.
Which of these should a change model include?

1. The steps that should be taken to handle the change.
2. Responsibilities: who should do what, including escalation?
3. Timescales and thresholds for completion of the actions.
4. Complaints and procedures.
a. 1, 2 and 3 only
b. 1 and 2 only
c. 2 and 4 only
d. All of the above.
2.
What type of baseline captures the structure, contents and details of the infrastructure
and represents a set of items that are related to each other?
a. Configuration Baseline
b. Project Baseline
c. Change Baseline
d. Asset Baseline.
3.
Which of the following CANNOT be produced by a tool?

a. Knowledge
b. Information
c. Wisdom
d. Data
4.
Which stage of change management process deals with what should be done if the
change is unsuccessful?
a. Remediation Planning
b. Categorization
c. Prioritization
d. Review and close
314
5
MODULE
SERVICE TRANSITION
5.
Which process or function is responsible for the Definitive Media Library and Definitive
Spares?
a. Facilities Management
b. Access Management
c. Request Fulfilment
d. Service Asset and Configuration Management.
6.
Which of the following statements about Service Asset and Configuration Management
is/are CORRECT?
1. A configuration item (CI) can exist as part of any number of other CIs at the same
time.
2. Choosing which CIs to record will depend on the level of control an organization
wishes to exert.
a. 1 only
b. 2 only
d. Neither of the above.
7.
Which of the following statements about Standard changes are CORRECT?

1. This approach is pre authorized.
2. The risk is usually low and well understood.
3. Details of the change will be recorded.
4. Some standard changes will be triggered by the request Fulfilment Process.
a. 1 only
b. 2 and 3 only
c. 1,2 and 3 only
315
5
MODULE
SERVICE TRANSITION
8.
Which of the following groups should have access to the change schedule?
1. Service Desk
2. Business Management
3. All IT Staff
4. IT Management
a. 2,3 and 4 only
b. 1, 2 and 4 only
c. 1,3 and 4 only
9.
Which of the following statements about a Definitive Media Library are CORRECT?
1. The DML includes a physical store.
2. The DML holds definitive hardware spares.
3. The DML includes master copies of controlled documentation.
a. All of the above
b. 1 and 2 only
c. 2 and 3 only
d. 1 and 3 only
10. For which of these activities is the change manager responsible?

a. Chairing the CAB
b. Establishing the root cause of a capacity incident.
c. Devising the backout plan for a significant change
d. Ensuring that the release has reached the target CIs.
316
5
MODULE
SERVICE TRANSITION
11. Consider the following statements; which is NOT true?

a. Change Management is responsible for providing a detailed specification of the
effect on CIs of an authorised change.
b. Change Management keeps a record of all changes by logging, tracking and reviewing
them.
c. Change Management receives, records and helps allocate priorities to all RFCs.
d. Change Management will ensure that adequate back-out plans are prepared before
changes are implemented.
12. It is important for the operation of a given application that the version of the software
installed on each of the computers on the network is the same. Which process is
responsible for this?
a. Change Management
b. Service Asset and Configuration Management
c. Network Management
d. Release and Deployment Management
317
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE OPERATION
318
Co
SERVICE OPERATION
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
Tra
n
siti o
319
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
6
MODULE
SERVICE OPERATION
Learning Objectives
After the completion of this module, you will be able to:
Understand and explain the value to the business provided by Service
Operation.
Understand and explain the position of Service Operation and how
it contributes to the Service Lifecycle.
Understand the key concepts and definitions of Service Operation.
Understand and Explain the key principles of Service Operation.
Understand and explain the Service Operation functions of: :
Service Desk.
Technical Management.
Application Management.
IT Operations Management.
Understand and explain the processes of:
Incident Management.
Event Management.
Request Fulfillment.
Problem Management.
Access Management.
320
6
MODULE
SERVICE OPERATION
Service Operation - Principles
When considering Service Operation it is tempting to focus only on

managing day to day activities and technology as ends in themselves.
However service operation exists within a far greater context.
It is through service operation lifecycle stage that the business
activity sees and receives value from its IT investments.
Service Operation - Principles

Purpose: The purpose of Service Operation is to coordinate and carry out the activities
and processes required to deliver and manage services at agreed levels to business users
and customers. Service Operation is also responsible for the 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 the day-today
operation of those processes is not properly conducted, controlled and managed. Nor will
service improvements be possible if day-to-day activities to monitor performance, assess
metrics and gather data are not systematically conducted during Service Operation.
Staff involved in the service operation stage of the service lifecycle should have processes
and support tools in place that allow them to have an overall view of service operation and
delivery (rather than just the separate components, such as hardware, software applications
321
6
MODULE
SERVICE OPERATION
and networks, that make up the end-to-end service from a business perspective). These
processes and tools should also detect any threats or failures to service quality. As services
may be provided, in whole or in part, by one or more partner/supplier organizations, the
service operation view of the end-to-end service should be extended to encompass external
aspects of service provision. When necessary, shared or interfacing processes and tools
should be deployed to manage cross-organizational workflows.
322
6
MODULE
SERVICE OPERATION
Service Operation Process
Event
Management
Incident
Management
Problem
Fanagement
Request
Fulfilment
Access
management
323
6
MODULE
SERVICE OPERATION
Service Operation Functions
Service desk
Technical
management
Mainframe
Server
Network
Storage
IT operaons management
IT operaons control
Console management /
operaons bridge
Job scheduling
Backup and restore
Print and output management
Facilies management
Recovery sites
Contracts
Data centers
Consolidaon
Applicaon
management
Financial
apps
HR
apps
Business
apps
Database
Directory
services
Desktop
Middleware
Internet/web
324
6
MODULE
SERVICE OPERATION
Service Operation Basic Concepts and Definitions
Event:
An event can be defined as any change of state that has significance for the
management of a configuration item (CI) or IT service. Events are typically
recognized through notifications created by an IT service, CI or monitoring tool.
Alert:
A notification 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.
An unplanned interruption to an IT service or reduction in the quality of an IT
Incident: service. Failure of a configuration item that has not yet affected service is also an
incident for example, failure of one disk from a mirror set.

Alert:A notification that a threshold has been reached, something has changed, or a failure
has occurred. Alerts are often created and managed by the systems management tools and
are managed by the event management process.
Event: A change of state that has significance for the management of an IT service or other
configuration item. The terms is also used to mean an alert or notification created by any IT
service, configuration item or monitoring tool.
Incident: An unplanned interruption to an IT service or reduction in the quality of an IT
service. Failure of a configuration item that has not yet affected service is also an incident
for example, failure of one disk from a mirror set.
325
6
MODULE
SERVICE OPERATION

Workaround:
Reducing or eliminating the impact of an incident or problem for which
a full resolution is not yet available.
Service Request:
A formal request from a user for something to be provided .
Priority:
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. EX, the SLA may state
that Priority 2 incidents must be resolved within 12 hours.
Urgency:
A measure of how long it will be until an incident, problem or change
has a significant impact on the business. EX, a high-impact incident may
have low urgency if the impact will not affect the business until the end
of the financial year.
Workaround:Reducing or eliminating the impact of an incident or problem for which a
full resolution is not yet available. 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.
Service Request: A formal request from a user for something to be provided for example,
a request for information or advice; to reset a password; or to install a workstation for a new
user. Service requests are managed by the request fulfilment process, usually in conjunction
326
6
MODULE
SERVICE OPERATION
with the service desk. Service requests may be linked to a request for change as part of
fulfilling the request.
Urgency: A measure of how long it will be until an incident, problem or change has 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.
Priority: 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
action to be taken.
327
6
MODULE
SERVICE OPERATION
Incident Management Process

Purpose:
The purpose of incident management is to restore normal service operation as
quickly as possible and minimize the adverse impact on business operations,
thus ensuring that agreed levels of service quality are maintained.
Objective:
Increase visibility and communication of incidents to
business and IT support staff .
Enhance business perception of IT through use of
a professional approach in quickly resolving and
communicating incidents when they occur.
Align incident management activities and priorities

with those of the business.

Purpose: The purpose of incident management is to restore normal service operation as
quickly as possible and minimize the adverse impact on business operations, thus ensuring
that agreed levels of service quality are maintained. Normal service operation is defined as
an operational state where services and CIs are performing within their agreed service and
operational levels.
328
6
MODULE
SERVICE OPERATION
Objectives: The objectives of the incident management process are to:

Ensure that standardized methods and procedures are used for efficient and prompt
response, analysis, documentation, ongoing management and reporting of incidents.
Increase visibility and communication of incidents to business and IT support staff.
Enhance business perception of IT through use of a professional approach in quickly
resolving and communicating incidents when they occur.
Align incident management activities and priorities with those of the business.
Maintain user satisfaction with the quality of IT services.
329
6
MODULE
SERVICE OPERATION

Scope:
This includes any event which disrupts, or which could disrupt, a service.
Incidents can also be reported and/or logged by technical staff.
Both incidents and service requests are reported to the service desk, this
does not mean that they are the same.

Scope: Incident management includes any event which disrupts, or which could disrupt, a
service. This includes events which are communicated directly by users, either through the
service desk or through an interface from event management to incident management tools.
Incidents can also be reported and/or logged by technical staff (if, for example, they notice
something untoward with a hardware or network component they may report or log an
incident and refer it to the service desk). This does not mean, however, that all events are
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, this does
not mean that they are the same. Service requests do not represent a disruption to agreed
service, but are a way of meeting the customers needs and may be addressing an agreed
target in an SLA. Service requests are dealt with by the request fulfilment process.
330
6
MODULE
SERVICE OPERATION
Incident Management Basic Concepts
Timescales must be agreed for all incident-handling stages (these will differ
Timescales: depending upon the priority level of the incident) based upon the overall
incident response and resolution targets within SLAs and captured as targets
within OLAs and Underpinning Contracts (UCs).
Incident
Models:
Many incidents are not new they involve dealing with something that has
happened before and may well happen again. For this reason, many organizations
will find it helpful to pre-define standard Incident Models and apply them to
appropriate incidents when they occur.
Major
incidents:
A separate procedure, with shorter timescales and greater urgency, must be

used for major incidents. A definition of what constitutes a major incident must
be agreed and ideally mapped on to the overall incident prioritization system
such that they will be dealt with through the major incident process.
Incident Management Basic Concepts

Principles and basic concepts: There are some basic things that need to be taken into account
and decided when considering Incident Management. These are covered in this section.
Timescales: Timescales must be agreed for all incident-handling stages (these will differ
depending upon the priority level of the incident) based upon the overall incident response
and resolution targets within SLAs and captured as targets within OLAs and Underpinning
Contracts (UCs). All support groups should be made fully aware of these timescales. Service
Management tools should be used to automate timescales and escalate the incident as
required based on predefined rules.
331
6
MODULE
SERVICE OPERATION
Incident Models: Many incidents are not new they involve dealing with something that has
happened before and may well happen again. For this reason, many organizations will find it
helpful to pre-define standard Incident Models and apply them to appropriate incidents
when they occur. An Incident Model is a way of pre-defining the steps that should be taken
to handle a process (in this case a process for dealing with a particular type of incident) in an
agreed way. Support tools can then be used to manage the required process. This will ensure
that standard incidents are handled in a predefined path and within pre-defined timescales.
Incidents which would require specialized handling can be treated in this way (for example,
security-related incidents can be routed to Information Security Management and capacityor performance-related incidents that would be routed to Capacity Management. The
Incident Model should include:
The steps that should be taken to handle the incident.
The chronological order these steps should be taken in, with any dependences or coprocessing defined.
Responsibilities: who should do what.
Timescales and thresholds for completion of the actions.
Escalation procedures; who should be contacted and when.
Any necessary evidence-preservation activities (particularly relevant for security- and
capacity-related incidents).
The models should be input to the incident-handling support tools in use and the tools should
then automate the handling, management and escalation of the process.
Major incidents: A separate procedure, with shorter timescales and greater urgency, must
be used for major incidents. A definition of what constitutes a major incident must be
agreed and ideally mapped on to the overall incident prioritization system such that they
will be dealt with through the major incident process. Note: People sometimes use loose
terminology and/or confuse a major incident with a problem. In reality, an incident remains
an incident forever it may 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 remains a separate entity always!
332
6
MODULE
SERVICE OPERATION
Some lower-priority incidents may also have to be handled through this procedure due to
potential business impact and some major incidents may not need to be handled in this
way if the cause and resolutions are obvious and the normal incident process can easily cope
within agreed target resolution times provided the impact remains low! Where necessary,
the major incident procedure should include the dynamic establishment of a separate major
incident team under the direct leadership of the Incident Manager, formulated to concentrate
on this incident alone to ensure that adequate resources and focus are provided to finding
a swift resolution. If the Service Desk Manager is also fulfilling the role of Incident Manager
(say in a small organization), then a separate person may need to be designated to lead the
major incident investigation team so as to avoid conflict of time or priorities but should
ultimately report back to the Incident Manager.
If the cause of the incident needs to be investigated at the same time, then the Problem
Manager would be involved as well but the Incident Manager must ensure that service
restoration and underlying cause are kept separate. Throughout, the Service Desk would
ensure that all activities are recorded and users are kept fully informed of progress. While
the service desk may be accountable for ensuring that the incident/major incident record
is always up-to-date, responsibility may also lie elsewhere (such as with the other technical
teams).
Incident status tracking: Incidents should be tracked throughout their lifecycle to support
proper handling and reporting on the status of incidents. Within the incident management
system, status codes may be linked to incidents to indicate where they are in relation to the
lifecycle. Examples of these might include:
Open An incident has been recognized but not yet assigned to a support resource for
resolution
In progress The incident is in the process of being investigated and resolved
Resolved A resolution has been put in place for the incident but normal state service
operation has not yet be
Closed The user or business has greed that the incident has been resolved and that
normal state operations have been restored.
333
6
MODULE
SERVICE OPERATION
Expanded incident lifecycle:

ITIL Service Design and ITIL Continual Service Improvement describe the expanded incident
lifecycle which can be used to help understand all contributions to the impact of incidents and
to plan for how these could be controlled or reduced.
334
6
MODULE
SERVICE OPERATION

Event
management
Web interface
Phone Call
Email
Is this really
an incident?
Yes
No
Incident logging
Incident
iden fica on
To request fulfilment
(if this is a service
request) or service
porolio management
(if this is a change
proposal)
Incident
categoriza on
Incident
priori za on
Major incident
procedure
Yes
Major incident
No
Ini al diagnosis
Func onal
escala on
Yes
Func onal
escala on
Yes
No
Escala on
Needed?
No
No
Management
escala on
Yes
Hierarchic
escala on
No
Inves ga on
And diagnosis
Resolu on
iden fied?
Yes
Resolu on and
recovery
Incident closure
End
Incident Management Process Activities:

Incident identification: While work cannot begin on dealing with an incident until it is known
that an incident has occurred, it is usually unacceptable, from a business perspective, to wait
until a user is impacted and contacts the service desk. As far as possible, all key components
should be monitored so that failures or potential failures are detected early. This means that
the incident management process can be started quickly. Ideally, incidents should be resolved
before they have an impact on users!
Incident logging: All incidents must be fully logged and date/time stamped, regardless of
whether they are raised through a service desk telephone call, automatically detected via
an event alert, or from any other source. All relevant information relating to the nature of
the incident must be logged so that a full historical record is maintained and so that if the
335
6
MODULE
SERVICE OPERATION
incident has to be referred to other support group(s), the will have all relevant information to
hand to assist them. The information needed for each incident can include:
Unique reference number If service desk and/or support staff visit the customers to deal
with one incident, they may be asked to deal with further incidents while they. It is
important that if this is done, a separate incident record is logged for each additional
incident handled, to ensure that a historical record is kept and credit is given for the work
undertaken.
Incident categorization (often broken down into between two and four sub-categories).
Incident urgency.
Incident impact.
Incident prioritization.
Date/time recorded.
Name/ID of the person and/or group recording the incident.
Method of notification (telephone, automatic, email, in person etc.).
Name/department/phone/location of user.
Call-back method (telephone, mail etc.).
Description of symptoms.
Incident status (active, waiting, closed etc.).
Related CI.
Support group/person to which the incident is allocated.
Related problem/known error.
Activities undertaken to resolve the incident and when these took place.
Resolution date and time.
336
6
MODULE
SERVICE OPERATION
Closure category.
Closure date and time.
Note that if the service desk does not work 24/7 and responsibility for first-line incident
logging and handling passes to another group, such as IT operations or network support, out
of service desk hours, then these staff need to be equally rigorous about logging of incident
details. Full training and awareness needs to be provided to such staff on this issue.
As further activities to resolve an incident occur, the incident record should be updated with
relevant information and details so that a full history is maintained. Examples of this might
include changing the categorization or priority once further diagnosis or escalation activities
have occurred.
Incident categorization: Part of the initial logging must be to allocate suitable incident
categorization coding so that the exact type of incident is recorded. This will be important
later when looking at incident types/ frequencies to establish trends for use in problem
management, supplier management and other ITSM activities.
Note that the check for service requests in this process does not imply that service requests
are incidents. This is simply recognition of the fact that service requests are sometimes
incorrectly logged as incidents (e.g. a user incorrectly enters the request as an incident from
the web interface). This check will detect any such requests and ensure that they are passed
to the request fulfilment process.
Incident categorization may change throughout the lifecycle of an incident. For example,
upon discovery and logging of the incident, initial categories may reflect symptoms (e.g.
service unavailable or performance slow). Upon later analysis, categories may reflect the
actual CIs at fault such as server or disk drive. For this reason, multi-level categorization can
be used to identify multiple levels of categories that can be associated with an incident. The
capability to track chosen categories as they change throughout the lifecycle of an incident
may also prove useful when looking for potential improvements. Multi-level categorization is
available in most tools usually to three or four levels of granularity.
All organizations are unique and it is therefore difficult to give generic guidance on the
categories an organization should use, particularly at the lower levels. However, there is a
337
6
MODULE
SERVICE OPERATION
technique that can be used to assist an organization achieve a correct and complete set of
categories if they are starting from scratch! The steps involve:
i.
Hold a brainstorming session among the relevant support groups, involving the service
desk supervisor and incident and problem managers.
ii. Use this session to decide the best guess top level categories, ideally with the
customer in mind, so that service (or worst case, application) heads the list and
include an other category. Set up the relevant logging tools to use these categories for
a trial period.
iii. Use the categories for a short trial period (long enough for several hundred incidents to
fall into each category, but not too long that an analysis will take too long to perform).
iv. Perform an analysis of the incidents logged during the trial period. The number of
incidents logged in each higher-level category will confirm whether the categories
are worth having and a more detailed analysis of the other category should allow
identification of any additional higher-level categories that will be needed.
v. A breakdown analysis of the incidents within each higher-level category should be used
to decide the lower-level categories that will be required.
vi. Review and repeat these activities after a further period of, say, one to three months
and again review regularly to ensure that they remain relevant. Be aware that any
significant changes to categorization may cause some difficulties for incident trending
or management reporting, so they should be stabilized unless changes are genuinely
required.
If an existing categorization scheme is in use, but is not thought to be working satisfactorily,
the basic idea of the technique suggested above can be used to review and amend the
existing scheme.
Initial diagnosis: If the incident has been routed via the service desk, the service desk analyst
must carry out initial diagnosis, typically while the user is still on the telephone if the call
is raised in this way to try to discover the full symptoms of the incident and 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 allowing earlier and accurate diagnosis.
338
6
MODULE
SERVICE OPERATION
If possible, the service desk analyst can resolve an incident while the user is still on the
telephone and close the incident if the resolution and recovery are agreed to be successful.
If the service desk analyst cannot resolve the incident while the user is still on the telephone,
but there is a prospect that the service desk may be able to do so within the agreed time
limit without help from other support groups, the analyst should inform the user of their
intentions, give the user the incident reference number and attempt to find a resolution.
Investigation and diagnosis: A reported incident is 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 and all such activities (including details
of any actions taken to try to resolve or recreate the incident) should be fully documented
in the incident record so that a complete historical record of all activities is maintained at
all times. Note that valuable time can often be lost if investigation and diagnostic action (or
indeed resolution or recovery actions) are performed serially. Where possible, such activities
should be performed in parallel to reduce overall timescales and support tools should
be designed and/ or selected to allow this. However, care should be taken to coordinate
activities, particularly resolution or recovery activities, otherwise the actions of different
groups may conflict or further complicate a resolution! This investigation is likely to include
such actions as:
Establishing exactly what has gone wrong or is being sought by the user.
Understanding the chronological order of events.
Confirming the full impact of the incident, including the number and range of users
affected.
Identifying any events that could have triggered the incident (e.g. a recent change, some
user action?).
Detailed knowledge searches looking for previous occurrences by searching incident/
problem records and/or known error databases (KEDBs) or manufacturers/suppliers
error logs or knowledge databases. These matches may not have been obvious during
initial diagnosis.
339
6
MODULE
SERVICE OPERATION
Resolution and recovery: When a potential resolution has been identified, this should be
applied and tested. The specific actions to be undertaken and the people who will be involved
in taking the recovery actions may vary, depending upon the nature of the fault, but could
involve:
Asking the user to undertake directed activities on their own desktop or remote
equipment .
The service desk implementing the resolution either centrally (say, rebooting a server) or
remotely using software to take control of the users desktop to diagnose and implement
a resolution.
Specialist support groups being asked to implement specific recovery actions (e.g.
network support reconfiguring a router).
A third-party supplier or maintainer being asked to resolve the fault.
Even when a resolution has been found, sufficient testing must be performed to ensure that
recovery action is complete and that normal state service operation has been restored. Note
that in some cases it may be necessary for two or more groups to take separate, though
perhaps coordinated, recovery actions for an overall resolution to be implemented. In such
cases incident management must coordinate the activities and liaise with all parties involved.
Regardless of the actions taken, or who does them, the incident record must be updated
accordingly with all relevant information and details so that a full history is maintained. The
resolving group should pass the incident back to the service desk for closure action.
Incident closure: The service desk should check that the incident is fully resolved and that
the users are satisfied and willing to agree the incident can be closed. The service desk should
also check the following:
Closure categorization: Check and confirm that the initial incident categorization was
correct or, where the categorization subsequently turned out to be incorrect, update
the record so that a correct closure categorization is recorded for the incident seeking
advice or guidance from the resolving group(s) as necessary.
User satisfaction survey: Carry out a user satisfaction call-back or email survey for the
agreed percentage of incidents.
340
6
MODULE
SERVICE OPERATION
Incident documentation: Chase any outstanding details and ensure that the incident
record is fully documented so that a full historic record at a sufficient level of detail is
complete.
Ongoing or recurring problem?: Determine (in conjunction with resolver groups) whether
the incident was resolved without the root cause being identified. In this situation, it is
likely that the incident could recur and require further preventive action to avoid this.
In all such cases, determine if a problem record related to the incident has already been
raised. If not, raise a new problem record in conjunction with the problem management
process so that preventive action is initiated.
Formal closure: Formally close the incident record.
Note that some organizations may choose to utilize an automatic closure period on specific,
or even all, incidents (e.g. incident will be automatically closed after two working days if no
further contact is made by the user). Where this approach is to be considered, it must first be
fully discussed and agreed with the users and widely publicized so hat all users and IT staff
are aware of this. It may be inappropriate to use this method for certain types of incidents,
such as major incidents or those involving VIPs etc.
341
Escalation
IT Service
Manager
Service Desk
Manager
Service Desk
Support Team
Hierarchical (authority)
MODULE
SERVICE OPERATION
2nd Line
Manager
2 nd Line
Support Team
3rd Line
Manager
3rd Line
Support Team
Funconal (competence)
Escalation:
Functional escalation: As soon as it becomes clear that the service desk is unable to resolve
the incident itself (or when target times for first-point resolution have been exceeded
whichever comes first), the incident must be immediately escalated for further support. If
the organization has a hierarchy of support groups with more time or specialist skills that the
service desk believes can resolve the incident, it should refer the incident to the appropriate
next level support group in that hierarchy. If it is obvious that the incident will require deeper
technical knowledge or a support group has not been able to resolve the incident within
agreed target times (whichever comes first), the incident must be immediately escalated to
the next appropriate support group in the hierarchy. The rules for escalation and handling
of incidents must be agreed in OLAs and UCs with internal and external support groups,
respectively.
342
6
MODULE
SERVICE OPERATION
Some incidents may require multiple support groups to resolve. Support groups may
be internal, but they may also be third parties such as software suppliers or hardware
manufacturers or maintainers. The rules for handling of incidents across support groups
and between third-party support providers must also be agreed in OLAs and UCs with each
support group, respectively. Note that incident ownership remains with the service desk!
Regardless of where an incident is referred to during its life, ownership of the incident must
remain with the service desk at all times. The service desk remains responsible for tracking
progress, keeping users informed and ultimately for incident closure.
Hierarchic escalation: If incidents are of a serious nature (for example, high-priority incidents)
the appropriate IT managers must be notified, for informational purposes at least. Hierarchic
escalation is also used if the investigation and diagnosis and resolution and recovery steps
are taking too long or proving too difficult. Hierarchic escalation should continue up the
management chain so that senior managers are aware and can be prepared and take any
necessary action, such as allocating additional resources or involving suppliers/maintainers.
Hierarchic escalation is also used when there is contention about who the incident is allocated
to. Hierarchic escalation can, of course, be initiated by the affected users or customer
management, as they see fit that is why it is important that IT managers are made aware so
that they can anticipate and prepare for any such escalation. The exact levels and timescales
for both functional and hierarchic escalation need to be agreed, taking into account SLA
targets, and embedded within support tools which can then be used to police and control
the process flow within agreed timescales. The service desk should keep the user informed of
any relevant escalation that takes place and ensure the incident record is updated accordingly
to keep a full history of actions.
Incident prioritization: Another important aspect of logging every incident is to agree and
allocate an appropriate prioritization code, as this will determine how the incident is handled
both by support tools and support staff. Prioritization can normally be determined by taking
into account both the urgency of the incident (how quickly the business needs a resolution)
and the level of business impact it is causing. An indication of impact is often (but not always)
the number of users being affected. In some cases, and very importantly, the loss of service
to a single user can have a major business impact it all depends upon who is trying to do
what so numbers alone are not enough to evaluate overall priority! Other factors that can
also contribute to impact levels are:
The number of services affected may be multiple services.
The level of financial losses.
343
6
MODULE
SERVICE OPERATION
Effect on business reputation.

Regulatory or legislative breaches.
An effective way of calculating these elements and deriving an overall priority level for each
incident is given in Table 4.1. In all cases, clear guidance with practical examples should
be provided for all support staff to enable them to determine the correct urgency and impact
levels, so the correct priority is allocated. Such guidance should be produced during service
level negotiations.
However, it must be noted that there will be occasions when, because of particular business
expediency, normal priority levels have to be overridden. When a user is adamant that an
incidents priority level should exceed normal guidelines, the service desk should comply with
such a request and if it subsequently turns out to be incorrect this can be resolved as an offline management level issue, rather than a dispute occurring with the user while the incident
is being reported. Some organizations may also recognize VIPs (high ranking executives,
officers, diplomats, politicians etc.) whose incidents would be handled on a higher priority
than normal but in such cases this is best catered for and documented within the guidance
provided to the service desk staff on how to apply the priority levels, so they are all aware
of the agreed rules for VIPs, and who falls into this category. A better practice would be to
formally recognize VIP priorities as an additional service option (the gold level of service, for
example) that is documented as part of the service catalogue tied to differentiated service
levels. It should be noted that an incidents priority may be dynamic if circumstances change,
or if an incident is not resolved within SLA target times, then the priority must be altered to
reflect the new situation. Changes to priority that might occur throughout the management
of an incident should be recorded in the incident record to provide an audit trail of why
the priority was changed. Note that some tools may have constraints that make it difficult
automatically to calculate performance against SLA targets if a priority is changed during the
lifetime of an incident. However, if circumstances do change, the change in priority should be
made and if necessary manual adjustments made to reporting tools. Ideally, tools with such
constraints should not be selected.
344
6
MODULE
SERVICE OPERATION
Incident Management Metrics

Each organization should develop KPIs that are appropriate for its level of
maturity, its CSFs and its particular circumstances. Achievement against KPIs
should be monitored and used to identify opportunities for improvement, which
should be logged in the CSI register for evaluation and possible implementation.
CSF Resolve incidents as quickly as possible minimizing impacts to the business.
KPI Mean elapsed time to achieve incident resolution or circumvention,
broken down by impact code.
CSF Maintain quality of IT services
KPI Total numbers of incidents (as a control measure).
Incident Management Metrics

Critical Success Factors and Key Performance Indicators: The following list includes some
sample CSFs for incident management. Each organization should identify appropriate CSFs
based on its objectives for the process. Each sample CSF is followed by a small number of typical
KPIs that support the CSF. These KPIs should not be adopted without careful consideration.
Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs
and its particular circumstances. Achievement against KPIs should be monitored and used
to identify opportunities for improvement, which should be logged in the CSI register for
evaluation and possible implementation.
CSF Resolve incidents as quickly as possible minimizing impacts to the business:
KPI Mean elapsed time to achieve incident resolution or circumvention, broken down by
impact code.
KPI Breakdown of incidents at each stage (e.g. logged, work in progress, closed etc.).
345
6
MODULE
SERVICE OPERATION
KPI Percentage of incidents closed by the service desk without reference to other levels
of support (often referred to as first point of contact).
KPI Number and percentage of incidents resolved remotely, without the need for a visit.
KPI Number of incidents resolved without impact to the business (e.g. incident was raised
by event management and resolved before it could impact the business).
CSF Maintain quality of IT services:
KPI Total numbers of incidents (as a control measure).
KPI Size of current incident backlog for each IT service.
KPI Number and percentage of major incidents for each IT service.
CSF Maintain user satisfaction with IT services.
KPI Average user/customer survey score (total and by question category).
KPI Percentage of satisfaction surveys answered versus total number of satisfaction
surveys sent.
CSF Increase visibility and communication of incidents to business and IT support staff:
KPI Average number of service desk calls or other contacts from business users for
incidents already reported.
KPI Number of business user complaints or issues about the content and quality of
incident communications.
CSF Align incident management activities and priorities with those of the business:
KPI Percentage of incidents handled within agreed response time (incident response
time targets may be specified in SLAs, for example, by impact and urgency codes).
KPI Average cost per incident.
346
6
MODULE
SERVICE OPERATION
CSF Ensure that standardized methods and procedures are used for efficient and prompt
response, analysis, documentation, ongoing management and reporting of incidents to
maintain business confidence in IT capabilities.
KPI Number and percentage of incidents incorrectly assigned
KPI Number and percentage of incidents incorrectly categorized
KPI Number and percentage of incidents processed per service desk agent
KPI Number and percentage of incidents related to changes and releases.
It is also helpful to break down and categorize incident metrics by category, timeframe,
impact, urgency, service impacted, location and priority and compare these with previous
periods. This can provide input to problem management, CSI and other processes seeking
to identify issues, problem trends or other situations. Reports should be produced under
the authority of the incident manager, who should draw up schedule and distribution list, 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 via SLA reports.
347
6
MODULE
SERVICE OPERATION
Incident Management -Roles

Incident Manager
The incident management process managers responsibilities typically
include.
Planning and managing support for incident management tools and
processes.
Coordinating interfaces between incident management and other service
management processes.
Driving the efficiency and effectiveness of the incident management process.
Producing management information.
Managing the work of incident support staff (first- and second-line).
Monitoring the effectiveness of incident management and making
recommendations for improvement.

The Incident management process managers responsibilities typically include:
Carrying out the generic process manager role for the incident management process.
Planning and managing support for incident management tools and processes.
Coordinating interfaces between incident management and other service management
processes.
Driving the efficiency and effectiveness of the incident management process.
348
6
MODULE
SERVICE OPERATION
Producing management information.

Managing the work of incident support staff (first- 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.
In many organizations the role of incident manager is assigned to the service desk supervisor,
although in larger organizations with high volumes a separate role may be necessary. In either
case it is important that the incident manager is given the authority to manage incidents
effectively through first, second and third line analysts.
.
349
6
MODULE
SERVICE OPERATION

First Line Analyst
This role is that of providing first-line support for incidents when they occur using
the incident management process.
Recording incidents.
Routeing incidents to support specialist groups when needed.
Analysing for correct prioritization, classification and providing initial support.
Providing ownership, monitoring, tracking and communication of incidents.
Providing resolution and recovery of incidents not assigned to support
specialist groups.
Second Line Analyst

Many organizations choose to have a second-line support group, made up of
staff with greater (though still general) technical skills than the service desk
and with additional time to devote to incident diagnosis and resolution without
interference from telephone interruptions.
Key responsibilities would be similar to the first-line analyst role.
A second line support manager (or supervisor if just a small group) will normally
head this group.

First-line analyst: This role is that of providing first-line support for incidents when they occur
using the incident management process. It is common to find this role combined with the
service desk analyst role include:
Recording incidents.
Routeing incidents to support specialist groups when needed.
350
6
MODULE
SERVICE OPERATION
Analysing for correct prioritization, classification and providing initial support.

Providing ownership, monitoring, tracking and communication of incidents.
Providing resolution and recovery of incidents not assigned to support specialist groups.
Closing incidents.
Monitoring the status and progress towards resolution of assigned incidents.
Keeping users and the service desk informed about incident progress.
Escalating incidents as necessary per established escalation policies.
Second-line analyst: Many organizations choose to have a second-line support group, made
up of staff with greater (though still general) technical skills than the service desk and
with additional time to devote to incident diagnosis and resolution without interference from
telephone interruptions. Key responsibilities would be similar to the first-line analyst role.
Such a group can handle many of the less complicated incidents, leaving more specialist
(third-line) support groups to concentrate on dealing with more deep-rooted incidents and/
or new developments etc. Where a second-line group is used, there are often advantages
to locating this group close to the service desk, to enable good communications and to ease
movement of staff between the groups, which may be helpful for training/awareness and
during busy periods or staff shortages. A second line support manager (or supervisor if just a
small group) will normally head this group.
351
6
MODULE
SERVICE OPERATION
Problem Management
Purpose
Purpose: The purpose of problem management is to manage the
lifecycle of all problems from first identification through further
investigation, documentation and eventual removal.

To minimize the adverse impact of incidents and problems
on the business that are caused by underlying errors within the IT
Infrastructure.
Objectives
Prevent problems and resulting incidents from happening.
Eliminate recurring incidents.
Minimize the impact of incidents that cannot be prevented..
Problem Management
Purpose: The purpose of problem management is to manage the lifecycle of all problems
from first identification through further investigation, documentation and eventual removal.
Problem management seeks to minimize the adverse impact of incidents and problems on the
business that are caused by underlying errors within the IT Infrastructure, and to proactively
prevent recurrence of incidents related to these errors. In order to achieve this, problem
management seeks to get to the root cause of incidents, document and communicate known
errors and initiate actions to improve or correct the situation.
352
6
MODULE
SERVICE OPERATION
Objectives: The objectives of the problem management process are to:

Prevent problems and resulting incidents from happening.
Eliminate recurring incidents.
Minimize the impact of incidents that cannot be prevented.
353
6
MODULE
SERVICE OPERATION
Problem Management
Responsible for ensuring
that the resolution is
implemented through
the appropriate change
procedures.
Includes activities to
diagnose the root cause of
problems.
SCOPE
Works hand in hand with
Incident Management
Maintain information about

problems
Problem Management
Scope: 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 and Deployment Management.
Problem Management will also maintain information about problems and the appropriate
workarounds and resolutions, so that the organization is able to reduce the number and
impact of incidents over time. In this respect, Problem Management has a strong interface
with Knowledge Management, and tools such as the Known Error Database will be used for
both. Although Incident and Problem Management are separate processes, they are closely
related and will typically use the same tools, and may use similar categorization, impact and
priority coding systems. This will ensure effective communication when dealing with related
incidents and problems.
354
6
MODULE
SERVICE OPERATION
Problem Management
Scope
Problem Management consists of two major processes:
Reactive Problem Management.
Is commonly executed as part of Service Operation.
Proactive Problem Management.
Is initiated in Service Operation, typically driven as part of Continual Service
Improvement.
Problem Management
Reactive problem management is concerned with solving problems in response to one or
more incidents.
Proactive problem management is concerned with identifying and solving problems and
known errors before further incidents related to them can occur again.
While reactive problem management activities are performed in reaction to specific
incident situations, proactive problem management activities take place as ongoing
activities targeted to improve the overall availability and end user satisfaction with IT
services. Examples of proactive problem management activities might include conducting
periodic scheduled reviews of incident records to find patterns and trends in reported
symptoms that may indicate the presence of underlying errors in the infrastructure.
355
6
MODULE
SERVICE OPERATION
Conducting major incident reviews where review of How can we prevent the recurrence?
can provide identification of an underlying cause or error.
Conducting periodic scheduled reviews of operational logs and maintenance records
identifying patterns and trends of activities that may indicate an underlying problem
might exist.
Conducting periodic scheduled reviews of event logs targeting patterns and trends of
warning and exception events that may indicate the presence of an underlying problem.
Conducting brainstorming sessions to identify trends that could indicate the existence of
underlying problems.
Using check sheets to proactively collect data on service or operational quality issues
that may help to detect underlying problems.
Reactive and proactive problem management activities are generally conducted within the
scope of service operation. A close relationship exists between proactive problem management
activities and CSI lifecycle activities that directly support identifying and implementing service
improvements. Proactive problem management supports those activities through trending
analysis and the targeting of preventive action. Identified problems from these activities will
become input to the CSI register used to record and manage improvement opportunities.
356
6
MODULE
SERVICE OPERATION
Problem Management Principles and Basic Concepts

Reactive and Proactive Problem Management Activities:
Both reactive and proactive problem management activities seek to raise
problems, manage them through the problem management process. The
difference between reactive and proactive problem management lies in how
the problem management process is triggered:
With reactive problem management, process activities will typically be

triggered in reaction to an incident that has taken place.
With proactive problem management, process activities are triggered by

activities seeking to improve services.
Problem Management Principles and Basic Concepts

Principles and basic concepts: There are some important concepts of problem management
that must be taken into account from the outset.
These include:
Reactive and proactive problem management activities: Both reactive and proactive
problem management activities seek to raise problems, manage them through the problem
management process, find the underlying causes of the incidents they are associated with
and prevent future recurrences of those incidents. The difference between reactive and
proactive problem management lies in how the problem management process is triggered:
357
6
MODULE
SERVICE OPERATION
With reactive problem management, process activities will typically be triggered in reaction
to an incident that has taken place. Reactive problem management complements incident
management activities by focusing on the underlying cause of an incident to prevent its
recurrence and identifying workarounds when necessary.
With proactive problem management, process activities are triggered by activities seeking to
improve services. One example might be trend analysis activities to find common underlying
causes of historical incidents that took place to prevent their recurrence. Proactive problem
management complements CSI activities by helping to identify workarounds and improvement
actions that can improve the quality of a service.
By redirecting the efforts of an organization from reacting to large numbers of incidents to
preventing incidents, an organization provides a better service to its customers and makes
more effective use of the available resources within the IT support organization.
Problem models: Many problems will be unique and will require handling in an individual
way but it is conceivable that some incidents may recur because of dormant or underlying
problems (for example, where the cost of a permanent resolution will be high and a decision
has been taken not to go ahead with an expensive solution but to live with the problem). As
well as creating a known error record in the KEDB to ensure quicker diagnosis, the creation
of a problem model for handling such problems in the future may be helpful. This is very
similar in concept to the idea of incident or request models described in previous chapters,
but applied to problems.
358
6
MODULE
SERVICE OPERATION
Problem Management - Basic Concepts

Problem: 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.
Known Error: A problem with a documented root cause and
workaround. The known error record should identify the problem
record it relates to and document the status of actions being taken to
resolve the problem, its root cause and workaround. All known error
records should be stored in the KEDB.
Known Error Database: A database containing all known error
records. This database is created by Problem Management and used
by Incident and Problem Management.
Problem Management - Basic Concepts

Problem: 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.
Known error: A problem with 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.
Workarounds: In some cases it may be possible to find a workaround to the incidents caused
by the problem a temporary way of overcoming the difficulties. For example, a manual
amendment may be made to an input file to allow a program to complete its run successfully
359
6
MODULE
SERVICE OPERATION
and allow a billing process to complete satisfactorily, but it is important that work on a
permanent resolution continues where this is justified in this example the reason for the file
becoming corrupted in the first place must be found and corrected to prevent this happening
again.
When a workaround is found, it is therefore important that the problem record remains open
and details of the workaround are documented within the problem record. In some cases
there may be multiple workarounds associated with a problem. As problem investigation and
diagnosis activities carry on, there may be a series of improvements that do not resolve the
problem, but lead to a progressive improvement in the quality of the workarounds available.
These may impact on the prioritization of the problem as successive workaround solutions
may reduce the impact of future related incidents, either by reducing their likelihood or
improving the speed of their resolution.
Raising a known error record: A known error is defined as a problem with a documented
root cause and workaround. The known error record should identify the problem record it
relates to and document the status of actions being taken to resolve the problem, its root
cause and workaround. All known error records should be stored in the KEDB.
As soon as the diagnosis is complete, and particularly where a workaround has been found
a known error record must be raised and placed in the KEDB so that if further incidents or
problems arise, they can be identified and the service restored more quickly. In some cases
it may be advantageous to raise a known error record even earlier in the overall process,
even though the diagnosis may not be complete or a workaround found. This might be used
for information purposes or to identify a root cause or workaround that appears to address
the problem but hasnt been fully confirmed. Therefore, it is inadvisable to set a concrete
procedural point for exactly when a known error record must be raised. It should be done as
soon as it becomes useful to do so!
Known Error Database: The purpose of a KEDB is to allow storage of previous knowledge
of incidents and problems and how they were overcome to allow quicker diagnosis and
resolution if they recur. The known error record should hold exact details of the fault and
the symptoms that occurred, together with precise details of any workaround or resolution
action that can be taken to restore the service and/or resolve the problem. An incident count
will also be useful to determine the frequency with which incidents are likely to recur and
influence priorities etc.
360
6
MODULE
SERVICE OPERATION
It should be noted that a business case for a permanent resolution for some problems may
not exist. For example, if a problem does not cause serious disruption and a workaround
exists and/or the cost of resolving the problem far outweighs the benefits of a permanent
resolution, then a decision may be taken to tolerate the problem. However, it will still be
desirable to diagnose and implement a workaround as quickly as possible, which is where
the KEDB can help.
It is essential that any data put into the database can be quickly and accurately retrieved. The
problem manager should be fully trained and familiar with the search methods/algorithms
used by the selected database and should carefully ensure that when new records are added,
the relevant search key criteria are correctly included.
Care should be taken to avoid duplication of records (i.e. the same problem described in two
or more ways as separate records). To avoid this, the problem manager should be the only
person able to enter a new record. Other support groups should be encouraged to propose
new records, but these should be vetted by the problem manager before entry to the KEDB. In
large organizations where a single KEDB is used (recommended) with problem management
staff in multiple locations, a procedure must be agreed to ensure that duplication of KEDB
records cannot occur. This may involve designating just one staff member as the central KEDB
manager.
The KEDB should be used during the incident and problem diagnosis phases to try to speed
up the resolution process and 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
conversant with the value that the KEDB can offer and the way it should be used. They should
be able readily to retrieve and use data.
361
6
MODULE
SERVICE OPERATION
Problem Management - Process Activities

Problem Detection
The multiple ways of detecting problems will exist in all
organizations. These can include triggers for reactive and
proactive problem Management.
Problem Logging
Irrespective 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 should be categorized in the same way as incidents
so that the true nature of the problem can be easily traced in
the future and meaningful management information can be
obtained. This also allows for incidents and problems to be more
readily matched.
Problem Prioritization
Problems should be prioritized the same way using the same
reasons as incidents. 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 the speed and nature of this investigation
will vary depending upon the impact, severity and urgency of
the problem.
362
6
MODULE
SERVICE OPERATION
Process activities, methods and techniques

Problem detection: It is likely that multiple ways of detecting problems will exist in all
organizations. These can include triggers for reactive and proactive problem management:
Reactive problem management triggers:
Suspicion or detection of a cause of one or more incidents by the service desk, resulting
in a problem record being raised the desk may have resolved the incident but has not
determined a definitive cause and suspects that it is likely to recur, so will raise a problem
record to allow the underlying cause to be resolved. Alternatively, it may be immediately
obvious from the outset that an incident, or incidents, has been caused by a major
problem, so a problem record will be raised without delay.
Analysis of an incident by a technical support group which reveals that an underlying
problem exists, or is likely to exist.
Automated detection of an infrastructure or application fault, using event/alert tools
automatically to raise an incident which may reveal the need for a problem record.
A notification from a supplier or contractor that a problem exists that has to be resolved.
Proactive problem management triggers:
Analysis of incidents that result in the need to raise a problem record so that the underlying
fault can be investigated further.
Trending of historical incident records to identify one or more underlying causes that if
removed, can prevent their recurrence. In this case, a problem record is raised once the
underlying trend or cause is discovered.
Activities taken to improve the quality of a service that result in the need to raise a
problem record to identify further improvement actions that should be taken.
Frequent and regular analysis of incident and problem data must be performed to identify any
trends as they become discernible. This will require meaningful and detailed categorization of
incidents/problems and regular reporting of patterns and areas of high occurrence. Top ten
reporting, with drill-down capabilities to lower levels, is useful in identifying trends.
363
6
MODULE
SERVICE OPERATION
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. A cross-reference must be made to the incident(s)
which initiated the problem record and all relevant details must be copied from the incident
record(s) to the problem record. It is difficult to be exact, as cases may vary, but typically this
will include details such as:
User details.
Service details.
Equipment details.
Date/time initially logged.
Priority and categorization details.
Incident description.
Incident record numbers or other cross reference.
Details of all diagnostic or attempted recovery actions taken.
Problem categorization: Problems should be categorized in the same way as incidents (and
it is advisable to use the same coding system) so that the true nature of the problem can be
easily traced in the future and meaningful management information can be obtained. This
also allows for incidents and problems to be more readily matched.
Problem prioritization: Problems should be prioritized the same way using the same reasons
as incidents. The frequency and impact of related incidents must also be taken into account.
The coding system (which combines incident impact with urgency to give an overall priority
level) can also be used to prioritize problems. Definition and guidance should be provided to
support staff on what constitutes a problem, and the related service targets for each priority
code level in the table. Problem prioritization should also take into account the severity of
the problems.
364
6
MODULE
SERVICE OPERATION
Problem investigation and diagnosis: At this stage, an investigation should be conducted to

try to diagnose the root cause of the problem the speed and nature of this investigation will
vary depending upon the impact, severity and urgency of the problem but the appropriate
level of resources and expertise should be applied to finding a resolution commensurate with
the priority code allocated and the service target in place for that priority level. There are a
number of useful problem-solving techniques that can be used to help diagnose and resolve
problems, and these should be used as appropriate.
The CMS must be used to help determine the level of impact and pinpoint and diagnose the
exact point of failure. The KEDB should also be accessed and problem-matching techniques
(such as keyword searches) should be used to see if the problem has occurred before and, if
so, to find the resolution. It is often valuable to try to recreate the failure to understand what
has gone wrong, and then try various ways of finding the most appropriate and cost-effective
resolution to the problem. It may be possible to recreate the problem in a test environment
that mirrors the live environment. This allows for investigation and diagnosis activities to
proceed effectively without causing further disruption to users.
365
6
MODULE
SERVICE OPERATION

Workarounds
In some cases it may be possible to find a workaround to
the incidents caused by the problem a temporary way of
overcoming the difficulties.
Raising A Known Error Record
A known error is defined as a problem with a documented root
cause and workaround.
Problem Resolution
Once a root cause has been found and a solution to remove it
has been developed, it should be applied to resolve the problem.
Problem Closure
When a final resolution has been applied, the problem record
should be formally closed as should any related incident
records that are still open.
Major Problem Review
After every major problem (as determined by the organizations
priority system), and while memories are still fresh, a review
should be conducted to learn any lessons for the future.

Workarounds: In some cases it may be possible to find a workaround to the incidents
caused by the problem a temporary way of overcoming the difficulties. For example, a
manual amendment may be made to an input file to allow a program to complete its run
successfully and allow a billing process to complete satisfactorily, but it is important that work
366
6
MODULE
SERVICE OPERATION
on a permanent resolution continues where this is justified in this example the reason for
the file becoming corrupted in the first place must be found and corrected to prevent this
happening again.
When a workaround is found, it is therefore important that the problem record remains open
and details of the workaround are documented within the problem record. In some cases
there may be multiple workarounds associated with a problem. As problem investigation and
diagnosis activities carry on, there may be a series of improvements that do not resolve the
problem, but lead to a progressive improvement in the quality of the workarounds available.
These may impact on the prioritization of the problem as successive workaround solutions
may reduce the impact of future related incidents, either by reducing their likelihood or
improving the speed of their resolution.
Raising a known error record: A known error is defined as a problem with a documented
root cause and workaround. The known error record should identify the problem record it
relates to and document the status of actions being taken to resolve the problem, its root
cause and workaround. All known error records should be stored in the KEDB. As soon as the
diagnosis is complete, and particularly where a workaround has been found (even though it
may not yet be a permanent resolution), a known error record must be raised and placed in
the KEDB so that if further incidents or problems arise, they can be identified and the service
restored more quickly. In some cases it may be advantageous to raise a known error record
even earlier in the overall process, even though the diagnosis may not be complete or a
workaround found. This might be used for information purposes or to identify a root cause or
workaround that appears to address the problem but hasnt been fully confirmed. Therefore,
it is inadvisable to set a concrete procedural point for exactly when a known error record
must be raised. It should be done as soon as it becomes useful to do so!
Problem resolution: Once a root cause has been found and a solution to remove it has been
developed, it should e applied to resolve the problem. In reality, safeguards may be needed
to ensure that the resolution does not cause further difficulties. If any change in functionality
is required, an RFC should be raised and authorized before the resolution can be applied.
If the problem is very serious and an urgent fix is needed for business reasons, then an
emergency RFC should be raised. The resolution should be applied only when the change has
been authorized and scheduled for release. In the meantime, the KEDB should be used to
help resolve quickly any further occurrences of the incidents/ problems that occur.
367
6
MODULE
SERVICE OPERATION
There may be some problems for which a business case for resolution cannot be justified (e.g.
where the impact is limited but the cost of resolution would be extremely high). In such cases
a decision ay be taken to leave the problem record open but to use a workaround description
in the known error record to detect and resolve any recurrences quickly. Care should be taken
to use the appropriate code to flag the open problem record so that it does not count against
the performance of the team performing the process and so that unauthorized rework does
not take place. In some cases, workarounds may be in place to mitigate the impacts of the
problem without a final resolution being found. In this event, the problem should be reprioritized based on the impact of the workarounds applied and investigative and diagnostic
activities should be continued.
Problem closure: When a final resolution has been applied, the problem record should be
formally closed as should any related incident records that are still open. A check should
be performed at this time to ensure that the record contains a full historical description of
all events and if not, the record should be updated. The status of any related known error
record should be updated to show that the resolution has been applied.
Major problem review: After every major problem (as determined by the organizations
priority system), and while memories are still fresh, a review should be conducted to learn
any lessons for the future. Specifically, the review should examine:
Those things that were done correctly.
Those things that were done wrong.
What could be done better in the future.
How to prevent recurrence.
Whether there has been any third-party responsibility and whether follow-up actions are
needed.
Such reviews can be used as part of training and awareness activities for support staff and
any lessons learned should be documented in appropriate procedures, work instructions,
diagnostic scripts or known error records. The problem manager facilitates the session and
documents any agreed actions.
368
6
MODULE
SERVICE OPERATION
Major problem reviews can also be a source of input to proactive problem management
through identification of underlying causes that may be discovered in the course of the
review.
The knowledge gained from the review should be incorporated into a service review meeting
with the business customer to ensure the customer is aware of the actions taken and the
plans to prevent future major incidents from occurring. This helps to improve customer
satisfaction and assure the business that service operation is handling major incidents
responsibly and actively working to prevent their future recurrence.
369
6
MODULE
SERVICE OPERATION
Problem Manager - Roles

Problem Management Process Manager:
The problem management process managers responsibilities typically
include
Carrying out the generic process managers role.
Planning and managing support for problem management tools and
processes.
Coordinating interfaces between problem management and other
processes.
Problem Manager - Roles

Problem Management Process Manager: The problem management process managers
Planning and managing support for problem management tools and processes.
Coordinating interfaces between problem management and other processes.
Ownership and maintenance of KEBD.
Gatekeeper for the inclusion of all known errors and management of search algorithms.
370
6
MODULE
SERVICE OPERATION
Formal closure of all problem records.

Liaising with all problem resolution groups to ensure swift resolution of problems within
SLA targets.
Problem analyst: The actual solving of problems is likely to be undertaken by one or more
technical support groups and/or suppliers or support contractors. These may include support
resources who may work in many different areas, but will come together to undertake
problem resolution activities under the coordination of the problem manager. The problem
analysts responsibilities typically include:
Reviewing incident data to analyse assigned problems.
Analysing problems for correct prioritization and classification.
Investigating assigned problems through to resolution or root cause.
Coordinating actions of others as necessary to assist with analysis and resolution actions
for problems and known errors.
Raising RFCs to resolve problems.
Monitoring progress on the resolution of known errors and advising incident management
staff on the best available workaround for incidents
Updating the KEDB with new or updated known errors and workarounds
Assisting with the handling of major incidents and identifying their root causes.
Where an individual problem is serious enough to warrant it, a dedicated problem
management team should be formulated to work together in overcoming that particular
problem. The problem resolver has a role to play in making sure that the correct number
and level of resources is available in the team and for escalation and communication up the
management chain of all organizations concerned.
371
6
MODULE
SERVICE OPERATION
Event Management
Purpose:
Purpose: The purpose of event management is to manage events throughout
their lifecycle. This lifecycle of activities to detect events, make sense of them
and determine the appropriate control action is coordinated by the event
management process.
Objectives:
Detect all changes of state that have significance for the management of a
CI or IT service.
Determine the appropriate control action for events and ensure these
are communicated to the appropriate functions.
Provide the trigger, or entry point, for the execution of many service
operation processes and operations management activities.
Event Management
Purpose: The purpose of event management is to manage events throughout their lifecycle.
This lifecycle of activities to detect events, make sense of them and determine the appropriate
control action is coordinated by the event management process.
Objectives: The objectives of the event management process are to:
Detect all changes of state that have significance for the management of a CI or IT service.
Determine the appropriate control action for events and ensure these are communicated
to the appropriate functions.
372
6
MODULE
SERVICE OPERATION
Provide the trigger, or entry point, for the execution of many service operation processes
and operations management activities.
Provide the means to compare actual operating performance and behaviour against
design standards and SLAs
Provide a basis for service assurance and reporting; and service improvement.
373
6
MODULE
SERVICE OPERATION
Event Management
Scope
Configuration Items .
Environmental Conditions .
Normal activity (e.g. tracking the use of an application or the
performance of a server).
Event Management
Scope: Event management can be applied to any aspect of service management that needs
to be controlled and which can be automated. This includes:
Configuration items (CIs):
Some CIs will be included because they need to stay in a constant state (e.g. a switch
on a network needs to stay on and event management tools confirm this by monitoring
responses to pings).
Some CIs will be included because their status needs to change frequently and event
management can be used to automate this and update the configuration management
system (CMS) (e.g. the updating of a file server).
374
6
MODULE
SERVICE OPERATION
Environmental conditions (e.g. fire and smoke detection).

Software licence monitoring for usage to ensure optimum/legal licence utilization and
allocation.
Security (e.g. intrusion detection).
Normal activity (e.g. tracking the use of an application or the performance of a server).
375
6
MODULE
SERVICE OPERATION
Event Management
Types of Events
Informational: Successful Completion of an Activity.
Ex : User Logging In, Email Reaching Recipient.
Exceptional: Does not always represent an Incident or Problem.
Ex: User attempts to login With incorrect password.
Warning: When service or device is Approaching threshold
Sometimes not raised for Device failure if device is redundant.
Informational Events:
A scheduled workload has completed.
A user has logged into an application.
An email has reached its intended recipient.
Warning Events:
A servers memory utilization reaches within 5% of its highest acceptable performance
level.
The completion time of a transaction is 10% longer than normal.
Warning events signify unusual, but not exceptional operation. These are an indication
that the situation may require closer monitoring.
376
6
MODULE
SERVICE OPERATION
Exception Events:
A user attempts to log on to an application with the incorrect password.
An unusual situation as occurred in a business process that may indicate an exception
requiring further business investigation.
A devices CPU is above the acceptable utilization rate.
377
6
MODULE
SERVICE OPERATION
Request Fulfillment
Purpose:
Purpose: Request fulfilment is the process responsible for managing the lifecycle
of all service requests from the users.
Objectives:
Maintain user and customer satisfaction through efficient and professional
handling of all service requests.
Provide a channel for users to request and receive standard services.
Source and deliver the components of requested standard services .
Event Management
Purpose: Request fulfilment is the process responsible for managing the lifecycle of all service
requests from the users.
Objectives: The objectives of the request fulfilment process are to:
Maintain user and customer satisfaction through efficient and professional handling of all
service requests.
Provide a channel for users to request and receive standard services for which a
pre-defined approval and qualification process exists.
Provide information to users and customers about the availability of services and the
procedure for obtaining them
Source and deliver the components of requested standard services (e.g. Licenses and
software media)
Assist with general information, complaints or comments.
378
6
MODULE
SERVICE OPERATION
Request Fulfillment
Scope
The process needed to fulfill a request will vary depending upon exactly what is
being requested but can usually be broken down into a set of activities that have
to be performed.
Some organizations will be comfortable letting the service requests be handled
through their incident management process (and tools) with service requests
being handled as a particular type of incident.
Request Fulfillment
Scope: The process needed to fulfill a request will vary depending upon exactly what is being
requested but can usually be broken down into a set of activities that have to be performed.
For each request, these activities should be documented into a request model and stored in
the SKMS.
Some organizations will be comfortable to let the Service Requests be handled through
their Incident Management processes (and tools) with Service Requests being handled
as a particular type of incident (using a high-level categorization system to identify those
incidents that are in fact Service Requests). Note, however, that there is a significant
difference here an incident is usually an unplanned event, whereas a service request is
usually something that can and should be planned!
Therefore, in an organization where large numbers of Service Requests have to be handled,
and where the actions to be taken to fulfill those requests are very varied or specialized, it
379
6
MODULE
SERVICE OPERATION
may be appropriate to handle Service Requests as a completely separate work stream and
to record and manage them as a separate record type.
This may be particularly appropriate if the organization has chosen to widen the scope of the
Service Desk to expand upon just IT-related issues and use the desk as a focal point for other
types or request for service for example, a request to service a photocopier or even going so
far as to include, for example, building management issues, such as a need to replace a light
fitment or repair a leak in the plumbing.. Note: It will ultimately be up to each organization to
decide and document which request it will handle through the Request Fulfillment process
and which others will have to go through more formal Change Management. There will
always be grey areas which prevent generic guidance from being usefully prescribed.
The value of Request Fulfillment is to provide quick and effective access to standard services
which business staff can use 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, thus 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.
380
6
MODULE
SERVICE OPERATION
Request Fulfilment Request Models

Request Models
Some service requests will occur frequently and will require handling
consistently in order to meet agreed service levels. To assist this, many
organizations will wish to create predefined request models .
This is similar in concept to the idea of incident models already described

in incident management, but applied to service requests.
Request Fulfilment Request Models

Request models: Some service requests will occur frequently and will require handling
consistently in order to meet agreed service levels. To assist this, many organizations will wish
to create predefined request models (which typically include one or more standard changes
in order to complete fulfilment activities). This is similar in concept to the idea of incident
models already described in incident management, but applied to service requests.
381
6
MODULE
SERVICE OPERATION
Request Fulfilment - Roles

The Request Fulfilment process managers responsibilities typically
include:
Planning and managing support for request fulfilment tools and
processes.
Coordinating interfaces between request fulfilment and other
processes.
Handing staff, customer and management concerns, requests,
issues and enquiries.
Request Fulfilment - Roles

Request Fulfilment Process Owner: The request fulfilment process owners responsibilities
typically include:
Carrying out the generic process owner role for the request fulfilment process.
Designing request fulfilment models and workflows.
and implementation of request fulfilment, incident management, event management,
access management and problem management.
382
6
MODULE
SERVICE OPERATION
Request Fulfilment Process Manager:

Planning and managing support for request fulfilment tools and processes.
Coordinating interfaces between request fulfilment and other processes.
Handing staff, customer and management concerns, requests, issues and enquiries.
Ensure request fulfilment activities operate in line with service level targets.
Reviewing and analyzing all request fulfilment reports to proactively seek improvements.
Request Fulfilment Analyst: This role coordinates fulfilment of service requests to maintain
high levels of satisfaction with IT services. It oversees, manages and coordinates all activities
to respond to a service request and serves as a single point of contact until it has been
fulfilled. The request fulfilment analysts responsibilities typically include:
Providing a single point of contact and end-to-end responsibility to ensure submitted
service requests have been processed.
Providing initial triage of service requests to determine which IT resources should be
engaged to fulfil them.
Communicating service requests to other IT resources that will be involved in fulfilling
them.
Escalating service requests in line with established service level targets.
Ensuring service requests are appropriately logged.
Initial handling of service requests is commonly undertaken by the service desk and incident
management staff.
383
6
MODULE
SERVICE OPERATION
Eventual fulfilment of the service request will be undertaken by the appropriate service
operation team(s) or departments and/or by external suppliers, as appropriate. Often,
facilities management, procurement and other business areas aid in the fulfilment of the
service request.
In most cases there will be no need for additional roles or posts to be created. In exceptional
cases where a very high number of service requests are handled, or where the requests are
of critical importance to the organization, it may be appropriate to have one or more of the
incident management team dedicated to handling and managing service requests.
384
6
MODULE
SERVICE OPERATION
Access Management
Purpose
To provide the right for users to be able to use a service or group of services. It
is therefore the execution of policies and actions defined in information security
management.
Objectives
Manage access to services based on policies and actions defined in
information security management.
Efficiently respond to requests for granting access to services, changing
access rights or restricting access, ensuring that the rights being provided.
Oversee access to services and ensure rights being provided are not
improperly used.
Access Management
Purpose: The purpose of access management is to provide the right for users to be able to
use a service or group of services. It is therefore the execution of policies and actions defined
in information security management.
Objectives: The objectives of the access management process are to:
Manage access to services based on policies and actions defined in information security
management (see ITIL Service Design).
Efficiently respond to requests for granting access to services, changing access rights
or restricting access, ensuring that the rights being provided or changed are properly
granted.
Oversee access to services and ensure rights being provided are not improperly used.
385
6
MODULE
SERVICE OPERATION
Access Management - Scope

Access management ensures that users are given the right to use a
service, but it does not ensure that this access is available at all times
this is provide by availability management.
Access management is a process that is executed by all technical
and application management functions and is usually not a separate
function.
Access Management can be initiated by service request.
Access Management - Scope

Scope: Access management ensures that users are given the right to use a service, but it does
not ensure that this access is available at all times this is provide by availability management.
Access management is a process that is executed by all technical and application management
functions and is usually not a separate function.
Access Management can be initiated by service request.
386
6
MODULE
SERVICE OPERATION
Access Management - Basic Concept

Access management is the process that enables users to use the services that are
documented in the service catalogue. It comprises the following basic concepts:
Access
Identity
Rights
Service
Groups
Directory
Services
Access Management - Basic Concept

Access management is the process that enables users to use the services that are documented
in the service catalogue. It comprises the following basic concepts:
Access: Access refers to the level and extent of a services functionality or data that a user
is entitled to use.
Identity: Identity refers to the information about them that distinguishes them as an
individual and which verifies their status within the organization. By definition, the
identity of a user is unique to that user.
Rights: Rights (also called privileges) refer to 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.
387
6
MODULE
SERVICE OPERATION
Services or service groups: Services or service groups. Most users do not use only one
service, and users performing a similar set of activities will use a similar set of services.
Instead of providing access to each service for each user separately, it is more efficient to
be able to grant each user or group of users access to the whole set of services that
they are entitled to use at the same time.
Directory services: Directory services refer to specific types of tools that are used to
manage access and rights.
388
6
MODULE
SERVICE OPERATION
Access Management Roles - Process Manager

The access management process managers responsibilities typically
include:
Carrying out the generic process manager role for the access
management process.
Planning and managing support for access management tools and
processes.
Coordinating interfaces between access management and other
service management processes.
Access Management Roles - Process Manager

Access Management Process Manager: The access management process managers
Carrying out the generic process manager role for the access management process.
Planning and managing support for access management tools and processes.
Coordinating interfaces between access management and other service management
processes.
The Role of Technical and Application Management Staff: Technical and application
management play several important roles as follows:
During service transition, they will test the service to ensure that access can be granted,
controlled and prevented as designed.
389
6
MODULE
SERVICE OPERATION
During service operation, these teams will typically perform access management for the
systems under their control. It is unusual for teams to have a dedicated person to manage
access management, but each manager or team leader will ensure that the appropriate
procedures are defined and executed according to the process and policy requirements.
Technical and application management will also be involved in dealing with incidents and
problems related to access management.
If access management activities are delegated to the service desk or IT operations
management, technical and application management must ensure that the staff are
adequately trained and that they have access to the appropriate tools to enable them to
perform these tasks.
390
6
MODULE
SERVICE OPERATION
Service Desk Function

A Service Desk is a functional unit of an organization consisting of dedicated staff who
are responsible for dealing with a wide variety of events often made via a telephone
or a web interface.
The service desk is a vitally important part of an IT organization and should be the
single point of contact for IT users on a day-by-day basis. It not only handles incidents,
escalates incidents to problem management staff, manages service requests and
answers questions.
Justification and role of the service desk:

The role of the service desk cannot be questioned as organizations are confirmed that
this is by far the best approach to deal with first line IT Issues.

Service desk function: A service desk is a functional unit made up of a dedicated number of
staff responsible for dealing with a variety of service activities, usually made via telephone
calls, web interface, or automatically reported infrastructure events.
The service desk is a vitally important part of an IT organization and should be the single point
of contact for IT users on a day-by-day basis. It not only handles incidents, escalates incidents
to problem management staff, manages service requests and answers questions; it may also
provide an interface for other activities such as customer change requests, maintenance
contracts, software licences, SLM, service asset and configuration management, availability
management, financial management for IT services, and IT service continuity management.
The value of an effective service desk should not be underestimated a good service desk
can often compensate for deficiencies elsewhere in the IT organization, but a poor service
desk (or the lack of a service desk) can give a poor impression of an otherwise very effective
391
6
MODULE
SERVICE OPERATION
IT organization! It is therefore very important that the correct calibre of staff be used on the
service desk and that IT managers do their best to make the desk an attractive place to work
to improve staff retention.
The exact nature, type, size and location of a service desk will vary, depending upon the type
of business, number of users, geography, and complexity of calls, scope of services and many
other factors. In alignment to customer and business requirements, the IT organizations
senior managers should decide the exact nature of its required service desk (and whether it
should be internal or outsourced to a third party).
Justification and role of the service desk: Very little justification is needed today for a
service desk, as many organizations have become convinced that this is by far the best
approach for dealing with first-line IT support issues. One only needs ask the question What
is the alternative? to make a compelling case for the service desk concept. Where further
justification is needed, the following benefits should be considered:
Improved customer service, perception and satisfaction.
Improved teamwork and communication.
Enhanced focus and a proactive approach to service provision.
Improved usage of IT support resources and increased productivity of business personnel.
More meaningful management information for decision support.
It is common practice that the service desk provides entry-level positions for ITSM staff.
Working on the service desk is an excellent grounding for anyone wishing to pursue a
career in service management. However, this could also present challenges with people
who do not understand the business or technology.
Users calling the service desk should be able to speak to someone who is able to address
their needs, and service desk analysts should not be burned out in less than a year because
of undue stress. Care should be taken to select appropriately skilled individuals with a good
understanding of the business and to provide adequate training thus preventing reduction
in levels of support due to a lack of knowledge at the first line.
392
6
MODULE
SERVICE OPERATION

Service Desk Objectives:
The primary aim of the service desk is to provide a single point of contact between the
services being provided and the users. A typical service desk manages incidents and
service requests, and also handles communication with the users.
Specific responsibilities will include:

Logging the incident /service request details, allocating categorization and
prioritization codes.
Conducting first line investigation and diagnosis of what went wrong.
Resolving incidents within their capabilities and escalating the incident and service
requests that they are not able to resolve.
Keeping the users updated on the progress and closing resolved incidents.

Service Desk Objectives: The primary aim of the service desk is to provide a single point of
contact between the services being provided and the users. A typical service desk manages
incidents and service requests, and also handles communication with the users. Service desk
staff executes the incident management and request fulfilment processes to restore the
normal-state service operation to the users as quickly as possible. In this context restoration
of service is meant in the widest possible sense. While this could involve fixing a technical
fault, it could equally involve fulfilling a service request or answering a query anything that
is needed to allow the users to return to working satisfactorily.
Specific responsibilities will include:
Logging all relevant incident/service request details, allocating categorization and
prioritization codes.
393
6
MODULE
SERVICE OPERATION
Providing first-line investigation and diagnosis.

Resolving incidents/service requests when first contacted whenever possible.
Escalating incidents/service requests that they cannot resolve within agreed timescales.
Keeping users informed of progress.
Closing all resolved incidents, requests and other calls.
Conducting customer/user satisfaction callbacks/ surveys as agreed.
Communication with users keeping them informed of incident progress, notifying
them of impending changes or agreed outages etc.
394
6
MODULE
SERVICE OPERATION

Service Desk Organizational Structure:
Local Service Desk

Centralized Service Desk
Virtual Service Desk
Follow the Sun

Service desk organizational structure: There are many ways of structuring service desks and
locating them and the correct solution will vary for different organizations. The primary
options are detailed below, but in reality an organization may need to implement a structure
that combines a number of these options in order to fully meet the business needs.
395
6
MODULE
SERVICE OPERATION
Local Service Desk
User
User
User
User
Customer Site
Service Desk
Technical
management
Applicaon
management
IT operaons
management
Third-party
support
Request
fulfilment
Local Service Desk

This is where a desk is co-located within or physically close to the user community it serves.
This often aids communication and gives a clearly visible presence, which some users like,
but can often be inefficient and expensive to resource as local staff are tied up waiting to deal
with incidents when the volume and arrival rate of calls may not justify this.
396
6
MODULE
SERVICE OPERATION
There may, however, be some valid reasons for maintaining a local desk, even where call
volumes alone do not justify this. Reasons might include:
Language and cultural or political differences.
Different time zones.
Specialized groups of users.
The existence of customized or specialized services that require specialist knowledge.
VIP/criticality status of users.
397
6
MODULE
SERVICE OPERATION
Centralized Service Desk
User
User
User
User
User
User
User
User
Customer site 2
Customer site 1
User
User
User
User
Customer site 3
Service desk
Technical
management
Applicaon
management
IT operaons
management
Third - party
support
Request
fulfilment
Centralized service desk

It is possible to reduce the number of service desks by merging them into a single location
(or into a smaller number of locations) by drawing the staff into one or more centralized
service desk structures. This can be more efficient and cost-effective, allowing fewer overall
staff to deal with a higher volume of calls, and can also lead to higher skill levels through
greater familiarization from more frequent occurrence of events. It might still be necessary to
maintain some form of local presence to handle physical support requirements, but such staff
can be controlled and deployed from the central desk.
398
6
MODULE
SERVICE OPERATION
San Francisco
service desk
Rio de
Janeiro
service desk
Paris
service desk
Virtual
Service desk
Sydney
service desk
Beijing
service desk
Service
Knowledge
Management
system
London
service desk

Virtual service desk: Through the use of technology, particularly the internet, and the use of
corporate support tools, it is possible to give the impression of a single, centralized service desk
when in fact the personnel may be spread or located in any number or type of geographical
or structural locations. This brings in the option of home working, secondary support
groups, offshoring or outsourcing or any combination necessary to meet user demand. It
is important to note, however, that safeguards are needed in all of these circumstances to
ensure consistency and uniformity in service quality and cultural terms.
399
6
MODULE
SERVICE OPERATION
Follow the sun: Some global or international organizations may wish to combine two or more
of their geographically dispersed service desks to provide a 24-hour follow-the-sun service.
For example, a service desk in the Asia-Pacific may handle calls during its standard office
hours and at the end of this period it may hand over responsibility for any open incidents
to a European-based desk. That desk will handle these calls alongside its own incidents
during its standard day and then hand over to a USA-based desk which finally hands back
responsibility to the Asia-Pacific desk to complete the cycle.
This can give 24-hour coverage at relatively low cost, as no desk has to work more than a
single shift. However, the same safeguards of common processes, tools, shared databases of
information and culture must be addressed for this approach to proceed and well-controlled
escalation and handover processes are needed.
400
6
MODULE
SERVICE OPERATION
Specialized Service Desk groups

For some organizations it might be beneficial to create specialist groups
within the overall service desk structure, so that incidents relating to
a particular IT service can be routed directly (normally via telephony
selection or a web-based interface) to the specialist group. This can
allow faster resolution of these incidents, through greater familiarity
and specialist training.
Specialized Service Desk groups

Specialized service desk groups: For some organizations it might be beneficial to create
specialist groups within the overall service desk structure, so that incidents relating to a
particular IT service can be routed directly (normally via telephony selection or a web-based
interface) to the specialist group. This can allow faster resolution of these incidents, through
greater familiarity and specialist training.
The selection would be made using a script along the lines of If your call is about the X
service, please press 1 now, otherwise please hold for a service desk analyst. Care is needed
not to overcomplicate the selection, so specialist groups should only be considered for a very
small number of key services where these exist, and where call rates about that service justify
a separate specialist group.
401
6
MODULE
SERVICE OPERATION
Note on building a single point of contact: to fulfil an organizations overall service desk
structure, individual users should be in no doubt about who to contact if they need assistance
or where they can access self-help support. A single telephone number (or a single number
for each group if separate desks are chosen) should be provided and well publicized, as well
as a single email address and a single web service desk contact page. There are several ways
to help publicize the service desk telephone number and email address, and make them
easily available when users are likely to need them, such as:
Including the service desk telephone number on hardware CI labels, attached to the
components the user is likely to be calling about.
Printing service desk contact details on telephones.
For PCs and laptops, using a customized background or desktop with the service desk
contact details, together with information read from the system that will be needed
when calling (such as IP address, OS build number etc.) in one corner.
Printing the service desk number on freebies (pens, pencils, mugs, mouse mats etc.).
Prominently placing these details on service desk internet/intranet sites.
Including them on any calling cards or satisfaction survey cards left with users when a
desk visit has been necessary.
Repeating the details on all correspondence sent to users (together with call
reference numbers).
Placing the details on notice boards or physical locations that users are likely to regularly
visit (entrances, canteens, refreshment areas etc.).
402
6
MODULE
SERVICE OPERATION
Service Operation Function

Service desk
Technical
management
Mainframe
Server
Network
Storage
IT operaons management
IT operaons control
Console management /
operaons bridge
Job scheduling
Backup and restore
Print and output management
Facilies management
Recovery sites
Contracts
Data centers
Consolidaon
Applicaon
management
Financial
apps
HR
apps
Business
apps
Database
Directory
services
Desktop
Middleware
Internet/web
403
6
MODULE
SERVICE OPERATION
Technical Management Function

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.
In this role 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.
Technical Management objectives

Well designed and highly resilient, cost-effective technical topology.
The use of sufficient technical skills to maintain the technical
infrastructure in optimum condition.

Technical Management Role plays a dual role: 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 and, thus, to meet business objectives. Defining
the requirements for these roles starts in Service Strategy and is expanded in Service Design,
validated in Service Transition and refined in Continual Service Improvement.
Part of this role is also to ensure a balance between the skill level, utilization and the cost
of these resources. For example, hiring a top-level resource at the higher end of the salary
scale and then only using that skill for 10% of the time is not effective. A better Technical
Management strategy would be to identify the times that the skill is needed and then hire a
contractor for only those tasks.
404
6
MODULE
SERVICE OPERATION
Another strategy in larger organizations is to leverage specialist staff out of central pools
so that specialists can be well utilized and provide an economy of scale to the organization
and minimize the need to hire in contractors. Specialized skills should be identified among
resources in the IT organization, then leveraged for specific needs as they arise, analogous
to a special tactical unit, whose members also perform regular duties but who are assigned
to tasks needing their specialized skills. This type of resource utilization is particularly useful
both for project teams and problem resolution.
An additional, but very important role played by Technical Management is to provide
guidance to IT Operations about how best to carry out the ongoing operational management
of technology. This role is partly carried out during the Service Design process, but it is also
a part of everyday communication with IT Operations Management as they seek to achieve
stability and optimum performance.
Technical Management Objectives: The objectives of technical management are to help
plan, implement and maintain a stable technical infrastructure to support the organizations
business processes through:
Well designed and highly resilient, cost-effective technical topology.
The use of adequate technical skills to maintain the technical infrastructure in optimum
condition.
Swift use of technical skills to speedily diagnose and resolve any technical failures that
do occur.
405
6
MODULE
SERVICE OPERATION
IT Operations Management Function

IT Operations Management Role:
The role of IT operations management is to execute the ongoing activities and
procedures required to manage and maintain the IT infrastructure so as to
deliver and support IT services at the agreed levels.
IT Operations
Control
Facilities
Management
IT Operations Control
Console Management, which refers to defining central observation and
monitoring capability and then using those consoles to exercise monitoring and
control activities Job Scheduling, or the management of routine batch jobs or
scripts
Backup and Restore on behalf of all Technical and Application Management
teams and departments and often on behalf of users

IT Operations Management Role: The role of IT operations management is to execute the
ongoing activities and procedures required to manage and maintain the IT infrastructure so
as to deliver and support IT services at the agreed levels.
IT Operations Control, which oversees the execution and monitoring of the operational
activities and events in the IT Infrastructure. This can be done with the assistance of an
Operations Bridge or Network Operations Centre. In addition to executing routine tasks from
all technical areas, Operations Control also performs the following specific tasks:
Console Management, which refers to defining central observation and monitoring
capability and then using those consoles to exercise monitoring and control activities
Job Scheduling, or the management of routine batch jobs or scripts.
406
6
MODULE
SERVICE OPERATION
Backup and Restore on behalf of all Technical and Application Management teams and
departments and often on behalf of users.
Print and Output management for the collation and distribution of all centralized printing
or electronic output.
Performance of maintenance activities on behalf of Technical or Application Management
teams or departments.
407
6
MODULE
SERVICE OPERATION

Facilities Management
IT Operations Management is responsible for executing the activities and
performance standards defined during Service Design and tested during
Service Transition.
IT Operations Management must be able to continually adapt to business
requirements and demand.
IT Operations must achieve a balance between these roles, which will require the following:
An understanding of how technology is used to provide IT services
An understanding of the relative importance and impact of those services on the

business.
All IT operations staff understand exactly how the performance of the technology
affects the delivery of IT services.
A value, rather than cost, based Return on Investment strategy.

Facilities Management: which refers to the management of the physical IT environment,
typically a Data Centre 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, e.g. Data Centre consolidation or server consolidation projects. In some
cases the management of a data center is outsourced, in which case Facilities Management
refers to the management of the outsourcing contract.
As with many IT Service Management processes and functions, IT Operations Management
plays a dual role.
408
6
MODULE
SERVICE OPERATION
IT Operations Management is responsible for executing the activities and performance

standards defined during Service Design and tested during Service Transition. In this sense IT
Operations role is primarily to maintain the status quo. The stability of the IT Infrastructure
and consistency of IT services is a primary concern of IT Operations. Even operational
improvements are aimed at finding simpler and better ways of doing the same thing.
At the same time, IT Operations is part of the process of adding value to the different
lines of business and to support the value network. The ability of the business to meet its
objectives and to remain competitive depends on the output and reliability of the day-to-day
operation of IT. As such, IT Operations Management must be able to continually adapt to
business requirements and demand. The Business does not care that IT Operations complied
with a standard procedure or that a server performed optimally. As business demand and
requirements change, IT Operations Management must be able to keep pace with them,
often challenging the status quo.
IT operations must achieve a balance between these roles, which will require the following:
An understanding of how technology is used to provide IT services.
An understanding of the relative importance and impact of those services on the business.
Procedures and manuals that outline the role of IT operations in both the management
of technology and the delivery of IT services.
A clearly differentiated set of metrics to report to the business on the achievement of
service objectives; and to report to IT managers on the efficiency and effectiveness of IT
operations.
All IT operations staff understands exactly how the performance of the technology affects
the delivery of IT services.
A cost strategy aimed at balancing the requirements of different business units with the
cost savings available through optimization of existing technology or investment in new
technology.
A value- rather than cost-based ROI strategy.
409
6
MODULE
SERVICE OPERATION

IT Operations Management Objectives:
To achieve stability in organizations day-to-day processes and activities,
one should maintain the quo status.
To achieve improved services at reduced cost with stability a regular
analysis has to be performed.
Summaries the application of operational skills to diagnose and to resolve
IT failures.
IT Operations Management objectives:

Maintenance of the status quo to achieve stability of the organizations day-to-day
processes and activities.
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.
410
6
MODULE
SERVICE OPERATION
Application Management Function

Application Management Role
Application management is responsible for managing applications throughout
their lifecycle. This differs from application development as application
management covers the entire ongoing lifecycle of an application, including
requirements, design, build, deploy, operate and optimize.
Application Management Objectives:

To assists in designing and deployment of those applications and in ongoing
support and improvement of applications.
Applications with well designed, resilient and cost-effective.

Application Management Role: Application management is to applications what technical
management is to the IT infrastructure. Application management activities are performed
in all applications, whether purchased or developed in-house. One of the key decisions that
they contribute to is the decision of whether to buy an application or build it. Once that
decision is made, application management will have several roles:
It 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.
411
6
MODULE
SERVICE OPERATION
It provides the actual resources to support the ITSM Lifecycle. In this role, Application
Management ensures that resources are effectively trained and deployed to design, build,
and transition, operate and improve the technology required to deliver and support IT
services.
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 and thus
to meet business objectives. This starts in Service Strategy and is expanded in Service Design,
tested in Service Transition and refined in Continual Service Improvement (see other ITIL
publications in this series). Part of this role is to ensure a balance between the skill level and
the cost of these resources.
In additional to these two high-level roles, Application Management also performs the
following two specific roles:
Providing guidance to IT Operations about how best to carry out the ongoing operational
management of applications. This role is partly carried out during the Service Design
process, but it is also a part of everyday communication with IT Operations Management
as they seek to achieve stability and optimum performance.
The integration of the Application Management Lifecycle into the ITSM Lifecycle.
Application Management objectives: The objectives of Application Management are
to support the organizations business processes by helping to identify functional and
manageability requirements for application software, and then to assist in the design and
deployment of those applications and the ongoing support and improvement of those
applications. These objectives are achieved through:
Applications that are well designed, resilient and cost-effective.
Ensuring that the required functionality is available 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 speedily diagnose and resolve any technical failures that
do occur.
412
6
MODULE
SERVICE OPERATION
Summary
Service Operations Principles
Service Operations Processes
Incident Management
Problem Management
Access Management
Event Management
Request Fulfilment Process
Service Operations Functions

Roles in Service Operations
413
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
MODULE
SERVICE OPERATION
414
6
MODULE
SERVICE OPERATION
Assessment
415
6
MODULE
SERVICE OPERATION
1.
Which of following statements are CORRECT?

1. An Event could be caused by an exception to normal operation, such as a device
exceeding a threshold.
2. An Event could be caused by normal operation, such as a user logging into an
application.
a. 2 only
b. 1 only
2.
Which of the following functions would be responsible for management of a data

centre?
a. Technical Management
b. Service Desk.
c. Application Management
d. Facilities Management.
3.
Which of the following can include steps that will help to resolve an Incident?
1. Incident Model
2. Known Error Record.
a. 1 only
b. 2 only
416
6
MODULE
SERVICE OPERATION
4.
Which Function is responsible for the closure of an Incident?

a. Event Management
b. The Service Desk only
c. Either the Service Desk or an appropriate third party engineer.
d. An appropriate function.
5.
Which process is responsible for low risk, frequently occurring, low cost changes?
a. Demand Management
b. Incident Management
c. Release and Deployment Management
d. Request Fulfilment Management
6.
Which of the following should be available to the Service Desk?

1. Known Error Data.
2. Change Schedules
3. Service knowledge Management System
4. Diagnostic scripts and tools
a. 1 only
b. 1, 2 AND 3 only
c. 1 and 3 only
7.
Which of the following are goals of Service Operation?

1. To coordinate and carry out the activities and processes required to deliver and
manage services at agreed levels to the business.
2. The successful release of services into the live environment.
a. 1 only
b. 2 only
417
6
MODULE
SERVICE OPERATION

8.
What are the two major processes in Problem Management?

a. Technical and Service
b. Resource and Proactive
c. Reactive and Proactive
d. Technical and Reactive
9.
Hierarchic escalations are best described as?

a. Notifying more senior levels of management about an Incident.
b. Passing an Incident to people with a greater level of technical skill.
c. Using more senior specialist than necessary to resolve an incident to maintain
customer satisfaction.
d. Failing to meet the Incident resolution times specified in a service level agreement.
10. Which of the following best describes a Problem?

a. An issue reported by a user.
b. The cause of two or more incidents.
c. A serious incident which has a critical impact to the business.
d. The cause of one or more incidents.
11. Which of the following best describes Technical Management?
a. A function responsible for Facilities Management and building control systems.
b. A function that provides hardware repair services for technology involved in the
delivery of service to customers.
c. Senior Management responsible for all staff within the technical support function.
d. A function that includes providing technical expertise and overall management of
the IT Infrastructure.
418
6
MODULE
SERVICE OPERATION
12. Which processes will contribute MOST to enabling effective problem detection?
a. Incident and Financial Management.
b. Change and Release Management.
c. Incident and Event Management.
d. Knowledge and Service Level Management.
13. Which of the following should be documented in an Incident Model?
1. Details of the Service Level Agreement pertaining to the incident.
2. Chronological order of steps to resolve the incident.
a. 1 only
b. 2 only
d. None of the above
14. Which of the following processes are performed by Service Desk?
1. Capacity Management.
2. Request Fulfilment.
3. Demand Management
4. Incident Management.
a. All of the above
b. 2, 3 and 4 only
c. 2 and 4 only
d. 2 only
419
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
420
Co
CONTINUAL SERVICE IMPROVEMENT
Improveme
rvice
nt
l Se
a
itnu
n
Service De
sig
n

n
Tra
n
siti o
421
vic
e
Se
Ser
era
ce Op ti on
r vi
vice Stra
gy
te
er
7
MODULE
Learning Objective
After the completion of this module participants will

be able to:
Understand and explain the concepts and definitions of CSI.
Understand and explain the Demings Cycle.
Explain the CSI Approach.
Understand the CSI Register.
Understand and explain the Metrics in CSI
Understand the 7-Step Improvement process within CSI.
420
7
MODULE
Continual service improvement and the service lifecycle

Service strategy
Strategies, policies,
standards
Output
Feedback
Lessons learned
for improvement
Service design
Plans to create and modify
services and service
management processes
Output
Feedback
Lessons learned
for improvement
Feedback
Lessons learned
for improvement
Service transion
Manage the transion of a
new or changed service
and/or service management
process into producon
Output
Feedback
Lessons learned
for improvement
Feedback
Lessons learned
for improvement
Service operaon
Day -to-day operaon of
services and service
management processes
Connual service improvement

Acvies are embedded in the service lifecycle
421
7
MODULE
Models used in CSI

Demings Cycle (PDCA).
Proposed by Edward Deming for Quality Improvement.
CSI Approach.
Overall approach to Continual Service Improvement.
422
7
MODULE
Models used in CSI - Deming Cycle (PDCA)

The Deming Cycle: W. Edwards Deming is best known for his
management philosophy leading to higher quality, increased
productivity, and a more competitive position.
Demings Cycle (PDCA) is critical at two points in CSI:
Implementation of CSI, and for the application of CSI to services and
service management processes. 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, and review and implement initiatives.

The Deming Cycle: W. Edwards Deming is best known for his management philosophy leading
to higher quality, increased productivity, and a more competitive position. As part of this
philosophy he formulated 14 points of attention for managers. Some of these points are
more appropriate to service management than others. For quality improvement he proposed
the Deming Cycle or Circle. This cycle is particularly applicable in CSI. The four key stages
of the cycle are Plan, Do, Check and Act, after which a phase of consolidation prevents the
circle from rolling back down the hill. Our goal in using the Deming Cycle is steady, ongoing
improvement. It is a fundamental tenet of Continual Service Improvement.
The PDCA Cycle is critical at two points in CSI: implementation of CSIs, and for the application
of CSI to services and service management processes. 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, and review and implement initiatives.
423
7
MODULE
The seven-step improvement process can be viewed as an example of an implementation

of the PDCA cycle, with each of the steps falling within one of the phases of the cycle: Plan,
Do, Check, Act. The cycle is underpinned by a process-led approach to management where
defined processes are in place, the activities are measured for compliance to expected values
and outputs are audited to validate and improve the process.
It should be noted that the PDCA cycle is a fundamental part of many quality standards
including ISO/IEC 20000.
424

Plan
Do
Check
Act
ACT
Maturity level
MODULE
Project Plan
Project
Audit
New acons
PLAN
Business
IT
alignment
CHECK
DO
Effecve quality
improvement
Consolidaon of the level reached
i.e. baseline
Timescale

The Deming Cycle: W. Edwards Deming is best known for his management philosophy leading
to higher quality, increased productivity, and a more competitive position. As part of this
philosophy he formulated 14 points of attention for managers. Some of these points are
more appropriate to service management than others. For quality improvement he proposed
the Deming Cycle or Circle. This cycle is particularly applicable in CSI. The four key stages
of the cycle are Plan, Do, Check and Act, after which a phase of consolidation prevents the
circle from rolling back down the hill. Our goal in using the Deming Cycle is steady, ongoing
improvement. It is a fundamental tenet of Continual Service Improvement.
425
7
MODULE
The PDCA Cycle is critical at two points in CSI: implementation of CSIs, and for the application
of CSI to services and service management processes. 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, and review and implement initiatives.
The seven-step improvement process fully described later can be viewed as an example
of an implementation of the PDCA cycle, with each of the steps falling within one of the
phases of the cycle: Plan, Do, Check, Act. The cycle is underpinned by a process-led approach
to management where defined processes are in place, the activities are measured for
compliance to expected values and outputs are audited to validate and improve the process.
426
7
MODULE
Continual Service Improvement Approach
How do we keep the

momentum going?
What is the vision?
Business vision,
mission, goals and
objecves
Where are we now?
Baseline
assessments
Where do we want
to be?
Measurable
targets
How do we get there?
Service and process

improvement
Did we get there?
Measurements and
metrics
Continual Service Improvement Approach

CSI Approach: The business needs to be involved with CSI in decision making on what
improvement initiatives make sense and add the greatest value back to the business. There
are some key questions that will assist the business in making decisions about whether a CSI
initiative is warranted or not. The following questions are often asked from a business and IT
perspective. Not understanding some of these questions can lead to challenges, perceived
poor service or in some cases actual poor service:
What is the vision? The question should ask by the IT service provider to understand what
the ultimate and long terms aims are.
Where are we now? This is a question every business should start out asking as this
creates a baseline of data for services currently being delivered.
427
7
MODULE
Where do we want be? This is often expressed in terms of business requirements.

How do we get there? What improvement initiatives are required in the short, medium
and long term? These initiatives should be logged in CSI register.
Did we get there? This is documented through monitoring, reporting and reviewing of
service level achievements and actual performance against targets identified by the
business requirements.
428
7
MODULE
Seven Step Improvement Process

Step 1 Identify the strategy for improvement
Step 2 Define what you will measure
Step 3 Gather the data
Step 4 Process the data
Step 5 Analyse the information and data
Step 6 Present and use the information
Step 7 Implement improvement
Seven Step Improvement Process

Step 1 Identify the strategy for improvement: Before any further activity can be started
it is imperative that the overall vision is identified. What are we trying to achieve for the
business as a whole? The questions we need to ask are: What initiatives does the business
429
7
MODULE
have that could be undermined by poor IT service provision? Or, more positively: How can
improvements in IT enable the business vision to be achieved? The answers to these questions
will come from stepping through the seven-step improvement process.
What are the business and IT strategy and plans for the coming months and years? Why do we
want to measure for improvement? The overall strategy should be assessed and analysed to
see where we need to focus our measurements, for example. The technical and operational
goals as well as the strategic goals need to be identified and assessed. The vision should not
be to have state-of-the-art servers and desk-top computers, but to have state of- the-art
services that ensure and enable the overall business to perform as well as possible so it is not
in any way constrained by the quality or cost of the IT services.
Step 2 Define what you will measure: This step is directly related to the strategic, tactical
and operational goals that have been defined for measuring services and service management
processes as well as the existing technology and capability to support measuring and CSI
activities.
In this step you need to define what you should measure; define what you can actually
measure; carry out a gap analysis; and then finalize the actual measurement plan.
As stated previously, measurement will take place at service, process and technology levels.
Step 2 is iterative during the rest of the activities. Depending on the goals and objectives to
support service improvement activities, an organization may have to purchase and install
new technology to support the gathering and processing of the data and/or hire staff with
the required skills sets. Effective service measures concentrate on a few vital, meaningful
indicators that are economical, quantitative and usable for the desired results. If there are
too many measures, organizations may become too intent on measurement and lose focus
on improving results. A guiding principle is to measure that which matters most. IT has never
lacked in the measuring area. In fact, many IT organizations measure far too many things that
have little or no value. There is often no thought or effort given to aligning measures to the
business and IT goals and objectives.
Step 3 Gather the data: Key message: Gathering the data is synonymous with service
measurement. Gathering data requires having monitoring in place. Monitoring could be
executed using technology such as application, system and component monitoring tools
as used in the event management process (documented in service operation) or even be
a manual process for certain tasks. The accuracy and integrity of the data should always be
maintained.
430
7
MODULE
Quality is the key objective of monitoring for CSI. Monitoring will therefore focus on the
effectiveness and efficiency of a service, process, tool, organization or configuration item
(CI). The emphasis is not on assuring real-time service performance; rather it is on identifying
where improvements can be made to the existing level of service, or IT performance.
Monitoring for CSI will therefore tend to focus on detecting exceptions and resolutions. For
example, CSI is not as interested in whether an incident was resolved, but whether it was
resolved within the agreed time, and whether future incidents can be prevented.
CSI is not only interested in exceptions, though. If an SLA is consistently met over time, CSI
will also be interested in determining whether that level of performance can be sustained
at a lower cost or whether it needs to be upgraded to an even better level of performance
because of changing business requirements. CSI may therefore also need access to regular
performance reports.
Step 4 Process the data: This step is to convert the data into the required format and for the
required audience. Follow the trail from metric to KPI to CSF, all the way back to the vision if
necessary. Report-generating technologies are typically used at this stage as various amounts
of data are condensed into information for use in the analysis activity. The data is also typically
put into a format that provides an end-to-end perspective on the overall performance of a
service. This activity begins the transformation of raw data into packaged information. Use
the information to develop insight into the performance of the service and/or processes.
Process the data into information (by creating logical groupings), which provides a better
means to analyse the information and data the next step in CSI.
The output of logical groupings could be in spreadsheets, reports generated directly from the
service management tool suite, system monitoring and reporting tools, or telephony tools
such as an automatic call distribution tool. Processing the data is an important CSI activity
that is often overlooked. While monitoring and collecting data on a single infrastructure
component is important, it is also important to understand that components impact on the
larger infrastructure and IT service. Knowing that a server was up 99.99% of the time is one
thing; knowing that no one could access the server is another. An example of processing the
data is taking the data from monitoring of individual components, such as the mainframe,
applications, WAN, LAN, servers etc., and processing it into a structure of an end-to-end
service from the customers perspective.
Key questions that need to be addressed in the processing activity are:
What is the frequency of processing the data? This could be hourly, daily, weekly or
monthly. When introducing a new service or service management process it is a good
431
7
MODULE
idea to monitor and process in shorter intervals than longer intervals. How often analysis
and trend investigation activities take place will drive how often the data is processed.
What format is required for the output? This is also driven by how analysis is carried out
and ultimately how the information is used.
What tools and systems can be used for processing the data?
How do we evaluate the accuracy of the processed data?
There are two aspects to processing data. One is automated and the other is manual. While
both are important and contribute greatly to the measuring process, accuracy is a major
differentiator between the two types. The accuracy of the automated data gathering and
processing is not the issue here. Nearly all CSI-related data will be gathered by automated
means. Human data gathering and processing is the issue. It is important for staff to properly
document their compliance activities, to update logs and records.
Step 5: Analyze the Information and data: Your organizations Service Desk has a trend of
reduced call volumes consistently over the last four months. Even though this is a trend,
you need to ask yourself the question: Is this a good trend or a bad trend? You dont
know if the call reduction is because you have reduced the number of recurring errors in
the infrastructure by good problem management activities or if the customers feel that the
Service Desk doesnt provide any value and they have started bypassing the Service Desk
and going directly to second-level support groups. Data analysis transforms the information
into knowledge of the events that are affecting the organization. More skill and experience
is required to perform data analysis than data gathering and processing. Verification against
goals and objectives is expected during this activity. This verification validates that objectives
are being supported and value is being added. It is not sufficient to simply produce graphs of
various types but to document the observations and conclusions.
Step 6: Present and use information: The sixth step is to take our knowledge and present it,
that is, turn it into wisdom by utilizing reports, monitors, action plans, reviews, evaluations
and opportunities. Consider the target audience; make sure that you identify exceptions to
the service, benefits that have been revealed, or can be expected. Data gathering occurs at
the operational level of an organization. Format this data into knowledge that all levels can
appreciate and gain insight into their needs and expectations.
432
7
MODULE
This stage involves presenting the information in a format that is understandable, at the
right level, provides value, notes exceptions to service, identifies benefits that were revealed
during the time period, and allows those receiving the information to make strategic, tactical
and operational decisions. In other words, presenting the information in the manner that
makes it the most useful for the target audience.
Step 7: Implement Improvement: Use the knowledge gained and combine it with previous
experience to make informed decisions about optimizing, improving and correcting services.
Managers need to identify issues and present solutions. This stage may include any number of
activities such as approval of improvement activities, prioritization and submitting a business
case, integration with change management, integration with other lifecycle stages, and
guidance on how to manage an ongoing improvement project successfully and on checking
on whether the improvement actually achieved its objective.
CSI identifies many opportunities for improvement however organizations cannot afford
to implement all of them. Based on goals, objectives and types of service breaches, an
organization needs to prioritize improvement activities. Improvement initiatives can also
be externally driven by regulatory requirements, changes in competition, or even political
decisions.
433
7
MODULE
The Seven-Step Improvement Process

Wisdom
2. Define what you will

measure
1.Idenfy the strategy for

improvement
Vision
Business need
Strategy
Taccal goals
Operaonal goals
PLAN
7. Implement improvement
Data
3. Gather the data

Who? How? When?
Criteria to evaluateintegrity
of data
Operaonal goals
Service measurement
DO
ACT
6. Present and use the
informaon
Assessment summary
Acon plans
Etc.
CHECK
5. Analyse the informaon
and data
Trends?
Targets?
Improvements required?
4. Process the data

Frequency?
Format?
Tools and systems?
Accuracy?
Knowledge
Informaon
434
7
MODULE
CSI Register
It is recommended that a CSI register is kept to record all the improvement
opportunities and that each one should be categorized into small, medium
and large undertakings.
The CSI register provides a coordinated, consistent view of the potentially
numerous improvement activities.
The CSI register will introduce a structure and visibility to CSI ensuring that
all initiatives are captured and recorded and benefits realized.
The CSI register contains important information for the overall service
provider and should be held and regarded as part of the Service Knowledge
Management System (SKMS)
CSI Register:
It is likely that several initiatives or possibilities for improvement are identified. It is
recommended that a CSI register is kept to record all the improvement opportunities and
that each one should be categorized into small, medium or large undertakings. Accordingly
they should be categorized into initiatives that can be achieved quickly, or in the medium or
longer term. Each improvement initiative should also show the benefits that will be achieved
by its implementation. With this information a clear prioritized list can be produced.
The CSI register contains important information for the overall service provider and should
be held and regarded as part of the service knowledge management system (SKMS). The CSI
register will introduce a structure and visibility to CSI ensuring that all initiatives are captured
and recorded, and benefits realized.
435
7
MODULE
Metrics in CSI
There are three types of metrics that an organization needs to gather
to support CSI activities as well as other process activities. The kinds of
metrics are:
Technology These metrics are often linked with component and application-based
metrics such as performance, availability etc.
Metrics
Process
Metrics
These metrics are captured in the form of CSFs, KPIs and activity metrics
for the service management processes. 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. Individual

technology and process metrics are used when calculating the end to
end service metrics.
Metrics in CSI:
There are three types of metrics that an organization needs to gather to support CSI activities
as well as other process activities. The kinds of metrics are:
Technology metrics These metrics are often linked with component and applicationbased metrics such as performance, availability etc.
Process metrics These metrics are captured in the form of CSFs, KPIs and activity metrics
for the service management processes. CSI would use these metrics as input in identifying
improvement opportunities for each process.
436
7
MODULE
Service metrics These metrics are the results of the end-to-end service. Individual
technology and process metrics are used when calculating the end to end service metrics.
In general, a metric is a scale of measurement defined in terms of a standard, i.e. in terms
of a well-defined unit. The quantification of an event through the process of measurement
relies on the existence of an explicit or implicit metric, which is the standard to which
measurements are referenced.
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. Metrics are usually specialized by the subject area, in which case they
are valid only within a certain domain and cannot be directly benchmarked or interpreted
outside it. Generic metrics, however, can be aggregated across subject areas or business
units of an enterprise.
Metrics are used in several business models including CMMI, COBIT and Six-Sigma. These
measurements or metrics are used to track trends, productivity, resources and much more.
437
7
MODULE
Critical Success Factors and Key Performance Indicators

Each organization should develop KPIs that are appropriate for
its level of maturity, its CSFs and its particular circumstances.
Achievement against KPIs should be monitored and used to identify
opportunities for improvement, which should be logged in the CSI
register for evaluation and possible implementation.
CSF All improvement opportunities identified:
KPI Percentage improvement in defects; for example, 3% reduction in failed
changes; 10% reduction in security breaches.
CSF The cost of providing services is reduced

KPI Percentage decrease in overall cost of service provision; for example, 2.5%
reduction in the average cost of handling an incident; 5% reduction in the cost of
processing a particular type of transaction.
CSF The required business outcomes from IT services are achieved

KPI A 3% increase in customer satisfaction with the service desk; 2% increase in
customer satisfaction with the warranty offered by the payroll service.
Critical Success Factors and Key Performance Indicators

Critical success factors and key performance indicators: The following list includes some
sample CSFs for the seven-step improvement process. Each organization should identify
appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a typical
KPI that supports the CSF. These KPIs should not be adopted without careful consideration.
Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs
and its particular circumstances. Achievement against KPIs should be monitored and used
to identify opportunities for improvement, which should be logged in the CSI register for
evaluation and possible implementation. Note that because of the nature of the seven step
438
7
MODULE
improvement process, it has to be applied to appropriate processes, activities, technology,

organizational structure, people and partners for the benefits to be realized. This means that
the KPIs used to judge the success of the seven-step improvement process are actually the
KPIs from the other lifecycle stages and processes to which it has been applied. As a result
the examples given here come from other areas.
CSF All improvement opportunities identified.
KPI Percentage improvement in defects; for example, 3% reduction in failed changes; 10%
reduction in security breaches.
CSF The cost of providing services is reduced.
KPI Percentage decrease in overall cost of service provision; for example, 2.5% reduction in
the average cost of handling an incident; 5% reduction in the cost of processing a particular
type of transaction.
CSF The required business outcomes from IT services are achieved.
KPI A 3% increase in customer satisfaction with the service desk; 2% increase in customer
satisfaction with the warranty offered by the payroll service.
Baselines:
In any improvement initiative is important to establish baselines as starting point for
comparision later.
Example:
An ITSM baseline can be used as starting point to measure the effect of a service improvement
plan.
A performance baseline can be used to measure change in performance over the lifetime
of an IT service.
A configuration baseline can be used as part of a backout plan to enable the IT
infrastructure to be restored to a known configuration if a change or release fails.
439
7
MODULE
Why should we Measure?
To validate
To direct
Your measurement framework
To interview
To Jusfy
Why should we Measure?

Validate are we supporting the strategy and vision?
Justify do we have the right targets and metrics?
Direct based on factual data, people can be guided to change behaviour.
Intervene take corrective actions such as identifying improvement opportunities.
440
7
MODULE
CSI Roles - CSI Manager

CSI Manager: The role of CSI manager is essential for a successful
improvement programme. The CSI manager is ultimately responsible for
the success of all improvement activities.
Developing the CSI domain.
Communicating the vision of CSI across the IT organization.
Ensuring that CSI roles have been filled.
Designing the CSI register and associated activities.
Working with service owners, service level managers, the seven-step
improvement manager, other process managers and functions to identify and
manage improvement opportunities:
Building improvement plans and making improvements.
Ensuring that knowledge management is an integral part of routine operations.
Reviewing analysed data.
Presenting recommendations to senior.
CSI Roles - CSI Manager

CSI manager: The role of CSI manager is essential for a successful improvement programme.
The CSI manager is ultimately responsible for the success of all improvement activities. This
single point of accountability coupled with competence and authority improves the chances
441
7
MODULE
of a successful improvement programme. The role of CSI manager can also fulfil the role of
the seven-step improvement process owner/manager.
The CSI managers responsibilities typically include:
Developing the CSI domain.
Communicating the vision of CSI across the IT organization.
Ensuring that CSI roles have been filled.
Designing the CSI register and associated activities.
Working with service owners, service level managers, the seven-step improvement
manager, other process managers and functions to identify and manage improvement
opportunities:
Building improvement plans and making improvements.
Working with service level managers to ensure that monitoring requirements are defined.
Ensuring that monitoring tools are in place to gather data.
Ensuring that baseline data is captured to measure improvement against it.

Defining and creating reports on CSI critical success factors (CSFs), key performance
indicators (KPIs) and CSI activity metrics.
Identifying other frameworks, models and standards that will support CSI activities.
Ensuring that knowledge management is an integral part of routine operations.
Ensuring that CSI activities are coordinated throughout the service lifecycle.
442
7
MODULE
Reviewing analysed data.

Presenting recommendations to senior management for improvement.
Helping prioritize improvement opportunities.
Leading, managing and delivering cross functional and cross-divisional improvement
projects.
Building effective relationships with the business and IT senior managers.
Identifying and delivering process improvements in critical business areas across
manufacturing and relevant divisions.
Setting direction and providing a framework through which improvement objectives can
be delivered.
Coaching, mentoring and supporting fellow service improvement professionals.
The CSI manager should possess the ability to influence positively all levels of management
to ensure that service improvement activities are receiving the necessary support and are
resourced sufficiently to implement solutions.
443
7
MODULE
Summary
Deming Cycle (PDCA): The PDCA cycle provides steady, ongoing improvement,
which is a fundamental tenet of CSI.
CSI Approach: Approach should ensure that the momentum for quality
improvement is maintained by assuring that changes become embedded in the
organization.
Seven Step Improvement Process: This sets out the processes and activities on
which effective CSI depends and how they integrate with the other stages of the
lifecycle.
Metrics in CSI: Process metrics, Technology metrics and Service metrics
CSFs and KPIs: Each sample CSF is followed by a typical KPI that supports the CSF.
CSI Manager Roles: The CSI manager is ultimately responsible for the success of
all improvement activities.
444
7
MODULE
Assessment
445
7
MODULE
1.
What type of improvement should be achieved by using the Deming Cycle?

a. Rapid one off improvement.
b. Return on Investment within 12 months.
c. Quick wins.
d. Steady, on-going improvement.
2.
Which of the following is NOT an objective of Continual Service Improvement:

a. Identify activities to improve the efficiency of service management processes.
b. Improve the cost of effectiveness of IT service without sacrificing customer
satisfaction.
c. Conduct activities to deliver and manage services at agreed levels to business users.
3.
Which of the following is the correct set of steps for the Continual Service improvement
(CSI) Model?
a. Devise a strategy; Design the solution; Transition into production; Operate the
Solution; continually improve
b. Where do we want to be?; How do we get there?; How do we check we arrived;
How do we keep the momentum going?
c. Identifies the required business outcomes; Plan how to achieve the outcomes;
Implement the plan; Check the plan has been properly implemented; improve the
solution
d. What is the vision? , Where are we now? , Where do we want to be? , How do we
get there? , Did we get there? , How do we keep the momentum going?
4.
Which of the following activities is NOT a part of the Deming Cycle?

a. Act
b. Plan
c. Do
d. Coordinate
446
7
MODULE
5.
Which of the following do Service Metrics measure?

a. Processes and Functions
b. Maturity and Cost
c. The end to end service
d. Infrastructure availability
6.
A CSI Register is (Chose the correct statement):

a. To keep a coordinated and consistent view of the numerous improvement activities.
b. To just register complaints
c. To make people accountable for improvement activities.
7.
Which of the following are critical to implementing CSI:

1. Adopting SLM
2. Service Measurement
3. CSI Register
4. Ownership
a. 1 and 2 only
b. 1 and 3 only
c. 3 and 4 only
8.
Which of the following are the correct set of Metrics an organization needs to collect to
support CSI activities:
a. Process, Service and Project Metrics
b. Process, Service and Technology Metrics
c. Process, Support and Service Metrics
d. Process, Support and Technology Metrics.
447
7
MODULE
9.
Which are the two basic kind of KPIs as defined in ITIL CSI books:
a. Process and Technology KPIs
b. Service and Technology KPIs
c. Qualitative and Quantitative KPIs
d. Qualitative and Process KPIs
10. Which of the following is important and work as starting point for later comparision:
a. Metrics
b. Processes
c. Baselines
d. Milestones
448
ACTIVITIES
449
ACTIVITIES
8.1 - SERVICE STRATEGY

Nestwood Forge, a fictitious manufacturing company with $500 million in annual revenues,
was under pressure from its shareholders and from Wall street to increase its profitability.
One possibility the top management considered was to install an online procurement system
to cut purchasing costs for just about everything the company buys, from raw materials for
its widgets to such commoditized items as safety helmets, work gloves and office supplies,
on which the company spends about $225 million a year. There has been a lot of hype
surrounding e-purchasing, and the companys executives, ordinarily a pretty conservative
group, were uneasy about making a significant investment in a new and, in their minds,
unproven-technology. So they asked their CIO and CFO a simple question: How much actual
value might such a system bring to Nestwood Forge?
To answer that question, Nestwoods CEO and CFO began by estimating the life of such an
online purchasing system to be about four years, given the rapid advance of such information
technology. In addition, Nestwoods new system would not be up and running for a year
because of the time it would take to build and install the system, train the companys
purchasing employees, connect the system to suppliers, and educate them in its use.
Time: 10 Minutes
Discussion:
How the system can benefit Nestwood forge?
450
ACTIVITIES
8.2 - SERVICE DESIGN

1.
A 24/7 IT service requires a weekly 2 hour planned downtime period for application
maintenance. Following the completion of the weekly maintenance an application
software error occurs which results in 3 hours of unplanned downtime.
1. The weekly availability for the IT service is this reporting period is therefore based on the
following:
a. Agreed Service Time (AST) should recognize that the planned 2 hour weekly
downtime is scheduled.
b. Down Time (DT) is the 3 hours of unplanned outage following the application
maintenance.
Basic Availability Calculation:
Availability =
(AST - DT)
AST
X 100
= Service or Component Availability (%)

Where:AST = Agreed service time
DT = Actual downtime during agreed service time
Report Back: Solve the above problem.
451
ACTIVITIES
2.
Availability Parallel Configuration
Host
98%
Host
Network
Server
98%
97.5%
Workstation
96%
98%
Calculate the Availability of the above Infrastructure?

3.
List the challenges/Problems of implementing Capacity Management Process.
4.
They say that You cannot articulate your value until you can show what you provide.
A service catalogue is the key step to becoming a successful service provider. Draw the
structure of service catalogue. You can take three services from your organization and
create a catalogue.
452
Th
is
pa
ge
i
si
nt
en
tio
na
lly
left
bl
an
k
ACTIVITIES
453
ACTIVITIES
8.2 - SERVICE DESIGN - ANSWERS

1.
98.12%
2.
91.69%
3.
Challenges of implementing capacity management.

a. Persuading business to provide information on its business plans.
b. In outsourced situations there may be commercial or confidential reasons why data
cannot be shared.
c. Quality and accuracy of data available for capacity management.
d. Information from different technologies is provided by different tools in different
formats.
e. Huge amount of information provided by business, service and component capacity
management which makes the analysis of information difficult.
454
ACTIVITIES
8.3 - SERVICE TRANSITION

1. Describe Change Management Process in your organization. Explain what you would like
to improve in your organization and how you would improve it.
.
Write down the answer in points on a chart. Present the chart to your Facilitator/Trainer.
2. Write benefits of implementing Change Management Process in your organization. You

should be able to explain these benefits in detail.
3. Discuss how Change Management depends on Service Asset and Configuration
Management? (or) How the relationship between Change Management and Service
Asset and Configuration Management benefits change management.
4. Write down atleast 4 KPIs which will assist in determining the effectiveness of Change
Management Process.
5. Prepare a presentation of 4 slides to share your experience of how Knowledge
Management is practiced in your organization.
455
ACTIVITIES
8.3 - SERVICE TRANSITION - ANSWERS

1.
2. Benefits of change management
a. Increased visibility and communication of changes to both business and support
b. Implement changes that meet customers agreed business requirements while
optimizing costs.
c. Reducing failed changes and therefore service disruption, defects and work.
d. Reducing the number of unauthorized changes, leading to reduced service disruption
and reduced time to resolve change related incidents.
e. Delivering changes promptly to meet business timescales.
f. Tracking changes through the service lifecycle and to the assets of its customers.
3.
Relation between change and configuration management.

a. The configuration management system provides reliable, quick and easy access to
accurate configuration information to enable stakeholders and staff to access the
impact of proposed changes.
b. The information from CMS enables the correct CI versions to be released to the
appropriate party or into the correct environment.
c. The CMS may also identify related CIs that will be affected by change, but not
included in original request, or similar CIs that would benefit from similar changes.
4. KPIs which will assist in determining effectiveness of change process.

a. Percentage of all changes successfully implemented
b. Percentage of all changes completed within budget
c. Reduction in the number of problems associated with implemented changes
d. Reduction in the number of backed-out changes
456
ACTIVITIES
8.4 - SERVICE OPERATIONS

1. Define and describe Service Desk & Incident Management Practices in your organization.
Describe what can be improved and also describe how you can improve.
2
2. Assume that your organizations Service desk which is not mature. Users of your
organization usually define the priorities of the incidents and requests (and not your
Service desk staff). The new Service Desk Manager wanted to bring improvement and
avoid confusion and misunderstandings and suggested to introduce pre-defined priorities
for Incidents and Service Requests.
.
Make assumptions:
Assume that you are the Service Desk Manager of your organization and list at least 8
of the most common incidents and/or service requests that can possibly occur in your
organization.
Develop a priority table and define and describe the criteria to determine the priority.
Your table should describe the priorities to use and how to determine the priority.
3. Write at least 5 KPIs for Problem Management. Write your answer in chart and present
3
it to your Facilitator/Trainer.
457
ACTIVITIES
8.4 - SERVICE OPERATIONS - ANSWERS

31. KPIs for Problem Management.
a. The number of Known errors added to database.
b. Percentage of incidents closed by service desk without reference to other levels of
support.
c. Number of repeat incidents for each IT service.
d. Average incident resolution time for those incidents linked to problem records.
e. The percentage of accuracy of the KEDB.
f. The number of total problems.
458
JOB AIDS
459
JOB AIDS
Job Aid - 1
Service Strategy Inputs and Outputs
Inputs
From the business / customers
x
Business requirements, Patterns of Business Activities (PBAs)
From Service Operation

x
Utilization level of services
From CSI feedback

x
Quality perspective, warranty factors, reliability, maintainability, redundancy
Outputs
Strategy Generation
x
Service strategies, policies, objectives from business requirements

x
Service Portfolio, Service Models, outcomes
Financial Management
x
Pricing, charging models
Demand Management
x
Resource availability, financial and physical constraints
460
JOB AIDS
Service Design Inputs and Outputs

Inputs
From business / customers
x
Business Information and organization plans
From Service Strategy

x
x
Service Portfolio, IT and Financial plans

Business Impact Analysis (BIA), Risk analyses, Studies of Vital Business Functions (VBFs)
From Service Transition

x
Change information
Outputs
x
IT architecture design, Process designs and documentation, Process, policy and

architecture for the design of IT services
Service Catalog Management

x
x
Solutions designs, architectures, standards, SDP

Service definition, Service Portfolio updates, Service Catalog, delivery model
Service Level management

x
x
Measurement systems and metrics, reports, document templates

SIPs, SLA, SLR and OLAs, SQP
Capacity Management
x
CMIS, workload analyses
x
AMIS, Availability Plan, Availability and restore design criteria

x
x
ITSCM policy, updated BIA, risk analyses

Recovery Plan, Plans for disaster recovery, testing and crisis management

x
Information security management policy, management system, security controls,

audits, reports
Supplier Management
x
Supplier and Contract Database (SCD), supplier performance info, Supplier

improvement plans, research reports
461
JOB AIDS
Service Transition Inputs and Outputs

Inputs
x
Service Portfolio, policies, architectures, contract portfolio
From Service Design

x
x
x
SDP
Definition of the Release package and design specifications
Acceptance criteria for the service
Outputs
x
Tested solutions

x
Transition strategy, Service transition plans
Change Management
x
Rejected or approved RFCs, new or changed Services, CIs, assets, adjusted PSO and
Change schedule, decisions, actions, documents, records, reports

x
x
x
Configuration Management Plan, contract

CI ID, naming, labeling, data and documentation
Baseline and Release ID, updated RFC, updated CI

x
Release and Deployment plans, RFC, service notifications, updated Service Catalog,
service model
x New / Changed documentation, service reports, SLA, OLAs and contracts
x New tested service environment
x Service Transition report , service capacity plan
x Complete CI list of release package
Service Validation and Testing
x Test reports, incidents, problems, errors
x Improvements for CSI
x Information and knowledge for the SKMS
Evaluation
x
Evaluation report
x
Updated SKMS
462
JOB AIDS
Service Operation Inputs and Outputs

Inputs
x
Service Portfolio
From Service Design

x
x
x
x
x
Service Catalog
SLA, SLR, OLAs
IT infrastructure details
Security policies
SCD
From Service Transition

x
CMDB
Outputs
x
Operational services
Event Management
x
x
Event, Incident, Problem records, RFC

Auto responses, alert and human intervention
Incident Management
x
x
Incident, Problem, service level reports

RFC, Workarounds, Requests
Request Fulfillment
x
Fulfilled service requests
Problem Management
x
Problem records, KEDB, RFCs, management information
Access Management
x
Access granted, reports on abuses of user authorization
Service Monitoring and Control

x
Service measurements
IT Operations Management
x
IT Services delivered to customers
463
JOB AIDS
Continual Service Improvement Inputs and Outputs

Inputs
x
x
Strategic imperatives that influence quality perspectives processed in CSI

Financial and physical constraints
From Service Design

x
x
Service catalog
SLRs
From Service Operation

x
Service measurements
Outputs
x
x
x
Improvement actions and plans

CSI policies
Service reports
464
JOB AIDS
Job Aid - 2
KEPNER AND TREGOE ROOT CAUSE ANALYSIS TECHNIQUE
The IT Infrastructure Library (ITIL) describes the steps of the root cause analysis method
called Kepner-Tregoe Define and Describe the Problem, Establish possible causes, Test the
most probable cause, and Verify the true cause. The ITIL mentions Kepner-Tregoe, but does
not give enough detail to use it to solve difficult problems.
The actual name is Kepner-Tregoe Problem Solving and Decision Making (PSDM). KepnerTregoe calls the part of PSDM that ITIL refers to Problem Analysis. Problem Analysis helps
the practitioner make sound decisions. It provides a process to identify and sort all the issues
surrounding a decision. As a troubleshooting tool, Problem Analysis helps prevent jumping to
conclusions.
Defining the Problem
Problem Analysis begins with defining the problem. The problem management team cannot
overlook this critical step.
Failure to understand exactly what the issue is often results in wasting precious time. Many
immature troubleshooters consider this step as wasted effort since they know what they are
going to do and this is the critical mistake made by many. Preconceived notions often result
in increased outage duration and even outage expansion due to poor judgment.
Since problem management is inherently a team exercise, it is important to have a group
understanding of the problem.
Consider the following examples. A poor problem definition might appear as follows:
The server crashed.
A better problem definition should include more information. A good model for clarifying
statements of all sorts is the Goal Question Metric (GQM) method. It results in a statement with
a clear Object, Purpose, Focus, Environment, andViewpoint. This results in an unambiguous
and easily understood statement
A clarified problem definition might be:
The e-mail system crashed after the 3rd shift support engineer applied hot-fix XYZ to
Exchange Server 123.
465
JOB AIDS
When developing a problem definition always use the 5 Whys technique to arrive at the
point where there is no explanation for the problem. Using 5 Whys with Kepner-Tregoe only
accelerates the process.
Describing the Problem
With a clear problem definition, the next step is to describe the problem in detail. The
following chart provides a nice template for this activity. You can do this using a presentation
board, paper, or common office software.
Table 1 describes the basic worksheet used in the process.
IS
COULD BE but
IS NOT
WHAT
System Failure
Similar
Systems/
Situations not
failed
WHERE
Failure Location
Other Locations
that did not fail
WHEN
Failure Time
Other locations
where failure
did not occur
EXTENT
Other Failed
Systems
Other systems
without failure
Differences
Changes
Table 1: Problem Analysis Worksheet

The worksheet describes the four aspects of any problem: what it is, where it occurs, when
it occurred, and the extent to which it occurred. The IS column provides space to describe
specifics about the problem -- what the problem IS. The COULD BE but IS NOT column
provides space to list related but excluded specifics -- what the problem COULD BE but IS
NOT. These two columns aid in eliminating intuitive but incorrect assumptions about the
problem. With columns one and two completed, the third column provides space to detail
the differences between the IS and COULD BE but IS NOT. These differences form the basis
of the troubleshooting. The last column provides space to list any changes made that could
account for the differences.
466
JOB AIDS
Establish Possible Causes

Anyone who has spent time troubleshooting knows to see what has changed since it worked
and start troubleshooting by checking for changes. The problem is that many changes can
occur, and that complicates things. Problem Analysis can help here by describing what the
problem is and what the problem could be, but is not.
For example:
Problem: The e-mail system crashed after the 3rd shift support engineer applied hot-fix XYZ
to Exchange Server 123.
IS
WHAT
WHERE
COULD BE but
IS NOT
Differences
Changes
Exchange Server
Different staff
123 crashed
Other Exchange
(3rd
New patch
upon
Servers
shift) applied
procedure
application of
getting hot-fix
this
from vendor
hotfix
XYZ
hot-fix
XYZ
3rd floor
New
production
Anywhere else
procedure, first
room without
with vendor/ Normally done
time 3rd shift
vendor/
contractor
by vendor
applies
contractor
support
hot-fixes
support
WHEN
Last night,
1:35am
Any other time

or location
EXTENT
Any Exchange
Server on 3rd
floor
Other servers
None noted
Table 2: Problem Analysis Worksheet Example
467
JOB AIDS
History (and best practice) says that the root cause of the problem is probably due to some
recent change. With the completed worksheet, some new possible solutions become
apparent. Shown above is becomes clear that the root cause is probably procedural, and due
to the fact the vendor did not apply the hot -fix, but rather gave procedures for the hot-fix
to the company
Test the Most Probable Cause
With a short list of possible causes (recent changes evaluated and turned into a list), the next
step is to think-through each possible problem. The following aid can help in this process.
Ask the question:
If _______is the root cause of this problem does it explain the problem IS and what the
problem COULD BE but
IS NOT?
If this potential solution is the root cause then the potential solution has to map to or fit
into all the aspects of the Problem Analysis worksheet (figure 2.) Use a worksheet like that
shown in figure 3 to help organize your thinking around the potential solutions.
Potential Root Cause
True if
Probable Root Cause
Exchange Server 123 has

something
wrong with it
Only Exchange Server 123

has this problem
Maybe
Procedure incorrect
Same procedure crashes

another server
Probably
Technician error
Problem did not always

reoccur
Probably not
Table 3: Clarifying Problem Analysis
468
JOB AIDS
Verify the True Cause

The next step is to compare the possible root causes (Table 3) against the problem description
(Table 2). Eliminate possible solutions that cannot explain the situation, and focus on the
remaining items. Before making any changes, verify that the proposed solution could be the
root cause. Failure to verify the true cause invalidates the entire exercise and is no better
than guessing. After verifying the true cause, you can propose the action required repair the
problem.
It is important here as well to think about how to prevent similar problems from occurring in
the future. The Problem Manager should consider how the issue arose in the first place by
asking some questions:
Where else might this problem appear?
Are there other occurrences of this problem in the past?
Do any procedures need to change?
The goal is to try to eliminate future occurrences of the problem.
Summary
Kepner-Tregoe is a mature process with decades of proven capabilities. There are
worksheets, training programs, and consulting firms all schooled in the process. You can take
courses at many local colleges as well. Kepner-Tregoe Problem Analysis was used by NASA
to troubleshoot Apollo XIII even though the technicians did not believe the results, they
followed the process and saved the mission. The rest of the story, as they say, is history.
Even without a lot of time available, using Kepner-Tregoe Problem Analysis can result in the
most efficient problem resolutions. Armed with tools like 5 Whys and Ishikawa diagramming,
a Problem Manager can capture the combined experience and knowledge of a team. When
used with Kepner-Tregoe Problem Analysis the result is amazing.
Adopted from an Article Thinking About Problems by Hank Marquis in
www.itsmsolutions.com
469
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
470
SAMPLE EXAM PAPERS
471
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
472
The ITIL Foundation Examination

Sample Paper A, version 5.1
Multiple Choice
Instructions
1.
2.
3.
4.
All 40 questions should be attempted.

All answers are to be marked on the answer grid provided.
You have 60 minutes to complete this paper.
You must achieve 26 or more out of a possible 40 marks (65%) to pass this
examination.
AXELOS Limited 2012

All rights reserved.
Reproduction of this material requires the permission of AXELOS Limited. The swirl logo is a
trade mark of AXELOS Limited
ITIL is a registered trade mark of AXELOS Limited
ITIL Foundation Examination SampleA v5.1.
This document must not be reproduced without express permission from The Accreditor.
Page 1 of 11
Version 5.1 (Live)
Owner The Official ITIL Accreditor
1.
What types of changes are NOT usually included within the scope of change
management?
a) Changes to a mainframe computer
b) Changes to business strategy
c) Changes to a service level agreement (SLA)
d) The retirement of a service
2.
Which of the following is NOT a purpose of service operation?

a) To undertake testing to ensure services are designed to meet business needs
b) To deliver and manage IT services
c) To manage the technology used to deliver services
d) To monitor the performance of technology and processes
3.
What does the term IT operations control refer to?

a) Managing the technical and applications management functions
b) Overseeing the execution and monitoring of operational activities and events
c) A set of tools used to monitor and display the status of the IT infrastructure and
applications
d) A service desk monitoring the status of the infrastructure when operators are
not available
4.
Which process is responsible for recording relationships between service

components?
a) Service level management
b) Service portfolio management
c) Service asset and configuration management (SACM)
d) Incident management
5.
What is the RACI model used for?

a) Documenting the roles and responsibilities of stakeholders in a process or
activity
b) Defining requirements for a new service or process
c) Analysing the business impact of an incident
d) Creating a balanced scorecard showing the overall status of service
management
Version 5.1 (Live)
AXELOS Limited 2012

Reproduction of this material requires the permission of AXELOS Limited.
The swirl logo is a trade mark of AXELOS Limited
Page 2 of 11
6.
Which of the following is the BEST description of an operational level agreement

(OLA)?
a) An agreement between an IT service provider and another part of the same
organization that assists in the provision of services
b) A written agreement between the IT service provider and their customer(s)
defining key targets and responsibilities of both parties
c) An agreement between two service providers about the levels of service
required by the customer
d) An agreement between a third party service desk and the IT customer about fix
and response times
7.
What is the MAIN purpose of availability management?

a) To monitor and report availability of components
b) To ensure that all targets in the service level agreements (SLAs) are met
c) To guarantee availability levels for services and components
d) To ensure that service availability meets the agreed needs of the business
8.
Which of the following does service transition provide guidance on?

1. Introducing new services
2. Decommissioning services
3. Transfer of services between service providers
a) 1 and 2 only
b) 2 only
c) All of the above
d) 1 and 3 only
9.
Which one of the following is NOT a stage of the service lifecycle?

a) Service optimization
b) Service transition
c) Service design
d) Service strategy
AXELOS Limited 2012

Page 3 of 11
Version 5.1 (Live)
10.
Which one of the following statements about a configuration management system

(CMS) is CORRECT?
a) The CMS should not contain corporate data about customers and users
b) There may be more than one CMS
c) There should not be more than one configuration management database
(CMDB)
d) If an organization outsources its IT services there is still a need for a CMS
11.
What are the three sub-processes of capacity management?

a) Business capacity management, service capacity management and component
capacity management
b) Supplier capacity management, service capacity management and component
capacity management
c) Supplier capacity management, service capacity management and technology
capacity management
d) Business capacity management, technology capacity management and
component capacity management
12.
Which of the following would be stored in the definitive media library (DML)?
1. Copies of purchased software
2. Copies of internally developed software
3. Relevant licence documentation
4. The change schedule
a) All of the above
b) 1 and 2 only
c) 3 and 4 only
d) 1, 2 and 3 only
13.
Which process is responsible for reviewing operational level agreements (OLAs) on

a regular basis?
a) Supplier management
b) Service level management
c) Service portfolio management
d) Demand management
AXELOS Limited 2012

Page 4 of 11
Version 5.1 (Live)
14.
Which role should ensure that process documentation is current and available?
a) The service owner
b) The chief information officer
c) Knowledge management
d) The process owner
15.
Which of the following does the release and deployment management process
address?
1. Defining and agreeing release and deployment plans
2. Ensuring release packages can be tracked
3. Authorizing changes to support the process
a) 1 and 2 only
b) All of the above
c) 2 and 3 only
d) 1 and 3 only
16.
Which of the following are characteristics of every process?

1. It is measurable
2. It delivers a specific result
3. It delivers its primary results to a customer or stakeholder
a) 1 and 3 only
b) 1 and 2 only
c) 2 and 3 only
d) All of the above
17.
Which of the following are key ITIL characteristics that contribute to its success?
1. It is vendor-neutral
2. It is non-prescriptive
3. It is best practice
4. It is a standard
a) 3 only
b) 1, 2 and 3 only
c) All of the above
d) 2, 3 and 4 only
AXELOS Limited 2012

Page 5 of 11
Version 5.1 (Live)
18.
Who should be granted access to the information security policy?

a) Senior business managers and IT staff
b) Senior business managers, IT executives and the information security
manager
c) All customers, users and IT staff
d) Information security management staff only
19.
Which of the following are valid elements of a service design package (SDP)?
1. Agreed and documented business requirements
2. A plan for transition of the service
3. Requirements for new or changed processes
4. Metrics to measure the service
a) 1 only
b) 2 and 3 only
c) 1, 2 and 4 only
d) All of the above
20.
Which of the following are examples of tools that might support the service
transition stage of the service lifecycle?
1. A tool to store definitive versions of software
2. A workflow tool for managing changes
3. An automated software distribution tool
4. Testing and validation tools
a) 1, 3 and 4 only
b) 1, 2 and 3 only
c) All of the above
d) 2, 3 and 4 only
21.
Which of the following statements about problem management is/are

CORRECT?
1. It ensures that all resolutions or workarounds that require a change to a
configuration item (CI) are submitted through change management
2. It provides management information about the cost of resolving and
preventing problems
a) 1 only
b) 2 only
c) Both of the above
d) Neither of the above
Version 5.1 (Live)
AXELOS Limited 2012

Page 6 of 11
22.
What is the purpose of the request fulfilment process?

a) Dealing with service requests from the users
b) Making sure all requests within an IT organization are fulfilled
c) Ensuring fulfilment of change requests
d) Making sure the service level agreement (SLA) is met
23.
Which statement about value creation through services is CORRECT?

a) The customer's perception of the service is an important factor in value
creation
b) The value of a service can only ever be measured in financial terms
c) Delivering service provider outcomes is important in the value of a service
d) Service provider preferences drive the value perception of a service
24.
Which one of the following statements about internal and external customers is
MOST correct?
a) External customers should receive better customer service because they pay
for their IT services
b) Internal customers should receive better customer service because they pay
employee salaries
c) The best customer service should be given to the customer that pays the
most money
d) Internal and external customers should receive the level of customer service
that has been agreed
25.
Which one of the following should IT services deliver to customers?

a) Capabilities
b) Cost
c) Risk
d) Value
26.
Which one of the following activities is part of the service level management
(SLM) process?
a) Designing the configuration management system from a business
perspective
b) Creating technology metrics to align with customer needs
c) Monitoring service performance against service level agreements (SLAs)
d) Training service desk staff how to deal with customer complaints about
service
AXELOS Limited 2012

Page 7 of 11
Version 5.1 (Live)
27. Which one of the following BEST summarizes the purpose of event management?
a) The ability to detect events, make sense of them and determine the appropriate
control action
b) The ability to detect events, restore normal service as soon as possible and
minimize the adverse impact on business operations
c) The ability to monitor and control the activities of technical staff
d) The ability to report on the successful delivery of services by checking the
uptime of infrastructure devices
28. Which one of the following should a service catalogue contain?

a) The version information of all software
b) The organizational structure of the company
c) Asset information
d) Details of all operational services
29. What does "Warranty of a service" mean?

a) The service is fit for purpose
b) There will be no failures in applications and infrastructure associated with the
service
c) All service-related problems are fixed free of charge for a certain period of time
d) Customers are assured of certain levels of availability, capacity, continuity and
security
30. Which is the first activity of the continual service improvement (CSI) approach?
a) Understand the business vision and objectives
b) Carry out a baseline assessment to understand the current situation
c) Agree on priorities for improvement
d) Create and verify a plan
31. Which one of the following is a benefit of using an incident model?

a) It will make problems easier to identify and diagnose
b) It means known incident types never recur
c) It provides pre-defined steps for handling particular types of incidents
d) It ensures all incidents are easy to solve
AXELOS Limited 2012
Page 8 of 11
Version 5.1 (Live)
32. Which one of the following is the CORRECT sequence of activities for handling an
incident?
a) identification, logging, categorization, prioritization, initial diagnosis, escalation,
investigation and diagnosis, resolution and recovery, closure
b) prioritization, identification, logging, categorization, initial diagnosis, escalation,
investigation and diagnosis, resolution and recovery, closure
c) identification, logging, initial diagnosis, categorization, prioritization, escalation,
resolution and recovery, investigation and diagnosis, closure
d) identification, initial diagnosis, investigation, logging, categorization, escalation,
prioritization, resolution and recovery, closure
33. Which service lifecycle stage ensures that measurement methods will provide the
required metrics for new or changed services?
a) Service design
b) Service operation
c) Service strategy
d) Service delivery
34. Which of the following processes are concerned with managing risks to services?
1. IT service continuity management
2. Information security management
3. Service catalogue management
a) All of the above
b) 1 and 3 only
c) 2 and 3 only
d) 1 and 2 only
35. Which one of the following is NOT a type of metric described in continual service
improvement (CSI)?
a) Process metrics
b) Service metrics
c) Personnel metrics
d) Technology metrics
AXELOS Limited 2012

Page 9 of 11
Version 5.1 (Live)
36. Which statement about the relationship between the configuration management
system (CMS) and the service knowledge management system (SKMS) is
CORRECT?
a) The SKMS is part of the CMS
b) The CMS is part of the SKMS
c) The CMS and SKMS are the same thing
d) There is no relationship between the CMS and the SKMS
37. What is the role of the emergency change advisory board (ECAB)?
a) To assist the change manager in ensuring that no urgent changes are made
during particularly volatile business periods
b) To assist the change manager by implementing emergency changes
c) To assist the change manager in evaluating emergency changes and to decide
whether they should be authorized
d) To assist the change manager in speeding up the emergency change process so
that no unacceptable delays occur
38. Which of the following statements about the service desk is/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 should be the owner of the problem management process
a) 2 only
b) 1 only
c) Both of the above
d) Neither of the above
39. Which one of the following is the CORRECT list of the four Ps of service design?
a) Planning, products, position, processes
b) Planning, perspective, position, people
c) Perspective, partners, problems, people
d) People, partners, products, processes
AXELOS Limited 2012

Page 10 of 11
Version 5.1 (Live)
40. Which one of the following represents the BEST course of action to take when a
problem workaround is found?
a) The problem record is closed
b) The problem record remains open and details of the workaround are
documented within it
c) The problem record remains open and details of the workaround are
documented on all related incident records
d) The problem record is closed and details of the workaround are documented in a
request for change(RFC)
AXELOS Limited 2012

Page 11 of 11
Version 5.1 (Live)
k
an
bl
left
lly
na
nt
en
tio
si
pa
ge
i
is
Th
484

Sample Paper B, version 5.1
Multiple Choice
Instructions
1.
2.
3.
4.
All 40 questions should be attempted.

All answers are to be marked on the answer grid provided.
You have 60 minutes to complete this paper.
You must achieve 26 or more out of a possible 40 marks (65%) to pass this examination.
AXELOS Limited 2012

ITIL Foundation Examination SampleB v5.1.
Page 1 of 11
Version 5.1 (Live)
Input from which processes could be considered by service level management when
negotiating service level agreements (SLA)?
a)
All other ITIL processes
b)
Capacity management and availability management only
c)
Incident management and problem management only
d)
Change management and release and deployment management only
Which one of the following statements about a standard change is INCORRECT?

a)
They are pre-authorized by change management
b)
They follow a procedure or work instruction
c)
They are low risk
d)
They must be implemented as soon as possible
Which of the following statements about the service desk are CORRECT?
1. It provides a single point of contact between the service provider and users
2. It manages incidents and service requests
3. It is a service management process
4. Service desk staff try to restore service as quickly as possible
a)
All of the above
b)
1, 2, and 4 only
c)
2 and 4 only
d)
2 and 3 only
Which of the following statements about functions are CORRECT?

1. They may include tools
2. They are groups that use resources to carry out one or more activities
3. One person or group may perform multiple functions
4. They are more costly to implement compared to processes
a)
1, 2 and 3 only
b)
1, 2 and 4 only
c)
All of the above
d)
None of the above
AXELOS Limited 2012

Page 2 of 11
Version 5.1 (Live)
Which one of the following is the BEST description of the activities carried out by
facilities management?
a)
The management of IT services that are viewed as "utilities", such as printers

or network access
b)
Advice and guidance to IT operations on methodology and tools for managing

IT services
c)
Management of the physical IT environment such as a data centre or computer

room
d)
The procurement and maintenance of tools that are used by IT operations staff
to maintain the infrastructure
Which process would assist with the identification and resolution of any incidents and
problems associated with service or component performance?
a)
Capacity management
b)
Supplier management
c)
Technology management
d)
Change management
Which one of the following statements about the known error database (KEDB) is
MOST correct?
a)
The KEDB is the same database as the service knowledge management

system (SKMS)
b)
The KEDB should be used during the incident diagnosis phase to try to speed
up the resolution process
c)
Care should be taken to avoid duplication of records in the KEDB. This can be
done by giving access to as many technicians as possible to create new
records
d)
Access to the KEDB should be limited to the service desk
Which of the following statements about key performance indicators (KPIs) and
metrics are CORRECT?
1. Service metrics measure the end-to-end service
2. Each KPI should relate to a critical success factor
3. Metrics can be used to identify improvement opportunities
4. KPIs can be both qualitative and quantitative
a)
1 only
b)
2 and 3 only
c)
1, 2 and 4 only
d)
All of the above
AXELOS Limited 2012

Page 3 of 11
Version 5.1 (Live)
10
11
12
Which one of the following maintains relationships between all service components?
a)
The capacity plan
b)
The definitive media library
c)
The configuration management system
d)
A service level agreement
Should a customer's request for a new service ALWAYS be fulfilled?

a)
Yes if they are an external customer as they are paying for the service
b)
No if they are an internal customer as they are not always paying for the
service
c)
No it is the responsibility of the service provider to carry out due diligence

before requests are fulfilled
d)
Yes the service provider should ensure that all requests for new services are
fulfilled
Which of the following statements is/are CORRECT?

1. Problem management can support the service desk by providing known errors to
speed up incident resolution
2. Problem management is the only source of information to service level
management about the impact of changes
a)
1 only
b)
2 only
c)
Both of the above
d)
Neither of the above
A failure has occurred on a system and is detected by a monitoring tool. This system
supports a live IT service. When should an incident be raised?
a)
Only when users notice the failure
b)
An incident should not be raised if the technicians have seen this before and
have a workaround
c)
Only if the failure results in a service level being breached
d)
Immediately, to limit or prevent impact on users
AXELOS Limited 2012

Page 4 of 11
Version 5.1 (Live)
13
14
15
16
Which of the following could be considered stakeholders in a service management

project?
1. Users
2. Customers
3. Suppliers
4. Functions
a)
1 and 2 only
b)
3 and 4 only
c)
2 and 4 only
d)
All of the above
Which of the following activities does service asset and configuration management
ensure are performed?
1. Configuration items (CIs) are identified
2. CIs are baselined
3. Changes to CIs are controlled
a)
All of the above
b)
1 and 2 only
c)
1 and 3 only
d)
2 and 3 only
Which of the following aspects of service design should be considered when

designing a service solution?
1. Measurement methods and metrics
2. Management information systems and tools
3. Technology architectures
4. The processes required
a)
1 and 2 only
b)
2 and 3 only
c)
2, 3 and 4 only
d)
All of the above
Which one of the following statements is CORRECT for ALL processes?

a)
They define functions as part of their design
b)
They deliver results to a customer or stakeholder
c)
They are carried out by an external service provider in support of a customer
d)
They are units of organizations responsible for specific outcomes
AXELOS Limited 2012

Page 5 of 11
Version 5.1 (Live)
17
18
19
20
Which process is primarily responsible for packaging, building, testing and deploying
services?
a)
Transition planning and support
b)
Release and deployment management
c)
Service asset and configuration management
d)
Service catalogue management
Which one of the following is the BEST example of a workaround?

a)
A technician installs a script to temporarily divert prints to an alternative printer

until a permanent fix is applied
b)
A technician tries several ways to solve an incident. One of them works,

although they do not know which one
c)
After reporting the incident to the service desk, the user works on alternative
tasks while the problem is identified and resolved
d)
A device works intermittently, allowing the user to continue working at

degraded levels of performance while the technician diagnoses the incident
Which of the following areas can be helped by technology?

1. Request management
2. Service catalogue management
3. Detection and monitoring
4. Design and modelling
a)
1, 2 and 3 only
b)
1, 3 and 4 only
c)
2, 3 and 4 only
d)
All of the above
Which one of the following is the CORRECT list of stages in the Deming Cycle?
a)
Plan, Measure, Monitor, Report
b)
Plan, Check, Re-Act, Implement
c)
Plan, Do, Act, Audit
d)
Plan, Do, Check, Act
AXELOS Limited 2012

Page 6 of 11
Version 5.1 (Live)
21
22
23
24
Which two processes will be involved the MOST in negotiating and agreeing
contracts for the provision of recovery capability to support continuity plans?
a)
Service level management and capacity management
b)
Supplier management and service level management
c)
IT service continuity management and service level management
d)
IT service continuity management and supplier management
Which one of the following is the BEST definition of an incident model?

a)
The template that defines the incident logging form used for reporting incidents
b)
A type of incident involving a standard (or model) type of configuration item (CI)
c)
A set of pre-defined steps to be followed when dealing with a known type of

incident
d)
An incident that is easy to solve
What roles are defined in the RACI model?

a)
Responsible, Accountable, Consulted, Informed
b)
Responsible, Achievable, Consulted, Informed
c)
Realistic, Accountable, Consulted, Informed
d)
Responsible, Accountable, Corrected, Informed
Which stage of the service lifecycle decides what services should be offered and to
whom they will be offered?
a)
Continual service improvement
b)
Service operation
c)
Service design
d)
Service strategy
AXELOS Limited 2012

Page 7 of 11
Version 5.1 (Live)
25
26
27
28
Which of the following does continual service improvement (CSI) provide guidance
on?
1. How to improve process efficiency and effectiveness
2. How to improve services
3. Improvement of all stages of the service lifecycle
a)
1 and 2 only
b)
1 and 3 only
c)
2 and 3 only
d)
All of the above
Which of the following is a type of service level agreement (SLA) described in the
ITIL service design publication?
a)
Priority-based SLA
b)
Technology-based SLA
c)
Location-based SLA
d)
Customer-based SLA
Which one of the following is the BEST definition of an event?

a)
An occurrence where a performance threshold has been exceeded and an

agreed service level has been impacted
b)
A change of state that has significance for the management of an IT service
c)
A known system defect that generates multiple incident reports
d)
A planned meeting of customers and IT staff to announce a new service or

improvement programme
Which one of the following is the MOST appropriate stakeholder to define the value
of a service?
a)
Customers
b)
IT Senior management
c)
Financial management for IT services
d)
Suppliers
AXELOS Limited 2012

Page 8 of 11
Version 5.1 (Live)
29
30
31
32
Which of the following should be treated as an incident?

1. A user is unable to access a service during service hours
2. An authorized IT staff member is unable to access a service during service hours
3. A network component fails but the user is not aware of any disruption to service
4. A user contacts the service desk about the slow performance of an application
a)
All of the above
b)
1 and 4 only
c)
2 and 3 only
d)
None of the above
Which one of the following statements about a change model is CORRECT?

a)
A change model should NOT be used for emergency changes
b)
A change model should be constructed when a significant change is required
c)
A change model defines the steps that should be taken to handle a particular
type of change
d)
Escalation procedures are outside the scope of a change model
The CSI approach uses a number of techniques. Which one of the following
techniques would BEST help a business understand "where are we now?"?
a)
Reviewing critical success factors
b)
Understanding the business vision
c)
Performing a baseline assessment
d)
Checking the CSI register
Which service operation processes are missing from the following list?
1. Incident management
2. Problem management
3. Access management
4. ?
5. ?
a)
Event management and request fulfilment
b)
Event management and service desk
c)
Facilities management and event management
d)
Change management and service level management
AXELOS Limited 2012

Page 9 of 11
Version 5.1 (Live)
33
34
35
36
Which stage of the service lifecycle provides a framework for evaluating service
capabilities and risk profiles before new or changed services are deployed?
a)
Service strategy
b)
Continual service improvement
c)
Service transition
d)
Service operation
Which of the following activities should a service owner undertake?

1. Representing a specific service across the organization
2. Updating the configuration management system (CMS) after a change
3. Helping to identify service improvements
4. Representing a specific service in change advisory board (CAB) meetings
a)
2, 3 and 4 only
b)
All of the above
c)
1, 2 and 3 only
d)
1, 3 and 4 only
Which one of the following is NOT a purpose or objective of availability

management?
a)
To monitor and report on the availability of components
b)
To ensure that service availability matches the agreed needs of the business
c)
To assess the impact of changes on the availability plan
d)
To ensure that business continuity plans are aligned to business objectives
Which one of the following is a CORRECT description of the four Ps of service

design?
a)
A four-step process for the design of effective service management
b)
A definition of the people and products required for successful design
c)
A set of questions that should be asked when reviewing design specifications
d)
Four major areas that need to be considered during service design
AXELOS Limited 2012

Page 10 of 11
Version 5.1 (Live)
37
38
39
40
Which one of the following BEST describes a major problem review?

a)
Facilitated by the problem manager, a major problem review is designed to

apportion blame after a resolution to the problem has been found
b)
A major problem review is run as part of the change advisory board (CAB) by
the change manager. It is conducted after the request for change (RFC) to
resolve the problem has been accepted
c)
A major problem review is facilitated by the service desk manager so that

lessons can be learned after a major problem has been resolved
d)
Facilitated by the problem manager, the review is conducted so that lessons

can be learned from the major problem, and to provide training and awareness
for support staff
Which one of the following statements about supplier management is INCORRECT?

a)
Supplier management negotiates operational level agreements (OLAs)
b)
Supplier management ensures that suppliers meet business expectations
c)
Supplier management maintains information in a supplier and contractor

management information system
d)
Supplier management negotiates external agreements to support the delivery

of services
Which one of the following is a primary purpose of business relationship

management?
a)
Carrying out operational activities to support services
b)
Ensuring all targets within service level agreements are met
c)
Maximizing contract value and operational efficiency of the services that are
delivered
d)
Understanding the customers needs and ensuring they are met
Which one of the following statements is an objective of the design coordination

process?
a)
To ensure that service availability targets are met
b)
To define, document, agree, monitor, measure and review service levels
c)
To provide and maintain a single source of consistent information on all

operational services
d)
To monitor and improve the performance of the service design lifecycle stage
AXELOS Limited 2012

Page 11 of 11
Version 5.1 (Live)
Th
is
pa
ge
i
si
nt
en
tio
na
lly
left
bl
an
ANSWERS
496
ANSWERS
497
ANSWERS
ASSESSMENT - INTRODUCTION [MODULE -1]
Questions No.
Answers
1.
2.
3.
4.
5.
6.
7.
8.
c
c
b
c
c
c
b
c
ASSESSMENT - SERVICE LIFECYCLE [MODULE -2]
Questions No.
Answers
1.
2.
3.
4.
5.
c
a
a
a
c
ASSESSMENT SERVICE STRATEGY [MODULE -3]
Questions No.
Answers
1.
2.
3.
4.
5.
6.
7.
b
b
b
b
a
d
d
498
ANSWERS
ASSESSMENT - SERVICE DESIGN [MODULE -4]
Questions No.
1.
2.

3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Answers
c
a
d
c
c
a
b
d
d
d
a
a,b,d
d
e
ASSESSMENT SERVICE TRANSITION [MODULE -5]
Questions No.
Answers
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
d
a
c
a
d
c
d
d
d
a
a
b
499
ANSWERS
ASSESSMENT - SERVICE OPERATIONS [MODULE -6]
Questions No.
Answers
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
c
d
c
b
d
d
a
c
a
d
d
c
c
c
ASSESSMENT CSI & TECHNOLOGY & ARCHITECTURE [MODULE -7]
Questions No.
Answers
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
d
c
d
d
c
a
d
b
c
c
500

Sample Paper A, version 5.1
Multiple Choice
ANSWERS AND RATIONALE
AXELOS Limited 2012

ITIL Foundation Examination SampleA ANSWERSandRATIONALES v5.1.
Page 1 of 4
Version 5.1 (Live)
Answer Key and Rationale:

Q
Syllabus
Ref
Book
Ref
05-51
ST
4.2.4.3
02-09
SO 1.1.1
06-02
SO
6.5.1.1
05-63
ST 4.3.1
07-02
SD
3.7.4.1
03-12
SD 4.3.4
05-42
SD 4.4.1
02-07
ST 1.1.1
02-02
SS 1.2
10
03-18
ST
4.3.4.3
11
05-45
SD
4.5.4.3
12
03-19
ST
4.3.4.4
13
05-31
SD 4.3.1
14
07-01
SD 6.3.2
15
05-61
ST 4.4.1
16
01-10
SS 2.2.2
17
01-02
SD 1.4
18
05-43
19
03-14
20
08-02
SD
4.7.4.1
SD App
A
SS 7.1
Rationale
A change request is a formal communication seeking an alteration
to one or more configuration items (CIs). Services, SLAs and
computers are examples of CIs. A business strategy is not normally
a CI and would be out of scope for change management.
Each of these are a purpose of service operation except for option
A, undertaking testing to ensure services are designed to meet
business needs. Option A is part of service transition.
IT operations control oversees the execution and monitoring of the
operational activities and events in the IT infrastructure.
Part of SACMs purpose is to maintain accurate information about
assets, including the relationship between assets.
RACI is a responsibility model used by ITIL to help define roles and
responsibilities.
A is the OLA, B is the definition of an SLA, C doesnt correspond to
an ITIL definition, D involves a third party and is a contract.
A is a supporting element of availability management, not a main
purpose. B relates to service level management. Availability
management does not offer guarantees as identified in C. D is the
main purpose of availability management: - to ensure that the level
of availability delivered in all IT services meets the agreed
availability needs of the business.
All three are in scope for service transition as all three involve major
change.
Service optimization is the correct answer
A: a CMS can contain corporate data about users / customers such
as location or department. B and C: there may be more than one
CMDB but they will be part of a single CMS. D is correct as a CMS
still helps to control and report on the infrastructure when IT services
are outsourced.
Book answer...business, service and component capacity
management are the three sub-processes
The DML contains master copies of all controlled software in an
organization along with licence documents or information. The
change schedule would not be included.
Service level management has responsibility for negotiating and
agreeing OLAs.
Book answer. A process owner should ensure process
documentation is current and available.
The two correct answers (1 and 2) are included in release and
deployment objectives. Option 3 is addressed by change
management.
Measurability, delivery of specific results, and delivery of results to a
customer or stakeholder are all characteristics of a process.
Option 4 is incorrect, ITIL is not a standard: ISO/IEC 20000 would
be an example of a standard. ITIL is vendor-neutral, nonprescriptive, and provides a best practice framework.
In most cases the policies should be widely available to all
customers and users and referenced in SLAs, OLAs and UCs.
All of the elements identified are included in the service design
package passed to service transition.
1 would be used to support a DML. 2 helps change management. 3
is a release and deployment tool. 4 can help with testing and
validation. They all support service transition.
AXELOS Limited 2012

Page 2 of 4
Version 5.1 (Live)
Syllabus
Ref
21
05-72
Book
Ref
SO 4.4.2
and
4.4.6.4
22
05-82
SO 4.3.1
23
04-02
SS 3.2.3
24
01-04
SS
3.2.1.2
25
01-03
SS 2.1.1
26
05-31
SD
4.3.5.6
27
05-81
SO 4.1.1
28
05-41
SD 4.2.1
29
03-01
SS 2.1.6
30
04-09
CSI 3.1
31
05-71
SO
4.2.4.2
32
05-71
SO 4.2.5
33
04-04
SD 3.1.1
05-43
SD 4.7.2
05-46
SD
4.6.5.2
34
35
04-10
CSI 5.5
36
03-16
ST
4.7.4.3
37
05-51
ST
4.2.5.11
Rationale
Book answer. They are both valid roles for problem management.
Request fulfilment is the process responsible for dealing with service
requests from the users. All requests (B) is too wide a scope for
the process. Change management looks after change requests (C).
Service level management is responsible for D.
D is incorrect; customer preferences drive value perception. C is
incorrect; delivering on customer outcomes is vital. B is incorrect;
the value of a service can be financial but other factors are also
relevant. A is correct; customer perception is a vital element in
defining how much a customer values a service.
D is the correct response. Both internal and external customers
should be provided with the agreed level of service, and with the
same level of customer service.
A service is a means of delivering value to customers. IT needs
capabilities to deliver services. Cost and risk are what IT helps to
manage.
C is correct: monitoring the SLAs and performance against them is a
vital part of the service level management process. A - designing the
CMS is a service asset and configuration management activity. B
technology metrics are likely to be created within capacity
management or other design processes. D training the service
desk is a service desk role.
A - the ability to detect events, make sense of them and determine
the appropriate control action is provided by event management. B
includes some incident management responsibilities. C is a
technical management task. D is likely to be shared between
availability management and service level management.
The service catalogue should contain details of all operational
services.
A is part of the definition of utility. B is unrealistic. C could be
feasible as a warranty statement from another industry but is not the
definition of warranty as used by ITIL. D is a good summary of
warranty as defined by ITIL.
The improvement approach begins with embracing the vision by
understanding the high-level business objectives.
Incident models are designed to provide reusable steps that can be
used to restore service after known incident types.
The correct order is given in the diagram in the incident
management process, and in the subsections of 4.2.5.
Measurements and metrics should be included in the design for a
new or changed service.
IT service continuity management carries out risk assessment as
part of defining the requirements and strategy. Information security
also needs to analyse security risks before taking action to mitigate
them. Service catalogue management does not carry out these
assessments.
Personnel metrics are not one of the three types of metrics
described in CSI
A is the wrong way round. C is incorrect as the SKMS contains more
information than the CMS. D is incorrect as the CMS is part of the
SKMS.
The emergency change advisory board (ECAB) provides assistance
in the authorization of emergency changes.
AXELOS Limited 2012

Page 3 of 4
Version 5.1 (Live)
Syllabus
Ref
Book
Ref
38
06-01
SO 6.3
39
04-03
SD 3.1.5
40
05-72
SO
4.4.5.6
Rationale
The service desk should be the single point of contact for IT users
on a day-by-day basis. The service desk manager may also be the
incident management process owner but would not normally be the
owner of problem management.
Book answer: people, processes, products (services, technology
and tools) and partners (suppliers, manufacturers and vendors).
A is incorrect; the problem record must remain open as it hasn't yet
been resolved. B is correct to document the workaround on the
problem record, not on each Incident record [C], nor on an RFC [D].
AXELOS Limited 2012

Page 4 of 4
Version 5.1 (Live)

Sample Paper B, version 5.1
Multiple Choice
ANSWERS AND RATIONALE
AXELOS Limited 2012

ITIL Foundation Examination SampleB ANSWERSandRATIONALES v5.1.
Page 1 of 3
Version 5.1 (Live)
Answer Key and Rationale:

Q
Syllabus
Ref
05-31
05-51
06-01
01-09
06-02
SO 6.5.1
05-45
SD 4.5.2
03-32
SO
4.4.7.2
04-10
CSI
4.1.12
5.5
03-18
ST
4.3.4.3
10
01-04
SS
3.2.1.2
11
05-72
SO
4.4.6.4
12
05-71
SO 4.2.5
13
01-08
SS 2.1.5
14
05-63
ST 4.3.2
15
04-04
SD 3.1.1
16
01-10
SS 2.2.2
17
05-61
ST 4.4.2
18
03-30
SO
4.4.5.6
19
20
D
D
08-02
03-42
SS 7.1
CSI 3.8
21
05-46
SD 4.6.1
Version 5.1 (Live)
Book
Ref
SD
4.3.5.2
ST
4.2.4.3
SO 6.3.2
SS
2.2.3.1
Rationale
Representatives of all of the other processes need to be consulted
for their opinion on what targets can be realistically achieved.
Standard changes would not normally need to be implemented as
soon as was possible, whereas emergency changes would.
The service desk is a function and not a process.
Functions are not described as being more costly than processes
and this would depend on the function or process being considered.
Facilities management refers to the management of the physical IT
environment, typically a data centre or computer rooms.
Performance issues are within the scope of capacity management.
A The KEDB is part of the SKMS, NOT the same thing. B is
correct. C Duplication should be avoided but by RESTRICTING
access. D Yes, the service desk should use it but they are NOT
the only ones.
Each statement is a summary of the book content.
The configuration management system (CMS) is responsible via its
various data sources (CMDBs, etc) for maintaining these
relationships.
The service provider should ensure due diligence is carried out
against the customer's requirements, irrespective of whether they
are internal or external customers.
Problem management is the source of known errors but change and
service asset and configuration management are likely to be other
sources of information about the impact of changes.
A There do not need to be discernable impacts to the user for an
incident to be raised. B Even if a workaround is available it needs
to be recorded to measure any on-going impact of the incident. C All incidents must be recorded. D Correct, in order to prevent loss
of service or to restore service as soon as possible.
D is the correct response. Stakeholders can be both internal and
external entities. An example of a function as a stakeholder could be
the service desk, technical management or application management
functions.
All activities are part of the scope of service asset and configuration
management.
All of these items are aspects of service design.
A Process design would involve allocation of activities to functions
but not their definition. B Correct processes deliver results or
they would not be worthwhile. C Not ALL processes are carried
out by external providers. D Is a description of a function.
All are activities performed by release and deployment
management.
A is a good example of a workaround which is not a permanent
solution but which overcomes the original incident. B is a lucky
incident resolution and unlikely to be repeatable. C does not allow
the user to continue with their original task. D is an incident under
investigation.
All four areas can be assisted by technology.
The four key stages of the cycle are Plan, Do, Check and Act.
ITSC provides the subject matter expertise and supplier
management provides the contract negotiation and selection
process. SLM also has a role in underpinning contracts but is not as
significant in this respect as the other two processes.
AXELOS Limited 2012

Page 2 of 3
Syllabus
Ref
Book
Ref
SO
4.2.4.2
SD
3.7.4.1
22
05-71
23
07-02
24
02-03
SS 1.1.1
25
02-11
CSI
1.1.1
26
05-31
SD
4.3.5.1
27
03-24
SO 4.1
28
04-02
SS 3.2.3
29
03-26
SO 4.2
30
05-51
ST
4.2.4.5
31
04-09
CSI
3.1.1
32
05-81
05-82
SO 4.1.1
4.3.1
33
02-07
ST 1.1.1
34
07-01
SD 6.3.1
35
05-42
SD 4.4.1
4.4.2
36
04-03
SD 3.1.5
37
05-72
SO
4.4.5.10
38
05-44
SD 4.8.1
39
05-23
SS 4.5.1
40
05-47
SD 4.1.1
Rationale
C matches the description of an incident model.
Roles are Responsible, Accountable, Consulted, Informed.
Deciding what services should be offered and to whom is an integral
part of service strategy.
1. CSI looks for ways to improve process effectiveness and
efficiency, as well as cost effectiveness.
2. CSI identifies and implements improvements to IT services
3. CSI improvement activities support each lifecycle stage: service
strategy, service design, service transition, service operation, and
CSI itself.
Priority-based, technology-based and location-based SLAs are not
discussed in service design.
A and C may cause an event to be generated. D is a meeting. B
closely matches the definition of an event in service operation.
Value is viewed as the level to which the service meets customer's
expectations and therefore they make the ultimate decision on
whether the service will drive value.
An incident is an unplanned interruption to an IT service or
reduction in the quality of an IT service or a failure of a CI that has
not yet impacted an IT service. The inability to access an IT
service as agreed is an unplanned interruption from the users
perspective.
A A change model can be used for emergency changes. B
Change models would not routinely be created when significant
changes are made. C is correct. D Escalation procedures can be
included in a change model.
Understanding "where are we now" requires a business to create a
baseline.
All of the service operation processes are covered by the syllabus.
The correct answer is A, B is a process and a function, C is a
function and a process, D are processes in service transition and
service design.
Service transition is responsible for this as part of the deployment of
new services.
1, 3 and 4 are all responsibilities of the service owner role. Option 2
is the responsibility of the configuration librarian/administrator.
D is the responsibility of IT service continuity management.
1 The four Ps are not a process. 2 Has some merit but only
addresses two of the four areas. 3 The four Ps are not a checklist
or set of questions.
D is the book answer. A is the right role but it is not about
apportioning blame. B is incorrect. C is plausible but is facilitated by
the wrong role.
All are objectives of the supplier management process, except A
which is undertaken by service level management.
To identify customer needs and ensure that the service provider is
able to meet these needs...
D is the correct answer. C is the purpose of service catalogue
management. B is an objective of service level management. A is an
objective of availability management.
AXELOS Limited 2012

Page 3 of 3
Version 5.1 (Live)
BUILDING
BETTER
FUTURES
Website: www.knowledgewoods.com
e-mail: info@knowledgewoods.com
Toll Free: 1800 103 6033 | Landline: +91 120 4060100
Mon - Fri :- 9:00 AM - 6:00 PM

ITIL 2011 Foundation Handbook

Uploaded by

Document Information

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

ITIL 2011 Foundation Handbook

Uploaded by

Copyright:

ITIL 2011

PEOPLECERT Accredited Training Organization (ATO), PMI Global Registered

KnowledgeWoods ITIL 2011 Foundation HandBook

Service Life Cycle..................................................................... 49 - 84

Service Strategy....................................................................... 89 - 129

Service Design......................................................................... 135 - 230

Service Transition.................................................................... 237 - 311

Service Operation.................................................................... 319 - 413

Continual Service Improvement.............................................. 421 - 444

Activities.................................................................................. 449- 458

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

What is IT? The meaning of IT changes with Context

IT as Component: IT is a collection of systems, applications

IT as Organization: IT is an organization with its own set

IT as Service: IT is a category of services utilized by business.

IT as Asset: IT is a category of business assets that provide

What is IT? The meaning of IT changes with Context

IT is a collection of systems, applications and infrastructures which are components

IT is an organization with its own set of capabilities and resources. IT organizations

ITIL is a registered trademark of AXELOS Limited.

IT is a category of services utilized by business. The services are typically IT applications

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

Definition of Best Practice & ITIL

Definition of Best Practice & ITIL

ITIL is a registered trademark of AXELOS Limited.

Deliver value for customers through services.

vi. Manage knowledge.

ITIL is a registered trademark of AXELOS Limited.

Sources and Enabler of Best Practice

Training and education

Knowledge fit for business

Sources and Enabler of Best Practice

Proprietary knowledge is deeply embedded in organizations and therefore difficult to

ITIL is a registered trademark of AXELOS Limited.

Owners of proprietary knowledge expect to be rewarded for their longterm investments.

The knowledge of public frameworks is more likely to be widely distributed among a

Ignoring public frameworks and standards can needlessly place an organization at a

ITIL is a registered trademark of AXELOS Limited.

Why is ITIL successful?

Why is ITIL successful?

Vendor-neutral ITIL service management practices are applicable in any IT organization

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

Service Provider and IT Service Provider

Service Provider and IT Service Provider

ITIL is a registered trademark of AXELOS Limited.

Types of Service Providers

Type II (Shared Services Unit)

Type III (External Service Provider)

Types of Service Providers

ITIL is a registered trademark of AXELOS Limited.

ITIL is a registered trademark of AXELOS Limited.

Type I Internal Service Provider

Type I Internal Service Provider

ITIL is a registered trademark of AXELOS Limited.

Type II Shared Services Unit

Type II Shared Services Unit

ITIL is a registered trademark of AXELOS Limited.