ITIL V3 Foundations V3

ITIL V3 Foundations V3
ITIL
Foundations V3
ITIL V3 Foundations V3
ITIL V3 Foundations
Index
ITIL V3 Foundations
ITIL V3 Foundations
Unit Title Page
1 Introduction 8
2 Service Management as a Practice 16
3 The Service Lifecycle 24
4 Service Strategy 30
5 Service Delivery 51
6 Service Transition 102
7 Service Operation 140
8 Continual Service Improvement 194
© Copyright 2009, IBM Brasil

Page: - 1 -
ITIL V3 Foundations

Page - 2 -
ITIL V3 Foundations
ITIL FOUNDATIONS V3
Renata Arruda (renatana@br.ibm.com)

Rosemeire Oikawa (roikawa@br.ibm.com)
Service Management Competency
© 2009 IBM Corporation

Page: - 3 -
ITIL V3 Foundations
Unit 1 – Introduction
History of ITIL
Why ITIL is important?
ITIL v2 Structure
ITIL v3 structure
ITIL v3 Qualification scheme
2 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

Page - 4 -
ITIL V3 Foundations
Managers
Set Environmental
Management
History of ITIL Computer Software Set

Version 1 Operations Support
Set Set
Environmental
Office Strategy Set
The British government commissioned a Environment
Set
study to find out “what is the best way to
Service
align IT with business objectives, lower Delivery
Set
Networks
Set
Service
Support
Set
costs and improve quality.” Results
published in 40+ books as the Information
Technology Infrastructure Library (ITIL) Version 2
Planning to implement service management
Service management
The technology
The business
The ICT
Revisions between 2000 and 2004 resulted business
perspective
Service support
Service delivery
Infrastructure
management
in Version 2 of ITIL® as a consolidated Software asset

management
Security
management
framework for IT Service Management Application management
Version 3 released in 2007 establishes a

Version 3
lifecycle approach to IT Service
Management

Page: - 5 -
ITIL V3 Foundations
Why ITIL is important?

Key ITIL® Benefits:
• Lower TCO
Service
• Redirect Operational Costs to
Operations Innovation
Service
Operations • Improve Service Quality
Portfolio • Improve Predictability of IT Costs
Service and Chargebacks
$
Management
Portfolio
Management • Facilitates Outtasking /
Outsourcing Operations
• Connect all the pieces of
Solution systems management
Solution Development • Represents best practices in the
Development and Innovation industry
and Innovation • Vendor neutral
• Consistent concepts and
terminology
Current Capability Optimized Capability
ITIL® services are the key to understanding how well IT is being utilized and the extent to which
the IT function is meeting its service level commitments.
ITIL is focused on improving service quality to the customer. Customers who adopt the ITIL
framework can expect to see improved alignment of IT with the business, a long-term
reduction in the cost of IT services, and better service quality and responsiveness.
Customers should see a reduction in system outages as proactive planning and quality
measures are implemented, and they should be able to implement IT infrastructure changes
more quickly to support new business requirements. Customer satisfaction should increase
because service providers will understand what is expected of them, based on business
needs. Support services should become more competitive.
Service providers will also benefit from the adoption of ITIL. Service providers should see
improvements in service delivery because they will have a single definable, repeatable,
scalable, and consistent set of IT processes. Roles and responsibilities will be properly
aligned and understood.
Communications between IT departments should improve because the linkages between

processes will be documented and understood. Service providers should see better resource
utilization and resources will be allocated based on business demands. Staff will be more
professional and motivated because skill requirements and capabilities, along with job
expectations, are better understood.

Page - 6 -
ITIL V3 Foundations
ITIL Implementation
Adopt and Adapt

Adopt ITIL as a common language and reference point for IT Service
Management best practices and key concepts
Adapt ITIL best practices to achieve business objectives specific to each
company
ITIL describes what needs to be done but not how it should be done. ITIL does not claim to
be a comprehensive description of everything within IT, but IT management “best practices”
observed and accepted in the industry.
ITIL does not define:

• Every role, job, or organization design
• Every tool, every tool requirement, every required customization
• Every process, procedure, and task required to be implemented

Page: - 7 -
ITIL V3 Foundations
ITIL V2
Planning to Implement Service

Service Management
The Technology
IT Service Management ICT
The Business
Infrastructure
The Service
Service Management
Business
Support
Support (Information &
Perspective
Service
Service Communication
Technology)
Delivery
Delivery
Security
Security
Management
Management
Applications Management

Page - 8 -
ITIL V3 Foundations
ITIL V3 represents a significant milestone in

the evolution of service management
The initial five books should be available on 30 May 2007

(in English – translation work has begun)
The release of ITIL v3 should further accelerate interest in and adoption of
leading practices for service management
IBM strongly supports the continued advancement of service management
best practice
ITIL V3 represents a significant milestone in the evolution of service management

• Introduces the Service Lifecycle
• Bring more management disciplines to the attention of the professional service
manager
• Adds new service management concepts to ITIL
• Emphasises the need for integration
• Updates and integrates ITIL v2 content

Page: - 9 -
ITIL V3 Foundations
ITIL V3 Service Lifecycle

Governance Methods
St
s an
ill da
Sk rd
& s
Al
d ge Continual Service ig
le nm
Improvement
ow en
Kn t
Service
Ca
Design
se
s
opic
Stu
yT
die
Service
cialt
s
Strategies
Spe
Templates
ITIL
Service
Operation
Ex
Co Imp
ec
nt r ov
Service
in
uti
en ice
ua eme
ity
Transition
ve
em erv
l S nt
bil
Int
ov S
erv
ala
pr al
ro
Im tinu
i ce
du
Sc
cti
n
Co
on
s
St in
ud W
y ic k
Ai
d Qu
s
Qualifications
ITIL Publications Structure

Core
Introduction to the ITIL Service Lifecycle
Five books
Service Strategy (SS)
Service Design (SD)
Service Transition (ST)
Service Operation (SO)
Continual Service Improvement (CSI)
Complementary Publications
Support for particular market sector or technology
Web
Value added products, process maps, templates, studies

Page - 10 -
ITIL V3 Foundations
ITIL Qualification Scheme
Master
ITIL Expert
V3
V3
Manager Practitioner
Bridge Managing through the Lifecycle 5pts Bridge
5 pts 5pts
3pts per module 4pts per module
PP OS RC SO
&O &A &V &A
V2
Service Service Capability Modules V2 Practitioners
Manager
17 pts Cluster 3.5pts
Single 2pts
ITIL Foundation for Service Management 2pts
V3 Foundation
Bridge 0,5pts
V2 Foundation
Certificate
1.5 pts

Page: - 11 -
ITIL V3 Foundations
Unit 2 - Service Management as a Practice
Service Management
Service
Process
Role
Function

Page - 12 -
ITIL V3 Foundations
What is a Service
Services are a ‘means of delivering value to customers by

facilitating outcomes customers want to achieve, without
the ownership of specific costs and risks’.
Value
Utility Warranty Creation
‘What the Customer gets’ ‘How is it delivered’ The basis of
differentiation in the
Market Space
Services are a means of delivering value to customers by facilitating outcomes customers

want to achieve, without the ownership of specific costs and risks. Services facilitate
outcomes by enhancing the performance of associated tasks and reducing the effect of
constraints. The result is an increase in the
From the customer’s perspective, value consists of two primary elements: utility or fitness for
purpose and warranty or fitness for use.
Utility is perceived by the customer from the attributes of the service that have a positive
effect on the performance of 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.

Page: - 13 -
ITIL V3 Foundations
Definition of Service Management
Service Management is a set of specialized organizational capabilities

for providing value to customers in the form of services.
Intangible nature of the output

Demand is tightly coupled with customer’s assets
High-level of contact for producers and consumers of services
The perishable nature of service output
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 capabilities are influenced by the following challenges that distinguish
services from other systems of value creation such as manufacturing, mining and
agriculture:
• Intangible nature of the output and intermediate products of service processes: difficult to
measure, control, and validate (or prove).
• Demand is tightly coupled with customer’s assets: users and other customer assets such
as processes, applications, documents and transactions arrive with demand and
stimulate service production.
• High-level of contact for producers and consumers of services: little or no buffer between
the customer, the front-office and back-office.

Page - 14 -
ITIL V3 Foundations
• The perishable nature of service output and service capacity: there is value for the
customer in receiving assurance that the service will continue to be supplied with
consistent quality. Providers need to secure a steady supply of demand from customers.
What is a 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.
Main characteristics of processes:

Measurable
Specific results
Customers
Responds to a specific event
Business outcomes are produced by business processes governed by objectives, policies

and constraints. The processes are supported by resources including people, knowledge,
applications and infrastructure. Workflow coordinates the execution of tasks and flow of
control between resources, and intervening action to ensure adequate performance and
desired outcomes. Business processes are particularly important from a service
management perspective. They apply the organization’s cumulative knowledge and
experience to the achievement of a particular outcome.
Processes are strategic assets when they create competitive advantage and market
differentiation. As a result, business processes define many of the challenges faced by
service management. The nature and dynamics of the relationship between business
processes and IT best explains this.
Processes that provide transformation towards a goal, and utilize feedback for self-
reinforcing and self-corrective action, function as closed-loop systems. It is
important to consider the entire process or how one process fits into another. Process
definitions describe actions, dependencies and sequence.
Processes have the following characteristics:

Page: - 15 -
ITIL V3 Foundations
• 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.
• 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.

Page - 16 -
ITIL V3 Foundations
ITIL Process Model
In the ITIL process model, data enters the process, is processed, and then the output is
measured and reviewed. A process is always organized around a goal. By defining 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. To discover whether or not activities are contributing to the business goal of
the process, measurements must be made on a regular basis. Measuring allows
comparison between what has actually been done and what the organization set out to do.
Process improvements can then be considered and implemented.

Page: - 17 -
ITIL V3 Foundations
What is a Role
A set of responsibilities defined in a Process and assigned to a person or team.

One person or team may have multiple Roles, for example the Roles of
Configuration Manager and Change Manager be carried out by a single person.
Important roles of processes:
• Process Owner
• Process Manager
• Process Operatives
Roles of processes:
• Process Owner Role: Responsible for the process goal and the results of the
process. The “What”.
• Process Manager Role: Responsible for the design, and management of the
process. Reports the process results to the process owner. The “How”.
• Process Operatives Role: Responsible for defined activities within the process.
These activities are reported to the process manager. The “Who”.

Page - 18 -
ITIL V3 Foundations
What is a Function
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 means of structuring organizations so as 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.

Page: - 19 -
ITIL V3 Foundations
Unit 3 - The Service Lifecycle
Service Lifecycle

Page - 20 -
ITIL V3 Foundations
ITIL v3
•Service Strategy provides guidance on how to design, develop and implement IT services
as strategic assets
•Service Design provides guidance for the design and development of services and service
management processes
•Service Transition provides guidance for the improvement of capabilities and transitioning
services into operations
•Service Transition introduces the concept of the Service Knowledge Management System
•Service Operation provides guidance on service delivery and support so as to ensure value
for the customer and service provider
•Continual Service Improvement provides guidance on creating value for customers through
better service management
The ITIL library is a set of books that describe internationally accepted best practices for IT
service management. These include the following practices:
• A process-based approach to IT service management

• A common language for IT service management
• A framework that is independent of organizational structures, architectures, or
technologies
The five volumes that makeup the ITIL Lifecycle are:

• ITIL Service Strategy
• ITIL Service Design
• ITIL Service Transition
• ITIL Service Operation
• ITIL Continual Service Improvement
Each book addresses capabilities having direct impact on the performance of a service
provider. In this course, you will notice that the structure of the ITIL core is in the form of a
lifecycle. This ITIL core is expected to provide structure, stability, and strength to service
management capabilities with durable principles, methods, and tools.
The best practices guidance in ITIL can be adapted for changes used in various business
environments and organizational strategies.

Page: - 21 -
ITIL V3 Foundations
Service Lifecycle
Strategy
Business
Need
Improvement Design
Requirements
Definition
Design Evaluation
Optimization
Develop
Procurement
Build & Test
Operation
Deployment
Operation
Retirement
Transition
The service management lifecycle is an approach that emphasizes coordination, integration,

and control across processes, functions, and systems that is necessary to manage IT
services. The service management lifecycle includes service strategy, design, transition,
operation and continuous improvement stages that correspond to the 5 core ITIL
publications.
Its important to note that although each of the 26 processes are identified within one book of
the lifecycle, they may be applied at across the service management lifecycle. So for
example: Service Level management is described in the service design book where it sets
the targets that are the design points for a service. During operation service levels are
monitored and responded to, and it is also applied during continual service improvement to
ensure that service levels are attained.
The ITIL framework also describes the high-level integration of processes. For example,
service management provides inputs to incident management for the prioritization of
incidents and receives information from the Service Measurement and reporting process to
understand if service levels are being attained..
It is important to understand that the service management lifecycle is not quite the same as
the outsourcing lifecycle. In it service management when we are in transition, we are
moving a new or changed service into a production environment using change and release
management. In outsourcing transition is moving control of a customer’s infrastructure to a
service provider. So for example, its setting up how change management will be performed
rather than performing actual change management. This is a very important distinction to
think about when you are talking to customers about ITIL.

Page - 22 -
ITIL V3 Foundations
ITIL® v3 Service Lifecycle
Continual
Strategy Design Transition Operation Improvement
Transition Planning & 7-step Improvement

Strategy Generation Service Catalog Mgmt Event Mgmt
Support Process
IT Financial Management Service Level Mgmt Change Management Incident Mgmt Service Measurement
Service Asset and

Service Portfolio Mgmt Capacity Mgmt Request Fulfillment Service Reporting
Configuration Management
Demand Management Availability Mgmt Release & Deployment Problem Mgmt
Service Testing and

IT Service Continuity Mgmt Access Mgmt
Validation
Information Security Mgmt Evaluation Service Desk
Technology
Supplier Mgmt Knowledge Management
Management
Application
Management
Processes IT Operations
Management
Functions Gray box=ITIL® v2 Facilities

Management
IT shows the 5 books in ITIL® V3 and the 26 processes and 5 functions. A function is a
group of people and the the tools they use to carry our a process or activity. For those of
you familiar with ITIL® v2 those processes are marked in gray. ITIL® v3 did not change
those processes significantly from ITIL® v2. The Blue boxes at the top are the ITIL® V3
books.

Page: - 23 -
ITIL V3 Foundations
The ITIL V3 processes may span more than one phase of the
service lifecycle
Continual
Owner
Service Service Service
Governance Processes Strategy
Service Design
Transition Operation
Service
Improvement
Service Measurement CSI
Service Reporting CSI
Service Improvement CSI
Demand Management SS
Strategy Generation SS
Service Portfolio Management SS
IT Financial Management SS

Page - 24 -
ITIL V3 Foundations
The ITIL V3 processes may span more than one phase of the
service lifecycle
Service Continual
Owner
Service Service
Operational Processes Strategy
Service Design
Transition
Operation Service
Improvement
Service Catalogue Management SD
Service Level Management SD
Capacity Management SD
Availability Management SD
Service Continuity Management SD
Information Security Management SD
Supplier Management SD
Transition Planning and Support ST
Change Management ST
Service Asset and Configuration Management ST
Release and Deployment Management ST
Service Validation and Testing ST
Evaluation ST >>
Knowledge Management ST
Event Management SO
Incident Management SO
Request Fulfilment SO
Problem Management SO
Operation Management SO <<

Page: - 25 -
ITIL V3 Foundations
Unit 4 – Service Strategy
Goal
Basic concepts
Main Activities
Processes

Page - 26 -
ITIL V3 Foundations
Continual

Support Process
Service Asset and

Service Testing and

Validation
Technology
Management
Application
Management
Management
Functions
Facilities
Management

Page: - 27 -
ITIL V3 Foundations
Service Strategy Goal
Definition of a Service Strategy

– Strategic Objectives
– Direction for Growth
– Prioritization of Investments
Deliverables
– Service Portfolio
– Requirements for the Service Design, Service Transition, and Service
Operation Phases.
Key purpose: think about WHY, before HOW
The goal of Service Strategy is to specify the strategic objectives, give overall directions,
develop policies and plans and allocate resources to implement the policies and plans to
achieve the organization's objectives. The strategy objectives provide direction for growth,
prioritize investments and define outcomes against which the effectiveness of the Services
can be measured. It is critical for a Business to understand why they are performing various
actions before thinking about how to actually perform them.
In order to elaborate the best Service Strategy, every IT organization needs to understand
how:
• To provide value to their Customers
• To differentiate themselves from others providers
The objective of this strategy module is to give insights on defining a Service Strategy based
on:
• A better understanding of the Customers of the IT organization
• The opportunities in terms of Services that the IT organization can offer to its Customers
• Defining strategic objectives (which represent the results expected from pursuing the
strategies)
• The deliverables needed to implement the strategy, such as the Service Portfolio and
Service Catalogue, and the requirements for the Service Design, Service Transition and
Service Operation cycles
As Business evolves constantly, any Service Strategy should be revised regularly (annually)
to check if the strategy is still aligned with the needs and direction of the Business.

Page - 28 -
ITIL V3 Foundations

Page: - 29 -
ITIL V3 Foundations
Basic Concepts
Service Value = Utility + Warranty
Performance supported? True / False

OR
Constraints removed?
Fit for purpose?
VALUE CREATED
AND
Available enough? True / False
Fit for use?
Capacity enough?
AND
True / False
Continuous enough?
Secure enough?
Value of a service: From the Customer’s perspective, value has two aspects:
• Fitness for purpose, which is utility
• Fitness for use, which is the warranty
Utility of a service: Utility is what the Customer gets. It is derived from the attributes of a
service that have a positive effect on performance or desired outcomes
Removal or relaxation of constraints on performance can also be a positive effect
Utility increases the performance average
Warranty of a service: Warranty is the assurance that some products or services will be
provided, and the way they are provided will meet certain specifications e.g. available when
needed, in sufficient capacity and magnitude, and dependably in terms of continuity and
security
Warranty reduces the performance variation

Page - 30 -
ITIL V3 Foundations
Basis for Value Creation
Assets:
Fonte: Livro ITIL Service Strategy
Assets: Any Resource or Capability. Assets of a Service Provider including anything that
could contribute to the delivery of a Service. Assets can be one of the following types:
Management, Organization, Process, Knowledge, People, Information, Applications,
Infrastructure, and Financial Capital
Resources are direct inputs for production. Management, organization, people, and
knowledge are used to transform resources.
Capabilities represent an organization’s ability to coordinate, control, and deploy resources

to produce value. They are typically experience-driven, knowledge-intensive, information
based, and firmly embedded within an organization’s people, systems, processes and
technologies. It is relatively easy to acquire resources compared to capabilities.
The development of distinctive capabilities is enhanced by the breadth and depth of

