Mate ITILv3 PDF

ITIL V3 Foundation for
IT Service Management
HF421S B.01
Student guide
ITIL V3 Foundation for
IT Service Management
HF421S B.01
Student guide
Use of this material to deliver training without prior written permission from HP is prohibited.
 Copyright 2007 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. The only warranties for HP
products and services are set forth in the express warranty statements accompanying such products and
services. Nothing herein should be construed as constituting an additional warranty. HP shall not be
liable for technical or editorial errors or omissions contained herein.
This is an HP copyrighted work that may not be reproduced without the written permission of HP. You
may not use these materials to deliver training to any person outside of your organization without the
written permission of HP.
All the content within this HP accredited training course is based on OGC ITIL ® materials, unless
otherwise stated.
HP are authorized by OGC to re-use the OGC-owned IPR (including Crown copyright material, logos
and trade marks) within the scope of HP's accredited training activities.
ITIL ® “ITIL ® is a Registered Trade Mark of the Office of Government
Commerce in the United Kingdom and other countries”
IT Infrastructure Library ® “IT Infrastructure Library ® is a Registered Trade Mark of the Office of
Government Commerce in the United Kingdom and other countries”
The Best Practice logo TM "The Best Practice logo TM is a Trade Mark of the Office of
Government Commerce"
The Swirl logo TM “The Swirl logo is a Trade Mark of the Office of Government
Commerce”
Export Compliance Agreement
Export Requirements. You may not export or re-export products subject to this agreement in violation of
any applicable laws or regulations.
Without limiting the generality of the foregoing, products subject to this agreement may not be
exported, re-exported, otherwise transferred to or within (or to a national or resident of) countries under
U.S. economic embargo and/or sanction including the following countries:
Cuba, Iran, North Korea, Sudan and Syria.
This list is subject to change.
In addition, products subject to this agreement may not be exported, re-exported, or otherwise
transferred to persons or entities listed on the U.S. Department of Commerce Denied Persons List; U.S.
Department of Commerce Entity List (15 CFR 744, Supplement 4); U.S. Treasury Department
Designated/Blocked Nationals exclusion list; or U.S. State Department Debarred Parties List; or to
parties directly or indirectly involved in the development or production of nuclear, chemical, or
biological weapons, missiles, rocket systems, or unmanned air vehicles as specified in the U.S. Export
Administration Regulations (15 CFR 744); or to parties directly or indirectly involved in the financing,
commission or support of terrorist activities.
By accepting this agreement you confirm that you are not located in (or a national or resident of) any
country under U.S. embargo or sanction; not identified on any U.S. Department of Commerce Denied
Persons List, Entity List, US State Department Debarred Parties List or Treasury Department Designated
Nationals exclusion list; not directly or indirectly involved in the development or production of nuclear,
chemical, biological weapons, missiles, rocket systems, or unmanned air vehicles as specified in the
U.S. Export Administration Regulations (15 CFR 744), and not directly or indirectly involved in the
financing, commission or support of terrorist activities.
Printed in the US
ITIL V3 Foundation for IT Service Management
Student guide
August 2007
Contents
Course Introductions
Course introductions ........................................................................................ 1
Health and safety ............................................................................................ 2
Logistics and refreshments................................................................................. 3
Course format ................................................................................................. 4
Agenda.......................................................................................................... 5
Timing............................................................................................................ 6
Exam format and details................................................................................... 7
Personal introductions....................................................................................... 8
Module 1 — Service Management as a Practice

What is a service?........................................................................................... 2
What is Service Management? ......................................................................... 5
IT Infrastructure Library (ITIL) .............................................................................. 7
Best Practice and Good Practice ................................................................. 7
Functions, Roles and Processes (1 of 2) ............................................................... 9
Functions, Roles and Processes (2 of 2).............................................................. 11
A Process Model ............................................................................................12
Characteristics of processes .............................................................................15
How to recognize a process ......................................................................16
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. i

Module 2 — The Service Lifecycle

Service Lifecycle .............................................................................................. 2
Service Strategy .............................................................................................. 6
Service Design (SD) ......................................................................................... 9
Scope of SD ..................................................................................................12
Value to business of SD ...................................................................................14
Service Transition (ST) .....................................................................................16
Scope of ST (1 of 2) ....................................................................................... 19
Scope of ST (2 of 2)....................................................................................... 20
Value to business of ST................................................................................... 22
Service Operation (SO) .................................................................................. 24
Scope of SO ................................................................................................. 26
Value to business of SO.................................................................................. 28
Achieving balance (Conflicting Motives) ........................................................... 29
Internal IT view versus external business view .............................................. 29
Stability versus responsiveness .................................................................. 30
Quality of Service versus Cost of Service.....................................................31
Reactive versus proactive.......................................................................... 32
The value of communication............................................................................ 34
Continual Service Improvement (CSI) ................................................................ 36
Scope of CSI................................................................................................. 39
Value to business of CSI ..................................................................................41
Interfaces with or Guidance, Methodologies, Legislation and Standards............... 43
Module 3 — Key Principles, Models and Concepts

Service Provider .............................................................................................. 2
RACI Model.................................................................................................... 3
Example RACI Model ................................................................................ 5
Process Owner ................................................................................................ 6
Service Owner ................................................................................................ 8
Suppliers and Contracts ................................................................................. 10
Service Portfolio..............................................................................................12
Service Catalog .............................................................................................15
Risk Management and Analysis........................................................................17
Plan, Do, Check, Act Model.............................................................................18
Governance.................................................................................................. 20
Corporate Governance ............................................................................ 20
IT Governance ........................................................................................ 21
Compliance............................................................................................ 21
ii © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Contents
Module 4 — Concepts, Processes, Roles and Functions

Service Operation ........................................................................................... 2
Event Management ................................................................................... 3
Event Management — Objectives ............................................................... 4
Event Management — Basic concepts ......................................................... 5
Event Management — Logging and Filtering ................................................ 6
Event Management — Managing Exceptions ............................................... 7
Event Management — Information and Warnings ......................................... 9
Event Management — Roles ...................................................................... 11
Incident Management ...............................................................................13
Incident Management — Objective ............................................................14
Incident Management — Scope .................................................................15
Incident Management — Business value......................................................16
Incident Management — Basic concepts .....................................................17
Incident Management — Activities ............................................................ 19
Incident Management — Interfaces ........................................................... 24
Incident Management — Key metrics ......................................................... 26
Incident Management — Roles ................................................................. 27
Incident Management — Challenges ......................................................... 29
Request Fulfillment ................................................................................... 30
Request Fulfillment — Objectives ................................................................31
Request Fulfillment — Basic concepts ......................................................... 32
Self Help................................................................................................ 34
Request Fulfillment — Roles....................................................................... 35
Problem Management ............................................................................. 36
Problem Management — Objectives ......................................................... 37
Problem Management — Basic concepts (1 of 2) ........................................ 38
Problem Management — Basic concepts (2 of 2) ........................................ 40
Problem Management — Roles ................................................................. 42
Access Management ............................................................................... 44
Access Management — Objectives ........................................................... 45
Access Management — Basic concepts ..................................................... 46
Access Management — Roles................................................................... 48
Service Operation functions...................................................................... 50
Service Desk........................................................................................... 52
Local Service Desk .................................................................................. 57
Centralized Service Desk.......................................................................... 58
Virtual Service Desk................................................................................. 59
Service Desk objectives ............................................................................ 60
Service Desk staffing ............................................................................... 62
Service Desk metrics ................................................................................ 65
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. iii

Technical Management............................................................................ 67
Technical Management organization ......................................................... 68
Technical Management — Objectives........................................................ 70
Technical Management — Roles ............................................................... 71
IT Operations Management...................................................................... 73
IT Operations Management — Objectives.................................................. 75
IT Operations Management — Roles ......................................................... 76
Application Management......................................................................... 78
Application Management — Objectives..................................................... 79
Application Management — Roles ............................................................ 80
Continual Service Improvement (CSI) ................................................................ 82
CSI and Organizational Change............................................................... 83
Continual Service Improvement Model ....................................................... 85
What is Service Measurement?................................................................. 87
Why do we measure? ............................................................................. 88
Types of metrics ...................................................................................... 89
The 7 Step Improvement Process Purpose ....................................................91
The 7 Step Improvement Process ............................................................... 92
Role of the Continual Service Improvement Manager ................................. 103
Role of the Service Manager .................................................................. 105
Service Transition......................................................................................... 108
Service Transition V Model ..................................................................... 109
Configuration Item (CI)............................................................................ 110
Configuration Management System (CMS) .................................................111
Knowledge Management (KM) ................................................................ 112
Data, Information, Knowledge and Wisdom (DIKW) .................................. 113
Service Knowledge Management System (SKMS) ....................................... 115
Definitive Media Library (DML)................................................................. 116
DML and CMDB relationship ................................................................... 118
Service Transition processes..................................................................... 119
Change Management.............................................................................120
Change — Objectives and purpose ......................................................... 121
Change — Scope ..................................................................................122
Change — Value to the business..............................................................124
Change — Basic concepts (1 of 2) ...........................................................126
Change — Basic concepts (2 of 2)...........................................................129
Change — Activities...............................................................................130
7 Rs of Change Management..................................................................135
Change — Roles (1 of 2) ........................................................................136
Change — Roles (2 of 2) ........................................................................138
Change — Interfaces..............................................................................140
Change — Inputs................................................................................... 141
Change — Outputs ................................................................................142
Change — Process interfaces ..................................................................143
Change — Key metrics ...........................................................................145
Change — Challenges ...........................................................................147
iv © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01
Contents
Service Asset and Configuration Management (SACM)...............................149

SACM — Objectives ..............................................................................150
SACM — Basic concepts ........................................................................ 151
SACM Configuration Items categories.......................................................152
SACM logical model ..............................................................................154
SACM — Roles ......................................................................................156
Release and Deployment Management .....................................................159
Release and Deployment — Objectives.....................................................160
Release and Deployment — Basic concepts (1 of 3) ...................................162
Release and Deployment — Roles (1 of 2) ................................................. 171
Release and Deployment — Roles (2 of 2).................................................172
Service Design .............................................................................................173
Scope of Service Design — “The Four Ps” ................................................. 174
Service Design Package (SDP) .................................................................177
5 major aspects of Service Design ...........................................................179
Service Catalog Management ................................................................. 181
Service Catalog Management — Objectives .............................................182
Service Catalog Management — Basic concepts .......................................183
Service Catalog Management — Roles.....................................................185
Service Level Management ......................................................................186
Service Level Management — Objectives ..................................................187
Service Level Management — Scope ........................................................188
Service Level Management — Business value.............................................189
Service Level Management — Basic concepts ............................................190
Service Level Management — Activities ....................................................192
Service Level Management — Key metrics .................................................195
Service Level Management — Roles .........................................................196
Service Level Management — Challenges .................................................198
Service Level Management — Interfaces .................................................. 200
Availability Management ....................................................................... 202
Availability Management — Objectives ................................................... 203
Availability Management — Basic concepts (1 of 6).................................. 205
Availability Management — Basic concepts (2 of 6) ................................. 207
Availability Management — Basic concepts (3 of 6) ................................. 208
Availability Management — Basic concepts (4 of 6) ..................................210
Availability Management — Basic concepts (5 of 6) .................................. 211
Availability Management — Basic concepts (6 of 6) .................................. 213
Availability Management — Roles ........................................................... 214
Information Security Management ............................................................ 215
Information Security Management — Objectives ........................................ 216
Information Security Management — Basic concepts .................................. 217
Information Security Management — Roles .............................................. 220
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. v

Supplier Management ........................................................................... 222

Supplier Management — Objectives ....................................................... 223
Supplier Management — Supplier and Contracts Database (SCD) .............. 224
Supplier Management — Roles............................................................... 226
Capacity Management .......................................................................... 227
Capacity Management — Objectives ...................................................... 228
Capacity Management — Basic concepts ................................................ 229
Capacity Management — Roles.............................................................. 233
IT Service Continuity Management (ITSCM) .............................................. 235
ITSCM — Objectives ............................................................................. 236
ITSCM — Key concepts (1 of 2) .............................................................. 238
ITSM — Key concepts (2 of 2) ................................................................ 240
ITSCM — Roles..................................................................................... 243
Service Strategy .......................................................................................... 245
Utility and Warranty.............................................................................. 246
Value creation .......................................................................................247
Service Provider .................................................................................... 249
Delivery Model options .......................................................................... 254
Service Model ...................................................................................... 255
Main activities ...................................................................................... 257
Service Portfolio Management ................................................................ 258
Service Portfolio Management — Objectives ............................................ 259
Service Portfolio Management — Basic concepts ...................................... 260
Service Portfolio Management — Activities ............................................... 264
Service Portfolio Management — Roles .................................................... 265
Demand Management ........................................................................... 269
Demand Management— Objectives and business value ............................ 270
Demand Management— Basic concepts (1 of 3)........................................271
Demand Management— Basic concepts (2 of 3) ...................................... 272
Demand Management— Basic concepts (3 of 3) .......................................274
Demand Management — Roles ...............................................................276
Financial Management .......................................................................... 277
Financial Management — Objectives and business value........................... 278
Financial Management — Basic concepts (1 of 2) ..................................... 279
Financial Management — Basic concepts (2 of 2)..................................... 282
Financial Management — Roles.............................................................. 284
vi © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Contents
Module 5 — Service Management Technology and Architecture

Service Management Technology and Architecture .............................................. 2
Scope ............................................................................................................ 3
Service Design tools......................................................................................... 4
Service Management tools — Scope.................................................................. 6
Self Help.................................................................................................. 6
Workflow or Process Engine ....................................................................... 6
Discovery/Deployment/Licensing Technology ............................................... 7
Remote Control ......................................................................................... 7
Diagnostic Utilities..................................................................................... 7
Reporting ................................................................................................. 7
Dashboards.............................................................................................. 8
Integration with Business Service Management ............................................. 8
Service Management tools — Benefits................................................................ 9
Automation processes .................................................................................... 10
Event Management tools — Scope ................................................................... 11
Event Management tools — Benefits .................................................................13
Benefits...................................................................................................13
Knowledge Management tools — Scope ...........................................................14
Knowledge Management tools — Benefits .........................................................16
Configuration Management System — Scope.....................................................18
Configuration Management System — Benefits.................................................. 20
Benefits.................................................................................................. 20
Tool selection ................................................................................................ 21
Module 6 — ITIL Qualification Scheme

ITIL v3 Qualification Scheme ............................................................................. 2
Relationship between v2 and v3 ....................................................................... 4
Module 7 — Documentation
Glossary
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. vii

viii © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Course introductions
• Health and safety
• Logistics and refreshments
• Course format, agenda and
timings
• Exam format and details
• Personal introductions
• Expectations?
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. Intro – 1

Health and safety
Health and safety

• Fire alarms
• Fire exits
• Assembly points
• Security
Intro – 2 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Logistics and refreshments
Logistics and refreshments

• Rest-rooms
• Location for meals and
refreshments
• Timing of breaks
• Use of telephones and laptops
etc

Course format
Course format
• Instructor-led teaching
modules
• Assignments
• Mock examination questions
• Mock examination and
review
• Short video sessions

Agenda
Agenda
Day 1 Day 3
• Course Introduction • Concepts, Roles and Functions
• Service Management as a (Cont)
Practice – Service Strategy
• Service Lifecycle • Technology and Architecture
• Key Principles, Models and • ITIL® Qualification Scheme
Concepts • Revision and Mock Examination
• Concepts, Roles and Functions
– Service Operation
Day 2
• Concepts, Roles and Functions
(Cont)
– Continual Service Improvement
– Service Transition
– Service Design

Timing
Timing
• Start times
• End times
• Breaks
• Examination
• Time-keeping

Exam format and details
Exam format and details

• Multiple choice
• 40 questions
• 60 minutes
– 15 extra minutes if English
is not your first language
• 65% pass mark
(26 out of 40)

Personal introductions
Personal introductions
• Name
• Organization
• Job Title/Responsibilities
• ITSM experience?
• Expectations?

Service Management as a Practice
Module 1
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1–1

What is a service?
What is a ‘service’?
A ‘service’ is a means of
delivering value to customers by
facilitating outcomes customers
want to achieve without the
ownership of specific costs and
risks
Services are a means of delivering value to customers by facilitating outcomes

customers want to achieve without the ownership of specific costs and risks.
Outcomes are possible from the performance of tasks and are limited by the
presence of certain constraints. Broadly speaking, services facilitate outcomes by
enhancing the performance and by reducing the grip of constraints. The result is an
increase in the possibility of desired outcomes. While some services enhance
performance of tasks, others have a more direct impact. They perform the task itself.
The preceding 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 work 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.
1–2 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Take for example the generalized pattern of a storage system. Storage is useful for
holding, organizing, or securing assets within the context of some activity, task, or
performance. Storage also creates useful conditions such as ease of access, efficient
organization, or security from threats. This simple pattern is inherent in many types of
storage services; each specialized to support a particular type of outcome for
customers.
Store
information
Store
files
Store
Store what? equipment
Storage
service
Store how? Online

database
Portable
devices
Secure
cabinets
© Crown Copyright 2007. Reproduced under licence from OGC.
Generalized patterns and specialized instances

For various reasons, customers seek outcomes but do not wish to have accountability
or ownership of all the associated costs and risks. For example, a business unit
needs a terabyte of secure storage to support its online shopping system. From a
strategic perspective, it wants the staff, equipment, facilities, and infrastructure for a
terabyte of storage, to remain within its span of control. It does not want, however, to
be accountable for all the associated costs and risks, real or nominal, actual or
perceived. Fortunately, there is a group within the business with specialized
knowledge and experience in large-scale storage systems, and the confidence to
control the associated costs and risks. The business unit agrees to pay for the storage
service provided by the group under specific terms and conditions.
The business unit remains responsible for the fulfillment of online purchase orders. It
is not responsible for the operation and maintenance of fault-tolerant configurations
of storage devices, dedicated and redundant power supplies, qualified personnel, or
the security of the building perimeter, administrative expenses, insurance, compliance
with safety regulations, contingency measures, or the optimization problem of idle
capacity for unexpected surges in demand. The design complexity, operational
uncertainties, and technical trade-offs associated with maintaining reliable high-
performance storage systems lead to costs and risks the business unit is simply not
willing to own. The service provider assumes ownership and allocates those costs
and risks to every unit of storage utilized by the business and any other customers of
the storage service.

What is Service Management?
What is Service Management?

• Service Management is a set of specialized organizational
capabilities for providing value to customers in the form of
services
and …
• A set of Functions and Processes for managing Services over

their Lifecycle
Service Management is a set of specialized organizational capabilities for providing

value to customers in the form of services. The capabilities take the form of functions
and processes for managing services over a lifecycle, with specializations in strategy,
design, transition, operation, and continual improvement. The capabilities represent a
service organization’s capacity, competency, and confidence for action. The act of
transforming resources into valuable services is at the core of service management.
Without these capabilities, a service organization is merely a bundle of resources
that by itself has relatively low intrinsic value for customers.
Service Management is also a professional practice supported by an extensive body
of knowledge, experience, and skills. A global community of individuals and
organizations in the public and private sectors fosters its growth and maturity. Formal
schemes exist for the education, training, and certification of practicing organizations
and individuals influence its quality. Industry best practices, academic research, and
formal standards contribute to its intellectual capital and draw from it.

The origins of service management are in traditional service businesses such as

airlines, banks, hotels, and phone companies. Its practice has grown with the
adoption by IT organizations of a service-oriented approach to managing IT
applications, infrastructure, and processes. Solutions to business problems and
support for business models, strategies, and operations are increasingly in the form
of services. The popularity of shared services and outsourcing has contributed to the
increase in the number of organizations who are service providers, including internal
organizational units. This in turn has strengthened the practice of service
management and at the same time imposed greater challenges upon it.

IT Infrastructure Library (ITIL)
IT Infrastructure Library (ITIL)

• Best practice for IT Service Management
– Proven ‘Good practice’ that is in wide industry use
• Provides detail for other industry frameworks and standards.
For example
– COBIT
– ISO/IEC 20000)
• First published by UK Government in late 1980s
• Updated to V2 in 2000/2001
– Improved for international audience
– New types of service delivery
• Updated to V3 in 2007
– Lifecycle model
– Greater focus on strategy and business outcomes
Best Practice and Good Practice

Best Practice provides a set of generic guidelines based on the successful experiences
of a number of organizations. These guidelines are at a high level and do not
answer questions about how they should be applied in specific types of organization
or industry sectors. While best practices are very helpful in defining solutions, they
have to be adapted for specific organizations.
Good practice could be either an application of best practice, or it could be an input
into best practice.
Good Practice as an application of Best Practice

As organizations define specific solutions based on best practice, these are passed
on as a good practice within organizations of a similar nature. For example, a
vendor sells and implements a Service Management tool in several organizations.
After each implementation, they learn more about how Best Practice is applied when
using this tool. These lessons then become a good practice for implementing that
tool.
Another example is that as organizations apply best practice they compare what
they have done – either informally through attending “user group” meetings, or more
formally by doing benchmarks. These solutions then become a good practice for that
specific industry.

Good Practice as in input into Best Practice

In some cases Good Practice comes before Best Practice. For example an
organization has a problem in controlling remote devices. It creates an innovative
way of using Event Management to achieve control.
This solution is very effective and other companies start implementing something
similar. In the next version of ITIL, this Good Practice becomes recognized as a
general guideline that can be applied across several contexts — and thus becomes a
Best Practice.

Functions, Roles and Processes (1 of 2)

• Function
– A team or group of people
and the tools they use to
carry out one or more
processes or activities
• Role
– A set of responsibilities,
activities and authorities
granted to a person or
team
Functions are units of organizations specialized to perform certain types of work and
responsible for specific outcomes. They are self-contained with capabilities and
resources necessary for their performance and outcomes. Capabilities include work
methods internal to the functions. Functions have their own body of knowledge,
which accumulates from experience. They provide structure and stability to
organizations.
Functions are a way of structuring organizations to implement the specialization
principle. Functions typically define roles and the associated authority and
responsibility for a specific performance and outcomes. Coordination between
functions through shared processes is a common pattern in organization design.
Functions tend to optimize their work methods locally to focus on assigned outcomes.
Poor coordination between functions combined with an inward focus leads to
functional silos that hinder alignment and feedback critical to the success of the
organization as a whole. Process models help avoid this problem with functional
hierarchies by improving cross-functional coordination and control. Well-defined
processes can improve productivity within and across functions.

Functions are often mistaken for processes. For example, there are misconceptions
about Capacity Management being a service management process. First, capacity
management is an organizational capability with specialized processes and work
methods. Whether or not it is a function or a process depends entirely on
organization design. It is a mistake to assume that capacity management can only
be a process. It is possible to measure and control capacity and to determine
whether it is adequate for a given purpose. Assuming that is always a process with
discrete countable outcomes can be an error.
A role refers to a set of connected behaviors or actions that are performed by a
person, team or group in a specific context. For example a technical management
department can perform the role of Problem Management when diagnosing the root
cause of Incidents. This same department could also be expected to play several
other roles at different times, for example, they may assess the impact of changes
(Change Management role), manage the performance of devices under their control
(Capacity Management role), etc. The scope of their role and what triggers them to
play that role are defined by the relevant process, and agreed by their line manager.
1 – 10 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01


• Process
– A set of activities
designed to accomplish a
specific objective. A
process takes defined
inputs and turns them into
defined outputs. A
process may include
roles, responsibilities,
tools and management
controls required to
deliver the outputs
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1 – 11

A Process Model
A Process Model
Process Control
Triggers
Process
Including
Process reports
& reviews
Process Enablers
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.”
Processes, once defined, should be documented and controlled; once under control,
they can be repeated and become manageable. Degrees of control over processes
can be defined, and then process measurement and metrics can be built in to the
process to control and improve the process as illustrated in the slide diagram.
The generic process elements show that data enters the process, is processed, is
output and the outcome is measured and reviewed. This very basic description
underpins any process description. A process is always organized around a set of
objectives. The main outputs from the process should be driven by the objectives and
should always include process measurements (metrics), reports and process
improvement.

Each process should be owned by a process owner who should be responsible for
the process and its improvement and for ensuring that a process meets its objectives.
The objectives of any IT process should be defined in measurable terms and should
be expressed in terms of business benefits and underpin business strategy and goals.
Service Design should assist each process owner with the design of processes, in
order to ensure that all processes use standard terms and templates, are consistent
and integrate with each other to provide end-to-end integration across all areas.
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 (because it can be repeated, measured and managed). If the
activities are carried out with a minimum use of resources, the process can also be
considered efficient. Process analysis, results and metrics should be incorporated in
regular management reports and process improvements.
All of these areas should be included within the design of any process. The ITIL books
have been written around “sets of processes” that reflect the stages in the lifecycle of
a service. Working with defined processes has been the foundation of ITIL from its
beginning. By defining what the organization’s activities are, which inputs are
necessary and which outputs will result from the process, it is possible to work in a
more efficient and effective manner. Measuring and steering the activities increases
this effectiveness. Finally, by adding norms to the process, it is possible to add
quality measures to the output.
This approach underpins the ‘plan-do-check-act’ cycle of continual improvement for
any quality-management system. Plan the purpose of the process in such a way that
process actions can be reviewed, assessed or audited for successful achievement
and, improved.
Norms define certain conditions that the results should meet. Defining norms
introduces quality aspects to the process. Even before starting, it is important to think
about what the process outcomes should look like. To discover whether or not
process activities are contributing optimally to the business goal and the objectives of
the process - aligned to business goals, the effectiveness should be measured on a
regular basis. Measuring allows comparison of what has actually been done, with
what the organization set out to do and to identify and implement improvements
within the process.
Each organization should adopt a formalized approach to the design and
implementation of Service Management processes. The objective should not be to
design “perfect processes”, but to design practical and appropriate processes with
“in-built” improvement mechanisms, so that the effectiveness and efficiency of the
processes are improved in the most suitable manner for the organization.
Documentation standards, processes and templates should be used to ensure that the
processes are easily adopted throughout the organization.

The goal for now and in the future is to design processes and support these with
tools that can provide integration between organizations. This has now become
possible because management tools are providing support of open standards, such
as the Distributed Management Task Force (DMTF), that support the exchange of
information based on ITIL concepts, such as Incidents, Problems and Changes with
standard formats and contents. This allows service providers to support efficient and
effective process interfaces with their main suppliers with automated exchange of key
operational information in real time.

Characteristics of processes
Characteristics of processes
Data, information
& knowledge
Process Desired
outcome
Service control & quality
Trigger
Processes are examples of closed-loop systems because they provide change and
transformation towards a goal, and utilize feedback for self-reinforcing and self-
corrective action. It is important to consider the entire process or how one process fits
into another.

How to recognize a process
How to recognize a process

• It is measurable
• It delivers specific results
• Primary results are delivered to customers or stakeholders
• It responds to specific events
Process definitions describe actions, dependencies, and sequence. Processes have

the following characteristics:
Measurable — 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.
Specific results —- The reason a process exists is to deliver a specific result. This
result must be individually identifiable and countable. While we can count
Changes, it is impossible to count how many Service Desks were completed. So
change is a process and Service Desk is not: it is a function.
Customers — Every process delivers its primary results to a customer or
stakeholder. They may be internal or external to the organization but the process
must meet their expectations.
Responds to a specific event —- While a process may be ongoing or iterative, it
should be traceable to a specific trigger.

The Service Lifecycle
Module 2

Service Lifecycle
Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service
Transition
The context of the publications depicted in this diagram is the ITIL Framework as a
source of good practice in service management. ITIL is used by organizations world-
wide to establish and improve capabilities in service management. 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.
The ITIL Library has the following components:
The ITIL Core: Best practice guidance applicable to all types of organizations
who provide services to a business
The ITIL Complementary Guidance: A complementary set of publications with
guidance specific to industry sectors, organization types, operating models, and
technology architectures
The ITIL Web: As well as the paper publications and the qualifications, it will be
provided a unified package of web-based support offerings for ITIL users.
Examples of web material include value added products, process maps,
templates and case studies.

The ITIL Core consists of five publications. Each provides the guidance necessary for
an integrated approach as required by the ISO/IEC 20000 standard specification:
Service Strategy
Service Design
Service Transition
Service Operation
Continual Service Improvement
Each publication addresses capabilities having direct impact on a service provider’s
performance. The structure of the core is in the form of a lifecycle. It is iterative and
multidimensional. It ensures organizations are set up to leverage capabilities in one
area for learning and improvements in others. The core is expected to provide
structure, stability, and strength to service management capabilities with durable
principles, methods, and tools. This serves to protect investments and provide the
necessary basis for measurement, learning, and improvement.
The guidance in ITIL can be adapted for use in various business environments and
organizational strategies. The Complementary Guidance provides flexibility to
implement the Core in a diverse range of environments. Practitioners can select
Complementary Guidance as needed to provide traction for the Core in a given
business context, much like tyres are selected based on the type of automobile,
purpose, and road conditions. This is to increase the durability and portability of
knowledge assets and to protect investments in service management capabilities.
The Service Strategy volume provides guidance on how to design, develop, and
implement service management not only as an organizational capability but as a
strategic asset. Guidance is provided on the principles underpinning the practice of
service management which are useful for developing service management policies,
guidelines, and processes across the ITIL Service Lifecycle. Service Strategy guidance
is useful in the context of Service Design, Service Transition, Service Operation, and
Continual Service Improvement. Topics covered in Service Strategy include the
development of markets, internal and external, service assets, service catalog, and
implementation of strategy through the Service Lifecycle. Financial Management,
Service Portfolio Management, Organizational Development, and Strategic Risks are
among other major topics.
Organizations use the guidance to set objectives and expectations of performance
towards serving customers and market spaces, and to identify, select, and prioritize
opportunities. Service Strategy is about ensuring that organizations are in position to
handle the costs and risks associated with their service portfolios, and are set up not
just for operational effectiveness but for distinctive performance. Decisions made with
respect to Service Strategy have far-reaching consequences including those with
delayed effect.

Organizations already practicing ITIL use this volume to guide a strategic review of
their ITIL based service management capabilities and to improve the alignment
between those capabilities and their business strategies. This volume of ITIL
encourages readers to stop and think about why something is to be done before
thinking of how. Answers to the first type of questions are closer to the customer’s
business. Service Strategy expands the scope of the ITIL framework beyond the
traditional audience of IT service management professionals.
The Service Design volume provides guidance for the design and development of
services and service management processes. It covers design principles and methods
for converting strategic objectives into portfolios of services and service assets. The
scope of Service Design is not limited to new services. It includes the changes and
improvements necessary to increase or maintain value to customers over the lifecycle
of services, the continuity of services, achievement of service levels, and conformance
to standards and regulations. It guides organizations on how to develop design
capabilities for service management.
The Service Transition volume provides guidance for the development and
improvement of capabilities for transitioning new and changed services into
operations. This publication provides guidance on how the requirements of Service
Strategy encoded in service design are effectively realized in service operations
while controlling the risks of failure and disruption. The publication combines
practices in release management, program management, and risk management and
places them in the practical context of service management. It provides guidance on
managing the complexity related to changes to services and service management
processes; preventing undesired consequences while allowing for innovation.
Guidance is provided on transferring the control of services between customers and
service providers.
The Service Operation volume embodies practices in the management of service
operations. It includes guidance on achieving effectiveness and efficiency in the
delivery and support of services so as to ensure value for the customer and the
service provider. Strategic objectives are ultimately realized through service
operations, therefore making it a critical capability. Guidance is provided on how to
maintain stability in service operations, allowing for changes in design, scale, scope,
and service levels. Organizations are provided with detailed process guidelines,
methods, and tools for use in two major control perspectives: reactive and proactive.
Managers and practitioners are provided with knowledge allowing them to make
better decisions in areas such as managing the availability of services, controlling
demand, optimizing capacity utilization, scheduling of operations, and fixing
problems. Guidance is provided on supporting operations through new models and
architectures such as shared services, utility computing, Web Services, and mobile
commerce.

The Continual Service Improvement volume provides instrumental guidance in

creating and maintaining value for customers through better design, introduction,
and operation of services. It combines principles, practices, and methods from
quality management, change management, and capability improvement.
Organizations learn to realize incremental and large-scale improvements in service
quality, operational efficiency, and business continuity. Guidance is provided for
linking improvement efforts and outcomes with service strategy, design, and
transition. A closed-loop feedback system, based on the Plan, Do, Check, Act (PDCA)
model specified in ISO/IEC 20000, is established and capable of receiving inputs
for change from any planning perspective.

Service Strategy
Service
Service
Strategy
ITIL

Service
Strategy
ITIL
Service Strategy
• Shows organizations how to transform Service Management
into a strategic asset and to then think and act in a strategic
manner
• Helps clarify the relationships between various services,
systems or processes and the business models, strategies or
objectives they support
System: A number of related things that work together to achieve an overall

Objective. For example:
A computer System including hardware, software and Applications
A management System, including multiple Processes that are planned and
managed together. For example a Quality Management System
A Database Management System or Operating System that includes many
software modules that are designed to perform a set of related Functions
To operate and grow successfully in the long-term, service providers must have the
ability to think and act in a strategic manner. The purpose of the Service Strategy
publication is to help organizations develop such abilities. The achievement of
strategic goals or objectives requires the use of strategic assets. The guidance shows
how to transform service management into a strategic asset. Organizations benefit
from seeing the relationships between various services, systems, or processes they
manage and the business models, strategies, or objectives they support.
The guidance answers questions of the following kind:
What services should we offer and to whom?
How do we differentiate ourselves from competing alternatives?
How do we truly create value for our customers?

How do we capture value for our stakeholders?

How can we make a case for strategic investments?
How can financial management provide visibility and control over value-
creation?
How should we define service quality?
How do we choose between different paths for improving service quality?
How do we efficiently allocate resources across a portfolio of services?
How do we resolve conflicting demands for shared resources?
A multi-disciplinary approach is required to answer such questions. Technical
knowledge of IT is necessary but not sufficient. The guidance is pollinated with
knowledge from the disciplines such as operations management, marketing, finance,
information systems, organizational development, systems dynamics, and industrial
engineering. The result is a body of knowledge robust enough to be effective across
a wide range of business environments. Some organizations are putting in place the
foundational elements of service management. Others are further up the adoption
curve; ready to tackle challenges and opportunities with higher levels of complexity
and uncertainty.

Service Design (SD)
Service
Service
Design
Design
Service
Service
Strategy
ITIL

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Design (SD)

• Provides guidance for the design and development of
services and Service Management processes
• The scope includes new services, and the changes and
improvements necessary to increase or maintain value to
customers over the lifecycle of services
The main purpose of the Service Design stage of the lifecycle is the design of new or
changed service for introduction into the live environment. It is important that a
holistic approach to all aspects of design is adopted and that when changing or
amending any of the individual elements of design all other aspects are considered.
Thus when designing and developing a new application, this shouldn’t be done in
isolation, but should also consider the impact on the overall service, the Service
Portfolio and Catalog, the technology, the Service Management processes and the
necessary measurements and metrics. This will ensure that not only the functional
elements are addressed by the design, but also that all of the management and
operational requirements are also addressed as a fundamental part of the design
and are not added as an afterthought.
The main goals and objectives of Service Design are to:
Design services to satisfy business objectives, based on the quality, compliance,
risk and security requirements delivering more effective and efficient IT and
business solutions and services aligned to business needs by coordinating all
design activities for IT services to ensure consistency and business focus.
Design services that can be easily and efficiently developed and enhanced
within appropriate time-scales and costs and wherever possible reduce,
minimize or constrain the long-term costs of service provision.

Design efficient and effective processes for the design, transition, operation and
improvement of high quality IT services, together with the supporting tools,
systems and information, especially the Service Portfolio to manage services
through their lifecycle.
Identify and manage risks in order that they can be removed or mitigated prior
to services becoming live.
Design secure and resilient IT infrastructures, environments, applications and
data/information resources and capability that meet the current and future
needs of the business and customers.
Design measurement methods and metrics for assessing the effectiveness and
efficiency of the design processes and their deliverables.
Produce and maintain IT plans, processes, policies, architectures, frameworks
and documents for the design of quality IT solutions, to meet current and future
agreed business needs.
Assist in the development of policies and standards in all areas of design and
planning of IT services and processes, receiving and acting upon feedback on
design processes from all other areas incorporating the actions into a continual
process of improvement.
Develop the skills and capability within IT by moving strategy and design
activities into operational tasks, making effective and efficient use of all IT service
resources.
Contribute to the improvement of the overall quality of IT service within the
imposed design constraints, especially by reducing the need for reworking and
enhancing services once they have been implemented in the live environment.

Scope of SD
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Scope of SD
• Design of:
– New and changed services
– Service Portfolio and Service Catalog
– Technology architecture and management systems
– Processes required
– Measurement methods and metrics
The Service Design stage of the lifecycle starts with a set of new or changed business
requirements and ends with the development of a service solution designed to meet
the documented needs of the business. This developed solution, together with its
Service Design Package (SDP), is then passed to Service Transition to evaluate, build,
test and deploy the new or changed service and on completion of these transition
activities; control is transferred to the Service Operation stage of the service lifecycle.
New and changed services: The main aim of Service Design is the design of
new or changed services. The requirements for these new services are extracted
from the Service Portfolio and each requirement is analyzed, documented and
agreed and a solution design is produced which is then compared with the
strategies and constraints from Service Strategy to ensure that it conforms to
corporate and IT policies. Each individual service design is also considered in
conjunction with each of the other aspects of Service Design.
The Service Portfolio: To ensure that this new or changed service is consistent
with all other services, and that all other services that interface, support or
depend upon the new or changed services are consistent with the new service. If
not, either the design of the new service or the other existing services will need
to be adapted.

The technology architectures and management systems: To ensure that the all
technology architectures and management systems are consistent with the new
or changed service and have the capability to operate and maintain the new
service. If not, then either the architectures or management systems will need to
be amended or the design of the new service will need to be revised.
The processes: To ensure that the processes, roles, responsibilities and skills have
the capability to operate, support and maintain the new or changed service. If
not the design of the new service will need to be revised or the existing process
capabilities will need to be enhanced. This includes all IT and Service
Management processes not just the key Service Design processes.
The measurement methods and metrics: To ensure that the existing measurement
methods can provide the required metrics on the new or changed service. If not
then the measurement methods will need to be enhanced or the service metrics
will need to be revised.
If all of the above activities are completed during the Service Design stage, this will
ensure that there will be minimal issues that arise during the subsequent stages of the
service lifecycle. Therefore Service Design must consolidate the key design issues and
activities of all IT and Service Management processes within its own design activities
to ensure that all aspects are considered and included within all designs for new or
changed services as part of everyday process operation.

Value to business of SD
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Value to business of SD
• Reduced total cost of ownership (TCO)
• Improved quality of service
• Improved consistency of service
• Easier implementation of new/changed services
• Improved service alignment
• More effective service improvement
• Improved IT governance
• More effective ITSM
• Improved information and decision making
With good Service Design it will be possible to deliver quality, cost effective services
and to ensure that the business requirements are being met. The following benefits
are as a result of good Service Design practice:
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 quality of service: both service and operational quality will be
enhanced
Improved consistency of service: as services are designed within the corporate
strategy, architectures and constraints
Easier implementation of new or changed services: as there is integrated and full
Service Design and the production of comprehensives Service Design Packages
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

Service Transition (ST)
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Transition (ST)

Service
Transition
• Plan and implement the deployment of all releases to create a

new service or improve an existing service
• Assure that the proposed changes in the Service Design
Package are realized
• Successfully steer releases through testing and into live
environment
• Transition services to/from other organizations
• Decommission or terminate services
The goals of Service Transition are to:

Set customer expectations on how the performance and use of the new or
changed service can be used to enable business change
Enable the business change project or customer to integrate a release into their
business processes and services
Reduce variations in the predicted and actual performance of the transitioned
services
Reduce the known errors and minimize the risks from transitioning the new or
changed services into production
Ensure that the service can be used in accordance with the requirements and
constraints specified within the service requirements
The objectives are to:
Plan and manage the resources to successfully establish a new or changed
service into production within the predicted cost, quality and time estimates
Ensure there is minimal unpredicted impact on the production services,
operations and support organization

Increase the customer, user and service management staff satisfaction with the
service transition practices including deployment of the new or changed service,
communications, release documentation, training, knowledge transfer
Increase proper use of the services and underlying applications and technology
solutions
Provide clear and comprehensive plans that enable the customer and business
change projects to align their activities with the service transition plans
The purpose of Service Transition is to:
Plan and manage the capacity and resources required to package, build, test,
and deploy a release into production and establish the service specified in the
customer and stakeholder requirements
Provide a consistent and rigorous framework for evaluating the service capability
and risk profile before a new or changed service is released or deployed
Establish and maintain the integrity of all identified service assets and
configurations as they evolve through the service transition stage
Provide good quality knowledge and information so that Change, Release and
Deployment Management can expedite effective decisions about promoting a
release through the test environments and into production
Provide efficient, repeatable build and installation mechanisms that can be used
to deploy releases to the test and production environments and to re-build
releases if required to restore service
Ensure that the service can be managed, operated and supported in
accordance with the requirements and constraints specified within the service
design

Scope of ST (1 of 2)
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
• Management and coordination of processes, systems and

functions to:
– Package, build, test and deploy a release into production
– Establish the service specified in the customer and stakeholder
requirements
The scope of the service transition life cycle stage is shown in the next slide.

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
Change Management (4.2)
RFC1 RFC2 RFC3 RFC4 RFC5 RFC6
Service Asset and Configuration Management (4.3)
BL BL BL BL BL BL BL
Service Transition Planning and Support (4.1)
Oversee management of organization and stakeholder change (5)
Evaluation of a Change or Service (4.6)
E1 E2 E3
Plan and Service Plan and Transfer, Review and

Service Service Build and Service
prepare testing and prepare for deploy, close service
Strategy Design test Operations
release pilots deployment retire transition
Early Life Support

Release and Deployment Management (4.4)
Service Validation and Testing (4.5)
Knowledge Management (4.7)
Point to Evaluate the Service Design

Focus of activity Other ITIL core E
ITIL process in this
related to service publication publication that supports
transition the whole service lifecycle
Point to capture Baseline
BL

Request for Change
RFC
Service Transition activities are shown in the white boxes. The dark boxes represent
activities in the other ITIL core books. There may be situations when some activities
are not applicable for a particular transition. For example the transfer of a set of
services from one organization to another may not involve release planning, build,
test and acceptance.
The following lifecycle processes in this book support all life cycle stages:
Change Management
Service Asset and Configuration Management
Knowledge Management
Service Transition uses all the processes described in the other ITIL books as it is
responsible for testing these processes, either as part of a new or changed service or
as part of testing changes to the service management processes. Service Level
Management is important to ensure that customer expectations are managed during
service transition. Incident and Problem Management are important for handling
incidents and problems during testing, pilot and deployment activities.

The following activities are excluded from the scope of Service Transition best
practices:
Minor modifications to the production services and environment, for example,
replacement of a failed PC or printer, installation of standard software on a PC
or server, new user
On-going continual service improvements that do not significantly impact the
services or service provider’s capability to deliver the services, for example,
request fulfillment activities driven from service operations

Value to business of ST
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Value to business of ST
Service
Transition
• Ability to react quickly to give ‘competitive edge’

• Management of mergers, de-mergers, acquisitions, transfer of
services
• Higher success rate of changes and releases
• Better prediction of service levels and warranties
• More confidence in governance and compliance
• Better estimating of resource plans and budgets
• Improved productivity of business and IT
• Timely savings following disposal or de-commissioning
• Reduced level of risk
Effective service transition can significantly improve a service provider’s ability to

handle high volumes of change and releases across its customer base. It enables the
service provider to:
Align the new or changed service with the customer’s business requirements and
business operations
Ensure that customers and users can use the new or changed service in a way
that maximizes value to the business operations
Specifically, Service Transition adds value to the business by improving:
The ability to adapt quickly to new requirements and market developments
(‘competitive edge’)
Transition management of mergers, de-mergers, acquisitions, transfer of services
The success rate of changes and releases for the business
The predictions of service levels and warranties for new and changed services
Confidence in the degree of compliance with business and governance
requirements during change
The variation of actual against estimated and approved resource plans/budgets

The productivity of business and Customer staff because of better planning and
use of new and changed services
The timeliness of cancellation or changes to maintenance contracts for both
hardware and software when components are disposed or de-commissioned
The understanding of the level of risk during and after change, for example,
service outage, disruption, re-work

Service Operation (SO)
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service
Transition

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Operation (SO)

Service
Transition
• Coordinate and carry-out day-to-day activities and processes

to deliver and manage services at agreed levels
• Ongoing management of the technology that is used to
deliver and support services
• Where the plans, designs and optimizations are executed
and measured
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 implemented processes will be of little value if the day-to-day
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.

Scope of SO
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Scope of SO
Service
Transition
• Ongoing management of:

– The services themselves
– The Service Management processes
– Technology
– People
Service Operation includes the execution of all ongoing activities required to deliver
and support services. The scope of Service Operation includes:
The services themselves. Any activity that forms part of a service is 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
many Service Management processes 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 Definition, the
actual Design process itself. These processes focus more on longer-term planning
and improvement activities which are outside of the direct scope of Service
Operation, however Service Operation provides input and influences these
regularly as part of 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 the Service
Operation book 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
organization’s 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 projects.

Value to business of SO
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Value to business of SO
Service
Transition
• Where actual value of strategy, design and transition are

realized by the customers and users
But
• Where business dependency usually commences
Each stage in the ITIL Service Lifecycle provides value to business. For example,
service value is modelled in Service Strategy, the cost of the service is designed,
predicted and validated in Service Design and Service Transition, and measures for
optimization identified in Continual Service Improvement. The operation of service is
where these plans, designs and optimizations are executed and measured. From a
customer viewpoint, Service Operation is where actual value is seen.

Achieving balance (Conflicting Motives)

Service
Service
Achieving balance
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service
(Conflicting Motives)
Transition
• IT Services v Technology
• Stability v Responsiveness
• Quality of service v Cost of service
• Reactive v Proactive
Service Operation is more than just the repetitive execution of a standard set of
procedures or activities. All functions, processes and activities are designed to deliver
a specified and agreed level of services, but they have to be delivered in an ever-
changing environment. This forms a conflict between maintaining the status quo and
adapting to changes in the business and technological environments. One of Service
Operation’s key roles is therefore to deal with this conflict and to achieve a balance
between conflicting sets of priorities. Service Operation highlights some of the key
tensions and conflicts, and identifies how IT organizations can recognize that they
are suffering from an imbalance by tending more toward one extreme or the other. It
also provides some high-level guidelines on how to resolve the conflict, and thus
move towards a best practice approach. Every conflict therefore represents an
opportunity for growth and improvement.
Internal IT view versus external business view

The most fundamental conflict in all phases of the IT Service Management Lifecycle is
between the view of IT as a set of IT Services (the external business view), and the
view of IT as a set of technology components (internal IT view).
The external view of IT is the way in which services are experienced by its users and
customers. They do not always understand, nor do they care about, the details of
what technology is used to manage those services. All they are concerned about is
that the services are delivered as required and agreed.

The internal view of IT is the way in which IT components and systems are managed
to deliver the services. Since IT systems are complex and diverse, this often means
that the technology is managed by several different teams or departments – each of
which is focused on achieving good performance and availability of “their” systems.
Both views are necessary when delivering services. The organization that focuses
only on business requirements without thinking about how they are going to deliver
will end up making promises that can not be kept. The organization that focuses only
on internal systems without thinking about what services they support will end up with
expensive services that deliver little value.
The potential for role conflict between the external and internal views is the result of
many variables, including the maturity of the organization, its management culture,
its history, etc. This makes a balance difficult to achieve and most organizations tend
more towards one role than the other. Of course, no organization will be totally
internally or externally focused, but will find themselves in a position along a
spectrum between the two.
For example, an IT department that focuses too much on the internal aspects will tend
to have very good technical management with high performing technology, while
users are very dissatisfied with the level of service. On the other hand, an IT
department that focuses too much on the external aspects will tend to make promises
that its current technology can not support.
Stability versus responsiveness

No matter how good the functionality is of an IT Service, and no matter how well it
has been designed it will be worth far less if the Service components are not
available or if they perform inconsistently. This means that Service Operation needs
to ensure that the IT Infrastructure is stable and available as designed. At the same
time Service Operation needs to recognize that business and IT requirements change.
Some of these changes are evolutionary. For example, the functionality, performance
and architecture of a platform may change over a number of years. Each change
brings with it an opportunity to provide better levels of service to the Business. In
evolutionary changes it is possible to plan how to respond to the change and thus
maintain stability while responding to the changes.
Many changes, though, happen very quickly and sometimes under extreme pressure.
For example, a Business Unit unexpectedly wins a contract that requires additional IT
Services, more capacity and faster response times. The ability to respond to this type
of change without impacting other services is a significant challenge.
Many IT organizations are unable to achieve this balance and tend to focus on either
the stability of the IT Infrastructure or the ability to respond to changes quickly.

For example, an IT department that insists on bureaucratic Change Control

mechanisms to ensure that nothing changes will not be able to respond to changing
business requirement in time. On the other hand, an IT department that implements
changes whenever they are asked to do so without any prioritization, proper testing
and clear funding will be unable to deliver a consistent set of services, and may even
find that their services fail frequently.
Quality of Service versus Cost of Service

Service Operation is required to consistently deliver the agreed level of IT Service to
its customers and users, while at the same time keeping costs and resource utilization
at an optimal level.
The figure below represents the investment made to deliver a service at increasing
levels of quality.
Service
Cost of service
Range of optimal
balance between
Cost and Quality
Quality of Service
(Performance, Availability, Recovery)
Balancing Service Quality and Cost
In the figure above an increase in the level of quality usually results in an increase in
the cost of that service, and visa versa. However, the relationship is not always
directly proportional:
Early in the service’s lifecycle it is possible to achieve significant increases in
service quality with a relatively small amount of money. For example improving
service availability from 55% to 75% is fairly straightforward and may not
require a huge investment

Later in the service’s lifecycle even small improvements in quality are very
expensive. For example, improving the same service’s availability form 96% to
99.9% may require large investments in high-availability technology and support
staff and tools
While this may seem straightforward, many organizations are under severe pressure
to increase the quality of service while reducing their costs. In the figure above the
relationship between cost and quality is sometimes inverse. It is possible (usually
inside the range of optimization) to increase quality while reducing costs. This is
normally initiated within Service Operation and carried forward by Continual Service
Improvement. Some costs can be reduced incrementally over time, but most cost-
savings can only be made once. For example, once a duplicate software tool has
been eliminated, it can not be eliminated again for further cost savings.
Achieving an optimal balance between Cost and Quality (shown between the dotted
lines in the figure above) is a key role of Service Management. There is no industry
standard for what this range should be since each service will have a different range
of optimization, depending on the nature of the service and the type of business
objective being met. For example the business may be prepared to spend more to
achieve high availability on a mission critical service, while they are prepared to live
with the lower quality of an administrative tool.
For example, an organization that focuses purely on the cost of IT may reject some
investments aimed at improving the level of service. In many cases this has an affect
on the ability of users to do their jobs properly and the company could lose money.
On the other hand, an extreme focus on quality could mean that money is spent on
enhancing and improving services that are not really contributing a large amount of
value to the organization.
Reactive versus proactive

A reactive organization is one which does not act unless it is prompted to do so by
an external driver, for example, a new business requirement, an application that has
been developed, escalation in complaints made by users and customers. An
unfortunate reality in many organizations is the focus on reactive management
mistakenly as the sole mean to ensure services that are highly consistent and stable,
actively discourage proactive behavior from operational staff. The unfortunate irony
of this approach is that discouraging effort investment in proactive service
management can ultimately increase the effort and cost of reactive activities and
further risk stability and consistency in services.
A proactive organization is always looking for ways to improve the current situation.
It will continually scan the internal and external environments, looking for signs of
potentially impacting changes. Proactive behavior is usually seen as positive,
especially since it enables the organization to maintain competitive advantage in a
changing environment. However, being too proactive can be expensive and can
result in staff being distracted. The need for proper balance in reactive and proactive
behavior often achieves the optimal result.

For example, an IT department that will only take action when the business complains
about something will always be seen as an obstacle to progress. On the other hand,
if the IT department keeps investing in new technology to fix things that are not
broken, they will be seen as a drain on the company’s finances.

The value of communication

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
The value of communication

Service
Transition
• Good communication is important across all phases of the

service lifecycle but particularly so in Service Operation
• Good communication is needed between all ITSM personnel
and with users/customers/partners
• Issues can often be mitigated or avoided through good
communication
• All communication should have:
– Intended purpose and/or resultant action
– Clear audience, who should be involved in deciding the
need/format
Good communication is important across all phases of the service lifecycle but
particularly so in Service Operation.
Good communication is needed with other IT teams and departments; with users and
internal customers and between the Service Operation teams and departments
themselves. Issues can often be prevented or mitigated with appropriate
communication.
An important principle is that all communication must have an intended purpose or a
resultant action. Information should not be communicated unless there is a clear
audience. In addition, that audience should have been actively involved in
determining the need for that communication and what they will do with the
information.
Types of communication include:
Routine Operational Communication
Communication between shifts
Communication in projects
Communication related to changes
Communication related to exceptions

Communication related to emergencies

Training on new or customized processes and service designs
Communication of Strategy and Design to Service Operation teams
Please note that there is no definitive medium for communication, nor is there a fixed
location or frequency. In some organizations communication has to take place in
meetings. Other organizations prefer to use email or the communication inherent in
their Service Management tools.
There should therefore be a policy around communication within each team or
department and for each process. Although this should be formal, the policy should
not be cumbersome or complex. For example a manager might require that all
communications regarding changes must be sent by email. As long as this is
specified in the department’s Standard Operating Procedures (in whatever form they
exist), there is no need to create a separate policy for it.
Although the typical content of communication is fairly consistent once processes
have been defined, the means of communication are changing with every new
introduction of technology. The list of alternatives is growing and, today includes:
Email, to traditional clients or mobile devices
SMS messages
Pagers
Instant messaging and web-based “chats”
Voice Over IP (VOIP) utilities that can turn any connected device to an
inexpensive communication medium
Teleconference and virtual meeting utilities have revolutionized meetings, which
are now held across long distances
Document sharing utilities
The means of communication itself is outside the scope of the Service Operation
book; however the following points should be noted:
Communication is primary and the means of communication must ensure that
they serve this goal. For example, the need for secure communication may
eliminate the possibility of some of the above means. The need for quality may
eliminate some VOIP options.
It is possible to use any means of communication as long as all stakeholders
understand how and when the communication will take place.

Continual Service Improvement (CSI)
Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service
Transition

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL

Operation
Service
Transition
• Aims to continually align IT services to changing business

needs by identifying and implementing improvements
• Continually looking for ways to improve process efficiency
and effectiveness as well as cost effectiveness
The primary purpose of Continual Service Improvement (CSI) is to continually align

and realign IT services to the 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. In effect, CSI is about
looking for ways to improve process effectiveness, efficiency as well as 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.”
If ITSM 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
carefully define the successful outcome.

The objectives of CSI are to:

Review, analyze and make recommendations on improvement opportunities in
each lifecycle phase: Service Strategy, Service Design, Service Transition, and
Service Operations
Review and analyze 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

Scope of CSI
Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Scope of CSI
Operation
Service
Transition
• Overall health of ITSM as a discipline and of the services

• Alignment of the service portfolio with business needs
• Maturity of processes
There are three 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
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
Conducting periodic customer satisfaction surveys
Conducting external and internal Service reviews to identify CSI opportunities
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.
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.

Value to business of CSI

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Value to business of CSI

Operation
Service
Transition
• Improved service quality, higher availability

• Gradual cost reductions and better cost-justification
• Better information about existing services and areas for
improvement
• Better business/IT alignment
• Increased flexibility and adaptability
• Improved communication
• ROI/VOI
There are four commonly used terms when discussing service improvement outcomes:
Improvements
Benefits
ROI (Return on Investment)
VOI (Value on Investment)
Much of the angst and confusion surrounding IT process improvement initiatives can
be traced to the misuse of these terms. Below is the proper use:
Improvements: Outcomes that when compared to the “before” state, show a
measurable increase in a desirable metric or decrease in an undesirable metric
• Example: ABC Corp achieved a 15% reduction in failed changes through
implementation of a formal Change Management process
Benefits: The gains achieved through realization of improvements, usually but not
always expressed in monetary terms
• Example: ABC Corp’s 15% reduction in failed changes has saved the
company $395,000 in productivity and re-works costs in the first year

ROI: The difference between the benefit (saving) achieved and the amount
expended to achieve that benefit, expressed as a percentage. Logically, one
would like to spend a little to save a lot
• Example: ABC Corp spent $200,000 to establish the formal Change
Management process that saved $395,000. The ROI at the end of the first
year of operation was therefore $195,000 or 97.5%
VOI: The extra value created by establishment of benefits that include non-
monetary or long term outcomes. ROI is a subcomponent of VOI
• Example: ABC Corp’s establishment of a formal Change Management
process (which reduced the number of failed changes) improved the ability
of ABC Corp to respond quickly to changing market conditions and
unexpected opportunities resulting in an enhanced market position. In
addition, it promoted collaboration between business units and the IT
organization and freed up resources to work on other projects that
otherwise may not have been completed

Interfaces with or Guidance, Methodologies,

Legislation and Standards
Interfaces with or Guidance, Methodologies,
Legislation and Standards
Continual Service
CMMI Improvement
TOGAF Service
Service ISO/IEC
Design
Design 20000
eTOM
Service
Service
Strategy
SOX
Six Sigma
Service
ITIL ISO/IEC
Operation
PMBOK 27001
PRINCE2 Service ISO/IEC

Transition 19770
SOA
COBIT
M_o_R
CMMI: Carnegie-Melon Capability Maturity Model Integration; a method for

evaluating the level of maturity of a process or function, which can be and often
is used for assessing ITSM capabilities
TOGAF: The Open Group Architecture Framework; a formal description of a
system, or a detailed plan of the system at component level to guide its
implementation
eTOM: Enhance Telecom Operations Map; A Business Process Framework for
the Information and Communications Service Industry
Six Sigma: A quality management system which features' Black Belts (quality
management project leaders) and Green Belts (who assist Black Belts to
implement Quality management projects)
PMBOK: Project Management Body of Knowledge; a white paper produced in
1987 in an attempt to document and standardize generally accepted project
management practices. The current edition, A Guide to the Project Management
Body of Knowledge (PMBOK Guide) - Third Edition, was released Oct 2004
and provides a basic reference for Project Management.
SOA: Service Oriented Architecture; a design for linking business and
computational resources (principally organizations, applications and data) on
demand to achieve the desired results for service consumers

PRINCE 2: The project management system developed by OGC for use within
the UK Government
COBIT: Control Objectives for Information & Related Technology; guidance on
ITSM Security and Auditing from ISAACA
M-o-R: Management of Risk
ISO/IEC 20000: International standard for IT Service Management for which
organizations can seek independent accreditation
SOX: Sarbane-Oxley; US Legislation seeking to introduce better management
controls and financial practices, including corporate disclosure, into
organizations listed on the US Stock Market
ISO/IEC 27001: International standard for IS Security
ISO/IEC 19770: International standard for Software Asset management

Key Principles, Models and Concepts
Module 3

Service Provider
Service Provider
• An organization supplying
services to one or more
internal customers or
external customers

RACI Model
RACI Model
• A RACI model can be used to help define roles and
responsibilities
• It identifies the activities that must be performed alongside the
various individuals and roles involved
• RACI is an acronym for the four main roles of:
– Responsible — The person or people responsible for getting the
job done
– Accountable — Only one person can be accountable for each
task
– Consulted — The people who are consulted and whose opinions
are sought
– Informed — The people who are kept up-to-date on progress
Whether designing a service, process or developing a project, it is imperative that all

the roles are clearly defined.
A trademark of high performing organizations is the ability to make the right
decisions quickly and execute them effectively. Whether the decision involves a
strategic choice or a critical operation, being clear on who has input, who decides
and who takes action will enable the company to move forward rapidly.
The RACI model will be beneficial in enabling decisions to be made with pace and
confidence. RACI is an acronym for the four main roles of:
Responsible — The person or people responsible for getting the job done
Accountable — Only one person can be accountable for each task
Consulted — The people who are consulted and whose opinions are sought
Informed — The people who are kept up-to-date on progress

To build a RACI chart the following steps are required:

Identify the activities/processes
Identify/define the functional roles
Conduct meetings and assign the RACI codes
Identify any gaps or overlaps – for example, where there are two As or no Rs
Distribute the chart and incorporate feedback
Ensure that the allocations are being followed
Potential problems with the RACI model:
Having more than one person accountable for a process means that in practice
no one is accountable
Delegation of responsibility or accountability without necessary authority
Focus on matching processes and activities with departments
Incorrect division/combination of functions; conflicting agendas or goals
Combination of responsibility for closely-related processes

Example RACI Model
Example RACI Model
Director Service Service Level Problem Security Procurement

Management Manager Manager Manager Manager
Activity 1 AR C I I C
Activity 2 A R C C C
Activity 3 I A R I C
Activity 4 I A R I
Activity 5 I I A C R
A RACI chart is a variation of an authority matrix, and a simple example of such

chart is shown above. The structure and power of RACI modeling with the activities
down the left-hand side including the actions that need to be taken and decisions
that must be made. Across the top, the chart lists the functional roles responsible for
carrying out the initiative or playing a part in decision making.
Whether RACI or some other tool or model is used, the important thing is to not just
leave the assignment of responsibilities to chance or leave it to the last minute to
decide. Conflicts can be avoided and decisions can be made quickly if the roles are
allocated in advance.

Process Owner
Process Owner
Responsible for:
• Assisting with Process
Design
• Documenting the process
• Making sure the process is
being performed as
documented
• Making sure the process
meets its aims
• Monitoring and improving
the process over time
A Process Owner is responsible for ensuring that their process is being performed
according to the agreed and documented process and is meeting the aims of the
process definition. This includes such tasks as:
Documenting and publicizing the process
Defining the Key Performance Indicators (KPIs) to evaluate the effectiveness and
efficiency of the process
Reviewing KPIs and taking action required following the analysis
Assisting with and ultimately responsible for the process design
Improving the effectiveness and efficiency of the process
Reviewing any proposed enhancements to the process
Providing input to the on-going Service Improvement Program
Addressing any issues with the running of the process
Ensuring all relevant staff have the required training in the process and are
aware of their role in the process

Ensuring that the process, roles, responsibilities and documentation are regularly
reviewed and audited
Interfacing with line management, ensuring that the process receives the needed
staff resources. Line management and process owners have complementary
tasks; they need to work together to ensure efficient and effective processes.
Often it is the task of line management to ensure the required training of staff.
The Process Manager role is responsible for operational management of a process.
The Process Manager's responsibilities include planning and co-ordination of all
activities required to carry out, monitor and report on the process.
There may be several Process Managers for one process, for example regional
Change Managers or IT Service Continuity Managers for each data centre.
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.

Service Owner
Service Owner
• The Service Owner is
responsible to the Customer
for a particular service
– Initiation and transition
– Ongoing maintenance and
support
– Monitoring and reporting
– Identifying improvement
opportunities
– Prime customer contact
The Service Owner is responsible to the Customer for the initiation, transition and
ongoing maintenance and support of a particular service.
The Service Owner has the following responsibilities:
To act as prime Customer contact for all Service related enquiries and issues
To ensure that the ongoing Service delivery and support meet agreed Customer
requirements
To identify opportunities for Service Improvements, discuss with the Customer
and to raise the RFC for assessment if appropriate
To liaise with the appropriate Process Owners throughout the Service
Management lifecycle
To solicit required data, statistics and reports for analysis and to facilitate
effective Service monitoring and performance
To be accountable to the IT Director for the delivery of the Service
The Service Owner is accountable for a specific service within an organization
regardless of where the underpinning technology components, processes or
professional capabilities reside. Service ownership is as critical to service
management as establishing ownership for processes which cross multiple vertical
silos or departments.

Service Manager is an important role that manages the development,

implementation, evaluation and on-going management of new and existing products
and services.
Service Managers are recognized as global product/service experts. They drive the
decision-making processes, manage product/service objectives and strategies, hold
internal and external suppliers accountable, and provide the integration of individual
product plans and new technologies into seamless customer-focused services. Service
Managers may also be required to coach other managers (Service Owners, Process
Owners) with differing levels of expertise for managing a business function or a
particular product/service, within a specified product/service family.
See more information about the Service Manager role in the Continual Service
Improvement section of Module 4 – Concepts, Processes, Roles and Functions.

Suppliers and Contracts
Suppliers and Contracts

• Supplier
– A third party responsible for
supplying goods or services
– These are required by the
service provider to enable them
to deliver services
• Contract
– A legally binding agreement
between two or more parties to
supply goods or services
Formal contracts are appropriate for external supply arrangements which make a
significant contribution to the delivery and development of the business. Contracts
provide for binding legal commitments between customer and supplier, and cover the
obligations each organization has to the other from the first day of the contract, often
extending beyond its termination. A contract is used as the basis for external supplier
agreements where an enforceable commitment is required. High-value and/or
strategic relationships are underpinned by a formal contract. The formality and
binding nature of a contract are not at odds with the culture of a partnering
agreement, but rather form the basis upon which trust in the relationship may be
founded.
A contract is likely to be structured with a main body containing the commercial and
legal clauses, and with the elements of a service agreement, attached as schedules.
Contracts may also include a number of other related documents and schedules, for
example:
Security requirements
Business continuity requirements
Mandated technical standards
Migration plans (agreed pre-scheduled change)
Disclosure agreements

Most large organizations have procurement and legal departments specializing in

sourcing contracts. Specialist legal firms may be employed to support the internal
procurement and legal function when establishing significant formal contracts.

Service Portfolio
Service Portfolio
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 provider’s services in terms of
business value. It articulates business needs and the provider’s response to those
needs. By definition, business value terms correspond to markets terms,
providing a means for comparing service competitiveness across alternative
providers. By acting as the basis of a decision framework, a service portfolio
either clarifies or helps to clarify the following strategic questions:
Why should a customer buy these services?
Why should they buy these services from you?
What are the pricing or chargeback models?
What are my strengths and weaknesses, priorities and risk?
How should my resources and capabilities be allocated?
Ideally the Service Portfolio should form part of a comprehensive Service Knowledge
Management System (SKMS) and registered as a document in the Configuration
Management System (CMS).

Once a strategic decision to charter a service is made, this is the stage in the service
lifecycle that Service Design begins architecting the service. The Service Portfolio
should contain information relating to every service and its current status within the
organization. The options of status within the Service Portfolio should include:
Requirements: A set of outline requirements have been received from the
business or IT for a new or changed service
Defined: The set of requirements for the new service are being assessed,
defined, and documented and the SLR is being produced
Analyzed: The set of requirements for the new service are being analyzed and
prioritized
Approved: The set of requirements for the new service have been finalized and
authorized
Chartered: The new service requirements are being communicated and
resources and budgets allocated
Designed: The new service and its constituent components are being designed-
and procured, if required
Developed: The service and its constituent components are being developed or
harvested, if applicable
Built: The service and its constituent components are being built
Test: The service and its constituent components are being tested
Released: The service and its constituent components are being released
Operational: The service and its constituent components are operational within
the live environment
Retired: The service and its constituent components have been retired
Customers and users would only be allowed access to those services within the
Service Portfolio that were of a status between “chartered” and “operational”, as
illustrated by the dashed box in the diagram in the slide. This phase describes the
services contained within the Service Catalog. Service Strategy and Service Design
personnel would need access to all records within the Service Portfolio, as well as
other important areas such as Change Management. Other members of the service
provider organization would have access to a permitted subset of the records within
the Service Portfolio. Although the Service Portfolio is designed by Service Design, it
is owned and managed by Service Strategy within the Service Portfolio Management
process.

The Requirements Portfolio is a subset of the overall Service Portfolio and contains
details of all of the business requirements that have not yet become services released
to the live environment. It is used as a basis for the definition, analysis, prioritization
and approval, by the IT Steering Group (ISG) and Service Strategy, of all requests for
new or changed services, to ensure that new and changed services are aligned to
business requirements. It will principally be used as input to the activities of the
Service Strategy and Service Design stages of the service lifecycle. It also provides
valuable input to the activities of the Service Transition stage of the lifecycle in
determining the services to be released. The Service Catalog Management process
must ensure that all of the details within the Service Portfolio are accurate and up to
date as the requirement and its new or changed service is migrated into the live
environment. This will involve close liaison with all Service Transition activities.

Service Catalog
Service Catalog
• Part of the Service Portfolio
• Services available for deployment or use
• Information to be shared with customers
• Business Service Catalog
– Services of interest to customers
• Technical Service Catalog
– Underpinning services of interest to IT
The Portfolio should contain all of the future requirements for services and the
Catalog should contain details of all operational services being provided or those
being prepared for transition to the live environment, a summary of their
characteristics and details of the customers and maintainers of each. A degree of
‘detective work’ may be needed to compile this list and agree it with the customers.
The Service Portfolio is produced as part of Service Strategy and should include
participation by those involved in Service Design, Transition, Operation and
Continual Service Improvement. Once a Service is ‘chartered’ (being developed for
use by customers), Service Design produces the specifications for the service and it is
at this point the Service should be added to the Service Catalog.
Each organization should develop and maintain a policy with regard to both the
Portfolio and the Catalog, with regard to the services recorded within them, what
details are recorded and what statuses are recorded for each of the services. The
policy should also contain details of responsibilities for each section of the overall
Portfolio and the scope of each of the constituent sections.
The Service Catalog Management process produces and maintains the Service
Catalog ensuring that a central, accurate and consistent source of data is provided,
recording the status of all operational services or services being transitioned to the
live environment, together with appropriate details of each service.

The Service Catalog has two aspects:

The Business Service Catalog: Containing details of all of the IT services
delivered to the customer, together with relationships to the business units and
the business process that rely upon the IT services. This is the customer view of
the Service Catalog.
The Technical Service Catalog: Containing details of all of the IT services
delivered to the customer, together with relationships to the supporting services,
shared services, components and CIs necessary to support the provision of the
service to the business. This should underpin the Business Service Catalog and
not form part of the customer view.

Risk Management and Analysis
Risk Management and Analysis

Define a framework
Embed and review Identify the risks
Gain assurances Identify probable

about effectiveness risk owners
Implement responses Evaluate the risks
Set acceptable levels of risk
Define a framework
Risk management Risk analysis
Risk is defined as uncertainty of outcome, whether positive opportunity or negative

threat. Managing risks requires the identification and control of the exposure to risk,
which may have an impact on the achievement of an organization’s business
objectives.
Every organization manages its risk, but not always in a way that is visible,
repeatable and consistently applied to support decision-making. The task of
management of risk is to ensure that the organization makes cost effective use of a
risk framework that has a series of well defined steps. The aim is to support better
decision-making through a good understanding of risks and their likely impact. There
are two distinct phases: risk analysis and risk management.
Risk analysis is concerned with gathering information about exposure to risk so that
the organization can make appropriate decisions and manage risk appropriately.
Management of risk involves having processes in place to monitor risks, access to
reliable and up to date information about risks, the right balance of control in place
to deal with those risks, and decision-making processes supported by a framework of
risk analysis and evaluation.
Management of risk covers a wide range of topics, including business continuity
management (BCM), security, program/project risk management and operational
service management. These topics need to be placed in the context of an
organizational framework for the management of risk.

Plan, Do, Check, Act Model
Plan, Do, Check, Act Model

Manage Services
Business Business results
requirements
Management Responsibility
Customer PLAN Customer

requirements Plan service satisfaction
management
&
services
Request for new or New or changed
changed services service
Act DO
Continuous Implement & run
service
Other process, improvement management Other process,
business, & service Business, Supplier,
supplier, customer customer
Check
Monitor,
Other teams, measure Team & people
e.g. Security & satisfaction
review
Planning for Improvement Initiatives (Plan) - At this stage goals and measures for
success are established, a gap analysis is performed, action steps to close the gap
are defined, and measures to ensure the gap was closed are established and
implemented.
Implementation of Improvement Initiative (Do) - This includes development and
implementation of a project to close the identified gaps, implementation of the
improvement to Service Management processes, and establishing the smooth
operation of the process.
Monitor, Measure and Review Services and Service Management Processes (Check) -
During this stage the implemented improvements are compared to the measures of
success established in the Plan phase. The comparison determines if a gap still exists
between the improvement objectives and the operational process state. Gaps don’t
necessarily require closure. A gap may be considered tolerable if the actual
performance is within allowable limits of performance. At the Check stage, the
expected output is recommendations for improvement. For example,
recommendations to update or modify the Service Catalog, measurements to be
tracked in SLAs, Operating Level Agreements (OLAs) and Underpinning Contracts
(UCs) could also come out of this stage.

Continual Service and Service Management process Improvement (Act) - This stage
requires implementing the actual Service and Service Management process
improvements. A decision to keep the status quo, close the gap or adding necessary
resources needs to be made to determine if further work is required to close
remaining gaps, and to determine the allocation of resources necessary to support
another round of improvement. Project decisions at this stage are the input for the
next round of the PDCA cycle, closing the loop as input to the next Plan stage.
Too many people and too many organizations are looking for the “big-bang”
approach to improvements. It is important to understand that a succession or series of
small planned increments of improvements will not stress the infrastructure as much
and will eventually amount to a large amount of improvement over time.

Governance
Ensures the provision of a corporate strategy and
Governance business plan. Establishes the corporate policies and
enables the strategic direction, objectives, critical
success targets and key results areas.
Corporate
Governance
Assures adherence to legal, industrial and
regulatory requirements.
Corporate Compliance
Establishes IT policy, standards and principles
and assures alignment of IT strategy to IT Governance
corporate business strategy.
IT Compliance
Assures the design and operability of

IT policies, processes and key controls. IT Service
Management
Establishes, enables and executes the IT strategy.

Establishes and operational model to assure high-quality, compliant IT service provisions.
Ensures effective key result areas.
Governance has actually been around the IT arena for decades. The mainframe had
significant controls built around its day-to-day operations. With the advent of
distributed processing in the early 90s, then n-tier processing, the Internet and
increasing virtualization, governance and controls simply went out of fashion, just
when they were the most desperately needed. With the exposure of high level
corporate fraud in the early years of this century, IT was thrust, without warning, into
a completely unfamiliar game with incredibly high stakes. Governance is back with a
vengeance. IT is now forced to comply with sweeping legislation and an ever-
increasing number of external regulations. External auditors are commonplace in
large IT shops. IT can no longer mask their operations behind a veil of secrecy or a
cloud of obfuscation but rather they must run an organization which prides itself on
its transparency.
Corporate Governance
"Corporate governance is about promoting corporate fairness, transparency and
accountability" (J. Wolfensohn, President, World Bank, Financial Times, June 21,
1999). The most recent and highly visible example of a renewed emphasis on
corporate governance is the Sarbanes-Oxley Act (SOX) of 2002 in the United States.
Created in the aftermath of fraudulent behavior by corporate giants, SOX demands
corporate fairness, mandates complete transparency of transactions and holds
executives accountable for any material deficiencies. The accountability provisions in
SOX include criminal charges and incarceration for non-compliance.

IT Governance
“IT governance is the responsibility of the board of directors and executive
management. It is an integral part of enterprise governance and consists of the
leadership, organizational structures and processes that ensure that the
organization’s IT sustains and extends the organization’s strategies and objectives”.
(Board Briefing on IT Governance, 2nd Edition, 2003, IT Governance Institute - ITGI).
On one hand, IT must now comply with new rules and legislation and continually
demonstrate their compliance through successful independent audits by external
organizations. On the other hand, IT is increasingly being called upon to “do more
with less” and create additional value while maximizing the use of existing resources.
These increasing pressures dovetail perfectly with the basic premise of ITIL: IT is a
service business. Existing internal IT organizations must transform themselves into
effective and efficient IT service providers or they will cease to be relevant to the
business and, soon after, cease to exist. This continual and unceasing drive toward
greater business value with greater internal efficiency is at the heart of Continual
Service Improvement.
Compliance
“Compliance ensures that a Standard or set of Guidelines is followed, or that proper,
consistent accounting or other practices are being employed.”


Concepts, Processes, Roles and Functions
Module 4

Service Operation
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Operation
Service
Transition
• Processes
– Event Management
– Incident Management
– Request Fulfillment
– Problem Management
– Access Management
• Functions
– Service Desk
– Technical Management
– IT Operations Management
– Application Management

Event Management
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Event Management
Service
Transition
• Objectives
• Basic concepts
• Roles

Event Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Event Management — Objectives

Service
Transition
• Detect Events, make sense of them, and determine the

appropriate control action
• Event Management is the basis for Operational Monitoring
and Control
Event Management’s main objective is the ability to detect Events, make sense of
them, and determine the appropriate control action.
In addition:
If these events are programmed to communicate operational information as well
as warnings and exceptions, they can be used as a basis for Operational
Monitoring and Control, automating many routine Operations Management
activities.
Event Management provides a way of comparing actual performance and
behavior against design standards and Service Level Agreements.

Event Management — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Event Management — Basic concepts

Service
Transition
• Event
An alert or notification created by any IT Service, Configuration
Item or monitoring tool. For example a batch job has completed.
Events typically require IT Operations personnel to take actions,
and often lead to Incidents being logged.
• Event Management
The Process responsible for managing Events throughout their
Lifecycle.
• Alert
Something that happens that triggers an event or a call for action
or human intervention after the event is filtered
Definition of an Event
Events are typically alerts or notifications created by an IT Service, Configuration Item
(CI) or monitoring tool.
Events can be formally defined as any detectable or discernable occurrence that has
significance for the management of the IT infrastructure or the delivery of IT service
and evaluation of the impact a deviation might cause to the services.
Examples of an Event:
A batch job has completed
A switch on the network needs to stay on, and Event Management tools confirm
this by monitoring responses to “pings”
Software license monitoring has detected that the number of licenses allocated
has reached a limit
A device’s CPU is above the acceptable utilization rate
Event Management
Event Management is the process responsible for managing Events throughout their
Lifecycle, that is, occurrence, detection, filtering, triggering some kind of action if
necessary, review and close.

Event Management — Logging and Filtering

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Event Management — Logging and Filtering

Service
Transition
Exception
Filter Warning
Information
Events occur continuously, but not all of them are detected or registered.
Once an Event Notification has been generated, it will be detected by an agent
running on the same system, or transmitted directly to a management tool specifically
designed to read and interpret the meaning of the Event.
Filtering then occurs, to decide whether to continue treating the Event or to ignore it.
If ignored, the Event will usually be recorded in a log file on the device, but no
further action will be taken.
If not ignored, the first level of correlation is performed, i.e. the determination of
whether the Event is Informational, a Warning, or an Exception (see next
pages). This correlation is usually done by an agent that resides on the CI or on
a server that the CI is connected to.
The filtering step is not always necessary. For some CIs, every Event is significant and
moves directly into a management tool’s correlation engine, even if it is duplicated.
Also, it may have been possible to turn off all unwanted Event notifications.

Event Management — Managing Exceptions

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Event Management — Managing Exceptions

Service
Transition
Incident Incident
Management
Incident/
Problem Problem
Exception Problem/
Change
Management
RFC Change
Management
Every organization will have its own categorization of the significance of an Event,
but it is suggested that at least these 3 broad categories be represented:
Informational
Warning
Exception
If the output of Filtering is an Exception, it means that a service or device is currently
operating abnormally (however that has been defined).
Typically this means that an OLA and SLA have been breached and the Business is
being impacted. Exceptions could represent a total failure, impaired functionality or
degraded performance.
Please note, though, that an Exception does not always represent an
Incident/Problem. For example, an exception could be generated when an
unauthorized device is discovered on the network. This can be managed by using
either an Incident Record or a Request for Change (or even both) depending on the
organization’s Incident and Change Management policies.

Examples of Exceptions include:

A server is down
Response time of a standard transaction across the network has slowed to more
than 15 seconds
More than 150 users have logged on to the General Ledger application
concurrently
A segment of the network is not responding to routine requests

Event Management — Information and Warnings

Event Management —
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Information and Warnings

Service
Transition
Incident
Incident/
Do any one or Problem/ Problem
Change
combination of
… RFC
Alert Human
Intervention
Warning
Auto Response
Information Log
If the output of Filtering is Informational, it refers to an Event that does not require any
action, and does not represent an exception. They are typically stored in the system
or service log files and kept for a predetermined period.
Informational Events are typically used:
To check on the status of a device or service
To confirm the successful completion of an activity
To generate statistics, such as the number of users logged on
As an input to investigations, such as which jobs completed successfully before
the transaction processing queue hung
Examples of Informational Events include:
A device has come online
A job in the batch queue completes successfully
A user logs onto an application
A transaction is completed successfully

If the output of Filtering is a Warning, it is an Event that is generated when a service

or device is approaching a threshold.
Warnings are intended to notify the appropriate person, process or tool so that the
situation can be checked and the appropriate action taken to prevent an exception.
Warnings are not typically raised for a device failure, although there is some debate
about whether the failure of a redundant device is a Warning or Exception (since the
service is still available). A good rule is that every failure should be treated as an
Exception, since the risk of an Incident impacting the Business is much greater.
Examples of Warnings Events include:
Memory utilization on a server is currently at 65% and increasing. If it reaches
75% response times will be unacceptably long and the OLA for that department
will be breached
The collision rate on a network has increased by 15% over the past hour and the
threshold is 30%
Alert and human intervention

If the Event requires human intervention it will need to be escalated via an alert. The
purpose of the alert is to ensure that the person with the skills appropriate to deal
with the Event is notified. Example: changing a toner cartridge in a printer when the
level is low.

Event Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Event Management — Roles

Service
Transition
• Event management roles are

filled by people in the
following functions
– Service Desk
– IT Operations Management
It is unusual for an organization to appoint an “Event Manager”, as events tend to

occur in multiple contexts and for many different reasons. However, it is important
that Event Management procedures are coordinated to prevent duplication of effort
and tools. The roles of the Service Operation Functions in Event Management are as
follows:
The Role of the Service Desk function - The Service Desk is not typically involved
in Event Management as such, unless an event requires some response that is
within the scope of the Service Desk’s defined activity, for example notifying a
user that a report is ready.
The Role of Technical and Application Management functions - Technical
management has expertise in the infrastructure and application management
has expertise in the application. They play several important roles as follows:
• During Service Design, they will participate in the instrumentation of the
service, classify Events, update correlation engines, and ensure that any
auto responses are defined
• During Service Transition they will test the service to ensure that Events are
properly generated and that the defined responses are appropriate

• During Service Operation these teams will typically perform Event

Management for the systems under their control
• Involvement in dealing with Incidents and Problems related to Events
• If Event 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
The Role of IT Operations Management function - Where IT Operations is
separated from Technical or Application Management, it is common for Event
Monitoring and first-line response to be delegated to IT Operations
Management. Operators for each area will be tasked with monitoring Events,
responding as required, or ensuring that Incidents are created as appropriate.
The instructions for how to do so must be included in the Standard Operating
Procedures for those teams.

Incident Management
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management
Service
Transition
• Objectives
• Scope
• Business value
• Basic concepts
• Activities
• Interfaces
• Key metrics
• Roles
• Challenges

Incident Management — Objective

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Objective

Service
Transition
• To restore normal service operation as quickly as possible

and minimize adverse impact on the business
The primary goal of the Incident Management process is to restore normal service
operation as quickly as possible and minimize the adverse impact on business
operations, thus ensuring that the best possible levels of service quality and
availability are maintained.
‘Normal service operation’ is defined here as service operation within Service Level
Agreement (SLA) limits.

Incident Management — Scope

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Scope

Service
Transition
• Managing any disruption or potential disruption to live IT

services
• Incidents are identified
– Directly by users through the Service Desk
– Through an interface from Event Management to Incident
Management tools
• Reported and/or logged by technical staff
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 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 (see previous section).
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 customer’s needs and may be
addressing an agreed target in a Service Level Agreement. Service Requests are
dealt with by the Request Fulfillment process (see next section).

Incident Management — Business value

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Business value

Service
Transition
• Quicker incident resolution

• Improved quality
• Reduced support costs
The business value of Incident Management includes:

Quicker incident resolution — Lower downtime to the business, which in turn
means higher availability of the service.
Improved quality — Ability to identify potential improvements to Services. This
happens as a result of understanding what constitutes an Incident and also from
being in contact with the activities of Business operational staff.
Reduced support costs — Capability to identify business priorities and
dynamically allocate the right resources as necessary, therefore avoiding
resource misuse.
Incident Management is highly visible to the business, and it is therefore easier to
demonstrate its value than most areas in Service Operation. For this reason, Incident
Management is often one of the first processes to be implemented in Service
Management projects. The added benefit of doing this is that Incident Management
can be used to highlight other areas that need attention – thereby providing a
justification for expenditure on implementing other processes.

Incident Management — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Basic concepts

Service
Transition
• An Incident
– An unplanned interruption or reduction in the quality of an IT
Service
– Any event which could affect an IT Service in the future is also
an Incident
• Timescales
• Incident Models
• Major Incidents
Incident
In ITIL terminology, an ‘Incident’ is defined as: “An unplanned interruption to an IT
service or reduction in the quality of an IT service”.
Any Event, such as a failure of a configuration item that has not yet impacted service
is also an Incident. For example failure of one disk from a mirror set.
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 Service Level Agreements – and captured as
targets within Operational Level Agreements and Underpinning Contracts. All
support groups should be made fully aware of these timescales.

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 predefine ‘standard’ incident models – and apply them to
appropriate incidents when they occur. An incident model is a way of predefining
the steps that should be taken to handle a process (in this case a process for dealing
with a particular type of incident) in an agreed way. 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 co processing defined
Responsibilities; who should do what
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’.

Incident Management — Activities

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Activities

Service
Transition
From Event Mgmt From Web Interface User Phone Call Email Technical Staff
Incident Identification
Incident Logging
Incident Categorization
Yes
Service Request? To Request Fulfilment
No
Incident Prioritization
Yes
Major Incident Procedure Major Incident?
No
Initial Diagnosis
Yes Yes Functional Escalation

Functional Escalation
Needed? 2/3 Level
Yes Hierarchic Escalation
Management Escalation No
Needed?
No Investigation & Diagnosis
Resolution and Recovery
Incident Closure
End
The process to be followed during the management of an includes the following

steps:
Identification
Logging
Categorization
Prioritization
Initial diagnosis
Escalation
Investigation and diagnosis
Resolution and recovery
Closure

Incident identification
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 so that
the incident management process can be started quickly.
Incident logging
All incidents must be fully logged and date/time stamped, regardless of whether they
are raised through a Service Desk telephone call or whether automatically detected
via an event alert.
All relevant information relating to the nature of the incident must be logged so that a
full historical record is maintained. The information needed for each incident is likely
to include:
Unique reference number
Incident categorization (often broken down into between 2-4 levels of sub
categories)
Incident urgency, impact, priority
Date/time recorded
Name/id of the person and/or group recording the Incident
Name/department/phone/location of user
Description of symptoms
Incident status (active, waiting, closed etc.)
Related Configuration Item
Support group/person to which the Incident is allocated
Related Problem/Known Error
Activities undertaken to resolve the incident
Resolution date and time
Closure category
Closure date and time

Incident categorization
Part of the initial logging must be to allocate suitable incident categorization coding
so that the exact type of the call is recorded. Multi-level categorization is available in
most tools – usually to three or four levels of granularity. For example an incident may
be categorized as:
Hardware
• Server
Memory Board
• Cell Card Failure
Or:
Software
• Application
Finance Suite
• Purchase Order System
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 impact it
is causing.
An effective way of calculating these elements and deriving an overall priority level
for each incident is given in the simple table below:
Impact
High Medium Low
High 1 2 3
Urgency Medium 2 3 4
Low 3 4 5
Priority Code Description Target Resolution Time

1 Critical 1 hour
2 High 8 hours
3 Medium 24 hours
4 Low 48 hours
5 Planning As planned

Initial diagnosis
If the incident has been routed via the Service Desk, the Service Desk Operator must
carry out initial diagnosis, typically while the user is still on the telephone - if the call
is raised in this way, to try and 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.
If the Service Desk Operator 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 assistance from other support groups, they should
inform the user of their intentions, give the user the incident reference number, and
attempt to find a resolution.
Incident escalation
1. Functional escalation
As soon as it becomes clear that the Service Desk is unable to resolve the
incident themselves or when target times for first point resolution have been
exceeded (whichever comes first), the incident must be immediately escalated for
further support (second-level, third-level support group, external vendors, etc.).
Note
Incident Ownership remains with the Service Desk! Regardless of where an
incident is referred to during its life, ownership of the incident remains with the
Service Desk at all times. The Service Desk remain responsible for tracking
progress, keeping users informed and ultimately for incident closure.
2. Hierarchic escalation
If incidents are of a serious nature, 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.

Investigation and diagnosis

In the case of incidents where the user is just seeking information, the Service Desk
should be able to provide this fairly quickly and resolve the service request – but if a
fault is being reported this is an incident and likely to require some degree of
investigation and diagnosis. Each of the support groups involved with the incident
handling will investigate and diagnose what has gone wrong – and all such activities
should be fully documented.
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.
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:
Assign correct Closure Categorization
Conduct a User Satisfaction Survey
Create/review useful Incident Documentation
Determine (in conjunction with resolver groups) whether it is likely that the
incident could recur and decide whether any preventative action is necessary to
avoid this. In conjunction with Problem Management, raise a problem record in
all such cases so that preventative action is initiated.
Formally Close the Incident record

Incident Management — Interfaces

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Interfaces

Service
Transition
• Problem Management
• Service Asset and Configuration Management (SACM)
• Change Management
• Capacity Management
• Availability Management
• Service Level Management
• Event Management
The interfaces with Incident Management include:

Problem Management: Incident Management forms part of the overall process of
dealing with problems in the organization. Incidents are often caused by
underlying problems, which must be solved to prevent the incident from
recurring.
Service Asset and Configuration Management: Provides the data used to identify
and progress incidents. One of the uses of the Configuration Management
System (CMS) is to identify faulty equipment and to assess the impact of an
incident. The CMS also contains information about which categories of incident
should be assigned to which support group. In turn, Incident Management can
maintain the status of faulty CIs.
Change Management: Where a change is required to implement a workaround
or resolution, this will need to be logged as an RFC and progressed through
Change Management. In turn, Incident Management is able to detect and
resolve incidents that arise from failed changes.
Capacity Management: Incident Management provides a trigger for
performance monitoring where there appears to be a performance problem.
Capacity Management may develop workarounds for incidents.

Availability Management: Will use incident management data to determine the

availability of IT services and look at where the incident lifecycle can be
improved.
Service Level Management (SLM): The ability to resolve incidents in a specified
time is a key part of delivering an agreed level of service. Incident Management
enables SLM to define measurable responses to service disruptions. SLM defines
the acceptable levels of service within which Incident Management works,
including:
• Incident response times
• Impact definitions
• Target fix times
• Service definitions, which are mapped to users
• Rules for requesting services
• Expectations for providing feedback to users
Event Management: Events may trigger incidents

Incident Management — Key metrics

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Key metrics

Service
Transition
• Total number of incidents (as a control measure)

• Breakdown of incidents at each stage (for example, logged,
WIP, closed, etc.)
• Size of incident backlog
• Mean elapsed time to resolution
• % resolved by the Service Desk (first-line fix)
• % handled within agreed response time
• % resolved within agreed Service Level Agreement target
• No. and % of Major Incidents
• No. and % of incident correctly assigned
• Average cost of incident handling
The metrics that should be monitored and reported upon to judge the efficiency and
effectiveness of the Incident Management process, and its operation, can be seen in
the slide.
Reports should be produced under the authority of the Incident Manager, who should
draw up a 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.

Incident Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Roles

Service
Transition
• Incident Manager
– May be performed by Service Desk Supervisor
• Super Users
• First-Line Support
– Usually Service Desk Analysts
• Second-Line Support
• Third-Line Support (Technical Management, IT Operations,
Application Management, Third-party suppliers)
Incident Manager
An Incident Manager has the responsibility for:
Monitoring and driving the efficiency and effectiveness of the Incident
Management process and making recommendations for improvement
Producing management information
Managing the work of Incident support staff (first-and second-line)
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 – though 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 1st, 2nd and 3rd line.

‘Super Users’
This role will consist of business users who act as liaison points with IT in general and
the Service Desk in particular. The role of the Super User can be summarized as
follows:
To facilitate communication between IT and the Business at an operational level
To reinforce expectations of users regarding what Service Levels have been
agreed
Staff training for users in their area
Providing support for minor incidents or simple request fulfillment
Involvement with new releases and roll-outs
First-line support
The primary Service Desk analyst role is that of providing first-line support through
taking calls and handling the resulting incidents or service requests using the incident
and request fulfillment processes.
Second-line support
Many organizations will 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.
Third-line support
Third-line support will be provided by a number of internal technical groups and/or
third party suppliers/maintainers. The list will vary from organization to organization
but is likely to include:
Network Support and Voice Support (if separate)
Server Support and Desktop Support
Application Management – likely that there may be separate teams for different
applications or application types – some of which may be external
supplier/maintainers.
Database Support
Hardware Maintenance Engineers
Environmental Equipment Maintainers/Suppliers

Incident Management — Challenges

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Incident Management — Challenges

Service
Transition
• Ability to detect incidents as quickly as possible (dependency

on Event Management)
• Ensuring all incidents are logged
• Ensuring previous history is available (Incidents, Problems,
Known Errors, Changes)
• Integration with Configuration Management System, Service
Level Management, and Known Error Database (CMS, SLM,
KEDB)
The following challenges will exist for successful Incident Management:

The ability to detect Incidents as early as possible. This will require education of
the users reporting Incidents, the use of Super Users, and the configuration of
Event Management tools (see previous sections)
Convincing all staff (technical teams as well as users) that all incidents must be
logged, and encouraging the use of self-help web-based capabilities (which can
speed up assistance and reduce resource requirements)
Availability of information about Problems and Known Errors. This will enable
Incident Management staff to learn from previous Incidents and also to track the
status of resolutions
Integration with the Configuration Management System to determine
relationships between CIs, and to refer to the history of CIs when performing
first-line support
Integration with the Service Level Management process. This will assist Incident
Management to correctly assess the impact and priority of Incidents, and assists
in defining and executing escalation procedures
Integration with Known Error Database (KEDB) to improve first-line fix rates

Request Fulfillment
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Request Fulfillment
Service
Transition
• Objectives
• Basic concepts
• Roles

Request Fulfillment — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Request Fulfillment — Objectives

Service
Transition
• To provide a channel for users to request and receive

standard services for which a pre defined approval and
qualification process exists
• To provide information to users and customers about the
availability of services and the procedure for obtaining them
• To source and deliver the components of requested standard
services (for example licenses and software media)
• To assist with general information, complaints or comments

Request Fulfillment — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Request Fulfillment — Basic concepts

Service
Transition
• Service Request
– A request from a User for information or advice, or for a
Standard Change. For example
• To reset a password, or to provide standard IT Services for a new
User.
• Request Model
Service request
The term ‘service request’ is used as a generic description for many varying types of
demands that are placed upon the IT department by the users. Many of these are
actually small changes – low risk, frequently occurring, low cost etc. For example:
A request to change a password
A request to install an additional software application onto a particular
workstation
A request to relocate some items of desktop equipment
A question requesting information
But their scale, frequency and low risk nature means that they are better handled by
a separate process, rather than being allowed to congest and obstruct the normal
incident and change management processes.

Request Models
Many service requests will be frequently recurring, so a predefined process-flow (a
model) can be devised to include the stages needed to fulfill the request, the
individuals or support groups involved, target timescales and escalation paths.
To assist with this, many organizations will wish to create predefined Request Models
(which typically include some form of pre-approval by Change Management). This is
similar in concept to the idea of Incident Models already described in the previous
section, but applied to service requests. Such Service Requests will usually be
satisfied by implementing a standard change. The ownership of service requests
resides with the service desk, which monitors, escalates, dispatches and often fulfils
the user request.

Self Help
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Self Help Significant opportunity to:

Service
Transition
–Improve responsiveness
–Reduce costs
–Extend hours of service
–Reduce demand on IT staff
Web based front end –Improve quality
menu driven shopping
cart experience
Incident Management
Request Fulfillment
Change Management
Deployment
Access Management
Asset or
CMBD
Request fulfillment offers great opportunities for self-help practices where users can
generate a service request using technology that links into service management tools.
Ideally users should be offered a ‘menu’ type selection via a web interface so that
they can select and input details of service requests from a predefined list –where
appropriate expectations can be set by giving target delivery and/or implementation
targets/dates (in line with SLA targets).
Where organizations are offering a Self-Help IT support capability to the users, for
Incident, Change and/or Access Management, it would make sense to combine this
with a Request Fulfillment system as described.
Specialist web tools to offer this type of ‘shopping cart’ experience can be used and
interfaces directly to the back-end integrated ITSM tools, or other more general
business process automation or ERP/CRM tools that may be used for management of
the request fulfillment activities.
A Request Fulfillment system offers significant opportunities to:
Improve Responsiveness
Reduce Costs
Extend Hours of Service
Reduce demand on IT staff
Improve Quality

Request Fulfillment — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Request Fulfillment — Roles

Service
Transition
• Not usually dedicated staff

• Service Desk staff
• Incident Management staff
• Service Operations teams
In most cases there will be no need for additional roles or posts to be created
exclusively to Request Fulfillment.
Initial handling of Service Requests will be undertaken by the Service Desk and
Incident Management staff.
Eventual fulfillment of the 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
fulfillment of the service request.
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.

Problem Management
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Problem Management
Service
Transition
• Objectives
• Basic concepts
• Roles

Problem Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Problem Management — Objectives

Service
Transition
• To prevent problems and resulting Incidents from happening

• To eliminate recurring incidents
• To minimize the impact of incidents that cannot be prevented
Problem Management is the process responsible for managing the Lifecycle of all
Problems.

Problem Management — Basic concepts (1 of 2)

Problem Management —
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Basic concepts (1 of 2)
Service
Transition
• Problem
– The cause of one or more incidents
• Problem Models
• Workaround
• Known Error
• Known Error Database
Problem
ITIL defines a ‘Problem’ as the cause of one or more incidents.
Problem Models
Many problems will be unique and will require handling in an individual way – but it
is conceivable that some incidents may re-occur 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 Known Error
Database 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 Models, already described, but applied to Problems as well as Incidents.
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 on a permanent resolution continues where this is
justified – in this example the reason why the file became corrupted in the first place
must be found and corrected to prevent this happening again.

Known Error
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 Known Error Database – so that if further incidents
or problems arise they can be identified and the service restored more quickly.
However, in some cases it may be advantageous to raise a Known Error record even
earlier in the overall process – just for information purposes for example - even
though the diagnosis may not be complete or a workaround found – so it is
inadvisable to set a concrete procedural point 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 Known Error Database 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.
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
existence of the problem. It will however still be desirable to diagnose and implement
a workaround as quickly as possible, which is where the KEDB can be of assistance.

Problem Management — Basic concepts (2 of 2)

Problem Management —
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service
Transition
• Reactive Problem Management

– Resolution of underlying cause(s)
– Covered in Service Operation
• Pro-active Problem Management
– Prevention of future problems
– Generally undertaken as part of CSI
Problem Management consists of two major processes:

Reactive Problem Management, which is generally executed as part of Service
Operation – and is therefore covered in this section (see next figure)
Proactive Problem Management which is initiated in Service Operation, but
generally driven as part of Continual Service Improvement

Proactive Problem
Service Desk Event Management Incident Management Management Supplier or Contractor
Problem Detection
Problem Logging
Categorization
Prioritization
Investigation & CMS

Diagnosis
Workaround?
Create Known
Error Record Known Error
Database
Yes
Change Management Change Needed?
No
Resolution
Closure
Major Problem? Major Problem Review
End

Reactive Problem Management Process Flow

Problem Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Problem Management — Roles

Service
Transition
• Problem Manager
• Supported by technical groups
– IT Operations
– Third-party suppliers
The following roles are needed for the Problem Management process:
Problem Manager
There should be a designated person (or in larger organizations, a team) responsible
for Problem Management. Smaller organizations may not be able to justify a full time
resource for this role, and it can be combined with other roles in such cases, but it is
essential that it not just left to technical resources to perform. There needs to be a
single point of coordination and an owner of the Problem Management process.
This role will coordinate all problem management activities and will have specific
responsibility for:
Liaison with all problem resolution groups to ensure swift resolution of problems
within SLA targets
Ownership and protection of the Known Error Database
Gatekeeper for the inclusion of all Known Errors and management of search
algorithms
Formal closure of all Problem records

Liaison with suppliers, contractors etc to ensure that third parties fulfill their
contractual obligations, especially with regards to resolving problems and
providing problem-related information and data
Arranging, running, documenting and all follow-up activities relating to Major
Problem Reviews
Technical support groups

The actual solving of problems is likely to be undertaken by one or more technical
support groups (Problem Solving Groups) and/or suppliers or support contractors –
under the coordination of the Problem Manager.
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 Manager 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.

Access Management
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Access Management
Service
Transition
• Objectives
• Basic concepts
• Roles

Access Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Access Management — Objectives

Service
Transition
• Granting authorized users the right to use a service

• Preventing access by non-authorized users
Access Management provides the right for users to be able to use a service or group
of services, thus preventing access to non-authorized users.
It is therefore the execution of policies and actions defined in Information Security
Management and Availability Management.

Access Management — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Access Management — Basic concepts

Service
Transition
• Access
• Identity
• Rights
• Service or Service Groups
• Directory Services
Access Management is the process that enables users to use the services that are
documented in the Service Catalog. It comprises the following basic concepts:
Access refers to the level and extent of a service’s functionality or data that a
user is entitled to use.
Identity refers to the information about the user 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 (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.
Services or Service groups. Most users do not only use 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 refers to a specific type of tool that is used to manage access
and rights.

Access Management activities

Requesting Access — Access (or restriction) can be requested using one of any
number of mechanisms, including:
• A standard request generated by the Human Resource system.
• A Request for Change
• A Service Request submitted via the Request Fulfillment system
• By executing a pre-authorized script
Verification — Access Management needs to verify every request for access to
an IT Service from two perspectives:
• That the User requesting access is who they say they are – for example,
providing their username and password.
• That they have a legitimate requirement for that Service – for example,
authorization from an appropriate (defined in the process) manager
Providing Rights — Access Management does not decide who has access to
which IT Services. Rather Access Management executes the policies and
regulations defined during Service Strategy and Service Design. Access
Management enforces decisions to restrict or provide access, rather than making
the decision. As soon as a User has been verified, Access Management will
provide that User with rights to use the requested Service.
Monitoring Identity Status — As Users work in the organization their roles
change and so also do their needs to access Services. Examples of such
changes include: job changes, promotions/demotions, transfers,
resignation/death, retirement, disciplinary action and dismissals.
Logging and Tracking Access — Access Management should not only respond
to requests. It is also responsible for ensuring that the rights that they have
provided are being properly used.
Removing or Restricting Rights — Just as Access Management provide rights to
use a Service, they are also responsible for revoking those rights. Again, this is
not a decision that they make on their own. Rather, they will execute the
decisions and policies already. It is usually done in the following circumstances:
death, resignation, dismissal, when the User has changed roles and no longer
requires access to the Service, transfer or travel to a an area where different
regional access applies.

Access Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Access Management — Roles

Service
Transition
• Not usually dedicated staff

• Access management is an execution of Availability
Management and Information Security Management
• Service Desk staff
• Technical Management staff
• Application Management staff
• IT Operations staff
Since Access Management is an execution of Security and Availability Management,

these two areas will be responsible for defining the appropriate roles.
It is unusual for an organization to appoint an “Access Manager”, although it is
important that there is a single Access Management process and a single set of
policies related to managing rights and access.
This process and the related policies are likely to be defined and maintained by
Information Security Management, and executed by the various Service Operation
functions. Their activities can be summarized as follows:
The Role of the Service Desk — Is typically used as a means to request access to
a service. This is normally done using a Service Request. The Service Desk will
validate the request by checking that the request has been approved at the
appropriate level of authority, that the user is a legitimate employee, contractor
or customer and that they qualify for access. Once they have performed these
checks they will pass the request to the appropriate team to provide access.

The Role of Technical and Application Management — They play several

important roles as follows:
• During Service Design, they will ensure that mechanisms are created to
simplify and control Access Management on each service that is designed.
They will also specify ways in which abuse of rights can be detected and
stopped.
• During Service Transition they will test the service to ensure that access can
be granted, controlled and prevented as designed.
• 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 is adequately trained and that they have access to the
appropriate tools to enable them to perform these tasks.
The Role of IT Operations Management — Where IT Operations is separated
from Technical or Application Management it is common for operational Access
Management tasks to be delegated to IT Operations Management. Operators
for each area will be tasked with providing or revoking access to key systems or
resources. The circumstances under which they may do so and the instructions
for how to do so must be included in the Standard Operating Procedures for
those teams.

Service Operation functions

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Operation functions

Service
Transition
Service Desk
IT Operations
Management
Technical Application
Management Management
Operations Control
Facilities Management
Some organizations may choose to perform operational activities as part of the

Technical Management and Application Management functions, whereas others
prefer to delegate these to a centralized IT Operations Management functions.

The following Service Operation functions are needed to manage the ‘steady state’
operational IT environment.
IT Operations Management
Technical IT Operations Control

Application
Service Desk Management Console Management Management
Job Scheduling
Backup and Restore
Financial Apps
Mainframe Print and Output
Facilities Management
Server HR Apps
Data Centres
Recovery Sites
Consolidation
Network Business Apps
Contracts
Storage
Database
Directory
Services
Desktop
Middleware
Internet/Web

Service Operation Functions
These are logical functions and do not necessarily have to be performed by an

equivalent organizational structure. This means that Technical and Application
Management can be organized in any combination and into any number of
departments. The second level groupings in the above figure are examples of typical
groups of activities performed by Technical Management (to be seen later on) and
are not a suggested organization structure.

Service Desk
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Desk
Service
Transition
• Primary point of contact

• Deals with all user issues (incidents, requests, standard
changes)
• Coordinates actions across the IT organization to meet user
requirements
• Different options (Local, Centralized, Virtual, Follow-the-Sun,
specialized groups)
A Service Desk is a functional unit made up of a dedicated number of staff

responsible for dealing with a variety of service events, often made via telephone
calls, web interface, or automatically reported infrastructure events.
The Service Desk is a vitally important part of an organization’s IT Department and
should be the single point of contact for IT users on a day-by-day basis – and will
handle all incidents, service requests, standard changes, usually using specialist
software tools to log and manage all such events.
The value of an effective Service Desk should not be underrated – 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 IT organization!
It is therefore very important that the correct caliber of staff is 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 Service Desk coordinates actions across all IT departments, on behalf of the user,
keeping communication flowing back and forth.

The exact nature, type, size and location of a Service Desk will vary, depending
upon the type of business, number of users, geography, complexity of calls, scope of
services and many other factors, but in alignment to customer and business
requirements. 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:
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 staff is tied up waiting to deal with incidents, when the
volume and arrival rate of calls may not justify this.
User User User User
Service Desk
Technical Application IT Operations 3rd Party Request

Management Management Management Support Fulfilment

Local Service Desk

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 because of 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.
Customer Site 1 Customer Site 2 Customer Site 3
Service Desk
Second Line
Support


Centralized 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 group, off-shoring 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.
Virtual Service Desk
San Francisco
Service Desk
Paris
Service Desk Rio de
Janeiro
Service Desk
Virtual
Service Desk
Sydney
Beijing Service Desk
Service Desk
Service
Knowledge
Management
System
London
Service Desk


Follow-the-Sun — Some global or international organizations may wish to

combine two or more of its geographically dispersed service desks to provide a
24 hour follow-the-sun service. For example, a Service Desk in Asia-Pacific may
handle calls during its standard office hours and at the end of this period they
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.
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 “If your call is about the nnnn Service please press 1 now,
otherwise please hold for a Service Desk analyst”. Care is needed not to over
complicate 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.

Local Service Desk

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Local Service Desk

Service
Transition
User User User User
Service Desk



Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL

Service
Transition
Customer Site 1 Customer Site 2 Customer Site 3
Service Desk
Second Line
Support



Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL

Service
Transition
San Francisco
Service Desk
Paris
Service Desk Rio de
Janeiro
Service Desk
Virtual
Service Desk
Sydney
Beijing Service Desk
Service Desk
Service
Knowledge
Management
System
London
Service Desk

Service Desk objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Desk objectives

Service
Transition
• Logging and categorizing Incidents, Service Requests and

some categories of change
• First line investigation and diagnosis
• Escalation
• Communication with Users and IT Staff
• Closing calls
• Customer satisfaction
• Update the CMS if so agreed
The primary aim of the Service Desk is to restore the ‘normal service’ 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
Providing first-line investigation and diagnosis, and possibly resolving those
incidents/service requests they are able
Escalating incidents/service requests that they cannot resolve within agreed
timescales
Communication with users — keeping users informed of progress, notifying them
of impending changes or agreed outages etc.
Closing all resolved Incidents, Requests and other calls

Conducting customer/user satisfaction call-backs/surveys as agreed

Updating the CMS under the direction and approval of Configuration
Management if so agreed
Note
These activities are explained and set in context with the fuller Incident
Management and Request Fulfillment process in previous sections.
Configuration Management System (CMS) — A set of tools and databases that are
used to manage an IT Service Provider's Configuration data. The CMS also includes
information about Incidents, Problems, Known Errors, Changes and Releases; and
may contain data about employees, Suppliers, locations, Business Units, Customers
and Users. The CMS includes tools for collecting, storing, managing, updating, and
presenting data about all Configuration Items and their Relationships. The CMS is
maintained by Configuration Management and is used by all IT Service
Management Processes. See Configuration Management Database, Service
Knowledge Management System.

Service Desk staffing

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Desk staffing

Service
Transition
• Correct number and qualifications at any given time,

considering:
– Customer expectations and business requirements
– Number of users to support, their language and skills
– Coverage period, out-of-hours, time zones/locations, travel time
– Processes and procedures in place
• Minimum qualifications
– Interpersonal skills
– Business understanding
– IT understanding
– Skill sets
• Customer and Technical emphasis, Expert
An organization must ensure that the correct number of staff is available at any given
time to match the demand being placed upon the desk by the business. Call rates
can be very volatile and often in the same day the arrival rate may go from very
high to very low and back again.
An organization planning a new desk should attempt to predict the call arrival rate
and profile – and to staff accordingly. Statistical analysis of call arrival rates under
current support arrangements must be undertaken and then closely monitored and
adjusted as necessary.
Many organizations will find that call rates peak during the start of the office day
and then fall off quickly, perhaps with another burst in the early part of the afternoon
— this obviously varies depending upon the organization’s business but is an often
occurring pattern for many organizations. In such circumstances it may be possible to
utilize part-time staff, home-workers, second-line support staff or third parties to cover
the peaks.

The following factors should be considered when deciding staffing levels:

Customer service expectations
Business requirements, such as budget, call response times, etc.
Size, relative age, design and complexity of the IT Infrastructure and Service
Catalog – for example, the number and type of incidents, the extent of
customized versus standard off-the-shelf software deployed, etc.
The number of customers and users to support, users speaking a different
language and their skill level
Incident and Service Request types (and types of RFC if appropriate):
• Duration of time required for call types
• Local or external expertise required
• The volume and types of incidents and Service Requests
The period of support cover required, based on hours covered, out-of-hours
support requirements, time zones to be covered, locations to be supported,
travel time between locations, workload pattern of requests, service level targets
in place, etc.
The type of response required, for example, telephone, e-
mail/fax/voicemail/video, physical attendance, online access/control
The level of training required
The support technologies available (for example, phone systems, remote support
tools, etc.)
The processes and procedures in use
The existing skill levels of staff. An organization must decide on the level and
range of skills it requires of its Service Desk staff – and then ensure that these
skills are available at the appropriate times. This will involve an ongoing training
and awareness program which should cover:
• Interpersonal skills: such as telephony and communication skills, active
listening and customer care training
• Business awareness: specific knowledge of the organization’s business
areas, drivers, structure, priorities, etc.
• Service awareness of all the organization’s key IT services for which support
is being provided
• Technical awareness (and deeper technical training to the appropriate level,
depending upon the resolution rate sought)

• Depending on level of support provided, some diagnosis skills

• Support tools and techniques
• Awareness training and tutorials in new systems and technologies, prior to
their introduction
• Processes and procedures (most particularly Incident, Change and
Configuration Management – but an overview of all ITSM processes and
procedures)
• Typing skills to ensure quick and accurate entry of incident or Service
Request details

Service Desk metrics

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service Desk metrics

Service
Transition
• Periodic evaluations of health, maturity, efficiency,

effectiveness and any opportunity to improve
• Realistic and carefully chosen – total number of call is not
itself good or bad
• Some examples:
– First-line resolution rate
– Average time to resolve and/or escalate an incident
– Total costs for the period divided by total call duration minutes
– The number of calls broken down by time of day and day of
week, combined with the average call-time
Metrics should be established so that performance of the Service Desk can be

evaluated at regular intervals. This is important to assess the health, maturity,
efficiency, effectiveness and any opportunities to improve Service Desk operations.
Metrics for Service Desk performance must be realistic and carefully chosen. It is
common to select those metrics that are easily available and that may seem to be a
possible indication of performance; however, this can be misleading.
For example, the total number of calls received by the Service Desk is not in itself an
indication of either good or bad performance and may in fact be caused by events
completely outside the control of the Service Desk – for example a particularly busy
period for the organization, or the release of a new version of a major corporate
system.
Further analysis and more detailed metrics are therefore needed and must be
examined over a period of time. These will include the call-handling statistics
previously mentioned under telephony, and additionally:
The first-line resolution rate: The percentage of calls resolved during the contact
with the Service Desk. This can be broken down further as follows:
• The percentage of calls resolved during the first contact with the Service
Desk, i.e. while the user is still on the telephone to report the call
• The percentage of calls resolved by the Service Desk staff themselves
without having to seek deeper support from other groups

Average time to resolve an incident (when resolved at first line) and average
time to escalate an incident (where first-line resolution is not possible)
Average Service Desk cost of handling an incident. Two metrics should be
considered here:
• Total cost of the Service Desk divided by the number of calls
• Total costs for the period divided by total call duration minutes
Percentage of customer or user updates conducted within target times, as
defined in SLA targets
Average time to review and close a resolved call
The number of calls broken down by time of day and day of week, combined
with the average call-time metric (critical in determining the number of staff
required)

Technical Management
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Technical Management
Service
Transition
• The groups, departments or teams that provide technical

expertise and overall management of the IT Infrastructure
– Custodians of technical knowledge and expertise related to
managing the IT Infrastructure
– Provide the actual resources to support the IT Service
Management Lifecycle
– Perform many of the common activities already outlined
– Execute most ITSM processes
Technical Management refers to the groups, departments or teams that provide

technical expertise and overall management of the IT Infrastructure.
Technical Management plays a dual role:
It is the custodian of technical knowledge and expertise related to managing the
IT Infrastructure. In this role it ensures that the knowledge required to design, test,
manage and improve IT services is identified, developed and refined.
It provides the actual resources to support the ITSM Lifecycle. 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.
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 organization

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Technical Management organization

Service
Transition
• Technical teams are usually aligned to the technology they

manage
• Can include operational activities
• Examples
– Mainframe management
– Server Management
– Internet/Web Management
– Network Management
– Database Administration
Technical Management is not normally provided by a single department or group.

One or more Technical Support teams or departments will be needed to provide
technical management and support for the IT Infrastructure. In all but the smallest
organizations where a single combined team or department may suffice, separate
teams or departments will be needed for each type of infrastructure being used.
The primary criterion of the Technical Management organizational structure is that of
Specialization or Division of Labor. The principle is that people are grouped
according to their technical skill sets, and that these skill sets are determined by the
technology that needs to be managed.
Some organizations may choose to perform operational activities as part of the
Technical Management and Application Management functions, whereas others
prefer to delegate these to a centralized IT Operations Management function.

The following list provides some examples of typical Technical Management teams or
departments:
Mainframe team or department – if one or more mainframe types are still being
used by the organization
Server team or department – often split again by technology types (for example
Unix Server, Wintel Server)
Storage team or department, responsible for the management of all data
storage devices and media
Network Support team or department, looking after the organizations internal
WANs/LANs and managing any external network suppliers
Desktop team or department, responsible for all installed desktop equipment
Database team or department, responsible for the creation, maintenance and
support of the organizations databases
Middleware team or department, responsible for the integration, testing and
maintenance of all middleware in use in the organization
Directory Services team or department, responsible for maintaining access and
rights to service elements in the infrastructure
Internet or Web team or department, responsible for managing the availability
and security of access to servers and content by external customers, users and
partners
Messaging team or department responsible for email services
IP based telephony team or department (for example Voice over IP)

Technical Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Technical Management — Objectives

Service
Transition
• Design of resilient, cost-

effective infrastructure
configuration
• Maintenance of the
infrastructure
• Support during technical
failures
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 infrastructure
configuration
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

Technical Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Technical Management — Roles

Service
Transition
• Technical Managers
• Team Leaders
• Technical Analysts/Architects
• Technical Operator
The following roles are needed in the Technical Management areas:

Technical Managers/Team-leaders -—A Technical Manager or Team-leader
(depending upon the size and/or importance of the team, and the
organization’s structure and culture) may be needed for each of the technical
teams or departments. The role will:
• Take overall responsibility for leadership, control and decision-making for
the technical team or department
• Provide technical knowledge and leadership in the specific technical areas
covered by the team or department
• Ensure necessary technical training, awareness and experience levels are
maintained within the team or department
• Report to senior management on all technical issues relevant to their area of
responsibility
• Perform line-management for all team or department members

Technical Analysts/Architects — This term refers to any staff member in

Technical Management who performs the activities such as:
• Identifying the knowledge and expertise required to manage the IT
Infrastructure
• Documentation of the skills that exist in the organization and skills to be
developed
• Initiating training programs to develop and refine the skills
• Design and delivery of training for users, the Service Desk and other groups
Based on the list of generic activities above, the role of Technical Analysts and
architects includes:
• Working with users, sponsors, Application Management and all other
stakeholders to determine their evolving needs
• Working with Application Management and other areas in Technical
Management to determine the highest level of system requirements required
to meet the requirements within budget and technology constraints
• Defining and maintaining knowledge about how systems are related and
ensuring that dependencies are understood and managed accordingly
• Performing cost-benefit analyses to determine the most appropriate means to
meet the stated requirements
• Developing Operational Models that will ensure optimal use of resources
and the appropriate level of performance
• Ensuring that the infrastructure is configured to be effectively managed
given the organization’s technology architecture, available skills and tools
• Ensuring the consistent and reliable performance of the infrastructure to
deliver the required level of service to the business
• Defining all tasks required to manage the infrastructure and to ensure that
these tasks are performed appropriately
• Providing input into the design of Configuration data required to manage
and track the application effectively
Technical Operator — This term is used to refer to any staff that perform day-to-
day operational tasks in Technical Management. Usually, these tasks are
delegated to a dedicated IT Operations team, and this role is therefore
discussed in the IT Operators section later on.

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Service
Transition
• The department, group or team of people responsible for

performing the organization’s day-to-day operational activities,
such as:
– Console Management
– Job Scheduling
– Backup and Restore
– Print and Output management
– Performance of maintenance activities
– Facilities Management
– Operations Bridge
– Network Operations Center
– Monitoring the infrastructure, applications and services
In business, the term ‘Operations Management’ is used mean the department, group
or team of people responsible for performing the organization’s day-to-day
operational activities – such as running the production line in a manufacturing
environment or managing the distribution centers and fleet movements within a
logistics organization.
In a similar way, IT Operations Management can be defined as the function
responsible for the ongoing management and maintenance of an organization’s IT
Infrastructure to ensure delivery of the agreed level of IT services to meet stated
Business Objectives.
Operations Control, an activity of IT Operations Management, oversees the execution
and monitoring of the operational activities and events in the IT Infrastructure and
performs the following 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
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
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
Operations Bridge which is a physical location where IT Services and IT
Infrastructure are monitored and managed
Network Operations Center which is a physical location where networks are
monitored and managed

IT Operations Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
IT Operations Management — Objectives

Service
Transition
• Maintaining the “status quo” to achieve infrastructure stability

• Identify opportunities to improve operational performance
and save costs
• Initial diagnosis and resolution of operational Incidents
The objectives of IT Operations Management include:

Maintenance of the ‘status quo’ to achieve stability of the organizations day-to-
day processes and activities. Sometimes, to maintain stability, some operational
procedures are required, for example, a table reorganization in a database, or
changes, such as patches applied to an operational system.
Regular scrutiny and improvements to achieve improved service at reduced costs,
whilst maintaining stability.
Swift application of operational skills to diagnose and resolve any IT operations
failures that occur.

IT Operations Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
IT Operations Management — Roles

Service
Transition
• IT Operations Manager
• Shift Leaders
• IT Operations Analysts
• IT Operators
The following roles are needed in the IT Operations Management area:

IT Operations Manager — Will be needed to take overall responsibility for all of
the IT Operations Management activities such as Operations Control and
Facilities Management. This role is to:
• Provide overall leadership, control and decision making and take
responsibility for the IT Operations Management teams and department
• Report to senior management on all IT Operations issues
• Perform line-management for all IT Operations team or department
managers/supervisors
Shift Leaders — Many IT Operations areas will work extended hours – on either
a two or three shift basis. In such cases a shift-leader will be needed on each of
the shifts to perform the following activities:
• Take overall responsibility for leadership, control and decision making
during the shift period
• Ensure that all operational activities are satisfactorily performed within
agreed timescales and in accordance with company policies and
procedures

• Liaise with the other shift leader(s) to ensure hand-over, continuity and
consistency between the shifts
• Act as line-manager for all Operations Analysts on his/her shift
• Assume overall health & safety, and security responsibility for the shift
(unless specifically designated to other staff members)
IT Operations Analysts—- Senior IT Operations staff who are able to determine
the most effective and efficient way to conduct a series of operations, usually in
high-volume, diverse environments. This role is normally performed as part of
Technical Management, but large organizations may find that the volume and
diversity of operational activities requires some more in-depth planning and
execution. Examples include Job Scheduling and the definition of a Back-up
strategy and schedule.
IT Operators — Staff who perform the day-to-day operational activities that are
defined in Technical or Application Management and, in some cases, IT
Operations Analysts. Typical Operator roles include:
• Performing Back-ups
• Console operations, i.e. monitoring the status of specific systems, job
queues, etc and providing 1st level intervention if appropriate
• Managing print devices, restocking with paper, toner, etc
• Ensuring that batch jobs, archiving, etc. are performed
• Running scheduled house-keeping jobs, such as database maintenance, file
clean-up, etc.
• Burning images for distribution and installation on new servers, Desktops or
laptops
• Physical installation of standard equipment in the data centre

Application Management
Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Application Management
Service
Transition
• Manages Applications throughout their Lifecycle

• Performed by any department, group or team managing and
supporting operational Applications
• Role in the design, testing and improvement of Applications
that form part of IT Services
• Involved in development projects, but not usually the same as
the Application Development teams
• Custodian of expertise for Applications
• Provides resources throughout the lifecycle
• Guidance to IT Operations Management
Application Management is responsible for managing Applications throughout their

Lifecycle.
The Application Management function is performed by any department, group or
team involved in managing and supporting operational Applications.
Application Management also plays an important role in the design, testing and
improvement of applications that form part of IT Services. As such they may be
involved in development projects, but are not usually the same as the Application
Development teams.
Application Management is to applications what Technical Management is to the IT
Infrastructure.
Application Management plays a role 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 play a dual role:
It is the custodian of technical knowledge and expertise related to managing
applications
It provides the actual resources to support the IT Service Management Lifecycle

Application Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Application Management — Objectives

Service
Transition
• Well designed, resilient, cost effective applications

• Ensuring availability of functionality
• Maintain operational applications
• Support during application failures
The objectives of Application Management are to support the organization’s 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
Assuring 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

Application Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
Service
Operation ITIL
Application Management — Roles

Service
Transition
• Application Manager/Team leaders

• Application Analyst/Architect
Note: Application Management teams are usually aligned to

the applications they manage
Application Managers/Team-leaders – This role should be considered for each

of the applications teams or departments. The role will:
• Take overall responsibility for leadership, control and decision-making for
the applications team or department
• Provide technical knowledge and leadership in the specific applications
support activities covered by the team or department
• Ensure necessary technical training, awareness and experience levels are
maintained within the team or department relevant to the applications being
supported and processes being used
• Involve ongoing communication with users and customers regarding
application performance and evolving requirements of the business
• Report to senior management on all issues relevant to the applications
being supported
• Perform line-management for all team or department members

Application Analyst/Architect - Application analysts and architects are

responsible for matching requirements to application specifications. Specific
activities include:
• Working with users, sponsors, and all other stakeholders to determine their
evolving needs
• Working with Technical Management to determine the highest level of
system requirements required to meet the requirements within budget and
technology constraints
• Performing cost-benefit analyses to determine the most appropriate means to
meet the stated requirement
• Developing Operational Models that will ensure optimal use of resources
and the appropriate level of performance
• Ensuring that applications are designed to be effectively managed given the
organization’s technology architecture, available skills and tools
• Developing and maintaining standards for application sizing, performance
modeling, etc
• Generating a set of acceptance test requirements, together with the
designers, test engineers, and the user, which determine that all of the high
level requirements have been met, both functional and manageability
• Input into the design of Configuration data required to manage and track
the application effectively
An appropriate number of Application Analysts will be needed for each of the
Application Management teams or department to perform their activities. Application
Management teams are usually aligned to the applications they manage.


Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL

Operation
Service
Transition
• CSI and Organizational Change

• CSI Model
• Measurements and metrics
• The 7 Step Improvement Process
• Continual Service Improvement roles:
– Service Manager
– Continual Service Improvement Manager

CSI and Organizational Change

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
CSI and Organizational Change

Operation
Service
Transition
• Successful CSI requires

organizational change
• Organizational change
presents challenges
• Use formal approaches to
address people-related issues:
– John Kotter’s “Eight steps to
transforming your
organization”
– Project Management
Successful ITSM requires an understanding of the way in which work is done and
putting in place a Program of Change within the IT organization. This type of
Change is, by its very nature, prone to difficulties. It involves people and the way
they work. People generally do not like to change; the benefits must be explained to
everyone to gain their support and to ensure that they break out of old working
practices.
Those responsible for managing and steering organizational change should
consciously address these softer issues. Using an approach such as John Kotter’s
'Eight steps to transforming your organization', coupled with formalized Project
Management skills and practices, will significantly increase the chance of success.
John P. Kotter, Professor of Leadership at Harvard Business School, investigated more
than 100 companies involved in, or having attempted a complex organizational
change program and identified 'Eight main reasons why transformation efforts fail'.
The main eight reasons, which are shown in the following figure, apply equally to IT
Service Management implementation programs.

[Steps]
‘…50% of transformations fail in this phase’

1 Creating a sense
‘…without motivation, people won’t help and the effort goes nowhere’
of urgency
‘…76% of company’s management should be convinced of the need’
‘…underestimating the difficulties in producing Change’

2
Forming a ‘…lack of effective, strong leadership’
guiding coalition ‘…not a powerful enough guiding coalition…opposition eventually stops the
Change initiative…’
‘…without a sensible vision transformation effort can easily dissolve into a list of
3
Creating a vision confusing, incompatible projects that can take the organization in the wrong direction,
or nowhere at all…’
‘…an explanation of 5 minutes should obtain reaction of ‘understanding’ and ‘interest’’
‘…without credible communication, and a lot of it, the hearts and minds of the
4 troops are never captured.’
Communicating the
vision ‘…make use of all communication channels’
‘…let managers lead by example..’”walk the talk”
‘…structures to underpin the vision…and removal of barriers to Change.’

5 ‘Empowering’ others to
‘…the more people involved, the better the outcome.’
act on the vision
‘…reward initiatives..’
6 ‘…real transformation takes time…without quick wins too many people give up
Planning for and
or join the ranks of those opposing Change’
creating quick wins
‘…actively look for performance improvements and establish clear goals..’
‘…communicate successes.’
‘…until Changes sink deeply into the culture new approaches are fragile and
7 Consolidating
subject to regression.’
improvements and
‘…in many cases workers revert to old practice.’
producing more Change
‘…use credibility of quick wins to tackle even bigger problems.’
8 ‘…show how new approaches, behaviour and attitude have helped improve
Institutionalising the
performance.’
Change
‘…ensure selection and promotion criteria underpin the new approach.’
Quotes

Eight reasons why transformation efforts fail

Continual Service Improvement Model

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Continual Service Improvement Model

Operation
Service
Transition
What is the Business vision,

mission, goals
vision? and objectives
Where are we Baseline

now? assessments
How do we keep Where do we Measurable

the momentum want to be? targets
going?
How do we Service and

process
get there? improvement
Did we Measurement
and
get there? metrics
As the above figure shows, there are many opportunities for CSI. The figure above
also illustrates a constant cycle for improvement. The improvement process can be
summarized in six steps:
Embracing the vision by understanding the high-level business objectives. The
vision should align the business and IT strategies.
Assessing the current situation to obtain an accurate, unbiased snapshot of
where the organization is right now. This baseline assessment is an analysis of
the current position in terms of the business, organization, people, process and
technology.
Understanding and agreeing on the priorities for improvement based on a
deeper development of the principles defined in the vision. The full vision may
be years away but this step provides specific goals and a manageable
timeframe.
Detailing the CSI plan to achieve higher quality Service provision by
implementing ITSM processes.
Verify that measurements and metrics are in place to ensure that milestones were
achieved, process compliance is high, and business objectives and priorities
were met by the level of service.
Finally, the process should ensure that the momentum for quality improvement is
maintained by assuring that changes become embedded in the organization.

An important beginning point for highlighting improvement is to establish baselines

as markers or starting points for later comparison. Baselines are also used to
establish an initial data point to determine if a Service or process needs to be
improved. As a result, it is important that baselines are documented, recognized and
accepted throughout the organization. Baselines must be established at each level:
strategic goals and objectives, tactical process maturity and operational metrics and
KPIs. If a baseline is not initially established the first measurement efforts will become
the baseline. That is why it is essential to collect data at the outset, even if the
integrity of the data is in question. It is better to have data to question than to have
no data at all.

What is Service Measurement?

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
What is Service Measurement?

Operation
Service
Transition
The ability to predict and report

service performance against
targets of an end-to-end service
• Will require someone to take
the individual measurements
and combine them to provide
a view of the customer
experience
• This data can be analyzed
over time to produce a trend
• This data can be collected at
multiple levels (for example,
CIs, processes, services)
Service Measurement is the ability to predict and report service performance against
the established target of achievements of an end-to-end service. Being able to
measure against a service is directly linked to the components, systems and
application that are being monitored and reported on. Service Measurement will
require someone to take the individual measurements and combine them to provide a
view of the true customer experience. Too often we provide a report against a
component, system or application but don’t provide the true Service Level as
experienced by the customer.
One of CSI’s key set of activities is to measure, analyze and report on IT Services
and ITSM results. Measurements will, of course, produce data. This data should be
analyzed over time to produce a trend. The trend will tell a story that may be good
or bad. It is essential that measurements of this kind have ongoing relevance. What
was important to know last year may no longer be pertinent this year
As part of the measuring process it is important to regularly confirm that the data
being collected and collated is still required and that measurements are adjusted
where necessary. This responsibility falls on the owner of each report or dashboard.
They are the individuals designated to keep the reports useful and to make sure that
something is being done with the results.

Why do we measure?
Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Why do we measure?
Operation
Service
Transition
To Validate To Justify
Strategic Vision Factual Evidence
Your Measurement Framework
To Intervene To Direct
Changes,
Targets and Metrics
corrective actions
Why do we measure?
To validate — monitoring and measuring to validate previous decisions
To direct — monitoring and measuring to set direction for activities in order to
meet set targets. It is the most prevalent reason for monitoring and measuring
To justify — monitoring and measuring to justify, with factual evidence or proof,
that a course of action is required
To intervene — monitoring and measuring to identify a point of intervention
including subsequent changes and corrective actions
The four basic reasons to monitor and measure lead to three key questions: “Why
are we monitoring and measuring?”, “When do we stop?” and “Is anyone using the
data?” To answer these questions, it is important to identify which of the above
reasons is driving the measurement effort. Too often, we continue to measure long
after the need has passed. Every time you produce a report you should ask, “Do we
still need this?”

Types of metrics
Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Types of metrics
Operation
Service
Transition
• Technology metrics: typically components and applications

For example
– Performance
– Availability
• Process metrics: Critical Success Factors (CSFs), Key
Performance Indicators (KPIs), activity metrics for ITSM
processes
• Service metrics: end-to-end service metrics
Critical Success Factor (CSF) — Something that must happen if a Process, Project,
Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each
CSF. For example a CSF of "protect IT Services when making Changes" could be
measured by KPIs such as "percentage reduction of unsuccessful Changes",
"percentage reduction in Changes causing Incidents" etc.
Key Performance Indicator (KPI) — A Metric that is used to help manage a Process,
IT Service or Activity. Many Metrics may be measured, but only the most important of
these are defined as KPIs and used to actively manage and report on the Process, IT
Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness,
and Cost Effectiveness are all managed.
See Critical Success Factor.
It is important to remember that there are three types of metrics that an organization
will need to collect to support CSI activities as well as other process activities. The
types of metrics are:
Technology metrics — These metrics are often associated with component and
application based 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. These metrics can help
determine the overall health of a process. Four key questions that KPIs can help
answer are around quality, performance, value and compliance of following the
process. CSI would use these metrics as input in identifying improvement
opportunities for each process.
Service metrics — These metrics are the results of the end-to-end service.
Component metrics are used to compute the Service metrics.

The 7 Step Improvement Process Purpose

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
The 7 Step Improvement Process Purpose

Operation
Service
Transition
• Fundamental to Continual
Service Improvement is the
concept of measurement
• The 7 Step Improvement Process
is designed to provide this
measurement

The 7 Step Improvement Process

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
The 7 Step Improvement Process

Operation
Service
Transition
Identify 1. Define what

Wisdom – Vision you should
– Tactical goals
– Operational goals
measure.
7. Implement 2. Define what

corrective you can
action. measure.
Goals
6. Present and use 3. Gather the data.
the information
assessment Who, how,
summary action when. Integrity
plans, etc. on the data?
5. Analyze the data. 4. Process the data.

Relationships, trends, Frequency,
according to plan, Data
Knowledge targets met, format, system,
corrective actions? accuracy.
Information
The 7 step improvement process is driven by the Strategy, Vision and Goals of the IT
organization and the business they serve. These need to be clearly identified and
understood in order to establish the correct decision-making framework, and to
ensure explicit agreement with the business.
Steps 1 and 2 are 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.
Steps 1 and 2 are 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.

Step 1 – Define what you should measure

Question: Where do you actually find the information?
Answer: Talk to the business, the customers and to IT management. Utilize the service
catalog as your starting point as well as the service level requirements of the different
customers. This is the place where you start with the end in mind. In a perfect world,
what should you measure? What is important to the business?
Compile a list of what you should measure. This will often be driven by business
requirements. Don’t try to cover every single eventuality or possible metric in the
world. Make it simple. The number of what you should measure can grow quite
rapidly. So too can the number of metrics and measurements.
Identify and link the following items:
Corporate vision, mission, goals and objectives
IT vision, mission, goals and objectives
Critical success factors
Service level targets
Job description for IT staffs
Inputs
Service level requirements and targets
Service Catalog
Vision and mission statements
Corporate, divisional and departmental goals and objectives
Legislative requirements
Governance requirements
Budget cycle
Balanced Scorecard

Step 2 – Define what you can measure

Every organization may find that they have limitations on what can actually be
measured. If you can not measure something then it should not appear in an SLA.
Question: What do you actually measure?
Answer: Start by listing the tools you currently have in place. These tools will include
service management tools, monitoring tools, reporting tools, investigation tools, and
others. Compile a list of what each tool can currently measure without any
configuration or customization. Stay away from customizing the tools as much as
possible; configuring them is acceptable.
Answer: The information is found within each process, procedure and work
instruction. The tools are merely a way to collect and provide the data. Look at
existing reports and databases. What data is currently being collected and reported
on?
Perform a gap analysis between the two lists. Report this information back to the
business, the customers and IT Management. It is possible that new tools are required
or that configuration or customization is required to be able to measure what is
required.
Inputs
List of what you should measure
Process flows
Procedures
Work instructions
Technical and user manuals from existing tools
Existing reports

Step 3 – Gather the data

The following figure shows the common procedures to follow in monitoring.
Define monitoring and

data collection requirements
Define frequency of monitoring

and data collection
Determine tool requirements

for monitoring and
data collection
Develop monitoring and

data collection procedures
Develop and communicate

monitoring
and data collection plan
Update availability and

capacity plans
Begin monitoring and

data collection

Monitoring and Data Collection Procedures
Outputs from “Gather the Data” activity

Updated Availability and Capacity Plans
Monitoring procedures
Identified tools to use
Monitoring plan
Input on IT capability
Collection of data
Agreement on the integrity of the data and that it makes sense

Step 4 – Process the data

This step converts the data into the required format and for the required audience.
Define processing
data requirements
Define frequency of data Process into

processing logical groupings
Determine format and tool Evaluate for

requirements for processing data accuracy
Develop processing
data procedures
Develop and communicate

processing data plan
Update availability and

capacity plans
Begin processing data

Procedure for Processing Data Activity
Outputs of Processing the Data activity

While it is important to identify the outputs of each activity such as data, decision it
is even more important to determine the output of the procedure, the level of detail,
the quality, the format, etc.
Examples of outputs from procedures:
Updated availability and capacity plans
Reports
Logical groupings of data ready for analysis

Step 5 – Analyze the data

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 really document the observations and conclusions.
Question: What do you actually analyze?
Answer: Once the data is processed into information, you can then analyze the
results, looking for answers to questions such as:
Are there any clear trends?
Are they positive or negative trends?
Are changes required?
Are we operating according to plan?
Are we meeting targets?
Are corrective actions required?
Are there underlying structural Problems?
What is the cost of the service gap?
Answer: Here you apply knowledge to your information. Without this, you have
nothing more than sets of numbers showing metrics that are meaningless. It is not
enough to simply look at this month’s figures and accept them without question, even
if they meet SLA targets. You should analyze the figures to stay ahead of the game.
Without analysis you merely have information. With analysis you have knowledge. If
you find anomalies or poor results, then look for ways to improve.
One of the major assumptions is that the automated processing/reporting tool has
actually done the analysis. Too often people simply “point” at a trend. “Look,
numbers have gone up over the last quarter”. However, key questions need to be
asked, questions such as:
Is this good?
Is this bad?
Is this expected?
Is this in line with targets?

Be sure to also compare against the clearly defined objectives with measurable
targets that were set in the Service Design, Transition and Operations lifecycle
stages. Confirmation needs to be sought that these objectives and the milestones
were reached. If not, have improvement initiatives been implemented? If so, then the
CSI activities start again from the gathering data, processing data, and analyzing
data to identify if the desired improvement in Service quality has been achieved. At
the completion of each significant stage or milestone, a review should be conducted
to ensure the objectives have been met. It is possible here to use the Post
Implementation Review (PIR) from the change management process. The PIR will
include a review of supporting documentation and the general awareness amongst
staff of the refined processes or Service. A comparison is required of what has been
achieved against the original goals.
During the analysis activity, but after the results are compiled and analysis and
trending has occurred, it is recommended that internal meetings be held within IT to
review the results and collectively identify improvement opportunities. It is important
to have these internal meetings before you begin presenting and using the
information which is the next activity of Continual Service Improvement. The result is
that IT is a key player in determining how the results and any actions items are
presented to the business. This puts IT in a better position of formulating a plan of
presenting the results and any action items to the Business and to Senior IT
Management.
When analyzing data, it is important to seek answers to questions such as:
Are operations running according to plan? – this could be a project plan,
financial plan, availability, capacity or even IT Service Continuity Management
plan.
Are targets defined in SLAs or the Service Catalog being met?
Are there underlying structural problems that can be identified?
Are corrective actions required?
Are there any trends? – If so then what are the trends showing?
Are they positive trends or negative trends?
What is leading to/causing the trends?
Trends are an indicator that more analysis is needed to understand what is causing
it. When a trend goes up or down it is a signal that further investigation is needed to
determine if it is positive or negative.
Throughout CSI, assessment should identify whether targets were achieved and, if so,
whether new targets (and therefore new KPIs) need to be defined. If targets were
achieved but the perception has not improved, then new targets may need to be set
and new measures put in place to ensure that these new targets are being met.

Step 6 – Present and use the information

The final stage 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.
Historical/previous presentations
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.
Creating reports and presenting information is an activity that is done in most
organizations to some extent or another; however it often is not done well. For many
organizations this activity is simply taking the gathered raw data (often straight from
the tool) and reporting this same data to everyone. There has been no processing
and analysis of the data.
In addition to understanding the target audience, it is also important to understand
the report’s purpose. If the purpose and value cannot be articulated, then it is
important to question if it is needed at all.
There are usually three distinct audiences:
The Business - Their real need is to understand whether IT delivered the Service
they promised at the levels they promised and if not, what corrective actions are
being implemented to improve the situation.
Senior (IT) Management - This group is often focused on the results surrounding
CSFs and KPIs such as, customer satisfaction, actual vs. plan, costing and
revenue targets. Information provided at this level helps determine strategic and
tactical improvements on a larger scale. Senior (IT) Management often wants this
type of information provided in the form of a Balanced Scorecard or IT
Scorecard format to see the big picture at one glance.
Internal IT - This group is often interested in KPIs and activity metrics that help
them plan, coordinate, schedule and identify incremental improvement
opportunities.

Often there is a gap between what IT reports and what is of interest to the business.
IT is famous for reporting availability in percentages such as 99.85% available. In
most cases this is not calculated from an end-to-end perspective but only Main Frame
availability or application availability and often doesn’t take into consideration
LAN/WAN, server or desktop downtime. In reality, most people in IT don’t know the
difference between 99.95% and 99.99% availability let alone the business. Yet
reports continue to show availability achievements in percentages. What the business
really wants to understand is the number of outages that occurred and the duration
of the outages with analysis describing the impact on the business processes, in
essence, unavailability expressed in a commonly understood measure – time.
Although most reports tend to concentrate on areas where things are not going as
well as hoped for, do not forget to report on the good news as well. A report
showing improvement trends is IT Services’ best marketing vehicle. It is vitally
important that reports show whether CSI has actually improved the overall Service
provision and if it has not, the actions taken to rectify the situation.

Step 7 – Implement corrective action

Use the knowledge gained to optimize, improve and correct services. Managers
need to identify issues and present solutions. Explain how the corrective actions to be
taken will improve the service.
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, change in
competition, or even political decisions.
Corrective action is often done in reaction to a single event that caused a (severe)
outage to part or all of the organization. Other times, the squeaky wheel will get
noticed and specific corrective action will be implemented in no relation to the
priorities of the organization, thus taking valuable resources away from real
emergencies. This is common practice but obviously not best practice.
After a decision to improve a Service and/or Service management process is made,
then the Service Lifecycle continues. A new Service Strategy may be defined, Service
Design builds the changes, Service Transition implements the changes into
production and then Service Operations manages the day-to-day operations of the
Service and/or Service management processes. Keep in mind that CSI activities
continue through each phase of the Service Lifecycle.
Each Service Lifecycle phase requires resources to build or modify the Services
and/or Service management processes, potential new technology or modifications to
existing technology, potential changes to KPIs and other metrics and possibly even
new or modified OLAs/UCs to support SLAs. Communication, training and
documentation is required to transition a new/improved Service, tool or Service
management process into production.
CSI is often viewed as an ad-hoc activity within IT Services. The activity usually kicks
in when someone in IT management yells loud enough. This is not the right way to
address CSI. Often times these reactionary events are not even providing continual
improvement, but simply stopping a single failure from occurring again.
CSI takes a commitment from everyone in IT working throughout the Service Lifecycle
to be successful at improving Services and Service management processes. It requires
ongoing attention, a well thought out plan, consistent attention to monitoring,
analyzing and reporting results with an eye toward improvement. Improvements can
be incremental in nature but also require a huge commitment to implement a new
Service or meet new business requirements.

This section spelled out the 7 steps of CSI activities. All 7 seven steps need attention.
There is no reward for taking a short cut or not addressing each step in a sequential
nature. If any step is missed, there is a risk of not being efficient and effective in
meeting the goals of CSI.
IT Services must ensure that proper staffing and tools are identified and implemented
to support CSI activities. It is also important to understand the difference between
what should be measured and what can be measured. Start small – don’t expect to
measure everything at once. Understand the organizational capability to gather data
and process the data. Be sure to spend time analyzing data as this is where the real
value comes in. Without analysis of the data, there is no real opportunity to truly
improve Services or Service management processes. Think through the strategy and
plan for reporting and using the data. Reporting is partly a “marketing” activity. It is
important that IT focus on the value added to the organization as well as reporting
on issues and achievements. In order for steps 5 through 7 to be carried out
correctly, it is imperative that the target audience is considered when packaging the
information.
An organization can find improvement opportunities throughout the entire Service
Lifecycle. An IT organization does not need to wait until a Service or Service
management process is transitioned into the Operations area to begin identifying
improvement opportunities.

Role of the Continual Service Improvement Manager

Role of the Continual Service Improvement
Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Manager
Operation
Service
Transition
• Ultimately responsible for the success of all improvement

activities
• Communicates the CSI vision across the IT organization
• Defines and reports on CSI Critical Success Factors, Key
Performance Indicators and CSI activity metrics
• Co-ordinates CSI throughout the service lifecycle
• Builds effective relationships with the business and IT
managers
• Ensures monitoring is in place to gather data
• Works with process and service owners to identify
improvements and improve quality
This role is essential for a successful improvement program. The CSI “owner” is
ultimately responsible for the success of all improvement activities. This single point of
accountability coupled with competence and authority virtually guarantees a
successful improvement program.
The most important of the CSI Manager’s responsibilities are shown on the slide. The
full list is below.
Key responsibilities
Responsible for development of the CSI domain
Responsible for communicating the vision of CSI across the IT organization
Ensures that CSI roles have been filled
Works with the Service Owner to identify and prioritize improvement
opportunities
Works with the Service Level Manager to ensure that monitoring requirements
are defined

Works with the Service Level Manager to identity Service Improvement Programs
Ensures that monitoring tools are in place to gather data
Defines and reports on CSI Critical Success Factors, Key Performance Indicators
and CSI activity metrics
Ensures that Knowledge Management is an integral part of the day to day
operations
Ensures that CSI activities are coordinated throughout the Service Lifecycle
Reviews analyzed data
Presents recommendations to Senior Management for improvement
Leads, manages and delivers cross-functional and cross-divisional improvement
projects
Builds effective relationships with the Business and IT Senior Managers
Identifies and delivers process improvements in critical business areas across
Manufacturing and relevant Divisions
Sets direction and provides framework through which improvement objectives
can be delivered
Coaches, mentors and supports fellow Service Improvement professionals
Possesses the ability to positively influence all levels of management to ensure
that Service Improvement activities are receiving the necessary support and are
resourced sufficiently to implement solutions

Role of the Service Manager

Continual Service
Improvement
Service
Service
Design
Design
Service
Service
Strategy
Service
ITIL
Role of the Service Manager

Operation
Service
Transition
• Manages the development, implementation, evaluation and

on-going management of new and existing products and
services
• Develops business case, product line strategy and
architecture
• Develops new service deployment and lifecycle management
schedules
• Performs Service Cost Management activities
• Works to instill a market focus
The Service Manager is an important role that manages the development,

implementation, evaluation and on-going management of new and existing products
and services. Responsibilities include business strategy development, competitive
market assessment/benchmarking, financial and internal customer analysis, vendor
management, inventory management, internal supplier management, cost
management, delivery and full lifecycle management of products and/or services.
Service Managers are responsible for managing very complex projects in order to
achieve objectives and strategies and strive for global leadership in the marketplace.
In order to attain this goal, they must evaluate new market opportunities, operating
models, technologies, and the emerging needs of customers in a company with
international scope.
At this level, Service Managers are recognized as global product/service experts.
They drive the decision making processes, manage product/service objectives and
strategies, hold internal and external suppliers accountable via formal agreements,
and provide the integration of individual product plans and new technologies into a
seamless customer focused services. Service Managers may also be required to
coach other managers (Service Owners, Process Owners) with differing levels of
expertise for managing a business function or a particular product/service, within a
specified product/service family.

Key responsibilities
Provide leadership on the development of business case and product line
strategy and architecture, new service deployment and lifecycle management
schedules
Perform Service Cost Management activities in close partnership with other
organizations such as Operations, Engineering, and Finance. Many of these
organizations are held to strict internal supplier agreements
Manage various and sometimes conflicting objectives in order to achieve the
organization’s goals and financial commitments
Instill a market focus
Create an imaginative organization which encourages high performance and
innovative contributions from its members within a rapidly changing environment
Service Managers are able to effectively communicate product/service line strategies
to corporate business leaders, and develop partnerships with other organizations
within the company with both similar and dissimilar objectives and also with
suppliers in order to satisfy internal and external customer needs. This is most often
achieved via formalized agreement for both internal and external suppliers.
They must be able to formulate development programs in response to new market
opportunities, assess the impact of new technologies, and guide creation of
innovative solutions in order to bring best-in-breed solutions to our internal and
external customers. They market the development and implementation of
products/services that incorporate new technologies or system development. This
requires extensive cross-organization communications. They also are able to identify,
develop, and implement financial improvement opportunities in order to meet the
firm’s commitments.

Key skills and competencies

Previous product/market management experience
Working knowledge of market analysis techniques and marketing programs
Advanced degree or equivalent experience
Working knowledge of the domestic and international marketplace including
industry applications, needs/trends, competitive vendor offerings, outsourcing,
licensing, vendor management, and customer relationships
Product knowledge must include complex engineering, telecommunications and
data protocols, as well as, data processing applications and the ability to
analyze the impact of new technologies
Demonstrated sustained performance in previous assignments
Sound business judgment
Negotiating skills
Human resource management skills
Excellent communications skills
Accept challenges and manage risk effectively and innovatively
Produce solutions on time within cost objectives

Service Transition
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Transition
Service
Transition
• Concepts
– V Model
– Configuration Item
– Configuration Management System
– Knowledge Management
– Data Information Knowledge Wisdom
– Service Knowledge Management System
– Definitive Media Library
• Processes
– Change Management
– Service Asset and Configuration Management
– Release and Deployment Management

Service Transition V Model

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Transition V Model

Service
Transition
Service Review Criteria/Plan Validate Service

Define
Level 1 Customer/Business •Contract, service Package, SLP, SPI
Packages, Offerings
Requirements and contracts
1a Service Acceptance Criteria/Plan 1b

Define Service
Level 2 Service •SLR
•Draft SLA
Acceptance
Requirements Test
2a Service Operation Criteria/Plan 2b

Design Service
Level 3 Service
SDP including:
•Service Mode. Operational
Solution •Capacity and resource plans Readiness Test
3a Service Release Test 3b

Design Criteria/Plan Service
Level 4 Service •Release Design Release Package
Release •Release Plan Test
4a 4b
Develop Component
Service And Assembly
Level 5
Solution Test
Service
KEY Levels of 5a Component 5b
configuration and Build &
testing Test Deliveries from
internal and
BL Baseline Point Internal &
external suppliers
external suppliers
Using a model such as the V-Model builds in service validation and testing early in
the service life cycle. It provides a framework to organize the levels of configuration
items to be managed through the life cycle and the associated validation and testing
activities both within and across stages.
The level of test is derived from the way a system is designed and built up. This is
known as a "V" model, which maps the types of test to each stage of development.
The V-model provides one example of how the service transition levels of testing can
be matched to corresponding stages of service requirements and design.
The left-hand side represents the specification of the service requirements down to the
detailed service design. The right-hand side focuses on the validation activities that
are performed against the specifications defined on the left-hand side. At each stage
on the left hand side, there is direct involvement by the equivalent party on the right
hand side. It shows that service validation and acceptance test planning should start
with the definition of the service requirements. For example, customers who sign off
the agreed service requirements will also sign off the service acceptance criteria and
test plan.

Configuration Item (CI)

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Configuration Item (CI)

Service
Transition
• Anything that needs to be managed in order to deliver an IT

Service
• CI information is recorded in the Configuration Management
System
• CI information is maintained throughout its Lifecycle by
Configuration Management
• All CIs are subject to Change Management control
• CIs typically include
– IT Services, hardware, software, buildings, people, and formal
documentation such as Process documentation and SLAs
A configuration item is an asset, service component or other item which is, or will be,
under the control of configuration management. Configuration items may vary widely
in complexity, size and type, ranging from an entire service or system including all
hardware, software, documentation and support staff to a single software module or
a minor hardware component. Configuration items may be grouped and managed
together, for example, a set of components may be grouped into a release.
Configuration Items should be selected using established selection criteria, grouped,
classified and identified in such a way that they are manageable and traceable
throughout the Service Life Cycle.

Configuration Management System (CMS)

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Configuration Management System (CMS)

Service
Transition
• Information about all Configuration Items

– CI may be entire service, or any component
– Stored in 1 or more databases (CMDBs)
• CMS stores attributes
– Any information about the CI that might be needed
• CMS stores relationships
– Between CIs
– With incident, problem, change records etc.
• CMS has multiple layers
– Data sources and tools, information integration, knowledge
processing, presentation
The Configuration Management System holds all the information for CIs within the
designated scope. Some of these items will have related specifications or files that
contain the contents of the item, for example, software, document, photograph. For
example, a Service CI will include the details such as supplier, cost, purchase date
and renewal date for licenses and maintenance contracts and the related
documentation such as SLAs and underpinning contracts.
The CMS is also used a for wide range of purposes, for example asset data held in a
CMS (CMDB data) may be made available to external financial Asset Management
systems to perform specific asset management process reporting outside of
Configuration Management. The CMS maintains the relationships between all service
components and any related Incidents, Problems, Known Errors, Change and Release
documentation and may also contain corporate data about employees, suppliers,
locations and business units, customers and users.
Many organizations are already using some elements of Service Asset and
Configuration Management, often maintaining records in documents, spreadsheets
or local databases and some of these may be used in the overall CMS. Automated
processes to load and update the Configuration Management database should be
developed where possible so as to reduce errors and optimize costs. Discovery tools,
inventory and audit tools, enterprise systems and network management tools can be
interfaced to the CMS. These tools can be used initially to populate a CMDB, and
subsequently to compare the actual ‘live’ configuration with the information and
records stored in the CMS.

Knowledge Management (KM)

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Knowledge Management (KM)

Service
Transition
“The process responsible for

gathering, analyzing, storing
and sharing knowledge and
information within an
organization.
The primary purpose of

Knowledge Management is to
improve efficiency by
reducing the need to
rediscover knowledge.”
The goal of Knowledge Management enables organizations is to improve the quality

of management decision making by ensuring that reliable and secure information
and data is available throughout the Service Life Cycle.
The objectives of Knowledge management include:
Enabling the service provider to be more efficient and improve quality of service,
increase satisfaction and reduce the cost of service
Ensuring 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 utilization of those services
Ensuring that, at a given time and location, service provider staff have adequate
information of
• Who is currently utilizing their services
• The current states of consumption
• Service delivery constraints
• Difficulties faced by the customer in fully realizing the benefits expected
from the service
The purpose of Knowledge Management is to ensure that the right information is
delivered to the appropriate place or person at the right time to enable informed
decisions.

Data, Information, Knowledge and Wisdom (DIKW)

Data, Information, Knowledge and Wisdom
Service
Service
Design
Design
Service
Service
Strategy
ITIL
(DIKW)
Service
Transition
Wisdom
Knowledge
Information
Data
Knowledge management is typically displayed within the Data-Information-

Knowledge-Wisdom structure. The usage 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. The key Knowledge
Management activities around data are the ability to:
Capture accurate data
Analyze, synthesize, and then transform the data into information
Identify relevant data and concentrate resources on its capture
Information comes from providing context to data. Information is typically stored in
semi-structured content such as documents, e-mail, and multimedia. The key
Knowledge Management activity around information is managing the content in a
way that makes it easy to capture, query, find, reuse, and learn from experiences so
that mistakes are not repeated and work is not duplicated.

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.
Wisdom gives the ultimate discernment of the material and having the application
and contextual awareness to provide a strong common sense judgment.
This is shown in the figure below.
Context
Wisdom
Why?
Knowledge
How?
Information
Who, what,
when, where?
Data
Understanding
The flow from data to wisdom

Service Knowledge Management System (SKMS)

Service Knowledge Management System
Service
Service
Design
Design
Service
Service
Strategy
ITIL
(SKMS)
Service
Transition
Wisdom – ability to make decisions

Presentation Layer
Knowledge Processing Layer
Information Service Knowledge Base

Integration
Layer
Configuration Management System
Data and CMDB DML

DML
Information
CMDB
Specifically within IT Service Management, Knowledge Management will be focused

within the Service Knowledge Management System (SKMS) concerned, as its name
implies, with knowledge. Underpinning this knowledge will be a considerable
quantity of data, which will be held in a central logical repository or configuration
management system (CMS) and database (CMDB). However, clearly the SKMS is a
broader concept that covers a much wider base of knowledge, for example:
The experience of staff
Records of peripheral matters, for example, weather, user numbers and
behavior, organization’s performance figures
Supplier and partners requirements, abilities and expectations
Typical and anticipated user skill levels
Note
DML is described in the next slide.

Definitive Media Library (DML)

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Definitive Media Library (DML)

Service
Transition
• Master copies of all software assets

– In house, external software house , COTS…
– Scripts as well as code
– Management tools as well as applications
– Including licenses
• Quality checked
– Complete, correct, virus scanned…
• The only source for build and distribution
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 license 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.
The DML will also include a physical store to hold master copies, for example, a
fireproof safe. Only authorized media should be accepted into the DML, strictly
controlled by Service Asset and Configuration Management. The DML is a
foundation for Release and Deployment Management. The exact configuration of the
DML is defined during the planning activities. The definition includes:
Medium, physical location, hardware and software to be used, if kept online -
some Configuration Management support tools incorporate software libraries,
which can be regarded as a logical part of a DML
Naming conventions for filestore areas and physical media

Environments supported, for example, Test and live environments

Security arrangements for submitting Changes and issuing software, plus backup
and recovery procedures
The scope of the DML: For example, Source code, object code from controlled
builds and associated documentation
Retention period
Capacity plans for the DML and procedures for monitoring growth in size
Audit procedures
Procedures to ensure that the DML is protected from erroneous or unauthorized
Change (for example Entry and exit criteria for items)
Commercial off the Shelf (COTS) is Application software or Middleware that can be
purchased from a Third Party.

DML and CMDB relationship
DML and CMDB relationship
DML Physical CIs Information about the CIs
CMDB
Electronic
CIs
Release
Record
Build new Release
Test new Release
Implement new Release
Distribute new Release to

live locations

Service Transition processes

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Transition processes

Service
Transition
• Transition Planning and Support

• Change Management
• Service Asset and Configuration Management (SACM)
• Release and Deployment Management
• Service Validation and Testing
• Evaluation
• Knowledge Management
The seven Service Transition processes are listed on the slide. Only three are
required to be discussed in detail: Change Management, Service Asset and
Configuration Management (SACM), and Release and Deployment Management.

Change Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change Management
Service
Transition
• Goals, objectives and purpose

• Scope
• Value to the business
• Basic concepts
• Activities
• Roles
• Interfaces
• Key metrics
• Challenges

Change — Objectives and purpose

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Objectives and purpose

Service
Transition
• Respond to changing business requirements

– Respond to Business and IT requests to align Services with
business needs
• Minimize impact of implementing changes
– Reduce incidents, disruption and rework
• Optimize business risk
• Implement changes successfully
• Implement changes in times that meet business needs
• Use standard processes
• Record all changes
There is a big difference between V2 and V3. In Version 2, we used to say minimize
risk but in ITIL V3 we consider the cost to the business and the value to the business
of risk treatments and we optimize these to achieve the best business outcome for the
money.
The goals of Change Management are to:
Respond to the customer’s changing business requirements whilst 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
The objective of the Change Management process is to ensure that changes are
recorded and then evaluated, authorized, prioritized, planned, tested, implemented,
documented and reviewed in a controlled manner.
The purpose of the Change Management process is to ensure that:
Standardized methods and procedures are used for efficient and prompt
handling of all Changes
All changes to service assets and configuration items are recorded in the
configuration management system
Overall business risk is optimized

Change — Scope
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Scope
Service
Transition
• Addition, Modification or Removal

of
– Any Service or Configuration Item or associated documentation
Including
– Strategic, Tactical and Operational changes
Excluding
– Business strategy and process
– Anything documented as out of scope
Change can be defined in many ways. The definition of a Service Change is:
"The addition, modification or removal of authorized, planned or supported service
or service component and its associated documentation.”
The scope of Change Management covers changes to baselined service assets and
configuration items across the whole Service Life Cycle. Each organization should
define the changes that lie outside the scope of their service change process.
Typically these might include:
Changes with significantly wider impacts than service changes, for example,
departmental organization, policies, 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

Business Service Provider Supplier

Manage the
Strategic Manage the
Manage IT services suppliers’
change business business
Tactical Manage the Service Manage

change business portfolio external
processes services
Service
change
Manage the External

Operational Service
business operations
change Operations
operations

Scope of Change and Release Management for Services
The figure above shows a typical scope for the service change management process
for an IT department and how it interfaces with the business and suppliers at
strategic, tactical and operational 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. Service Change management must interface with
Business change management (to the left in the figure), and with the supplier’s
change management (to the right in the figure). This may be an external supplier
with a formal change management system, or with the project change mechanisms
within an internal development project.
The Service Portfolio provides a clear definition of 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 business relationship
management processes. Changes to a Service will be brought in via Service Design,
Continual Service Improvement and the Service Level Management process.
Corrective change, resolving errors detected in services, will be initiated from Service
Operations, and may route via support or external suppliers into a formal RFC.
Exclusions
The scope of a Service Change does not include strategic planning for business
transformation or organizational change although the interfaces to these processes
do need to be managed.

Change — Value to the business

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Value to the business

Service
Transition
• Prioritizing and responding to requests

• Implementing changes in required times
• Meet agreed service requirements while optimizing costs
• Reducing failed changes and rework
• Correctly estimating quality, time and cost
• Assessing and managing risks
• Managing staff time
Reliability and business continuity are essential for the success and survival of any
organization. Service and infrastructure Changes can 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:
Prioritizing and responding to business and customer change proposals
Implementing changes that meet the customers’ agreed service requirements
while optimizing costs
Note
We are not trying to minimize costs like in ITIL V2. In V3 we may choose a
solution with higher a cost for a better outcome
Contributing to meet governance, legal, contractual and regulatory requirements

Reducing failed changes and therefore service disruption, defects and re-work
Delivering change promptly to meet business timescales
Tracking changes through the Service Life Cycle and to the assets of its customers
Contributing to better estimations of the quality, time and cost of change

Assessing the risks associated with the transition of services (introduction or

disposal)
Aiding productivity of staff through minimizing disruptions due to 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

Change — Basic concepts (1 of 2)

Service
Service
Design
Design
Service
Service
Strategy
ITIL

Service
Transition
• Change types
– Normal changes
• Types are specific to the organization
• Type determines what assessment is required
– Standard changes
• Pre-authorized with an established procedure
– Emergency changes
• Business criticality means there is insufficient time for normal
handling
• Should use normal process but speeded up
A change request is a formal communication seeking an alteration to one or more

Configuration Items, this could take several forms, for example, ‘request for change’
document, service desk call, project initiation document. Different types of change
may require different types of change request. 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.
As much use as possible should be made of devolved authorization, both through the
standard change procedure and through the authorization of minor changes by
change management staff. During the planning of different types of change requests,
each must be defined with a unique naming convention. For different change types
there are often specific procedures, for example, for impact assessment and change
authorization.

Standard Changes
A standard Change is a change to a service or infrastructure for which the approach
is pre-authorized by change management that has an accepted and established
procedure to provide a specific change requirement. Examples might include an
upgrade of a PC in order to make use of specific standard and pre-budgeted
software, new starters within an organization, desktop move for single user. Other
examples include low impact, routine application change to handle seasonal
variation.
Approval of each occurrence of a standard change will be granted by the delegated
authority for that standard change, for example, by the budget holding customer for
installation of software from an approved list on a PC registered to their
organizational unit or by the third party engineer for replacement of a faulty desktop
printer.
The crucial elements of a standard Change are that:
There is a defined trigger to initiate the RFC
The tasks are well-known, documented and proven
Authority is effectively given in advance
Budgetary approval will typically be preordained or within the control of the
Change requester
Usually low risk, and always well understood risk
Once the approach to manage standard changes has been agreed, standard
Change processes and associated change workflows should be developed and
communicated. A change model would normally be associated with each standard
change to ensure consistency of approach. Standard Changes should be identified
early on when building the Change management process to promote efficiency.
All changes, including standard changes will have details of the change recorded.
For some standard changes this may be different in nature from normal change
records. Some standard changes to configuration items may be tracked on the asset
or configuration item life cycle, particularly where there is a comprehensive CMS that
provides reports of changes, their current status, the related configuration items and
the status of the related CI versions. In these cases the change and configuration
management reporting is integrated and change management can have ‘oversight’
of all changes to service CIs and release CIs.
Some standard changes will be triggered by the request fulfillment process and be
directly recorded and passed for action by the service desk.

Emergency Changes
Emergency Changes are sometimes required and should be designed carefully and
tested before use or the impact of the emergency change may be greater than the
original incident. Emergency changes may document some details 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.
Emergency change 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 introduce immediately required business improvements are handled as normal
changes, assessed as having the highest urgency.
Defined authorization levels will exist for an emergency change, and the levels of
delegated authority must be clearly documented and understood. In an emergency
situation it may not be possible to convene a full Change Advisory Board (CAB)
meeting. Where CAB approval is required, this will be provided by the Emergency
CAB (ECAB). Not all emergency changes will require the ECAB involvement, many
may be predictable both in occurrence and resolution and well understood changes
available, with authority delegated, for example, to Operations teams who will
action, document and report on the emergency change.


Service
Service
Design
Design
Service
Service
Strategy
ITIL

Service
Transition
• Change, configuration, release and deployment

– Should be planned together
– Should have coordinated implementation
• Remediation plans
– Every change should have a backout plan
– Sometimes a change can’t be backed out
• Must still have a plan for what to do
No change should be approved without having explicitly addressed the question of

what to do if it is not successful. Ideally, this will comprise a back-out plan which will
restore the organization to its initial situation, 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 (for example, it is
successful when tested), can the risk of the proposed change be determined and the
appropriate decisions taken.

Change — Activities
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Activities
Service
Transition
Update change and configuration in CMS

Create RFC
Change
proposal
(optional) Record the RFC
Initiator Requested
Change
Review the RFC
Management Ready for evaluation
Assess and evaluate
change
Work orders
Ready for decision
Authorize change Authorize
proposal Change change
Authority Authorized
Plan updates
Change
Management Scheduled Work orders
Co-ordinate change
implementation*
Change
Management Implemented
Evaluation Review and close

report change record
Closed * Includes build and test the change
Raising and recording changes

The change is raised by a request from the initiator – the individual or organizational
group that require the change. This may be a business unit who require additional
facilities, problem management who are instigating an error resolution of many other
sources. For a major change with significant organizational and/or financial
implications, a change proposal may be required which will contain full description
of the change together with business and financial justification for the proposed
change. The change proposal will include sign off by appropriate levels of business
management.
The change record holds the full history of the change, incorporating information
from the RFC and subsequently recording agreed parameters such as priority and
authorization, implementation and review information. There may be many different
types of change records used to record different types of change. The documentation
should be defined during the process design and planning stage.

Review the RFC

Change logging
The procedures for documenting RFCs should be decided. RFCs might be able to be
submitted on paper forms, through email or using a web-based interface, for
example. Where a computer based support tool is used, the tool may restrict the
format.
All RFCs received should be logged and allocated an identification number (in
chronological sequence). Where Change requests are submitted in response to a
trigger such as a resolution to a Problem record (PR), it is important that the reference
number of the triggering document is retained to provide traceability.
Change filtering
The procedures should stipulate that, as changes are logged, Change Management
should briefly consider each request and filter out any that seem to be:
Totally impractical
Repeats of earlier RFCs, accepted, rejected or still under consideration
Incomplete submissions, for example, inadequate description, without necessary
budgetary approval
These should be returned to the initiator, together with brief details of the reason for
the rejection, and the log should record this fact. A right of appeal against rejection
should exist, via normal management channels, and should be incorporated within
the procedures.
Assess and evaluate the change

Risk categorization
The issue of risk to the business of any Change must be considered prior to the
authorization of any Change. Many organizations use a simple matrix to categorize
risk, and from this the level of change assessment and authorization required.
The relevant risk is the risk to the business service and changes require thorough
assessment, wide communication, and appropriate authorization by the person or
persons accountable for that business service. Assessing risk from the business
perspective can produce a correct course of action very different from that which
would have been chosen from an IT perspective, especially within high risk industries.

Evaluation of the Change

Based upon the impact and risk assessments, and the potential benefits of the
Change, each of the assessors should evaluate the information and indicate whether
they support approval of the Change. All members of the change authority should
evaluate the change based on impact, urgency, risk, benefits and costs. Each will
indicate whether they support approval and be prepared to argue their case for any
alterations that they see as necessary. The potential impact on the services of failed
changes and their impact on service assets and configurations need to be
considered. Generic questions (for example, the ‘seven Rs’ – see the later slide)
provide a good starting point.
Allocation of priorities
Prioritization is used to establish the order in which Changes put forward should be
considered. Every RFC will include the originator’s assessment of the impact and
urgency of the change. The priority of a change is derived from the agreed impact
and urgency. Initial impact and urgency will be suggested by the change initiator but
may well be modified in the change authorization process. Risk assessment is of
crucial importance at this stage. The CAB will need information on business
consequences in order to assess effectively the risk of implementing or rejecting the
change.
Change planning and scheduling
Careful planning of changes will ensure that there is no ambiguity about what tasks
are included in the change management process, what tasks are included in other
processes and how processes interface to any suppliers or projects that are providing
a change or release. Many changes may be grouped into one release and may be
designed, tested and released together if the amount of changes involved can be
handled by the business, the service provider and its customers. However, if many
independent changes are grouped into a release then this may create unnecessary
dependencies that are difficult to manage. If not enough changes are grouped into a
release then the overhead of managing more releases can be time consuming and
waste resources. It is recommended very strongly that Change Management schedule
Changes to meet business rather than IT needs, for example, avoiding critical
business periods.
Assessing remediation
It is important to develop a remediation plan to address a failing Change or release
long before implementation. Very often, remediation is the last thing to be
considered; risks may be assessed, mitigation plans cast in stone. How to get back
to the original start point is often ignored or considered only when regression is the
last remaining option.

Authorize the Change

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 or risk of the Change, for
example, 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 may allow a more streamlined
approach.
A degree of delegated authority may well exist within an authorization level, for
example, delegating authority to a Change Manager according to pre-set
parameters relating to:
Anticipated business risk
Financial implications
Scope of the Change (for example, internal effects only, within the finance
service, specific outsourced services
Should disputes arise over change authorization or rejection, there should be a right
of appeal to the higher level.
Co-ordinating Change implementation

Authorized RFCs should be passed to the relevant technical groups for building of the
changes. It is best practice to do this in a formal way that can be tracked, for
example, using work orders. Change Management has responsibility for ensuring
that Changes are implemented as scheduled, this is largely a coordination role as
the actual implementation will be the responsibility of others (for example, hardware
technical specialists will implement hardware Changes). Remediation procedures
should be prepared and documented in advance, for each authorized Change, so
that if errors occur during or after implementation, these procedures can be quickly
activated with minimum impact on service quality. Authority and responsibility for
invoking remediation is specifically mentioned in change documentation.
Change Management has an oversight role to ensure that all Changes that can be,
are thoroughly tested. In all cases involving Changes that have not been fully tested,
special care needs to be taken during implementation. Testing may continue in
parallel with early live usage of a service – looking at unusual, unexpected or future
situations so that further correcting action can be taken before any detected errors
become apparent in live operation.
The implementation of such Changes should be scheduled when the least impact on
live services is likely. Support staff should be on hand to deal quickly with any
Incidents that might arise.

Review and close Change record

On completion of the Change, the results should be reported for evaluation to those
responsible for managing Changes, and then presented as a completed Change for
stakeholder agreement (including the closing of related Incidents, Problems or Known
Errors). Clearly, for major Changes there will be more Customer and stakeholder
input throughout the entire process. Review should also include any Incidents arising
as a result of the change (if they are known at this stage). If the Change is part of a
service managed by an external provider, details of any contractual service targets
will be required (for example, no priority 1 incidents during first week after
implementation).
A Change Review (for example, Post Implementation Review) should be carried out to
confirm that the Change has met its objectives, that the initiator and stakeholders are
happy with the results; and that there have been no unexpected side-effects. Lessons
learned should be fed back into future Changes. Small organizations may opt to use
spot checking of Changes rather than large-scale PIR; in larger organizations,
sampling will have a value when there are many similar Changes taking place.

7 Rs of Change Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
7 Rs of Change Management
Service
Transition
• Who RAISED the change?

• What is the REASON for the change?
• What is the RETURN required from the change?
• What are the RISKS involved in the change?
• What RESOURCES are required to deliver the change?
• Who is RESPONSIBLE for the build, test and implementation
of the change?
• What is the RELATIONSHIP between this change and other
changes?
The 7 Rs are important questions to be asked when evaluating the change, during
the “Assess and Evaluate Change” activity. These generic questions provide a good
starting point from which to consider the potential impact on the services of failed
changes, and their impact on service assets and configurations.

Change — Roles (1 of 2)
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
• Change Manager
– Process owner
– Ensures that process is followed
– Usually authorizes minor changes
– Coordinates and runs CAB meetings
– Produces change schedule
– Coordinates change/built/test/implementation
– Reviews/Closes Changes
The main duties of the Change Manager, some of which may be delegated, are
listed below:
Receive, log and allocate a priority, in collaboration with the initiator, to all
RFCs. Reject any RFCs that are totally impractical
Table all RFCs for a CAB meeting, issue an agenda and circulate all RFCs to
CAB members in advance of meetings to allow prior consideration
Decide which people will come to which meetings, who gets specific RFCs
depending on the nature of the RFC, what is to be changed, and people’s areas
of expertise
Convene urgent CAB or ECAB meetings for all urgent RFCs
Chair all CAB and ECAB meetings
After consideration of the advice given by the CAB or ECAB, authorize
acceptable Changes
Issue Change Schedules, via the Service Desk

Liaise with all necessary parties to coordinate Change building, testing and
implementation, in accordance with schedules
Update the Change log with all progress that occurs, including any actions to
correct problems and/or to take opportunities to improve service quality
Review all implemented Changes to ensure that they have met their objectives.
Refer back any that have been backed out or have failed
Review all outstanding RFCs awaiting consideration or awaiting action
Analyze Change records to determine any trends or apparent problems that
occur. Seek rectification with relevant parties
Close RFCs
Produce regular and accurate management reports

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
• Change Advisory Board (CAB)

– Supports the change manager
– Consulted on significant changes
– Business, users, application/technical support, operations,
service desk, capacity, service continuity, third parties…
• Emergency CAB (ECAB)
– Subset of the standard CAB
– Membership depends on the specific change
The Change Advisory Board (CAB) is a body that exists to support the authorization
of changes and to assist Change Management in the assessment and prioritization of
changes. As and when a CAB is convened, members should be chosen who are
capable of ensuring that all Changes within the scope of the CAB are adequately
assessed from both a business and a technical viewpoint.
The 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 clear understanding across the whole range of stakeholder
needs. The Change Manager will normally chair the CAB and, potential members
include:
Customer(s)
User manager(s)
User group representative(s)
Applications developers/maintainers
Specialists/technical consultants
Services and operations staff, for example, Service Desk, Test management,
ITSCM, Security, Capacity

Facilities/office services staff (where Changes may affect

moves/accommodation and vice versa)
Contractor’s or third parties’ representatives, for example, in outsourcing
situations
Other parties as applicable to specific circumstances (for example, police if
traffic disruptions likely, marketing if public products affected)
It is important to emphasize that the CAB:
Will be composed according to the Changes being considered
May vary considerably in make-up even across the range of a single meeting
Should involve suppliers when that would be useful
Should reflect both user and Customer 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 the 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 a
technical standpoint, to make appropriate decisions in any conceivable eventuality.
A practical tip worth bearing in mind is that the 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.

Change — Interfaces
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Interfaces
Service
Transition
• Inputs
• Outputs
• Interfaces with other processes

Change — Inputs
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Inputs
Service
Transition
• Change policy and strategy

• RFCs
• Change Proposals
• Service Management Plans
• Assets and configuration items
• Existing change management documents
– Change schedule
– Projected Service Outage (PSO)
Changes may be submitted as a Request for Change (RFC), often with an associated
change proposal that provides the detail of how the change will happen, for
example, approach to implementing a legislative change. The change proposal will
be based on a change model and will provide more detail about the specific change
proposed. The inputs include those listed on the slide.
Examples of Service Management Plans include the plans for doing change,
transition, release, deployment, test, evaluation and remediation.
The Change Schedule is a document that lists all approved Changes and their
planned implementation dates.
The Projected Service Outage is a document that identifies the effect of planned
Changes, maintenance activities and test plans on agreed Service Levels.
All these inputs are considered when assessing a change through the Change
Management process.

Change — Outputs
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Outputs
Service
Transition
• Rejected and approved RFCs

• Changes to services and CIs
• Updated
– Change schedule
– Projected Service Outage (PSO)
• Change plans, decisions, actions…
• Change documents and records
• Management reports

Change — Process interfaces

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Process interfaces

Service
Transition
• Asset and Configuration Management

• IT Service Continuity Management
• Capacity and Demand Management
• Release and Deployment Management
• Security Management
The service management processes may require change and improvements. Many
will also be involved in the impact assessment and implementation of service
changes. For example:
Asset and Configuration Management

The Configuration Management System provides reliable, quick and easy access to
accurate configuration information to enable stakeholders and staff to assess the
impact of proposed changes and to track changes work flow. This information
enables the correct asset and service component versions to be released to the
appropriate party or into the correct environment. As changes are implemented, the
configuration management information is updated. The CMS may also identify
related CI/assets that will be affected by the change, but not included in the original
request, or in fact similar CI/Assets that would benefit from similar change.

An overview of how the change, and configuration management processes work

together for an individual change is shown in the following Figure.
Change Management
Approve Co-ordinate Review

Raise & record Assess Close
reject change change
change request change change
change implementation*
Release and deploy

New/changed CIs
Capture
release and Check
Reports & Identify Update Audit
environment records
audits affected items records items
baselines updated
*Includes build and test where applicable

Request for change workflow and key interfaces to Configuration Management
IT Service Continuity Management

IT Service continuity has many procedures, and plans should be updated via change
management to ensure that they are accurate, up to date and that stakeholders are
aware of changes.
Capacity and Demand Management

Capacity and Demand management is a critical aspect of change management.
Poorly managed demand is a source of costs and risk for service providers because
there is always a level of uncertainty associated with the demand for services.
Capacity management has an important role in assessing proposed changes, not
only the individual changes but the total impact of changes on service capacity.
Changes arising form capacity management, including those set out in the capacity
plan will be initiated as RFCs through the change process.
Release and Deployment Management

Change Management and Release and Deployment Management interface during
many shared activities. It is essential that releases to the production environment have
been authorized by the Change Management process.
Security Management
Security management interfaces with change management since changes required
by security will go via change management process and security will be a key
contributor to CAB discussion on many services. Every significant change will be
assessed for its potential impact on the security plan.

Change — Key metrics

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Key metrics

Service
Transition
• Compliance
– Reduction in unauthorized changes
– Reduction in emergency changes
• Effectiveness
– Percentage of changes which met requirements
– Reduction in disruptions, defects and re-work
– Reduction in changes failed/backed out
– Number of incidents attributable to changes
• Efficiency
– Benefits (value compared to cost)
– Average time to implement (by urgency/priority/type)
– Percentage accuracy in change estimates
Change Management must ensure that measures that have specific meaning. While
it is relatively easy to count the number of Incidents that eventually generate
Changes, it is infinitely more valuable to look at the underlying cause of such
Changes, and to identify trends. Better still to be able to measure the impact of
Changes and to demonstrate reduced disruption over time because of the
introduction of Change Management, and also to measure the speed and
effectiveness with which the IT infrastructure responds to identified business needs.
Measures taken should be linked to business goals wherever practical – and to cost,
service availability, and reliability. Any predictions should be compared with actual
measurements.
The Key Performance Indicators for Change Management are:
The number of changes implemented to services which met the customers agreed
requirements, for example, quality/cost/time (expressed as a percentage of all
changes)
The benefits of change expressed as ‘value of improvements made’ + ‘negative
impacts prevented or terminated’ compared to the costs of the change process
Reduction in the number of disruptions to services, defects and re-work caused
by inaccurate specification, poor or incomplete impact assessment

Reduction in the number of unauthorized changes

Reduction in the backlog of change requests
Reduction in the number and percent of unplanned changes and emergency
fixes
Change success rate.(percentage of changes deemed successful at
review/number of RFCs approved)
Reduction in the number of changes where remediation is invoked
Reduction in the number of failed changes
Average time to implement based on urgency/priority/change type
Incidents attributable to changes
Percentage accuracy in change estimate
(The important KPIs are listed on the slide, and separated into categories of
“Compliance”, “Effectiveness” and “Efficiency”, for ease of understanding.)
Naturally there is other management information required around change and
statistics to be gathered and analyzed to ensure efficient and effective process, but
for organizations with a ‘dashboard’ reporting approach, these are good metrics to
use.
Meaningful measurements are those from which management can make timely and
accurate actionable decisions. For example: Reporting on the number of changes is
meaningless. Reporting on the ratio of changes implemented versus RFCs received
provides an efficiency rating. If this rating is low, management can easily see that
changes are not being processed in an efficient of effective manner and then take
timely action to correct the deficiencies causing this.

Change — Challenges
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Change — Challenges
Service
Transition
• People who ignore the process

• Inadequate Configuration Management
• Business pressure to “just do it”
• Lack of “Standard Changes”
• Scalability across large organizations
There are a number of challenges that must be overcome to ensure a successful

Change Management process. These include:
Ensuring that people follow the process
Change Management is often perceived by technical groups as a means to
control their activity. It can also be perceived by users and customers as IT trying
to limit the level of service. In all cases it is important that Change Management
is correctly positioned and that the benefits are clearly articulated.
Inadequate Configuration Management
Configuration Management plays two very important roles in Change
Management. Firstly it provides data which allows IT to control the physical
assets. If it was not in a database, how would we know whether it is a
controlled item? Secondly, it provides data and information that enables Change
Management to define, assess and implement the change. Imagine trying to
manage a change, when there is no information about the item being changed.
Business press to “just do it”
This is often the result of poor planning or of fast-paced changes in the business
environment. Overcoming this challenge will require the business to accept and
support Change Management. This is best achieved by pointing to the results of
failed changes in the past, and by ensuring that the business takes full
responsibility for the implementation of uncontrolled changes.

Lack of Standard Changes

This implies that every change that is managed is new to IT. Even routine
changes have to go through unnecessary bureaucracy. Establishing standard
changes need not be complicated. Simply starting to identify common steps for
dealing with routine changes will ensure that change models become accepted.
Stability across large organizations
Large organizations with complex infrastructures and applications find it difficult
to define cohesive Change Management processes. The best way to overcome
this challenge is through the concept of centralized control with delegated
decision-making and decentralized execution. This is covered in detail in more
advanced courses.

Service Asset and Configuration Management (SACM)

Service Asset and Configuration Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
(SACM)
Service
Transition
• Objectives
• Basic concepts
• Roles

SACM — Objectives
Service
Service
Design
Design
Service
Service
Strategy
ITIL
SACM — Objectives
Service
Transition
• For service assets, configuration items, and (where

appropriate) customer assets
– Protect integrity throughout their lifecycle
– Provide accurate information to support business and service
management
• Establish and maintain a Configuration Management System
– As part of an overall Service Knowledge Management System
The purpose of Service Asset and Configuration Management is to:

Protect the integrity of service assets and configuration items (and where
appropriate, those of its customers) through the Service Life Cycle
Place IT assets and designated configuration items within the Service Life Cycle
under configuration management
Ensure the integrity of the assets and configurations required to control the
services and IT infrastructure by establishing and maintaining an accurate and
complete configuration management system
Support efficient and effective business and service management processes by
providing accurate information about assets and configuration items
The goal of Service Asset and Configuration Management is to provide a logical
model of the IT infrastructure correlating IT services and different IT components
(physical, logical etc) needed to deliver these services.
The objective is to define and control the components of services and infrastructure
and maintain accurate configuration records. This enables an organization to comply
with corporate governance requirements, control its asset base, optimize its costs,
manage change and releases effectively, and resolve incidents and problems faster.

SACM — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
ITIL
SACM — Basic concepts

Service
Transition
• Configuration Items
• Logical Model

SACM Configuration Items categories

Service
Service
Design
Design
Service
Service
Strategy
ITIL
SACM Configuration Items categories

Service
Transition
• Service Lifecycle CIs

– Business case, plan, design package…
• Service CIs
– Service package, acceptance criteria,…
– Service assets
• Management, organization, process, knowledge, people,
information, applications, infrastructure, financial capital
• Organization CIs
• Internal and External CIs
There will be a variety of CIs; the following categories may help to identify them.
Service Life Cycle CIs such as the Business case, Service Management plans,
Service Life Cycle plans, Service Design Package, Release and Change plans,
Test plans. They provide a picture of the service provider’s services, how these
services will be delivered, what benefits are expected, at what cost, and when
they will be realized.
Service CIs such as:
• Service capability assets: management, organization, processes,
knowledge, people
• Service resource assets: financial capital, systems, applications, information,
data, infrastructure and facilities, financial capital, people
• Service Model
• Service Package
• Release Package
• Service Acceptance Criteria

Organization CIs. Some documentation will define the characteristics of a CI

whereas other documentation will be a CI in its own right and need to be
controlled, for example, the organization’s business strategy or other policies
that are internal to the organization but independent of the service provider.
Regulatory or statutory requirements also form external products that need to be
tracked, as do products shared between more than one group.
Internal CIs comprising those delivered by individual projects, including tangible
(data centre) and intangible assets such as software that are required to deliver
and maintain the service and infrastructure.
External CIs such as external customer requirements and agreements, releases
from suppliers or sub-contractors and external services.

SACM logical model

Service
Service
Design
Design
Service
Service
Strategy
ITIL
SACM logical model

Service
Transition
Hierarchy and relationships between CIs

Services
E-Banking E-Sales
User User
Experience Application Application
Experience
Business Business
Availability SLA SLA Availability
Logic Logic
Application Application
Infrastructure Infrastructure
Data Center
Network
Messaging Data services Web services Web services Data services Messaging
Network Name
Topology Service
Authentication
Configuration management delivers a required logical model of the services, assets

and the infrastructure by recording the relationships between configuration items as
shown in the slide. This enables other processes to access valuable information for
example:
To assess the impact and cause of incidents and problems
To assess the impact of proposed changes
To plan and design new or changed services
To plan technology refresh and software upgrades
To plan release and deployment packages and migrate service assets to
different locations and service centers
To optimize asset utilization and costs, for example, consolidate data-centers,
reduce variations, and re-use assets

The real power of configuration management’s logical model of the infrastructure is

that it is THE model – a single common representation used by all parts of IT Service
management, and beyond – such as HR, Finance, supplier and customers.
‘Danish Clock’
There is a traditional Danish proverb that runs ‘When you have a clock in your
house, you know the time – once you get two clocks you are no longer certain’.
SACM delivers that one clock for all processes and so glues them together, delivers
consistency and helps achieve common purpose.
The configuration items and related configuration information can be at varying

levels of detail, for example, an overview of all the services or a detailed level to
view the specification for a service component. A more detailed level of
Configuration management should be used where the service provider requires tight
control, traceability, and tight coupling of configuration information through the
Service Life Cycle.

SACM — Roles
Service
Service
Design
Design
Service
Service
Strategy
ITIL
SACM — Roles
Service
Transition
• Service Asset Manager

• Configuration Manager
• Each of these is the process owner for their area
– Implement policy and standards
– Procure and manage finances
– Agree scope, processes and procedures
– Define and procure tools
– Recruit and train staff
– Oversee collection and management of data
– Manage audits
– Provide management reports
Role specifications for the Change, Service Asset and Configuration Management
team need to be developed. Typical roles include:
Service Asset Manager
Configuration Manager
Configuration Analyst
Administrator/Librarian
CMS/Tools administrator
Assign the Configuration Manager and other key roles as early as possible, because
assigned individuals can then be involved in the implementation. For some
operational activities Configuration Management will require staff who will adopt a
diligent approach and pay due attention to detail.

The key roles of Service Asset Manager and Configuration Manager have the
following responsibilities:
Works to the overall objectives agreed with the IT Services Manager; implements
the organization’s Service Asset Management/Configuration Management
policy and standards
Evaluates existing Asset Management/Configuration Management systems and
the design, implementation and management of new/improved systems for
efficiency and effectiveness – including estimating and planning the work and
resources involved, and monitoring and reporting on progress against plan
Agrees scope of the Asset Management/Configuration Management processes,
function, the items that are to be controlled, and the information that is to be
recorded. Develops Asset Management/Configuration Management standards,
plans and procedures
Mounts an awareness campaign to win support for new Asset
Management/Configuration Management procedures. Ensures that changes to
the Asset Management/Configuration Management methods and processes are
properly approved and communicated to staff before being implemented. Plans,
publicizes and oversees implementation of new Asset
Management/Configuration Management systems
Arranges recruitment and training of staff
Manages the evaluation of proprietary Asset Management/Configuration
Management tools and recommends those that best meet the organization’s
budget, resource, timescale and technical requirements
Manages the Asset Management/Configuration Management plan, principles
and processes and their implementation
Agrees assets/CIs to be uniquely identified with naming conventions. Ensures
that staff comply with identification standards for object types, environments,
processes, lifecycles, documentation, versions, formats, baselines, Releases and
templates
Proposes and/or agrees interfaces with Change Management, Problem
Management, Network Management, Release Management, computer
operations, logistics, finance and administration functions
Plans population of the Asset DB/CMS. Manages the Asset DB/CMS, central
libraries and tools. Ensures regular housekeeping of the Asset DB/CMS

Provides reports, including management reports (indicating suggested action to

deal with current or foreseen shortcomings), impact analysis reports and
Asset/configuration status reports
Initiates actions needed to secure funds to enhance the infrastructure and staffing
levels in order to cope with growth and change
Assists auditors to audit the activities of the Asset Management/Configuration
Management team for compliance with laid-down procedures. Ensures corrective
action is carried out


Service
Service
Design
Design
Service
Service
Strategy
ITIL

Service
Transition
• Objectives
• Basic concepts
• Roles

Release and Deployment — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Release and Deployment — Objectives

Service
Transition
• Clear, comprehensive release and deployment plans

– Supporting customer and business change projects
• Release packages can be built, installed, tested and
deployed
– Efficiently, successfully and on schedule.
– With minimal impact on production services, operations, and
support teams
– Enabling new or changed services to deliver agreed service
requirements
• Skills and knowledge transfer to enable
– Customers and users to optimize use of the service
– Operations and support staff to run and support the service
A Service Package is a set of things to be released together. It can range in size from
a single release unit that is a small part of one application to a complete IT Service
including hardware, software, processes, documentation, user training, IT Staff
training, service level agreements, supplier contracts and more.
The goal of release and deployment management is to deploy Releases into
production and enable effective use of the service in order to deliver value to the
customer.
The objective of release and deployment management is to ensure that:
There are clear and comprehensive release and deployment plans that enable
the customer and business change projects to align their activities with these
plans
A release package can be built, installed, tested and deployed efficiently to a
deployment group or target environment successfully and on schedule
A new or changed service and its enabling systems, technology and
organization are capable of delivering the agreed service requirements i.e.
utilities, warranties and service levels
There is knowledge transfer to enable the customers and users to optimize their
use of the service to support their business activities

Skills and knowledge are transferred to operations and support staff to enable
them to effectively and efficiently deliver, support and maintain the service
according to required warranties and service levels
There is minimal unpredicted impact on the production services, operations and
support organization
Customers, users and service management staff are satisfied with the service
transition practices and outputs, for example, user documentation and training
The purpose of release and deployment management is to:
Define and agree release and deployment plans with customers and
stakeholders
Ensure that each release package consists of a set of related assets and service
components that are compatible with each other
Ensure that integrity of a release package and its constituent components is
maintained throughout the transition activities and recorded accurately in the
CMS
Ensure that all release and deployment packages can be tracked, installed,
tested, verified, and/or uninstalled or backed out if appropriate
Record and manage deviations, risks, issues related to the new or changed
service and take necessary corrective action

Release and Deployment — Basic concepts (1 of 3)

Release and Deployment —
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
• Release Unit
– CIs that are normally released together
– Typically includes sufficient components to perform a useful
function. For example
• Fully configured desktop PC, payroll application
– Considerations include
• Ease and amount of change needed to deploy
• Resources needed to build, test and deploy
• Complexity of interfaces
A ‘Release unit’ describes the portion of a service or IT infrastructure that is normally

released together according to the organization’s 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 figure below gives a simplified example showing an IT
service made up of systems and service assets, which are in turn made up of service
components.
IT Service A
A1 A2 A3
A2.1 A2.2 A3.1
A2.1.1

Simplified example of release units for an IT service

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 web site is at the page level.
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 and deploy a Release
unit
The amount of resources and time needed to build, test, distribute and
implement a Release unit
The complexity of interfaces between the proposed unit and the rest of the
services and IT infrastructure
The storage available in the build, test, distribution and live environments
Releases should be uniquely identified according to a scheme defined in the Release
policy. The Release identification should include a reference to the CIs that it
represents and a version number that will often have 2 or 3 parts, for example,
emergency fix Releases: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.


Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
• Big bang versus phased approach

– Phased approach can be by users, locations, functionality…
• Push versus Pull deployment
• Automated versus manual deployment
• Release Package
– Single release or many related releases
– Can include hardware, software, utility, warranty,
documentation, training…
Service design will define the approach to transitioning from the current service to the
new or changed service or service offering. The Service Design Package (SDP)
defines the service and solution design components to be transitioned to deliver the
required Service Package(s) and Service Level Package(s). Common options for
release and deployment that are considered in service design are discussed below.
The selected option will can have a significant impact on the release and deployment
resources as well as the business outcomes. It is important to understand the Patterns
of Business Activity, (PBA) and User profiles when planning and designing the
releases.

Big bang versus Phased

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 roll out 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. Variations of the phased approach include:
• Portions of the service are delivered to the live environment in phases, but
all end Users are affected simultaneously (for example, incremental changes
to a shared application)
• Each Release is deployed gradually across the total population of end Users
(for example, one geographical location at a time)
• Different types of service element are deployed in separate phases, for
example, hardware changes are first, followed by user training and then by
the new or changed software
• A combination of all of these approaches is usually adopted, and the plans
may deliberately allow for variations in the light of actual deployment
experience
Push and Pull

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.

In order to deploy via ‘push’ approach, the data on all user locations must be
available. Pull approaches do not rest so heavily on accurate configuration data and
they can trigger an update to user records. This may be through new users
appearing and requesting downloads or expected users not doing so triggering
investigation into their continued existence. As some users will never ‘Pull’ a Release
it may be appropriate to allow a “Pull” within a specified time limit and if this is
exceeded a Push will be forced, for example, for an anti-virus update.
Automation versus Manual

Whether by automation or other means, the mechanisms to release and deploy the
service components should be established in the release design phase and tested in
the build and test stages of the new or changed service.
Automation will help to ensure repeatability and consistency. The time required to
provide a well designed and efficient automated mechanism may not always be
available or viable. If a manual mechanism is used it is important to monitor and
measure the impact of many repeated manual activities as they are likely to be
inefficient and error prone. Too many manual activities will slow down the release
team and create resource/capacity issues that affect the service levels.
Many of the release and deployment activities are capable of a degree of
automation. For example:
Discovery tools aid release planning
Discovery and installation software can check whether the required pre-
requisites and co-requisites are in place before installation of new or changed
software components
Automated builds can significantly reduce build and recovery times that in turn
can resolve scheduling conflicts and delays
Automate configuration baseline procedures to save time and reduce errors in
capturing the status of configurations and releases during build, test and
deployment
Automatic comparisons of the actual ‘live’ configuration with the expected
configuration or CMS help to identify issues at the earliest opportunity that could
cause incidents and delays during deployment
Automated processes to load and update data to the CMS helps to ensure the
records are accurate and complete
Installation procedures automatically update user and licence information in the
CMS

Release Package
Release
Current Baseline (as-is) Package Target Baseline (to-be)
Business/Organization Business/Organization
Architecture BARO1 Architecture
Delivery, feedback Delivery, feedback

and monitoring and monitoring
Service Service
Service Architecture Service Architecture
Portfolio SARO1 Portfolio
Supported by Supported by
Application Information and

Application Information and
Architecture Data Architecture Architecture Data Architecture
AARO1
Manipulated
Using Manipulated Using
by
by
Technology Technology
Architecture Architecture
TARO1
Product Product Build
Architecture Architecture and
Test

Architecture Elements to be Built and Tested
The figure above provides an example of how the architectural elements of a service
may be changed from the current baseline to the new baseline with releases at each
level. The architecture will be different in some organizations but is provided in this
section to give a context for release and deployment activities. The release and
deployment teams need to understand the relevant architecture in order to be able to
plan, package, build and test a release to support the new or changed service. This
helps to prioritize the release and deployment activities and manage dependencies,
for example, the technology infrastructure needs to be ready with operations staff
ready to support it with new or changed procedures before an application is
installed.
The figure also shows how the service architectural elements depend on the service
portfolio that defines the service offerings and service packages. Dependent services
will need to be built and tested in service transition. For example an IT financial
service may be dependent on several internal support services and an external
service.
There are normally dependencies between particular versions of service components
required for the service to operate. For example a new version of an application may
require an upgrade to the operating system and one or other of these two Changes
could require a hardware change, for example, a faster processor or more memory.
In some cases, the release package may consist of a set of documentation and
procedures. These could be deployed via a manual update or through an automatic
publishing mechanism, for example, to the SKMS/web site.

A release package may be a single release unit or a structured set of release units
such as the one shown in the figure below

Example of a Package Release
The example in the figure 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 services, its utilities and warranties, release documentation. Often there will
be different ways of designing a Release Package and consideration needs to 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 issue in testing.


Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service
Transition
• Release and deployment models

– Standard approach for a release
– Overall structure for building the release
– Exit and entry criteria for each stage
– Build and test environments to use
– Roles and responsibilities
– Configuration baseline model
– Template schedules
– Release and deployment steps
– Supporting systems
– Handover activities
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 right time.
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 for each
stage of release and deployment
Considerations in designing the release and deployment model include activities to:
Verify that a Release complies with the SDP, architecture and related standards
Ensure the approach to ensuring the integrity of hardware and software is
protected during installation, handling, packaging and delivery
Ensure the use of standard release and deployment procedures and tools
Automate the delivery, distribution, installation, build and configuration audit
procedures where appropriate to reduce costly manual steps
Manage and deploy/re-deploy/remove/retire software licenses
Package and build the Release Package so that it can be backed out or
remediated if required
Use configuration management procedures, the CMS and DML to manage and
control components during the build and deployment activities
Document the release and deployment steps
Document the deployment group or target environment that will receive the
release
Issue service notifications

Release and Deployment — Roles (1 of 2)

Service
Service
Design
Design
Service
Service
Strategy
ITIL

Service
Transition
• Release package and build manager

– Establishes final release configuration
– Builds final release
– Tests final delivery prior to independent testing
– Establishes and reports known errors and workarounds
– Provides input to final implementation sign-off
Release Packaging and Build management is the flow of work (establish

requirements, design, build, test, deploy, operate and optimize) to deliver
applications and infrastructure that meet the Service Design requirements.
The Release Packaging and Build manager cannot perform this role in isolation;
other functions with which there will be significant interface are:
Security management
Test management
Change and Service Asset Configuration management
Capacity management
Availability management
Incident management
Quality management


Service
Service
Design
Design
Service
Service
Strategy
ITIL

Service
Transition
• Deployment manager
– Final physical delivery of the service implementation
– Co-ordinates documentation and communications
• Including training and customer, service management and technical
release notes
– Plans deployment with Change, SKMS and SACM
– Technical and application guidance and support
• Including known errors and workarounds
– Feedback on effectiveness of the release
– Records metrics for deployment
• To ensure within agreed SLAs

Service Design
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Design
Key concepts Processes
• Four Ps • Service Level Management
• Service Design Package • Service Catalog Management
• Aspects of Service Design • Availability Management
• Information Security Management
• Supplier Management
• Capacity Management
• IT Service Continuity Management

Scope of Service Design — “The Four Ps”

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Scope of Service Design — “The Four Ps”
People
Products Processes
Partners
There are five individual aspects of Service Design considered within the Service
Delivery scope:
The design of new or changed services
The design of the Service Portfolio, including the Service Catalog
The design of the technology architecture and management systems
The design of the processes required
The design of measurement methods and metrics
The Service Design stage of the lifecycle starts with a set of new or changed business
requirements and ends with the development of a service solution designed to meet
the documented needs of the business.
This developed solution, together with its Service Design Pack (SDP, see next note), is
then passed to Service Transition to evaluate, build, test and deploy the new or
changed service and on completion of these transition activities, control is transferred
to the Service Operation stage of the service lifecycle.

The main aim of Service Design is the design of new or changed services. The
requirements for these new services are extracted from the Service Portfolio and each
requirement is analyzed, documented and agreed and a solution design is produced
which is then compared with the strategies and constraints from Service Strategy to
ensure that it conforms to corporate and IT policies.
Many designs, plans and projects fail through a lack of preparation and
management. The implementation of ITIL service management as a practice is about
preparing and planning the effective and efficient use of the four Ps: the People, the
Processes, the Products (services, technology and tools), and the Partners (suppliers,
manufacturers and vendors) as illustrated in the slide diagram.
People
Users, Customers, IT Staff and Managers all come under this heading.
Communication, training and clear definitions of roles and responsibilities for all
parties involved are essential if this valuable asset is to be utilized fully.
Processes
The Service Management processes are core of ITIL and they are distributed along
the Service Management Lifecycle.
Products
There are numerous tools available that are viewed as conforming to ITIL guidelines.
In other words, they have been developed to be consistent with IT Service
Management procedures. However, while tools significantly help in the
implementation and running of IT service provision they are by no means a solution
in their own right:
“In order to support the ITIL processes several different types of tools are required, the
one commonality in all of the tools is that they should be capable of providing a
service level view of the environment.”
“…IT has to be able to provide a reliable, high quality service for an acceptable fee.
This is not achieved through tools alone; any fool can implement a tool!”
From “A Fool with a Tool is Still a Fool” (Hewlett Packard White Paper – by Lindsay
Parker)

Partners
In most organizations there are many groups providing each part of the overall
service, with groups split across organizational boundaries and reporting lines.
Service management processes include the management of the services from all
contributors, irrespective of their function or reporting line. The third party supplier is
encouraged to find and implement improvements, be responsive to customer needs
and is discouraged from becoming complacent.
The Customer may not be aware that a part or all of the service they use is provided
by a third party because the service, when controlled by good service management
processes, is seamless.

Service Design Package (SDP)

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Design Package (SDP)

• Details all aspects of a service
through all stages of its
lifecycle.
• The SDP is passed from
Service Design to Service
Transition for implementation
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. The SDP should contain:
Category Sub-category Description of what is in the SDP

Business
The initial agreed and documented business requirements.
Requirements
Requirements Service Applicability This defines how and where the service would be used.
The business contacts, customer contacts and stakeholders in
Service Contacts
the service.
The changed functionality of the new or changed service,
Service Functional
including its planned outcomes and deliverables, in a
Requirements
formally agreed Statement of Requirements (SoR).
Service level The SLR, revised or new SLA, including service and quality
Requirements targets.
Service Service and Management requirements to manage the new or changed
Design Operational service and its components, including all supporting services
Management and agreements, control, operation, monitoring, measuring
requirements and reporting.
The design transition and subsequent, implementation and
Service Design and
operation of the service solution and its supporting
Topology
components.

Category Sub-category Description of what is in the SDP

Report and plan, including: business benefit,
Organization Organizational financial/technical/resource/organizational assessment,
al Readiness Readiness together with details of all new skills, competences,
Assessment Assessment capabilities required of the service provider organization, its
suppliers, supporting services and contracts.
An overall program or plan covering all stages of the
lifecycle of the service, including the time scales and
Service Program
phasing, for the transition, operation and subsequent
improvement of the new service.
Service Service Transition Overall transition strategy, objectives, policy, risk assessment
Lifecycle Plan Plan and plans.
Service Operational Overall operational strategy, objectives, policy, risk
Acceptance Plan assessment and plans.
Service Acceptance Development and use of Service Acceptance Criteria (SAC)
Criteria for progression through each stage of the service lifecycle.

5 major aspects of Service Design

Service
Service
Design
Design
Service
Service
Strategy
ITIL
5 major aspects of Service Design

• Services
– Including requirements
• Service management systems and tools
– Especially the Service Portfolio
• Technical and management architectures
– And supporting tools
• ITSM processes
• Measurement systems and metrics
All design activities are triggered by changes in business needs and requirements. A
structured and holistic approach to the design activities should be adopted so that all
available information is considered to ensure consistency and integration is achieved
throughout the IT service provider organization within all design activities:
Requirements collection, analysis and engineering to ensure that business
requirements are clearly documented and agreed
Design of appropriate services, technology, processes, information and process
measurements to meet business requirements
Review and revision of all processes and documents involved in Service Design,
including designs, plans, architectures and policies
Liaison with all other design and planning activities and roles, for example,
solution design
Production and maintenance of IT policies and design documents, including
designs, plans, architectures and policies
Revision of all design documents and planning for the deployment and
implementation of IT strategies using “roadmaps”, programs and project plans
Risk assessment and management of all design processes and deliverables
Ensuring alignment with all corporate and IT strategies and policies

An overall, integrated approach should be adapted to the design activities

documented in the above section and should cover the following five major aspects
of design:
1. The design of the service solutions, including all of the functional requirements,
resources and capabilities needed and agreed.
2. The design of Service Management systems and tools, especially the Service
Portfolio for the management and control of services through their lifecycle.
3. The design of the technology architectures and management architectures and
tools required to provide the services.
4. The design of the processes needed to design, transition, operate and improve
the services.
5. The design of the measurement systems, methods and metrics for the services,
the architectures and their constituent components and the processes.

Service Catalog Management

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Catalog Management

• Objectives
• Basic concepts
• Roles

Service Catalog Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Catalog Management — Objectives

• Create and manage an accurate Service Catalog
– A single source of information on all services
The objectives of Service Catalog Management (SCM) are:

Provide a single source of consistent information on all of the agreed services
and ensure that it is widely available to those that are approved to access it.
Ensure that a Service Catalog is produced and maintained containing accurate
information on all operational services and those being prepared to be run
operationally.
SCM manages the information contained within the Service Catalog and ensures
that it 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.

Service Catalog Management — Basic concepts

Service Catalog Management —
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Basic concepts
• The Service Catalog
– Part of the Service Portfolio
– Details of all operational services and those being prepared for
transition
– Business Service Catalog
• Details of all of the IT services delivered to customers
• Visible to the customers
– Technical Service Catalog
• Details of all supporting services
• Not usually visible to customers
Over the years, organizations’ IT Infrastructures have grown and developed, and
there may not be a clear picture of all the services currently being provided and the
customers of each service. In order to establish an accurate picture, it is
recommended that an IT Service Portfolio containing a Service Catalog are produced
and maintained to provide a central accurate set of information on all services and to
develop a service focused culture.
The Service Portfolio is produced as part of Service Strategy and should include
participation by those involved in Service Design, Transition, Operation and
Improvement. Once a Service is ‘chartered’ (being developed for use by customers),
Service Design produces the specifications for the service and it is at this point the
Service should be added to the Service Catalog.
The Service Catalog should contain details of all operational services being provided
or those being prepared for transition to the live environment, a summary of their
characteristics and details of the customers and maintainers of each.

See the figure below for a visual representation of the Service Portfolio/Catalog:
The Service Catalog has two aspects:

The Business Service Catalog: containing details of all of the IT services
delivered to the customer, together with relationships to the business units and
the business process that rely upon the IT services. This is the customer view of
the Service Catalog.
The Technical Service Catalog: containing details of all of the IT services
delivered to the customer, together with relationships to the supporting services,
shared services, components and CIs necessary to support the provision of the
service to the business. This should underpin the Business Service Catalog and
not form part of the customer view.

Service Catalog Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Catalog Management — Roles

• Service Catalog Manager
– Produce and maintain the Service Catalog
– Ensure all operational services and those being prepared for
operational running are recorded
– Ensure all information in the Service Catalog is accurate and up
to date
– Ensure all information is consistent with the information in the
Service Portfolio
– Ensure all information is adequately protected and backed-up

Service Level Management

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management

• Objectives
• Scope
• Basic value
• Business concepts
• Activities
• Key metrics
• Roles
• Challenges
• Interfaces
Service Level Management (SLM) negotiates, agrees and documents appropriate IT

service targets with representatives of the business, and then monitors and produces
reports on the service provider’s ability to deliver the agreed level of service.
SLM is a vital process for every IT service provider organization in that it is
responsible for agreeing and documenting service level targets and responsibilities
within Service Level Agreements (SLAs) and Service Level Requirements (SLRs), for
every activity within IT.
If these targets are appropriate and accurately reflect the requirements of the
business, then the service delivered by the service providers will align with business
requirements and meet the expectations of the customers and users in terms of service
quality.
If the targets are not aligned with business needs, then service provider activities and
service levels will not be aligned with business expectations and problems will
develop.
The SLA is effectively a level of assurance or warranty with regard to the level of
service quality delivered by the service provider for each of the services delivered to
the business.
The success of SLM is very dependent on the quality of the Service Portfolio and the
Service Catalog and their contents, because they provide the necessary information
on the services to be managed within the SLM process.

Service Level Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Objectives

• Negotiate, agree and document service levels
• Measure, report and improve service levels
• Communicate with business and customers
The purpose of the SLM process is to ensure that all operational services and their
performance are measured in a consistent, professional manner throughout the IT
organization, and that the services and the reports produced meet the needs of the
business and customers.
Service Level Management process ensures that an agreed level of IT service is
provided for all current IT services, and that future services are delivered to agreed
achievable targets. Proactive measures are also taken to seek and implement
improvements to 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
Provide and improve the relationship and communication with the business and
customers
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 proactive measures to improve the levels of service delivered are
implemented wherever it is cost-justifiable to do so

Service Level Management — Scope

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Scope

• Ensure quality of service
matches expectations
– Existing services
– Requirements for new or
changed services.
– Expectation and perception of
the business, customers and
users
SLM should provide a point of regular contact and communication to the customers
and business managers of an organization. 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 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 for all current
live services and manage the level 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.
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.

Service Level Management — Business value

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Business value

• Consistent interface to the business for all IT service related
issues
• Feedback on service failures or breaches & resolution actions
taken
• Reliable communications channel and trusted relationship
SLM provides a consistent interface to the business for all service related issues. It
provides the business with the agreed service targets and the required management
information to ensure that those targets have been met.
Where targets are breached, SLM should provide feedback on the cause of the
breach and details of the actions taken to prevent the breach from recurring. Thus
SLM provides a reliable communication channel and a trusted relationship with the
appropriate customers and business representatives.

Service Level Management — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Basic concepts

Customers/Users
Service Level Agreements
Service A Service B Service C
IT Infrastructure
Operational Level Agreements Underpinning Contracts
Internal Organization External Organization
SLM is the name given to the processes of planning, coordinating, drafting,

agreeing, monitoring and reporting of SLAs, and the ongoing review of service
achievements to ensure that the required and cost-justifiable service quality is
maintained and gradually improved.
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.
However, SLM is not only concerned with ensuring that current services and SLAs are
managed, but it is also involved in ensuring that new requirements are captured and
that new or changed services and SLAs are developed to match the business needs
and expectations.
SLAs provide the basis for managing the relationship between the service provider
and the customer, and SLM provides that central point of focus for a group of
customers, business units or lines of business.
SLM is also responsible for ensuring that all targets and measures agreed in SLAs
with the business are ‘backed off’ or supported by appropriate underpinning
Operational Level Agreements (OLAs) or contracts, with internal support units and
external partners and suppliers.

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. The same with
Underpinning Contracts (UCs), which involve external support organizations.
The slide above shows the relationship between the business and its processes and
the services, and the associated technology, supporting services, teams and suppliers
required to meet their needs. It demonstrates how important the SLAs, OLAs and UCs
are in defining and achieving the level of service required by the business.

Service Level Management — Activities

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Activities

• Design SLA frameworks
• Identify Service Level Requirements (SLRs)
– Agree and document Service Level Agreements (SLAs)
– Negotiate and document Operational Level Agreements (OLAs) and
Underpinning Contracts (UCs)
• Monitor service performance against SLA
• Measure and improve Customer Satisfaction
• Review and revise underpinning agreements and service scope
• Produce service reports
• Conduct service reviews and instigate improvements
• Review and revise SLAs, OLAs and UCs
• Develop contacts and relationships
• Manage complaints and compliments
The key activities within the SLM process should include:

Designing SLA frameworks
Using the Service Catalog 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 organization’s needs (Service-based, Customer-based or Multi-
level SLA).
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.
This is one of the earliest activities within the Service Design stage of the service
lifecycle. Once the Service Catalog has been produced and the SLA structure
has been agreed, a first SLR must be drafted. It is advisable to involve customers
from the outset, but rather than going along with a blank sheet to start with, it
may be better to produce a first outline draft of the performance targets and the
management and operational requirements, as a starting point for more detailed
and in-depth discussion.

Monitor and measure service performance achievements of all operational

services against targets within SLAs.
Nothing should be included in an SLA unless it can be effectively monitored and
measured at a commonly agreed point.
Collate, measure and improve customer satisfaction.
There are a number of important ‘soft’ issues that cannot be monitored by
mechanistic or procedural means, such as customers’ overall feelings. For
example, even when there have been a number of reported service failures, the
customers may still feel positive about things, because they may feel satisfied
that appropriate actions are being taken to improve things.
Review and revise underpinning agreements and service scope.
IT service providers are dependent to some extent on their own internal technical
support teams or on external partners or suppliers. They cannot commit to
meeting SLA targets unless their own support team’s and suppliers’
performances underpin these targets. Contracts with external suppliers are
mandatory, but many organizations have also identified the benefits of having
simple agreements with internal support groups, usually referred to as OLAs.
‘Underpinning agreements’ is a term used to refer to all underpinning OLAs,
SLAs and underpinning contracts.
Produce service reports.
Immediately the SLA is agreed and accepted, monitoring must be instigated and
service achievement/misses reports must be produced. The SLA reporting
mechanisms, intervals and report formats must be defined and agreed with the
customers.
Conduct service reviews and instigate improvements within an overall Service
Improvement Program/Plan (SIP).
Periodic review meetings must be held on a regular basis with customers (or their
representatives) to review the service achievement in the last period and to
preview any issues for the coming period. It is normal to hold such meetings
monthly, or as a minimum, quarterly.
Review and revise SLAs, service scope and underpinning agreements.
All agreements and underpinning agreements, including SLAs, underpinning
contracts and OLAs, must be kept up-to-date. They should be brought under
Change and Configuration Management control and reviewed periodically, at
least annually, to ensure that they are still current and comprehensive, and are
still aligned to business needs and strategy.

Develop and document contacts and relationships with the business, customers
and stakeholders.
It is very important that SLM develops trust and respect with the business,
especially with the key business contacts. Using the Service Catalog, especially
the Business Service Catalog element of it, enables SLM to be much more
proactive.
Develop, maintain and operate procedures for logging, actioning and resolving
all complaints, and for logging and distributing compliments.
The SLM process should also include activities and procedures for the logging
and management of all complaints and compliments. The logging procedures
are often performed by the Service Desk as they are similar to those of Incident
Management and Request Fulfillment.

Service Level Management — Key metrics

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Key metrics

• Number and % of targets being met
• Number and severity of service breaches
• Number and % of up to date SLAs
• Number of services with timely reports and service reviews
• Improvements in Customer Satisfaction
Key performance indicators (KPIs) and metrics can be used to judge the efficiency
and effectiveness of the SLM activities and the progress of the SIP. These metrics
should be developed from the service, customer and business perspective and should
cover both subjective and objective measurements such as the following:
Objective metrics
Number or percentage of service targets being met
Number and severity of service breaches
Number of services with up-to-date SLAs
Number of services with timely reports and active service reviews
Subjective metric
Improvements in Customer Satisfaction

Service Level Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Roles

• Service Level Manager
– Process Owner
– Understand Customers
– Create and Maintain SLAs
and OLAs
– Review and Reporting
– Ensure that Changes are
assessed for impact on
service levels
The Service Level Manager has responsibility for ensuring that the aims of Service
Level Management are met, as the process owner. This includes responsibilities such
as:
Keeping aware of changing business needs, understanding what customers
need
Ensuring that the current and future service requirements of customers are
identified, understood and documented in SLA and SLR documents
Negotiating and agreeing levels of service to be delivered with the customer
(either internal or external). Formally documenting these levels of service 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 Catalog, Application portfolio and the corresponding maintenance
procedures
Ensuring that targets agreed within underpinning contracts are aligned with SLA
and SLR targets

Ensuring that service reports are produced for each customer service and that
breaches of SLA targets are highlighted, investigated and actions taken to
prevent their recurrence
Ensuring that service performance reviews are scheduled, carried out with
customers regularly and are documented with agreed actions progressed
Ensuring that improvement initiatives identified in service reviews are acted upon
and progress reports are provided to customers
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
CAB meetings if appropriate
Identification of all key stakeholders and customers
Developing relationships and communication with stakeholders, customers and
key users
Definition and agreement of complaints and their recording, management,
escalation where necessary and resolution
Definition recording and communication of all complaints

Service Level Management — Challenges

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Challenges

• Identifying appropriate customer/business representatives
• Overcoming ‘current issues’
• Differing requirements at different levels within the customer
community
• Achieving accurate monitoring of service achievements
• Getting SLAs signed at the appropriate level
One challenge faced by SLM is that of identifying suitable customer representatives

with whom to negotiate. Who ‘owns’ the service? In some cases, this may be
obvious, and a single customer manager is willing to act as the signatory to the
agreement.
In other cases, it might take quite a bit of negotiating or cajoling to find a
representative ‘volunteer’ (beware that volunteers often want to express their own
personal view rather than represent a general consensus), or it may be necessary to
get all customers to sign.
Care should be taken when opening discussions on service levels for the first time, as
it is likely that ‘current issues’ (the failure that occurred yesterday) or long-standing
grievances (that old printer that we have been trying to get replaced for ages) are
likely to be aired at the outset.
On negotiating the current support hours for a large service, that span geographies,
an organization may found discrepancies in the required time of usage between
Head Office and the field office’s customers. Head Office might win the ‘political’
argument, but if field office’s has the majority of customers, they actually will be
using more services than Head office.

Where no past monitored data is available, it is advisable to leave the agreement in

draft format for an initial period, until monitoring can confirm that initial targets are
achievable. Targets may have to be re-negotiated in some cases.
One point to ensure is that at the end of the drafting and negotiating process, the
SLA is actually signed by the appropriate managers on the customer and IT service
provider sides to the agreement. This gives a firm commitment by both parties that
every attempt will be made to meet the agreement. Generally speaking, the more
senior the signatories are within their respective organizations, the stronger the
message of commitment.

Service Level Management — Interfaces

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Service Level Management — Interfaces

• Service Portfolio Management
• Service Catalog Management
• Supplier Management
• Availability Management, Capacity Management and ITSCM
– To understand risks, options and BIA
• Service Knowledge Management System
• Continuous Service Improvement
• All other service management processes
– To agree and document required customer outcomes
There are a number of sources of information that interfaces and are relevant to the
Service Level Management process. These should include:
Business information: from the organization’s business strategy, plans, and
financial plans and information on their current and future requirements
The strategies, policies and constraints from Service Strategy
The Service Portfolio and Service Catalog
Continuous Service Improvement — Service Improvement Program/Plan (SIP): An
overall program or plan of prioritized improvement actions, encompassing all
services and all processes, together with associated impacts and risks
Service Knowledge Management System: Containing information on the
relationships between the business services, the supporting services and the
technology

Advice, information and input from any of the other processes, for example,:
• Incident Management — Number/period of incidents, major incidents
• Capacity Management, Availability and IT Services Continuity
Management — understand risks, options and Business Impact Analysis
• Change Management — Information such as a Change Schedule and a
need to assess all changes for their impact on all services
Together with the existing SLAs, SLRs, and OLAs and past service reports on the
quality of service delivered.

Availability Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Availability Management
• Objectives
• Basic concepts
• Roles

Availability Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Availability Management — Objectives

• Ensure agreed level of availability is provided
• Continually optimize and improve availability of
– IT Infrastructure
– Services
– Supporting organization
• Provide cost effective availability improvements that can
deliver business and customer benefits
• Produce and maintain an availability plan
The Availability Management process ensures that the level of service availability
delivered in all services is matched to or exceeds the current and future agreed needs
of the business, in a cost effective manner.
Availability Management 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.
The objectives of Availability Management are:
To produce and maintain an appropriate and up to date Availability Plan, which
reflects the current and future needs of the business
To provide advice and guidance to all other areas of the business and IT on all
availability related issues
To ensure that service availability achievements meet or exceed all of their
agreed targets, by managing services and resources related availability
performance
To assist with the diagnosis and resolution of availability related incidents and
problems
To asses the impact of all changes on the Availability Plan and the performance
and capacity of all services and resources
To 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.

Availability Management — Basic concepts (1 of 6)

Availability Management —
Service
Service
Design
Design
Service
Service
Strategy
ITIL
• Availability Management process includes
– Proactive activities
• Design and planning activities
• Planning, design and improvement of availability
– Reactive activities
• Operational activities
• Monitoring, measuring, analysis and management of all events,
incidents and problems involving unavailability
The Availability Management process is continually trying to ensure that all

operational services meet their agreed availability targets and that new or changed
services are designed appropriately to meet their intended targets without
compromising the performance of existing services.
In order to achieve this Availability Management should perform the reactive and
proactive activities illustrated in the following figure.

Reactive activities
Monitor, measure,
analyse report & review
service & component Availability
availability Management
Information System
(AMIS)
Investigate all service &
component unavailability &
investigate remedial action Availability
Management
reports
Proactive activities Availability

Plan
Risk assessment Plan & design for new
& Management & changed services
Availability
design criteria
Implement cost – Review all new &
justifiable counter changed services & test
measures all availability & resilience
mechanisms Availability
testing
schedule

The Availability Management Process
The reactive activities of Availability Management consist of monitoring, measuring,

analyzing, reporting and reviewing all aspects of component and service availability.
This is to ensure that all agreed service targets are measured and achieved.
Wherever deviations or breaches are detected, these are investigated and remedial
action instigated.
Most of these reactive activities are conducted within the Operations stage of the
lifecycle and are linked into the Monitoring and Control activities, Event and Incident
Management Processes.
The proactive activities consist of 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.


Service
Service
Design
Design
Service
Service
Strategy
ITIL
• Availability
– The ability of a service, component or configuration item to
perform its agreed function when required
– Often measured and reported as a percentage
(Agreed Service Time (AST) – Downtime)

Availability ( % ) = --------------------------------------------------------------------------------------------- X 100 %
Agreed Service Time (AST)
– Most important measurements are those that reflect

availability from the business and user perspective
Availability Management relies on the monitoring, measurement, analysis and

reporting of the following aspects: Availability, Reliability, Maintainability and
Serviceability.
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:
Availability (%) = (AST – DT) x 100 = Service or Component Availability
AST
Where:
AST = Agreed service time
DT = Actual downtime during agreed service time
Note
Although downtime is included in the above calculation only when it occurs
within the Agreed Service Time (AST), total downtime should also be recorded
and reported.
The most important measurements are those that reflect availability from the business
and user perspective.
Reliability, Maintainability and Serviceability will be explained in the next slides and
notes.


Service
Service
Design
Design
Service
Service
Strategy
ITIL
• Reliability
– Measure of how long a service, component or CI can perform
its agreed function without interruption
• Maintainability
– Measure of how quickly and effectively a service, component or
CI can be restored to normal working after a failure
• Serviceability
– Ability of a third party supplier to meet the terms of their
contract
Reliability
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).
Definition of resilience – the capability of a set of CIs to continue to provide a
required function when one or more CIs in the set have suffered a failure.
Reliability is often measured and reported as Mean Time Between Service Incidents
(MTBSI) or Mean Time Between Failures (MTBF):
Available time in hours
Reliability (MTBSI in hours ) = -------------------------------------------
Number of breaks
Available time in hours – Total downtime in hours

Reliability ( MTBF in hours ) = -------------------------------------------------------------------------------------------------------
Number of breaks

Maintainability
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 Mean Time To
Restore Service (MTRS) and should be calculated using the following formula:
Total Downtime in hours
Maintainability (MTRS in hours) = -------------------------------------------------------
Number of service breaks
Serviceability
The ability of a third party supplier to meet the terms of their contract. Often this
contract will include agreed levels of availability, reliability and/or maintainability
for a supporting service or component.


Service
Service
Design
Design
Service
Service
Strategy
ITIL
Incident Incident Incident
start start start
Uptime Uptime Uptime (availability)
Service Service Service

available available available
Downtime (time to restore)(MTRS) Downtime

Service
Service unavailable unavailable
Availability Availability
Diagnose Recover
Detect Repair Restore
Time between system incidents Time between failures (MTBF)
Time


Service
Service
Design
Design
Service
Service
Strategy
ITIL
• Vital Business Function (VBF)
– A Function of a Business Process which is critical to the success
of the Business.
• High Availability
– Minimizing or hiding the effects of a component failure
• Fault Tolerance
– Ability of an IT service, component or CI to operate correctly
after component failure
Vital Business Function

The term Vital Business Function (VBF) is used to reflect the business critical elements
of the business process supported by an IT service. An IT service may support a
number of business functions that are less critical.
For example in an Automated Teller Machine (ATM) or cash dispenser service the
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 IT.
Certain VBFs may need special designs, which are now being used as a matter or
course within service design plans, incorporating High Availability, Fault Tolerance,
Continuous Operation and Continuous Availability. The last two will be discussed in
the next note.

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.


Service
Service
Design
Design
Service
Service
Strategy
ITIL
• Continuous Operation
– Approach or design to eliminate planned downtime of a service
• Continuous Availability
– Approach or design to achieve 100% availability
– An IT service that has no planned or unplanned downtime
Continuous Operation
An approach or design to eliminate planned downtime of an IT service. Note
that individual components or CIs may be down even though the IT service
remains available.
Continuous Availability
An approach or design to achieve 100% availability
An IT service that has no planned or unplanned downtime

Availability Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Availability Management — Roles

• Availability Manager
– Process owner
– Ensuring services deliver agreed levels of availability
– Creation and maintenance of an availability plan
– Assessing changes
– Monitoring and reporting availability
– Proactive improvement of service availability and optimization
of the IT infrastructure to optimize costs
– Assisting with investigation and diagnosis of incidents and
problems which cause availability issues
The Availability Manager is the process owner that has responsibility for ensuring
that the aims of Availability Management are met. This includes responsibilities such
as:
Ensuring that all new services are designed to deliver the levels of availability
required by the business
Ensuring that all existing services deliver the levels of availability agreed with the
business in SLAs
Creation and maintenance of an availability plan
Assessing changes for their impact on all aspects of availability including overall
service availability and the Availability Plan
To be responsible for the monitoring of IT components and actual IT Services
availability achieved against SLA, creating relevant reports
To proactively improve service availability wherever possible and to optimize the
availability of the IT infrastructure to deliver cost effective improvements that
deliver tangible benefits to the business
Assisting with the investigation and diagnosis of all incidents and problems
which cause availability issues or unavailability of services or components

Information Security Management

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Information Security Management

• Objectives
• Basic concepts
• Roles
Information Security Management (ISM) needs to be considered within the overall

Corporate Governance framework. Corporate Governance is the set of
responsibilities and practices exercised by the board and executive management with
the goal of providing strategic direction, ensuring the objectives are achieved,
ascertaining the risks are being managed appropriately and verifying that the
enterprises resources are used effectively.
Information security is a management activity within the Corporate Governance
framework, which provides the strategic direction for security activities and ensures
objectives are achieved. It further ensures that the information security risks are
appropriately managed and enterprise information resources are used responsibly.
The purpose of ISM is to provide a focus for all aspects of IT security and manage all
IT security activities.

Information Security Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Information Security Management — Objectives

• To protect the interests of those relying on information
• To protect the systems and communications that deliver the
information
• Specifically related to harm resulting from failures of:
– Availability
– Confidentiality
– Integrity
• The ability to do business with other organizations safely
The term “information” is used as a general term and includes data stores, databases
and metadata.
The objective of information security 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 availability, confidentiality, and integrity.
For most organizations, the security objective is met when:
Information is available and usable when required, and the systems that provide
it can appropriately resist attacks and recover from or prevent failures
(availability)
Information is observed by or disclosed to only those who have a right to know
(confidentiality)
Information is complete, accurate and protected against unauthorized
modification (integrity)
Business transactions as well as information exchanges between enterprises, or
with partners can be trusted (authenticity and non-repudiation)
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 program that
supports the business objectives.

Information Security Management — Basic concepts

Information Security Management —
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Basic concepts
• Information Security Policy
• Information Security Management System (ISMS)
• Risk analysis and risk management
• Security controls
Executive management is ultimately responsible for their organization’s information

and is tasked with responding to issues that affect its protection.
In addition, boards of directors are expected to make information security an integral
part of corporate governance. All IT service provider organizations must therefore
ensure that they have a comprehensive ISM policy(s) and the necessary security
controls in place to monitor and enforce the policies.
The Information Security Management process and framework will generally consist
of:
An Information Security Policy (ISP) and specific security policies that address
each aspect of strategy, controls and regulation
The ISP 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:
• An overall ISP
• Use and misuse of IT assets policy

• An access and password control policy

• An email, Internet and anti-virus policy
• An information and document classification policy
• A remote access policy
• A policy with regard to supplier access of IT service, information and
components
• An asset disposal policy
An Information Security Management System (ISMS), containing the standards,
management procedures and guidelines supporting the information security
policies
The framework or the ISMS in turn provides a basis of the development of a cost
effective information security program that support the business objectives. It will
involve the four P’s of People, Process, Products and technology as well as
Partners and suppliers to ensure high levels of security are in place.
ISO 27001 is the formal standard against which organizations may seek
independent certification of their ISMS (meaning their frameworks to design,
implement, manage, maintain and enforce information security processes and
controls systematically and consistently throughout the organizations).
Performing security risk analysis and risk management in conjunction with
Availability and IT Service Continuity Management
Security controls
The information security manager must understand that security is not a step in
the life cycle of services and systems or that security can be solved through
technology. Rather, information security must be an integral part of all services
and systems and is an ongoing process that needs to be continuously managed
using a set of security controls.

Threat
Prevention/ Evaluation/
Reduction Reporting
Incident
Direction/ Evaluation/
Repression Reporting
Damage
Correction/ Evaluation/
Recovery Reporting
Control

Security controls for threats and incidents
The set of security controls should be designed to support and enforce the ISP
and to minimize all recognized and identified threats. The controls would be
considerably more cost effective if included within the design of all services. This
will ensure the continued protection of all existing services and that new services
and access to them are in line with the ISP.
Security measures can be used in a specific stage in the prevention and
handling of security incidents, as illustrated in the above diagram. Security
incidents are not solely caused by technical threats – statistics show that, for
example, the large majority stem from human errors (intended or not) or
procedural errors, and often have implications in other fields such as safety,
legal or health.

Information Security Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Information Security Management — Roles

• Security Manager
– Process owner
– Develop and maintain Information Security Policy
– Communicate and publicize security awareness and policy
– Perform security risk analysis and risk management
– Monitor and manage security breaches and incidents
The Security Manager has responsibility for ensuring that the aims of Information
Security Management are met. This includes such tasks and responsibilities as:
Developing and maintaining the Information Security Policy and a supporting set
of specific policies, ensuring appropriate authorization, commitment and
endorsement from senior IT and business management
Communication and publicizing of the Information Security Policy to all
appropriate parties
Ensuring that the Information Security Policy is enforced and adhered to
Identifying and classifying IT and information assets (Configuration Items) and
the level of control and protection required
Assisting with Business Impact Analyses
Performing security risk analysis and risk management in conjunction with
Availability and IT Service Continuity Management
Designing security controls and developing security plans
Developing and documenting procedures for operating and maintaining security
controls

Monitoring and managing all security breaches and handling security incidents,
taking remedial action to prevent recurrence wherever possible
Reporting, analysis and reduction of the impact and volumes of all security
incidents in conjunction with Problem Management
Promoting education and awareness of security
Maintaining a set of security controls and documentation and regularly
reviewing and auditing all security controls and procedures
Ensuring all changes are assessed for impact on all security aspects including
the Information Security Policy and security controls and attendance at CAB
meetings when appropriate
Performing security tests
Participating in any security reviews arising from security breaches and
instigating remedial actions
Ensuring that the confidentiality, integrity and availability of the services are
maintained at the levels agreed in the SLAs and conform to all relevant statutory
requirements
Ensure that all access to services by external partners and suppliers is subject to
contractual agreements and responsibilities
Act as a focal point for all security issues

Supplier Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Supplier Management
• Objectives
• Basic concepts
• Roles
The goal of the Supplier Management process is to manage suppliers and the
services they supply, to provide seamless quality of IT service to the business,
ensuring value for money is obtained.

Supplier Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Supplier Management — Objectives

• Manage supplier relationship and performance
• Negotiate and agree contracts
– In conjunction with Service Level Management (SLM)
– Ensure that contracts and agreements are aligned to business
needs and support SLAs
• Manage contracts throughout lifecycle
• Maintain a supplier policy and a supporting Supplier and
Contract Database (SCD)
The Supplier Management process ensures that suppliers and the services they
provide are managed to support IT service targets and business expectations.
The main objectives of the Supplier Management process are to:
Obtain value for money from suppliers and contracts
Ensure that underpinning contracts and agreements 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 Database
(SCD)

Supplier Management — Supplier and Contracts Database (SCD)

Supplier Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Supplier and Contracts Database (SCD)

Supplier strategy
& policy
Service Knowledge
Management
System
(SKMS) Evaluation of new
suppliers & contracts
Establish new
Supplier categorization suppliers & contracts
& maintenance of the
SCD
Supplier & contract

management &
performance
Supplier & contract

database SCD
Contract renewal
Supplier reports and/or termination
and information
The Supplier Management process attempts to ensure that suppliers meet the terms,
conditions and targets of their contracts and agreements, while trying to increase the
value for money obtained from suppliers and the services they provide.
All Supplier Management process activity should be driven by a supplier strategy
and policy from Service Strategy.
In order to achieve consistency and effectiveness in the implementation of the policy
a Supplier and Contract Database (SCD) should be established as illustrated in the
slide, together with clearly defined roles and responsibilities.
Ideally the SCD should form an integrated element of a comprehensive CMS or
SKMS, recording all supplier and contract details, together with details of the type of
service(s) or product(s) provided by each supplier, and with all other information and
relationships with other associated CIs.
The services provided by suppliers will also form a key part of the Service Portfolio
and the Service Catalog. The relationship between the supporting services and the IT
and business services they support are key to providing quality IT services.

This information within the SCD will provide a complete set of reference information
for all Supplier Management procedures and activities:
Supplier categorization and maintenance of the Supplier and Contracts
Database (SCD)
Evaluation and set up of new suppliers and contracts
Establish new suppliers
Supplier and Contract Management and performance
Contract renewal and termination
The first two elements within the above list are covered within the Service Design
stage.
The third element is part of Service Transition and the last two are part of the Service
Operation stage.

Supplier Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Supplier Management — Roles

• Supplier Manager
– Process owner
– Maintain and review
• Supplier and Contracts Database (SCD)
• Processes for contract disputes, expected end, early end or transfer
of a service
– Assist in development and review of SLAs, contracts,
agreements etc.
– Perform supplier, contract and SLA reviews
• Identify improvement actions and ensure these are implemented
– Assess changes for impact on suppliers, supporting services and
contracts

Capacity Management
Service
Service
Design
Design
Service
Service
Strategy
ITIL
Capacity Management
• Objectives
• Basic concepts
• Roles
Capacity Management is a process that extends across the Service Lifecycle. A key
success factor in managing capacity is ensuring it is considered during the Design
stage, and this is the reason that the Capacity Management Process is included in
the Design stage.
Capacity Management is supported initially in Service Strategy where the decisions
and analysis of business requirements, customer outcomes influences the
development of patterns of business activity (PBA), levels of service (LOS) and service
level packages (SLPs) are identified. This provides the predictive and ongoing
capacity indicators needed to align capacity to demand.

Capacity Management — Objectives

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Capacity Management — Objectives

• To produce and maintain a Capacity Plan
• To provide advice and guidance on capacity and
performance related issues
• To ensure services meet or exceed performance targets
• To assist in diagnosing and resolving capacity related
problems and incidents
• To assess the impact of changes on the Capacity Plan
• Proactive capacity and performance measures
The Capacity Management process ensures that cost justifiable IT capacity always
exists in all areas of IT, and is matched to the current and future agreed needs of the
business, in a timely manner.
Capacity Management provides a point of focus and management for all capacity
and performance related issues, relating to both services and resources.
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
capacity and performance related issues
To ensure that service performance achievements meet or exceed all of their
agreed performance targets, by managing the performance and capacity of
both services and resources
To assist with the diagnosis and resolution of performance and capacity related
incidents and problems
To asses the impact of all changes on the Capacity Plan and the performance
and capacity of all services and resources
To ensure that proactive measures to improve the performance of services are

Capacity Management — Basic concepts

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Capacity Management — Basic concepts

• Balancing costs against resources needed
• Balancing supply against demand
• Should be involved at all stages of the lifecycle
• Forward looking, regularly updated Capacity Plan
• Three levels of concern:
– Business Capacity Management
– Service Capacity Management
– Component Capacity Management
• Capacity Management Information System
Capacity Management ensures that the capacity and performance of the IT services
and systems matches the evolving agreed demands of the business in the most cost-
effective and timely manner. Capacity Management is essentially a balancing act:
Balancing costs against resources needed: The need to ensure that processing
Capacity that is purchased is not only cost justifiable in terms of business need,
but also the need to make the most efficient use of those resources.
Balancing supply against demand: The need to ensure that the available supply
of IT processing power matches the demands made on it by the business, both
now and in the future; it may also be necessary to manage or influence the
demand for a particular resource.
Capacity Management processes and planning must be involved in all stages of the
service lifecycle from strategy and design through transition and operation to
improvement.

The appropriate capacity and performance should be designed in to services and

components from the initial design stages. This will ensure that not only does the
performance of any new or changed service meet its expected targets, but that all
existing services continue to meet all of theirs. This is the basis of stable service
provision.
The overall Capacity Management process is continually trying to cost effectively
match IT resources and capacity to the ever changing needs and requirements of the
business. This requires the tuning and optimization of the current resources and the
effective estimation and planning of the future resources, as illustrated in the
following figure.
Review current Capacity Management

capacity & performance
Information System
(CMIS)
Improve current Capacity &

service & component
performance
capacity
reports & data
Assess, agree &

document new Forecasts
requirements & capacity
Plan new Capacity plan

capacity

Capacity Management Process

Capacity Management has three levels of concern:

Business Capacity Management
This 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 already existing services.
Service Capacity Management
The focus of this sub-process is 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 the
collected data is recorded, analyzed 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 implemented.

Component Capacity Management

The focus in this sub-process is 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, analyzed
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.
The Capacity Management Information System (CMIS)

The CMIS holds the information needed by all sub-processes within Capacity
Management. For example, the data monitored and collected as part of
Component and Service Capacity Management is used in Business Capacity
Management to determine what infrastructure components or upgrades to
components are needed, and when.
Service Portfolio
Business
requirement
Capacity &
Performance reports
Business Review current

Capacity Management capacity & performance
SLA/SLR IT service
Improve current service
design
& component capacity
Capacity Management
Information System
Assess, agree & (CMIS)
Service
document new
Capacity Management
requirement & capacity
Component
Plan new capacity
Capacity Management Forecasts
Capacity Plan
Capacity
Management Tools

Capacity Management sub-process

Capacity Management — Roles

Service
Service
Design
Design
Service
Service
Strategy
ITIL
Capacity Management — Roles

• Capacity Manager
– Process owner
– Proactive planning
• Service Level Manager
– Provides capacity requirements through discussions with the
Business users
• Technical and Application Management
– Day-to-day capacity management activities
– Reacting to capacity incidents and problems
A Capacity Manager, as the process owner, has responsibility for ensuring that the
aims of Capacity Management are met. This includes such tasks as:
Capacity Management has overall responsibility for ensuring that there is
adequate IT Capacity to meet required levels of service and for ensuring that
senior IT management is correctly advised on how to match Capacity and
demand, and to ensure that use of existing Capacity is optimized
Forecasting future capacity requirements based on business plans, usage trends,
sizing of new services, etc.
Identifying with the Service Level Manager, capacity requirements through
discussions with the business users
Understanding the current usage of the infrastructure and IT services, and the
maximum capacity of each component
Production, regular review and revision of the Capacity Plan, in line with the
organization’s business planning cycle, identifying current usage and forecast
requirements during the period covered by the plan
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
Assessment of new technology and its relevance to the organization in terms of
performance and cost
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. Technical and Application
Management roles assist with day-to-day capacity management activities
Note
Both Service Level Manager and Technical and Application Management are
outlined elsewhere in the student notes.

IT Service Continuity Management (ITSCM)

Service
Service
Design
Design
Service
Service
Strategy
ITIL
IT Service Continuity Management (ITSCM)

• Objectives
• Basic concepts
• Roles

ITSCM — Objectives
Service
Service
Design
Design
Service
Service
Strategy
ITIL
ITSCM — Objectives
• To maintain Service Continuity and IT Recovery plans that
support the Business Continuity plans
• To complete regular Business Impact Analysis exercises to
ensure that plans are current and relevant
• To conduct regular risk assessment and management
activities
• To provide advice and guidance on issues related to Service
Continuity
• To implement measures to meet or exceed Business Continuity
targets
• To check the impact of changes on existing plans
• To negotiate necessary contracts with suppliers
IT Service Continuity Management (ITSCM) supports the overall Business Continuity

Management process by ensuring that the required IT technical and service facilities
(including computer systems, networks, applications, data repositories,
telecommunications, environment, technical support and Service Desk) can be
resumed within required, and agreed, business timescales.
As technology is a core component of most business processes, continued or high
availability of IT is critical to the survival of the business as a whole. This is achieved
by introducing risk reduction measures and recovery options. Like all elements of
ITSM successful implementation of ITSCM can only be achieved with senior
management commitment and the support of all members of the organization.
Ongoing maintenance of the recovery capability is essential if it is to remain
effective.
ITSCM maintains the necessary ongoing recovery capability within the IT services
and their supporting components.

The objectives of ITSCM are:

To maintain a set of IT Service Continuity Plans and IT recovery plans that
support the overall Business Continuity Plans (BCPs) of the organization
To complete regular Business Impact Analysis (BIA) exercises to ensure that all
continuity plans are maintained in line with changing business impacts and
requirements
To conduct regular risk assessment and management exercises in conjunction
particularly with the business and the Availability Management and Security
Management processes, that manage IT services within an agreed level of
business risk
continuity and recovery related issues
To ensure that appropriate continuity and recovery mechanisms are put in place
to meet or exceed the agreed business continuity targets
To asses the impact of all changes on the IT Service Continuity Plans and IT
recovery plans
To ensure that proactive measures to improve the availability of services are
To negotiate and agree the necessary contracts with suppliers for the provision
of the necessary recovery capability to support all continuity plans in
conjunction with the Supplier Management process

ITSCM — Key concepts (1 of 2)

Service
Service
Design
Design
Service
Service
Strategy
ITIL

• ITSCM should be based on Business Continuity
– Appropriate protection and recovery measures
– Written recovery plans
• Lifecycle approach
– Initiation, Requirements & Strategy, Implementation, Operation
– Regular Business Impact Analysis (BIA), Risk Assessment and
Risk Management to ensure plans remain valid
– Regular testing of plans
• Negotiate with suppliers as necessary
• Assess changes for impact on ITSCM
ITSCM provides an invaluable role in supporting the Business Continuity Planning

process. In many organizations ITSCM is used to raise awareness of continuity and
recovery requirements and is often used to justify and implement a Business
Continuity Planning process and Business Continuity Plans.
The ITSCM should be driven by business risk as identified by Business Continuity
Planning and ensures that the recovery arrangements for IT services are aligned to
identify business impacts, risks and needs.
A lifecycle approach should be adopted to the setting up and operation of an ITSCM
process. The following figure shows the lifecycle of ITSCM from initiation through to
continual assurance that the protection provided by the plan is current and reflects all
changes to services and service levels.

ITSCM is a cyclic process through the lifecycle to ensure that once service continuity
and recovery plans have been developed they are kept aligned with Business
Continuity Plans (BCPs) and business priorities. The diagram also shows the role
played within the ITSCM process of BCM.
Lifecycle Key activities

Business Policy setting
Continuity Initiation Scope
Management Initiate a project
(BCM)
Business Impact Analysis

Requirements
Business Risk Assessment
Continuity and strategy
IT Service Continuity Strategy
Strategy
Develop IT Service continuity plans

Business
Continuity Develop IT plans, recovery plans
plans Implementation and procedures
Organization Planning
Testing strategy
Education, awareness and Training

On going Review and audit
Invocation Operation Testing
Change Management

Lifecycle of Service Continuity Management
Initiation and requirements stages are principally Business Continuity Management

(BCM) activities. ITSCM should only be involved in these stages to support the BCM
activities and to understand the relationship between the business processes and the
impacts caused upon them by loss of IT service.
As a result of these initial Business Impact Analysis (BIA) and risk assessment
activities BCM should produce a Business Continuity Strategy and the first real ITSCM
task is to produce an ITSCM strategy that underpins the BCM strategy and its needs.

ITSM — Key concepts (2 of 2)

Service
Service
Design
Design
Service
Service
Strategy
ITIL

• Common Recovery Options include
– Manual workarounds
– Reciprocal Arrangements
– Gradual Recovery (Cold Standby)
– Intermediate Recovery (Warm Standby)
– Fast Recovery (Hot Standby)
– Immediate Recovery
An organization’s ITSCM strategy is a balance between the cost of risk reduction

measures and recovery options to support the recovery of critical business processes
within agreed timescales.
The following is a list of the potential IT recovery options that need to be considered
when developing the strategy. The strategy is likely to include a combination of risk
response measures and a combination of the recovery options below.
Manual workarounds
It is possible for certain types of services that manual workarounds can be an
effective interim measure for a limited time frame of around 2 or 3 days until the IT
Service is resumed. For instance a Service Desk call logging service could survive for
a limited time using paper forms linked to a laptop computer with a spreadsheet.
Reciprocal arrangements
In the past reciprocal arrangements were typical contingency measures where
agreements were put in place with another organization using similar technology.
This is no longer effective or possible for most types of IT systems but can still be used
in special specific cases. Examples: setting up of an agreement to share high speed
printing facilities or off-site storage of backups and other critical information.

Gradual recovery (Cold Standby – target recovery normally in excess of 72

hours)
This option (sometimes referred to as ‘Cold Standby’) includes the provision of empty
accommodation fully equipped with power, environmental controls and local network
cabling Infrastructure, telecommunications connections, and available in a disaster
situation for an organization to install its own computer equipment. It does not
include the actual computing equipment so is not applicable for services requiring
speedy recovery as set up time is required before recovery of services can begin.
The accommodation may be provided commercially by a third party, for a fee, or
may be private, (established by the organization itself) and provided as either a fixed
or portable service. A portable facility is typically a prefabricated building provided
by a third party and located when needed at a predetermined site agreed with the
organization.
Intermediate recovery (Warm Standby - target recovery normally between

24 and 72 hours)
This option (sometimes referred to as ‘Warm Standby’) is selected by organizations
that need to recover IT facilities within a predetermined time to prevent impacts to the
business process. The predetermined time will have been agreed with the business
during the BIA. Most common is the use of commercial facilities, which are offered
by third party recovery organizations to a number of subscribers, spreading the cost
across those subscribers. One potentially major disadvantage is the security
implications of running IT services at a third party’s data centre. This must be taken
into account when planning to use this type of facility
Fast recovery (Hot Standby - target recovery normally within 24 hours)

This option (sometimes referred to as ‘Hot Standby’) provides for fast recovery and
restoration of services and is sometimes provided as an extension to the intermediate
recovery provided by a third party recovery provider. Where there is a need for a
fast restoration of a service, it is possible to ‘rent’ floor space at the recovery site and
install servers or systems with application systems and communications already
available and data mirrored from the operational servers. In the event of a system
failure, the customers can then recover and switch over to the backup facility with
little loss of service.

Immediate recovery
This option (also often referred to as ‘Hot Standby’, ‘mirroring’, ‘load balancing’ or
’split site’), provides for immediate restoration of services, with no loss of service. For
business critical services, organizations requiring continuous operation will provide
their own facilities within the organization but not on the same site as the normal
operations. Sufficient IT equipment will be “dual located” in either an owned or
hosted location to run the compete service from either location in the event of loss of
one facility, with no loss of service to the customer. The second site can then be
recovered whilst the service is provided from the single operable location.
This is an expensive option but may be justified for critical business processes or
VBFs where non-availability for a short period could result in a significant impact or
where it would not be appropriate to be running IT services on a third party’s
premises for security or other reasons. The facility needs to be located separately
and far enough away from the home site that it will not be affected by a disaster
affecting that location.
However, these mirrored servers and sites options, should be implemented in close
liaison with Availability Management as they support services with high levels of
availability.

ITSCM — Roles
Service
Service
Design
Design
Service
Service
Strategy
ITIL
ITSCM — Roles
• Service Continuity Manager
– Process Owner for ITSCM
– Responsible for producing, testing and maintaining service
continuity plans
– Part of overall Business Continuity Team
The Service Continuity Manager, as the ITSCM process owner, has responsibility for
ensuring that the aims of Service Continuity Management are met.
This includes such tasks and responsibilities as:
To implement and maintain the ITSCM process in accordance with the overall
requirements of the organization’s Business Continuity Management process
To represent the IT services function within the Business Continuity Management
process
To Perform Business Impact Analyses for all existing and all new services
Performing risk assessment and risk management to prevent disasters where cost
justifiable and where practical
Assessing potential service continuity issues and invoking the Service Continuity
Plan if necessary and managing the Service Continuity Plan while it is in
operation, including fail-over to a secondary location and restoration to the
primary location
Performing post mortem reviews of service continuity tests and invocations and
instigating corrective actions where required

Ensure that all IT service areas are prepared and able to respond to an
invocation of the continuity plans, while maintaining a comprehensive IT testing
schedule, including the testing of all continuity plans in line with business
requirements and after every major business change
Communicate and maintain awareness of ITSCM objectives within the business
areas supported and IT Service areas
Undertake regular reviews, at least annually, of the Continuity plans with the
business areas to ensure that they accurately reflect the business needs
Negotiate and manage contracts with providers of third party recovery services
Assessing changes for their impact on service continuity and Continuity Plans,
and attending CAB meetings when appropriate

Service Strategy
Service
Strategy
ITIL
Service Strategy
• Key concepts
– Utility and Warranty
– Value Creation
– Service Provider
– Delivery Model Options
– Service Model
• Processes
– Service Portfolio Management (SPM)
– Demand Management
– Financial Management

Utility and Warranty

Service
Strategy
ITIL
Utility and Warranty

• Utility and Warranty define services and work together to
create value for the customer
• Utility
– What does the service do?
– Functional requirements
– Features, inputs, outputs…
– “fit for purpose”
• Warranty
– How well does the service do it?
– Non-functional requirements
– Capacity, performance, availability…
– “fit for use”
From the customer’s perspective, value consists of two primary elements: Utility or
fitness for purpose and warranty or fitness for use.
Utility is derived from the attributes of the service that have a positive effect on the
performance of activities, objects, and tasks associated with desired outcomes.
Removal or relaxation of constraints on performance is also perceived as a positive
effect.
Warranty is derived from the positive effect being available when needed, in
sufficient capacity or magnitude, and dependably in terms of continuity and security.
Utility is what the customer gets, and warranty is how it is delivered.
Customers cannot benefit from something that is fit for purpose but not fit for use and
vice versa. It is useful to separate the logic of utility from the logic of warranty for the
purpose of design, development, and improvement. Considering all the separate
controllable inputs allows for a wider range of solutions to the problem of creating,
maintaining, and increasing value.

Value creation
Service
Strategy
ITIL
Value creation
Return on
assets
Service
Performance Utility
Performance of + average
customer assets
- Performance
variation
Warranty
There is skepticism about the value realized from services when there is uncertainty in
the service output. Costs are certain but utility may vary from one unit of output to
another. When the utility of a service is not backed up by warranty, customers worry
about possible losses due to poor service quality more than the possible gains from
receiving the promised utility. To allay such concerns and influence customer
perceptions of possible gains and losses, it is important that the value of a service is
fully described in terms of utility and warranty.
The utility effect of a service is explained as the increase in possible gains from the
performance of customer assets, leading to increase in the probability of achieving
outcomes.
Warranty of services is explained as the decrease in possible losses for the customer
from variation in performance. Customers feel more certain that every unit of demand
for service will be fulfilled with the same level of utility with little variation.
This approach can change customer perceptions of uncertainty in the promised
benefits of a service. Customers expect to see a strong link between the utilization of
a service and the positive effect on the performance of their own assets leading to
higher return on assets.

A mere graphic is however not sufficient to convince customers. They must be assured
of the actual mental mapping made by groups engaged in different parts of the
Service Lifecycle. Customers may also expect evidence that policies, procedures, and
guideline are in place to uncover all costs and risks associated with service delivery
and support. In the absence of such institutionalized practice, the promise of a
service can just as easily turn to peril during the course of carrying out the terms of
the contract or service agreement.

Service Provider
Service
Strategy
ITIL
Service Provider
An organization supplying services to one or more internal
customers or external customers
• Type 1
– Internal
– Embedded in the business unit it serves
• Type 2
– Shared
– Provide services to multiple business units
• Type 3
– External
– Provide services to many customers
It is necessary to distinguish between different types of service providers. While most

aspects of service management apply equally to all types of service providers, others
such as customers, contracts, competition, market spaces, revenue, and strategy take
on different meanings depending on the type. There are three archetypes of business
models service providers:
Type I - Internal Service Provider
Type II – Shared Services Provider
Type III –External Service Provider
Type I – Internal Service Provider

Type I providers are typically business functions embedded within the business units
they serve. The business units themselves may be part of a larger enterprise or parent
organization. Business functions such as finance, administration, logistics, human
resources, and IT, provide services required various parts of the business. They are
funded by overheads and are required to operate strictly within the mandates of the
business. Type I providers have the benefit of tight-coupling with their owner-
customers, avoiding certain costs and risks associated with conducting business with
external parties.

The primary objectives of Type I providers are to achieve functional excellence and
cost effectiveness for their business units. They specialize to serve a relatively narrow
set of business needs. Services can be highly customized and resources are
dedicated to provide relatively high service levels. The governance and
administration of business functions are relatively straightforward. The decision rights
are restricted in terms of strategies and operating models. The general managers of
business units make all key decisions such as the portfolio of services to offer, the
investments in capabilities and resources, and the metrics for measuring performance
and outcomes.
Type I providers operate within internal market spaces. Their growth is limited by the
growth of the business unit they belong to. Each business unit (BU) may have its own
Type I provider. The success of Type I providers is not measured in terms of revenues
or profits because they tend to operate on a cost-recovery basis with internal funding.
All costs are borne by the owning business unit or enterprise.
Corporate
(Corporate Business
Function)
Marketing Coatings Plastics Textiles

R&D Strategic planning
(BU) (BU) (BU)
Government Affairs
Human resources Human resources Human resources

Finance & admin Finance & admin Finance & admin
Customer care Customer care Customer care
IT IT IT

Type I Providers
Competition for Type I providers is from providers outside the business unit such as
corporate business functions, who wield advantages such as scale, scope, and
autonomy. In general, service providers serving more than one customer face much
lower risk of market failure. With multiple sources of demand, peak demand from
one source can be offset by low demand from another. There is duplication and
waste when Type I providers are replicated within the enterprise.
To leverage economy of scale and economy, Type I providers of similar
characteristics and are consolidated into a corporate business function. At this level
of aggregation Type I providers balance enterprise needs with those at the business
unit level. The trade-offs can be complex and require a significant amount of
attention and control by senior executives. As such, consolidated Type I providers are
more appropriate where classes of assets such as IT, R&D, marketing, or
manufacturing are at the core of the organization’s competitive advantage and
therefore need careful control.

Type II – Shared Services Provider

Functions such as finance, IT, human resources, and logistics are not always at the
core of an organization's competitive advantage. They hence 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). This model allows a
more devolved governing structure under which SSU can focus on serving business
units as direct customers. SSU can create, grow, and sustain an internal market for
their services and model themselves along the lines of service providers in the open
market. Like corporate business functions, they can leverage opportunities across the
enterprise and spread their costs and risks across a wider base. Unlike corporate
business functions, they have fewer protections under the banner of strategic value
and core competence. They are subject to comparisons with external service
providers whose business practices, operating models, and strategies they must
emulate and whose performance they should approximate if not exceed.
Performance gaps are justified through benefits received through services within its
domain of control.
Corporate
(Corporate Business
Function)
Coatings Plastics Textiles

(BU) (BU) (BU)
Business Services
(Shared Services Unit)
Human Resources
Service
catalogue
Finance &
Administration
Service
catalogue Customer Care
Service
catalogue
Logistics
Service
catalogue Information
Technology
Service
catalogue
BU: Business Unit
SSU: Shared Services Unit

Common Type II Providers

Customers of Type II are business units under a corporate parent, common

stakeholders, and an enterprise-level strategy. What may be sub-optimal for a
particular business unit may be justified by advantages reaped at the corporate level
for which the business unit may be compensated. Type II can offer lower prices
compared to external service providers by leveraging corporate advantage, internal
agreements and accounting policies. With the autonomy to function like a business
unit, Type II providers can make decisions outside the constraints of business unit
level policies. They can standardize their service offerings across business units and
use market-based pricing to influence demand patterns.
While Type II providers benefit from a relatively captive internal market for their
services, their customers may still evaluate them in comparison with external service
providers. This balance is crucial to the effectiveness of the shared services model. It
also means that poorly performing Type II providers face the threat of substitution.
This puts pressure on the leadership to adopt industry best practices, cultivate market
spaces, formulate business strategies, strive for operational effectiveness, and
develop distinctive capabilities. Industry leading shared services units have
successfully been spun-off by their parents as independent businesses competing in
the external market. They become a source of revenues from the initial charter of
simply providing a cost-advantage.
Type III – External Service Provider

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. Business strategies often require reductions in the asset base,
fixed costs, operational risks, or the redeployment of financial assets. Competitive
business environments often require customers to have flexible and lean structures. In
such cases it is better to buy services rather than own and operate the assets
necessary to execute certain business functions and processes. For such customers,
Type III is the best choice for a given set of services. The experience of such providers
is not limited to any one enterprise or market. The breadth and depth of such
experience is often the single-most distinctive source of value for customers. The
breadth comes from serving multiple types of customers or markets. The depth comes
from serving multiples of the same type.

From a certain perspective, Type III providers are operating under an extended large
scale shared services model. They assume a greater level of risk from their customers
compared to Type I and Type II. But their capabilities and resources are shared by
their customers - some of whom may be rivals. This means that rival customers have
access to the same bundle of assets, thereby diminishing any competitive advantage
those assets bestowed.
Security is always an issue in shared services environments. But when the
environment is shared with competitors, security becomes a larger concern. This is a
driver of additional costs for Type III providers. As a counter-balance, Type III
providers mitigate a type of risk inherent to Type I and II: Business functions and
shared service units are subject to the same system of risks as their business unit or
enterprise parent. This sets up a vicious cycle whereby risks faced by the business
units or the enterprise are transferred to the service units and then fed back with
amplification through the services utilized. Customers may reduce systemic risks by
transferring them to external service providers who spread those risks across a larger
value network.
Corporate
(Corporate Business
Function)
Coatings Plastics Textiles

(BU) (BU) (BU)
External
Providers
Alpha Co.
Service
catalogue
Beta Inc.
Service
catalogue
Service
catalogue
Gamma Ltd.
Service
catalogue
Delta Plc.
Service
catalogue

Type III Providers

Delivery Model options

Service
Strategy
ITIL
Delivery Model options

Delivery Strategy Description
Insourcing Utilizing internal organizational resources for all stages in the lifecycle
Outsourcing Utilizing the resources of an external organization or organizations
Co-sourcing The combination of Insourcing and Outsourcing to co-source key elements within the
lifecycle
Partnership or Multi- Formal arrangement between 2 or more organizations to work together. Focus on
sourcing strategic partnerships to leverage expertise or market opportunities
Business Process Formal arrangement between two organizations to relocate and manage an entire
Outsourcing (BPO) business function (for example payroll, call-centre) from a low-cost location
Application Service Formal agreement with an Application Service Provider (ASP) to provide shared
Provision computer based services over a network (sometimes called ‘on-demand’
software/applications)
Knowledge Process Provision of domain based processes and business expertise requiring advanced
Outsourcing (KPO) analytical and specialist skills from the outsourcer

Service Model
Service
Strategy
ITIL
Service Model
• Graphical representation of
the components that make up
a service
• Documents workflow and
dependencies
• Used to support design,
analysis and communication
Service Models codify the service strategy for a market space. They are blueprints by
service management process and functions to communicate and collaborate on value
creation. Service Models describe how service assets interact with customer assets
and create value for a given portfolio of contracts (see diagram on the next page).
Interaction means demand connects with the capacity to serve. Service agreements
specify the terms and conditions under which such interaction occurs with
commitments and expectations on each side. The outcomes define the value to be
created for the customer which itself rests on the utility provided to customers and the
warranty.

Market Service Determine/Influence

Space Portfolio
Customer Contract Customer

Portfolio Portfolio assets
Service Service
assets Models

Service models are shaped by market spaces
Service Models codify the structure and dynamics of services. The structure and
dynamics are influenced by factors of utility and warranty to be delivered to
customers. The structure and dynamics have consequences for Service Operations
which are evaluated by Service Transition.
Structure is defined in terms of particular service assets needed and the patterns in
which they are configured. Service models also describe the dynamics of value-
creation. Activities, flow of resources, coordination, and interactions describe the
dynamics. This includes the cooperation and communication between service users
and service agents. The dynamics of a service include patterns of business activity,
demand patterns, exceptions and variations.
The methods and tools of systems engineering and workflow management are useful
for developing the process maps, workflow diagrams, queuing models, and activity
patterns necessary for completeness of service models. Service Transition evaluates
detailed service models to ensure they are fit for purpose and fit for use before
entering Service Operation through the Service Catalog. It is necessary for service
models to be under change control because the utility and warranty of a service can
have undesired variation if there are changes to the service assets or their
configuration. The integrity of a service model depends on the integrity of the
structure.
Service models are useful for effectiveness in Continual Service Improvement.
Improvements can be made to the structure or the dynamics of a model. Service
Transition evaluates the options or paths for improvements and recommends solutions
that are cost-effective and low-risk. Service models continually evolve, based on
external feedback received from customers and internal feedback from service
management processes. CSI processes ensure the feedback to the strategy, design,
transition, and operation processes.

Main activities
Main activities
• Define the market
– Evaluate the services you could potentially offer, and who you may be
able to offer them to!
• Develop the offerings
– Continue to formulate the services you think it will be worthwhile
pursuing
– Utility and Warranty are considered at this stage
• Develop strategic assets
– Look for opportunities to exploit your services and capabilities (to
allow more services to more customers)
– Develop Service Management so that it becomes a strategic asset
• Prepare for execution
– Take all the necessary steps to ensure that we are ready to go ahead
and it is worthwhile doing so

Service Portfolio Management

Service
Strategy
ITIL
Service Portfolio Management

• Objectives
• Basic Concepts
• Activities
• Roles

Service Portfolio Management — Objectives

Service
Strategy
ITIL
Service Portfolio Management — Objectives

• Decide what services to offer
• Understand
– Why should a customer buy these services?
– Why should they buy these services from us?
• Provide direction to Service Design
– So they can manage and fully exploit the services into the future
A service portfolio describes a provider’s services in terms of business value. It

articulates business needs and the provider’s response to those needs. By definition,
business value terms correspond to marketing terms, providing a means for
comparing service competitiveness across alternative providers. By acting as the
basis of a decision framework, a service portfolio either clarifies or helps to clarify
the following strategic questions:
Why should a customer buy these services?
Why should they buy these services from us?
What are the pricing or chargeback models?
What are our strengths and weaknesses, priorities and risk?
How should our resources and capabilities be allocated?
Organizations embarking upon a service-orientation journey have a tendency to view
it as a series of tactical programs. Armed with a conceptual understanding of
services, organizations frequently rush to industrialize service outcomes. The impulse
is to launch initiatives in organizational change or process redesign. While these are
important fulfillment elements, there is an order worth noting.
While this order is not absolute it does serves two purposes. First, it warns against
missteps such as performing organizational design before knowing what services to
offer or performing a tool selection before optimizing processes. Second, it signals
the early need for a service portfolio, one of the most vital yet often missing
constructs for driving service strategies and managing service investments.
Service Portfolio Management — Basic concepts

Service Portfolio Management —
Service
Strategy
ITIL
Basic concepts
• Business Service
– A service that directly supports a business process
• IT Service
– A service that the business does not think of in business context
or semantics
• Business Service Management
– Considering service management in terms of business processes
and business value
Business Services and IT Services

Business processes should be considered in comprehensive terms – the endpoints of
a value chain. If a process improvement plan focused only on Accounts Payable (AP),
for example, it might improve that sub-process, but not improve the overall process,
Order-to-Cash (OTC). Worse, one might improve the sub-process at the expense of
the overall value chain. For example, if the AP improvements included a service that
produced higher quality reports, but took longer to produce, the delay may affect the
company’s ability to respond to changes in the marketplace.
A business process can be distributed across technologies and applications, span
geographies, have many users, and yet still reside in one place: the Data Centre. To
integrate business process, 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 began as an elegant top-
down business design frequently deteriorates into a disjointed and inflexible IT
solution, disconnected from the goals of the business.

An improved strategy for engaging at the business process layer is focusing on

modelled abstractions of business activities. These focal points, called business
services, represent business activities with varying degrees of granularity and
functionality. A business process, for example, may be represented as a single
business service or a collection of business services. A business service can represent
a composite application or a discrete application function. It may represent a discrete
transaction or a collection of supporting fulfillment elements. In all cases, it exists in
the domain of the business.
Business Service IT Service
Business
Process IT Application
Management Information
Management Information
People Logic Applications

People Workflow Applications
Knowledge Infrastructure
Knowledge Infrastructure
Utility Utility
Service Platform Service Platform

Availability Capacity Availability Capacity
Continuity Security Continuity Security
Warranty Warranty

Business Service and IT Service
A business service is defined by the business. If IT provides a service to the business,

but the business does not think of the service in any business context or semantics,
then it is an IT service. By considering services as a system for creating and capturing
value, regardless of sourcing or underpinnings, the line between IT services and
business services begins to blur. Instead, each can be thought of as different
perspectives across a spectrum. Again, the decision to adopt a business or IT
perspective depends on the context of the customer.

Business Service Management

IT priorities must be clearly aligned with other drivers of business value. In order for IT
to organize its activities around business objectives, the organization must link to
business processes and services - not just observe them. IT leadership must engage in
a meaningful dialog with line-of-business owners and communicate in terms of
desired outcomes.
The transition from managing infrastructures to managing services is marked by a
fundamental difference. While managing infrastructure requires a focus on
component operational availability, managing services is centered on customer and
business needs. Operational information about the infrastructure’s health is a critical
foundation but is not enough. IT organizations intuitively recognize the need to link
their activities with business objectives but frequently struggle in deciding how far to
go in exposing the linkages between business activities and IT execution.
ITIL
Business
Service
Management
IT Service Business Activity

Management
Value to Business
IT Systems
Management IT Activity
Infrastructure
and Application
Technology Activity
Resources
Value to IT
The IT Management Continuum

Organizations are increasingly less focused on IT infrastructure and applications than

on coupling applications internally and with business partners in the quest to
automate end-to-end business processes and deliver business services. The challenge
is to derive operational objectives from business services and to manage accordingly.
Business perspectives, however, often do not easily relate to IT infrastructure.
A strategy aimed at this challenge is Business Service Management (BSM). BSM
differs from previous strategic methods by offering a holistic top-down approach
aimed at aligning the IT infrastructure with the business.
“Business Service Management is the ongoing practice of governing, monitoring
and reporting on IT and the business services it impacts.”
BSM provides the means by which the service provider manages business services.
When the provider focuses its operations on business services it is better able to
align investments in infrastructure and operational activities with business objectives.
BSM sets forth a model for developing business-focused metrics; enabling adaptation
to future needs as driven by the business requirements.
The cornerstone to BSM is the ability to link service assets to their higher-level
business services. The links are based on causality instead of correlation. The view of
IT infrastructure shifts from a topological map to a dependency model. This model
identifies the asset-to-service linkages, allowing infrastructure events to be tied to
corresponding business outcomes.

Service Portfolio Management — Activities

Service
Strategy
ITIL
Service Portfolio Management — Activities

Service
Strategy
• Inventories
Define • Business Case
• Value proposition
Analyze • Prioritization
• Service Portfolio
Approve
• Authorization
• Communication
Charter • Resource allocation
If we think of SPM as a dynamic and ongoing process set, it should include the
following work methods:
Define: Inventory services, ensure business cases and validate portfolio data
Analyze: Maximize portfolio value, align and prioritize and balance supply and
demand
Approve: Finalize proposed portfolio, authorize services and resources
Charter: Communicate decisions, allocate resources and charter services

Service Portfolio Management — Roles

Service
Strategy
ITIL
Service Portfolio Management — Roles

• Product Manager
– Own and manage a set of related services
– Evaluate market opportunities and customer needs
– Create business cases
– Plan new service development programs
• Business Relationship Manager
– Identify and document customer needs
Product Manager is a key role within Service Portfolio Management (See following
figure). The role is responsible for managing services as a product over their entire
lifecycle from concept to retirement through design, transition, and operation. They
are instrumental in the development of Service Strategy and its execution through the
Service Lifecycle in a high-performing portfolio of services. Product Managers bring
coordination and focus to the organization around the Service Catalog of which they
maintain ownership. They work closely with Business Relationship Managers (BRM)
who bring coordination and focus to the Customer Portfolio.
Business Relationship Managers (BRMs) are responsible for gaining insight into the
customer's business and having good knowledge of customer outcomes. This is
essential to developing a strong business relationship with customers. They are
'customer focused' and manage opportunities through a Customer Portfolio. In many
organizations BRMs are known as Account Managers, Business Representatives and
Sales Managers.

Director of
Service Management
Perspective
Financial
Compliance
Management
People Audit
Assets
Positions
Business Service
Relationship Organization Sourcing
Portfolio
Management Development Management
Management
Contract Customer Service Service Component Sourcing

Portfolio Portfolio Functions Processes
Pipeline Catalogue Services Contracts
Plans and patterns
Continual Service
Service Design Service Transition Service Operation
Improvement

Product Managers have a key role under Service Portfolio Management

Product Managers are recognized as the subject matter experts on Lines of Service
(LOS) and the Service Catalog. They understand Service Models and their internal
structure and dynamics to be able to effectively drive changes and improvements.
They have a consolidated view of costs and risks across LOS just as BRM maintain a
similar view across customers and contracts.
Product Manager Business Representative
Lines of Sources of
service Service demand
Catalogue

Product Managers and Lines of Service (LOS)
Product Managers evaluate new market opportunities, operating models,

technologies, and the emerging needs of customers. They follow variety-based
positions and seek new sources of demand for items in the Service Catalog. They
negotiate internal agreements with BRMs who represent the underserved and un-
served needs of customers. When solutions are not found in the Catalog or Pipeline,
Product Managers and BRMs work together on making a business case for new
service development (NSD). They involve the Sourcing Management function when
there is a need to integrate third-party services and other service components for a
new or existing service. They hold a position within the Sourcing Organization. This
requires Product Managers to be adept in integration projects and in holding internal
and external suppliers accountable via formal agreements.
Product Managers provide leadership on the development of business cases, LOS
strategy, new service deployment and service lifecycle management schedules. They
perform financial analysis in collaboration with Service Design, Service Operation,
and Financial Management. This requires them to be good in negotiation, managing
conflict, and achieving consensus in order to achieve the organization’s strategic
positions and financial objectives.

They bring the marketing mindset necessary for an outcome-based definition of

services and effectiveness in value creation. They are able to manage conflict and
constraints. They balance change and innovation in the Service Pipeline with
stability, dependability, and financial performance of the Service Catalog. Product
Managers are able to effectively communicate LOS strategies to senior leadership,
develop partnerships with other groups within the organization and outside suppliers
in order to satisfy customer needs. They must be able to plan new service
development programs in response to new market opportunities, assess the impact of
new technologies, and guide the creation of innovative solutions. They market the
development and implementation of services that incorporate new technologies or
system development. This requires extensive cross-organization communications.

Demand Management
Service
Strategy
ITIL
Demand Management
• Objectives
• Basic concepts
• Roles

Demand Management— Objectives and business value

Demand Management—
Service
Strategy
ITIL
Objectives and business value

• Understand customer requirements for services and how these
vary over the business cycle
• Ensure the provision of appropriate levels of service
– By varying provision or influencing customer demand
• Ensure that the Warranty and Utility we offer matches the
customer needs
Business processes are the primary source of demand for services. Patterns of
business activity (PBA) influence the demand patterns seen by the service providers. It
is very important to study the customer’s business to identify, analyze, and codify
such patterns to provide sufficient basis for capacity management. Visualize the
customer’s business activity and plans in terms of the demand for supporting
services.

Demand Management— Basic concepts (1 of 3)

Service
Strategy
ITIL
• Core Service
– An IT Service that delivers outcomes desired by one or more
customers
• Supporting Service
– A service that enables or enhances a core service. For example
• A directory service or a backup service
Core services deliver the basic outcomes desired by the customer. They represent the
value that the customer wants and for which they are willing to pay. Core services
anchor the value-proposition for the customer and provide the basis for their
continued utilization and satisfaction. Supporting services either enable or enhance
the value-proposition. Enabling Services are Basic Factors and Enhancing Services
are Excitement Factors.
For example, the core service of a bank could be providing financial capital to small
and medium enterprises. Value is created for the bank’s customer only when the
bank can provide financial capital in a timely manner (after having evaluated all the
costs and risks of financing the borrower). The supporting services could include the
aid offered by loan officers in assessing working capital needs and collateral, the
application processing service, flexible disbursement of loan funds, and the facility of
a bank account into which the borrower can electronically transfer funds. The credit-
reporting service that the lending department utilizes for evaluating credit-reporting,
may be a core service provided to the loan officers by internal or external service
providers. It is not a supporting service to borrowers because they are not its users.
Supporting services for the loan officers could include a service desk that provides
technical support for the credit reporting service, e-mail, and voice-mail. These
services support the outcome of approving loans to credit-worthy customers in an
efficient and timely manner, compliant with all policies, procedures, and regulations.


Service
Strategy
ITIL
• Pattern of Business Activity (PBA)
– Workload profile of one or more business activities
– Varies over time
– Represents changing business demands
• User Profile
– Pattern of user demand for IT Services
– Each user profile includes one or more PBAs
Business activities drive demand for services. Customer assets such as People,
Processes, and Applications generate patterns of business activity (PBA). PBA define
dynamics of a business and include interactions with customers, suppliers, partners,
and other stakeholders. Services often directly support PBA. Since PBA generate
revenue, income, and costs they account for a large proportion of business outcomes.
Patterns of business activity (PBA) are identified, codified, and shared across process
for clarity and completeness of detail. One or more attributes such as frequency,
volume, location, and duration describe business activity. They are associated with
requirements such as security, privacy, and latency or tolerance for delays. This
profile of business activity can change over time with changes and improvements in
business processes, people, organization, applications, and infrastructure. PBA are
placed under change control.
Each PBA has to be substantially different from another PBA in order to be coded
with a unique reference. Codifying patterns helps multidimensional analysis using
criteria such as likeness and nearness. This provides efficiency and robustness in
developing a catalog of patterns with simplification and standardization to reduce
the number of patterns, make analysis easier, and avoid complicated solutions.

User profiles (UP) are based on roles and responsibilities within organizations for
People, and functions and operations for Processes and Applications. As suggested
earlier, business processes and applications are treated as users in many business
contexts. Many processes are not actively executed or control by staff or personnel.
Process automation allows for processes to consume services on their own. Processes
and applications can have user profiles. Whether they should is a matter of
judgment.
Each UP can be associated one or more PBA. This allows aggregations and relations
between diverse PBS connected by the interactions between their respective UPs.
User profiles (UP) are constructed using one ore more pre-defined PBA. They are also
under change control. UPs represent patterns that are persistent and correlated.
Pattern matching using PBA and UP ensure a systematic approach to understanding
and managing demand from customers. They also require customers to better
understand their own business activities and view them as consumers of services and
producers of demand. When they are used to communicate demand, service
providers have the information necessary to sort and serve the demand with
appropriately matched services, service levels, and service assets. This leads to
improved value for both customers and service providers by eliminating waste and
poor performance.
UP communicate information on the roles, responsibilities, interactions, schedules,
work environments, and social context of related users.


Service
Strategy
ITIL
• Service Package
– Detailed description of a service
– Includes a service level package and one or more core services
and supporting services.
• Service Level Package
– Defined level of utility and warranty for a particular service
package
– Designed to meet the needs of a PBA. For example
• Gold, Silver or Bronze service
Service Packages
The packing of core and supporting services is an essential aspect of market strategy.
Service providers should conduct a thorough analysis of the prevailing conditions in
their business environment, the needs of the customer segments or types they serve,
and the alternatives that are available to those customers. The decisions are strategic
because they hold a long-term view for maintaining value for customers even as
industry practices, norms, technologies, and regulations change.
The matter of bundling supporting services with core services has implications on
service operations and challenges for the design, transition, and improvement
processes. The costs and risks for supporting services may be overlooked during
initial stages of planning and development. Not only that, since supporting services
are often shared by several core services, there is often poor visibility and control
over the demand for supporting services and their consumption.
While service providers must focus on the effective delivery of value from core
services, they should also devote enough attention to the supporting services.
Satisfaction surveys show that user dissatisfaction is often with supporting services
even where the core service is being effectively delivered.

Some supporting services, such as help desk or technical support services typically
bundled with most service packages can also be offered on their own. This is an
important consideration in strategic planning and reviews. Service providers may
adopt different strategies for core services and supporting services. For example, they
can drive standardization and consolidation for supporting services to leverage
economies of scale and to reduce operating costs, while developing core service
packages specifically designed for particular customers. Or they may standardize on
the core service package and use supporting services to differentiate the offerings
across customers or market segments. These strategic decisions can have enormous
implications on the overall success of a service provider at the portfolio level. This is
particularly important for service providers who need to balance the differing needs
of typically not one but several enterprises or business units while trying to either
keep costs down across that portfolio to remain competitive.
Service Level Packages

Services packages come with one or more service level packages (SLP). Each SLP
provides a definite level of utility or warranty from the perspective of outcomes,
assets, and the PBA of customers. Each SLP is capable of fulfilling one or more
patterns of demand.
SLPs are associated with a set of service levels, pricing policies, and a core service
package (CSP). CSP are service packages that provide a platform of utility and
warranty shared by two or more SLP. Combinations of CSP and SLP are used to serve
customer segments with differentiated value. Common attributes of across SLP are
subsumed into the supporting CSP. This follows the principle of modularity to reduce
complexity, increase asset utilization across SLPs, and to reduce the overall cost of
services. CSP and SLP are loosely coupled to allow for local optimization while
maintaining efficiency over the entire supported Service Catalog. Improvements
made to CSP are automatically available to all SLP following the principle of
inheritance and encapsulation. Economy of scale and economy of scope are realized
at the CSP level and the savings are transmitted to the SLP and to customers as policy
permits.
Under certain contexts, CSP are infrastructure services offered by a specialized
service unit. This allows for greater economy, learning and growth from
specialization. This is similar to the arrangements between product marketing groups
and manufacturing.

Demand Management — Roles

Service
Strategy
ITIL
Demand Management — Roles

• Business Relationship Manager
– Document PBAs and user profiles
– Identify correct service level packages for their customers
– Identify unmet customer need
– Negotiate with Product Managers for creation of new services

Financial Management
Service
Strategy
ITIL
Financial Management
• Objectives
• Basic concepts
• Roles

Financial Management — Objectives and business value

Financial Management —
Service
Strategy
ITIL
Objectives and business value

• Financial visibility and accountability
• Financial compliance and control
• Enhanced decision making
• Operational control
• Value capture and creation
• Understand the value of IT Services
Operational visibility, insight and superior decision making are the core capabilities
brought to the enterprise through the rigorous application of Financial Management.
Just as business units accrue benefits through the analysis of product mix and margin
data, or customer profiles and product behavior, a similar utility of financial data
continues to increase the importance of Financial Management for IT and the
business as well.
Financial Management as a strategic tool is equally applicable to all three service
provider types. Internal service providers are increasingly asked to operate with the
same levels of financial visibility and accountability as their business unit and
external counterparts. Moreover, technology and innovation have become the core
revenue generating capabilities of many companies.
Financial Management provides the business and IT with the quantification, in
financial terms, of the value of IT services, the value of the assets underlying the
provisioning of those services, and the qualification of operational forecasting.
Talking about IT in terms of services is the crux of changing the perception of IT and
its value to the business. Therefore, a significant portion of Financial Management is
working in tandem with IT and the business to help identify, document and agree
upon the value of the services being received, and the enablement of service
demand modeling and management.

Financial Management — Basic concepts (1 of 2)

Service
Strategy
ITIL
• Service valuation
– Cost of providing the service
– Value to the customers receiving the service
• Service investment analysis
– Understand the total lifecycle value and costs of proposed new
services or projects
• Accounting
– Keeping track of what has been spent, assigned to appropriate
categories
Service Valuation
Service Valuation quantifies, in financial terms, the funding sought by the business
and IT for services delivered, based on the agreed value of those services. FM
calculates and assigns a monetary value to a service or service component so that
they may be disseminated across the enterprise once the business customer and IT
identify what services are actually desired.
The pricing of a service is the cost-to-value translation necessary to achieve clarity
and influence the demand and consumption of services. The activity involves
identifying the cost baseline for services and then quantifying the perceived value
added by a provider’s service assets in order to conclude a final service value. The
primary goal of Service Valuation is to produce a value for services that the business
perceives as fair, and fulfils the needs of the provider in terms of supporting it as an
ongoing concern. A secondary objective is the improved management of demand
and consumption behavior.

Service Investment Analysis

Financial management provides the shared analytical models and knowledge used
throughout an enterprise in order to assess the expected value and/or return of a
given initiative, solution, program or project in a standardized fashion. It sets the
thresholds that guide the organization in determining what level of analytical
sophistication is to be applied to various projects based on size, scope, resources,
cost and related parameters.
The objective of service investment analysis is to derive a value indication for the total
lifecycle of a service based on upon 1) the value received, and 2) costs incurred
during the lifecycle of the service.
Assumptions about the service are a key component of analyzing investments. The
granularity of assumptions used in investment analysis can have significant impact on
the outcome of the analysis. For example: A service obtained via an instantly self-
deployable packaged software solution residing on a single desktop and requiring
little user support will have a different investment profile than a service obtained
through custom development, global customer interaction and other resources that go
into creating, deploying and supporting an enterprise solution with multiple language
users. In Service Investment Analysis, it is best to lean toward the use of an exhaustive
inventory of assumptions rather than a limited set of high level inputs, in order to
generate a more realistic and accurate view of the investment being made.
Accounting
Accounting within Financial Management differs from traditional accounting in that
additional category and characteristics must be defined that enable the identification
and tracking of service-oriented expense or capital items.
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 provisioning and
consumption, and the generation of data that feeds directly into the planning
process. The functions and accounting characteristics that come into play are
discussed below:
Service recording — The assignment of a cost entry to the appropriate service.
Depending on how services are defined, and the granularity of the definitions,
there may be additional sub-service components.
Cost Types — These are higher level expenses categories such as hardware,
software, labor, administration, etc. These attributes assist with reporting and
analyzing demand and usage of services and their components in commonly
used financial terms.

Cost Classifications — There are also classifications within services that

designate the end purpose of the cost. These include classifications such as:
• Capital/Operational – This classification addresses different accounting
methodologies which are required by the business and regulatory agencies
• Direct/Indirect – This designation determines whether a cost will be
assigned directly or indirectly to a consumer or service
Direct Costs are charged directly to a service since it is the only
consumer of the expense.
Indirect or “shared” costs are allocated across multiple services since
each service may consume a portion of the expense.
• Fixed/Variable — This segregation of costs is based on contractual
commitments of time or price. The strategic issue around this classification is
that the business should seek to optimize fixed service costs and minimize
the variable in order to maximize predictability and stability.
• Cost Units — This is the identified unit of consumption that is accounted for
a particular service or service asset.
As accounting processes and practices mature toward a service orientation, more
evidence is created that substantiates the existence and performance of the IT
organization. The information available by translating cost account data into service
account information dramatically changes the dynamics and visibility of service
management, enabling a higher level of service strategy development and execution.

Financial Management — Basic concepts (2 of 2)

Service
Strategy
ITIL
• Business Case
– A decision support and planning tool that predicts outcomes of
a proposed action
– Used to justify investments
• Business Impact Analysis
– Understanding the financial cost of service outages
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.
Business Case Structure

A. Introduction
Presents the business objectives addressed by the service
B. Methods and Assumptions
Defines the boundaries of the business case, such as time period, whose costs
and whose benefits.
C. Business Impacts
The financial and non-financial business case results.
D. Risks and Contingencies
The probability that alternative results will emerge.
E. Recommendations
Specific actions recommended.

Business Impact Analysis

A BIA seeks to identify a company’s most critical business services through analysis
of outage severity translated into a financial value, coupled with operational risk.
This information can help shape and enhance operational performance by enabling
better decision making regarding prioritization of incident handling, problem
management focus, change and release management operations, project priority,
and so on. It is a beneficial tool for identifying the cost of service outage to a
company, and the relative worth of a service. These two concepts are not identical.
The cost of service outage is a financial value placed on a specific service, and is
meant to reflect the value of lost productivity and revenue over a specific period of
time. The worth of a service relative to other services in a portfolio may not result
exclusively from financial characteristics. Service Value, as discussed earlier, is
derived from characteristics that may go beyond Financial Management, and
represent aspects such as the ability to complete work or communicate with clients,
that may not be directly related to revenue generation. Both of these elements can be
identified to a very adequate degree by the use of a BIA.

Financial Management — Roles

Service
Strategy
ITIL
Financial Management — Roles

• All managers have some financial responsibility
• Senior IT Management own budgets and are ultimately
responsible for decisions
• Many organizations appoint a financial controller to oversee
day-to-day finances
• Accounting department provides governance framework and
support

Service Management
Technology and Architecture
Module 5

Service Management Technology and Architecture

Service Management
Technology and Architecture
• Two types of architecture and technology
– To implement and deliver the IT Services
– To manage the lifecycle of the IT Services
• This module is about architecture and technology to manage
the IT Services

Scope
Scope
• Service Design Tools
• Service Management Tools
• Event Management Tools
• Knowledge Management
Tools
– Configuration Management
System
• Tool selection

Service Design tools
Service Design tools

Scope
• Hardware, software, environment, processes, data…
Benefits
• Speed up the design process
• Ensure standards and rules are followed
• Prototyping, simulation and “what if”
• Validate designs before implementation
There are many tools and techniques that can be used to assist with the design of
services and their associated components.
These tools and techniques enable:
Hardware design
Software design
Environmental design
Process design
Data design
The tools and techniques are many and varied, including both proprietary and non-
proprietary and are useful in:
Speeding up the design process
Ensuring that standards and conventions are followed
Offering prototyping, modeling and simulation facilities
Enabling “What if?” scenarios to be examined
Enable interfaces and dependencies to checked and correlated
Validating designs before they are developed and implemented to ensure that
they satisfy and fulfill their intended requirements

Developing service designs can be simplified by the use of tools that provide
graphical views of the service and its constituent components, from the business
processes, through the service and SLA to the infrastructure, environment, data and
applications, processes, OLAs, teams, contracts and suppliers.

Service Management tools — Scope
Service Management tools — Scope

• Typically includes Incident, Problem, Change
• Often includes Configuration Management
• Often includes Workflow Management
• May be integrated with Service Knowledge Management
system
• May be a single integrated toolset or a set of distinct tools
with data exchange
An integrated IT Service Management technology or toolset as some suppliers sell

their technology as ‘modules’ i.e. HelpDesk module (for the Service Desk function,
Incident, Problem, Configuration Management processes), Change module (for the
Change Management process, etc., is needed that includes the following core
functionality:
Self Help
Many organizations find it beneficial to offer ‘Self Help’ capabilities to their users.
The technology should therefore support this capability with some form of web front-
end allowing web pages to be defined offering a menu-driven range of self help and
service requests –with a direct interface into the back end process handling software.
Workflow or Process Engine

A workflow or process control engine is needed to allow the pre-definition and
control of defined processes such as an incident lifecycle, request fulfillment lifecycle,
problem lifecycle, change model etc.
This should allow responsibilities, activities, timescales, escalation paths and alerting
to be pre-defined and then automatically managed.

Integrated Configuration Management System/Service Knowledge Management

System
The tool should have an integrated CMS/SKMS to allow the organization’s IT
infrastructure assets, components, services and any ancillary CIs (such as contracts,
locations, licenses, suppliers etc – anything that the IT organization wishes to control)
to be held, together with all relevant attributes, in a centralized location – and to
allow relationships between each to be stored and maintained – and linked to
Incident, Problem, Known Error and Change records as appropriate.
Discovery/Deployment/Licensing Technology
In order to populate or verify the CMS data and to assist in License Management,
discovery or automated audit tools will be required. Such tools should be capable of
being run from any location on the network and allow interrogation and recovery of
information relating to all components that make up, or are connected, to the IT
Infrastructure.
Remote Control
It is often helpful for the Service Desk analysts and other support groups to be able to
take control of the user’s desk-top (under properly controlled security conditions) so
as to allow them to conduct investigations or correct settings etc. Facilities to allow
this level of remote control will be needed.
Diagnostic Utilities
It will be extremely useful for Service Desk and other support groups if the technology
incorporated the capability to create and use diagnostic scripts and other diagnostic
utilities (such as, for example, case-based reasoning tools) to assist with earlier
diagnosis of incidents. Ideally these should be ‘context sensitive’ and presentation of
the scripts is automated so far as possible.
Reporting
There is no use storing data unless it can be easily retrieved and used to meet the
organizations purposes. The technology should therefore incorporate good reporting
capabilities, as well as to allow standard interfaces which can be used to input data
to industry-standard reporting packages, dashboards etc. Ideally instant on screen as
well as printed reporting can be provided through the use of context-sensitive ‘top
ten’ reports.

Dashboards
Dashboard type technology is useful to allow ‘see at a glance’ visibility of overall IT
service performance and availability levels. Such displays can be included in
management level reports to users and customers – but can also give real-time
information for inclusion in IT web pages to give dynamic reporting – and can be
used for support and investigation purposes. Capabilities to support customized
views of information to meet specific levels of interest can be particularly useful.
Integration with Business Service Management

There is a trend within the IT industry to try and bring together business related IT
with the processes and disciplines of IT Service Management – some call this
Business Service Management. To facilitate this, business applications and tools need
to be interfaced with ITSM support tools to give the required functionality. This can
be illustrated by this example:
An Eastern European telecoms company was able to interface its telephone cell-net
monitoring and billing system to its Event Management, Incident Management and
Configuration Management Processes. In this way it was able to detect any unusual
usage/billing patterns and interpret these such that it could identify, with a high
degree of certainly, that a telephone had been stolen and was being used to make
illicit calls. It was able to raise Events for such patterns and automate actions to
suspend usage of the mobile phone devices and, in parallel, identify the exact
location of the illicit user (using GPRS technology) and raise Incidents so that the
Police had the capability of finding the suspected thief and recovering the device.
More advanced tools integration capabilities are needed to allow greater
exploitation of this sort of business & IT integration.

Service Management tools — Benefits
Service Management tools — Benefits

• Reduced time and effort to manage incidents, problems and
changes
• Enable high volumes to be managed
• Provide historical reporting and dashboards
• Assists integration of service management processes. For
example
– Linking incident to change, change to problem
Here is a list of some benefits of using a Service Management tool:

An Integrated ITSM technology allows automated relationships to be made and
maintained between incidents, service requests, problems, known errors and all
other configuration items, reducing time and efforts to manage them.
By using a Workflow or Process Engine available in the tool, this should allow
responsibilities, activities, timescales, escalation paths and alerting to be pre-
defined and then automatically managed, ensuring standards and rules are
followed
Enable high volumes to be managed
All calls, incidents, etc., will be centrally manage, allowing for different views,
for example, “Outstanding Calls”, “Incident with High Priority – last week” etc.,
providing either historical reporting and/or dashboards

Automation processes
Automating processes
• Automation of service processes helps
– Improve quality
– Reduce costs and risks
– Reduce variationÖincrease warranty
• To get the most benefit
– Simplify processes before automating them
– Clarify activities, information needs, interactions
– In self-service situations, reduce the contact users have with
underlying systems and processes
– Do not be in a hurry to automate tasks and interactions that are
neither simple nor routine

Event Management tools — Scope
Event Management tools — Scope

• Services, Applications,
Software, Hardware,
Environment
• Active and passive monitoring
• Management consoles
• Integration with Service
Management tools
• Dashboards and reporting
The Event Management tool should cover several layers of individual components
such as Hardware (routers, switches, servers, desktops, printers, etc.), Software
(operational system, applications, etc.) as well as correlating the individual
components with the Service supported by these components. The environment where
the Services and its components are hosted/delivered should also be monitored.
Active versus Passive Monitoring
Active monitoring refers to the ongoing ‘interrogation’ of a device or system to
determine its status. This type of monitoring can be resource intensive and is
usually reserved to proactively monitor the availability of critical devices or
systems; or as a diagnostic step when attempting to resolve an Incident or
diagnose a Problem.
Passive monitoring is more common and refers to generating and transmitting
events to a ‘listening device’ or monitoring agent. Passive monitoring depends
on successful definition of events and instrumentation of the system being
monitored.

Management consoles
Observation and monitoring of the IT Infrastructure from a centralized console –
to which all system events are routed. Historically this involved the monitoring of
the master operations console of one or more mainframes – but these days is
more likely to involve monitoring of a server farm(s), storage devices, network
components, applications, databases – or any other Configuration Items (CIs),
including and remaining mainframe(s) – from a single location, known as the
Operations Bridge.
Integration with Service Management tools
An Event Management tool might not be from the same vendor as the Service
Management tool, but it is paramount that some level of integration – the more
automated, the better – exists between them.
Dashboards and reporting
Good reporting functionality to allow feed-back into design and transition
phases as well a meaningful management information and business user
‘dashboard’.

Event Management tools — Benefits
Event Management tools — Benefits

• Faster response to incidents
• More data available at early stages of incident
• Prevent incidents from being missed
• Proactively notify users of incidents
• Ensure current status of services and infrastructure is always
known
Benefits
Faster response to incidents – If the event is filtered as an Incident, it can
generate an Incident record so IT can act upon the failure and maybe correct it
even before Users know what happened.
More data available at early stages of incident – let’s suppose Users complain
of a “slow network”; an Event monitoring tool can show the behavior of the
network, the current and historical performance of servers, to help understand
what can be done to restore Services as quickly as possible.
Prevent incidents from being missed – if no monitoring is in place, IT relies
exclusively on its ability to manually check if Services are functioning and on the
Users calling the Service Desk.
Proactively notify users of incidents – it would be a very good customer
experience to let them know that an application is in some kind of error, so
Users can plan ahead their work and avoid using that application but still being
productive.
Ensure standards and rules are followed – creating workflows to follow an
organization standard, or an escalation path, or even responding to an Event
and trying to correct a possible failure is a common feature in many tools.
Ensure current status of services and infrastructure is always known.

Knowledge Management tools — Scope
Knowledge Management tools — Scope

• Documents, Records and Content
• Capture, storage, analysis, searching, sharing, presenting,
reviewing of knowledge and information
• All processes and services
• All stages of the Service Lifecycle
• In reality the knowledge management system is likely to have
a much narrower scope than this ideal
Knowledge management tools address an organization’s need for management for

processing information and promulgating knowledge. Knowledge management tools
address the requirements of maintaining records and documents electronically.
Records are distinguished from documents by the fact that they function as evidence
of activities, rather than evidence of intentions. Examples of documents include policy
statements, plans, procedures, service level agreements and contracts.
Document Management
Document Management defines the set of capabilities to support the storage,
protection, archiving, classification and retirement of documents and information.
Records Management
Records Management defines the set of capabilities to support the storage,
protection, archiving, classification and retirement of records.

Content Management
Content Management is the capability that manages the storage, maintenance and
retrieval of documents and information of a system or website. The result is often a
knowledge asset represented in written words, figures, graphics, and other forms of
knowledge presentation. Examples of knowledge services which directly support
content management are:
Web publishing tools
Web conferencing, wikis, blogs etc
Word processing
Data and financial analysis
Presentation tools
Flow-charting
Content management systems (codify, organize, version control, document
architectures)
Publication and distribution
Knowledge management tools should capture, store, analyze, search, share, present
and review knowledge and information about all processes and services, in all
stages of the Service Lifecycle. In reality the knowledge management system is likely
to have a much narrower scope than this ideal, due to its complex nature.

Knowledge Management tools — Benefits
Knowledge Management tools — Benefits

• Reduces time and effort for many activities
• Enables organizations to learn
• Enables senior personnel to contribute to improved
effectiveness of others
• Improves integration of processes across the service lifecycle
Benefits
Reduces time and effort for many activities – Take just as one example the time it
would be required to assess the impact and resources needed to implement a
change if no Configuration Management System is in place, and all
relationships between CI’s would need to be gathered and understood before a
decision is made.
Enables organizations to learn - Knowledge puts information into an “ease of
use” form, which can facilitate decision making. For example, 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.
Enables senior personnel to contribute to improved effectiveness of others - The
purpose of Knowledge Management tools is to ensure that the right information
is delivered to the appropriate place or person at the right time to enable
informed decision; without a tool it would take too much time and effort to find
the required information.

Improves integration of processes across the service lifecycle – All knowledge

capture and recorded during all stages of the Service Lifecycle would be very
beneficial to connect the analysis and decisions in each stage, especially for
Continual Services Improvement objectives. For example, looking at the lessons
learned during Service Operation, I can improve the Service Design; knowledge
management tools are the “memory” of a Service.

Configuration Management System — Scope

Configuration Management System — Scope
May be part of the Service Knowledge Management System
• All Configuration Items
• Attributes, relationships and
status
• Historical information
• Integration with incident,
problem and change
management data
The figure below is a very simplified illustration of the relationship of the three levels
of a Service Knowledge Management System, with data being gathered within the
CMDB, and feeding through the CMS into the SKMS and supporting the informed
decision making process.
Service Knowledge
Decisions
Management System
Databases

Relationship of CMDB, CMS and the SKMS

Many organizations have some form of Configuration Management in operation, but

it is often paper-based. For large and complex infrastructures, Configuration
Management will operate more effectively when supported by a software tool that is
capable of maintaining a CMS.
The CMS contains details about the attributes and the history of each CI and details
of the important relationships between CIs. Ideally, any CMDB should be linked to
the DML. Often, several tools need to be integrated to provide the fully automated
solution across platforms.
The Configuration Management system should prevent Changes from being made to
an IT infrastructure without valid authorization via Change Management. The
authorization record should automatically ‘drive’ the Change. As far as possible, all
Changes should be recorded on the CMS at least by the time that the Change is
implemented. The status (for example, ‘live’, ‘archive’, etc) of each CI affected by a
Change should be updated automatically if possible. Example ways in which this
automatic recording of Changes could be implemented include automatic updating
of the CMS when software is moved between libraries (for example, from
‘acceptance test’ to ‘live’, or from ‘live’ to an ‘archive’ library), when the service
catalog is changed, and when a Release is distributed.
The Configuration Management system should, in addition, provide:
Sufficient security controls to limit access on a need-to-know basis
Support for CIs of varying complexity, for example, entire systems, releases,
single hardware items, software modules hierarchic and networked relationships
between CIs; by holding information on the relationships between CIs,
Configuration Management tools facilitate the impact assessment of RFCs
Easy addition of new CIs and deletion of old CIs
Automatic validation of input data (for example, are all CI names unique?)
Automatic determination of all relationships that can be automatically
established, when new CIs are added
Support for CIs with different model numbers, version numbers, and copy
numbers
Automatic identification of other affected CIs when any CI is the subject of an
Incident

Configuration Management System — Benefits
Configuration Management System — Benefits

• Provides information about configuration items when and
where it is needed
• Helps to prevent out-of-date information being used
• Improves efficiency and effectiveness of all service
management processes
• Assists in the integration of service management processes
Benefits
Provides information about configuration items when and where it is needed –
This can be used, for example, during Problem Management to understand
trends on incidents in high priority configuration items
Helps to prevent out-of-date information being used — many tools can perform
automatic discovery scans, not only helping in gather up to date information but
also unveiling unauthorized changes
Improves efficiency and effectiveness of all service management processes
Assists in the integration of service management processes

Tool selection
Tool selection
• Create a Statement of Requirements
• Use MoSCoW analysis to define features
– Must, Should, Could, Won’t (but Should in the future)
• Consider vendor and tool credibility
• Visit reference sites
• Assess training needs
• Consider integration with environment
Consideration must be given to the exact requirements for the tool.

What are the mandatory requirements and what are the desired requirements?
Generally the tool should support the processes not the other way round so minimize
modification of the processes to fit the tool.
Where possible it is better to purchase a fully integrated tool (although not at the
expense of efficiency and effectiveness) to underpin many (if not all) Service
Management processes. If this is not possible, consideration must be given to the
interfaces between the various tools.
It is essential to have Statement of Requirements (SoR) for use during the selection
process; this statement can be used as a ‘tick list’.

The tool requirements should be separated be categorized using the MoSCoW

analysis:
M - MUST have this. A key requirement without which the tool has no value.
S - SHOULD have this if at all possible. An important requirement that must be
addressed, but, the tool would still have value without them.
C - COULD have this if it does not affect anything else. A requirement that would
be beneficial to include if it does not cost too much or take too long to deliver,
but it is not central to the tool.
W - WON'T have this time but WOULD like in the future. A requirement that
would be beneficial to include if it does not cost too much or take too long to
deliver, but it is not central to the tool.
Remember the considerations about the supplier’s credibility, and carry out a formal
evaluation of the products under consideration. How many years ahead do you
expect the ‘life’ of the vendor tool would be, or even the vendor itself? Ask for
references, visit others customers’ sites.
Assess the training needs of the organization and evaluate the capability of the
supplier to provide the appropriate training. Also the ongoing training & tool update
(upgrades & changes in user requirements) will need to be assessed to ascertain the
support and training costs. In particular, consider training costs, training location,
time required, how soon after training the tool will be in use and during the
implementation project ensure that sufficient training is provided – think about how
the new tool will impact both IT and Customer.
Consider integration with environment, i.e., what other tools the organization already
have, how well it will integrate with them.

ITIL Qualification Scheme
Module 6

ITIL v3 Qualification Scheme
ITIL Qualification Structure
Please note that the documented credits on the above diagram may be subject to change pending the further
development and release of a fully signed off v3 qualifications scheme by the Qualifications Board.
1
The new ITIL qualifications scheme recognizes the value of existing v2 qualifications
and introduces a system that enables an individual to gain credits for ITIL v2 and v3
courses. Once candidates have accumulated a sufficient number of credits they can
be awarded the ITIL Diploma in IT Service Management.
There are four levels within the new scheme namely: Foundation level, two
Intermediate levels, and Advanced level, which is currently under development. To
achieve a diploma, candidates must achieve 22 credits, two of which can be gained
at Foundation level.
The Foundation level focuses on knowledge and comprehension to provide a good
grounding in the key concepts, terminology and processes of ITIL v3. At this level, the
qualification remains very similar to the ITIL v2 Foundation qualification.
In the new intermediate level, there are two streams: a lifecycle stream and a
capability stream. The lifecycle stream is built around the five core OGC books:
Service Strategy, Service Design, Service Transition, Service Operation, and
Continual Service Improvement.
1
Extract from APMG Press release – 5th June 2007 – these credits could change, subject to
Qualifications Board decisions
ITIL Qualification Scheme
The intermediate capability stream is built around four clusters: service portfolio &
relationship management; service design & optimization; service monitoring &
control; and service operation & support.
Both intermediate streams assess an individual’s comprehension and application of
the concepts of ITIL v3.
Candidates are able to take units from either of the intermediate streams. These units
give them credits towards a diploma. There is a course – Managing across the
Lifecycle - that brings together the full essence of a lifecycle approach to service
management.
Once someone has gained the requisite number of 22 credits through their
education at foundation and intermediate level they will be awarded the ITIL v3
Diploma. No further examination or course is required to gain the diploma.
The Advanced Level Diploma will assess an individual’s ability to apply and analyze
the ITIL v3 concepts in new areas. This higher Diploma has not been developed at
this stage.

Relationship between v2 and v3
ITIL Bridging Qualifications
Please note that the documented credits on the above diagram may be subject to change pending the further
development and release of a fully signed off v3 qualifications scheme by the Qualifications Board.
2
Individuals with existing ITIL v2 Qualifications can use those qualifications as credits
towards the diploma.
Any ITIL v2 Manager who wishes to gain the v3 Diploma can take a bridging course
and pass an examination. The three day course covers the new concepts within ITIL
v3 and fully integrates the benefits of the lifecycle approach.
There is a also a one day bridging course at foundation which covers the differences
between v2 and v3 and allows someone to take an exam to demonstrate their
understanding of the ITIL v3 approach.
ITIL v 2 Practitioner qualifications count towards the ITIL Diploma in Service
Management. Depending on whether an individual holds a single topic certificate or
a clustered certificate the credits will vary.
2
Extract from APMG Press release – 5th June 2007 – these credits could change, subject to
Qualifications Board decisions
Documentation
Module 7
Contents
The ITIL® Foundation Certificate in IT Service Management – Syllabus
Course satisfaction survey


The ITIL® Foundation Certificate in IT Service Management - Syllabus
Document Control Information

Document Details
Document Name: ITIL® Foundation Certificate_v.3.0.doc
Purpose of Document: Detailed syllabus for those wishing to study the

ITIL® Foundation Certificate in IT Service
Management
Document Version Number: 3.0
Document Status: Live
Document Owner: V3 ITIL® Chief Examiner
Prepared by: Christian Feldbech Nissen

Katsushi Yaginuma
Rosemary Gurney
Signe Marie Hernes
Date of first draft: 20th April 2007
Date Approved: 21st May 2007
Approved by: ITIL® Qualifications Board
Next Scheduled review date: 1st January 2008
Version History
Version Date Change / Reasons for change / Comments:

Number: Approved:
3.0 21st May 2007 Draft syllabus set to live status by the Qualification
Board
Distribution List
Version Name Title / Company
3.0 Examination APM Group (AMPG)
Institute Information Systems Examination Institute (ISEB)
Examination Institute for Information Science (EXIN)
information
The ITIL® Foundation Certificate Syllabus

Version 3.0 (Status – Live) Document owner – Chief Examiner
© The APM Group Limited 2007
Professional Qualifications for
ITIL® PRACTICES FOR SERVICE MANAGEMENT
The ITIL® Foundation Certificate

in IT Service Management
SYLLABUS
OGC’s Official Accreditor

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered
in the U.S. Patent and Trademark Office.
The Best Practice logo ™ is a Trade Mark of the Office of Government Commerce.

Version 3.0 (Status – Live) Page 1 of 9 Document owner – Chief Examiner
THE ITIL® FOUNDATION CERTIFICATE IN IT SEVICE
MANAGEMENT
The purpose of the ITIL® Foundation certificate in IT Service Management is to certify that the
candidate has gained knowledge of the ITIL® terminology, structure and basic concepts and has
comprehended the core principles of ITIL® practices for Service Management.
The ITIL® Foundation certificate in IT Service Management is not intended to enable the holders
of the certificate to apply the ITIL® practices for Service Management without further guidance.
Candidates can expect to gain competencies in the following upon successful completion of the
education and examination components related to this certification.
• Service Management as a practice (Comprehension)

• Service Lifecycle (Comprehension)
• Key Principles and Models (Comprehension)
• Generic Concepts (Awareness)
• Selected Processes (Awareness)
• Selected Roles (Awareness)
• Selected Functions (Awareness)
• Technology and Architecture (Awareness)
• ITIL® Qualification scheme (Awareness)
Target Group
The target group of the ITIL® Foundation certificate in IT Service Management is drawn from:
• Individuals who require a basic understanding of the ITIL® framework and how it may be
used to enhance the quality of IT service management within an organisation.
• IT professionals that are working within an organisation that has adopted and adapted
ITIL® who need to be informed about and thereafter contribute to an ongoing service
improvement programme.
This may include but is not limited to, IT professionals, business managers and business process
owners.

Syllabus
The syllabus will guide the design, development and use of training materials as well as training
aimed at raising individual’s understanding of, and competence in, IT Service Management as
described in the ITIL® Service Strategy, ITIL® Service Design, ITIL® Service Transition, ITIL®
Service Operation, ITIL® Continual Service Improvement, ITIL® Introduction and ITIL® Glossary
publications. The syllabus has been designed with ease of reference, extensibility and ease of
maintenance in mind.
Candidates for the ITIL® Foundation certificate in IT Service Management have to complete all
units and successfully pass the corresponding examination to achieve certification.
Training providers are free to structure and organize their training in the way they find most
appropriate, provided the units below are sufficiently covered. It is strongly recommended that
training providers do not structure their courses by simply following the order of the training units
as described in this document. It has been designed to be flexible so that training providers can add
value as appropriate.
The units cover the topics listed. The terms emphasized in italics are defined in the ITIL® Glossary.
Unit Content
ITILFND01 Service Management as a practice
The purpose of this unit is to help the candidate to define Service and to
comprehend and explain the concept of Service Management as a practice.
Specifically, candidates must be able to:

01-1. Describe the concept of Good Practice (SS, SD, ST, SO, CSI 1.2.2)
01-2. Define and explain the concept of a Service (SS, SD, ST, SO, CSI 2.2.1)
01-3. Define and explain the concept of Service Management (SS, SD, ST, SO,
CSI 2.1)
01-4. Define and distinguish between Functions, Roles and Processes (SS 2.3,
2.6.1, 2.6.2, SD 2.3, SD 3.6.4, ST 2.3, SO 2.3, 3.1, CSI 2.3)
01-5. Explain the process model (SD 3.6.4)
01-6. List the characteristics of processes (Measurable, Specific results,
Customers, and Responds to a specific event) (SS 2.6.2, SD, ST, SO, CSI
2.3.2)
The recommended study period for this unit is minimum 1 hour.
ITILFND02 The Service Lifecycle
The purpose of this unit is to help the candidate to understand the Service Lifecycle
and explain the objectives and business value for each phase in the lifecycle.

02-1. Briefly explain the Service Lifecycle (SS 1.2.3, 2.5.1, SD 1.2.3, ST 1.2.3,
SO 1.2.3, CSI 1.2.3)
02-2. Describe the structure, scope, components and interfaces of the ITIL
Library (SS, SD, ST, SO 1.2.3, 2.4.2, CSI 1.2.3, 2.4.3)
02-3. Account for the main goals and objectives of Service Strategy (SS 1.3)

Unit Content
02-4. Account for the main goals and objectives of Service Design (SD 2.4.1, SD
3.1)
02-5. Briefly explain what value Service Design provides to the business (SD
2.4.3)
02-6. Account for the main goals and objectives of Service Transition (ST 2.4.1)
02-7. Briefly explain what value Service Transition provides to the business (ST
2.4.3)
02-8. Account for the main goals and objectives of Service Operations (SO 2.4.1)
02-9. Briefly explain what value Service Operation provides to the business (SO
2.4.3)
02-10. Account for the main goals and objectives of Continual Service Improvement
(CSI 2.4.1, 2.4.2)
02-11. Briefly explain what value Continual Service Improvement provides to the
business (CSI 2.4.5)
The recommended study period for this unit is minimum 1 hour and 30 minutes.
ITILFND03 Generic concepts and definitions
The purpose of this unit is to help the candidate to define some of the key
terminology and explain the key concepts of Service Management.
Specifically, candidates must be able to define and explain the following key
concepts:
03-1. Utility and Warranty (SS 2.2.2, 3.1.3, ST 3.1.2)
03-2. Resources and Capabilities (SS 3.2.1)
03-3. Service Portfolio (SS 4.2.3, SD 3.6.2)
03-4. Service Catalogue (Business Service Catalogue and Technical Service
Catalogue) (SS 4.2.3.1, SD 3.6.2, 4.1.4)
03-5. The role of IT Governance across the Service Lifecycle (CSI 3.10)
03-6. Business Case (SS 5.2.1, CSI 4.4.1)
03-7. Risk (SS 9.5.1, CSI 5.6.3.2)
03-8. Service Model (SS 7.2.1, SD 3.3, ST 4.5.4.1)
03-9. Service Provider (SD 4.2.4)
03-10. Supplier (SD 4.2.4, 4.7.2)
03-11. Service Level Agreement (SLA) (SD 4.2.4, 4.2.5.1)
03-12. Operational Level Agreement (OLA) (SD 4.2.4)
03-13. Contract (SD 4.7.5.1)
03-14. Service Design Package (SD 3.6.1)
03-15. Availability (SD 4.4.4)
03-16. Service Knowledge Management System (SKMS) (ST 4.7.4.2, SO 4.4.7.2)
03-17. Configuration Item (CI) (ST 4.3.4.2)
03-18. Configuration Management System (ST 4.3.4.3, SO 4.4.7.1)
03-19. Definitive Media Library (DML) (ST 4.3.4.3)
03-20. Service Change (ST 4.2.2)
03-21. Change types (Normal, Standard and Emergency) (ST 4.2.4.3, 4.2.4.4,
4.2.6.9)
03-22. Release Unit (ST 4.4.4.1)
03-23. Seven R’s of Change Management (ST 4.2.6.3)
Unit Content
03-24. Event (SO 4.1)
03-25. Alert (SO 4.1)
03-26. Incident (SO 4.2)
03-27. Impact, Urgency and Priority (SO 4.2.5.4, 4.4.5.4)
03-28. Service Request (SO 4.3)
03-29. Problem (SO 4.4)
03-30. Workaround (SO 4.4.5.6)
03-31. Known Error (SO 4.4.5.7)
03-32. Known Error Data Base (KEDB) (SO 4.4.7.2)
03-33. The role of communication in Service Operation (SO 3.6)
The recommended study period for this unit is minimum 1 hour and 30 minutes.
This unit will probably be covered as part of the training in the other units.
ITILFND04 Key Principles and Models
The purpose of this unit is to help the candidate to comprehend and account for
the key principles and models of Service Management and to balance some of the
opposing forces within Service Management.
Service Strategy
04-1. Explain how Service Assets are the basis for Value Creation (SS 3.2.1)
04-2. Describe basics of Value Creation through Services (SS 3.1.1, 3.1.2)
Service Design
04-3. Understand the importance of People, Processes, Products and Partners
for Service Management (SD 2.4.2)
04-4. Discuss the five major aspects of Service Design (SD 3.6):
• Service Portfolio Design
• Identification of Business Requirements, definition of Service
requirements and design of Services
• Technology and architectural design
• Process design
• Measurement design
04-5. Distinguish between different sourcing approaches and options (SD
3.11.1 & Table 3.1)
Service Transition
04-6. Explain the Service V model (ST 4.4.5.1, 4.5.4.7)
Service Operation
04-7. Summarize the following conflicting balances in Service Operation (SO
3.2):
• IT Services versus Technology components
• Stability versus Responsiveness
• Quality of Service versus Cost of Service
Unit Content
• Reactive versus Proactive

04-8. Discuss the Plan, Do, Check and Act (PDCA) Model to control and
manage quality (CSI 3.6, 5.5)
04-9. Explain the Continual Service Improvement Model (CSI 2.4.4)
04-10. Understand the role of measurement for Continual Service Improvement
and explain the following key elements:
• Business value (CSI 3.7.2)
• Baselines (CSI 3.7.1)
• Types of metrics (technology metrics, process metrics, service
metrics) (CSI 4.1.3)
The recommended study period for this unit is minimum 2 hours and 30
minutes.
ITILFND05 Processes
The purpose of this unit is to help the candidate understand how the Service
Management processes contribute to the Service Lifecycle, to explain the high level
objectives, scope, basic concepts, activities, key metrics (KPI’s), roles and challenges for
five of the core processes and to state the objectives, some of the basic concepts
and roles for fifteen of the remaining processes.
Service Strategy
05-1. Outline the four main activities in the Service Strategy process
• Define the market (SS 4.1)
• Develop the offerings (SS 4.2)
• Develop strategic assets (SS 4.3)
• Prepare for execution (SS 4.4)
05-2. State the objectives, basic concepts and roles for:
• Service Portfolio Management (SPM) (SS 5.3, 5.4, 11.2.1)
• Demand Management (SS 5.5)
• Financial Management (SS 5.1, 5.1.2)
Service Design
05-3. Explain the high level objectives, scope, basic concepts, process activities,
key metrics (KPI’s), roles and challenges for:
• Service Level Management (SLM) (SD 4.2, 6.4.6, CSI 3.5, 4.6)

• Service Catalogue Management (SD 4.1.1, 4.1.4, 6.4.5)
• Availability Management (SD 4.4.1, 4.4.4, 6.4.7)
• Information Security Management (ISM) (SD 4.6.1, 4.6.4, 6.4.10)
• Supplier Management (SD 4.7.1, 4.7.4, 6.4.11)

Unit Content
• Capacity Management (SD 4.3.1, 4.3.4, 6.4.9)
• IT Service Continuity Management (SD 4.5.1, 4.5.4, 6.4.8)
Service Transition
key metrics, roles and challenges for:
• Change Management (ST 4.2, 6.3.2.4)

• Service Asset and Configuration Management (SACM) (ST 4.3.1, 4.3.4,
6.3.2.4)
• Release and Deployment Management (ST 4.4.1, 4.4.4, 6.3.2.8, 6.3.2.9,
6.3.2.10)
Service Operation
key metrics, roles and challenges for:
• Incident Management (SO 4.2, 6.6.6)

• Event Management (SO 4.1.1, 4.1.4, 6.5.5)
• Request Fulfilment (SO 4.3.1, 4.3.4, 6.6.7)
• Problem Management (SO 4.4.1, 4.4.4, 6.6.8)
• Access Management (SO 4.5.1, 4.5.4, 6.6.9)

05-9. Explain the high level objectives, basic concepts, process activities, roles
and metrics for:
• The 7 step improvement process (CSI 3.7.3, 4.1.1 6.1.1, 6.1.2, 6.1.3)
The recommended study period for this unit is minimum 5 hours.

ITILFND06 Functions
The purpose of this unit is to help the candidate to explain the role, objectives,
organizational structures, staffing and metrics of the Service Desk function and to
state the role, objectives and overlap of three other functions.

06-1. Explain the role, objectives, organizational structures, staffing and metrics
of:
• The Service Desk function (SO 6.2)
06-2. State the role, objectives and organisational overlap of:

• The Technical Management function (SO 6.3.1, 6.3.2)
• The Application Management function (SO 6.5.1, 6.5.2)
• The IT Operations Management function (IT Operations Control and
Facilities Management) (SO 6.4.1, 6.4.2)

Unit Content

ITILFND07 Roles
The purpose of this unit is to help the candidate to account for the role and to be
aware of the responsibilities of some of the key roles in Service Management and to
recognize a number of the remaining roles described in other Learning Units.
07-1. Account for the role and the responsibilities of the

• Process owner (SD 6.4.1, ST 6.1.1, CSI 3.3, 6.1.5)
• Service owner (ST 6.2.1, CSI 3.3, 6.1.4)
07-2. Recognize the RACI model and explain its role in determining
organisational structure. (SD 6, CSI 6.2)
ITILFND08 Technology and Architecture
The purpose of this unit is to help the candidate to

08-1. List some generic requirements for an integrated set of Service Management
Technology (SD 7.1, ST 7, SO 7.1)
08-2. Understand how Service Automation assists with integrating Service
Management processes (SS 8.1)
The recommended study period for this unit is minimum 30 minutes.
ITILFND09 ITIL® Qualification scheme
The purpose of this unit is to help the candidate to

09-1. Explain the ITIL® Qualification scheme, distinguish between the
purposes of the two intermediate streams, mention the included
certificates and diplomas, and understand the different options for
further training (Non examinable).
The recommended study period for this unit is minimum 15 minutes.
ITILFND10 Mock exam
The purpose of this unit is to help the candidate to pass the ITIL® Foundation
exam.
Specifically, candidates must:

10-1. Sit minimum one ITIL® Foundation mock exam.
The recommended study period for this unit is minimum 2 hours inclusive
revision.
Format of the Examination
This syllabus has an accompanying examination at which the candidate must achieve a pass score
to gain the ITIL® Foundation Certificate in IT Service Management.
Type: Multiple choices, 40 questions

Duration: Maximum 60 minutes. Candidates sitting the examination in a language
other than their native language have a maximum of 75 minutes and are
allowed the use of a dictionary)
Prerequisite: Accredited Foundation training is strongly recommended but not a
prerequisite
Supervised: Yes
Open Book: No
Pass Score: 65% (26 out of 40)
Distinction Score: None
Delivery: Online or Paper Based.

HP Instructor-Led Training
Course satisfaction survey
Student details/Course details (If you wish to provide your feedback anonymously, all fields marked with * are optional)
Last name:* Course ID:
First name:* Course name:
Business email address:* Course end date:
HP Student ID/HP Employee number:*
All students Please help us improve our service to you by providing the following information.
Strongly Somewhat Strongly N/A

Please rate the extent of your agreement with the following statements: disagree Disagree agree Agree agree
I believe this course achieved its stated objectives 1 2 3 4 5

The skills/concepts taught are directly relevant to the demands of my job/role 1 2 3 4 5
The instructor's teaching methods, style, and pace helped me to learn 1 2 3 4 5
The student guide/workbook enhanced the course content and met my needs 1 2 3 4 5
The examples, hands-on labs, or exercises enhanced my learning 1 2 3 4 5
What I have learned will enhance my job/role performance 1 2 3 4 5
I am motivated to apply these new skills/concepts in my job/role 1 2 3 4 5
I would recommend this course to others 1 2 3 4 5
The overall quality of this course was excellent 1 2 3 4 5
Somewhat Very Completely N/A

Please rate your overall satisfaction with the following aspects of the course: Dissatisfied dissatisfied Satisfied satisfied satisfied
Course content 1 2 3 4 5
Instructor 1 2 3 4 5
Course logistics 1 2 3 4 5
Registration process 1 2 3 4 5
Training facility/classroom 1 2 3 4 5
Lab or demonstration equipment 1 2 3 4 5
What comments or suggestions do you have about any aspect of the course?
If you could do one thing to make this course excellent, what would it be?
Please select whether you are an HP Employee or an HP Customer or HP Partner:
HP Employee HP Customer/HP Partner
Additional questions on the potential impact of your learning experience can be found at the back of this page.
Your responses are greatly appreciated.
HP Customers and Partners only If you are an HP Customer or an HP Partner employee please help us improve
our service to you by providing the following information:
Last name: Course ID:
First name: Course name:
New Skills and Knowledge
If 0% represents no increase, and 100% represents a very significant increase on your previous ■ 0% - 20% ■ 20% - 40% ■ 40% - 60%
knowledge, please rate your INCREASE in skill level or knowledge of this content after this course ■ 60% - 80% ■ 80% - 100% ■ N/A
What percentage of the new knowledge and skills you learned from this course do you estimate ■ 0% - 20% ■ 20% - 40% ■ 40% - 60%
you will apply directly to your job? ■ 60% - 80% ■ 80% - 100% ■ N/A
What percentage of your total work time requires you to use the knowledge and skills presented ■ 0% - 20% ■ 20% - 40% ■ 40% - 60%
in this course? ■ 60% - 80% ■ 80% - 100% ■ N/A
On a scale of 0% (not at all) to 100% (extremely critical), how critical is applying the content ■ 0% - 20% ■ 20% - 40% ■ 40% - 60%
of this course to your job success? ■ 60% - 80% ■ 80% - 100% ■ N/A
Your Preferences
What best describes your Job Function? ■ Accounting/Finance ■ Quality ■ Consulting ■ Engineering ■ Instructor
■ General Management ■ Human Resources ■ IT Professional ■ Marketing/Sales ■ Production
■ Purchasing ■ Student ■ Biotechnology/Pharmaceutical
■ Other (please specify)
What was the primary way you learned about this course or event?
■ HP web site ■ HP email ■ HP letter ■ HP printed course catalog

■ Recommendation ■ My manager ■ HP advert ■ HP Sales representative
■ Trade show ■ HP Channel Partner
What is the primary way you would like to learn about future courses or events?
■ HP web site ■ HP email ■ HP letter ■ HP printed course catalog
Follow-up Survey
HP invites you to participate in a follow-up survey to measure the impact of this training to your job.
Please indicate if you would be willing to participate. Yes No
HP Certified Professional Program
Regarding the HP Certified Professional Program, please help us improve our service to you by providing the following information:
Did you attend this course with the intention of becoming certified? Yes No
Would you consider pursuing certification based on your successful completion of this class? Yes No
No Low Very Highest N/A

Please rate the importance of the following aspects of the HPCP program: importance importance Important important importance
How important is the HP Certified Professional Program to you? 1 2 3 4 5

How important is the HP Certified Professional Program to your company? 1 2 3 4 5
How important is the HP Certified Professional Program to your customers? 1 2 3 4 5
Thank you for taking the time to complete this survey form.
Glossary
ITIL© Glossary of Terms, Definitions and Acronyms
© Crown Copyright Office of Government Commerce. Reproduced with the

permission of the Controller of HMSO and the Office of Government Commerce.
ITIL ® is a Registered Trade Mark, and a Registered Community Trade Mark of the
Office of Government Commerce, and is Registered in the U.S. Patent and Trademark
Office.
HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1

2 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

ITIL® V3 Glossary v3.1.24, 11 May 2007
Acceptance to Alert
ITIL® Glossary of Terms, Definitions and Acronyms
Term Definition
Acceptance Formal agreement that an IT Service, Process, Plan, or other

Deliverable is complete, accurate, Reliable and meets its specified
Requirements. Acceptance is usually preceded by Evaluation or Testing
and is often required before proceeding to the next stage of a Project or
Process.
See Service Acceptance Criteria.
Access (Service Operation) The Process responsible for allowing Users

Management to make use of IT Services, data, or other Assets. Access Management
helps to protect the Confidentiality, Integrity and Availability of Assets by
ensuring that only authorized Users are able to access or modify the
Assets. Access Management is sometimes referred to as Rights
Management or Identity Management.
Account Manager (Service Strategy) A Role that is very similar to Business Relationship
Manager, but includes more commercial aspects. Most commonly used
when dealing with External Customers.
Accounting (Service Strategy) The Process responsible for identifying actual Costs
of delivering IT Services, comparing these with budgeted costs, and
managing variance from the Budget.
Accredited Officially authorised to carry out a Role. For example an Accredited

body may be authorised to provide training or to conduct Audits.
Active Monitoring (Service Operation) Monitoring of a Configuration Item or an IT Service

that uses automated regular checks to discover the current status.
See Passive Monitoring.
Activity A set of actions designed to achieve a particular result. Activities are

usually defined as part of Processes or Plans, and are documented in
Procedures.
Agreed Service (Service Design) A synonym for Service Hours, commonly used in
Time formal calculations of Availability. See Downtime.
Agreement A Document that describes a formal understanding between two or

more parties. An Agreement is not legally binding, unless it forms part of
a Contract.
See Service Level Agreement, Operational Level Agreement.
Alert (Service Operation) A warning that a threshold has been reached,

something has changed, or a Failure has occurred. Alerts are often
created and managed by System Management tools and are managed
by the Event Management Process.
Analytical Modelling to Assessment
Term Definition
Analytical (Service Strategy) (Service Design) (Continual Service

Modelling Improvement) A technique that uses mathematical Models to predict
the behaviour of a Configuration Item or IT Service. Analytical Models
are commonly used in Capacity Management and Availability
Management.
See Modelling.
Application Software that provides Functions that are required by an IT Service.

Each Application may be part of more than one IT Service. An
Application runs on one or more Servers or Clients.
See Application Management, Application Portfolio.
Application (Service Design) (Service Operation) The Function responsible for

Management managing Applications throughout their Lifecycle.
Application (Service Design) A database or structured Document used to manage

Portfolio Applications throughout their Lifecycle. The Application Portfolio
contains key Attributes of all Applications. The Application Portfolio is
sometimes implemented as part of the Service Portfolio, or as part of
the Configuration Management System.
Application (Service Design) An External Service Provider that provides IT

Service Provider Services using Applications running at the Service Provider's premises.
(ASP) Users access the Applications by network connections to the Service
Provider.
Application Sizing (Service Design) The Activity responsible for understanding the
Resource Requirements needed to support a new Application, or a
major Change to an existing Application. Application Sizing helps to
ensure that the IT Service can meet its agreed Service Level Targets for
Capacity and Performance.
Architecture (Service Design) The structure of a System or IT Service, including the

Relationships of Components to each other and to the environment they
are in. Architecture also includes the Standards and Guidelines which
guide the design and evolution of the System.
Assembly (Service Transition) A Configuration Item that is made up from a

number of other CIs. For example a Server CI may contain CIs for
CPUs, Disks, Memory etc.; an IT Service CI may contain many
Hardware, Software and other CIs.
See Component CI, Build.
Assessment Inspection and analysis to check whether a Standard or set of

Guidelines is being followed, that Records are accurate, or that
Efficiency and Effectiveness targets are being met.
See Audit.
Asset to Availability Management Information System (AMIS)
Term Definition
Asset (Service Strategy) Any Resource or Capability. Assets of a Service

Provider include anything that could contribute to the delivery of a
Service. Assets can be one of the following types: Management,
Organisation, Process, Knowledge, People, Information, Applications,
Infrastructure, and Financial Capital.
Asset (Service Transition) Asset Management is the Process responsible for

Management tracking and reporting the value and ownership of financial Assets
throughout their Lifecycle. Asset Management is part of an overall
Service Asset and Configuration Management Process.
See Asset Register.
Asset Register (Service Transition) A list of Assets, which includes their ownership
and value. The Asset Register is maintained by Asset Management.
Attribute (Service Transition) A piece of information about a Configuration Item.

Examples are name, location, Version number, and Cost. Attributes of
CIs are recorded in the Configuration Management Database (CMDB).
See Relationship.
Audit Formal inspection and verification to check whether a Standard or set of

Guidelines is being followed, that Records are accurate, or that
Efficiency and Effectiveness targets are being met. An Audit may be
carried out by internal or external groups.
See Certification, Assessment.
Authority Matrix Synonym for RACI.
Automatic Call (Service Operation) Use of Information Technology to direct an

Distribution (ACD) incoming telephone call to the most appropriate person in the shortest
possible time. ACD is sometimes called Automated Call Distribution.
Availability (Service Design) Ability of a Configuration Item or IT Service to perform

its agreed Function when required. Availability is determined by
Reliability, Maintainability, Serviceability, Performance, and Security.
Availability is usually calculated as a percentage. This calculation is
often based on Agreed Service Time and Downtime. It is Best Practice
to calculate Availability using measurements of the Business output of
the IT Service.
Availability (Service Design) The Process responsible for defining, analysing,

Management Planning, measuring and improving all aspects of the Availability of IT
Services. Availability Management is responsible for ensuring that all IT
Infrastructure, Processes, Tools, Roles etc are appropriate for the
agreed Service Level Targets for Availability.
Availability (Service Design) A virtual repository of all Availability Management

Management data, usually stored in multiple physical locations.
Information See Service Knowledge Management System.
System (AMIS)
Availability Plan to Brainstorming
Term Definition
Availability Plan (Service Design) A Plan to ensure that existing and future Availability
Requirements for IT Services can be provided Cost Effectively.
Back-out Synonym for Remediation.
Backup (Service Design) (Service Operation) Copying data to protect against

loss of Integrity or Availability of the original.
Balanced (Continual Service Improvement) A management tool developed by

Scorecard Drs. Robert Kaplan (Harvard Business School) and David Norton. A
Balanced Scorecard enables a Strategy to be broken down into Key
Performance Indicators. Performance against the KPIs is used to
demonstrate how well the Strategy is being achieved. A Balanced
Scorecard has 4 major areas, each of which has a small number of
KPIs. The same 4 areas are considered at different levels of detail
throughout the Organisation.
Baseline (Continual Service Improvement) A Benchmark used as a reference

point. For example:
• An ITSM Baseline can be used as a starting point to measure the
effect of a Service Improvement Plan
• A Performance Baseline can be used to measure changes in
Performance over the lifetime of an IT Service
• A Configuration Management Baseline can be used to enable the
IT Infrastructure to be restored to a known Configuration if a
Change or Release fails
Benchmark (Continual Service Improvement) The recorded state of something at

a specific point in time. A Benchmark can be created for a
Configuration, a Process, or any other set of data. For example, a
benchmark can be used in:
• Continual Service Improvement, to establish the current state for
managing improvements.
• Capacity Management, to document Performance characteristics
during normal operations.
• See Benchmarking, Baseline.
Benchmarking (Continual Service Improvement) Comparing a Benchmark with a

Baseline or with Best Practice. The term Benchmarking is also used to
mean creating a series of Benchmarks over time, and comparing the
results to measure progress or improvement.
Best Practice Proven Activities or Processes that have been successfully used by
multiple Organisations. ITIL is an example of Best Practice.
Brainstorming (Service Design) A technique that helps a team to generate ideas.

Ideas are not reviewed during the Brainstorming session, but at a later
stage. Brainstorming is often used by Problem Management to identify
possible causes.
British Standards Institution (BSI) to Business Continuity Management (BCM)
Term Definition
British Standards The UK National Standards body, responsible for creating and
Institution (BSI) maintaining British Standards. See http://www.bsi-global.com for more
information.
See ISO.
Budget A list of all the money an Organisation or Business Unit plans to receive,
and plans to pay out, over a specified period of time.
See Budgeting, Planning.
Budgeting The Activity of predicting and controlling the spending of money.

Consists of a periodic negotiation cycle to set future Budgets (usually
annual) and the day-to-day monitoring and adjusting of current Budgets.
Build (Service Transition) The Activity of assembling a number of

Configuration Items to create part of an IT Service. The term Build is
also used to refer to a Release that is authorised for distribution. For
example Server Build or laptop Build.
See Configuration Baseline.
Build Environment (Service Transition) A controlled Environment where Applications, IT

Services and other Builds are assembled prior to being moved into a
Test or Live Environment.
Business (Service Strategy) An overall corporate entity or Organisation formed

of a number of Business Units. In the context of ITSM, the term
Business includes public sector and not-for-profit organisations, as well
as companies. An IT Service Provider provides IT Services to a
Customer within a Business. The IT Service Provider may be part of the
same Business as their Customer (Internal Service Provider), or part of
another Business (External Service Provider).
Business (Service Design) In the context of ITSM, Business Capacity

Capacity Management is the Activity responsible for understanding future
Management Business Requirements for use in the Capacity Plan.
(BCM) See Service Capacity Management.
Business Case (Service Strategy) Justification for a significant item of expenditure.

Includes information about Costs, benefits, options, issues, Risks, and
possible problems.
See Cost Benefit Analysis.
Business (Service Design) The Business Process responsible for managing

Continuity Risks that could seriously impact the Business. BCM safeguards the
Management interests of key stakeholders, reputation, brand and value creating
(BCM) activities. The BCM Process involves reducing Risks to an acceptable
level and planning for the recovery of Business Processes should a
disruption to the Business occur. BCM sets the Objectives, Scope and
Requirements for IT Service Continuity Management.
Business Continuity Plan (BCP) to Business Relationship Manager (BRM)
Term Definition
Business (Service Design) A Plan defining the steps required to Restore

Continuity Plan Business Processes following a disruption. The Plan will also identify
(BCP) the triggers for Invocation, people to be involved, communications etc.
IT Service Continuity Plans form a significant part of Business
Continuity Plans.
Business (Service Strategy) A recipient of a product or a Service from the

Customer Business. For example if the Business is a car manufacturer then the
Business Customer is someone who buys a car.
Business Impact (Service Strategy) BIA is the Activity in Business Continuity

Analysis (BIA) Management that identifies Vital Business Functions and their
dependencies. These dependencies may include Suppliers, people,
other Business Processes, IT Services etc.
BIA defines the recovery requirements for IT Services. These
requirements include Recovery Time Objectives, Recovery Point
Objectives and minimum Service Level Targets for each IT Service.
Business (Service Strategy) The Objective of a Business Process, or of the

Objective Business as a whole. Business Objectives support the Business Vision,
provide guidance for the IT Strategy, and are often supported by IT
Services.
Business (Service Strategy) The day-to-day execution, monitoring and

Operations management of Business Processes.
Business (Continual Service Improvement) An understanding of the Service

Perspective Provider and IT Services from the point of view of the Business, and an
understanding of the Business from the point of view of the Service
Provider.
Business Process A Process that is owned and carried out by the Business. A Business
Process contributes to the delivery of a product or Service to a Business
Customer. For example, a retailer may have a purchasing Process
which helps to deliver Services to their Business Customers. Many
Business Processes rely on IT Services.
Business (Service Strategy) The Process or Function responsible for maintaining

Relationship a Relationship with the Business. BRM usually includes:
Management • Managing personal Relationships with Business managers
• Providing input to Service Portfolio Management
• Ensuring that the IT Service Provider is satisfying the Business
needs of the Customers
This Process has strong links with Service Level Management.
Business (Service Strategy) A Role responsible for maintaining the Relationship

Relationship with one or more Customers. This Role is often combined with the
Manager (BRM) Service Level Manager Role.
See Account Manager.
Business Service to Capability Maturity Model (CMM)
Term Definition
Business Service An IT Service that directly supports a Business Process, as opposed to

an Infrastructure Service which is used internally by the IT Service
Provider and is not usually visible to the Business.
The term Business Service is also used to mean a Service that is
delivered to Business Customers by Business Units. For example
delivery of financial services to Customers of a bank, or goods to the
Customers of a retail store. Successful delivery of Business Services
often depends on one or more IT Services.
Business Service (Service Strategy) (Service Design) An approach to the management

Management of IT Services that considers the Business Processes supported and the
(BSM) Business value provided.
This term also means the management of Business Services delivered
to Business Customers.
Business Unit (Service Strategy) A segment of the Business which has its own Plans,
Metrics, income and Costs. Each Business Unit owns Assets and uses
these to create value for Customers in the form of goods and Services.
Call (Service Operation) A telephone call to the Service Desk from a User.
A Call could result in an Incident or a Service Request being logged.
Call Centre (Service Operation) An Organisation or Business Unit which handles

large numbers of incoming and outgoing telephone calls.
See Service Desk.
Call Type (Service Operation) A Category that is used to distinguish incoming

requests to a Service Desk. Common Call Types are Incident, Service
Request and Complaint.
Capability (Service Strategy) The ability of an Organisation, person, Process,

Application, Configuration Item or IT Service to carry out an Activity.
Capabilities are intangible Assets of an Organisation.
See Resource.
Capability (Continual Service Improvement) The Capability Maturity Model for

Maturity Model Software (also known as the CMM and SW-CMM) is a model used to
(CMM) identify Best Practices to help increase Process Maturity. CMM was
developed at the Software Engineering Institute (SEI) of Carnegie
Mellon University. In 2000, the SW-CMM was upgraded to CMMI®
(Capability Maturity Model Integration). The SEI no longer maintains the
SW-CMM model, its associated appraisal methods, or training
materials.
Capability Maturity Model Integration (CMMI) to Capitalization
Term Definition
Capability (Continual Service Improvement) Capability Maturity Model®

Maturity Model Integration (CMMI) is a process improvement approach developed by
Integration the Software Engineering Institute (SEI) of Carnegie Melon University.
(CMMI) CMMI provides organizations with the essential elements of effective
processes. It can be used to guide process improvement across a
project, a division, or an entire organization. CMMI helps integrate
traditionally separate organizational functions, set process improvement
goals and priorities, provide guidance for quality processes, and provide
a point of reference for appraising current processes. See
http://www.sei.cmu.edu/cmmi/ for more information.
See CMM, Continuous Improvement, Maturity.
Capacity (Service Design) The maximum Throughput that a Configuration Item

or IT Service can deliver whilst meeting agreed Service Level Targets.
For some types of CI, Capacity may be the size or volume, for example
a disk drive.
Capacity (Service Design) The Process responsible for ensuring that the
Management Capacity of IT Services and the IT Infrastructure is able to deliver
agreed Service Level Targets in a Cost Effective and timely manner.
Capacity Management considers all Resources required to deliver the
IT Service, and plans for short, medium and long term Business
Requirements.
Capacity (Service Design) A virtual repository of all Capacity Management data,

Management usually stored in multiple physical locations.
Information See Service Knowledge Management System.
System (CMIS)
Capacity Plan (Service Design) A Capacity Plan is used to manage the Resources
required to deliver IT Services. The Plan contains scenarios for different
predictions of Business demand, and costed options to deliver the
agreed Service Level Targets.
Capacity Planning (Service Design) The Activity within Capacity Management responsible
for creating a Capacity Plan.
Capital (Service Strategy) The Cost of purchasing something that will become
Expenditure a financial Asset, for example computer equipment and buildings. The
(CAPEX) value of the Asset is Depreciated over multiple accounting periods.
Capital Item (Service Strategy) An Asset that is of interest to Financial Management

because it is above an agreed financial value.
Capitalization (Service Strategy) Identifying major Cost as capital, even though no

Asset is purchased. This is done to spread the impact of the Cost over
multiple accounting periods. The most common example of this is
software development, or purchase of a software license.
Category to Change Request
Term Definition
Category A named group of things that have something in common. Categories

are used to group similar things together. For example Cost Types are
used to group similar types of Cost. Incident Categories are used to
group similar types of Incident, CI Types are used to group similar types
of Configuration Item.
Certification Issuing a certificate to confirm Compliance to a Standard. Certification

includes a formal Audit by an independent and Accredited body. The
term Certification is also used to mean awarding a certificate to verify
that a person has achieved a qualification.
Change (Service Transition) The addition, modification or removal of anything

that could have an effect on IT Services. The Scope should include all
IT Services, Configuration Items, Processes, Documentation etc.
Change Advisory (Service Transition) A group of people that advises the Change
Board (CAB) Manager in the Assessment, prioritisation and scheduling of Changes.
This board is usually made up of representatives from all areas within
the IT Service Provider, the Business, and Third Parties such as
Suppliers.
Change Case (Service Operation) A technique used to predict the impact of

proposed Changes. Change Cases use specific scenarios to clarify the
scope of proposed Changes and to help with Cost Benefit Analysis.
See Use Case.
Change History (Service Transition) Information about all changes made to a

Configuration Item during its life. Change History consists of all those
Change Records that apply to the CI.
Change (Service Transition) The Process responsible for controlling the

Management Lifecycle of all Changes. The primary objective of Change Management
is to enable beneficial Changes to be made, with minimum disruption to
IT Services.
Change Model (Service Transition) A repeatable way of dealing with a particular

Category of Change. A Change Model defines specific pre-defined
steps that will be followed for a Change of this Category. Change
Models may be very simple, with no requirement for approval (e.g.
Password Reset) or may be very complex with many steps that require
approval (e.g. major software Release).
See Standard Change, Change Advisory Board.
Change Record (Service Transition) A Record containing the details of a Change.

Each Change Record documents the Lifecycle of a single Change. A
Change Record is created for every Request for Change that is
received, even those that are subsequently rejected. Change Records
should reference the Configuration Items that are affected by the
Change. Change Records are stored in the Configuration Management
System.
Change Request Synonym for Request for Change.

Change Schedule to Code of Practice
Term Definition
Change Schedule (Service Transition) A Document that lists all approved Changes and
their planned implementation dates. A Change Schedule is sometimes
called a Forward Schedule of Change, even though it also contains
information about Changes that have already been implemented.
Change Window (Service Transition) A regular, agreed time when Changes or

Releases may be implemented with minimal impact on Services.
Change Windows are usually documented in SLAs.
Charging (Service Strategy) Requiring payment for IT Services. Charging for IT

Services is optional, and many Organisations choose to treat their IT
Service Provider as a Cost Centre.
Chronological (Service Operation) A technique used to help identify possible causes

Analysis of Problems. All available data about the Problem is collected and
sorted by date and time to provide a detailed timeline. This can make it
possible to identify which Events may have been triggered by others.
CI Type (Service Transition) A Category that is used to Classify CIs. The CI

Type identifies the required Attributes and Relationships for a
Configuration Record. Common CI Types include: hardware, Document,
User etc.
Classification The act of assigning a Category to something. Classification is used to

ensure consistent management and reporting. CIs, Incidents, Problems,
Changes etc. are usually classified.
Client A generic term that means a Customer, the Business or a Business

Customer. For example Client Manager may be used as a synonym for
Account Manager.
The term client is also used to mean:
• A computer that is used directly by a User, for example a PC,
Handheld Computer, or Workstation.
• The part of a Client-Server Application that the User directly
interfaces with. For example an email Client.
Closed (Service Operation) The final Status in the Lifecycle of an Incident,

Problem, Change etc. When the Status is Closed, no further action is
taken.
Closure (Service Operation) The act of changing the Status of an Incident,

Problem, Change etc. to Closed.
COBIT (Continual Service Improvement) Control Objectives for Information

and related Technology (COBIT) provides guidance and Best Practice
for the management of IT Processes. COBIT is published by the IT
Governance Institute. See http://www.isaca.org/ for more information.
Code of Practice A Guideline published by a public body or a Standards Organisation,

such as ISO or BSI. Many Standards consist of a Code of Practice and
a Specification. The Code of Practice describes recommended Best
Practice.
Cold Standby to Configuration Baseline
Term Definition
Cold Standby Synonym for Gradual Recovery.
Commercial off (Service Design) Application software or Middleware that can be

the Shelf (COTS) purchased from a Third Party.
Compliance Ensuring that a Standard or set of Guidelines is followed, or that proper,

consistent accounting or other practices are being employed.
Component A general term that is used to mean one part of something more
complex. For example, a computer System may be a component of an
IT Service, an Application may be a Component of a Release Unit.
Components that need to be managed should be Configuration Items.
Component (Service Design) (Continual Service Improvement) The Process

Capacity responsible for understanding the Capacity, Utilisation, and
Management Performance of Configuration Items. Data is collected, recorded and
(CCM) analysed for use in the Capacity Plan.
See Service Capacity Management.
Component CI (Service Transition) A Configuration Item that is part of an Assembly.

For example, a CPU or Memory CI may be part of a Server CI.
Component (Service Design) A technique that helps to identify the impact of CI

Failure Impact failure on IT Services. A matrix is created with IT Services on one edge
Analysis (CFIA) and CIs on the other. This enables the identification of critical CIs (that
could cause the failure of multiple IT Services) and of fragile IT Services
(that have multiple Single Points of Failure).
Computer (Service Operation) CTI is a general term covering any kind of

Telephony integration between computers and telephone Systems. It is most
Integration (CTI) commonly used to refer to Systems where an Application displays
detailed screens relating to incoming or outgoing telephone calls.
See Automatic Call Distribution, Interactive Voice Response.
Concurrency A measure of the number of Users engaged in the same Operation at

the same time.
Confidentiality (Service Design) A security principle that requires that data should only
be accessed by authorised people.
Configuration (Service Transition) A generic term, used to describe a group of

Configuration Items that work together to deliver an IT Service, or a
recognizable part of an IT Service. Configuration is also used to
describe the parameter settings for one or more CIs.
Configuration (Service Transition) A Baseline of a Configuration that has been

Baseline formally agreed and is managed through the Change Management
process. A Configuration Baseline is used as a basis for future Builds,
Releases and Changes.
Configuration Control to Configuration Structure
Term Definition
Configuration (Service Transition) The Activity responsible for ensuring that adding,
Control modifying or removing a CI is properly managed, for example by
submitting a Request for Change or Service Request.
Configuration (Service Transition) The Activity responsible for collecting information

Identification about Configuration Items and their Relationships, and loading this
information into the CMDB. Configuration Identification is also
responsible for labelling the CIs themselves, so that the corresponding
Configuration Records can be found.
Configuration (Service Transition) Any Component that needs to be managed in

Item (CI) order to deliver an IT Service. Information about each CI is recorded in
a Configuration Record within the Configuration Management System
and is maintained throughout its Lifecycle by Configuration
Management. CIs are under the control of Change Management. CIs
typically include IT Services, hardware, software, buildings, people, and
formal documentation such as Process documentation and SLAs.
Configuration (Service Transition) The Process responsible for maintaining

Management information about Configuration Items required to deliver an IT Service,
including their Relationships. This information is managed throughout
the Lifecycle of the CI. Configuration Management is part of an overall
Service Asset and Configuration Management Process.
Configuration (Service Transition) A database used to store Configuration Records

Management throughout their Lifecycle. The Configuration Management System
Database maintains one or more CMDBs, and each CMDB stores Attributes of
(CMDB) CIs, and Relationships with other CIs.
Configuration (Service Transition) A set of tools and databases that are used to
Management manage an IT Service Provider's Configuration data. The CMS also
System (CMS) includes information about Incidents, Problems, Known Errors, Changes
and Releases; and may contain data about employees, Suppliers,
locations, Business Units, Customers and Users. The CMS includes
tools for collecting, storing, managing, updating, and presenting data
about all Configuration Items and their Relationships. The CMS is
maintained by Configuration Management and is used by all IT Service
See Configuration Management Database, Service Knowledge
Management System.
Configuration (Service Transition) A Record containing the details of a Configuration

Record Item. Each Configuration Record documents the Lifecycle of a single CI.
Configuration Records are stored in a Configuration Management
Database.
Configuration (Service Transition) The hierarchy and other Relationships between all
Structure the Configuration Items that comprise a Configuration.
Continual Service Improvement (CSI) to Control Processes
Term Definition
Continual Service (Continual Service Improvement) A stage in the Lifecycle of an IT

Improvement Service and the title of one of the Core ITIL publications.
(CSI) Continual Service Improvement is responsible for managing
improvements to IT Service Management Processes and IT Services.
The Performance of the IT Service Provider is continually measured and
improvements are made to Processes, IT Services and IT Infrastructure
in order to increase Efficiency, Effectiveness, and Cost Effectiveness.
See Plan-Do-Check-Act.
Continuous (Service Design) An approach or design to achieve 100% Availability.

Availability A Continuously Available IT Service has no planned or unplanned
Downtime.
Continuous (Service Design) An approach or design to eliminate planned

Operation Downtime of an IT Service. Note that individual Configuration Items may
be down even though the IT Service is Available.
Contract A legally binding Agreement between two or more parties.
Contract Portfolio (Service Strategy) A database or structured Document used to

manage Service Contracts or Agreements between an IT Service
Provider and their Customers. Each IT Service delivered to a Customer
should have a Contract or other Agreement which is listed in the
Contract Portfolio.
See Service Portfolio, Service Catalogue.
Control A means of managing a Risk, ensuring that a Business Objective is

achieved, or ensuring that a Process is followed. Example Controls
include Policies, Procedures, Roles, RAID, door-locks etc. A control is
sometimes called a Countermeasure or safeguard.
Control also means to manage the utilization or behaviour of a
Configuration Item, System or IT Service.
Control See COBIT.

Objectives for
Information and
related
Technology
(COBIT)
Control (Service Strategy) An approach to the management of IT Services,

perspective Processes, Functions, Assets etc. There can be several different
Control Perspectives on the same IT Service, Process etc., allowing
different individuals or teams to focus on what is important and relevant
to their specific Role. Example Control Perspectives include Reactive
and Proactive management within IT Operations, or a Lifecycle view for
an Application Project team.
Control The ISO/IEC 20000 Process group that includes Change Management
Processes and Configuration Management.
Core Service to Cost Unit
Term Definition
Core Service (Service Strategy) An IT Service that delivers basic Outcomes desired
by one or more Customers.
See Supporting Service, Core Service Package.
Core Service (Service Strategy) A detailed description of a Core Service that may be
Package (CSP) shared by two or more Service Level Packages.
See Service Package.
Cost The amount of money spent on a specific Activity, IT Service, or

Business Unit. Costs consist of real cost (money), notional cost such as
people's time, and Depreciation.
Cost Benefit An Activity that analyses and compares the Costs and the benefits
Analysis involved in one or more alternative courses of action.
See Business Case, Net Present Value, Internal Rate of Return, Return
on Investment, Value on Investment.
Cost Centre (Service Strategy) A Business Unit or Project to which Costs are
assigned. A Cost Centre does not charge for Services provided. An IT
Service Provider can be run as a Cost Centre or a Profit Centre.
Cost A measure of the balance between the Effectiveness and Cost of a

Effectiveness Service, Process or activity, A Cost Effective Process is one which
achieves its Objectives at minimum Cost.
See KPI, Return on Investment, Value for Money.
Cost Element (Service Strategy) The middle level of category to which Costs are
assigned in Budgeting and Accounting. The highest level category is
Cost Type. For example a Cost Type of “people” could have cost
elements of payroll, staff benefits, expenses, training, overtime etc. Cost
Elements can be further broken down to give Cost Units. For example
the Cost Element “expenses” could include Cost Units of Hotels,
Transport, Meals etc.
Cost (Service Strategy) A general term that is used to refer to Budgeting

Management and Accounting, sometimes used as a synonym for Financial
Management
Cost Type (Service Strategy) The highest level of category to which Costs are
assigned in Budgeting and Accounting. For example hardware,
software, people, accommodation, external and Transfer.
See Cost Element, Cost Type.
Cost Unit (Service Strategy) The lowest level of category to which Costs are
assigned, Cost Units are usually things that can be easily counted (e.g.
staff numbers, software licences) or things easily measured (e.g. CPU
usage, Electricity consumed). Cost Units are included within Cost
Elements. For example a Cost Element of “expenses” could include
Cost Units of Hotels, Transport, Meals etc.
See Cost Type.
Countermeasure to Data-to-Information-to-Knowledge-to-Wisdom (DIKW)
Term Definition
Countermeasure Can be used to refer to any type of Control. The term Countermeasure
is most often used when referring to measures that increase Resilience,
Fault Tolerance or Reliability of an IT Service.
Course Changes made to a Plan or Activity that has already started, to ensure
Corrections that it will meet its Objectives. Course corrections are made as a result
of Monitoring progress.
CRAMM A methodology and tool for analysing and managing Risks. CRAMM
was developed by the UK Government, but is now privately owned.
Further information is available from http://www.cramm.com/
Crisis The Process responsible for managing the wider implications of

Management Business Continuity. A Crisis Management team is responsible for
Strategic issues such as managing media relations and shareholder
confidence, and decides when to invoke Business Continuity Plans.
Critical Success Something that must happen if a Process, Project, Plan, or IT Service is
Factor (CSF) to succeed. KPIs are used to measure the achievement of each CSF.
For example a CSF of "protect IT Services when making Changes"
could be measured by KPIs such as "percentage reduction of
unsuccessful Changes", "percentage reduction in Changes causing
Incidents" etc.
Culture A set of values that is shared by a group of people, including

expectations about how people should behave, ideas, beliefs, and
practices.
See Vision.
Customer Someone who buys goods or Services. The Customer of an IT Service

Provider is the person or group who defines and agrees the Service
Level Targets. The term Customers is also sometimes informally used
to mean Users, for example "this is a Customer focussed Organisation".
Customer (Service Strategy) A database or structured Document used to record

Portfolio all Customers of the IT Service Provider. The Customer Portfolio is the
Business Relationship Manager's view of the Customers who receive
Services from the IT Service Provider.
See Contract Portfolio, Service Portfolio.
Dashboard (Service Operation) A graphical representation of overall IT Service

Performance and Availability. Dashboard images may be updated in
real-time, and can also be included in management reports and web
pages. Dashboards can be used to support Service Level Management,
Event Management or Incident Diagnosis.
Data-to- A way of understanding the relationships between data, information,

Information-to- knowledge, and wisdom. DIKW shows how each of these builds on the
Knowledge-to- others.
Wisdom (DIKW)
Definitive Media Library (DML) to Development Environment
Term Definition
Definitive Media (Service Transition) One or more locations in which the definitive and
Library (DML) approved versions of all software Configuration Items are securely
stored. The DML may also contain associated CIs such as licenses and
documentation. The DML is a single logical storage area even if there
are multiple locations. All software in the DML is under the control of
Change and Release Management and is recorded in the Configuration
Management System. Only software from the DML is acceptable for use
in a Release.
Deliverable Something that must be provided to meet a commitment in a Service

Level Agreement or a Contract. Deliverable is also used in a more
informal way to mean a planned output of any Process.
Demand Activities that understand and influence Customer demand for Services
Management and the provision of Capacity to meet these demands. At a Strategic
level Demand Management can involve analysis of Patterns of Business
Activity and User Profiles. At a Tactical level it can involve use of
Differential Charging to encourage Customers to use IT Services at less
busy times.
See Capacity Management.
Deming Cycle Synonym for Plan Do Check Act.
Dependency The direct or indirect reliance of one Process or Activity upon another.
Deployment (Service Transition) The Activity responsible for movement of new or

changed hardware, software, documentation, Process, etc to the Live
Environment. Deployment is part of the Release and Deployment
Management Process.
See Rollout.
Depreciation (Service Strategy) A measure of the reduction in value of an Asset

over its life. This is based on wearing out, consumption or other
reduction in the useful economic value.
Design (Service Design) An Activity or Process that identifies Requirements

and then defines a solution that is able to meet these Requirements.
See Service Design.
Detection (Service Operation) A stage in the Incident Lifecycle. Detection results

in the Incident becoming known to the Service Provider. Detection can
be automatic, or can be the result of a User logging an Incident.
Development (Service Design) The Process responsible for creating or modifying an

IT Service or Application. Also used to mean the Role or group that
carries out Development work.
Development (Service Design) An Environment used to create or modify IT Services

Environment or Applications. Development Environments are not typically subjected
to the same degree of control as Test Environments or Live
Environments.
See Development.
Diagnosis to Economies of scale
Term Definition
Diagnosis (Service Operation) A stage in the Incident and Problem Lifecycles.

The purpose of Diagnosis is to identify a Workaround for an Incident or
the Root Cause of a Problem.
Diagnostic Script (Service Operation) A structured set of questions used by Service

Desk staff to ensure they ask the correct questions, and to help them
Classify, Resolve and assign Incidents. Diagnostic Scripts may also be
made available to Users to help them diagnose and resolve their own
Incidents.
Differential A technique used to support Demand Management by charging different

Charging amounts for the same IT Service Function at different times.
Direct Cost (Service Strategy) A cost of providing an IT Service which can be

allocated in full to a specific Customer, Cost Centre, Project etc. For
example cost of providing non-shared servers or software licenses.
See Indirect Cost.
Directory Service (Service Operation) An Application that manages information about IT

Infrastructure available on a network, and corresponding User access
Rights.
Do Nothing (Service Design) A Recovery Option. The Service Provider formally

agrees with the Customer that Recovery of this IT Service will not be
performed.
Document Information in readable form. A Document may be paper or electronic.

For example a Policy statement, Service Level Agreement, Incident
Record, diagram of computer room layout.
See Record.
Downtime (Service Design) (Service Operation) The time when a Configuration

Item or IT Service is not Available during its Agreed Service Time. The
Availability of an IT Service is often calculated from Agreed Service
Time and Downtime.
Driver Something that influences Strategy, Objectives or Requirements. For

example new legislation or the actions of competitors.
Early Life Support (Service Transition) Support provided for a new or Changed IT
Service for a period of time after it is Released. During Early Life
Support the IT Service Provider may review the KPIs, Service Levels
and Monitoring Thresholds, and provide additional Resources for
Incident and Problem Management.
Economies of (Service Strategy) The reduction in average Cost that is possible from
scale increasing the usage of an IT Service or Asset.
See Economies of Scope.
Economies of scope to Escalation
Term Definition
Economies of (Service Strategy) The reduction in Cost that is allocated to an IT

scope Service by using an existing Asset for an additional purpose. For
example delivering a new IT Service from existing IT Infrastructure.
See Economies of Scale.
Effectiveness (Continual Service Improvement) A measure of whether the

Objectives of a Process, Service or Activity have been achieved. An
Effective Process or Activity is one that achieves its agreed Objectives.
See KPI.
Efficiency (Continual Service Improvement) A measure of whether the right

amount of resources have been used to deliver a Process, Service or
Activity. An Efficient Process achieves its Objectives with the minimum
amount of time, money, people or other resources.
See KPI.
Emergency (Service Transition) A Change that must be introduced as soon as

Change possible. For example to resolve a Major Incident or implement a
Security patch. The Change Management Process will normally have a
specific Procedure for handling Emergency Changes.
See Emergency Change Advisory Board (ECAB).
Emergency (Service Transition) A sub-set of the Change Advisory Board who

Change Advisory make decisions about high impact Emergency Changes. Membership of
Board (ECAB) the ECAB may be decided at the time a meeting is called, and depends
on the nature of the Emergency Change.
Environment (Service Transition) A subset of the IT Infrastructure that is used for a

particular purpose. For Example: Live Environment, Test Environment,
Build Environment. It is possible for multiple Environments to share a
Configuration Item, for example Test and Live Environments may use
different partitions on a single mainframe computer. Also used in the
term Physical Environment to mean the accommodation, air
conditioning, power system etc.
Environment is also used as a generic term to mean the external
conditions that influence or affect something.
Error (Service Operation) A design flaw or malfunction that causes a Failure

of one or more Configuration Items or IT Services. A mistake made by a
person or a faulty Process that impacts a CI or IT Service is also an
Error.
Escalation (Service Operation) An Activity that obtains additional Resources when

these are needed to meet Service Level Targets or Customer
expectations. Escalation may be needed within any IT Service
Management Process, but is most commonly associated with Incident
Management, Problem Management and the management of Customer
complaints. There are two types of Escalation, Functional Escalation
and Hierarchic Escalation.
eSourcing Capability Model for Client Organizations (eSCM-CL) to External
Customer
Term Definition
eSourcing (Service Strategy) A framework to help Organisations guide their

Capability Model analysis and decisions on Service Sourcing Models and Strategies.
for Client eSCM-CL was developed by Carnegie Mellon University.
Organizations See eSCM-SP.
(eSCM-CL)
eSourcing (Service Strategy) A framework to help IT Service Providers develop

Capability Model their IT Service Management Capabilities from a Service Sourcing
for Service perspective. eSCM-SP was developed by Carnegie Mellon University.
Providers (eSCM- See eSCM-CL.
SP)
Estimation The use of experience to provide an approximate value for a Metric or

Cost. Estimation is also used in Capacity and Availability Management
as the cheapest and least accurate Modelling method.
Evaluation (Service Transition) The Process responsible for assessing a new or

Changed IT Service to ensure that Risks have been managed and to
help determine whether to proceed with the Change.
Evaluation is also used to mean comparing an actual Outcome with the
intended Outcome, or comparing one alternative with another.
Event (Service Operation) A change of state which has significance for the
management of a Configuration Item or IT Service.
The term Event is also used to mean an Alert or notification created by
any IT Service, Configuration Item or Monitoring tool. Events typically
require IT Operations personnel to take actions, and often lead to
Incidents being logged.
Event (Service Operation) The Process responsible for managing Events

Management throughout their Lifecycle. Event Management is one of the main
Activities of IT Operations.
Exception Report A Document containing details of one or more KPIs or other important
targets that have exceeded defined Thresholds. Examples include SLA
targets being missed or about to be missed, and a Performance Metric
indicating a potential Capacity problem.
Expanded (Availability Management) Detailed stages in the Lifecycle of an

Incident Lifecycle Incident. The stages are Detection, Diagnosis, Repair, Recovery,
Restoration. The Expanded Incident Lifecycle is used to help
understand all contributions to the Impact of Incidents and to Plan how
these could be controlled or reduced.
External A Customer who works for a different Business to the IT Service

Customer Provider.
See External Service Provider, Internal Customer.
External Metric to Financial Management
Term Definition
External Metric A Metric that is used to measure the delivery of IT Service to a

Customer. External Metrics are usually defined in SLAs and reported to
Customers.
See Internal Metric.
External Service (Service Strategy) An IT Service Provider which is part of a different

Provider Organisation to their Customer. An IT Service Provider may have both
Internal Customers and External Customers.
See Type III Service Provider.
External Sourcing Synonym for Outsourcing.
Facilities (Service Operation) The Function responsible for managing the

Management physical Environment where the IT Infrastructure is located. Facilities
Management includes all aspects of managing the physical
Environment, for example power and cooling, building Access
Management, and environmental Monitoring.
Failure (Service Operation) Loss of ability to Operate to Specification, or to

deliver the required output. The term Failure may be used when
referring to IT Services, Processes, Activities, Configuration Items etc. A
Failure often causes an Incident.
Failure Modes An approach to assessing the potential Impact of Failures. FMEA

and Effects involves analysing what would happen after Failure of each
Analysis (FMEA) Configuration Item, all the way up to the effect on the Business. FMEA
is often used in Information Security Management and in IT Service
Continuity Planning.
Fast Recovery (Service Design) A Recovery Option which is also known as Hot
Standby. Provision is made to Recover the IT Service in a short period
of time, typically less than 24 hours. Fast Recovery typically uses a
dedicated Fixed Facility with computer Systems, and software
configured ready to run the IT Services. Immediate Recovery may take
up to 24 hours if there is a need to Restore data from Backups.
Fault Synonym for Error.
Fault Tolerance (Service Design) The ability of an IT Service or Configuration Item to

continue to Operate correctly after Failure of a Component part.
See Resilience, Countermeasure.
Fault Tree (Service Design) (Continual Service Improvement) A technique that

Analysis (FTA) can be used to determine the chain of Events that leads to a Problem.
Fault Tree Analysis represents a chain of Events using Boolean notation
in a diagram.
Financial (Service Strategy) The Function and Processes responsible for

Management managing an IT Service Provider's Budgeting, Accounting and Charging
Requirements.
First-line Support to Governance
Term Definition
First-line Support (Service Operation) The first level in a hierarchy of Support Groups
involved in the resolution of Incidents. Each level contains more
specialist skills, or has more time or other Resources.
See Escalation.
Fishbone Synonym for Ishikawa Diagram.

Diagram
Fit for Purpose An informal term used to describe a Process, Configuration Item, IT
Service etc. that is capable of meeting its Objectives or Service Levels.
Being Fit for Purpose requires suitable Design, implementation, Control
and maintenance.
Fixed Cost (Service Strategy) A Cost that does not vary with IT Service usage. For
example the cost of Server hardware.
See Variable Cost.
Fixed Facility (Service Design) A permanent building, available for use when needed
by an IT Service Continuity Plan.
See Recovery Option, Portable Facility.
Follow the Sun (Service Operation) A methodology for using Service Desks and
Support Groups around the world to provide seamless 24 * 7 Service.
Calls, Incidents, Problems and Service Requests are passed between
groups in different time zones.
Fulfilment Performing Activities to meet a need or Requirement. For example by

providing a new IT Service, or meeting a Service Request.
Function A team or group of people and the tools they use to carry out one or
more Processes or Activities. For example the Service Desk.
The term Function also has two other meanings
• An intended purpose of a Configuration Item, Person, Team,
Process, or IT Service. For example one Function of an Email
Service may be to store and forward outgoing mails, one Function
of a Business Process may be to dispatch goods to Customers.
• To perform the intended purpose correctly, "The computer is
Functioning"
Functional (Service Operation) Transferring an Incident, Problem or Change to a

Escalation technical team with a higher level of expertise to assist in an Escalation.
Gap Analysis (Continual Service Improvement) An Activity which compares two

sets of data and identifies the differences. Gap Analysis is commonly
used to compare a set of Requirements with actual delivery.
See Benchmarking.
Governance Ensuring that Policies and Strategy are actually implemented, and that
required Processes are correctly followed. Governance includes
defining Roles and responsibilities, measuring and reporting, and taking
actions to resolve any issues identified.
Gradual Recovery to Incident Management
Term Definition
Gradual Recovery (Service Design) A Recovery Option which is also known as Cold
Standby. Provision is made to Recover the IT Service in a period of time
greater than 72 hours. Gradual Recovery typically uses a Portable or
Fixed Facility that has environmental support and network cabling, but
no computer Systems. The hardware and software are installed as part
of the IT Service Continuity Plan.
Guideline A Document describing Best Practice, that recommends what should be

done. Compliance to a guideline is not normally enforced.
See Standard.
Help Desk (Service Operation) A point of contact for Users to log Incidents. A
Help Desk is usually more technically focussed than a Service Desk and
does not provide a Single Point of Contact for all interaction. The term
Help Desk is often used as a synonym for Service Desk.
Hierarchic (Service Operation) Informing or involving more senior levels of

Escalation management to assist in an Escalation.
High Availability (Service Design) An approach or Design that minimises or hides the
effects of Configuration Item Failure on the Users of an IT Service. High
Availability solutions are Designed to achieve an agreed level of
Availability and make use of techniques such as Fault Tolerance,
Resilience and fast Recovery to reduce the number of Incidents, and
the Impact of Incidents.
Hot Standby Synonym for Fast Recovery or Immediate Recovery.
Identity (Service Operation) A unique name that is used to identify a User,

person or Role. The Identity is used to grant Rights to that User, person,
or Role. Example identities might be the username SmithJ or the Role
"Change manager".
Immediate (Service Design) A Recovery Option which is also known as Hot

Recovery Standby. Provision is made to Recover the IT Service with no loss of
Service. Immediate Recovery typically uses mirroring, load balancing
and split site technologies.
Impact (Service Operation) (Service Transition) A measure of the effect of an

Incident, Problem or Change on Business Processes. Impact is often
based on how Service Levels will be affected. Impact and Urgency are
used to assign Priority.
Incident (Service Operation) An unplanned interruption to an IT Service or a

reduction in the Quality of an IT Service. Failure of a Configuration Item
that has not yet impacted Service is also an Incident. For example
Failure of one disk from a mirror set.
Incident (Service Operation) The Process responsible for managing the

Management Lifecycle of all Incidents. The primary Objective of Incident Management
is to return the IT Service to Users as quickly as possible.
Incident Record to Interactive Voice Response (IVR)
Term Definition
Incident Record (Service Operation) A Record containing the details of an Incident.

Each Incident record documents the Lifecycle of a single Incident.
Indirect Cost (Service Strategy) A Cost of providing an IT Service which cannot be

allocated in full to a specific Customer. For example Cost of providing
shared Servers or software licenses. Also known as Overhead.
See Direct Cost.
Information (Service Design) The Process that ensures the Confidentiality, Integrity
Security and Availability of an Organisation's Assets, information, data and IT
Management Services. Information Security Management usually forms part of an
(ISM) Organisational approach to Security Management which has a wider
scope than the IT Service Provider, and includes handling of paper,
building access, phone calls etc., for the entire Organisation.
Information (Service Design) The framework of Policy, Processes, Standards,

Security Guidelines and tools that ensures an Organisation can achieve its
Management Information Security Management Objectives.
System (ISMS)
Information (Service Design) The Policy that governs the Organisation’s approach
Security Policy to Information Security Management.
Information The use of technology for the storage, communication or processing of

Technology (IT) information. The technology typically includes computers,
telecommunications, Applications and other software. The information
may include Business data, voice, images, video, etc. Information
Technology is often used to support Business Processes through IT
Services.
Infrastructure An IT Service that is not directly used by the Business, but is required
Service by the IT Service Provider so they can provide other IT Services. For
example Directory Services, naming services, or communication
services.
Insourcing Synonym for Internal Sourcing.
Integrity (Service Design) A security principle that ensures data and

Configuration Items are only modified by authorised personnel and
Activities. Integrity considers all possible causes of modification,
including software and hardware Failure, environmental Events, and
human intervention.
Interactive Voice (Service Operation) A form of Automatic Call Distribution that accepts
Response (IVR) User input, such as key presses and spoken commands, to identify the
correct destination for incoming Calls.
Intermediate Recovery to Ishikawa Diagram
Term Definition
Intermediate (Service Design) A Recovery Option which is also known as Warm

Recovery Standby. Provision is made to Recover the IT Service in a period of time
between 24 and 72 hours. Intermediate Recovery typically uses a
shared Portable or Fixed Facility that has computer Systems and
network Components. The hardware and software will need to be
configured, and data will need to be restored, as part of the IT Service
Continuity Plan.
Internal Customer A Customer who works for the same Business as the IT Service
Provider.
See Internal Service Provider, External Customer.
Internal Metric A Metric that is used within the IT Service Provider to Monitor the
Efficiency, Effectiveness or Cost Effectiveness of the IT Service
Provider's internal Processes. Internal Metrics are not normally reported
to the Customer of the IT Service. See External Metric.
Internal Rate of (Service Strategy) A technique used to help make decisions about
Return (IRR) Capital Expenditure. IRR calculates a figure that allows two or more
alternative investments to be compared. A larger IRR indicates a better
investment.
See Net Present Value, Return on Investment.
Internal Service (Service Strategy) An IT Service Provider which is part of the same
Provider Organisation as their Customer. An IT Service Provider may have both
Internal Customers and External Customers.
See Type I Service Provider, Type II Service Provider, Insource.
Internal Sourcing (Service Strategy) Using an Internal Service Provider to manage IT

Services.
See Service Sourcing, Type I Service Provider, Type II Service
Provider.
International The International Organization for Standardization (ISO) is the world's

Organization for largest developer of Standards. ISO is a non-governmental organization
Standardization which is a network of the national standards institutes of 156 countries.
(ISO) Further information about ISO is available from http://www.iso.org/
International See International Organization for Standardization (ISO)

Standards
Organisation
Internet Service An External Service Provider that provides access to the Internet. Most
Provider (ISP) ISPs also provide other IT Services such as web hosting.
Invocation (Service Design) Initiation of the steps defined in a plan. For example
initiating the IT Service Continuity Plan for one or more IT Services.
Ishikawa Diagram (Service Operation) (Continual Service Improvement) A technique

that helps a team to identify all the possible causes of a Problem.
Originally devised by Kaoru Ishikawa, the output of this technique is a
diagram that looks like a fishbone.
ISO 9000 to IT Service
Term Definition
ISO 9000 A generic term that refers to a number of international Standards and
Guidelines for Quality Management Systems.
See http://www.iso.org/ for more information.
See ISO.
ISO 9001 An international Standard for Quality Management Systems.

See ISO 9000, Standard.
ISO/IEC 17799 (Continual Service Improvement) ISO Code of Practice for

Information Security Management.
See Standard.
ISO/IEC 20000 ISO Specification and Code of Practice for IT Service Management.
ISO/IEC 20000 is aligned with ITIL Best Practice.
ISO/IEC 27001 (Service Design) (Continual Service Improvement) ISO Specification

for Information Security Management. The corresponding Code of
Practice is ISO/IEC 17799.
See Standard.
IT Directorate (Continual Service Improvement) Senior Management within a

Service Provider, charged with developing and delivering IT services.
Most commonly used in UK Government departments.
IT Infrastructure All of the hardware, software, networks, facilities etc. that are required to
Develop, Test, deliver, Monitor, Control or support IT Services. The term
IT Infrastructure includes all of the Information Technology but not the
associated people, Processes and documentation.
IT Operations (Service Operation) Activities carried out by IT Operations Control,

including Console Management, Job Scheduling, Backup and Restore,
and Print and Output Management.
IT Operations is also used as a synonym for Service Operation.
IT Operations (Service Operation) The Function responsible for Monitoring and

Control Control of the IT Services and IT Infrastructure.
See Operations Bridge.
IT Operations (Service Operation) The Function within an IT Service Provider which

Management performs the daily Activities needed to manage IT Services and the
supporting IT Infrastructure. IT Operations Management includes IT
Operations Control and Facilities Management.
IT Service A Service provided to one or more Customers by an IT Service

Provider. An IT Service is based on the use of Information Technology
and supports the Customer's Business Processes. An IT Service is
made up from a combination of people, Processes and technology and
should be defined in a Service Level Agreement.
IT Service Continuity Management (ITSCM) to Job Scheduling
Term Definition
IT Service (Service Design) The Process responsible for managing Risks that
Continuity could seriously impact IT Services. ITSCM ensures that the IT Service
Management Provider can always provide minimum agreed Service Levels, by
(ITSCM) reducing the Risk to an acceptable level and Planning for the Recovery
of IT Services. ITSCM should be designed to support Business
Continuity Management.
IT Service (Service Design) A Plan defining the steps required to Recover one or
Continuity Plan more IT Services. The Plan will also identify the triggers for Invocation,
people to be involved, communications etc. The IT Service Continuity
Plan should be part of a Business Continuity Plan.
IT Service The implementation and management of Quality IT Services that meet

Management the needs of the Business. IT Service Management is performed by IT
(ITSM) Service Providers through an appropriate mix of people, Process and
Information Technology.
See Service Management.
IT Service The IT Service Management Forum is an independent Organisation

Management dedicated to promoting a professional approach to IT Service
Forum (itSMF) Management. The itSMF is a not-for-profit membership Organisation
with representation in many countries around the world (itSMF
Chapters). The itSMF and its membership contribute to the
development of ITIL and associated IT Service Management Standards.
See http://www.itsmf.com/ for more information.
IT Service (Service Strategy) A Service Provider that provides IT Services to

Provider Internal Customers or External Customers.
IT Steering Group A formal group that is responsible for ensuring that Business and IT
(ISG) Service Provider Strategies and Plans are closely aligned. An IT
Steering Group includes senior representatives from the Business and
the IT Service Provider.
ITIL A set of Best Practice guidance for IT Service Management. ITIL is

owned by the OGC and consists of a series of publications giving
guidance on the provision of Quality IT Services, and on the Processes
and facilities needed to support them. See http://www.itil.co.uk/ for
more information.
Job Description A Document which defines the Roles, responsibilities, skills and
knowledge required by a particular person. One Job Description can
include multiple Roles, for example the Roles of Configuration Manager
and Change Manager may be carried out by one person.
Job Scheduling (Service Operation) Planning and managing the execution of software
tasks that are required as part of an IT Service. Job Scheduling is
carried out by IT Operations Management, and is often automated using
software tools that run batch or online tasks at specific times of the day,
week, month or year.
Kano Model to Known Error Record
Term Definition
Kano Model (Service Strategy) A Model developed by Noriaki Kano that is used to
help understand Customer preferences. The Kano Model considers
Attributes of an IT Service grouped into areas such as Basic Factors,
Excitement Factors, Performance Factors etc.
Kepner & Tregoe (Service Operation) (Continual Service Improvement) A structured

Analysis approach to Problem solving. The Problem is analysed in terms of what,
where, when and extent. Possible causes are identified. The most
probable cause is tested. The true cause is verified.
Key Performance (Continual Service Improvement) A Metric that is used to help

Indicator (KPI) manage a Process, IT Service or Activity. Many Metrics may be
measured, but only the most important of these are defined as KPIs and
used to actively manage and report on the Process, IT Service or
Activity. KPIs should be selected to ensure that Efficiency,
Effectiveness, and Cost Effectiveness are all managed.
See Critical Success Factor.
Knowledge Base (Service Transition) A logical database containing the data used by the
Service Knowledge Management System.
Knowledge (Service Transition) The Process responsible for gathering, analysing,

Management storing and sharing knowledge and information within an Organisation.
The primary purpose of Knowledge Management is to improve
Efficiency by reducing the need to rediscover knowledge.
See Data-to-Information-to-Knowledge-to-Wisdom, Service Knowledge
Management System.
Known Error (Service Operation) A Problem that has a documented Root Cause
and a Workaround. Known Errors are created and managed throughout
their Lifecycle by Problem Management. Known Errors may also be
identified by Development or Suppliers.
Known Error (Service Operation) A database containing all Known Error Records.
Database (KEDB) This database is created by Problem Management and used by Incident
and Problem Management. The Known Error Database is part of the
Known Error (Service Operation) A Record containing the details of a Known Error.
Record Each Known Error Record documents the Lifecycle of a Known Error,
including the Status, Root Cause and Workaround. In some
implementations a Known Error is documented using additional fields in
a Problem Record.
Lifecycle to Management System
Term Definition
Lifecycle The various stages in the life of an IT Service, Configuration Item,

Incident, Problem, Change etc. The Lifecycle defines the Categories for
Status and the Status transitions that are permitted. For example:
• The Lifecycle of an Application includes Requirements, Design,
Build, Deploy, Operate, Optimise.
• The Expanded Incident Lifecycle includes Detect, Respond,
Diagnose, Repair, Recover, Restore.
• The lifecycle of a Server may include: Ordered, Received, In Test,
Live, Disposed etc.
Line of Service (Service Strategy) A Core Service or Supporting Service that has
(LOS) multiple Service Level Packages. A line of Service is managed by a
Product Manager and each Service Level Package is designed to
support a particular market segment.
Live (Service Transition) Refers to an IT Service or Configuration Item that

is being used to deliver Service to a Customer.
Live Environment (Service Transition) A controlled Environment containing Live

Configuration Items used to deliver IT Services to Customers.
Maintainability (Service Design) A measure of how quickly and Effectively a

Configuration Item or IT Service can be restored to normal working after
a Failure. Maintainability is often measured and reported as MTRS.
Maintainability is also used in the context of Software or IT Service
Development to mean ability to be Changed or Repaired easily.
Major Incident (Service Operation) The highest Category of Impact for an Incident. A
Major Incident results in significant disruption to the Business.
Managed (Service Strategy) A perspective on IT Services which emphasizes the

Services fact that they are managed. The term Managed Services is also used as
a synonym for Outsourced IT Services.
Management Information that is used to support decision making by managers.

Information Management Information is often generated automatically by tools
supporting the various IT Service Management Processes.
Management Information often includes the values of KPIs such as
"Percentage of Changes leading to Incidents", or "first time fix rate".
Management of The OGC methodology for managing Risks. MoR includes all the
Risk (MoR) Activities required to identify and Control the exposure to Risk which
may have an impact on the achievement of an Organisation’s Business
Objectives.
See http://www.m-o-r.org/ for more details.
Management The framework of Policy, Processes and Functions that ensures an

System Organisation can achieve its Objectives.
Manual Workaround to Middleware
Term Definition
Manual A Workaround that requires manual intervention. Manual Workaround is

Workaround also used as the name of a Recovery Option in which The Business
Process Operates without the use of IT Services. This is a temporary
measure and is usually combined with another Recovery Option.
Marginal Cost (Service Strategy) The Cost of continuing to provide the IT Service.
Marginal Cost does not include investment already made, for example
the cost of developing new software and delivering training.
Market Space (Service Strategy) All opportunities that an IT Service Provider could
exploit to meet business needs of Customers. The Market Space
identifies the possible IT Services that an IT Service Provider may wish
to consider delivering.
Maturity (Continual Service Improvement) A measure of the Reliability,

Efficiency and Effectiveness of a Process, Function, Organisation etc.
The most mature Processes and Functions are formally aligned to
Business Objectives and Strategy, and are supported by a framework
for continual improvement.
Maturity Level A named level in a Maturity model such as the Carnegie Mellon
Capability Maturity Model Integration.
Mean Time (Service Design) A Metric for measuring and reporting Reliability.
Between Failures MTBF is the average time that a Configuration Item or IT Service can
(MTBF) perform its agreed Function without interruption. This is measured from
when the CI or IT Service starts working, until it next fails.
Mean Time (Service Design) A Metric used for measuring and reporting Reliability.
Between Service MTBSI is the mean time from when a System or IT Service fails, until it
Incidents (MTBSI) next fails. MTBSI is equal to MTBF + MTRS.
Mean Time To The average time taken to repair a Configuration Item or IT Service after
Repair (MTTR) a Failure. MTTR is measured from when the CI or IT Service fails until it
is Repaired. MTTR does not include the time required to Recover or
Restore. MTTR is sometimes incorrectly used to mean Mean Time to
Restore Service.
Mean Time to The average time taken to Restore a Configuration Item or IT Service
Restore Service after a Failure. MTRS is measured from when the CI or IT Service fails
(MTRS) until it is fully Restored and delivering its normal functionality.
See Maintainability, Mean Time to Repair.
Metric (Continual Service Improvement) Something that is measured and

reported to help manage a Process, IT Service or Activity.
See KPI.
Middleware (Service Design) Software that connects two or more software

Components or Applications. Middleware is usually purchased from a
Supplier, rather than developed within the IT Service Provider.
See Off the Shelf.
Mission Statement to Office of Government Commerce (OGC)
Term Definition
Mission The Mission Statement of an Organisation is a short but complete

Statement description of the overall purpose and intentions of that Organisation. It
states what is to be achieved, but not how this should be done.
Model A representation of a System, Process, IT Service, Configuration Item

etc. that is used to help understand or predict future behaviour.
Modelling A technique that is used to predict the future behaviour of a System,

Process, IT Service, Configuration Item etc. Modelling is commonly
used in Financial Management, Capacity Management and Availability
Management.
Monitor Control (Service Operation) Monitoring the output of a Task, Process, IT

Loop Service or Configuration Item; comparing this output to a predefined
norm; and taking appropriate action based on this comparison.
Monitoring (Service Operation) Repeated observation of a Configuration Item, IT

Service or Process to detect Events and to ensure that the current
status is known.
Near-Shore (Service Strategy) Provision of Services from a country near the

country where the Customer is based. This can be the provision of an IT
Service, or of supporting Functions such as Service Desk.
See On-shore, Off-shore.
Net Present Value (Service Strategy) A technique used to help make decisions about
(NPV) Capital Expenditure. NPV compares cash inflows to cash outflows.
Positive NPV indicates that an investment is worthwhile.
See Internal Rate of Return, Return on Investment.
Notional Charging (Service Strategy) An approach to Charging for IT Services. Charges

to Customers are calculated and Customers are informed of the charge,
but no money is actually transferred. Notional Charging is sometimes
introduced to ensure that Customers are aware of the Costs they incur,
or as a stage during the introduction of real Charging.
Objective The defined purpose or aim of a Process, an Activity or an Organisation

as a whole. Objectives are usually expressed as measurable targets.
The term Objective is also informally used to mean a Requirement.
See Outcome.
Off the Shelf Synonym for Commercial Off the Shelf.
Office of OGC owns the ITIL brand (copyright and trademark). OGC is a UK
Government Government department that supports the delivery of the government's
Commerce (OGC) procurement agenda through its work in collaborative procurement and
in raising levels of procurement skills and capability with departments. It
also provides support for complex public sector projects.
Office of Public Sector Information (OPSI) to Operational Level Agreement (OLA)
Term Definition
Office of Public OPSI license the Crown Copyright material used in the ITIL
Sector publications. They are a UK Government department who provide
Information online access to UK legislation, license the re-use of Crown copyright
(OPSI) material, manage the Information Fair Trader Scheme, maintain the
Government’s Information Asset Register and provide advice and
guidance on official publishing and Crown copyright.
Off-shore (Service Strategy) Provision of Services from a location outside the

country where the Customer is based, often in a different continent. This
can be the provision of an IT Service, or of supporting Functions such
as Service Desk.
See On-shore, Near-shore.
On-shore (Service Strategy) Provision of Services from a location within the

country where the Customer is based. See Off-shore, Near-shore.
Operate To perform as expected. A Process or Configuration Item is said to

Operate if it is delivering the Required outputs. Operate also means to
perform one or more Operations. For example, to Operate a computer is
to do the day-to-day Operations needed for it to perform as expected.
Operation (Service Operation) Day-to-day management of an IT Service, System,

or other Configuration Item. Operation is also used to mean any pre-
defined Activity or Transaction. For example loading a magnetic tape,
accepting money at a point of sale, or reading data from a disk drive.
Operational The lowest of three levels of Planning and delivery (Strategic, Tactical,
Operational). Operational Activities include the day-to-day or short term
Planning or delivery of a Business Process or IT Service Management
Process.
The term Operational is also a synonym for Live.
Operational Cost Cost resulting from running the IT Services. Often repeating payments.
For example staff costs, hardware maintenance and electricity (also
known as "current expenditure" or "revenue expenditure").
See Capital Expenditure.
Operational Synonym for Operational Cost.

Expenditure
(OPEX)
Operational Level (Service Design) (Continual Service Improvement) An Agreement

Agreement (OLA) between an IT Service Provider and another part of the same
Organisation. An OLA supports the IT Service Provider's delivery of IT
Services to Customers. The OLA defines the goods or Services to be
provided and the responsibilities of both parties. For example there
could be an OLA
• between the IT Service Provider and a procurement department to
obtain hardware in agreed times
• between the Service Desk and a Support Group to provide Incident
Resolution in agreed times.
See Service Level Agreement.
Operations Bridge to Pareto Principle
Term Definition
Operations Bridge (Service Operation) A physical location where IT Services and IT

Infrastructure are monitored and managed.
Operations Synonym for IT Operations Control.

Control
Operations Synonym for IT Operations Management.

Management
Opportunity Cost (Service Strategy) A Cost that is used in deciding between investment
choices. Opportunity Cost represents the revenue that would have been
generated by using the Resources in a different way. For example the
Opportunity Cost of purchasing a new Server may include not carrying
out a Service Improvement activity that the money could have been
spent on. Opportunity cost analysis is used as part of a decision making
processes, but is not treated as an actual Cost in any financial
statement.
Optimise Review, Plan and request Changes, in order to obtain the maximum
Efficiency and Effectiveness from a Process, Configuration Item,
Application etc.
Organisation A company, legal entity or other institution. Examples of Organisations

that are not companies include International Standards Organisation or
itSMF. The term Organisation is sometimes used to refer to any entity
which has People, Resources and Budgets. For example a Project or
Business Unit.
Outcome The result of carrying out an Activity; following a Process; delivering an

IT Service etc. The term Outcome is used to refer to intended results, as
well as to actual results.
See Objective.
Outsourcing (Service Strategy) Using an External Service Provider to manage IT

Services.
See Service Sourcing, Type III Service Provider.
Overhead Synonym for Indirect cost
Pain Value (Service Operation) A technique used to help identify the Business
Analysis Impact of one or more Problems. A formula is used to calculate Pain
Value based on the number of Users affected, the duration of the
Downtime, the Impact on each User, and the cost to the Business (if
known).
Pareto Principle (Service Operation) A technique used to prioritise Activities. The

Pareto Principle says that 80% of the value of any Activity is created
with 20% of the effort. Pareto Analysis is also used in Problem
Management to prioritise possible Problem causes for investigation.
Partnership to Plan-Do-Check-Act
Term Definition
Partnership A relationship between two Organisations which involves working

closely together for common goals or mutual benefit. The IT Service
Provider should have a Partnership with the Business, and with Third
Parties who are critical to the delivery of IT Services.
See Value Network.
Passive (Service Operation) Monitoring of a Configuration Item, an IT Service

Monitoring or a Process that relies on an Alert or notification to discover the current
status. See Active Monitoring.
Pattern of (Service Strategy) A Workload profile of one or more Business

Business Activity Activities. Patterns of Business Activity are used to help the IT Service
(PBA) Provider understand and plan for different levels of Business Activity.
See User Profile.
Percentage (Service Design) The amount of time that a Component is busy over a
utilisation given period of time. For example, if a CPU is busy for 1800 seconds in
a one hour period, its utilisation is 50%
Performance A measure of what is achieved or delivered by a System, person, team,

Process, or IT Service.
Performance (Service Strategy) An approach to Organisational Culture that

Anatomy integrates, and actively manages, leadership and strategy, people
development, technology enablement, performance management and
innovation.
Performance (Continual Service Improvement) The Process responsible for day-to-

Management day Capacity Management Activities. These include Monitoring,
Threshold detection, Performance analysis and Tuning, and
implementing Changes related to Performance and Capacity.
Pilot (Service Transition) A limited Deployment of an IT Service, a Release

or a Process to the Live Environment. A Pilot is used to reduce Risk and
to gain User feedback and Acceptance.
See Test, Evaluation.
Plan A detailed proposal which describes the Activities and Resources

needed to achieve an Objective. For example a Plan to implement a
new IT Service or Process. ISO/IEC 20000 requires a Plan for the
management of each IT Service Management Process.
Plan-Do-Check- (Continual Service Improvement) A four stage cycle for Process

Act management, attributed to Edward Deming. Plan-Do-Check-Act is also
called the Deming Cycle.
PLAN: Design or revise Processes that support the IT Services.
DO: Implement the Plan and manage the Processes.
CHECK: Measure the Processes and IT Services, compare with
Objectives and produce reports
ACT: Plan and implement Changes to improve the Processes.
Planned Downtime to Proactive Monitoring
Term Definition
Planned (Service Design) Agreed time when an IT Service will not be available.
Downtime Planned Downtime is often used for maintenance, upgrades and testing.
See Change Window, Downtime.
Planning An Activity responsible for creating one or more Plans. For example,
Capacity Planning.
PMBOK A Project management Standard maintained and published by the

Project Management Institute. PMBOK stands for Project Management
Body of Knowledge. See http://www.pmi.org/ for more information.
See PRINCE2.
Policy Formally documented management expectations and intentions.

Policies are used to direct decisions, and to ensure consistent and
appropriate development and implementation of Processes, Standards,
Roles, Activities, IT Infrastructure etc.
Portable Facility (Service Design) A prefabricated building, or a large vehicle, provided

by a Third Party and moved to a site when needed by an IT Service
Continuity Plan.
See Recovery Option, Fixed Facility.
Post A Review that takes place after a Change or a Project has been
Implementation implemented. A PIR determines if the Change or Project was
Review (PIR) successful, and identifies opportunities for improvement.
Practice A way of working, or a way in which work must be done. Practices can
include Activities, Processes, Functions, Standards and Guidelines.
See Best Practice.
Prerequisite for An Activity that needs to be completed, or a condition that needs to be

Success (PFS) met, to enable successful implementation of a Plan or Process. A PFS
is often an output from one Process that is a required input to another
Process.
Pricing (Service Strategy) The Activity for establishing how much Customers
will be Charged.
PRINCE2 The standard UK government methodology for Project management.

See http://www.ogc.gov.uk/prince2/ for more information.
See PMBOK.
Priority (Service Transition) (Service Operation) A Category used to identify

the relative importance of an Incident, Problem or Change. Priority is
based on Impact and Urgency, and is used to identify required times for
actions to be taken. For example the SLA may state that Priority2
Incidents must be resolved within 12 hours.
Proactive (Service Operation) Monitoring that looks for patterns of Events to

Monitoring predict possible future Failures.
See Reactive Monitoring.
Proactive Problem Management to Production Environment
Term Definition
Proactive (Service Operation) Part of the Problem Management Process. The

Problem Objective of Proactive Problem Management is to identify Problems that
Management might otherwise be missed. Proactive Problem Management analyses
Incident Records, and uses data collected by other IT Service
Management Processes to identify trends or significant Problems.
Problem (Service Operation) A cause of one or more Incidents. The cause is

not usually known at the time a Problem Record is created, and the
Problem Management Process is responsible for further investigation.
Problem (Service Operation) The Process responsible for managing the

Management Lifecycle of all Problems. The primary Objectives of Problem
Management are to prevent Incidents from happening, and to minimise
the Impact of Incidents that cannot be prevented.
Problem Record (Service Operation) A Record containing the details of a Problem.

Each Problem Record documents the Lifecycle of a single Problem.
Procedure A Document containing steps that specify how to achieve an Activity.

Procedures are defined as part of Processes.
See Work Instruction.
Process A structured set of Activities designed to accomplish a specific

Objective. A Process takes one or more defined inputs and turns them
into defined outputs. A Process may include any of the Roles,
responsibilities, tools and management Controls required to reliably
deliver the outputs. A Process may define Policies, Standards,
Guidelines, Activities, and Work Instructions if they are needed.
Process Control The Activity of planning and regulating a Process, with the Objective of
performing the Process in an Effective, Efficient, and consistent manner.
Process Manager A Role responsible for Operational management of a Process. The

Process Manager's responsibilities include Planning and co-ordination
of all Activities required to carry out, monitor and report on the Process.
There may be several Process Managers for one Process, for example
regional Change Managers or IT Service Continuity Managers for each
data centre. 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 Organisations.
Process Owner A Role responsible for ensuring that a Process is Fit for Purpose. The
Process Owner’s responsibilities include sponsorship, Design, Change
Management and continual improvement of the Process and its Metrics.
This Role is often assigned to the same person who carries out the
Process Manager Role, but the two Roles may be separate in larger
Organisations.
Production Synonym for Live Environment.

Environment
Profit Centre to Quick Win
Term Definition
Profit Centre (Service Strategy) A Business Unit which charges for Services
provided. A Profit Centre can be created with the objective of making a
profit, recovering Costs, or running at a loss. An IT Service Provider can
be run as a Cost Centre or a Profit Centre.
pro-forma A template, or example Document containing example data that will be

replaced with the real values when these are available.
Programme A number of Projects and Activities that are planned and managed
together to achieve an overall set of related Objectives and other
Outcomes.
Project A temporary Organisation, with people and other Assets required to

achieve an Objective or other Outcome. Each Project has a Lifecycle
that typically includes initiation, Planning, execution, Closure etc.
Projects are usually managed using a formal methodology such as
PRINCE2.
Projected Service (Service Transition) A Document that identifies the effect of planned
Outage (PSO) Changes, maintenance Activities and Test Plans on agreed Service
Levels.
PRojects IN See PRINCE2

Controlled
Environments
(PRINCE2)
Qualification (Service Transition) An Activity that ensures that IT Infrastructure is

appropriate, and correctly configured, to support an Application or IT
Service.
See Validation.
Quality The ability of a product, Service, or Process to provide the intended

value. For example, a hardware Component can be considered to be of
high Quality if it performs as expected and delivers the required
Reliability. Process Quality also requires an ability to monitor
Effectiveness and Efficiency, and to improve them if necessary.
See Quality Management System.
Quality Assurance (Service Transition) The Process responsible for ensuring that the
(QA) Quality of a product, Service or Process will provide its intended Value.
Quality (Continual Service Improvement) The set of Processes responsible

Management for ensuring that all work carried out by an Organisation is of a suitable
System (QMS) Quality to reliably meet Business Objectives or Service Levels.
See ISO 9000.
Quick Win (Continual Service Improvement) An improvement Activity which is

expected to provide a Return on Investment in a short period of time
with relatively small Cost and effort.
See Pareto Principle.
RACI to Redundancy
Term Definition
RACI (Service Design) (Continual Service Improvement) A Model used to

help define Roles and Responsibilities. RACI stands for Responsible,
Accountable, Consulted and Informed.
See Stakeholder.
Reactive (Service Operation) Monitoring that takes action in response to an

Monitoring Event. For example submitting a batch job when the previous job
completes, or logging an Incident when an Error occurs.
See Proactive Monitoring.
Reciprocal (Service Design) A Recovery Option. An agreement between two

Arrangement Organisations to share resources in an emergency. For example,
Computer Room space or use of a mainframe.
Record A Document containing the results or other output from a Process or

Activity. Records are evidence of the fact that an Activity took place and
may be paper or electronic. For example, an Audit report, an Incident
Record, or the minutes of a meeting.
Recovery (Service Design) (Service Operation) Returning a Configuration Item

or an IT Service to a working state. Recovery of an IT Service often
includes recovering data to a known consistent state. After Recovery,
further steps may be needed before the IT Service can be made
available to the Users (Restoration).
Recovery Option (Service Design) A Strategy for responding to an interruption to

Service. Commonly used Strategies are Do Nothing, Manual
Workaround, Reciprocal Arrangement, Gradual Recovery, Intermediate
Recovery, Fast Recovery, Immediate Recovery. Recovery Options may
make use of dedicated facilities, or Third Party facilities shared by
multiple Businesses.
Recovery Point (Service Operation) The maximum amount of data that may be lost
Objective (RPO) when Service is Restored after an interruption. Recovery Point
Objective is expressed as a length of time before the Failure. For
example a Recovery Point Objective of one day may be supported by
daily Backups, and up to 24 hours of data may be lost. Recovery Point
Objectives for each IT Service should be negotiated, agreed and
documented, and used as Requirements for Service Design and IT
Service Continuity Plans.
Recovery Time (Service Operation) The maximum time allowed for recovery of an IT
Objective (RTO) Service following an interruption. The Service Level to be provided may
be less than normal Service Level Targets. Recovery Time Objectives
for each IT Service should be negotiated, agreed and documented.
See Business Impact Analysis.
Redundancy Synonym for Fault Tolerance.

The term Redundant also has a generic meaning of obsolete, or no
longer needed.
Relationship to Release Window
Term Definition
Relationship A connection or interaction between two people or things. In Business

Relationship Management it is the interaction between the IT Service
Provider and the Business. In Configuration Management it is a link
between two Configuration Items that identifies a dependency or
connection between them. For example Applications may be linked to
the Servers they run on, IT Services have many links to all the CIs that
contribute to them.
Relationship The ISO/IEC 20000 Process group that includes Business Relationship
Processes Management and Supplier Management.
Release (Service Transition) A collection of hardware, software,

documentation, Processes or other Components required to implement
one or more approved Changes to IT Services. The contents of each
Release are managed, Tested, and Deployed as a single entity.
Release and (Service Transition) The Process responsible for both Release
Deployment Management and Deployment.
Management
Release (Service Transition) A naming convention used to uniquely identify a

Identification Release. The Release Identification typically includes a reference to the
Configuration Item and a version number. For example Microsoft Office
2003 SR2.
Release (Service Transition) The Process responsible for Planning, scheduling

Management and controlling the movement of Releases to Test and Live
Environments. The primary Objective of Release Management is to
ensure that the integrity of the Live Environment is protected and that
the correct Components are released. Release Management is part of
the Release and Deployment Management Process.
Release Process The name used by ISO/IEC 20000 for the Process group that includes
Release Management. This group does not include any other
Processes.
Release Process is also used as a synonym for Release Management
Process.
Release Record (Service Transition) A Record in the CMDB that defines the content of
a Release. A Release Record has Relationships with all Configuration
Items that are affected by the Release.
Release Unit (Service Transition) Components of an IT Service that are normally

Released together. A Release Unit typically includes sufficient
Components to perform a useful Function. For example one Release
Unit could be a Desktop PC, including Hardware, Software, Licenses,
Documentation etc. A different Release Unit may be the complete
Payroll Application, including IT Operations Procedures and User
training.
Release Window Synonym for Change Window.

Reliability to Responsiveness
Term Definition
Reliability (Service Design) (Continual Service Improvement) A measure of

how long a Configuration Item or IT Service can perform its agreed
Function without interruption. Usually measured as MTBF or MTBSI.
The term Reliability can also be used to state how likely it is that a
Process, Function etc. will deliver its required outputs.
See Availability.
Remediation (Service Transition) Recovery to a known state after a failed Change

or Release.
Repair (Service Operation) The replacement or correction of a failed

Configuration Item.
Request for (Service Transition) A formal proposal for a Change to be made. An

Change (RFC) RFC includes details of the proposed Change, and may be recorded on
paper or electronically. The term RFC is often misused to mean a
Change Record, or the Change itself.
Request (Service Operation) The Process responsible for managing the

Fulfilment Lifecycle of all Service Requests.
Requirement (Service Design) A formal statement of what is needed. For example a

Service Level Requirement, a Project Requirement or the required
Deliverables for a Process.
See Statement of Requirements.
Resilience (Service Design) The ability of a Configuration Item or IT Service to

resist Failure or to Recover quickly following a Failure. For example, an
armoured cable will resist failure when put under stress.
See Fault Tolerance.
Resolution (Service Operation) Action taken to repair the Root Cause of an

Incident or Problem, or to implement a Workaround.
In ISO/IEC 20000, Resolution Processes is the Process group that
includes Incident and Problem Management.
Resolution The ISO/IEC 20000 Process group that includes Incident Management
Processes and Problem Management.
Resource (Service Strategy) A generic term that includes IT Infrastructure,

people, money or anything else that might help to deliver an IT Service.
Resources are considered to be Assets of an Organisation.
See Capability, Service Asset.
Response Time A measure of the time taken to complete an Operation or Transaction.

Used in Capacity Management as a measure of IT Infrastructure
Performance, and in Incident Management as a measure of the time
taken to answer the phone, or to start Diagnosis.
Responsiveness A measurement of the time taken to respond to something. This could

be Response Time of a Transaction, or the speed with which an IT
Service Provider responds to an Incident or Request for Change etc.
Restoration of Service to Role
Term Definition
Restoration of See Restore.

Service
Restore (Service Operation) Taking action to return an IT Service to the Users

after Repair and Recovery from an Incident. This is the primary
Objective of Incident Management.
Retire (Service Transition) Permanent removal of an IT Service, or other

Configuration Item, from the Live Environment. Retired is a stage in the
Lifecycle of many Configuration Items.
Return on (Service Strategy) (Continual Service Improvement) A measurement

Investment (ROI) of the expected benefit of an investment. In the simplest sense it is the
net profit of an investment divided by the net worth of the assets
invested.
See Net Present Value, Value on Investment.
Return to Normal (Service Design) The phase of an IT Service Continuity Plan during
which full normal operations are resumed. For example, if an alternate
data centre has been in use, then this phase will bring the primary data
centre back into operation, and restore the ability to invoke IT Service
Continuity Plans again.
Review An evaluation of a Change, Problem, Process, Project etc. Reviews are

typically carried out at predefined points in the Lifecycle, and especially
after Closure. The purpose of a Review is to ensure that all Deliverables
have been provided, and to identify opportunities for improvement.
See Post Implementation Review.
Rights (Service Operation) Entitlements, or permissions, granted to a User or

Role. For example the Right to modify particular data, or to authorize a
Change.
Risk A possible Event that could cause harm or loss, or affect the ability to
achieve Objectives. A Risk is measured by the probability of a Threat,
the Vulnerability of the Asset to that Threat, and the Impact it would
have if it occurred.
Risk Assessment The initial steps of Risk Management. Analysing the value of Assets to
the business, identifying Threats to those Assets, and evaluating how
Vulnerable each Asset is to those Threats. Risk Assessment can be
quantitative (based on numerical data) or qualitative.
Risk Management The Process responsible for identifying, assessing and controlling
Risks.
See Risk Assessment.
Role A set of responsibilities, Activities and authorities granted to a person or

team. A Role is defined in a Process. One person or team may have
multiple Roles, for example the Roles of Configuration Manager and
Change Manager may be carried out by a single person.
Rollout to Service Acceptance Criteria (SAC)
Term Definition
Rollout (Service Transition) Synonym for Deployment. Most often used to refer
to complex or phased Deployments or Deployments to multiple
locations.
Root Cause (Service Operation) The underlying or original cause of an Incident or

Problem.
Root Cause (Service Operation) An Activity that identifies the Root Cause of an
Analysis (RCA) Incident or Problem. RCA typically concentrates on IT Infrastructure
failures.
See Service Failure Analysis.
Running Costs Synonym for Operational Costs
Scalability The ability of an IT Service, Process, Configuration Item etc. to perform

its agreed Function when the Workload or Scope changes.
Scope The boundary, or extent, to which a Process, Procedure, Certification,

Contract etc. applies. For example the Scope of Change Management
may include all Live IT Services and related Configuration Items, the
Scope of an ISO/IEC 20000 Certificate may include all IT Services
delivered out of a named data centre.
Second-line (Service Operation) The second level in a hierarchy of Support Groups

Support involved in the resolution of Incidents and investigation of Problems.
Each level contains more specialist skills, or has more time or other
Resources.
Security See Information Security Management
Security Synonym for Information Security Management

Management
Security Policy Synonym for Information Security Policy
Separation of (Service Strategy) An approach to Designing a solution or IT Service

Concerns (SoC) that divides the problem into pieces that can be solved independently.
This approach separates "what" is to be done from "how" it is to be
done.
Server (Service Operation) A computer that is connected to a network and

provides software Functions that are used by other computers.
Service A means of delivering value to Customers by facilitating Outcomes

Customers want to achieve without the ownership of specific Costs and
Risks.
Service (Service Transition) A set of criteria used to ensure that an IT Service

Acceptance meets its functionality and Quality Requirements and that the IT Service
Criteria (SAC) Provider is ready to Operate the new IT Service when it has been
Deployed.
See Acceptance.
Service Analytics to Service Design Package
Term Definition
Service Analytics (Service Strategy) A technique used in the Assessment of the

Business Impact of Incidents. Service Analytics Models the
dependencies between Configuration Items, and the dependencies of IT
Services on Configuration Items.
Service Asset Any Capability or Resource of a Service Provider.

See Asset.
Service Asset and (Service Transition) The Process responsible for both Configuration
Configuration Management and Asset Management.
Management
(SACM)
Service Capacity (Service Design) (Continual Service Improvement) The Activity

Management responsible for understanding the Performance and Capacity of IT
(SCM) Services. The Resources used by each IT Service and the pattern of
usage over time are collected, recorded, and analysed for use in the
Capacity Plan.
See Business Capacity Management, Component Capacity
Management.
Service (Service Design) A database or structured Document with information

Catalogue about all Live IT Services, including those available for Deployment. The
Service Catalogue is the only part of the Service Portfolio published to
Customers, and is used to support the sale and delivery of IT Services.
The Service Catalogue includes information about deliverables, prices,
contact points, ordering and request Processes.
See Contract Portfolio.
Service Continuity Synonym for IT Service Continuity Management.

Management
Service Contract (Service Strategy) A Contract to deliver one or more IT Services. The
term Service Contract is also used to mean any Agreement to deliver IT
Services, whether this is a legal Contract or an SLA.
See Contract Portfolio.
Service Culture A Customer oriented Culture. The major Objectives of a Service Culture
are Customer satisfaction and helping the Customer to achieve their
Business Objectives.
Service Design (Service Design) A stage in the Lifecycle of an IT Service. Service

Design includes a number of Processes and Functions and is the title of
one of the Core ITIL publications.
See Design.
Service Design (Service Design) Document(s) defining all aspects of an IT Service and
Package its Requirements through each stage of its Lifecycle. A Service Design
Package is produced for each new IT Service, major Change, or IT
Service Retirement.
Service Desk to Service Level Package (SLP)
Term Definition
Service Desk (Service Operation) The Single Point of Contact between the Service
Provider and the Users. A typical Service Desk manages Incidents and
Service Requests, and also handles communication with the Users.
Service Failure (Service Design) An Activity that identifies underlying causes of one or
Analysis (SFA) more IT Service interruptions. SFA identifies opportunities to improve
the IT Service Provider's Processes and tools, and not just the IT
Infrastructure. SFA is a time constrained, project-like activity, rather than
an ongoing process of analysis.
See Root Cause Analysis.
Service Hours (Service Design) (Continual Service Improvement) An agreed time

period when a particular IT Service should be Available. For example,
"Monday-Friday 08:00 to 17:00 except public holidays". Service Hours
should be defined in a Service Level Agreement.
Service (Continual Service Improvement) A formal Plan to implement

Improvement Plan improvements to a Process or IT Service.
(SIP)
Service (Service Transition) A set of tools and databases that are used to
Knowledge manage knowledge and information. The SKMS includes the
Management Configuration Management System, as well as other tools and
System (SKMS) databases. The SKMS stores, manages, updates, and presents all
information that an IT Service Provider needs to manage the full
Lifecycle of IT Services.
Service Level Measured and reported achievement against one or more Service Level
Targets. The term Service Level is sometimes used informally to mean
Service Level Target.
Service Level (Service Design) (Continual Service Improvement) An Agreement

Agreement (SLA) between an IT Service Provider and a Customer. The SLA describes
the IT Service, documents Service Level Targets, and specifies the
responsibilities of the IT Service Provider and the Customer. A single
SLA may cover multiple IT Services or multiple Customers.
See Operational Level Agreement.
Service Level (Service Design) (Continual Service Improvement) The Process

Management responsible for negotiating Service Level Agreements, and ensuring that
(SLM) these are met. SLM is responsible for ensuring that all IT Service
Management Processes, Operational Level Agreements, and
Underpinning Contracts, are appropriate for the agreed Service Level
Targets. SLM monitors and reports on Service Levels, and holds regular
Customer reviews.
Service Level (Service Strategy) A defined level of Utility and Warranty for a
Package (SLP) particular Service Package. Each SLP is designed to meet the needs of
a particular Pattern of Business Activity.
See Line of Service.
Service Level Requirement (SLR) to Service Pipeline
Term Definition
Service Level (Service Design) (Continual Service Improvement) A Customer

Requirement Requirement for an aspect of an IT Service. SLRs are based on
(SLR) Business Objectives and are used to negotiate agreed Service Level
Targets.
Service Level (Service Design) (Continual Service Improvement) A commitment

Target that is documented in a Service Level Agreement. Service Level
Targets are based on Service Level Requirements, and are needed to
ensure that the IT Service design is Fit for Purpose. Service Level
Targets should be SMART, and are usually based on KPIs.
Service (Service Operation) The expected time that a Configuration Item will
Maintenance be unavailable due to planned maintenance Activity.
Objective
Service Service Management is a set of specialized organizational capabilities

Management for providing value to customers in the form of services.
Service An approach to IT Service Management that emphasizes the

Management importance of coordination and Control across the various Functions,
Lifecycle Processes, and Systems necessary to manage the full Lifecycle of IT
Services. The Service Management Lifecycle approach considers the
Strategy, Design, Transition, Operation and Continuous Improvement of
IT Services.
Service Manager A manager who is responsible for managing the end-to-end Lifecycle of
one or more IT Services. The term Service Manager is also used to
mean any manager within the IT Service Provider. Most commonly
used to refer to a Business Relationship Manager, a Process Manager,
an Account Manager or a senior manager with responsibility for IT
Services overall.
Service Operation (Service Operation) A stage in the Lifecycle of an IT Service. Service

Operation includes a number of Processes and Functions and is the title
of one of the Core ITIL publications.
See Operation.
Service Owner (Continual Service Improvement) A Role which is accountable for the
delivery of a specific IT Service.
Service Package (Service Strategy) A detailed description of an IT Service that is

available to be delivered to Customers. A Service Package includes a
Service Level Package and one or more Core Services and Supporting
Services.
Service Pipeline (Service Strategy) A database or structured Document listing all IT

Services that are under consideration or Development, but are not yet
available to Customers. The Service Pipeline provides a Business view
of possible future IT Services and is part of the Service Portfolio which
is not normally published to Customers.
Service Portfolio to Service Sourcing
Term Definition
Service Portfolio (Service Strategy) The complete set of Services that are managed by a
Service Provider. The Service Portfolio is used to manage the entire
Lifecycle of all Services, and includes three Categories: Service Pipeline
(proposed or in Development); Service Catalogue (Live or available for
Deployment); and Retired Services.
See Service Portfolio Management, Contract Portfolio.
Service Portfolio (Service Strategy) The Process responsible for managing the Service
Management Portfolio. Service Portfolio Management considers Services in terms of
(SPM) the Business value that they provide.
Service Potential (Service Strategy) The total possible value of the overall Capabilities
and Resources of the IT Service Provider.
Service Provider (Service Strategy) An Organisation supplying Services to one or more

Internal Customers or External Customers. Service Provider is often
used as an abbreviation for IT Service Provider.
See Type I Service Provider, Type II Service Provider, Type III Service
Provider.
Service Provider (Service Strategy) An interface between the IT Service Provider and a
Interface (SPI) User, Customer, Business Process, or a Supplier. Analysis of Service
Provider Interfaces helps to coordinate end-to-end management of IT
Services.
Service (Service Strategy) Analysing the finances and constraints of an IT

Provisioning Service to decide if alternative approaches to Service delivery might
Optimization reduce Costs or improve Quality.
(SPO)
Service Reporting (Continual Service Improvement) The Process responsible for

producing and delivering reports of achievement and trends against
Service Levels. Service Reporting should agree the format, content and
frequency of reports with Customers.
Service Request (Service Operation) A request from a User for information, or advice,
or for a Standard Change or for Access to an IT Service. For example to
reset a password, or to provide standard IT Services for a new User.
Service Requests are usually handled by a Service Desk, and do not
require an RFC to be submitted.
See Request Fulfilment.
Service Sourcing (Service Strategy) The Strategy and approach for deciding whether to
provide a Service internally or to Outsource it to an External Service
Provider. Service Sourcing also means the execution of this Strategy.
Service Sourcing includes:
• Internal Sourcing - Internal or Shared Services using Type I or
Type II Service Providers.
• Traditional Sourcing - Full Service Outsourcing using a Type III
Service Provider.
• Multivendor Sourcing - Prime, Consortium or Selective
Outsourcing using Type III Service Providers.
Service Strategy to Simulation modelling
Term Definition
Service Strategy (Service Strategy) The title of one of the Core ITIL publications.
Service Strategy establishes an overall Strategy for IT Services and for
IT Service Management.
Service Transition (Service Transition) A stage in the Lifecycle of an IT Service. Service

Transition includes a number of Processes and Functions and is the title
of one of the Core ITIL publications.
See Transition.
Service Utility (Service Strategy) The Functionality of an IT Service from the

Customer's perspective. The Business value of an IT Service is created
by the combination of Service Utility (what the Service does) and
Service Warranty (how well it does it).
See Utility.
Service Validation (Service Transition) The Process responsible for Validation and
and Testing Testing of a new or Changed IT Service. Service Validation and Testing
ensures that the IT Service matches its Design Specification and will
meet the needs of the Business.
Service Valuation (Service Strategy) A measurement of the total Cost of delivering an IT

Service, and the total value to the Business of that IT Service. Service
Valuation is used to help the Business and the IT Service Provider
agree on the value of the IT Service.
Service Warranty (Service Strategy) Assurance that an IT Service will meet agreed
Requirements. This may be a formal Agreement such as a Service
Level Agreement or Contract, or may be a marketing message or brand
image. The Business value of an IT Service is created by the
combination of Service Utility (what the Service does) and Service
Warranty (how well it does it).
See Warranty.
Serviceability (Service Design) (Continual Service Improvement) The ability of a

Third Party Supplier to meet the terms of their Contract. This Contract
will include agreed levels of Reliability, Maintainability or Availability for
a Configuration Item.
Shift (Service Operation) A group or team of people who carry out a specific
Role for a fixed period of time. For example there could be four shifts of
IT Operations Control personnel to support an IT Service that is used 24
hours a day.
Simulation (Service Design) (Continual Service Improvement) A technique that

modelling creates a detailed Model to predict the behaviour of a Configuration
Item or IT Service. Simulation Models can be very accurate but are
expensive and time consuming to create. A Simulation Model is often
created by using the actual Configuration Items that are being modelled,
with artificial Workloads or Transactions. They are used in Capacity
Management when accurate results are important. A simulation model
is sometimes called a Performance Benchmark.
Single Point of Contact to Standard
Term Definition
Single Point of (Service Operation) Providing a single consistent way to communicate

Contact with an Organisation or Business Unit. For example, a Single Point of
Contact for an IT Service Provider is usually called a Service Desk.
Single Point of (Service Design) Any Configuration Item that can cause an Incident
Failure (SPOF) when it fails, and for which a Countermeasure has not been
implemented. A SPOF may be a person, or a step in a Process or
Activity, as well as a Component of the IT Infrastructure.
See Failure.
SLAM Chart (Continual Service Improvement) A Service Level Agreement

Monitoring Chart is used to help monitor and report achievements
against Service Level Targets. A SLAM Chart is typically colour coded
to show whether each agreed Service Level Target has been met,
missed, or nearly missed during each of the previous 12 months.
SMART (Service Design) (Continual Service Improvement) An acronym for

helping to remember that targets in Service Level Agreements and
Project Plans should be Specific, Measurable, Achievable, Relevant and
Timely.
Snapshot (Service Transition) The current state of a Configuration as captured

by a discovery tool.
Also used as a synonym for Benchmark.
See Baseline.
Source See Service Sourcing.
Specification A formal definition of Requirements. A Specification may be used to

define technical or Operational Requirements, and may be internal or
external. Many public Standards consist of a Code of Practice and a
Specification. The Specification defines the Standard against which an
Organisation can be Audited.
Stakeholder All people who have an interest in an Organisation, Project, IT Service

etc. Stakeholders may be interested in the Activities, targets,
Resources, or Deliverables. Stakeholders may include Customers,
Partners, employees, shareholders, owners, etc.
See RACI.
Standard A mandatory Requirement. Examples include ISO/IEC 20000 (an

international Standard), an internal security Standard for Unix
configuration, or a government Standard for how financial Records
should be maintained. The term Standard is also used to refer to a
Code of Practice or Specification published by a Standards
Organisation such as ISO or BSI.
See Guideline.
Standard Change to Supplier
Term Definition
Standard Change (Service Transition) A pre-approved Change that is low Risk, relatively
common and follows a Procedure or Work Instruction. For example
password reset or provision of standard equipment to a new employee.
RFCs are not required to implement a Standard Change, and they are
logged and tracked using a different mechanism, such as a Service
Request.
See Change Model.
Standard (Service Operation) Procedures used by IT Operations Management.

Operating
Procedures
(SOP)
Standby (Service Design) Used to refer to Resources that are not required to
deliver the Live IT Services, but are available to support IT Service
Continuity Plans. For example a Standby data centre may be
maintained to support Hot Standby, Warm Standby or Cold Standby
arrangements.
Statement of (Service Design) A Document containing all Requirements for a

requirements product purchase, or a new or changed IT Service.
(SOR) See Terms of Reference.
Status The name of a required field in many types of Record. It shows the
current stage in the Lifecycle of the associated Configuration Item,
Incident, Problem etc.
Status Accounting (Service Transition) The Activity responsible for recording and
reporting the Lifecycle of each Configuration Item.
Storage (Service Operation) The Process responsible for managing the storage
Management and maintenance of data throughout its Lifecycle.
Strategic (Service Strategy) The highest of three levels of Planning and delivery
(Strategic, Tactical, Operational). Strategic Activities include Objective
setting and long term Planning to achieve the overall Vision.
Strategy (Service Strategy) A Strategic Plan designed to achieve defined

Objectives.
Super User (Service Operation) A User who helps other Users, and assists in
communication with the Service Desk or other parts of the IT Service
Provider. Super Users typically provide support for minor Incidents and
training.
Supplier (Service Strategy) (Service Design) A Third Party responsible for

supplying goods or Services that are required to deliver IT services.
Examples of suppliers include commodity hardware and software
vendors, network and telecom providers, and Outsourcing
Organisations.
See Underpinning Contract, Supply Chain.
Supplier and Contract Database (SCD) to Tactical
Term Definition
Supplier and (Service Design) A database or structured Document used to manage

Contract Supplier Contracts throughout their Lifecycle. The SCD contains key
Database (SCD) Attributes of all Contracts with Suppliers, and should be part of the
Supplier (Service Design) The Process responsible for ensuring that all
Management Contracts with Suppliers support the needs of the Business, and that all
Suppliers meet their contractual commitments.
Supply Chain (Service Strategy) The Activities in a Value Chain carried out by
Suppliers. A Supply Chain typically involves multiple Suppliers, each
adding value to the product or Service.
See Value Network.
Support Group (Service Operation) A group of people with technical skills. Support
Groups provide the Technical Support needed by all of the IT Service
See Technical Management.
Support Hours (Service Design) (Service Operation) The times or hours when
support is available to the Users. Typically this is the hours when the
Service Desk is available. Support Hours should be defined in a Service
Level Agreement, and may be different from Service Hours. For
example, Service Hours may be 24 hours a day, but the Support Hours
may be 07:00 to 19:00.
Supporting (Service Strategy) A Service that enables or enhances a Core Service.

Service For example a Directory Service or a Backup Service.
See Service Package.
SWOT Analysis (Continual Service Improvement) A technique that reviews and

analyses the internal strengths and weaknesses of an Organisation and
the external opportunities and threats which it faces SWOT stands for
Strengths, Weaknesses, Opportunities and Threats.
System A number of related things that work together to achieve an overall

Objective. For example:
• A computer System including hardware, software and Applications.
• A management System, including multiple Processes that are
planned and managed together. For example a Quality
Management System.
• A Database Management System or Operating System that
includes many software modules that are designed to perform a
set of related Functions.
System The part of IT Service Management that focuses on the management of

Management IT Infrastructure rather than Process.
Tactical The middle of three levels of Planning and delivery (Strategic, Tactical,
Operational). Tactical Activities include the medium term Plans required
to achieve specific Objectives, typically over a period of weeks to
months.
Tag to Threat
Term Definition
Tag (Service Strategy) A short code used to identify a Category. For

example tags EC1, EC2, EC3 etc. might be used to identify different
Customer outcomes when analysing and comparing Strategies. The
term Tag is also used to refer to the Activity of assigning Tags to things.
Technical (Service Operation) The Function responsible for providing technical

Management skills in support of IT Services and management of the IT Infrastructure.
Technical Management defines the Roles of Support Groups, as well as
the tools, Processes and Procedures required.
Technical (Continual Service Improvement) A technique used in Service

Observation (TO) Improvement, Problem investigation and Availability Management.
Technical support staff meet to monitor the behaviour and Performance
of an IT Service and make recommendations for improvement.
Technical Service Synonym for Infrastructure Service.
Technical Support Synonym for Technical Management.
Tension Metrics (Continual Service Improvement) A set of related Metrics, in which

improvements to one Metric have a negative effect on another. Tension
Metrics are designed to ensure that an appropriate balance is achieved.
Terms of (Service Design) A Document specifying the Requirements, Scope,

Reference (TOR) Deliverables, Resources and schedule for a Project or Activity.
Test (Service Transition) An Activity that verifies that a Configuration Item,

IT Service, Process, etc. meets its Specification or agreed
Requirements.
See Service Validation and Testing, Acceptance.
Test Environment (Service Transition) A controlled Environment used to Test

Configuration Items, Builds, IT Services, Processes etc.
Third Party A person, group, or Business who is not part of the Service Level
Agreement for an IT Service, but is required to ensure successful
delivery of that IT Service. For example a software Supplier, a hardware
maintenance company, or a facilities department. Requirements for
Third Parties are typically specified in Underpinning Contracts or
Operational Level Agreements.
Third-line Support (Service Operation) The third level in a hierarchy of Support Groups
involved in the resolution of Incidents and investigation of Problems.
Each level contains more specialist skills, or has more time or other
Resources.
Threat Anything that might exploit a Vulnerability. Any potential cause of an

Incident can be considered to be a Threat. For example a fire is a
Threat that could exploit the Vulnerability of flammable floor coverings.
This term is commonly used in Information Security Management and IT
Service Continuity Management, but also applies to other areas such as
Problem and Availability Management.
Threshold to Tuning
Term Definition
Threshold The value of a Metric which should cause an Alert to be generated, or

management action to be taken. For example "Priority1 Incident not
solved within 4 hours", "more than 5 soft disk errors in an hour", or
"more than 10 failed changes in a month".
Throughput (Service Design) A measure of the number of Transactions, or other

Operations, performed in a fixed time. For example 5000 emails sent
per hour, or 200 disk I/Os per second.
Total Cost of (Service Strategy) A methodology used to help make investment

Ownership (TCO) decisions. TCO assesses the full Lifecycle Cost of owning a
Configuration Item, not just the initial Cost or purchase price.
See Total Cost of Utilization.
Total Cost of (Service Strategy) A methodology used to help make investment and
Utilization (TCU) Service Sourcing decisions. TCU assesses the full Lifecycle Cost to the
Customer of using an IT Service.
See Total Cost of Ownership.
Total Quality (Continual Service Improvement) A methodology for managing

Management continual Improvement by using a Quality Management System. TQM
(TQM) establishes a Culture involving all people in the Organisation in a
Process of continual monitoring and improvement.
Transaction A discrete Function performed by an IT Service. For example

transferring money from one bank account to another. A single
Transaction may involve numerous additions, deletions and
modifications of data. Either all of these complete successfully or none
of them is carried out.
Transition (Service Transition) A change in state, corresponding to a movement

of an IT Service or other Configuration Item from one Lifecycle status to
the next.
Transition (Service Transition) The Process responsible for Planning all Service
Planning and Transition Processes and co-ordinating the resources that they require.
Support These Service Transition Processes are Change Management, Service
Asset and Configuration Management, Release and Deployment
Management, Service Validation and Testing, Evaluation, and
Knowledge Management.
Trend Analysis (Continual Service Improvement) Analysis of data to identify time

related patterns. Trend Analysis is used in Problem Management to
identify common Failures or fragile Configuration Items, and in Capacity
Management as a Modelling tool to predict future behaviour. It is also
used as a management tool for identifying deficiencies in IT Service
Tuning The Activity responsible for Planning Changes to make the most
efficient use of Resources. Tuning is part of Performance Management,
which also includes Performance Monitoring and implementation of the
required Changes.
Type I Service Provider to Utility
Term Definition
Type I Service (Service Strategy) An Internal Service Provider that is embedded

Provider within a Business Unit. There may be several Type I Service Providers
within an Organisation.
Type II Service (Service Strategy) An Internal Service Provider that provides shared IT
Provider Services to more than one Business Unit.
Type III Service (Service Strategy) A Service Provider that provides IT Services to
Provider External Customers.
Underpinning (Service Design) A Contract between an IT Service Provider and a

Contract (UC) Third Party. The Third Party provides goods or Services that support
delivery of an IT Service to a Customer. The Underpinning Contract
defines targets and responsibilities that are required to meet agreed
Service Level Targets in an SLA.
Unit Cost (Service Strategy) The Cost to the IT Service Provider of providing a
single Component of an IT Service. For example the Cost of a single
desktop PC, or of a single Transaction.
Urgency (Service Transition) (Service Design) A measure of how long it will be

until an Incident, Problem or Change has a significant Impact on the
Business. For example a high Impact Incident may have low Urgency, if
the Impact will not affect the Business until the end of the financial year.
Impact and Urgency are used to assign Priority.
Usability (Service Design) The ease with which an Application, product, or IT

Service can be used. Usability Requirements are often included in a
Statement of Requirements.
Use Case (Service Design) A technique used to define required functionality and
Objectives, and to Design Tests. Use Cases define realistic scenarios
that describe interactions between Users and an IT Service or other
System.
See Change Case.
User A person who uses the IT Service on a day-to-day basis. Users are
distinct from Customers, as some Customers do not use the IT Service
directly.
User Profile (UP) (Service Strategy) A pattern of User demand for IT Services. Each
User Profile includes one or more Patterns of Business Activity.
Utility (Service Strategy) Functionality offered by a Product or Service to

meet a particular need. Utility is often summarised as "what it does".
See Service Utility.
Validation to Verification and Audit
Term Definition
Validation (Service Transition) An Activity that ensures a new or changed IT

Service, Process, Plan, or other Deliverable meets the needs of the
Business. Validation ensures that Business Requirements are met even
though these may have changed since the original Design.
See Verification, Acceptance, Qualification, Service Validation and
Testing.
Value Chain (Service Strategy) A sequence of Processes that creates a product or

Service that is of value to a Customer. Each step of the sequence builds
on the previous steps and contributes to the overall product or Service.
See Value Network.
Value for Money An informal measure of Cost Effectiveness. Value for Money is often
based on a comparison with the Cost of alternatives.
See Cost Benefit Analysis.
Value Network (Service Strategy) A complex set of Relationships between two or

more groups or organisations. Value is generated through exchange of
knowledge, information, goods or Services.
See Value Chain, Partnership.
Value on (Continual Service Improvement) A measurement of the expected

Investment (VOI) benefit of an investment. VOI considers both financial and intangible
benefits.
See Return on Investment.
Variable Cost (Service Strategy) A Cost that depends on how much the IT Service is
used, how many products are produced, the number and type of Users,
or something else that cannot be fixed in advance.
See Variable Cost Dynamics.
Variable Cost (Service Strategy) A technique used to understand how overall Costs
Dynamics are impacted by the many complex variable elements that contribute to
the provision of IT Services.
Variance The difference between a planned value and the actual measured
value. Commonly used in Financial Management, Capacity
Management and Service Level Management, but could apply in any
area where Plans are in place.
Verification (Service Transition) An Activity that ensures a new or changed IT

Service, Process, Plan, or other Deliverable is complete, accurate,
Reliable and matches its Design Specification.
See Validation, Acceptance, Service Validation and Testing.
Verification and (Service Transition) The Activities responsible for ensuring that
Audit information in the CMDB is accurate and that all Configuration Items
have been identified and recorded in the CMDB. Verification includes
routine checks that are part of other Processes. For example, verifying
the serial number of a desktop PC when a User logs an Incident. Audit
is a periodic, formal check.
Version to Workload
Term Definition
Version (Service Transition) A Version is used to identify a specific Baseline of

a Configuration Item. Versions typically use a naming convention that
enables the sequence or date of each Baseline to be identified. For
example Payroll Application Version 3 contains updated functionality
from Version 2.
Vision A description of what the Organisation intends to become in the future.

A Vision is created by senior management and is used to help influence
Culture and Strategic Planning.
Vital Business (Service Design) A Function of a Business Process which is critical to

Function (VBF) the success of the Business. Vital Business Functions are an important
consideration of Business Continuity Management, IT Service
Continuity Management and Availability Management.
Vulnerability A weakness that could be exploited by a Threat. For example an open

firewall port, a password that is never changed, or a flammable carpet.
A missing Control is also considered to be a Vulnerability.
Warm Standby Synonym for Intermediate Recovery.
Warranty (Service Strategy) A promise or guarantee that a product or Service

will meet its agreed Requirements.
See Service Validation and Testing, Service Warranty.
Work in Progress A Status that means Activities have started but are not yet complete. It
(WIP) is commonly used as a Status for Incidents, Problems, Changes etc.
Work Instruction A Document containing detailed instructions that specify exactly what
steps to follow to carry out an Activity. A Work Instruction contains much
more detail than a Procedure and is only created if very detailed
instructions are needed.
Workaround (Service Operation) Reducing or eliminating the Impact of an Incident

or Problem for which a full Resolution is not yet available. For example
by restarting a failed Configuration Item. Workarounds for Problems are
documented in Known Error Records. Workarounds for Incidents that do
not have associated Problem Records are documented in the Incident
Record.
Workload The Resources required to deliver an identifiable part of an IT Service.

Workloads may be Categorised by Users, groups of Users, or Functions
within the IT Service. This is used to assist in analysing and managing
the Capacity, Performance and Utilisation of Configuration Items and IT
Services. The term Workload is sometimes used as a synonym for
Throughput.
ITIL® Glossary v01, 1 May 2006: Acronyms
ACD to ISG
Acronym Term
ACD Automatic Call Distribution
AM Availability Management
AMIS Availability Management Information System
ASP Application Service Provider
BCM Business Capacity Management
BCM Business Continuity Management
BCP Business Continuity Plan
BIA Business Impact Analysis
BRM Business Relationship Manager
BSI British Standards Institution
BSM Business Service Management
CAB Change Advisory Board
CAB/EC Change Advisory Board / Emergency Committee
CAPEX Capital Expenditure
CCM Component Capacity Management
CFIA Component Failure Impact Analysis
CI Configuration Item
CMDB Configuration Management Database
CMIS Capacity Management Information System
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
CMS Configuration Management System
COTS Commercial off the Shelf
CSF Critical Success Factor
CSI Continual Service Improvement
CSIP Continual Service Improvement Programme
CSP Core Service Package
CTI Computer Telephony Integration
DIKW Data-to-Information-to-Knowledge-to-Wisdom
eSCM-CL eSourcing Capability Model for Client Organizations
eSCM-SP eSourcing Capability Model for Service Providers
FMEA Failure Modes and Effects Analysis
FTA Fault Tree Analysis
IRR Internal Rate of Return
ISG IT Steering Group
ISM to SACM
Acronym Term
ISM Information Security Management
ISMS Information Security Management System
ISO International Organization for Standardization
ISP Internet Service Provider
IT Information Technology
ITSCM IT Service Continuity Management
ITSM IT Service Management
itSMF IT Service Management Forum
IVR Interactive Voice Response
KEDB Known Error Database
KPI Key Performance Indicator
LOS Line of Service
MoR Management of Risk
MTBF Mean Time Between Failures
MTBSI Mean Time Between Service Incidents
MTRS Mean Time to Restore Service
MTTR Mean Time to Repair
NPV Net Present Value
OGC Office of Government Commerce
OLA Operational Level Agreement
OPEX Operational Expenditure
OPSI Office of Public Sector Information
PBA Pattern of Business Activity
PFS Prerequisite for Success
PIR Post Implementation Review
PSA Projected Service Availability
QA Quality Assurance
QMS Quality Management System
RCA Root Cause Analysis
RFC Request for Change
ROI Return on Investment
RPO Recovery Point Objective
RTO Recovery Time Objective
SAC Service Acceptance Criteria
SACM Service Asset and Configuration Management
SCD to WIP
Acronym Term
SCD Supplier and Contract Database
SCM Service Capacity Management
SFA Service Failure Analysis
SIP Service Improvement Plan
SKMS Service Knowledge Management System
SLA Service Level Agreement
SLM Service Level Management
SLP Service Level Package
SLR Service Level Requirement
SMO Service Maintenance Objective
SoC Separation of Concerns
SOP Standard Operating Procedures
SOR Statement of requirements
SPI Service Provider Interface
SPM Service Portfolio Management
SPO Service Provisioning Optimization
SPOF Single Point of Failure
TCO Total Cost of Ownership
TCU Total Cost of Utilization
TO Technical Observation
TOR Terms of Reference
TQM Total Quality Management
UC Underpinning Contract
UP User Profile
VBF Vital Business Function
VOI Value on Investment
WIP Work in Progress
Acknowledgements
We would like to express our gratitude and acknowledge the contribution of Stuart Rance and Ashley Hanna of
Hewlett-Packard in the production of this glossary.

Mate ITILv3 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mate ITILv3 PDF

Uploaded by

Copyright:

Available Formats

ITIL V3 Foundation for

Module 1 — Service Management as a Practice

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. i

Module 2 — The Service Lifecycle

Module 3 — Key Principles, Models and Concepts

ii © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Module 4 — Concepts, Processes, Roles and Functions

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. iii

Service Asset and Configuration Management (SACM)...............................149

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. v

Supplier Management ........................................................................... 222

vi © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Module 5 — Service Management Technology and Architecture

Module 6 — ITIL Qualification Scheme

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. vii

viii © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. Intro – 1

Health and safety

Health and safety

Intro – 2 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Logistics and refreshments

Logistics and refreshments

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. Intro – 3

Intro – 4 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. Intro – 5

Intro – 6 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Exam format and details

Exam format and details

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. Intro – 7

Intro – 8 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1–1

Services are a means of delivering value to customers by facilitating outcomes

1–2 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Store how? Online

© Crown Copyright 2007. Reproduced under licence from OGC.

Generalized patterns and specialized instances

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1–3

1–4 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

What is Service Management?

What is Service Management?

• A set of Functions and Processes for managing Services over

Service Management is a set of specialized organizational capabilities for providing

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1–5

The origins of service management are in traditional service businesses such as

1–6 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

IT Infrastructure Library (ITIL)

IT Infrastructure Library (ITIL)

Best Practice and Good Practice

Good Practice as an application of Best Practice

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1–7

Good Practice as in input into Best Practice

1–8 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Functions, Roles and Processes (1 of 2)

Functions, Roles and Processes (1 of 2)

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1–9

1 – 10 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

Functions, Roles and Processes (2 of 2)

Functions, Roles and Processes (2 of 2)

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1 – 11

A process model enables understanding and helps to articulate the distinctive

1 – 12 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

HF421S B.01 © 2007 Hewlett-Packard Development Company, L.P. 1 – 13

1 – 14 © 2007 Hewlett-Packard Development Company, L.P. HF421S B.01

How do we capture value for our stakeholders?

Improved IT governance: assist with the implementation and communication of a

People. Regardless of what services, processes and technology are managed,