experience gained from the number and variety of customers, market spaces, contracts, and
services. Experience is similarly enriched from solving problems, handling situations,
managing risks, and analysing failures. For example, the combination of experience in a
market space, reputation among customers, long- term contracts, subject matter experts,
mature processes, and infrastructure in key locations, results in distinctive capabilities
difficult for alternatives to offer. This assumes the organization captures knowledge and
feeds it back into its management systems and processes. Investments in learning
capabilities are particularly important for service providers for the development of strategic
assets.
Service providers need to develop distinctive capabilities to retain customers with value
propositions that are hard for competitors to duplicate. For example, two service providers

Page: - 31 -
ITIL V3 Foundations
may have similar resources such as applications, infrastructure, and access to finance. Their
capabilities, however, differ in terms of management systems, organization structure,
processes, and knowledge assets.
This difference is reflected in actual performance. Capabilities by themselves cannot

produce value without adequate and appropriate resources. The productive capacity of a
service provider is dependent on the resources under its control. Capabilities are used to
develop, deploy and coordinate this productive capacity. For example, capabilities such as
Capacity Management and Availability Management are used to manage the performance
and utilization of processes, applications and infrastructure, ensuring service levels are
effectively delivered.

Page - 32 -
ITIL V3 Foundations
Value Creation
Source: Livro ITIL Service Strategy

Page: - 33 -
ITIL V3 Foundations
Main Activities of Service Strategy
Define Market Develop Develop Prepare

Space offerings Strategic Asset for execution
There are four main activities in Service Strategy
– Define the market space and understand the customer

– Develop the offerings
– Develop the strategic assets
– Prepare for execution
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.

Page - 34 -
ITIL V3 Foundations
Define Market Space and Understand the Customer

Define Develop Prepare
Develop
Market Strategic for
offerings
Space Asset execution
Develop service strategies

Differentiate services from the
competition Strategy
for Service
Use existing opportunities: customer
Strategy
that are not happy represent
opportunities for services to be offered
as solutions
Use new opportunities: new
opportunities emerge when changes in Service for
Service
Strategy
the business environment cause a
previously well-supported customer to
be poorly supported
Services and strategy

Organizations have an interest in strategy within the context of service management in two
distinct but related perspectives. There are strategies for services and there are services for
strategies (Figure 4.1). From one perspective, strategies are developed for services offered.
Providers differentiate their services from competing alternatives available to customers.
From the other perspective, service management is a competence for offering services as
part of a business strategy. A software vendor may decide to offer software as a service. It
combines its capabilities in software development with new capabilities in service
management.
Understand the customer

Organizations strive to achieve business objectives using whatever assets they have at
hand, subject to various constraints. Constraints include costs and risks attributable to
complexity, uncertainty and conflicts in the business environment. The value-creating
potential of the business depends on the performance of business assets. Assets must
perform well at their full potential. The assets may be owned by the business or available for
use from others under various types of financial arrangements.
Understand the opportunities

Customers own and operate configurations of assets to create value for their own
customers. The assets are the means of achieving outcomes that enable or enhance value
creation. For example, for a lending bank value is created by the outcome of processing a
loan application on time. Customers receiving the loan will have access to the required
financial capital and the lender benefits from the onset and accrual of interest. The lending
process is therefore a business asset whose performance leads to specific business
outcomes.

Page: - 35 -
ITIL V3 Foundations
Develop the Offerings

Develop
offerings
Identify opportunities of services

– Services are a means of delivering value to customers by facilitating
outcomes customers need to achieve without owning specific costs
and risks.
Understand the market space

– A market space is defined by a set of business outcomes, which can
be facilitated by a service. The opportunity to facilitate those outcomes
defines a market space.
Market space
A market space is defined by a set of business outcomes, which can be facilitated by a
service. The opportunity to facilitate those outcomes defines a market space. The following
are examples of business outcomes that can be the bases of one or more market spaces.
• Sales teams are productive with sales management system on wireless computers
• E-commerce website is linked to the warehouse management system
• Key business applications are monitored and secure
• Loan officers have faster access to information required on loan applicants
• Online bill payment service offers more options for shoppers to pay
• Business continuity is assured.
Each of the conditions is related to one or more categories of customer assets, such as
people, infrastructure, information, accounts receivables and purchase orders, and can then
be linked to the services that make them possible. Each condition can be met through
multiple ways. Customers will prefer the one that means lower costs and risks. Service
providers create these conditions through the services they deliver and thereby provide
support for customers to achieve specific business outcomes.
A market space therefore represents a set of opportunities for service providers to deliver
value to a customer’s business through one or more services. This approach has definite
value for service providers in building strong relationships with customers. Customers often
express dissatisfaction with a service provider even when terms and conditions of service

Page - 36 -
ITIL V3 Foundations
level agreements (SLAs) are fulfilled. Often it is not clear how services create value for
customers. Services are often defined in the terms of resources made available for use by
customers. Service definitions lack clarity on the context in which such resources are useful,
and the business outcomes that justify the expense of a service from a customer’s
perspective. This problem leads to poor designs, ineffective operation and lackluster
performance in service contracts. Service improvements are difficult when it is not clear
where improvements are truly required. Customers can understand and appreciate
improvements only within the context of their own business assets, performances and
outcomes. A proper definition of services takes into account the context in which customers
perceive value from the services.

Page: - 37 -
ITIL V3 Foundations
Develop Strategic Assets

Develop
offerings
Strategic Assets
– Too meet the needs of future opportunities, Service Management must

further invest in assets such as Process, Knowledge, People,
Applications, and Infrastructure
– Service Management as strategic asset identifies the key relationships

and interactions to have better visibility and control over the systems
and processes they operate
Service providers should treat service management as a strategic asset and entrust it with
challenges and opportunities in terms of customers, services, and contracts to support.
Investments made in trusted assets are less risky because they have the capability to deliver
consistently time and again. Service management begins with capabilities that coordinate
and control resources to support a catalogue of services. Challenges are overcome in
achieving progressively higher service levels. There is mutual reinforcement between the
two. Capabilities and resources are adjusted until the goal is reached. Customers perceive
demonstrated value from the service provider. Customers perceive benefits in a continued
relationship, and entrust the provider with the business of increasing value and also adding
new customers and market spaces to the realm of possibilities. This justifies further
investments in service management in terms of capabilities and resources, which have a
tendency to reinforce each other.
Stakeholders may initially trust the provider with low-value contracts or non-critical services.
Service management responds by delivering the performance expected of a strategic asset.
The performance is rewarded with contract renewals, new services, and customers, which
together represent a larger value of business. To handle this increase in value, service
management must invest further in assets such as process, knowledge, people, applications
and infrastructure. Successful learning and growth enables commitments of higher service
levels as service management gets conditioned to handle bigger challenges.

Page - 38 -
ITIL V3 Foundations
Prepare for Execution

Develop
offerings
To specify the Service Portfolio (and the Service Catalogue)

To specify the requirements needed for the Service Design, Service
Transition and Service Operation phases.
This stage contains the following steps:
Strategic assessment: In crafting a service strategy, a provider should first take a careful
look at what it does already. It is likely there already exists a core of differentiation. An
established service provider frequently lacks an understanding of its own unique
differentiators.
Setting objectives: Objectives represent the results expected from pursuing strategies,
while strategies represent the actions to be taken to accomplish objectives. Clear objectives
provide for consistent decision making, minimizing later conflicts. They set forth priorities and
serve as standards. Organizations should avoid the following means of ‘not managing by
objectives’.
Aligning service assets with customer outcomes: Service providers must manage assets
much in the same manner as their customers. Service assets are coordinated, controlled,
and deployed in a manner that maximizes the value to customers while minimizing risks and
costs for the provider. For example, a messaging service such as wireless email increases
the performance of one of the most critical and expensive type of customer assets:
managers and staff. The customer deploys these assets in a manner that gets the most out
of their productive capacities.
Defining critical success factors: For every market space there are critical success factors
that determine the success or failure of a service strategy. These factors are influenced by
customer needs, business trends, competition, regulatory environment, suppliers, standards,
industry best practices and technologies.

Page: - 39 -
ITIL V3 Foundations
Critical success factors and competitive analysis: CSFs are determinants of success in
a market space. They are also useful in evaluating a service provider’s strategic position in
a market space and driving changes to such positions. This requires CSFs to be further
refined in terms of some distinct value proposition to customers.
Prioritizing investments: One common problem service providers have is prioritizing

investments and managerial attention on the right set of opportunities. There is a hierarchy
in customer needs analogous to Maslow’s Hierarchy of Needs for individuals. At any one
time, the business needs of customers are fulfilled to varying levels of satisfaction. The
combination of hierarchy or importance of a need and its current level of satisfaction
determines the priority in the customer’s mind for purchases. The best opportunities for
service providers lie in areas where an important customer need remains poorly satisfied
Exploring business potential: Service providers can be present in more than one market
space. As part of strategic planning, service providers should analyse their presence across
various market spaces. Strategic reviews include the analysis of strengths, weaknesses,
opportunities and threats in each market
space. Service providers also analyse their business potential based on unserved or
underserved market spaces. This is an important aspect of leadership and direction provided
by the senior management of service providers. The long-term vitality of the service provider
rests on supporting customer needs as they change or grow as well exploiting new
opportunities that emerge.
Alignment with customer needs: Understand the mutual relationship between customers
and market spaces. Customers can contain one or more market spaces. Market spaces can
contain one or more Customers
Expansion and growth: Once service strategies are linked to market spaces, it is easier to
make decisions on Service Portfolios, designs, operations, and long-term improvements.
Investments in service assets such as skills sets, knowledge, processes, and infrastructure
are driven by the critical success factors for a given market space. The growth and
expansion of any business is less risky when anchored by core capabilities and
demonstrated performance. Successful expansion strategies are often based on leveraging
existing service assets and Customer Portfolios to drive new growth and profitability.
Differentiation in market spaces: In a given market space, services provide utility to

customers by delivering benefit with a level of certainty (i.e. warranty). Market spaces can be
defined anywhere an opportunity exists to improve the performance of customer assets.
Service strategy is about how to provide distinctive value in each market space. Service
providers should analyse every market space they support and determine their position with
respect to the options that customers have with other service providers.

Page - 40 -
ITIL V3 Foundations
Service Portfolio Management
Service Portfolio Management is a dynamic method for governing

investments in service management across the enterprise and managing
them for value
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 on a service-orientation journey have a tendency to view it as a

series of tactical programmes. 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 fulfilment
elements, there is an order worth noting.
While this order is not absolute it does serve 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.
Financial managers tailor a portfolio of investments based on their customer’s risk and
reward profile. Regardless of the profile, the objective is the same: maximize return at
an acceptable risk level. When conditions change, appropriate changes are made to the
portfolio. There is a need for applying comparable practices when managing a portfolio of
services.
The value of a Service Portfolio strategy is demonstrated through the ability to anticipate
change while maintaining traceability to strategy and planning.

Page: - 41 -
ITIL V3 Foundations
Service Portfolio
Service Knowledge Management System
• The Service Portfolio represents the
Service Portfolio
Service Lifecycle
commitments and investments
Status:
Service Pipeline Requirements
• It also helps managers prioritize
Defined investments and improve the
Service
Catalogue Analysed allocation of resources.
Approved
Customer/suport
Chartered • SP is divided into three phases:
team viewable
section of the Designed Service Catalogue, Service Pipeline
Service Porfolio Developed and Retired Services
(the Service Built
Catalogue, with Test
selected fields
Released
viewable In summary, SPM is about
Operational
Retired Services
Retired
maximizing value while
managing risks and costs
Source: “ITIL Refresh: Vendor pre-release briefing”, May 2007
Service Portfolio
The Service Portfolio represents the commitments and investments made by a service
provider across all customers and market spaces. It represents present contractual
commitments, new service development, and ongoing service improvement plans initiated
by Continual Service Improvement. The portfolio also includes third-party services, which are
an integral part of service offerings to customers. Some third-party services are visible to the
customers while others are not.
The portfolio management approach helps managers prioritize investments and improve the
allocation of resources. Changes to portfolios are governed by policies and procedures.
Portfolios install a certain financial discipline necessary to avoid making investments that will
not yield value. Service Portfolios represent the ability and readiness of a service provider to
serve customers and market spaces.
The Service Portfolio is divided into three phases: Service Catalogue, Service Pipeline and
Retired Services. The Service Portfolio represents all the resources presently engaged or
being released in various phases of the Service Lifecycle. Each phase requires resources for
completion of projects, initiatives and contracts. This is a very important governance aspect
of Service Portfolio Management (SPM).
Service Catalogue
The Service Catalogue is the subset of the Service Portfolio visible to customers. It consists
of services presently active in the Service Operation phase and those approved to be readily
offered to current or prospective customers. Items can enter the Service Catalogue only after
due diligence has been performed on related costs and risks. Resources are engaged to
fully support active services.

Page - 42 -
ITIL V3 Foundations
The Catalogue is useful in developing suitable solutions for customers from one or more
services. Items in the Catalogue can be configured and suitably priced to fulfill a particular
need. The Service Catalogue is an important tool for Service Strategy because it is the
virtual projection of the service provider’s actual and present capabilities. Many customers
are only interested in what the provider can commit now, rather than in future. The value of
future possibilities is discounted in the present.
Retired services
Some services in the Catalogue are phased out or retired. Phasing out of services is part of
Service Transition. This is to ensure that all commitments made to customers are duly
fulfilled and service assets are released from contracts. When services are phased out, the
related knowledge and information are stored in a knowledge base for future use. Phased-
out services are not available to new customers or contracts unless a special business case
is made. Such services may be reactivated into operations under special conditions and
SLAs that are to be approved by senior management. This is necessary because such
services may cost a lot more to support and may disrupt economies of scale and scope.

Page: - 43 -
ITIL V3 Foundations
Service Portfolio x Service Catalogue
Source: ITIL Service Strategy Book
The Service Portfolio represents all the resources presently engaged or being released in
various phases of the Service Lifecycle. Entry, progress, and exit are approved only with
approved funding and a financial plan for recovering costs or showing profit, as necessary.
The portfolio should have the right mix of services in the pipeline and catalog to secure the
financial viability of the service provider. The Service Catalog is the only part of the Service
Portfolio that recovers costs or earns profits.
Service Portfolio Management (SPM) is about maximizing value while managing risks and
costs. The value realization is derived from better service delivery and better customer
experiences. SPM begins by documenting the standardized services of the organization and
therefore has strong links to Service Level Management, particularly the Service Catalog.

Page - 44 -
ITIL V3 Foundations
Service Portfolio Activities

Service
Strategy
Inventory services, ensure

Define business cases and validate
portfolio data
Maximize portfolio value, align and

Analyze prioritize and balance supply and
demand
Finalize proposed portfolio,

Approve authorize services and resources
Communicate decisions, allocate

Charter resources and charter services
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.

Page: - 45 -
ITIL V3 Foundations
Demand Management
Demand Management is a critical aspect of service management. Poorly

managed demand is a source of risk for service providers because of
uncertainty in demand. Excess capacity generates cost without creating
value that provides a basis for cost recovery.
Patterns of business activity (PBA)

User profile
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.
For example, the fulfillment of a purchase order (business activity) may result in a set of
requests (demand) generated by the order-to-cash process (business process of customer).
Analysing and tracking the activity patterns of the business process makes it possible to
predict demand for services in the catalogue that support the process. It is also possible to
predict demand for underlying service assets that support those services. Every additional
unit of demand generated by business activity is allocated to a unit of service capacity.
Demand patterns occur at multiple levels. Activity-based Demand Management can daisy-
chain demand patterns to ensure that the business plans of customers are synchronized
with the service management plans of the service provider.
If a business plan calls for the allocation of human resources, the addition of an employee
can be translated into additional demand for the Service Desk function in terms of service
requests and service incidents. Similarly, new instances of business processes can be used
as predictors of demand for the Service Demand in terms of incidents and requests. After
validating the activity/demand model it is possible to make adjustments to account for
variations such as new employees, changes to business processes, and technology
upgrades on the customer’s side.
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

Page - 46 -
ITIL V3 Foundations
processes and applications are treated as users in many business contexts. Many
processes are not actively executed or controlled by staff or personnel. Process automation
allows for processes to consume services on their own. Processes and applications can
have user profiles. Whether they should is a matter of judgment. Each UP can be associated
with 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 predefined 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

Page: - 47 -
ITIL V3 Foundations
Financial Management
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
IT organizations are increasingly incorporating Financial Management in the pursuit of:
Enhanced decision making

Speed of change
Service Portfolio Management
Financial compliance and control
Operational control
Value capture and creation.
Service and strategy design both benefit greatly from the operational decision-making data
that Financial Management aggregates, refines and distributes as part of the Financial
Management process. Rigorously applied, Financial Management generates meaningful
critical performance data used to answer important questions for an organization:
• Is our differentiation strategy resulting in higher profits or revenues, lower costs, or

greater service adoption?
• Which services cost us the most, and why?
• What are our volumes and types of consumed services, and what is the correlating
budget requirement?
• How efficient are our service provisioning models in relation to alternatives?
• Does our strategic approach to service design result in services that can be offered at a
competitive ‘market price’, substantially reduce risk or offer superior value?
• Where are our greatest service inefficiencies?
• Which functional areas represent the highest priority opportunities for us to focus on as
we generate a Continual Service Improvement strategy?
Concepts, inputs and outputs

Like its business equivalent, IT Financial Management responsibilities and activities do not
exist solely within the IT finance and accounting domain. Rather, many parts of the
enterprise interact to generate and consume IT financial information, including operations
and support units, project management organizations, application development,

Page - 48 -
ITIL V3 Foundations
infrastructure, Change Management, business units, end users etc. These entities
aggregate, share and maintain the financial data they need. The Financial Management data
used by an IT organization may reside in, and be owned by the accounting and finance
domain, but responsibility for generating and utilizing it extends to other areas. Financial
Management aggregates data inputs from across the enterprise and assists in generating
and disseminating information as an output to feed critical decisions and activities such as
those discussed below.

Page: - 49 -
ITIL V3 Foundations
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

Page - 50 -
ITIL V3 Foundations
Service Automation
Automation can have particularly significant impact on the performance of service

assets such as management, organization, people, process, knowledge and
information.
Applications by themselves are a means of automation but their performance can

also be improved where they need to be shared between people and process assets.
The following are some of the areas where service management can benefit from
automation:
– Design and modelling
– Service catalogue
– Pattern recognition and analysis
– Classification, prioritization and routing
– Detection and monitoring
– Optimization
Automation is considered to improve the utility and warranty of services. It may offer
advantages in many areas of opportunity, including the following:
• The capacity of automated resources can be more easily adjusted in response to

variations in demand volumes.
• Automated resources can handle capacity with fewer restrictions on time of access; they
can therefore be used to serve demand across time zones and during after hours.
• Automated systems present a good basis for measuring and improving service
processes by holding constant the factor of human resources. Conversely, they can be
used to measure the differential impact on service quality and costs due to varying levels
of knowledge, skills and experience of human resources.
• Many optimization problems such as scheduling, routing and allocation of resources
require computing power that is beyond the capacity of human agents.
• Automation is a means for capturing the knowledge required for a service process.
Codified knowledge is relatively easy to distribute throughout the organization in a
consistent and secure manner. It reduces the depreciation of knowledge when
employees move within the organization or permanently leave.

Page: - 51 -
ITIL V3 Foundations
Unit 5 – Service Design
Goal
Basic concepts
Main Activities
Processes
After several years of contraction, the global IT industry returned to growth in 2003. At the
same time, a significant new opportunity began to emerge for providers of business process
services. Combined, these sources of growth are propelling IT and business services
beyond the IT industry as we have known it.

Page - 52 -
ITIL V3 Foundations
Continual

Support Process
Service Asset and

IT Service Continuity Service Testing and

Access Mgmt
Mgmt Validation
Technology
Management
Application
Management
Management
Functions
Facilities
Management

Page: - 53 -
ITIL V3 Foundations
Service Design Goal
The main goal of the Service Design stage of the lifecycle is the design of
new or changed services for introduction into the live environment.
A holistic approach should be adopted for all Service

Design aspects and areas to ensure consistency and
integration within all activities and processes across
the entire IT technology, providing end-to-end
business-related functionality and quality.
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 timescales 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 so that they can be removed or mitigated before services go
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

Page - 54 -
ITIL V3 Foundations
• Assist in the development of policies and standards in all areas of design and planning of
IT services and processes, receiving and acting on feedback on design processes from
all other areas and 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.
Not every change within an IT service will require the instigation of Service Design activity. It
will only be required where there is ‘significant’ change. Every organization must define what
constitutes ‘significant’ so that everyone within the organization is clear as to when Service
Design activity is instigated. Therefore all changes should be assessed for their impact on
Service Design activities to determine whether they are significant in terms of requiring
Service Design activity. This should be part of the Change Management process impact
assessment within the Service Transition publication of ITIL.

Page: - 55 -
ITIL V3 Foundations
Value to the Business
Reduced Total Cost of Ownership (TCO)

Improved quality of service
Improved consistency of service
Easier implementation of new or changed services
Improved service alignment:
More effective service performance
Improved IT governance:
More effective Service Management and IT Processes
Improved information and decision-making
With good Service Design, it is possible to deliver quality, cost-effective services and to
ensure that the business requirements are being met. The following benefits result from
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 comprehensive SDPs
• Improved service alignment: involvement from the conception of the service, ensuring
that new or changed services match business needs, with services designed to meet
Service Level Requirements
• More effective service performance: with incorporation and recognition of Capacity,
Financial Availability and IT Service Continuity Plans
• Improved IT governance: assist with the implementation and communication of a set of
controls for effective governance of IT
• More effective Service Management and IT processes: processes will be designed
with optimal quality and cost-effectiveness

Page - 56 -
ITIL V3 Foundations
• 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.

Page: - 57 -
ITIL V3 Foundations
Service Design Processes
Service Design Process

Service Catalogue Management
Service Level Management
Capacity Management
Avaliability Management
IT Service Continuity Management
Information Security Management
Supplier Management

Page - 58 -
ITIL V3 Foundations
Service Design Overview
This chapter describes and explains the fundamentals of the key supporting Service Design
processes.
These processes are principally responsible for providing key information to the design of
new or changed service solutions. There are five aspects of design that need to be
considered:
• The design of the services, including all of the functional requirements, resources and
capabilities needed and agreed
• The design of Service Management systems and tools, especially the Service Portfolio,
for the management and control of services through their lifecycle
• The design of the technology architectures and management systems required to
provide the services
• The design of the processes needed to design, transition, operate and improve the
services, the architectures and the processes themselves
• The design of the measurement methods and metrics of the services, the architectures
and their constituent components and the processes.

Page: - 59 -
ITIL V3 Foundations
Basic Concepts – 4 Ps
The implementation of ITIL Service Management

as a practice is about preparing and planning the
effective and efficient use of the four Ps:
People
Processes
Products (services, technology, and tools)
Partners (suppliers, manufacturers,and
vendors)
Many designs, plans, and projects fail due to a lack

of preparation and management.
In general, the key to the successful provision of IT services is an appropriate level of design
and planning to determine which projects, processes and services will have the greatest
impact or benefit to the business. With the appropriate level of thought, design, preparation
and planning, effort can be targeted at those areas that will yield the greatest return. Risk
assessment and management are key requirements within all design activities. Therefore all
five aspects of Service Design must include risk assessment and management as an
integrated, inherent part of everything they do. This will ensure that the risks involved in the
provision of services and the operation of processes, technology and measurement methods
are aligned with business risk and impact, because risk assessment and management are
embedded within all design processes and activities.
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)

Page - 60 -
ITIL V3 Foundations
Basic Concepts – Service Provider Types

There are three types of Service Providers
Type I - Internal Service Provider

Type II - Shared Services Unit
Type III - External Service Provider
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 unit
• Type III – external service provider

Page: - 61 -
ITIL V3 Foundations
Basic Concepts – Sourcing Approaches
Insourcing
Outsourcing
Co-sourcing
Partnership or multi-sourcing
Business Process Outsourcing (BPO)
Knowledge Process Outsourcing (KPO)
Application Service Provision (ASP)
Insourcing: This approach relies on utilizing internal organizational resources in the design,
development, transition, maintenance, operation and/or support of new, changed or revised
services or data centre operations.
Outsourcing: This approach utilizes the resources of an external organization or

organizations in a formal arrangement to provide a well defined portion of a service’s design,
development, maintenance, operations and/or support. This includes the consumption of
services from Application Service Providers (ASPs) described below.
Co-sourcing: Often a combination of insourcing and outsourcing, using a number of

outsourcing organizations working together to co-source key elements within the lifecycle.
This generally involves using a number of external organizations working together to design,
develop, transition, maintain, operate and/or support a portion of a service.
Partnership or multi-sourcing: Formal arrangements between two or more organizations

to work together to design, develop, transition, maintain, operate and/or support IT
service(s). The focus here tends to be on strategic partnerships that leverage critical
expertise or market opportunities.
Business Process Outsourcing (BPO):l The increasing trend of relocating entire business
functions using formal arrangements between organizations where one organization
provides and manages the other organization’s entire business process(es) or functions(s) in
a low-cost location. Common examples are accounting, payroll and call centre operations.
Knowledge Process Outsourcing (KPO): The newest form of outsourcing, KPO is a step
ahead of BPO in one respect. KPO organizations provide domain-based processes and

Page - 62 -
ITIL V3 Foundations
business expertise rather than just process expertise, and require advanced analytical and
specialized skills from the outsourcing organization.
Application Service Provision: Involves formal arrangements with an Application Service

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

Page: - 63 -
ITIL V3 Foundations
Basic Concepts – 5 Aspects
Technology & Service Management

Architecture Systems and Tools
Service
Processes Measurement Methods
There are five individual aspects of Service Design considered within this publication. These
are the design of:
The Service Management systems and tools, especially 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 on 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. Also the Service Management systems and tools
should be reviewed to ensure they are capable of supporting the new or changed service.
The technology architectures and management systems: to ensure that all the
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.

Page - 64 -
ITIL V3 Foundations
If all the above activities are completed during the Service Design stage, this will ensure that
there will be minimal issues arising 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.

Page: - 65 -
ITIL V3 Foundations
Basic Concepts – Service Design Tools

The Service Design Tools are used for:
Hardware Design
Software Design
Environmental Design
Process Design
Data Design
Some benefits:
Speeding up the design process
Ensuring that standards and conventions are followed
Validating designs before they are developed and implemented to ensure that they
satisfy and fulfil their intended requirements.
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, modelling and simulation facilities
• Enabling ‘What if?’ scenarios to be examined
• Enabling interfaces and dependencies to checked and correlated
• Validating designs before they are developed and implemented to ensure that they
satisfy and fulfil their intended requirements.

Page - 66 -
ITIL V3 Foundations
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. Some Configuration Management tools provide such
facilities, and are sometimes referred to as an element of Business Service Management
(BSM) tools. They can contain or be linked to ‘auto-discovery’ tools and mechanisms and
allow the relationships between all of these elements to be graphically represented,
providing the ability to drill down within each component and obtain detailed information if
needed.

Page: - 67 -
ITIL V3 Foundations
Basic Concepts – Solution Space
All design activities operate within many constraints. These constraints come from the
business and Service Strategy and cover many different areas. This means that designers
are not always ‘free’ to design the most appropriate solution for the business, because it
does not fall within the imposed constraints. The most obvious constraint is the financial one.
There may be insufficient budget available for the most appropriate solution, therefore a
cheaper alternative service would have to be identified and agreed with the business. The
designer can only provide the solution that fits within all of the currently known constraints, or
else try lifting or renegotiating some of the constraints – for instance, by obtaining a bigger
budget. In the Solution Space, not only will more budget need to be obtained to implement
the desired solution, but it would also be non-compliant with some of the relevant standards
and regulations. So in this case an alternative, cheaper compliant solution would be probably
be required.
So the Service Design processes must recognize the fact that they are free to design
solutions, but they are working in an environment where many external factors can influence
the design.
Many of these external influences are from the need for good corporate and IT governance,
and others are from the requirement for compliance with regulations, legislation and
international standards. It is essential, therefore, that all designers recognize these and
ensure that the designs and solutions they produce have all of the necessary controls and
capability within them.

Page - 68 -
ITIL V3 Foundations
Basic Concepts – Service Design Package
Produced during the Service Design phase

This Package is passed form Service Design to Serice Transition
Details all aspects of the service
Service Service
Service Design
Design Transition
P ack age6
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:
Requirements:
• Business requirements
• Service applicability
• Service contacts
Service Design:
• Service functional requeriments
• Service level requirements
• Service and operational management requirements
• Service design and topology
Organization readiness assessment
• Service lifecycle plan

• Service programme
• Service transition plan
• Service operational acceptance plan

Page: - 69 -
ITIL V3 Foundations
• Service acceptance criteria
Basic Concepts – Service Portfolio

Service Portfolio is designed by Service Design;
SP is owned and managed by Service Strategy within the Service Portfolio
Management process
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 market terms, providing a means for comparing service competitiveness across
alternative providers.
The Service Portfolio would therefore contain details of all services and their status with
respect to the current stage within the Service Lifecycle
Customers and users would only be allowed access to those services within the Service
Portfolio that were of a status between ‘chartered’ and ‘operational’, those services
contained within the Service Catalogue. 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.

Page - 70 -
ITIL V3 Foundations
Service Catalogue Management
To provide a single source of consistent information on all of the agreed

services
To ensure that information is widely available to those who are approved to

access it.
To ensure that a Service Catalogue is produced and maintained, containing

accurate information on all operational services and those being prepared to
be run operationally
To manage the information contained within the Service Catalogue, and to

ensure that it is accurate.
The purpose of Service Catalogue Management is to provide a single source of consistent

information on all of the agreed services, and ensure that it is widely available to those who
are approved to access it.
The goal of the Service Catalogue Management process is to ensure that a Service
Catalogue is produced and maintained, containing accurate information on all operational
services and those being prepared to be run operationally.
The objective of Service Catalogue Management is to manage the information contained

within the Service Catalogue, and to ensure 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.

Page: - 71 -
ITIL V3 Foundations
Service Catalogue
The Service Catalog is an important tool for Service Strategy because it is the virtual projection of the
actual and present capabilities of the service provider. Many customers are only interested in what the
provider can commit now rather than in future. The value of future possibilities is discounted in the present.
The Service Catalogue has two aspects:
• The Business Service Catalogue: containing details of all the IT services delivered to
the customer, together with relationships to the business units and the business process
that rely on the IT services. This is the customer view of the Service Catalogue.
• The Technical Service Catalogue: containing details of all 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 Catalogue and not form part of the customer
view.
Some organizations only maintain either a Business Service Catalogue or a Technical

Service Catalogue. The preferred situation adopted by the more mature organizations
maintains both aspects within a single Service Catalogue, which is part of a totally integrated
Service Management activity and Service Portfolio.
The Business Service Catalogue facilitates the development of a much more proactive or
even preemptive SLM process, allowing it to develop more into the
field of Business Service Management. The Technical Service Catalogue is extremely
beneficial when constructing the relationship between services, SLAs, OLAs and other
underpinning agreements and components, as it will identify the technology required to
support a service and the support group(s) that support the components.
The combination of a Business Service Catalogue and a Technical Service Catalogue is

invaluable for quickly assessing the impact of incidents and changes on the business.

Page - 72 -
ITIL V3 Foundations
Service Catalogue Manager
Ensuring that all operational services and all services being prepared for
operational running are recorded within the Service Catalogue
Ensuring that all the information within the Service Catalogue is accurate
and up-to-date
Ensuring that all the information within the Service Catalogue is consistent
with the information within the Service Portfolio
Ensuring that the information within the Service Catalogue is adequately

protected and backed up.

Page: - 73 -
ITIL V3 Foundations
Service Level Management

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 (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 SLAs and 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
Catalogue and their contents, because they provide the necessary information on the
services to be managed within the SLM process.

Page - 74 -
ITIL V3 Foundations
SLM – Activities
The key activities within the SLM process should include:
• Determine, negotiate, document, and agree upon requirements for new or changed
services in SLRs
• Manage and review the requirements through the Service Lifecycle into SLAs for
operational services
• Monitor and measure service performance achievements of all operational services
against targets within SLAs
• Collate, measure and improve customer satisfaction
• Produce service reports
• Conduct service review and instigate improvements within an overall Service
Improvement Plan (SIP)
• Review and revise SLAs, service scope OLAs, contracts, and any other underpinning
agreements
• Develop and document contacts and relationships with the business, customers, and
stakeholders
• Develop, maintain, and operate procedures for:
• Logging, assigning, and resolving all complaints
• Logging and distributing compliments
• Provide the appropriate management information to aid performance management and
demonstrate service achievement

Page: - 75 -
ITIL V3 Foundations
• Provide and maintain up-to-date SLM document templates and standards
SLM – Basic Concepts
To reach Service Level Management objectives, some concepts must be taken in

consideration:
Service Level Requirements (SLR): Is a set of targets and responsibilities documented and
agreed within an SLR for each proposed new or changed Service. SLR’s are based on
Business Objectives and are used to negotiate agreed Service Level Targets.
Service Level Agreement (SLA): Is a written agreement between an IT Service provider

and the IT customer, defining the key Service targets and responsibilities of both parties.
The emphasis must be on agreement and SLA’s should not be used as away of holding one
side or the other to ransom. A true partnership should be developed between the IT Service
provider and the customer, so that a mutually beneficial agreement is reached.
Although the IT organization itself has access to certain resources, it can also acquire
resources and/or Services from internal providers (like the network department, mainframe
department) or external providers (like a telecommunication company). To be able to
manage the performance of these hired resources and Services, the IT organization needs
agreements with these providers. These are called Operational Level Agreements for
Internal Providers and Underpinning Contracts for External Providers.
Operational Level Agreement (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

Page - 76 -
ITIL V3 Foundations
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 that to ensure that targets will not be breached by failure of the supporting activity.
Underpinning Contract (UC): Is a contract between an IT Service provider and an external

supplier covering delivery of Services that support the IT organization in their delivery of
Services. In ITIL Version 3 the Supplier Management process is responsible for negotiating
these UC’s with external suppliers and making sure that they aligned with the needs of the
business.

Page: - 77 -
ITIL V3 Foundations
SLA Structure
Service-based SLA: This is where an SLA covers one service, for all the
customers of that service covering all the customers of that service.
Customer-based SLA: This is an agreement with an individual customer

group, covering all the services they use.
Multi-level SLA
– Corporate level: covering all the generic SLM issues appropriate to every
customer throughout the organization.
– Customer level: covering all SLM issues relevant to the particular customer
group
– Service level: covering all SLM issues relevant to the specific service, in
relation to a specific customer
Using the Service Catalogue as an aid, SLM must design the most appropriate SLA
structure to ensure that all services and all customers are covered in a manner best suited to
the organization’s needs. There are a number of potential options, including the following.
Service-based SLA
This is where an SLA covers one service, for all the customers of that service – for example,
an SLA may be established for an organization’s e-mail service – covering all the customers
of that service. Where common levels of service are provided across all areas of the
business, e.g. e-mail or telephony, the service- based SLA can be an efficient approach to
use. Multiple classes of service, e.g. gold, silver and bronze, can also be used to increase
the effectiveness of service-based SLAs.
Customer-based SLA
This is an agreement with an individual customer group, covering all the services they use.
For example, agreements may be reached with an organization’s finance department
covering, say, the finance system, the accounting system, the payroll system, the billing
system, the procurement system, and any other IT systems that they use. Customers often
prefer such an agreement, as all of their requirements are covered in a single document.
Multi-level SLAs
Some organizations have chosen to adopt a multi-level SLA structure. For example, a three-
layer structure as follows:
Corporate level: covering all the generic SLM issues appropriate to every customer
throughout the organization. These issues are likely to be less volatile, so updates are less
frequently required

Page - 78 -
ITIL V3 Foundations
Customer level: covering all SLM issues relevant to the particular customer group or
business unit, regardless of the service being used
Service level: covering all SLM issues relevant to the specific service, in relation to a
specific customer group (one for each service covered by the SLA).

Page: - 79 -
ITIL V3 Foundations
SLM – Key Performance Indicators

Objective:
Number or percentage of service targets being met

Number and severity of service breaches
Number of services with up-to-date SLAs
Number of services with timely reports and activeservice reviews.
Subjective:
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.

Page - 80 -
ITIL V3 Foundations
SLM – Challenges
Identifying suitable representative within the business

Designate appropriate representatives from within the IT Organization
(internal or external)
Get Service Desk commitment
Formalize and communicate the agreements in customer satisfaction.
If there has been no previous experience of SLM, then it is advisable to start with a draft
SLA. A decision should bemade on which service or customers are to be used for the draft.
It is helpful if the selected customer is enthusiastic and wishes to participate – perhaps
because they are anxious to see improvements in service quality.
The results of an initial customer perception survey may give pointers to a suitable initial
draft SLA. One difficulty sometimes encountered is that staff at different levels within the
customer community may have different objectives and perceptions. It is important that all of
the appropriate and relevant customer requirements, at all levels, are identified and
incorporated in SLAs.
Once the initial SLA has been completed, and any early difficulties overcome, then move on
and gradually introduce SLAs for other services/customers. If it is decided from the outset to
go for a multi-level structure, it is likely that the corporate-level issues have to be covered for
all customers at the time of the initial SLA. It is also worth trialling the corporate issues
during this initial phase.
It is important that the Service Desk staff are committed to the SLM process, and become
proactive ambassadors for SLAs, embracing the necessary service culture, as they are the
first contact point for customers’ incidents, complaints and queries. If the Service Desk staff
are not fully aware of SLAs in place, and do not act on their contents, customers very quickly
lose faith in SLAs.

Page: - 81 -
ITIL V3 Foundations
Service Level Manager
Service Level Manager is responsible for:

To develop relationships and communication with stakeholders, customers
and key users
To identify, understand and document the current and future requirements
of customers;
To negotiate and agree SLRs, SLAs and OLAs with the customers and IT
staff, respectively;
To ensure the underpinning contracts are aligned with SLA and SLR
targets;
To improve the quality and performance of services according the business
requirements
The Service Level Manager has responsibility for ensuring that the aims of Service Level
Management are met. This includes responsibilities such as:
• Keeping aware of changing business needs

• Ensuring that the current and future service requirements of customers are identified,
understood and documented in SLA and SLR documents
• Negotiating and agreeing levels of service to be delivered with the customer (either
internal or external); formally documenting these levels of service in SLAs
• Negotiating and agreeing OLAs and, in some cases, other SLAs and agreements that
underpin the SLAs with the customers of the service
• Assisting with the production and maintenance of an accurate Service Portfolio, Service
Catalogue, Application Portfolio and the corresponding maintenance procedures
• Ensuring that targets agreed within underpinning contracts are aligned with SLA and
SLR targets
• Ensuring that service reports are produced for 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 on and
progress reports are provided to customers

Page - 82 -
ITIL V3 Foundations
• 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 CABmeetings if
appropriate
• Identifying all key stakeholders and customers
• Developing relationships and communication with stakeholders, customers and key
users
• Defining and agreeing complaints and their recording, management, escalation, where
necessary, and resolution
• Definition recording and communication of all complaints
• Measuring, recording, analysing and improving customer satisfaction.

Page: - 83 -
ITIL V3 Foundations
Capacity Management
The goal of the Capacity Management process is to ensure that cost-

justifiable IT capacity in all areas of IT always exists and is matched to the
current and future agreed needs of the business, in a timely manner’.To
improve the quality and performance of services according the business
requirements.
Balancing costs against resources needed

Balancing supply against demand
The Capacity Management process should be the focal point for all IT performance and
capacity issues. Technology management functions such as Network Support, Server
Support or Operation Management may carry out the bulk of the day-to-day operational
duties, but will provide performance information to the Capacity Management process. The
process should encompass all areas of technology, both hardware and software, for all IT
technology components and environments.
Capacity Management should also consider space planning and environmental systems
capacity as well as certain aspects of human resources, but only where a lack of human
resources could result in a breach of SLA or OLA targets, a delay in the end-to-end
performance or service response time, or an inability to meet future commitments and plans
(e.g. overnight data backups not completed in time because no operators were present to
load tapes).
The objectives of Capacity Management are to:
• Produce and maintain an appropriate and up-to-date Capacity Plan, which reflects the
current and future needs of the business
• Provide advice and guidance to all other areas of the business and IT on all capacity-
and performance related issues
• 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

Page - 84 -
ITIL V3 Foundations
• Assist with the diagnosis and resolution of performance- and capacity-related incidents
and problems
• Assess the impact of all changes on the Capacity Plan, and the performance and
capacity of all services and resources
Ensure that proactive measures to improve the performance of services are implemented
wherever it is cost-justifiable to do so.

Page: - 85 -
ITIL V3 Foundations
Basic Concepts - Capacity Management
Capacity Plan
Business Capacity Management
Service Capacity Management
Component Capacity Management
The Capacity Plan

This deliverable of Capacity Management process is used by all areas of the business and
IT management. and is acted on by the IT service provider and senior management of the
organization to plan the capacity of the IT infrastructure. It also provides planning input to
many other areas of IT and the business. It contains information on the current usage of
service and components, and plans for the development of IT capacity to meet the needs in
the growth of both existing service and any agreed new services. The Capacity Plan should
be actively used as a basis for decision-making. Too often, Capacity Plans are created and
never referred to or used.
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.
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, analysed and
reported. Wherever necessary, proactive and reactive action should be instigated, to ensure
that the performance of all services meets their agreed business targets.
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

Page - 86 -
ITIL V3 Foundations
components within the IT infrastructure that have finite resource are monitored and
measured, and that the collected data is recorded, analysed and reported.

Page: - 87 -
ITIL V3 Foundations
Capacity Management Process
Capacity Management is an extremely technical, complex and demanding process, and in

order to achieve results, it requires three supporting sub-processes.
One of the key activities of Capacity Management is to produce a plan that documents the
current levels of resource utilization and service performance and, after consideration of the
Service Strategy and plans, forecasts the future requirements for new IT resources to
support the IT services that underpin the business activities. The plan should indicate clearly
any assumptions made. It should also include any recommendations quantified in terms of
resource required, cost, benefits, impact, etc.
The production and maintenance of a Capacity Plan should occur at pre-defined intervals. It
is, essentially, an investment plan and should therefore be published annually, in line with
the business or budget lifecycle, and completed before the start of negotiations on future
budgets. A quarterly re-issue of the updated plan may be necessary to take into account
changes in service plans, to report on the accuracy of forecasts and to make or refine
recommendations. This takes extra effort but, if it is regularly updated, the Capacity Plan is
more likely to be accurate and to reflect the changing business need.

Page - 88 -
ITIL V3 Foundations
Availability Management
The goal of the Availability Management process is to ensure 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.
The objectives of Availability Management are to:
• Produce and maintain an appropriate and up-to-date Availability Plan that reflects the
current and future needs of the business
• Provide advice and guidance to all other areas of the business and IT on all availability-
related issues
• Ensure that service availability achievements meet or exceed all their agreed targets, by
managing services and resources-related availability performance
• Assist with the diagnosis and resolution of availability related incidents and problems
• Assess the impact of all changes on the Availability
• Plan and the performance and capacity of all services and resources
• Ensure that proactive measures to improve the availability of services are implemented
wherever it is cost-justifiable to do so.
Availability Management should ensure the agreed level of availability is provided. The
measurement and monitoring of IT availability is a key activity to ensure availability levels
are being met consistently. Availability Management should look to continually optimize and
proactively improve the availability of the IT infrastructure, the services and the supporting
organization, in order to provide cost-effective availability improvements that can deliver
business and customer benefits.

Page: - 89 -
ITIL V3 Foundations
Basic Concepts - Availability Management
Service availability
Component availability
Availability
Serviceability
Service availability: involves all aspects of service availability and unavailability and the
impact of component availability, or the potential impact of component unavailability on
service availability
Component availability: involves all aspects of component availability and unavailability.
Availability: the ability of a service, component or CI to perform its agreed function when
required.
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

Page - 90 -
ITIL V3 Foundations

Reliability
Reliability is often measured and reported as Mean Time between Service Incidents (MTBSI) or Mean Time between
Failures (MTBF).
Reliability is a measure of how long a service, component, or CI can perform its agreed-upon 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 (such as increasing the component redundancy, for example by
using load balancing techniques).

Page: - 91 -
ITIL V3 Foundations

Maintainability and Serviceability
•Maintainability is a measure of how quickly and effectively a service, component, or CI can be restored to
normal working after a failure. It is measured and reported as Mean Time to Restore Service (MTRS) and
should be calculated using the following formula shown.
Example: A situation where a 24 x 7 service has been running for a period of 5020 hours with only two
breaks, one of 6 hours and one of 14 hours, would give the following figures:
•Availability = (5020-(6+14)) / 5020 x 100 = 99.60%
•Reliability (MTBSI) = 5020 / 2 = 2510 hours
•Reliability (MTBF) = 5020 – (6+14) / 2 = 2500 hours
•Maintainability (MTRS) = (6+14) / 2 = 10 hours

Page - 92 -
ITIL V3 Foundations
Availability Management - Process
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.
The reactive activities of Availability Management consist of monitoring, measuring,

analysing, 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 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.
An effective Availability Management process, consisting of both the reactive and proactive
activities, can ‘make a big difference’ and will be recognized as such by the business, if the
deployment of Availability Management within an IT organization has a strong emphasis on
the needs of the business and customers.

Page: - 93 -
ITIL V3 Foundations
IT Service Continuity Management
‘The goal of ITSCM is to support 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.’
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
• Complete regular Business Impact Analysis (BIA) exercises to ensure that all continuity
plans are maintained in line with changing business impacts and requirements
• Conduct regular Risk Analysis and Management exercises, particularly in conjunction
with the business and the Availability Management and Security
• Management processes, that manage IT services within an agreed level of business risk
• Provide advice and guidance to all other areas of the business and IT on all continuity-
and recovery-related issues
• Ensure that appropriate continuity and recovery mechanisms are put in place to meet or
exceed the agreed business continuity targets
• Assess the impact of all changes on the IT Service Continuity Plans and IT recovery
plans
• Ensure that proactive measures to improve the availability of services are implemented
wherever it is cost-justifiable to do so
• 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.

Page - 94 -
ITIL V3 Foundations
ITSCM – Basic Concepts
Business Continuity Plans

Business Continuity Management
Business Impact Analysis
Risk Analysis
Business Continuity Plan (BCP)

A Plan defining the steps required to Restore Business Processes following a disruption.
The Plan will also identify the triggers for Invocation, people to be involved, communications,
etc. IT Service Continuity Plans form a significant part of Business Continuity Plans
Business Continuity Management (BCM)

The Business Process responsible for managing Risks that could seriously affect the
Business. BCM safeguards the interests of key stakeholders, reputation, brand and value-
creating activities. The BCM Process involves reducing Risks to an acceptable level and
planning for the recovery of Business Processes should a disruption to the Business occur.
BCM sets the Objectives, Scope and Requirements for IT Service Continuity Management.
Business Impact Analysis (BIA)

The purpose of a Business Impact Analysis (BIA) is to quantify the impact to the business
that loss of service would have. This impact could be a ‘hard’ impact that can be precisely
identified – such as financial loss – or ‘soft’ impact – such as public relations, morale, health
and safety or loss of competitive advantage. The BIA will identify the most important services
to the organization and will therefore be a key input to the strategy..
Risk Analysis (RA)

RA consist in the risk identification and risk assessment to identify potential threats to
continuity and the likelihood of the threats becoming reality. This also includes taking
measures to manage the identified threats where this can be cost-justified

Page: - 95 -
ITIL V3 Foundations
ITSCM - Process
ITSCM primarily considers the IT assets and configurations that support the business
processes. If (following a disaster) it is necessary to relocate to an alternative working
location, provision will also be required for items such as office and personnel
accommodation, copies of critical paper records, courier services and telephone facilities to
communicate with customers and third parties. The scope will need to take into account the
number and location of the organization’s offices and the services performed in each.
ITSCM does not usually directly cover longer-term risks such as those from changes in
business direction, diversification, restructuring, major competitor failure, and so on. While
these risks can have a significant impact on IT service elements and their continuity
mechanisms, there is usually time to identify and evaluate the risk and include risk mitigation
through changes or shifts in business and IT strategies, thereby becoming part of the overall
business and IT Change Management programme.
Similarly, ITSCM does not usually cover minor technical faults (for example, non critical disk
failure), unless there is a possibility that the impact could have a major impact on the
business. These risks would be expected to be covered mainly through the Service Desk
and the Incident Management process, or resolved through the planning associated with the
processes of Availability Management, Problem Management, Change Management,
Configuration Management and ‘business as usual’ operational management.
The ITSCM process includes:

• The agreement of the scope of the ITSCM process and the policies adopted.
• Business Impact Analysis (BIA) to quantify the impact loss of IT service would have on
the business.

Page - 96 -
ITIL V3 Foundations
• Risk Analysis of the services.
• Production of an overall ITSCM strategy that must be integrated into the BCM strategy.
This can be produced following the two steps identified above, and is likely to include
elements of risk reduction as well as selection of appropriate and comprehensive
recovery options.
• Production of an ITSCM plan, which again must be integrated with the overall BCM
plans.
• Testing of the plans.
• Ongoing operation and maintenance of the plans.

Page: - 97 -
ITIL V3 Foundations
Information Security Management
‘The goal of the ISM process is to align IT security with business security
and ensure that information security is effectively managed in all service and
Service Management activities’
The ISM process should be the focal point for all IT security issues, and must ensure that an
Information Security Policy is produced, maintained and enforced that covers the use and
misuse of all IT systems and services. ISM needs to understand the total IT and business
security environment,
The ISM process should include:
• The production, maintenance, distribution and enforcement of an Information Security

Policy and supporting security policies
• Understanding the agreed current and future security requirements of the business and
the existing Business Security Policy and plans
• Implementation of a set of security controls that support the Information Security Policy
and manage risks associated with access to services, information and systems
• Documentation of all security controls, together with the operation and maintenance of
the controls and their associated risks
• Management of suppliers and contracts regarding access to systems and services, in
conjunction with Supplier Management
• Management of all security breaches and incidents associated with all systems and
services
• The proactive improvement of security controls, and security risk management and the
reduction of security risks
• Integration of security aspects within all other IT SM processes.
To achieve effective information security governance, management must establish and

maintain an Information Security Management System (ISMS) to guide the development and

Page - 98 -
ITIL V3 Foundations
management of a comprehensive information security programme that supports the
business objectives
Security Framework
Information Security Policy
Security framework
Information Security Policy

Information Security Management activities should be focused on and driven by an overall
Information Security Policy and a set of underpinning specific security policies.
The ITP should have the full support of top executive IT management and ideally the support
and commitment of top executive business management. The policy should cover all areas
of security, be appropriate, meet the needs of the business.
These policies should be widely available to all customers and users, and their compliance
should be referred to in all SLRs, SLAs, contracts and agreements. The policies should be
authorized by top executive management within the business and IT, and compliance to
them should be endorsed on a regular basis. All security policies should be reviewed – and,
where necessary, revised – on at least an annual basis.
Security framework
The Information Security Management process and framework will generally consist of:
• An Information Security Policy and specific security policies that address each aspect of
strategy, controls and regulation
• An Information Security Management System (ISMS), containing the standards,
management procedures and guidelines supporting the information security policies

Page: - 99 -
ITIL V3 Foundations
• A comprehensive security strategy, closely linked to the business objectives, strategies
and plans
• An effective security organizational structure
• A set of security controls to support the policy
• The management of security risks
• Monitoring processes to ensure compliance and provide feedback on effectiveness
• Communications strategy and plan for security
• Training and awareness strategy and plan
The framework or the ISMS in turn provides a basis for the development of a cost-effective
information security programme that supports the business objectives. It will involve the Four
Ps of People, Process, Products and technology as well as Partners and suppliers to ensure
high levels of security are in place.
The five elements within this framework are as follows:
Control
The objectives of the control element of the ISMS are to:
• Establish a management framework to initiate and manage information security in the

organization
• Establish an organization structure to prepare, approve and implement the Information
Security Policy
• Allocate responsibilities
• Establish and control documentation.
Plan
The objective of the plan element of the ISMS is to devise and recommend the appropriate
security measures, based on an understanding of the requirements of the Organization
Implement
The objective of the implementation of the ISMS is to ensure that appropriate procedures,
tools and controls are in place to underpin the Information Security Policy.
Evaluation
The objectives of the evaluation element of the ISMS are to:
• Supervise and check compliance with the security policy and security requirements in
SLAs and OLAs
• Carry out regular audits of the technical security of IT systems
• Provide information to external auditors and regulators, if required.
Maintain
The objectives of this maintain element of the ISMS are to:
• Improve security agreements as specified in, for example, SLAs and OLAs
• Improve the implementation of security measures and controls.

Page - 100 -
ITIL V3 Foundations
Supplier Management
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.
The purpose of the Supplier Management process is to obtain value for money from
suppliers and to ensure that suppliers perform to the targets contained within their contracts
and agreements, while conforming to all of the terms and conditions.
The main objectives of the Supplier Management process are to:
• Obtain value for money from supplier 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).
The Supplier Management process should include the management of all suppliers and
contracts needed to support the provision of IT services to the business. Each service
provider should have formal processes for the management of all suppliers and contracts.
However, the processes should adapt to cater for the importance of the supplier and/or the
contract and the potential business impact on the provision of services.

Page: - 101 -
ITIL V3 Foundations
Supplier Management Process
The Supplier Management process attempts to ensure that suppliers meet the terms,
conditions and targets of their contracts and agreements, whilst 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 Contracts Database (SCD) should be established 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 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 Catalogue. The relationship between the supporting services and
the IT and business services they support are key to providing quality IT services.
The Supplier Management process should include:
• Implementation and enforcement of the supplier policy

• Maintenance of a Supplier and Contract Database (SCD)
• Supplier and contract categorization and risk assessment
• Supplier and contract evaluation and selection
• Development, negotiation and agreement of contracts
• Contract review, renewal and termination
• Management of suppliers and supplier performance
• Agreement and implementation of service and supplier improvement plans
• Maintenance of standard contracts, terms and Conditions

Page - 102 -
ITIL V3 Foundations
Unit 6 – Service Transition
Goal
Basic concepts
Main Activities
Processes

Page: - 103 -
ITIL V3 Foundations
Continual

Support Process
Service Asset and

Service Testing and

Validation
Technology
Management
Application
Management
Management
Functions
Facilities
Management

Page - 104 -
ITIL V3 Foundations
Service Transition Goal
How to introduce new Services (or Change the existing Services) with
appropriate balance of:
– Speed
– Cost
– Safety
– Focus on Customer expectations and requirements;
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 be rebuilt 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.
Service Transition uses all the processes described in the other ITIL publications 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.

Page: - 105 -
ITIL V3 Foundations
Incident and problem management are important for handling incidents and problems during
testing, pilot and deployment activities.
The scope of Service Transition includes the management and coordination of the
processes, systems and functions to package, build, test and deploy a release into
production and establish the service specified in the customer and stakeholder
requirements.
The following activities are excluded from the scope of Service Transition best practices:
• Minor modifications to the production services and environment, e.g. replacement of a

failed PC or printer, installation of standard software on a PC or server, or a new user;
• Ongoing Continual Service Improvements that do not significantly impact the services or
service provider’s capability to deliver the services, e.g. request fulfilment activities
driven from Service Operations.

Page - 106 -
ITIL V3 Foundations
Service Transition Value
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.
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 and 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 and budgets
• The productivity of business and customer staff because of better planning and use of
new and changed services

Page: - 107 -
ITIL V3 Foundations
Service Transition Processes
The following processes are strongly focused within the Service Transition
stage:
Transition Planning and Support

Change Management
Service Asset and Configuration Management
Knowledge Management.
Release and Deployment Management
Service Testing and Validation
Evaluation.
There are two types of significant Service Management process that are described in this
publication as indicated below.
Processes that support the service lifecycle
The first group are whole service lifecycle processes that are critical during the transition
stage but influence and support all lifecycle stages. These comprise:
• Change Management
• Service Asset and Configuration Management
• Knowledge Management.
Processes within Service Transition
The following processes are strongly focused within the Service Transition stage:
• Transition Planning and Support

• Release and Deployment Management
• Service Testing and Validation
• Evaluation.

Page - 108 -
ITIL V3 Foundations
Change Management
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.
The goals of Change Management are to:
• Respond to the customer’s changing business requirements while maximizing value and
reducing incidents, disruption and re-work
• Respond to the business and IT requests for change that will align the services with the
business needs.
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.

Page: - 109 -
ITIL V3 Foundations
Basic Concepts - Change Management
Service change: ‘The addition, modification or removal of authorized, planned

or supported service or service component and its associated documentation.’
Change request: A formal communication of the change.

– Request for Change: A formal proposal for a small and medium
Change to be made
– Change Proposal: May be used to register a a major change with
significant organizational and/or financial implications
Remediation Planning: A back-out plan, which will restore the organization to

its initial situation
Service change: ‘The addition, modification or removal of authorized, planned or supported

service or service component and its associated documentation.’
Change Request: is a formal communication seeking an alteration to one or more

configuration items. This could take several forms, e.g. ‘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.
Request for Change (RFC): A formal proposal for a Change to be made. An RFC includes
details of the proposed Change, and may be recorded on paper or electronically. The term
RFC is often misused to mean a Change Record, or the Change itself.
Change Proposal: For a major change with significant organizational and/or financial
implications, a change proposal may be required, which will contain a full description of the
change together with a business and financial justification for the proposed change. The
change proposal will include signoff by appropriate levels of business management.
Remediation Planning: No change should be approved without having explicitly addressed

the question of what to do if it is not successful. Ideally, there will be a back-out plan, which
will restore the organization to its initial 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 organization’s business continuity plan.

Page - 110 -
ITIL V3 Foundations
Basic Concepts - Change Management
Service
User IT Staff Tools ...
Desk
Change Request
Standard Change Emergency

Normal Change
(Pre-Authorized) Change
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.
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
• The risk is usually low and always well understood.
Emergency Change is 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 change may document some details retrospectively. 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.
Effectively, the emergency change procedure will follow the normal change procedure
except that:

Page: - 111 -
ITIL V3 Foundations
• Approval will be given by the ECAB rather than waiting for a CAB meeting
• Testing may be reduced, or in extreme cases forgone completely, if considered a
necessary risk to deliver the change immediately
• Documentation, i.e. updating the change record and configuration data, may be deferred,
typically until normal working hours.
Normal Changes (such as Changes to Service Portfolios, Service Definitions, Project

Changes, User Accesses, Operational Changes) need to follow the Normal Change
Management process, and can be further categorized as Changes which are Major, Minor,
or Significant in nature and they need to be referred to the various levels of management for
the final authorization.

Page - 112 -
ITIL V3 Foundations
Change Management Process
This section provides approaches to managing service changes effectively by addressing

the tasks carried out to achieve and deliver controlled change. Overall Change Management
activities include:
• Planning and controlling changes

• Change and release scheduling
• Communications
• Change decision making and change authorization
• Ensuring there are remediation plans
• Measurement and control
• Management reporting
• Understanding the impact of change
• Continual improvement
Typical activities in managing individual changes are:
• Create and record the RFC

• Review RFC and change proposal
o Filter changes (e.g. incomplete or wrongly routed changes)
• Assess and evaluate the change
o Establish the appropriate level of change authority

Page: - 113 -
ITIL V3 Foundations
o Establish relevant areas of interest (i.e. who should be involved in the CAB)
o Assess and evaluate the business justification, impact, cost, benefits and risk of
changes
• Request independent evaluation of a change
• Authorize the change:
o Obtain authorization/rejection
o Communicate the decision with all stakeholders, in particular the initiator of the
Request for Change Plan updates
o Coordinate change implementation
• Review and close change:
• Collate the change documentation, e.g. baselines and evaluation reports
• Review the change(s) and change documentation
• Close the change document when all actions are completed.

Page - 114 -
ITIL V3 Foundations
The “Seven Rs” of Change Management
. Who RAISED the change?

What is the REASON for the change?
What is the RETURN required from the change?
What are the RISKS involved in the change?
What RESOURCES are required to deliver the
change?
Who is RESPONSIBLE for the build, test and
implementation of the change?
What is the RELATIONSHIP between this
change and other changes?
The potential impact on the services of failed changes and their impact on service assets
and configurations need to be considered. Generic questions (e.g. the ‘seven Rs’) provide a
good starting point.
The following questions must be answered for all changes. Without this information, the
impact assessment cannot be completed, and the balance of risk and benefit to the live
service will not be understood. This could result in the change not delivering all the possible
or expected business benefits or even of it having a detrimental, unexpected effect on the
live service.
Who RAISED the change?

What is the REASON for the change?
What is the RETURN required from the change?
What are the RISKS involved in the change?
What RESOURCES are required to deliver the change?
Who is RESPONSIBLE for the build, test and implementation of the change?
What is the RELATIONSHIP between this change and other changes?

Page: - 115 -
ITIL V3 Foundations
Change Autorization
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.
Emergency Change Advisory Board (ECAB): is body that makes

emergency decisions about emergency changes.
Note that the CAB is an advisory body only!!!
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.
Note that the CAB is an advisory body only. If the CAB cannot agree to a recommendation,
the final decision on whether to authorize changes, and commit to the expense involved, is
the responsibility of management (normally the director of IT or the services director, service
manager or change manager as their delegated representative). The Change Management
authorization plan should specifically name the person(s) authorized to sign off RFCs.
Emergency Change Advisory Board (ECAB).

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

Page - 116 -
ITIL V3 Foundations
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, e.g. to Operations teams who will action, document and report on the emergency
change.

Page: - 117 -
ITIL V3 Foundations
Change Manager
Change Manager
– Responsible of main activities of the process

– Control RFC
– Coordinate CAB
Note: It is the Change Manager, not the CAB or ECAB, that authorizes (or
rejects) Changes
The main duties of the Change Manager, some of which may be delegated, are listed below:
• Receives, logs and allocates a priority, in collaboration with the initiator, to all RFCs;
rejects any RFCs that are totally impractical
• Tables all RFCs for a CAB meeting, issues an agenda and circulates all RFCs to CAB
members in advance of meetings to allow prior consideration
• Decides 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
• Convenes urgent CAB or ECAB meetings for all urgent RFCs
• Chairs all CAB and ECAB meetings
• After consideration of the advice given by the CAB or ECAB, authorizes acceptable
changes
• Issues change schedules, via the service desk
• Liaises with all necessary parties to coordinate change building, testing and
implementation, in accordance with schedules
• Updates the change log with all progress that occurs, including any actions to correct
problems and/or to take opportunities to improve service quality
• Reviews all implemented changes to ensure that they have met their objectives; refers
back any that have been backed out or have failed
• Reviews all outstanding RFCs awaiting consideration or awaiting action
• Analyses change records to determine any trends or apparent problems that occur;
seeks rectification with relevant parties
• Closes RFCs
• Produces regular and accurate management reports.

Page - 118 -
ITIL V3 Foundations
Change Management Metrics
The number of changes implemented to services which met the customer’s

agreed requirements
Change success rate
Incidents attributable to changes
Reduction in the number of changes where remediation is invoked
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 customer’s agreed
requirements, e.g. 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 with 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 percentage 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.

Page: - 119 -
ITIL V3 Foundations
Service Asset and Configuration Management
The objective is to define and control the components of services and

infrastructure and maintain accurate configuration information on the historical,
planned and current state of the services and infrastructure
Provide Information
Define and Control Configuration Items (CI's)
Protect and ensure integrity of CI's
The purpose of SACM is to:
• Identify, control, record, report, audit and verify service assets and configuration items,
including versions, baselines, constituent components, their attributes, and relationships
• Account for, manage and protect the integrity of service assets and configuration items
(and, where appropriate, those of its customers) through the service lifecycle by ensuring
that only authorized components are used and only authorized changes are made
• Protect the integrity of service assets and configuration items (and, where appropriate,
those of its customers) through the service lifecycle
• 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.

Page - 120 -
ITIL V3 Foundations
SACM - Scope
Asset Management:
Asset Management covers service assets across the whole service lifecycle.
It provides a complete inventory of assets and who is responsible for their
control
Configuration Management:
Configuration Management ensures that selected components of a complete

service, system or product (the configuration) are identified, baselined and
maintained and that changes to them are controlled.
Asset Management covers service assets across the whole service lifecycle. It provides a
complete inventory of assets and who is responsible for their control. It includes:
• Full lifecycle management of IT and service assets, from the point of acquisition through
to disposal
• Maintenance of the asset inventory.
Configuration Management ensures that selected components of a complete service, system

or product (the configuration) are identified, baselined and maintained and that changes to
them are controlled. It also ensures that releases into controlled environments and
operational use are done on the basis of formal approvals. It provides a configuration model
of the services, assets and infrastructure by recording the relationships between service
assets and configuration items. SACM may cover non-IT assets, work products used to
develop the services and configuration items required to support the service that are not
formally classified as assets.
The scope covers interfaces to internal and external service providers where there are
assets and configuration items that need to be controlled, e.g. shared assets.

Page: - 121 -
ITIL V3 Foundations
Basic Concepts - SACM

Asset: Any Resource or Capability. Assets can be Management,
Organization, Process, Knowledge, People, Information, Applications,
Infrastructure, and Financial Capital.
Configuration Item: is an asset, service component or other item that is, or

will be, under the control of Configuration Management
The Configuration Model: is the logical model used to connect the CIs
used by SACM.
Configuration Management System (CMS): A set of tools and databases

that are used to manage the Service Asset and Configuration Management
data.
Configuration Management Database (CMDB): A database used to store

Configuration Records throughout their Lifecycle
Asset
A asset can be any Resource or Capability. Assets of a Service Provider including anything
that could contribute to the delivery of a Service. Assets are classified by the following types:
Management, Organization, Process, Knowledge, People, Information, Applications,
Infrastructure, and Financial Capital
Configuration items
A configuration item (CI) is an asset, service component or other item that 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, e.g. 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 lifecycle.
The Configuration Model

Configuration Management delivers a model of the services, assets and the infrastructure by
recording the relationships between configuration items. This enables other processes to
access valuable information
The real power of Configuration Management’s logical model of the services and
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.

Page - 122 -
ITIL V3 Foundations

To manage large and complex IT services and infrastructures, Service Asset and
Configuration Management requires the use of a supporting system known as the
Configuration Management System (CMS). The CMS holds all the information for CIs within
the designated scope. Some of these items will have related specifications or files that
contain the contents of the item, e.g. software, document or photograph. For example, a
Service CI will include the details such as supplier, cost, purchase date and renewal date for
licences and maintenance contracts and the related documentation such as SLAs and
underpinning contracts.
Configuration Management Database (CMDB)

A database used to store Configuration Records throughout their Lifecycle. The
Configuration Management System maintains one or more CMDBs, and each CMDB stores
Attributes of CIs, and Relationships with other CIs.

Page: - 123 -
ITIL V3 Foundations
SACM – CMS x CMDB
Business/Customer/Supplier/User – Service – Application – Infrastructure mapping

Information
Integration Service Portfolio Service Change
Layer Service Model INTEGRATED CMDB
Service Catalogue Service Release
Common Schema Meta Data Data Data Extract, Mining

Process, Data Mapping Management Reconciliation Synchronization
Tranform,
and Information
Model Load
DATA INTEGRATION
Platform Enterprise
Project Document Definitive Media Physical CMDBs Software Discovery,
Configuration Applications
File Store Library Configuration Asset
Data and CMDB 1 Tools Acess Mangement
Management Management
Eg. Stora Human Resources
Information STRUCTURED Definitive Document
and Audit
Supply Chain
Sources CMDB 2 DBs, Tools
Library Mangement
Middleware,
and Tools Network, Customer
Project Software Definitive Multimedia CMDB 3 Relationship
Mainframe...
Libraries Management
The Configuration Management System (CMS) holds all the information for CIs within the
designated scope, and is used for wide range of purposes.
CMS maintains the relationships between all service components and any related incidents,
problems, known errors, change and release documentation
CMS could contain corporate data about employees, suppliers, locations and business units,
customers, and users
Some of these items will have related specifications or files that contain the contents of the
item such as software, documents, or a photograph.
For example, a Service CI will include the details such as supplier, cost, purchase date, and
renewal date for licenses and maintenance contracts, and the related documentation, such
as SLAs and Underpinning Contracts.
Note: 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.

Page - 124 -
ITIL V3 Foundations
Basic Concepts - SACM
Secure Libraries
Secure Store
Definitive Media Library (DML)
Definitive Spares
Snapshot
Configuration Baseline
Secure libraries
A secure library is a collection of software, electronic or document CIs of known type and
status. Access to items in a secure library is restricted. Libraries are used for controlling and
releasing components throughout the service lifecycle, e.g. in design, building, testing,
deployment and operations.
Secure store
A secure store is a location that warehouses IT assets. It is identified within SACM, e.g.
secure stores used for desktop deployment. Secure stores play an important role in the
provision of security and continuity – maintaining reliable access to equipment of known
quality.
The Definitive Media Library

The Definitive Media Library (DML) is the secure library in which the definitive authorized
versions of all media CIs are stored and protected. It stores master copies of versions that
have passed quality assurance checks. This library may in reality consist of one or more
software ibraries or file-storage areas, separate from development, test or live file-store
areas. It contains the master copies of all controlled software in an organization. The DML
should include definitive copies of purchased software (along with licence documents or
information), as well as software developed on site. Master copies of controlled
documentation for a system are also stored in the DML in electronic form.
The DML will also include a physical store to hold master copies, e.g. a fireproof safe. Only
authorized media should be accepted into the DML, strictly controlled by SACM.

Page: - 125 -
ITIL V3 Foundations
Definitive Spares
An area should be set aside for the secure storage of definitive hardware spares. These are
spare components and assemblies that are maintained at the same level as the
comparative systems within the controlled test or live environment. Details of these
components, their locations and their respective builds and contents should be
comprehensively recorded in the CMS. These can then be used in a controlled manner
when needed for additional systems or in the recovery from incidents. Once their
(temporary) use has ended, they are returned to the spares store or replacements are
obtained.
Snapshot
A snapshot of the current state of a configuration item or an environment, e.g. from a
discovery tool. This snapshot is recorded in the CMS and remains as a fixed historical
record. Sometimes this is referred to a footprint. A snapshot is not necessarily formally
reviewed and agreed on – it is just a documentation of a state, which may contain faults and
unauthorized CIs. One example is where a snapshot is established after an installation,
perhaps using a discovery tool, and later compared to the original configuration baseline.
Configuration baseline
A configuration baseline is the configuration of a service, product or infrastructure that has
been formally reviewed and agreed on, that thereafter serves as the basis for further
activities and that can be changed only through formal change procedures. It captures the
structure, contents and details of a configuration and represents a set of configuration items
that are related to each other.

Page - 126 -
ITIL V3 Foundations
SACM – Process
Management
and Planning
Configuration
Identification
Configuration
Control
Status Accounting
and Reporting
Verification and
Audit
Management and planning

There is no standard template for determining the optimum approach for SACM. The
management team and Configuration Management should decide what level of
Configuration Management is required for the selected service or project that is delivering
changes and how this level will be achieved. This is documented in a Configuration
Management Plan. Often there will be a Configuration Management Plan for a project,
service or groups of services, e.g. network services. These plans define the specific
Configuration Management activities within the context of the overarching Service Asset and
Configuration Management strategy.
Configuration identification
• Define and document criteria for selecting configuration items and the components that
compose them
• Select the configuration items and the components that compose them based on
documented criteria
• Assign unique identifiers to configuration items Specify the relevant attributes of each
configuration item
• Specify when each configuration item is placed under Configuration Management
• Identify the owner responsible for each configuration item.
Configuration Control
Configuration control ensures that there are adequate control mechanisms over CIs while
maintaining a record of changes to CIs, versions, location and custodianship/ownership.

Page: - 127 -
ITIL V3 Foundations
Without control of the physical or electronic assets and components, the configuration data
and information there will be a mismatch with the physical world.
No CI should be added, modified, replaced or removed without an appropriate controlling
documentation or procedure being followed.
Status accounting and reporting

Each asset or CI will have one or more discrete states through which it can progress. The
significance of each state should be defined in terms of what use can be made of the asset
or CI in that state. There will typically be a range of states relevant to the individual asset or
CIs.
Verification and audit

The activities include a series of reviews or audits to:
• Ensure there is conformity between the documented baselines (e.g. agreements,

interface control documents) and the actual business environment to which they refer
• Verify the physical existence of CIs in the organization or in the DML and spares stores,
the functional and operational characteristics of CIs and to check that the records in the
CMS match the physical infrastructure
• Check that release and configuration documentation is present before making a release.

Page - 128 -
ITIL V3 Foundations
SACM – Roles and Responsibilities
Service Asset Manager

– Responsible for Asset Management System including the policy, plan,
process, people, tools, reports in the system
Configuration Manager
– Responsible for Configuration Management System including policy,
plan, process, people, tools, reports in the system
Service Asset Manager

The Service Asset Manager has the following responsibilities:
• Works to the overall objectives agreed with the IT Services Manager; implements the
organization’s Service Asset Management policy and standards
• Evaluates existing Asset Management Systems, plans, implements and manages
Changed systems, and provides reporting on progress against plan
• Agrees to the scope of the Asset Management processes. Develops and manages Asset
Management standards, plans and procedures and manages implementation
• Mounts an awareness campaign on procedures, controls Changes to Asset
Management methods and processes and communicates these to staff before being
implemented. The Service Asset Manager also oversees implementation of new Asset
Management Systems
• Manages the evaluation of proprietary Asset Management tools and recommends
suitable tools
• Agrees to which assets will be uniquely identified with naming conventions and
compliance
Configuration Manager
The Service Configuration Manager has the following responsibilities:

Page: - 129 -
ITIL V3 Foundations
• Works to the overall objectives agreed with the IT Services Manager; implements the
organization’s Configuration Management policy and standards
• Evaluates existing Configuration Management Systems, plan, implement and manage
Changed systems, and reporting on progress against plan
• Agrees scope of the Configuration Management processes. Develops and manages
Configuration Management standards, plans and procedures and manage
implementation
• Mounts an awareness campaign on procedures, controls Changes to Configuration
Management methods and processes and communicates these to staff before being
implemented. The Configuration Manager also oversees implementation of new
Configuration Management Systems
• Manages the evaluation of proprietary Configuration Management tools and
recommends suitable tools
• Agrees assets to be uniquely identified with naming conventions and compliance
• Plans population of the CMS. Manages CMS, central libraries, tools, common codes and
data. Ensures regular housekeeping of the CMS
• Provides reports, including management reports, impact analysis reports and
Configuration status reports

Page - 130 -
ITIL V3 Foundations
Release and Deployment Management
Release and Deployment Management aims to build, test and deliver the
capability to provide the services specified by Service Design and that will
accomplish the stakeholders’ requirements and deliver the intended
objectives.
The scope of Release and Deployment Management includes the

processes, systems and functions to package, build, test and deploy a
release into production and establish the service specified in the Service
Design package before final handover to service operations.
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
• Ensure that organization and stakeholder change is managed during the release and
deployment activities
• Record and manage deviations, risks, issues related to the new or changed service and
take necessary corrective action
• Ensure that there is knowledge transfer to enable the customers and users to optimize
their use of the service to support their business activities
• Ensure that skills and knowledge are transferred to operations and support staff to
enable them to effectively and efficiently deliver, support and maintain the service
according to required warranties and service levels.

Page: - 131 -
ITIL V3 Foundations
The scope of Release and Deployment Management includes the processes, systems and
functions to package, build, test and deploy a release into production and establish the
service specified in the Service Design package before final handover to service operations.
Basic Concepts - Release and Deployment Management
Release: A collection of hardware, software, documentation, processes or

other components required to implement one or more approved Changes to
IT Services
Release Unit: A ‘release unit’ describes the portion of a service or IT

infrastructure that is normally released together according to the
organization’s release policy.
Release Packages: Release packages are planned and designed to be

built, tested, delivered, distributed and deployed into the live environment in
a manner that provides the agreed levels of traceability, in a cost-effective
and efficient way.
Release:
A collection of hardware, software, documentation, processes or other components required
to implement one or more approved Changes to IT Services
Release Unit
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 general aim is to decide the most appropriate release unit level for each service asset or
component. An organization may, for example, decide that the release unit for business
critical applications is the complete application in order to ensure that testing is
comprehensive. The same organization may decide that a more appropriate release unit for
a website is at the page level.
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

Page - 132 -
ITIL V3 Foundations
• 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.
Release packages: Release packages are planned and designed to be built, tested,
delivered, distributed and deployed into the live environment in a manner that provides the
agreed levels of traceability, in a cost-effective and efficient way.

Page: - 133 -
ITIL V3 Foundations
Deployment Approach
Big Bang
Phased
Push
Pull
Automation
Manual
‘Big bang’ vs 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 rollout plan.
This will be the case in many scenarios such as in retail organizations for new services being
introduced into the stores’ environment in manageable phases.
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 bigbang 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.

Page - 134 -
ITIL V3 Foundations
Automation vs manual
Whether by automation or other means, the mechanisms to release and deploy the correctly
configured service components should be established in the release design phase and
tested in the build and test stages.
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 or capacity issues
that affect the service levels

Page: - 135 -
ITIL V3 Foundations
Service V Model
The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact,
just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD
approaches. Within each cycle of the iterative development, the V-model concepts of
establishing acceptance requirements against the requirements and design can apply, with
each iterative design being considered for the degree of integrity and competence that would
justify release to the customer for trial and assessment.
The test strategy defines the overall approach to validation and testing. It includes the
organization of validation and testing activities and resources and can apply to the whole
organization, a set of services or an individual service
Various controlled environments will need to be built or made available for the different types
and levels of testing as well as to support other transition activities such as training. Existing
deployment processes and procedures can be used to build the controlled test
environments. The environments will need to be secure to ensure there is no unauthorized
access and that any segregation of duty requirements are met.

Page - 136 -
ITIL V3 Foundations
Knowledge Management
The purpose of Knowledge Management is to ensure that the right

information is delivered to the appropriate place or competent person at the
right time to enable informed decision.
The goal of Knowledge Management is to enable organizations to improve

the quality of management decision making by ensuring that reliable and
secure information and data is available throughout the service lifecycle.
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 use of those
services
• Ensuring that, at a given time and location, service provider staff have adequate
information on:
o Who is currently using their services
o The current states of consumption
o Service delivery constraints
o Difficulties faced by the customer in fully realizing the benefits expected from the
service
Knowledge Management is a whole lifecycle-wide process in that it is relevant to all lifecycle

sectors and hence is referenced throughout ITIL from the perspective of each publication. It
is dealt with to some degree within other ITIL publications but this chapter sets out the basic
concept, from a Service Transition focus.

Page: - 137 -
ITIL V3 Foundations
Knowledge Management – Concept DIKW
WISDOM
Why
KNOWLEDGE
How?
CONTEXT
INFORMATION
Who, What,
When, Where
DATA
Knowledge Management is typically displayed within the Data–to–Information–to–

Knowledge–to–Wisdom (DIKW) structure. The use of these terms is set out below.
Data is a set of discrete facts about events. Most organizations capture significant amounts
of data in highly structured databases such as Service Management and Configuration
Management tools/systems and databases.
The key Knowledge Management activities around data are the ability to:
• Capture accurate data
• Analyse, 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, re-use 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 judgements 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

Page - 138 -
ITIL V3 Foundations
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 judgement.

Page: - 139 -
ITIL V3 Foundations
Service Knowledge Management Systems
Service Knowledge Management System

Known Error
Database
(KEDB)
Multiple CMDBs
Secure libraries and
CMS secure stores
Definitive Media Library
CI’s Definitive spares Security
Attributes Capacity Mgt Management
Configuration baselines Information
Relationships Information
Snapshots System (CMIS) System (SMIS)
Service Configurations
Availability Mgt Supplier and

Service Service Desk Information Contracts
Portfolio System System (AMIS) Database
(SCD)
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
Configuration Management 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, e.g. weather, user numbers and behaviour, organization’s
performance figures
• Suppliers’ and partners’ requirements, abilities and expectations
• Typical and anticipated user skill levels.
This slide is a very simplified illustration of the relationship of the three levels, with data
being gathered within the CMDB, and feeding through the CMS into the SKMS and
supporting the informed decision making process.

Page - 140 -
ITIL V3 Foundations
Unit 7 – Service Operation
Goal
Basic concepts
Main Activities
Processes

Page: - 141 -
ITIL V3 Foundations
Continual

Support Process
Service Asset and

Service Testing and

Validation
Technology
Management
Application
Management
Management
Functions
Facilities
Management

Page - 142 -
ITIL V3 Foundations
Service Operation Goal
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.
The purpose of Service Operation is to coordinate and carry out the activities and processes
required to deliver and manage services at agreed levels to business users and customers.
Service Operation is also responsible for the ongoing management of the technology that is
used to deliver and support services. Well-designed and well-implemented processes will be
of little value if the day-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.
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 the direct scope of
Service Operation; however, Service Operation provides input and influences these regularly
as part of the lifecycle of Service Management.

Page: - 143 -
ITIL V3 Foundations
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 this publication 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

Page - 144 -
ITIL V3 Foundations
Value to Business
Actual delivery of Services

Relationship with and satisfaction of Customers is improved
Provision of what is required by the Business is provided and planned for
From Customer viewpoint, it is where actual value is seen
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 are
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.
There is a down side to this, though:
Once a service has been designed and tested, it is expected to run within the budgetary and
Return on Investment targets established earlier in the lifecycle. In reality, however, very few
organizations plan effectively for the costs of ongoing management of services. It is very
easy to quantify the costs of a project, but very difficult to quantify what the service will cost
after three years of operation. It is difficult to obtain funding during the operational phase, to
fix design flaws or unforeseen requirements – since this was not part of the original value
proposition. In many cases it is only after some time in operation that these problems
surface. Most organizations do not have a formal mechanism to review operational services
for design and value. This is left to Incident and Problem Management to resolve – as if it is
purely an operational issue.
It is difficult to obtain additional funding for tools or actions (including training) aimed at
improving the efficiency of Service Operation. This is partly because they are not directly
linked to the functionality of a specific service and partly because there is an expectation
from the customer that these costs should have been built into the cost of the service from
the beginning. Unfortunately, the rate of technology change is very high. Shortly after a

Page: - 145 -
ITIL V3 Foundations
solution has been deployed that will efficiently manage a set of services, new technology
becomes available that can do it faster, cheaper and more effectively.
Once a service has been operational for some time, it becomes part of the baseline of what
the business expects from the IT services. Attempts to optimize the service or to use new
tools to manage it more effectively are seen as successful only if the service has been very
problematic in the past. In other words, some services are taken for granted and any action
to optimize them is perceived as ‘fixing services that are not broken’.

Page - 146 -
ITIL V3 Foundations
Communication
Good communication is needed with other IT teams and departments, with

users and internal customers, and between the Service Operation teams
and departments themselves.
Different organizations communicate in different ways. There are some

types of communication:
– The Operations meeting
– Department, group or team meetings
– Customer meetings
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.
Meetings
The purpose of meetings is to communicate effectively to a group of people about a common
set of objectives or activities. Meetings should be well controlled and brief, and the focus
should be on facilitating action. A good rule is not to hold a meeting if the information can be
communicated effectively by automated means.
The Operations meeting

Operations meetings are normally held between the managers of the IT operational
departments, teams or groups, at the beginning of each business day or week. The purpose
of this type of meeting is to make staff aware of any issue relevant to Operations (such as
change schedules, business events, maintenance schedules, etc.) and to provide an
opportunity for staff to raise any issues of which they are aware. This is an opportunity to
ensure that all departments in a data centre are synchronized.
Department, group or team meetings

These meetings are essentially the same as the Operations meeting, but are aimed at a
single IT department, group or team. Each manager or supervisor relays the information

Page: - 147 -
ITIL V3 Foundations
from the Operations meeting that is relevant to their team. Additionally, these meetings will
also cover the following:
A more detailed discussion of incidents, problems and changes that are still being worked
on, with information about:
• Progress to date
• Confirmation of what still needs to be done
• Estimated completion times
• Request for additional resources, if required
• Discussion of potential problems or concerns
• Confirmation of staff availability for roster duties
• Confirmation of vacation schedules.
Customer meetings
From time to time it will be necessary to hold meetings with customers, apart from the
regular Service Level Review meetings. Examples include:
Follow-up after serious incidents. The purpose of these meetings is to repair the relationship
with the customers, but also to ensure that IT has all the information required to prevent
recurrence. Customers also have the opportunity to provide information about unforeseen
business impacts. These meetings are helpful in agreeing actions for similar types of
incident that may occur in future.
A customer forum, which can be used for a range of purposes, including testing ideas for
new services or solutions, or gathering requirements for new or revised services or
procedures. A customer forum is generally a regular meeting with customers to discuss
areas of common concern.

Page - 148 -
ITIL V3 Foundations
Balance in Service Operation
Internal IT view versus external business view

Stability versus responsiveness
Reactive versus Proactive
Quality of Service versus Cost of Service
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.
This section of the publication 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 towards 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.

Page: - 149 -
ITIL V3 Foundations
Service Operational: Internal IT view versus external

business view
An organization here is An organization here is

out of balance and is quite balanced, but tends
danger of not meeting to under-deliver on
business requirements promises to the business
Extreme focus Extreme focus

on Internal on External
The most fundamental conflict in all phases of the ITSM 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 ‘its’ 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 cannot 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 itself in a position along a spectrum between the two.

Page - 150 -
ITIL V3 Foundations
Service Operational: Stability versus responsiveness
An organization here is
out of balance and is in An organization here is
danger of ignoring quite balanced, but may
changing business tend to overspend on
requirements change
Extreme focus Extreme focus on

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

Page: - 151 -
ITIL V3 Foundations
Service Operation: Reactive versus Proactive
This table compares reactive versus proactive approaches to Service Operation.
Approach Description Risks

Responding to business needs and incidents only
after they are reported can cause delivery of new
A reactive organization does services to take a long time because each project
not act unless it is prompted is dealt with as if it is the first occurrence. Staff
Reactive
to do so by an external turnover tends to be high and morale is generally
driver. low, as IT staff keep moving from project to
project without achieving a lasting, stable set of
IT services.
Proactive behavior is usually seen as positive.
However,being too proactive can be expensive
A proactive organization is and can result in staff being distracted.
Proactive always looking for ways to Discouraging effort investment in proactive
improve the current situation. service management can ultimately increase the
effort and cost of reactive activities and further
risk stability and consistency in services.
A reactive organization is one which does not act unless it is prompted to do so by an

external driver, e.g. a new business requirement, an application that has been developed or
escalation in complaints made by users and customers. An unfortunate reality in many
organizations is the focus on reactive management mistakenly as the sole means to ensure
services that are highly consistent and stable, actively discouraging proactive behaviour 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 behaviour 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 behaviour often achieves the optimal
result.
Generally, it is better to manage IT services proactively, but achieving this is not easily
planned or achieved. This is because building a proactive IT organization is dependent on
many variables, including:
• The maturity of the organization. The longer the organization has been delivering a
consistent set of IT services, the more likely it is to understand the relationship between
IT and the business and the IT Infrastructure and IT services.

Page - 152 -
ITIL V3 Foundations
• The culture of the organization. Some organizations have a culture that is focused on
innovation and are more likely to be proactive. Others are more likely to focus on the
status quo and as such are likely to resist change and have more reactive focus. The
role that IT plays in the business and the mandate that IT has to influence the strategy
and tactics of the business. For example, a company where the CIO is a board member
is likely to have an IT organization that is far more proactive and responsive than a
company where IT is seen as an administrative overhead.
• The level of integration of management processes and tools. Higher levels of integration
will facilitate better knowledge of opportunities.
• The maturity and scope of Knowledge Management in the organization; this is especially
seen in organizations which have been able to store and organize historical data
effectively – especially Availability and Problem Management data.
While proactive behaviour in Service Operation is generally good, there are also times where
reactive behaviour is needed. The role of Service Operation is therefore to achieve a
balance between being reactive and proactive.
This will require:

• Formal Problem Management and Incident Management processes, integrated between
Service Operation and Continual Service Improvement.
• The ability to be able to prioritize technical faults as well as business demands. This
needs to be done during Service Operation, but the mechanisms need to be put in place
during Service Strategy and Design. These mechanisms could include incident
categorization systems, escalation procedures and tools to facilitate impact assessment
for changes.
• Data from Configuration and Asset Management to provide data where required, saving
projects time and making decisions more accurate.
• Ongoing involvement of SLM in Service Operation.

Page: - 153 -
ITIL V3 Foundations
Service Operation: Quality of Service versus Cost of Service
Service Operation is required to consistently deliver the agreed upon level of service.
Service Operation must keep costs and resource utilization at an optimal level. An increase
in the level of quality usually results in an increase in the cost of service. The relationship
between quality and cost of service is not always directly proportional.
For example, improving service availability from 55% to 75% could be straightforward and
might not require a huge investment. However, improving availability of the same service
from 96% to 99.9% might require large investments in high-availability technology 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 slide, 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 be made only once. For example, once a
duplicate software tool has been eliminated, it cannot be eliminated again for further cost
savings.
Achieving an optimal balance between cost and quality 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 it is prepared to live with the
lower quality of an administrative tool.

Page - 154 -
ITIL V3 Foundations
Determining the appropriate balance of cost and quality should be done during the Service
Strategy and Service Design Lifecycle phases, although in many organizations it is left to the
Service Operation teams – many of whom do not generally have all the facts or authority to
be able to make this type of decision.

Page: - 155 -
ITIL V3 Foundations
Basic Concepts - Service Operation
Alert: A warning that a threshold has been reached, something has

changed, or a Failure has occurred.
Event: An event can be defined as any detectable or discernible 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
Incident: An unplanned interruption to an IT service or reduction in the

quality of an IT service. Failure of a configuration item that has not yet
impacted service is also an incident.

Page - 156 -
ITIL V3 Foundations
Basic Concepts - Service Operation
Service Request: A request from a User for information, or advice, or for a

Standard Change or for Access to an IT Service.
Problem: A cause of one or more Incidents.
Workaround: A temporary way of overcoming the difficulties

Page: - 157 -
ITIL V3 Foundations
Service Operations Functions

IT Operations
Management
Technical IT Operations Application

Service Desk Control
Management Management
Console Management
Job Scheduling Financial
Mainframe
A function is a logical Backup and Restore Apps
Print and Output
concept that refers to the
HR
Server
people and automated Apps
Facilities
measures that execute a Management Business
Network
Apps
defined process, an activity Data Centres
Recovery Sites
or a combination of Consolidation
Storage ...
Contracts
processes or activities.
...
Function: A function is a logical concept that refers to the people and automated measures
that execute a defined process, an activity or a combination of processes or activities. In
larger organizations, a function may be broken out and performed by several departments,
teams and groups, or it may be embodied within a single organizational unit (e.g. Service
Desk). In smaller organizations, one person or group can perform multiple functions – e.g. a
Technical Management department could also incorporate the Service Desk function
The Service Operation functions are needed to manage the ‘steady state’ operational IT
environment. 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 are examples of typical groups of activities performed by Technical Management
and are not a suggested organization structure.

Page - 158 -
ITIL V3 Foundations
Service Desk
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.
The Service Desk is the primary point of contact for users when there is a service
disruption, for service requests or even for some categories of Request for Change. The
Service Desk provides a point of communication to the users and a point of coordination for
several IT groups and processes. To enable them to perform these actions effectively the
Service Desk is usually separate from the other Service Operation functions. In some cases,
e.g. where detailed technical support is offered to users on the first call, it may be necessary
for Technical or Application Management staff to be on the Service Desk. This does not
mean that the Service Desk becomes part of the Technical Management function. In fact,
while they are on the Service Desk, they cease to be a part of the Technical Management or
Application Management functions and become part of the Service Desk, even if only
temporarily.

Page: - 159 -
ITIL V3 Foundations
Service Desk organizational structure
There are many ways of structuring Service Desks and locating them – and the correct
solution will vary for different organizations. The primary options are detailed below, but in
reality an organization may need to implement a structure that combines a number of these
options in order to fully meet the business needs:
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 are tied up waiting to deal with
incidents when the volume and arrival rate of calls may not justify this. There may, however,
be some valid reasons for maintaining a local desk, even where call volumes alone do not
justify this. Reasons might include:
• Language and cultural or political differences

• Different time zones
• Specialized groups of users
• The existence of customized or specialized services that require specialist knowledge
• VIP/criticality status of users.
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
great familiarization through more frequent occurrence of events. It might still be necessary

Page - 160 -
ITIL V3 Foundations
to maintain some form of ‘local presence’ to handle physical support requirements, but such
staff can be controlled and deployed from the central 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.
Follow the Sun

Some global or international organizations may wish to combine two or more of their
geographically dispersed Service Desks to provide a 24-hour follow-the- un service. For
example, a Service Desk in Asia-Pacific may handle calls during its standard office hours
and at the end of this period it may hand over responsibility for any open incidents to a
European-based desk. That desk will handle these calls alongside its own incidents during
its standard day and then hand over to a USA-based desk – which finally hands back
responsibility to the Asia-Pacific desk to complete the cycle. This can give 24-hour coverage
at relatively low cost, as no desk has to work more than a single shift. However, the same
safeguards of common processes, tools, shared database of information and culture must
be addressed for this approach to proceed – and well-controlled escalation and handover
processes are needed.

Page: - 161 -
ITIL V3 Foundations
Service Desk Staffing
Staffing Levels:
How many? Where? At what time?
Skill Levels:
Technically Skilled/Technically Unskilled
Training Requirements:
Soft skills, Technical Skills, Tools, Business Awareness, Processes, etc.
Staff Retention:
Measures to Retain Staff: Rewards, Motivation, Training, etc.
Required Skills:
Communications, Soft Skills
Staffing levels
An organization must ensure that the correct number of staff are 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.
Skill levels
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. A range of
skill options are possible, starting from a ‘call-logging’ service only – where staff need only
very basic technical skills – right through to a ‘technical’ Service Desk where the
organization’s most technically skilled staff are used. In the case of the former, there will be
a high handling but low resolution rate, while in the latter case this will be reversed.
The decision on the required skills level will often be driven by target resolution times
(agreed with the business and captured in service level targets), the complexity of the
systems supported and ‘what the business is prepared to pay’.

Page - 162 -
ITIL V3 Foundations
Training
It is vital that all Service Desk staff are adequately trained before they are called upon to
staff the Service Desk. A formal induction programme should be undertaken by all new staff,
the exact content of which will vary depending upon the existing skill levels and experience
of the new recruit, but is likely to include many of the required skills as described above.
Where possible, a business awareness programme, including short periods of secondment

into key business areas, should be provided for new staff who do not already have this level
of business awareness.
Staff retention
It is very important that all IT Managers recognize the importance of the Service Desk and
the staff who work on it, and give this special attention. Any significant loss of staff can be
disruptive and lead to inconsistency of service – so efforts should be made to make the
Service Desk an attractive place to work.
Ways in which this can be done include proper recognition of the role with reward packages
recognizing this, team-building exercises, staff rotation onto other activities (projects,
second-line support, etc.).
The Service Desk can often be used as a stepping stone into other more technical or
supervisory/managerial roles. If this is done, care is needed to ensure that proper
succession planning takes place so that the desk does not lose all of its key expertise in any
area at one time. Also, good documentation and cross-training can mitigate this risk.

Page: - 163 -
ITIL V3 Foundations
Metrics
‘Hard’ measures:
The first-line resolution rate

Average time to resolve an incident (when resolved at first line)
Average time to escalate an incident (where first-line resolution is not
possible)
‘Soft’ measures:
How well the customers and users feel their calls have been answered
If the Service Desk operator was courteous and professional
If the Service Desk operator stilled confidence in the user.
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.
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.
An increase in the number of calls to the Service Desk can indicate less reliable services
over that period of time – but may also indicate increased user confidence in a Service Desk

Page - 164 -
ITIL V3 Foundations
that is maturing, resulting in a higher likelihood that users will seek assistance rather than try
to cope alone. For this type of metric to be reliable for reaching either conclusion, further
comparison of previous periods for any Service Desk improvements implemented since the
last measurement baseline, or service reliability changes, problems, etc. to isolate the true
cause for the increase is needed.

Page: - 165 -
ITIL V3 Foundations
Technical Management
It is the custodian of technical knowledge and expertise related to managing

the IT Infrastructure. In this role, Technical Management ensures that the
knowledge required to design, test, manage and improve IT services is
identified, developed and refined.
It provides the actual resources to support the 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.
Technical Management provides detailed technical skills and resources needed to support
the ongoing operation of the IT Infrastructure. Technical Management also plays an
important role in the design, testing, release and improvement of IT services. In small
organizations, it is possible to manage this expertise in a single department, but larger
organizations are typically split into a number of technically specialized departments. In
many organizations, the Technical Management departments are also responsible for the
daily operation of a subset of the IT Infrastructure.
By performing these two roles, Technical Management is able to ensure that the
organization has access to the right type and level of human resources to manage
technology and, thus, to meet business objectives. Defining the requirements for these roles
starts in Service Strategy and is expanded in Service Design, validated in Service Transition
and refined in Continual Service Improvement. Part of this role is also to ensure a balance
between the skill level, utilization and the cost of these resources. For example, hiring a top-
level resource at the higher end of the salary scale and then only using that skill for 10% of
the time is not effective. A better Technical Management strategy would be to identify the
times that the skill is needed and then hire a contractor for only those tasks.
The objectives of Technical Management are to help plan, implement and maintain a stable
technical infrastructure to support the organization’s business processes through:
• Well designed and highly resilient, cost-effective technical topology

• The use of adequate technical skills to maintain the technical infrastructure in optimum
condition

Page - 166 -
ITIL V3 Foundations
• Swift use of technical skills to speedily diagnose and resolve any technical failures that
do occur.

Page: - 167 -
ITIL V3 Foundations
IT Operations Management
IT Operations Management is responsible for executing the activities and

performance standards defined during Service Design and tested during
Service Transition. This function are divided in:
– Operations Control, which oversees the execution and monitoring of

the operational activities and events in the IT Infrastructure. This can be
done with the assistance of an Operations Bridge or Network Operations
Centre
– 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
In business, the term ‘Operations Management’ is used to 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 centres and fleet movements within a logistics organization.
The role of Operations Management is to execute the ongoing activities and procedures
required to manage and maintain the IT Infrastructure so as to deliver and support IT
Services at the agreed levels, which are summarized here:
Operations Control, which oversees the execution and monitoring of the operational
activities and events in the IT Infrastructure. This can be done with the assistance of an
Operations Bridge or Network Operations Centre. In addition to executing routine tasks from
all technical areas, Operations Control also performs the following specific tasks:
• Console Management, which refers to defining central observation and monitoring

capability and then using those consoles to exercise monitoring and control
activities
• Job Scheduling, or the management of routine batch jobs or scripts
• 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

Page - 168 -
ITIL V3 Foundations
• 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. Facilities Management also includes the
coordination of large-scale consolidation projects, e.g. Data Centre consolidation or
server consolidation projects. In some cases the management of a data centre is
outsourced, in which case Facilities Management refers to the management of the
outsourcing contract.

Page: - 169 -
ITIL V3 Foundations
Application Management
Application Management is responsible for managing applications

throughout their lifecycle:
It is the custodian of technical knowledge and expertise related to managing

applications, working together with Technical Management, ensures that the
knowledge required to design, test, manage and improve IT services is identified,
developed and refined.
Application Management provides the actual resources to support the ITSM

Lifecycle. In this role, Application Management ensures that resources are effectively
trained and deployed to design, build, transition, operate and improve the technology
required to deliver and support IT services
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, it may be involved in development projects, but is not usually the
same as the Applications 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. In

this role Application Management, working together with Technical Management, ensures
that the knowledge required to design, test, manage and improve IT services is identified,
developed and refined.
It provides the actual resources to support the ITSM Lifecycle. In this role, Application
Management ensures that resources are effectively trained and deployed to design, build,
transition, operate and improve the technology required to deliver and support IT services
By performing these two roles, Application Management is able to ensure that the
organization has access to the right type and level of human resources to manage
applications and thus to meet business objectives. This starts in Service Strategy and is

Page - 170 -
ITIL V3 Foundations
expanded in Service Design, tested in Service Transition and refined in Continual Service
Improvement.
Service Operations Processes
Event Management
Incident Management
Problem Management
Request Fulfilment
Access Management

Page: - 171 -
ITIL V3 Foundations
Event Management
The ability to detect events, make sense of them and determine the
appropriate control action is provided by Event Management.
Event Management can be applied to any aspect of Service Management

that needs to be controlled and which can be automated.
Be careful with the difference between: Monitoring and Event Management
Effective Service Operation is dependent on knowing the status of the infrastructure and
detecting any deviation from normal or expected operation. This is provided by good
monitoring and control systems, which are based on two types of tools:
• active monitoring tools that poll key CIs to determine their status and availability. Any
exceptions will generate an alert that needs to be communicated to the appropriate tool
or team for action
• passive monitoring tools that detect and correlate operational alerts or communications
generated by CIs.
Event Management can be applied to any aspect of Service Management that needs to be
controlled and which can be automated. These include:
• Configuration Items:
• Some CIs will be included because they need to stay in a constant state (e.g. a switch on
a network needs to stay on and Event Management tools confirm this by monitoring
responses to ‘pings’).
• Some CIs will be included because their status needs to change frequently and Event
Management can be used to automate this and update the CMS (e.g. the updating of a
file server).
• Environmental conditions (e.g. fire and smoke detection)
• Software licence monitoring for usage to ensure optimum/legal licence utilization and
allocation
• Security (e.g. intrusion detection)
• Normal activity (e.g. tracking the use of an application or the performance of a server).
The difference between monitoring and Event Management

Page - 172 -
ITIL V3 Foundations
These two areas are very closely related, but slightly different in nature. Event Management
is focused on generating and detecting meaningful notifications about the status of the IT
Infrastructure and services. While it is true that monitoring is required to detect and track
these notifications, monitoring is broader than Event Management. For example, monitoring
tools will check the status of a device to ensure that it is operating within acceptable limits,
even if that device is not generating events. Put more simply, Event Management works with
occurrences that are specifically generated to be monitored. Monitoring tracks these
occurrences, but it will also actively seek out conditions that do not generate events.

Page: - 173 -
ITIL V3 Foundations
Roles
It is unusual for an organization to appoint an ‘Event Manager
The Role of the Service Desk

– Initial Support, Escalation, Communication
Role of Technical and Application Management

– Define, Manage Events
– Deal with Incidents and Problems Related to Event
IT Operations Management
– Event Monitoring, Provide Initial Response
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.

Page - 174 -
ITIL V3 Foundations
Incident Management
The 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 means service operation within SLA limits
Effective Service Operation is dependent on knowing the status of the infrastructure and
detecting any deviation from normal or expected operation. This is provided by good
monitoring and control systems, which are based on two types of tools:
• active monitoring tools that poll key CIs to determine their status and availability. Any
exceptions will generate an alert that needs to be communicated to the appropriate tool
or team for action
• passive monitoring tools that detect and correlate operational alerts or communications
generated by CIs.
Event Management can be applied to any aspect of Service Management that needs to be
controlled and which can be automated. These include:
• Configuration Items:
• Some CIs will be included because they need to stay in a constant state (e.g. a
switch on a network needs to stay on and Event Management tools confirm this
by monitoring responses to ‘pings’).
• Some CIs will be included because their status needs to change frequently and
Event Management can be used to automate this and update the CMS (e.g. the
updating of a file server).
• Environmental conditions (e.g. fire and smoke detection)
• Software licence monitoring for usage to ensure optimum/legal licence utilization and
allocation
• Security (e.g. intrusion detection)

Page: - 175 -
ITIL V3 Foundations
• Normal activity (e.g. tracking the use of an application or the performance of a
server).
The difference between monitoring and Event Management
These two areas are very closely related, but slightly different in nature. Event Management
is focused on generating and detecting meaningful notifications about the status of the IT
Infrastructure and services. While it is true that monitoring is required to detect and track
these notifications, monitoring is broader than Event Management. For example, monitoring
tools will check the status of a device to ensure that it is operating within acceptable limits,
even if that device is not generating events. Put more simply, Event Management works with
occurrences that are specifically generated to be monitored. Monitoring tracks these
occurrences, but it will also actively seek out conditions that do not generate events.

Page - 176 -
ITIL V3 Foundations
Incident Management Scope
Events which are communicated directly by users, either through the Service
Desk or through an interface from Event Management to Incident
Management tools.
Incidents can also be reported and/or logged by technical staff (if, for
example, they notice something untoward with a hardware or network
component they may report or log an incident and refer it to the Service Desk).
Incident Management includes any event which disrupts, or which could disrupt, a service.
This includes events which are communicated directly by users, either through the Service
Desk or through an interface from Event Management to Incident Management tools.
Incidents can also be reported and/or logged by technical staff (if, for example, they notice
something untoward with a hardware or network component they may report or log an
incident and refer it to the Service Desk). This does not mean, however, that all events are
incidents. Many classes of events are not related to disruptions at all, but are indicators of
normal operation or are simply informational.
Although both incidents and service requests are reported to the Service Desk, this does not
mean that they are the same. Service requests do not represent a disruption to agreed
service, but are a way of meeting the customer’s needs and may be addressing an agreed
target in an SLA. Service requests are dealt with by the Request Fulfilment process.

Page: - 177 -
ITIL V3 Foundations
Basic Concepts
Timescales: It must be agreed for all incident-handling stages based upon

the overall incident response and resolution targets within SLAs
Incident Model: An Incident Model is a way of pre-defining the steps that

should be taken to handle a process in an agreed way.
Major Incident: The highest Category of Impact for na Incident. A Major

Incident results in significant disruption to the Business.
Priority: The result of Impact x Urgency
Timescales
Timescales must be agreed for all incident-handling stages (these will differ depending upon
the priority level of the incident) – based upon the overall incident response and resolution
targets within SLAs – and captured as targets within OLAs and Underpinning Contracts
(UCs). All support groups should be made fully aware of these timescales. Service
Management tools should be used to automate timescales and escalate the incident as
required based on
pre-defined rules.
Incident Models
Many incidents are not new – they involve dealing with something that has happened before
and may well happen again. For this reason, many organizations will find it helpful to pre-
define ‘standard’ Incident Models – and apply them to appropriate incidents when they
occur. An Incident Model is a way of pre-defining the steps that should be taken to handle a
process (in this case a process for dealing with a particular type of incident) in an agreed
way. Support tools can then be used to manage the required process. This will ensure that
‘standard’ incidents are handled in a pre-defined path and within pre-defined timescales.
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.
Where necessary, the major incident procedure should include the dynamic establishment of
a separate major incident team under the direct leadership of the Incident Manager,

Page - 178 -
ITIL V3 Foundations
formulated to concentrate on this incident alone to ensure that adequate resources and
focus are provided to finding a swift resolution. If the Service Desk Manager is also fulfilling
the role of Incident Manager (say in a small organization), then a separate person may need
to be designated to lead the major incident investigation team – so as to avoid conflict of
time or priorities – but should ultimately report back to the Incident Manager.

Page: - 179 -
ITIL V3 Foundations
Event WEB Technical User Phone

Process: Managment Interface Staff Call
Incident identification
& logging
Incident Categorization
Service Yes To Request

Request? Fulfilment
No
Incident Priorization
Major Incident Yes Major

Procedure Incident?
No
Initial Diagnosis
Investigation and
Diagnosis
Resolution
And Recovery
Incident Closure
The process to be followed during the management of an Incident includes the following
steps:
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. Ideally, incidents should be resolved before they have an impact on
users!
Incident logging
All incidents must be fully logged and date/time stamped, regardless of whether they are
raised through a Service Desk telephone call or whether automatically detected via an event
alert.
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. This will be important later when looking at incident
types/frequencies to establish trends for use in Problem Management, Supplier
Management and other ITSM activities
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

Page - 180 -
ITIL V3 Foundations
urgency of the incident (how quickly the business needs a resolution) and the level of impact
it is causing. An indication of impact is often (but not always) the number of users being
affected. In some cases, and very importantly, the loss of service to a single user can have a
major business impact – it all depends upon who is trying to do what – so numbers alone is
not enough to evaluate overall priority!
Initial diagnosis
If the incident has been routed via the Service Desk, the Service Desk Analyst must carry
out initial diagnosis, typically while the user is still on the telephone – if the call is raised in
this way – to try to discover the full symptoms of the incident and to determine exactly what
has gone wrong and how to correct it. It is at this stage that diagnostic scripts and known
error information can be most valuable in allowing earlier and accurate diagnosis
Incident escalation
Functional escalation. As soon as it becomes clear that the Service Desk is unable to
resolve the incident itself (or when target times for first-point resolution have been exceeded
– whichever comes first!) the incident must be immediately escalated for further support.
Hierarchic escalation. If incidents are of a serious nature (for example Priority 1 incidents)
the appropriate IT managers must be notified, for informational purposes at least. Hierarchic
escalation is also used if the ‘Investigation and Diagnosis’ and ‘Resolution and Recovery’
steps are taking too long or proving too difficult.
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
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.

Page: - 181 -
ITIL V3 Foundations
Incident Management Roles
Incident Manager
Service Desk
2nd, 3nd, nth line (specialists)
Incident Manager
An Incident Manager has the responsibility for:
• Driving the efficiency and effectiveness of the Incident Management process

• Producing management information
• Managing the work of incident support staff (first- and second-line)
• Monitoring the effectiveness of Incident Management and making recommendations for
improvement
• 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 first, second and third line.
Second line
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

Page - 182 -
ITIL V3 Foundations
Third-line support will be provided by a number of internal technical groups and/or third-party
suppliers/maintainers.
Metrics
Total numbers of Incidents (as a control measure)

Number and percentage of major incidents
Percentage of incidents handled within agreed response time (for example,
by impact and urgency codes)
Average cost per incident
Number of incidents reopened and as a percentage of the total
Percentage of Incidents closed by the Service Desk without reference to
other levels of support
The metrics that should be monitored and reported upon to judge the efficiency and
effectiveness of the Incident Management process, and its operation, will include:
• Total numbers of Incidents (as a control measure)

• Breakdown of incidents at each stage (e.g. logged, work in progress, closed etc)
• Size of current incident backlog
• Number and percentage of major incidents
• Mean elapsed time to achieve incident resolution or circumvention, broken down by
impact code
• Percentage of incidents handled within agreed response time (incident response-time
targets may be specified in SLAs, for example, by impact and urgency codes)
• Average cost per incident
• Number of incidents reopened and as a percentage of the total
• Number and percentage of incidents incorrectly assigned
• Number and percentage of incidents incorrectly categorized
• Percentage of Incidents closed by the Service Desk without reference to other levels of
support (often referred to as ‘first point of contact’)

Page: - 183 -
ITIL V3 Foundations
• Number and percentage the of incidents processed per Service Desk agent
• Number and percentage of incidents resolved remotely, without the need for a visit
• Number of incidents handled by each Incident Model
• Breakdown of incidents by time of day, to help pinpoint peaks and ensure matching of
resources.
Reports should be produced under the authority of the Incident Manager, 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.

Page - 184 -
ITIL V3 Foundations
Request Fulfilment
Request Fulfilment is the processes of dealing with Service Requests

from the users
To provide a channel for users to request and receive standard services

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 (e.g.
licences and software media)
To assist with general information, complaints or comments.
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. (e.g. 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) or maybe just a
question requesting information – but their scale and frequent, 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 Fulfilment is the processes of dealing with Service Requests from the users. The
objectives of the Request Fulfilment process include:
• 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 (e.g. licences and
software media)
• To assist with general information, complaints or comments.

Page: - 185 -
ITIL V3 Foundations
Basic concepts
Request Models
Some Service Requests will occur frequently and will require handling in a
consistent manner in order to meet agreed service levels. To assist this, many
organizations will wish to create pre-defined Request Model.
Standard Change can be handled as a Service Request!
Many Service Requests will be frequently recurring, so a predefined process flow (a model)
can be devised to include the stages needed to fulfil the request, the individuals or support
groups involved, target timescales and escalation paths. 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.
Request Models
Some Service Requests will occur frequently and will require handling in a consistent
manner in order to meet agreed service levels. To assist this, many organizations will wish to
create pre-defined Request Models (which typically include some form of pre-approval by
Change Management). This is similar in concept to the idea of Incident Models, but applied
to Service Requests

Page - 186 -
ITIL V3 Foundations
Request Fulfilment Roles
Service Desk staff

Staff in other functions
External Suppliers, as appropriate.
Initial handling of Service Requests will be undertaken by the Service Desk and Incident
Management staff. Eventual fulfilment 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 fulfilment of
the Service Request. In most cases there will be no need for additional roles or posts to be
created.
In exceptional cases where a very high number of Service Requests are handled, or where
the requests are of critical importance to the organization, it may be appropriate to have one
or more of the Incident Management team dedicated to handling and managing Service
Requests.

Page: - 187 -
ITIL V3 Foundations
Problem Management
The primary objectives of Problem Management are to prevent

problems and resulting incidents from happening, to eliminate recurring
incidents and to minimize the impact of incidents that cannot be prevented.
Additional value is derived from the following:
Higher availability of IT services

Higher productivity of business and IT staff
Reduced expenditure on workarounds or fixes that do not work
Reduction in cost of effort in fire-fighting or resolving repeat incidents
Problem Management includes the activities required to diagnose the root cause of incidents
and to determine the resolution to those problems. It is also responsible for ensuring that the
resolution is implemented through the appropriate control procedures, especially Change
Management and Release Management. Problem Management will also maintain
information about problems and the appropriate workarounds and resolutions, so that the
organization is able to reduce the number and impact of incidents over time. In this respect,
Problem Management has a strong interface with Knowledge Management, and tools such
as the Known Error Database will be used for both.
Although Incident and Problem Management are separate processes, they are closely
related and will typically use the same tools, and may use similar categorization, impact and
priority coding systems. This will ensure effective communication when dealing with related
incidents and problems.
Value to business
Problem Management works together with Incident Management and Change Management
to ensure that IT service availability and quality are increased. When incidents are resolved,
information about the resolution is recorded. Over time, this information is used to speed up
the resolution time and identify permanent solutions, reducing the number and resolution
time of incidents. This results in less downtime and less disruption to business critical
systems.

Page - 188 -
ITIL V3 Foundations
Basic concepts
Problem: “The unknown root cause of one or more Incidents”
Workaround: “A temporary way of overcoming technical difficulties (i.e.,

Incidents or Problems”)
Known Error: “Problem that has a documented Root Cause and a

Workaround”
Known Error Database (KEDB): “Database containing all Known Error

Records“
Problem Models: A way of predefining the steps that should be taken to

handle Incidents caused by a Known Error or an Error

Page: - 189 -
ITIL V3 Foundations
Problem Management Roles
Problem Manager
Problem-Solving Groups
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 KEDB
• 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 fulfil their contractual
obligations, especially with regard to resolving problems and providing problem-related
information and data
• Arranging, running, documenting and all follow-up activities relating to Major Problem
Reviews.

Page - 190 -
ITIL V3 Foundations
Problem-Solving Groups
The actual solving of problems is likely to be undertaken by one or more technical support
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.

Page: - 191 -
ITIL V3 Foundations
Access Management
Access Management provides the right for users to be able to use a service or
group of services. It is therefore the execution of policies and actions defined
in Security and Availability Management.
Access Management is effectively the execution of both Availability and Information Security
Management, in that it enables the organization to manage the confidentiality, availability
and integrity of the organization’s data and intellectual property.
Access Management ensures that users are given the right to use a service, but it does not
ensure that this access is available at all agreed times – this is provided by Availability
Management.
Access Management is a process that is executed by all Technical and Application

Management functions and is usually not a separate function. However, there is likely to be
a single control point of coordination, usually in IT Operations Management or on the Service
Desk. Access Management can be initiated by a Service Request through the Service Desk.

Page - 192 -
ITIL V3 Foundations
Basic concepts
Access
Identity
Rights
Services or service groups
Directory Services
Access Management is the process that enables users to use the services that are
documented in the Service Catalogue. It comprises the following basic concepts:
Access 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 them that distinguishes them as an individual and
which verifies their status within the organization. By definition, the Identity of a user is
unique to that user.
Rights (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 use only one service, and users performing
a similar set of activities will use a similar set of services. Instead of providing access to each
service for each user separately, it is more efficient to be able to grant each user – or group
of users – access to the whole set of services that they are entitled to use at the same time.
Directory Services refers to a specific type of tool that is used to manage access and rights

Page: - 193 -
ITIL V3 Foundations
Access Management Roles
Information Security Managers

– Define and Maintain Policies for this Process
Service Desk Staff

– Handle the Requests
Staff in other functions (e.g., Technical and Application Management)

– Execution of the Requests
It is unusual for an organization to appoint an ‘Access Manager’

Page - 194 -
ITIL V3 Foundations
Unit 8 – Continual Service Improvement
Goal
Basic concepts
Main Activities
Processes

Page: - 195 -
ITIL V3 Foundations
Continual

Support Process
Service Asset and

Service Testing and

Validation
Technology
Management
Application
Management
Management
Functions
Facilities
Management

Page - 196 -
ITIL V3 Foundations
Continual Service Improvement Goal
The primary purpose of 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.
The primary purpose of 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:
• Review, analyse and make recommendations on improvement opportunities in each

lifecycle phase: Service Strategy, Service Design, Service Transition and Service
Operation.
• Review and analyse Service Level Achievement results.

Page: - 197 -
ITIL V3 Foundations
• 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.

Page - 198 -
ITIL V3 Foundations
Scope
The continual alignment of the portfolio of IT services with the current and
future business needs
The overall health of ITSM as a discipline
The maturity of the enabling IT processes for each service in a continual

service lifecycle model.
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

Page: - 199 -
ITIL V3 Foundations
• 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 na ongoing continual improvement strategy for each of the processes
as well as the services.

Page - 200 -
ITIL V3 Foundations
Basic Concepts - Service Lifecycle
Service
Feedback
Strategy
Service
Feedback
Design
Service Feedback
Transition
Service
Operation
Continual Service Improvement

Page: - 201 -
ITIL V3 Foundations
Basic Concepts - Measurement for CSI
Why are measurements

performed?
To validate
To direct
To justify
To intervene
Basically, there are four reasons to monitor and 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?’

Page - 202 -
ITIL V3 Foundations
CSI Methods
Deming Cycle (PDCA)

CSI Model
7-Step Improvement Process
Vision to measurements

Page: - 203 -
ITIL V3 Foundations
Deming Cycle - PDCA
W. Edwards Deming is best known for his management philosophy leading to higher quality,
increased productivity, and a more competitive position. As part of this philosophy he
formulated 14 points of attention for managers. Some of these points are more appropriate
to service management than others. For quality improvement he proposed the Deming Cycle
or Circle.
This cycle is particularly applicable in CSI. The four key stages of the cycle are Plan, Do,
Check and Act, after which a phase of consolidation prevents the circle from rolling back
down the hill. Our goal in using the Deming Cycle is steady, ongoing improvement. It is a
fundamental tenet of Continual Service Improvement.
The Deming Cycle is critical at two points in CSI: implementation of CSIs, and for the
application of CSI to services and service management processes. At implementation, all
four stages of the Deming Cycle are used. With ongoing improvement, CSI draws on the
check and act stages to monitor, measure, review and implement initiatives. The cycle is
underpinned by a process-led approach to management where defined processes are in
place, the activities are measured for compliance to expected values and outputs are
audited to validate and improve the process.

Page - 204 -
ITIL V3 Foundations
CSI Model

Page: - 205 -
ITIL V3 Foundations
7-Step Improvement Process
Fundamental to CSI is the concept of measurement. CSI uses the 7-Step Improvement
Process shown in slide.
Which steps support CSI?
It is obvious that all the activities of the improvement process will assist CSI in some way. It
is relatively simple to identify what takes places but the difficulty lies in understanding exactly
how this will happen. The improvement process spans not only the management
organization but the entire service lifecycle. This is a cornerstone of CSI.
1. Define what you should measure

At the onset of the service lifecycle, Service Strategy and Service Design should have
identified this information. CSI can then start its cycle all over again at ‘Where are we now?’
This identifies the ideal situation for both the Business and IT.
2. Define what you can measure

This activity related to the CSI activities of ‘Where do we want to be?’ By identifying the new
service level requirements of the business, the IT capabilities (identified through Service
Design and implemented via Service Transition) and the available budgets, CSI can conduct
a gap analysis to identify the opportunities for improvement as well as answering the
question ‘How will we get there?’
3. Gathering the data

In order to properly answer the ‘Did we get there?’ question, data must first be gathered
(usually through Service Operations). Data is gathered based on goals and objectives
identified. At this point the data is raw and no conclusions are drawn.

Page - 206 -
ITIL V3 Foundations
4. Processing the data

Here the data is processed in alignment with the CSFs and KPIs specified. This means that
timeframes are coordinated, unaligned data is rationalized and made consistent, and gaps in
data are identified. The simple goal of this step is to process data from multiple disparate
sources into an ‘apples to apples’ comparison. Once we have rationalized the data we can
then begin analysis.
5. Analysing the data

Here the data becomes information as it is analysed to identify service gaps, trends and the
impact on business. It is the analysing step that is most often overlooked or forgotten in the
rush to present data to management.
6. Presenting and using the information

Here the answer to ‘Did we get there?’ is formatted and communicated in whatever way
necessary to present to the various stakeholders an accurate picture of the results of the
improvement efforts. Knowledge is presented to the business in a form and manner that
reflects their needs and assists them in determining the next steps.
7. Implementing corrective action

The knowledge gained is used to optimize, improve and correct services. Managers identify
issues and present solutions. The corrective actions that need to be taken to improve the
service are communicated and explained to the organization. Following this step the
organization establishes a new baseline and the cycle begins anew.
While these seven steps of measurement appear to form a circular set of activities, in fact,
they constitute a knowledge spiral In actual practice, knowledge gathered and wisdom
derived from that knowledge at one level of the organization becomes a data input to the
next.

Page: - 207 -
ITIL V3 Foundations
Vision from measurement
Once data is gathered, the next step is to process the data into the required format. Report-
generating technologies are typically used at this stage as various amounts of data are
condensed into information for use in the analysis activity. The data is also typically put into
a format that provides an end-to-end perspective on the overall performance of a service.
This activity begins the transformation of raw data into packaged information. Use the
information to develop insight into the performance of the service and/or processes. Process
the data into information (i.e. create logical groupings) which provides a better means to
analyse the data – the next activity step in CSI.
The output of logical groupings could be in spreadsheets, reports generated directly from the
service management tool suite, system monitoring and reporting tools, or telephony tools
such as an automatic call distribution tool. Processing the data is an important CSI activity
that is often overlooked. While monitoring and collecting data on a single infrastructure
component is important, it is also important to understand that component’s impact on the
larger infrastructure and IT service. Knowing that a server was up 99.99% of the time is one
thing, knowing that no one could access the server is another. An example of processing the
data is taking the data from monitoring of the individual components such as the mainframe,
applications, WAN, LAN, servers etc and process this into a structure of an end-to-end
service from the customer’s perspective.

Page - 208 -
ITIL V3 Foundations
Roles in CSI
CSI Manager
Responsible for communicating the vision of CSI across the IT organization

Works with the Service Owner to identify and prioritize improvement
opportunities
Works with the Service Level Manager to ensure that monitoring requirements
are defined and identity service improvement plans
Reviews analysed data
Presents recommendations to senior management for improvement
Helps prioritize improvement opportunities
This new role is essential for a successful improvement programme. 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 programme.
• 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 plans
• Ensures that monitoring tools are in place to gather data
• Ensures that baseline data is captured to measure improvement against it
• Defines and reports on CSI CSFs, KPIs and CSI activity metrics
• Identifies other frameworks, models and standards that will support CSI activities
• 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 analysed data

Page: - 209 -
ITIL V3 Foundations
• Presents recommendations to senior management for improvement
• Helps prioritize improvement opportunities
• Lead, manage and deliver cross-functional and cross-divisional improvement projects
• Build effective relationships with the business and IT senior managers
• Identify and deliver process improvements in critical business areas across
manufacturing and relevant divisions
• Set direction and provide framework through which improvement objectives can be
delivered
• Coach, mentor and support fellow service improvement professionals
• Possess 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.

Page - 210 -
ITIL V3 Foundations
Roles in CSI
Service Owner
Represents the service across the organization

Understands the service (components etc.)
Represents the service in Change Advisory Board meetings
Participates in internal service review meetings (within IT)
Works with the CSI Manager to identify and prioritize service improvement
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 Owner is responsible for:
• Service Owner for a specified service

• Provides input in service attributes such as performance, availability etc.
• Represents the service across the organization
• Understands the service (components etc.)
• Point of escalation (notification) for major Incidents
• Represents the service in Change Advisory Board meetings
• Provides input in CSI
• Participates in internal service review meetings (within IT)
• Works with the CSI Manager to identify and prioritize service improvement
• Participates in external service review meetings (with the business)
• Responsible for ensuring that the service entry in the Service Catalogue is accurate and
is maintained
• Participates in negotiating SLAs and OLAs.
The Service Owner is responsible for continual improvement and the management of
change affecting the services under their care.

Page: - 211 -
ITIL V3 Foundations
Interface with Service Level Management
SLM is critical to CSI

SLM initiates Service Improvement Programs and Service Quality Plans
Monitoring and measuring is a joint responsibility of SLM and CSI
SLM effort is about building and maintaining better relationships between IT
and its Customers
Service Level Management (SLM) is critical for CSI. SLM activities support The 7-Step
Improvement Process in that the SLM should drive what to measure, defining monitoring
requirements, reporting Service Level Achievements and working with the business to
understand new service requirements or changes to existing services. This provides input
into CSI activities and helps prioritize improvement projects. Even though SLM is critical for
many organizations it is often one of the least mature processes.
Service Level Management can be described in two words: building relationships. That is
building relations with IT customers, building relationships between functional groups within
IT, and building relationships with the vendor community who provide services to IT. Service
Level Management is so much more than simply a SLA. Many people have worked in
organizations where management and/or the business refuse to sign any document that will
commit anyone to a level of service. This leads many organizations to think that they cannot
implement Service Level Management, but they are wrong. You can still build relationships
with your customers by meeting with them on a consistent basis. Share with them your
Service Level Achievements, and discuss any future new services or requirements. Having
knowledge about what they need doesn’t necessarily mean they get it, but it is surely better
than not knowing what they need at all.

Page - 212 -
ITIL V3 Foundations
Risk Management
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.
There are two distinct phases:

Risk analysis
Risk management
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.

Page: - 213 -
ITIL V3 Foundations
This material was developed by
Renata Arruda (renatana@br.ibm.com)

Rosemeire Oikawa (roikawa@br.ibm.com)

Page - 214 -

ITIL V3 Foundations V3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ITIL V3 Foundations V3

Uploaded by

Copyright:

Available Formats

ITIL V3 Foundations V3

Unit Title Page

© Copyright 2009, IBM Brasil

© Copyright 2009, IBM Brasil

Renata Arruda (renatana@br.ibm.com)

© 2009 IBM Corporation

© Copyright 2009, IBM Brasil

2 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

© Copyright 2009, IBM Brasil

History of ITIL Computer Software Set

in Version 2 of ITIL® as a consolidated Software asset

framework for IT Service Management Application management

Version 3 released in 2007 establishes a

3 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

© Copyright 2009, IBM Brasil

Why ITIL is important?

Communications between IT departments should improve because the linkages between

© Copyright 2009, IBM Brasil

Adopt and Adapt

5 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

ITIL does not define:

© Copyright 2009, IBM Brasil

Planning to Implement Service

6 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

© Copyright 2009, IBM Brasil

ITIL V3 represents a significant milestone in

The initial five books should be available on 30 May 2007

7 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

ITIL V3 represents a significant milestone in the evolution of service management

© Copyright 2009, IBM Brasil

ITIL V3 Service Lifecycle

8 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

ITIL Publications Structure

© Copyright 2009, IBM Brasil

ITIL Qualification Scheme

9 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

© Copyright 2009, IBM Brasil

Unit 2 - Service Management as a Practice

10 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

© Copyright 2009, IBM Brasil

Services are a ‘means of delivering value to customers by

11 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

Services are a means of delivering value to customers by facilitating outcomes customers

© Copyright 2009, IBM Brasil

Definition of Service Management

Service Management is a set of specialized organizational capabilities

Intangible nature of the output

12 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

Service Management is a set of specialized organizational capabilities for providing value to

© Copyright 2009, IBM Brasil

A structured set of Activities designed to accomplish a specific Objective. A

Main characteristics of processes:

13 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

Business outcomes are produced by business processes governed by objectives, policies

Processes have the following characteristics:

© Copyright 2009, IBM Brasil

• Customers: Every process delivers its primary results to a customer or stakeholder.

• Responds to a specific event: While a process may be ongoing or iterative, it should

© Copyright 2009, IBM Brasil

ITIL Process Model

14 ITIL FOUNDATIONS V3 © 2009 IBM Corporation

© Copyright 2009, IBM Brasil

A set of responsibilities defined in a Process and assigned to a person or team.