ITIL Study Guide

ITIL Study Guide
By Robert Perrine
Fall 2004
Table of Contents
ITIL Study Guide ...........................................................................................................1
1. Revision History.................................................................................................3
2. Introduction.......................................................................................................4
3. Service Desk ......................................................................................................5
4. Incident Management ......................................................................................14
5. Problem Management ......................................................................................27
6. Configuration Management..............................................................................41
7. Change Management .......................................................................................55
8. Release Management .......................................................................................74
9. Service Level Management ...............................................................................92
10. Financial Management ...................................................................................105
11. Capacity Management....................................................................................114
12. IT Service Continuity Management .................................................................127
13. Availability Management ................................................................................138
2
1. Revision History
Date Version Author Description
26 Oct 2004 0.8 Robert Perrine First preliminary release for comment.
28-Oct-2004 0.9 Robert Perrine Wider distribution of this preliminary release.
29-Oct-2004 1.0 Robert Perrine Added Synopsis to each Process.
3
2. Introduction
I compiled this study guide to organize the ITIL Service Support and Service Delivery material
into a uniform format. This study guide is not a stand-alone publication, but simply an organized
synopsis of the contents in the ITIL guides. Wherever possible, text and images have been
directly copied from the ITIL publication. In copying text and images, my intent is not to break
copyright laws, but to create a supplement to the publications from the British OGC.
It is my understanding that teaching materials may contain up to 10% of a publication without

breaking the copyright laws in the United States of America. Also, the court system in the United
States of America tends to prevail on the concept that damage only occurs if there is a financial
loss. Thus, it is imperative that this material only be used in conjunction with a licensed copy of
the ITIL Service Support and Service Delivery guides. And it is imperative that no charge be
made for this material. I believe that by observing both of those precautions I am within the legal
bounds allowed by the copyright laws of the United States of America. If you have information
to the contrary, please notify me so that I may take action to correct any infringements.
As for this document, no warranty is offered or implied as to the suitable of this material for use.
If you find errors or discrepancies, please send an email and I will do my best to correct the
situation. Please understand that this is a voluntary work in progress.
Also, please remember that this is a supplement, not a replacement for the ITIL Service Delivery
and Service Support guides. While this material may aid your studies, I strongly emphasize the
importance of reading the actual OGC materials.
Robert Perrine
Robert.Perrine@cox.net
Fall 2004
Irvine, California, United States of America
4
3. Service Desk
Soft skills such as active listening
3.1.
3.1. Service Desk Synopsis Time tracking
Goals Reports
Global approach Work load analysis
Integrated
Handles incidents & Problems Activities
Provides interface to other processes Receiving calls & Customer liaison
Recording and tracking Incidents and complaints
Benefits
Benefits Customers informed
Improved Customer service, perception and satisfaction Initial assessment & attempt to resolve
Single point of contact Monitoring and escalation by SLA
Better-quality and speedier Full life-cycle
Improved teamwork and communication Communicate changes
Focused and proactive Coordinating support groups
Reduced negative Management information and recommendations
Better managed infrastructure Identify Problems
Improved usage of resources Highlight Customer training needs
Increased productivity of business personnel Confirm closure with Customer
Better management information Contribute to Problem diagnosis
Critical Success Factors Inputs

Business needs understood Data feeds (assets, etc)
Customer requirements understood Incidents: Desktop, Security, Network, System,
Investment in training Application & Operational
Service objectives, goals and deliverables clearly defined Requests for status
Service levels are practical, agreed, and regularly Questions
reviewed Service Requests
Benefits accepted by the business
Outputs
Key Performance Indicators Management Information and Monitoring
Number of requests Support: Desktop, Security, Network, System, Application
Requests taking most time & Operational
Request taking Customer longest time Third Party Support
Which Customers require the most support? Sales, Purchase, Contract & Account Management
Support
Possible Implementation Problems
Problems Communicate status and schedules
Unrealistic expectations
Back-door support options Manager’s Duties
Misaligned communications Coordinate distributed SD resources
Support the Service Management processes
Tools Implement Incident Management
Configuration Management Database Workload monitoring to manage staffing level
Service Catalog Management reporting
Service Level Agreements, Operational Level Agreements Conduct & analyze customer satisfaction surveys
and Underpinning Contracts Classification Process Reviews
Users Manual Review & revise SD tools & procedures
Support procedures
Notification and escalation lists Other Roles
Customer Surveys First Line, Second Line
Knowledge base including list of known errors
5
3.2.
3.2. Service Desk Goal Statement
The Service Desk extends the range of services and offers a more global-focused
approach, allowing business processes to be integrated into the Service Management
infrastructure. It not only handles incidents, Problems and questions, but also provides
an interface for other activities such as customer Change requests, maintenance
contracts, software licenses, Service Level Management, Configuration Management,
Availability Management, Financial Management for IT Services, and IT Service Continuity
Management.
3.3.
3.3. Service Desk Benefits
• Improved Customer service, perception and satisfaction
• Increased accessibility through a single point of contact, communication, and
information
• Better-quality and speedier turnaround of customer requests
• Improved teamwork and communication
• Enhanced focus and a proactive approach to service provision
• A reduced negative business impact
• Better managed infrastructure and control
• Improved usage of IT support resources and increased productivity of business
personnel
• More meaningful management information for decision support” (SS 4.1.8)
3.4.
3.4. Service Desk Critical Success Factors
• Business needs are understood
• Customer requirements are understood
• Investment is made in training for Customers, support teams and Service Desk
staff
• Service objectives, goals and deliverables are clearly defined
• Service levels are practical, agreed, and regularly reviewed
• The benefits are accepted by the business (SS 4.10.1)
3.5.
3.5. Service Desk Key Performance
Performance Indicators
• "The number of requests being handled by the Service Desk, with this initially
needing to take into account requests passed directly to second-line support
groups
• The types of request that staff are spending the most time on, such as
• Equipment failures
• Business application problems
• Telecommunications
• Customer queries
• Installations/upgrades
• The types of request that are taking the longest time to turnaround to the
Customer by:
• First-line support
6
• Second-line internal support groups
• Third-party support groups
• Suppliers
• Which Customers require the most support, and in which areas – this information
can be used to develop training programs for both Customer staff and Service
Desk and support staff" (SS 4.4.7)
3.6.
3.6. Service Desk Possible Implementation
Implementation Problems
• Unrealistic expectations
• Charging can cause the Users to find back-door support options
• Misaligned communications
3.7.
3.7. Service Desk Tools
• Configuration Management Database
• Service Catalog
• Service Level Agreements, Operational Level Agreements and Underpinning
Contracts
• Users Manual
• Support procedures
• Notification and escalation lists
• Customer Surveys
• Knowledge base including list of known errors
• Soft skills such as active listening
• Time tracking
• Reports
• Work load analysis
3.8.
3.8. Service Desk Inputs and Outputs
Outputs
When fully implemented the Service Desk will serve as the single interface for IS Users.
The following diagram illustrates the types of inputs and outputs into the Service Desk.
Inputs:
• Data feeds (assets, etc)

• Incidents: Desktop, Security, Network, System, Application & Operational
• Requests for status
• Questions
• Service Requests
• Incident product purchases
• Application queries
• Requests for equipment moves, installations, upgrades and
enhancements
• Requests for consumables
Outputs:
• Management Information and Monitoring

• Support: Desktop, Security, Network, System, Application & Operational
7
• Third Party Support
• Sales, Purchase, Contract & Account Management Support
• Communicate status and schedules
Activities:
• "Receiving calls, first-line Customer liaison

• Recording and tracking Incidents and complaints
• Keeping Customers informed on request status and progress
• Making an initial assessment of requests, attempting to resolve them or refer
them to someone who can, based on agreed service levels
• Monitoring and escalation procedures relative to the appropriate SLA
• Managing the request life-cycle, including closure and verification
• Communicating planned and short-term changes of service levels to Customers
• Coordinating second-line and third-party support groups
• Providing management information and recommendations for service
improvement
• Identifying Problems
• Highlighting Customer training and education needs
• Closing Incidents and confirmation with the Customer
• Contributing to Problem identification" (SS 4.4.1)
3.8.1. Service Desk Inputs and Outputs Diagram
8
3.8.2. Service Desk Inputs and Outputs Description
Interface Description
Data feeds (assets, The Service Desk is the communications center for the users and for IS
etc) Support. It is the hub of multiple types of data, including Security,
Security Incidents Network, System, Application and other Operational Incidents. It is also
Network & System the recipient of multiple types of communication including automated
Incidents interfaces, manual data interfaces and human interfaces.
Application Incidents • Automated monitoring will feed Incidents into the Service Desk.
Operational Where possible, those Incidents feeds should be directly
Incidents integrated into the Configuration Management Database (CMDB)
in order to automatically create new Incident Records.
• Where the automated monitoring cannot be interfaced, the
Service Desk will be called upon to read emails, browse
monitoring consoles and check web pages to find data and then
manually create Incident Records.
• Additionally, the Service Desk is the primary interface for both
users and IS support. Phone calls and emails from users and IS
support must be processed manually and keyed into the CMDB to
create new Incident Records.
Service Desk The Service Desk is an organization with multiple responsibilities. Those
responsibilities are documented within the ITIL processes. The primary
responsibility is the implementation of the Incident Management
process.
Management As the communications center for IS, the Service Desk is the
Information and organization responsible for ensuring that all Incidents are recorded in
Monitoring the CMDB as Incident Records. That consolidation allows management to
quickly assess the health of the organization and examine trends.
Desktop Support The Service Desk is a two-way communications center. Incidents that
Network Support cannot be managed within the Service Desk are escalated outward
Application Support functionally to support groups and hierarchically to management.
Systems & The Service Desk also provides the interface between the technical
Operations Support support teams and the users for status updates, to facilitate diagnosis,
to implement work-arounds and other activities as required supporting
the ITIL processes.
Third Party Support When escalations and implementations are managed by third party
support companies, the Service Desk is the organization called on to
facilitate communication. This activity is simply an extension of the
communication described above for IS support.
9
Sales, Purchase, As the single point of contact for the user community, the Service Desk
Contract & Account is also called upon to provide communications for other processes.
Management These other communications should be documented as Service Requests
Support so that there is a clear distinction between the support of the
infrastructure and the support of the users.
3.9.
3.9. Service Desk as a Function
Service Desk is a Function and not a Process. The primary function of Service Desk is to
implement the Incident Management process. Please refer to the description of Incident
Management and review that process flow as that process flow is the focus of the Service
Desk.
3.10.
3.10. Service Desk Relationships with other Service Management Processes
Service Desk with
with Incident Management
Service Desk can be the customer interface to the ITIL processes (2.11)
Service Desk can implement Incident Management (2.11)
Service Desk can provide life-cycle management of Incidents including: receive, record, classify, prioritize,
triage, notify, escalate, track, communicate status and report.
Tools, such as the list of Known Errors, used by Service Desk also support Incident Management.
Second level and third level Incident Management may be outside the Service Desk.
Service Desk should document issues that impact the SLA.
Service Desk should define the relationship to "Super Users".
Service Desk should implement and publish customer satisfaction surveys.
Service Desk can feed Incidents into the Incident Management process
Service Desk is responsible for the monitoring and resolution of all Incidents
Second level and third level Incident Management may be outside the Service Desk.
Service Desk is responsible for registering all Incidents
The Service Desk will generally be responsible for Incident resolution and often handles up to 85% of the
Incidents
The Service Desk monitors the progress on all registered Incidents
Service Desk assigns the Priority
It is recommended that all five Service Support processes and the Service Desk be implemented as a unit
Incident closure should be handled by the Service Desk even if the resolution was determined outside of
the Service Desk
Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the
Configuration Management Database so that that records can be shared (2.9)
Changes may create new Incidents (2.9)
There should be a close interface between Incident, Problem, Change Management and the Service Desk
(2.9)
Service Desk with Problem Management
Service Desk can be the customer interface to the ITIL processes.

Service Desk interfaces with Problem Management include Problem identification, escalation and
enforcement of SLA/OLA requirements.
Service Desk should escalate to Problem Management when it is unclear how to proceed with Incident
10
Service Desk with Problem Management
Management.
Problem Management must only accept Problems from the Service Desk or the Service Desk will loose
control of the process
Service Desk is responsible for disseminating the information about the work-around or resolution once
Problem Management defines it
Problem Management must be kept separate from the Service Desk due to conflicts in interests.
Service Desk with Configuration Management

Service Desk should be integrated with Configuration Management.
Service Desk is dependent on the Configuration Management tools.
Service Desk with Change Management
Service Desk can be the customer interface to the ITIL processes (2.11)
Service Desk should be integrated with Change Management.
Even self-service style "Service Desk" functionality must integrate with Change Management.
Service Desk might act as the focal point for Requests for Change from the Users, distribute the Forward
Schedule of Change on behalf of Change Management and keep the Users informed regarding the
progress of their Changes (2.11)
The Service Desk may be given delegation to implement standard Changes to circumvent Incidents within
its sphere of authority. The scope of such Changes should be predefined and the Change Management
function should be informed about all such Changes. Prior approval of Change Management is essential
before Changes of specification of any Configuration Item are implemented (2.11)
Change Management can delegate authority to the Service Desk to implement changes
The Service Desk is usually asked to handle customer notification regarding Changes
Effective Change Management relies on the Service Desk and Configuration, Problem and Release
Management
The Service Desk must be kept informed of the details of each Change (2.7)
Service Desk with Release Management

Service Desk should be integrated with Release Management.
Even self-service style "Service Desk" functionality must integrate with Release Management.
Service considerations must be included in release planning.
The Service Desk must be informed about any changes in the vendor support agreements
Release Management should inform the users when there are changes to the vendor support agreements,
but the Service Desk may need to repeat that communication
Problem Management and Service Desk personnel must be trained to use and support the new Release
Service Desk with Service Level Management

Service Desk uses Service Level Agreements and can provide enforcement on the Service Level Agreement
and Operational Level Agreement requirements.
Service Desk uses the Service Catalog to define agreed expectations and identify the appropriate support
11
Service Desk with Service Level Management
process.
The Service Desk is in the direct firing line of any impact on the SLAs and as such needs rapid information
flows (2.11)
Service Desk Incident Records can be used to identify the services when constructing a Service Catalog
Verify that the Service Level Agreements are achievable before agreeing
It is important that the Customer reports Incidents promptly so that the Incident can be resolved within the
time allotted in the Service Level Agreement
Many organizations use their Service Desk linked to a comprehensive Configuration Management Database
to monitor the Customer's perception of Availability
The Service Desk can monitor Incident response times and Incident resolution times
The Service Desk can monitor compliance with the Underpinning Contracts
The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk
tool to facilitate communication, monitoring and escalation
The Customer's perception of response time should be recorded and Problem Management should
investigate repetitions
Planning for a new Service should include the Service Desk, Change, Configuration and Release
Management to verify resource and training requirements
Service Desk with

with Financial Management

Service Desk can integrate with Financial Management.
Service Desk and integrated Service Management processes are likely to be able o provide data to be input
to cost calculation (SD 5.5.8)
Training materials must be produced to explain the IT Accounting and/or Charging system. The Service
Desk might be one of the users of this documentation (SD 5.6.1)
Sources of data for the costing / charging model are Service Desk calls, workload data from the Capacity
Management Database, inventories from the Configuration Management Database and planned
acquisitions (Capacity Plan) (SD 5.6.2)
Service Desk with Capacity Management
Service Desk can integrate with IT Service Capacity Management.

Service Desk can recommend improvements to Capacity Management.
Service Desk may refer performance related Incidents to Capacity Management to assess (SD 6.2)
Capacity Management works with Problem Management to give Incident Management diagnostic tools,
automated alerting and updates to Known Errors (SD 6.7.1)
Service Desk with IT Service Continuity Management

Service Desk can integrate with IT Service Continuity Management.
Service Continuity will interface with Service Desk for statistics on prior activities (SD 7.1.8)
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the
business. Those risks are to be worked through Incident and Problem Management, addressed through
Availability and Problem Management and resolved through Change and Configuration (and Release)
Management (SD 7.2.2)
Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service
Continuity Management (SD 7.3.5)
12
Service Desk with IT Service Continuity Management
The Service Desk has an important role to play if business continuity is invoked (2.4)
Service Desk with Availability Management

Service Desk and Incident Management handling of an Incident can significantly impact how this Incident
affects Availability (processes, notifications, escalations, diagnostics, detection) (SD 8.5.4)
Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)
The Incident should only be closed when the Users have verified that Service has been restored (SD 8.5.4)
Every component should have a designated maintenance strategy (planned downtime) incorporated into
the service agreements (SD 8.5.6)
Service Desk, Change and Problem Management should provide data on downtimes (planned and
unplanned), but this should be augmented by automated monitoring (SD 8.8.1)
Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service
Outage Analysis (SD 8.9.8)
Available Management can use the Expanded Incident LifeCycle and work closely with Incident and
Problem Management to insure that failures are not repeated (SD 8.9.9)
13
4. Incident Management
4.1.
4.1. Incident Management Synopsis Tools
Goals CMDB with automated matching
Restore normal service operation quickly Automated monitoring to create Incidents
Minimize adverse impact Escalation timers
Maintain service quality & availability Ability to route to other groups
Automation for Classification
Benefits Auto-Call Distribution telephone system
Reduced business impact Diagnostic tools
Timely resolution Knowledge base including list of known errors
Proactive identification of enhancements
Improved monitoring on SLAs Activities
Management information on service quality Incident detection and recording
Better staff utilization Classification and initial support
Elimination of lost Incidents Investigation and diagnosis
More accurate CMDB information Resolution and recovery
Improved User and Customer satisfaction Incident closure
Ownership, monitor, track and communicate
Critical Success Factors
Up-to-date CMDB Inputs
Knowledge Base Incident details
Automated Incident Management system Configuration Items
Close link to SLM for SLA targets Matching against Problems and Known Errors
Resolution details
Key Performance Indicators Response on RFC
Numbers of Incidents
Mean time to resolution Outputs
Percentage within agreed response time RFC for resolution
Average cost per Incident Updated resolution & Work-arounds
Percentage closed by Service Desk Resolved and closed Incidents
Incidents per SD workstation Communication to Customers
Percentage resolved without a visit Management information (reports)
Possible Implementation
Implementation Problems Manager’s Duties
Management or staff commitment Drive efficiency and effectiveness of IM Process
Clarity about business needs Produce management information
Practices not reviewed or changed Managing the work of IM staff
Poor objectives, goals and responsibilities Monitoring the effectiveness of IM
No provision of agreed Customer service levels Make recommendations for improvement
Lack of knowledge Develop and maintain the IM systems
Inadequate training
Lack of integration Other Roles
Tools to automate the process Service Desk Manager
Resistance to change First, Second & Third-line
14
4.2.
4.2. Incident Management Goal Statement
The primary goal of the Incident Management process is to restore normal service
operation as quickly as possible and minimize the adverse impact on business
operations, thus ensuring that the best possible levels of service quality and availability
are maintained. ‘Normal service operation’ is defined here as service operation within
Service level agreement (SLA) limits.
4.3.
4.3. Incident Management Benefits
“For the business as a whole:
• Reduced business impact of Incidents by timely resolution, thereby increasing

effectiveness
• The proactive identification of beneficial system enhancements and amendments
• The availability of business-focused management information related to the SLA
For the IT organization in particular:
• Improved monitoring, allowing performance against SLAs to be accurately

measured
• Improved management information on aspects of service quality
• Better staff utilization, leading to greater efficiency
• Elimination of lost or incorrect Incidents and service requests
• More accurate CMDB information (giving an ongoing audit while registering
Incidents)
• Improved User and Customer satisfaction” (SS 5.4)
4.4.
4.4. Incident Management Critical Success Factors
• "An up-to-date CMDB is a prerequisite for an efficiently working Incident
Management process. If a CMDB is not available, information about
Configuration Items (CIs) related to Incidents should be obtained manually, and
determining impact and urgency will be much more difficult and time-
consuming.
• A ‘knowledge base’ in the form of an up-to-date Problem/error database should
be developed to provide for resolutions and Work-arounds. This will greatly
speed up the process of resolving Incidents. Third-party Known Error databases
should also be available to assist in this process.
• An effectively automated system for Incident Management is fundamental to the
success of a Service Desk. Paper-based systems are not really practical or
necessary, now that good and cheap support tools are available.
• Forge a close link with the Service-Level Management (SLM) process to obtain
necessary Incident response targets. Timely Incident resolution will satisfy
Customers and Users." (SS 5.5.2)
15
4.5.
4.5. Incident Management Key Performance Indicators
Indicators
• "Total numbers of 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 code)
• Average cost per Incident
• Percentage of Incidents closed by the Service Desk without reference to other
levels of support
• Incidents processed per Service Desk workstation
• Number and percentage of Incidents resolved remotely, without the need for a
visit" (SS 5.9)
4.6.
4.6. Incident Management Possible Implementation Problems
• “No visible management or staff commitment, resulting in non-availability of
resources for implementation
• Lack of clarity about business needs
• Working practices not being reviewed or changed
• Poorly defined service objectives, goals and responsibilities
• No provision of agreed Customer service levels
• Lack of knowledge for resolving Incidents
• Inadequate training for staff
• Lack of integration with other processes
• Lack of, or expense of, tools to automate the process
• Resistance to change” (SS 5.5.3)
4.7.
4.7. Incident Management Tools
• Configuration Management Database with automation for matching the Incident
to the appropriate Configuration Item
• Automated monitoring with an interface to automatically create Incident Records
• Escalation timers
• Ability to route Incident Records to other Service Desk locations and to other
groups
• Automation for Classification
• Auto-Call Distribution telephone system
• Diagnostic tools
• Knowledge base including list of known errors
4.8.
4.8. Incident Management Inputs and Outputs
Inputs:
• Incident details sourced from (for example) Service Desk, networks or computer
operations
16
• configuration details from the Configuration Management Database (CMDB)
• response from Incident matching against Problems and Known Errors
• resolution details
• response on RFC to effect resolution for Incident(s)
Outputs:
• RFC for Incident resolution; updated Incident record (including resolution and/or
Work-arounds)
• resolved and closed Incidents
• communication to Customers
• management information (reports)
Incident Management activities:
• Incident detection and recording

• Classification and initial support
• investigation and diagnosis
• resolution and recovery
• Incident closure
• Incident ownership, monitoring, tracking and communication
4.8.1. Incident Management Inputs and Outputs Diagram
17
4.8.2. Incident Management Inputs and Outputs Description
Service Desk Service Desk acts as the interface into Incident Management for most of
the users of the process. The Service Desk accepts customer input from
telephone calls, emails and other communications and generates
Incident Records. The Service Desk may also be authorized to accept
input from various automation processes and transcribe those inputs
into Incident Records.
Service Desk also communicates outwardly from Incident Management
to inform users and management of status, provide work-arounds and
confirm resolutions.
The extent of the interface between the Service Desk and Incident
Management is further detailed in the description of the Service Desk
Function.
Computer Computer Operations and Networking are simply placeholders to
Operations indicate 1) that the IS associates and contractors are also users of the
Networking Incident Management system and 2) that automated monitoring jobs
should be configured to feed Incidents into the Incident Management
system. These source objects are included as a reminder that both the
human and automation interfaces can either interface through the
Service Desk or directly into the Incident Management system.
Procedures All of the ITIL processes are interconnected and interdependent.
Procedural documents used by all of the ITIL processes should include
the process for reporting Incidents into the central Incident Management
process. This will ensure consistency in the classification, management,
notification and escalation processes.
Other sources of The ITIL definition for an Incident is: “any event which is not part of the
Incident standard operation of a service and which causes, or may cause, an
interruption to, or a reduction in, the quality of that service.” Every
“Incident” must be reported into the central Incident Management
system.
Service Request The ITIL definition of a Service Request is simply: “Every Incident not
Procedures being a failure in the IT Infrastructure.” The intent here is to designate
whether an Incident Record is processed through the Incident
Management process or through some other standard process. The
purpose for this separation is to ensure that metrics on the reliability of
the infrastructure are not inflated by “business as usual” user requests.
18
CMDB CMDB stands for the “Configuration Management DataBase”. The
complete definition of the infrastructure, the relationships between the
components and the interrelationships of those components with the
other ITIL processes is to be accessible through one central repository.
The definition and usage of this repository is contained in the
Configuration Management section of this document.
Change Management Incident Management generates both inputs into Change Management
Process and it receives outputs from that process. Inputs from Incident
Management into Change Management will be made through the
Request for Change process. The outputs from Change Management to
Incident Management consist of status updates and management
reports including the Forward Schedule of Changes. The Forward
Schedule of Changes is used by Incident Management to advise the
users and customers about the schedule for implementing the required
Resolutions.
Problem Error The Problem Error Database is an essential tool maintained by the
Database Problem Management process. Since Problem Management is not
included in this phase of the ITIL implementation, it is important to
document a deviation from the defined ITIL processes.
Incident The Incident Management Process is defined in the next section of this
Management Process document.
4.9.
4.9. Incident Management Process Flow
4.9.1. Incident Management Process Flow Diagram
19
4.9.2. Incident Management Process Flow Description
Aspect Description
Ownership, Incident Management has an overriding requirement to take ownership
monitoring, tracking of Incidents, monitor the Incident, track progress on restoring normal
and communication service and communicate. This aspect of the overall process is distinct
in that it is interrupt driven. In contrast, the other aspects of the Incident
Management are sequential.
Incident detection The sequential aspect of Incident Management begins when an Incident
and recording is detected. Detection can be a manual process or it can be implemented
through automation.
Initial classification As soon as the Incident has been detected, it is important to create an
and support Incident Record to match this Incident with the appropriate
Configuration Item(s). The Classification process then identifies the
Category, Impact and Urgency for the Incident. Using that information
the appropriate resource is identified
Service Request The ITIL definition of a Service Request is simply: “Every Incident not
being a failure in the IT Infrastructure.” The intent here is to designate
Service Request Pre-defined procedures are required for all Service Requests.
procedure
Investigation and Incidents that are “a failure in the IT infrastructure” must be investigated
diagnosis and diagnosed. Incident Management experience should be captured
into standard diagnostic processes. Those processes will typically
include a check against related open Incidents, a search through the
Problem Error Database, a check against the Forward Schedule of
Changes, use of appropriate diagnostic tools and standardized
troubleshooting processes.
Resolution and “The primary goal of the Incident Management process is to restore
recovery normal service operation as quickly as possible.” This can be
accomplished through a break-fix process, by implementing a work-
around, or by following the defined process for implementing a Change.
The precise boundaries of responsibility must be defined to ensure that
Incident Management does not overreach into Problem Management or
Release Management.
20
Aspect Description
Incident closure Incident Closure is always the responsibility of the Incident Management
team, regardless of which ITIL Process actually implemented the
restoration of service. Incident Closure consists of verifying with the
user that reported the Incident that service has been restored to a
normal level.
4.10.
4.10. Incident Management Line Escalation
4.10.1. Incident Management Line Escalation Diagram
4.10.2. Incident Management Line Escalation Description

Aspect Description
Detect and record The sequential aspect of Incident Management begins when an Incident
is detected. Detection can be a manual process or it can be implemented
through automation.
21
Aspect Description
Request The ITIL definition of a Service Request is simply: “Every Incident not
being a failure in the IT Infrastructure.” The intent here is to designate
Service Request Pre-defined procedures are required for all Service Requests.
procedure
Initial Support As soon as the Incident has been detected, it is important to create an
Incident Record to match this Incident with the appropriate
Configuration Item(s). The Classification process then identifies the
Category, Impact and Urgency for the Incident. Using that information
the appropriate resource is identified
Resolved Resolution of an Incident simply means that they symptom is no longer
occurring. It is important to distinguish between Problem Resolution,
implying a permanent fix, and the “restoration of normal service”.
Restoration can occur through a break-fix, a work-around, through a
permanent fix or simply because the error is no longer occurring.
Resolution / Once normal service is possible, it is necessary to “recover”. Recovery
Recovery can be as simple as reprinting lost reports or as complex as restoring a
corrupted database. The process for recovery should be included in the
process “script” for this classification of Incident.
Investigate / Incidents that are “a failure in the IT infrastructure” must be investigated
Diagnose and diagnosed. Incident Management experience should be captured
into standard diagnostic processes. Those processes will typically
include a check against related open Incidents, a search through the
Problem Error Database, a check against the Forward Schedule of
Changes, use of appropriate diagnostic tools and standardized
troubleshooting processes.
ETC Processes must be defined for functional escalation beyond the skill set
available to the Incident Management team.
Close Incident Closure is always the responsibility of the Incident Management
team, regardless of which ITIL Process actually implemented the
restoration of service. Incident Closure consists of verifying with the
user that reported the Incident that service has been restored to a
normal level.
4.11.
4.11. Incident Management Relationships with other Service Management Processes
Please refer to the prior section for the relationships of Incident Management with
Service Desk.
22
Incident Management with Problem Management
Management
The Incident Management process includes searching for matches against open Problems, Known Errors
and resolution details
Incidents are linked to Problem Records when there is a match
Incident Management can generate a Problem Record when the cause of the Incident is unknown
Incident Management is responsible for finding a resolution or a work-around
When Incident Management finds a work-around they should pass it to Problem Management for
evaluation
When Problem Management finds a work-around or resolution they need to pass it over to Incident
Management
Problem Management should be notified if there is a Major Incident
(2.9)
Incident Management forwards Incident details and work-arounds to Problem Management
Incident Management uses the documentation on known errors and work-arounds
Problem Management reacts to Incidents when escalated
Problem Management should proactively examine the history of Incidents and find trends
Improvements in the Knowledge database should allow Incident Management to resolve more Incidents
and do so more quickly
Problem Management should be implemented in parallel with Incident Management, or after Incident
Management
Problem Management needs to work closely with Incident Management to create and update the
Categories
Problem Management can create or deploy diagnostic tools and then train the Incident Management team
on how to use them
Incident Management with Configuration Management
Incident Management utilizes the Configuration Management Database and links Incidents to
Configuration Items
Incident Management may uncover discrepancies in the Configuration Management Database
Inconsistencies in the Configuration Management Database should be reported to Configuration
Management
Incident Management should use the Configuration Management database to assess the number of users
impacted by an Incident
(2.9)
Provide an accurate representation of the infrastructure to support other ITIL processes
23
Incident Management with Configuration Management
Configuration Management must be able to report on all Configuration Items impacted by an Incident or a
Problem
All of the ITIL processes should be entered into the Configuration Management Database as Configuration
Items and subject to Change Management (3.2)
The Configuration Management Database is used to link Incidents, Problems and other records to the
Configuration Items and the Users (2.6)
Incident Management with Change Management
Requests for Change are not regarded as Incidents.

Incident Management will use the response from a Request for Change to implement a work-around or
resolution
Replacing faulty hardware is not considered a Change
(2.9)
Incident Management is authorized to make corrections, but should seek authorization for Changes
Incident Management with Release Management
The Definitive Hardware Store can be used in the event of a Major Incident
Release procedures may be an integral part of Incident and Problem Management (2.7)
Incident Management with Service Level Management
The detailed history that Incident Management maintains on each Incident is helpful when evaluating
Service Level Agreement breaches
Functional Escalation should occur before the Service Level Agreement time has expired
Hierarchical Escalation occurs when the Service Level Agreement time is likely to expire
Service Level Management defines the time to resolve goals, often based upon Categories
Incident Management uses the time to resolve goals and the Category to determine Urgency
Incident Management gathers the data for the evaluation of Service Level Agreement compliance
Incident priorities and escalation procedures need to be agreed as part of the Service Level Management
process and documented in the Service Level Agreements (2.9)
Service Desk Incident Records can be used to identify the services when constructing a Service Catalog
It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services
Recent Incidents and longstanding Problems often cloud the negotiation on Service Level Agreements
It is important that the Customer reports Incidents promptly so that the Incident can be resolved within the
time allotted in the Service Level Agreement
24
Incident Management with Service Level Management
The Service Desk can monitor Incident response times and Incident resolution times
Some of the most important targets set in the Service Level Agreements relate to service Availability and
thus require Incident resolution within agreed periods (2.1)
Incident
Incident Management with Financial Management
Incident Management needs to update Incident Records with appropriate costing codes and hours worked
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD
5.1.6)
Incident Management with Capacity Management
Incident Management often finds options for beneficial system enhancement

The history of Incidents and Problems is a key input into Capacity planning (SD 6.2)
Other Service Management processes can refer Incidents and Problems to Service Capacity Management
when there is a breach or a risk of a breach against a Service Level Agreement. Service Capacity
Management will then refer those Incidents or Problems to Resource Capacity Management (2.3, SD 6.2.2,
6.2.3, 6.7)
Reports from the Capacity Management Database are useful to many of the other Service Management
processes, but especially so to Service Level Management when reviewing Service Levels and to Incident
and Problem Management when investigating and diagnosing Incidents and Problems (SD 6.3.5)
It is necessary to review the Capacity Management Database to ensure the data collected is at the
appropriate level and for the appropriate values so that the monitoring is not wasting resources and not
missing data vital to the Incident and Problem Management processes (SD 6.6)
Incident Management must inform Capacity Management regarding all Incidents related to capacity or
performance (SD 6.7.1)
Incident Management with IT Service

Service Continuity Management
Incident Management with Availability Management
A history of prior Incidents and Problems is used in Availability planning to assess component failures
25
Incident Management with Availability Management
Availability Management is dependent upon the maturity of Incident, Problem and Change Management
It might be necessary to improve upon the Incident, Problem, Change and Release Management processes
to achieve higher levels of Availability (SD 8.5.3)
Service Desk and Incident Management handling of an Incident can significantly impact how this Incident
affects Availability (processes, notifications, escalations, diagnostics, detection) (SD 8.5.4)
The Incident should only be closed when the Users have verified that Service has been restored (SD 8.5.4)
Incident and Problem Management should provide input into the Availability reports to highlight Problem
"black spots" and areas for increased preventative maintenance (SD 8.7.7)
26
5. Problem Management
5.1.
5.1. Problem Management Synopsis Activities
Goals Problem control
Minimize the adverse impact from IR & PR Error control
Prevent recurrence Proactive prevention
Seek root cause Identify trends
Initiate actions to improve or correct Management information from PM data
Major Problem reviews
Benefits
Improved IT service quality Inputs
Incident volume reduction Incident details from IM
Permanent solutions Configuration Items
Improved organizational learning Work-arounds from IM
Better first-time fix rate for SD
Outputs
Critical Success Factors Known Errors
Effective automated registration & classification Requests for Change
Achievable objectives to use Problem-solving talents Updated PRs with resolutions & work-arounds
Balance potential conflict between IM & PM Properly closed PRs
Matched IR to PR and KE
Key Performance Indicators Management information
Number of Problems and errors grouped
Elapsed time to close Manager’s Duties
Elapsed time on outstanding Develop and maintain Problem Control process
Expected resolution time on outstanding Efficiency and effectiveness of Problem Control
Mean and maximum elapsed time to confirm KE Produce management information
Any temporary resolution actions Manage Problem support staff
Allocating resources
Possible Implementation Problems Effectiveness of Error Control
Absence of good IM process Recommendations to improve Error Control
Absence of good historical data Develop and maintain Problem/Error Control systems
Failing to link IR with PR and KE Efficiency and effectiveness of Proactive activities
Management commitment
Do not undermine SD with back-door Other Roles
Time spent on Knowledge Base Problem support team
Inaccurate prioritization
Tools
CMDB
Scientific Method
Ishikawa
Brainstorming
Flowcharting
27
5.2.
5.2. Problem Management Goal Statement
The goal of Problem Management is to minimize the adverse impact of Incidents and
Problems on the business that are caused by errors within the IT Infrastructure, and to
prevent recurrence of Incidents related to these errors. In order to achieve this goal,
Problem Management seeks to get to the root cause of Incidents and then initiate
actions to improve or correct the situation.
5.3.
5.3. Problem Management Benefits
• “Improved IT service quality
• Incident volume reduction
• Permanent solutions
• Improved organizational learning
• Better first-time fix rate at the Service Desk” (SS 6.4)
5.4.
5.4. Problem Management
Management Critical Success Factors
• “An effective automated registration of Incidents, with an effective classification,
is fundamental for the success of Problem Management.
• Setting achievable objectives and making use of the Problem-solving talents of
existing staff is a key activity. Consider ‘part-time’ Problem Management,
whereby staff set aside periods when they will look at Problems away from the
daily fire-fighting pressures.
• In view of the potentially conflicting interests between Incident Management and
Problem Management (paragraph 6.3.1), good cooperation between both
processes is essential. Both also have enormous synergy, which can help.
Support staff, often involved in both processes, should be aware of the
importance of balancing activities between the two.” (SS 6.5.2)
5.5.
5.5. Problem Management Key Performance Indicators
• “The number of Problems and errors split by:
o status
o service
o impact
o category
o User group
• The total elapsed time on closed Problems
• The elapsed time to date on outstanding Problems
• The mean and maximum elapsed time to close Problems or confirm a Known
Error, from the time of raising the Problem record, by impact code and by
support group (including vendors)
• Any temporary resolution actions
• The expected resolution time for outstanding Problems
• The total elapsed time for closed Problems” (SS 6.10.1)
28
5.6.
5.6. Problem Management Possible Implementation Problems
• “Absence of a good Incident control process, and thus the absence of detailed
historical data on Incidents (necessary for the correct identification of Problems).
• Failure to link Incident records with Problem/error records, means a failure to
gain many of the potential benefits. This is a key feature in moving from reactive
support to a more planned and proactive support approach.
• Lack of management commitment, so that support staff (usually also involved
with reactive Incident control activities) cannot allocate sufficient time to
structural Problem-solving activities.
• The undermining of the Service Desk role. Problem Management staff should
accept support requests only from authorized sources. Difficulties will arise if
the process deals with requests from many sources since multiple reports of
Incidents with the same cause may not be interpreted in the same way.
• Failure to set aside time to build and maintain the knowledge base will restrict
the delivery of benefits.
• An inability to determine accurately the business impact of Incidents and
Problems. Consequently the business-critical Incidents and Problems are not
given the correct priority.“ (SS 6.5.3)
5.7.
5.7. Problem Management Tools
• Configuration Management Database for a record of the Configuration Items,
Incidents, Problems and Request for Change
• Kepner and Tregoe analysis (Scientific Method)
• Ishikawa Diagrams
• Brainstorming
• Flowcharting
5.8.
5.8. Problem Management Inputs and Outputs
Inputs:
• “Incident details from Incident Management

• Configuration details from the Configuration Management Database (CMDB)
• Any defined Work-arounds (from Incident Management)” (SS 6.2)
Outputs:
• “Known Errors
• A Request for Change (RFC)
• An updated Problem record (including a solution and/or any available Work-
arounds)
• For a resolved Problem, a closed Problem record
• Response from Incident matching to Problems and Known Errors
• Management information” (SS 6.2)
Activities:
29
• “Problem control
• Error control
• The proactive prevention of Problems
• Identifying trends
• Obtaining management information from Problem Management data
• The completion of major Problem reviews” (SS 6.2)
5.8.1. Problem Management Inputs and Outputs Diagram
30
5.8.2. Problem Management Inputs and Outputs Description
Incident Details The standard pathway into Problem Management is from Incident
Management. Incident Records are worked by Incident Management until
• matching the Incident to existing Problems and Known Errors is
not successful during the stage of Incident initial support and
classification
• analysis of Incident data reveals recurrent Incidents
• analysis of Incident data reveals Incidents that are not yet
matched to existing Problems or Known Errors
• analysis of the IT infrastructure indicates a Problem that could
potentially lead to Incidents
• a major or significant Incident (serious and adverse impact on
services to the Customer) occurs for which a structural solution
has to be found
Incident Management will then escalate to Problem Management and
Problem Management will use the history of the activity recorded in the
Incident Record(s) to create a new Problem Record. Subsequent Incidents
that match this Problem Record will be linked to this Problem Record by
Incident Management. Those additional Incidents will be evaluated by
Problem Management to glean additional information about the
underlying Problem.
Configuration The Configuration Management Database (CMDB) is the core system that
Details supports the ITIL processes. Incident Records and Problem Records will
be linked to the Configuration Items in the CMDB. The details about
those Configuration Items and the relationships between Configuration
Items are valuable to Problem Management in diagnosing the Problem,
assessing the impact, and preparing the resulting Request for Change.
Work-Arounds Incident Management often generates work-arounds to Problems in
order to “restore normal operations as quickly as possible”. Those work-
arounds must be linked to the Problem Record so that Incident
Management can quickly access this information and not expend time
reinventing something that has already been developed. Additionally,
the work-arounds often provide valuable information that aids Problem
Management in determining the underlying cause.
Problem The Problem Management process has six primary activities, as shown
Management in the preceding diagram. The flow through the Problem Management
process is also documented in the following section of this document.
31
Problem Control “The Problem control process is concerned with handling Problems in an
efficient and effective way. The aim of Problem control is to identify the
root cause, such as the CIs that are at fault, and to provide the Service
Desk with information and advice on Work-arounds when available.”
Error Control “Error control covers the processes involved in progressing Known errors
until they are eliminated by the successful implementation of a Change
under the control of the Change Management process. The objective of
error control is to be aware of errors, to monitor them and to eliminate
them when feasible and cost-justifiable.”
Proactive “Proactive Problem Management covers the activities aimed at
Identify Trends identifying and resolving Problems before Incidents occur. These
Management Info activities are:
• Trend analysis
• Targeting support action
• Providing information to the organization
By redirecting the efforts of an organization from reacting to large
numbers of Incidents to preventing Incidents, an organization provides a
better service to its Customers and makes more effect use of the
available resources within the IT support organization.”
Major Problem On completion of the resolution of every major Problem, Problem
Reviews Management should complete a major Problem review. The appropriate
people involved in the resolution should be called to the review to
determine:
• What was done right
• What was done wrong
• What could be done better next time
• How to prevent the Problem from happening again
Known Errors ITIL defines a Known Error as “an Incident or Problem for which the root
cause is known and for which a temporary Work-around or a permanent
alternative has been identified. If a business case exists, an RFC will be
raised, but, in any event, it remains a known error unless it is
permanently fixed by a Change.”
Request for Change An important distinction between Problem Management and Incident
Management is that the Problem Management produces resolutions that
require a Change to the environment. The Request for Change is the
document used by Problem Management to interface with Change
Management.
32
Updated Problem Problem Management is responsible for maintaining an accurate and
Record current status in the Problem Record in order to communicate with the
other ITIL processes. The Service Desk will use those Problem Record
updates to communicate status to the user community.
Problem Resolution A Problem Resolution is a Change that will resolve the Problem and the
Incidents linked to that Problem. This is a “permanent fix”. For example,
if an Incident Record states that a web server process is no longer
serving web pages, Incident Management may “restore normal
operations” by stopping and restarting the web server process. That is a
work-around. Problem Management may become engaged because the
Incident recurs. Problem Management will then come up with a Problem
Resolution, such as applying a patch to the operating system.
Incident matching Problem Management and Incident Management work together to link
Incidents to Problems so that the Release Management process can
implement the Problem Resolution on each impacted Configuration
Item.
Management Problem Management is responsible for providing key management
Information information including an analysis on the number of Problems and a
summary on the type of closure on each.
5.9.
5.9. Problem
Problem Management Problem Control Process Flow
5.9.1. Problem Management Problem Control Process Flow Diagram
33
5.9.2. Problem Management Problem Control Process Flow Description
Aspect Description
Tracking and Tracking and monitoring of Problems is an ongoing asynchronous
monitoring of activity. Problems need to be checked for changes in the reported
Problems errors, for diagnostic input, for third party resolutions and for
communication from the users, customers and other ITIL processes.
Problem Management is also responsible for updating the Problem
Record on a consistent basis so that the other ITIL processes and the
Service Desk can use the Problem Record for immediate status.
Problem The standard pathway into Problem Management is from Incident
identification and Management. Incident Records are worked by Incident Management until
recording • matching the Incident to existing Problems and Known Errors is
not successful during the stage of Incident initial support and
classification
• analysis of Incident data reveals recurrent Incidents
• analysis of Incident data reveals Incidents that are not yet
matched to existing Problems or Known Errors
• analysis of the IT infrastructure indicates a Problem that could
potentially lead to Incidents
• a major or significant Incident (serious and adverse impact on
services to the Customer) occurs for which a structural solution
has to be found
Incident Management will then escalate to Problem Management and
Problem Management will use the history of the activity recorded in the
Incident Record(s) to create a new Problem Record. Subsequent Incidents
that match this Problem Record will be linked to this Problem Record by
Incident Management. Those additional Incidents will be evaluated by
Problem Management to glean additional information about the
underlying Problem.
Problem When a Problem is identified, the amount of effort required to detect
classification and recover the failing CI(s) has to be determined. Therefore it is
important to be aware of the impact of the Problem on existing service
levels. This process is known as ‘classification’. In practice, support
effort is allocated to only a small proportion of Problems linked to a
single Incident.
The steps involved in Problem classification are similar to the steps in
classifying Incidents; they are to determine:
• category
• impact
• urgency
• priority
34
Aspect Description
Problem “The process of Problem investigation is similar to that of Incident
investigating and investigation – but the primary objective of each process is significantly
diagnosis different. Incident Management’s aim is rapid restoration of service,
whereas Problem Management’s aim is diagnosis of the underlying
cause. Investigation activities should include available Work-arounds for
the Incidents related to the Problem, as registered in the Incident record
database. Problem Management activities should include updating
recommended Work-arounds in the Problem record, to support Incident
control.”
RFC and possible The Problem Control investigation may uncover the Change required to
resolution and resolve the Problem. When that occurs, Problem Control will need to
closure follow the steps described for how Error Control records the Error
resolution, generates and monitors a Request for Change, and closes the
Problem when the Change has successfully resolved the Problem to the
satisfaction of the user.
Error Control “Error control covers the processes involved in progressing Known errors
until they are eliminated by the successful implementation of a Change
under the control of the Change Management process. The objective of
error control is to be aware of errors, to monitor them and to eliminate
them when feasible and cost-justifiable.” Once the Problem Control
activities have been completed, the Known Error and the Problem(s)
linked to that Known Error are passed to Error Control for resolution.
35
5.10.
5.10. Problem Management Error Control Process Flow
5.10.1. Problem Management Error Control Process Flow Diagram
5.10.2. Problem Management Error Control Process Flow Description

Aspect Description
Problem Control “The Problem control process is concerned with handling Problems in an
efficient and effective way. The aim of Problem control is to identify the
root cause, such as the CIs that are at fault, and to provide the Service
Desk with information and advice on Work-arounds when available.”
Once the Problem Control activities have been completed, the Known
Error and the Problem(s) linked to that Known Error are passed to Error
Control for resolution.
36
Aspect Description
Tracking and Tracking and monitoring of Errors is an ongoing asynchronous activity.
monitoring errors Errors need to be checked for changes in the reported symptoms, for
diagnostic input, for third party resolutions and for communication from
the users, customers and other ITIL processes. Problem Management is
also responsible for updating the Error Record on a consistent basis so
that the other ITIL processes and the Service Desk can use the Error
Record for status.
Identify and record When the person performing the Error Control activities is not the
error person that performed the Problem Control activities, it is necessary to
begin Error Control by reviewing the history of the Incident(s), work-
around(s), Problem(s) and Known Error.
Assess Error Error Assessment is the process of evaluating alternative resolutions to
find the resolution that achieves the desired results cost effectively.
Record Error Once the appropriate resolution has been identified, it is important to
resolution record those details so that the Incident(s), work-around(s), Problem(s)
and Known Error link to this resolution. Note that this step is highlighted
here, but is already called for as part of the ongoing activity of “Tracking
and monitoring errors”.
RFC An RFC is a Request for Change. The Request for Change is the
document used by Problem Management to interface with Change
Management in order to Release the resolution into the production
environment.
Change successfully Change Management assesses the success of a Change by verifying user
implemented satisfaction. Problem Management interfaces with Change Management
to determine the implementation status and verify that the resolution is
satisfactory.
Close Error and Once the resolution has been successfully implemented, Problem
associated Management will close the Known Error and all associated Problem
Problem(s) Records with appropriate comments. Incident Management will use the
Known Errors database to link new Incidents to this Known Error and
identify the appropriate resolution.
5.11.
5.11. Problem Management Relationships with other Service Management
Management Processes
Please refer to the prior section for the relationship of Problem Management with Service
Desk and Incident Management
Problem Management with Configuration Management
Problem Management utilizes the Configuration Management Database to identify details about the
Incidents and Problems
It is sometimes necessary to create dummy Configuration Items to allow tracking of Problems
All support documentation must be made available to the Problem Management team
37
Problem Management with Configuration Management
Problem Management should use the contact information in the Configuration Management Database to
determine who needs to know about a work-around or resolution
Configuration Management must be able to report on all Configuration Items impacted by an Incident or a
Problem
Problem Management uses the Configuration Management Database during trend analysis
The Configuration Management Database is used to link Incidents, Problems and other records to the
Configuration Items and the Users (2.6)
Problem Management with Change Management
Request for Change is submitted in order to implement a resolution

Problem Management should examine records of recent changes to see if those changes contributed to
the Problem
Problem Management should advise Change Management as to the urgency of the Problem and can
escalate if the Problem becomes more critical
Requests for Change can encompass processes as well as hardware and software
Problem Management only leads to a change when there is "a state different from a previously defined
condition"
Management
Problem Management with Release Management
Problem Management records should trace from Incident to Problem to Known Error to Request for Change
to Release and change implementation
A Release is typically designed to resolve problems and enhance services
An Emergency Fix generally resolves a small number of Problems
A Minor Release generally supersedes by inclusion prior Emergency Fixes as well as incorporating a few
enhancements
A Major Release often includes enhancements that make prior Problem fixes redundant
A Package Release bundles multiple Releases, often from different applications, together into one Release
Procedures need to be defined for Problem escalation as related to the Release process
Once the Release is successful, Problems and enhancement requests resolved by the Release should be
closed
Problems caused by the Release should be linked to the Release
Release procedures may be an integral part of Incident and Problem Management (2.7)
Problem Management with Service Level Management
Problem Management needs to be aware of the impact that Problems are having on Service Levels
Problems reported to vendors need to be monitored to insure that the vendor responds in a reasonable
time or within the time defined in the Underpinning Contract when defined there
Problem resolution needs to be measured against the Service Level Agreements
38
Problem Management with Service Level Management
Problem identification and resolution is easier when Service Level Management has built a strong
relationship between IT and the IT Customers
Recent Incidents and longstanding Problems often cloud the negotiation on Service Level Agreements
It is best to pilot the Service Level Agreements with a Customer group that has a small number of
Problems
Service Review meetings should be held monthly, or at least quarterly to review the results and initiate a
Service Improvement Program if warranted
Problem Management with Financial Management
Resolutions need to be cost effective

Some Problems do not justify the expenditure required for resolution
5.1.6)
Financial Management should conduct periodic audits to ensure that the Change and Problem
Management processes are strictly followed (SD 5.7.11)
Problem Management with Capacity Management
Capacity Management should be the "focal point" for all performance and capacity Problems (SD 6.1.1,
6.1.3)
The history of Incidents and Problems is a key input into Capacity planning (SD 6.2)
Proactive Changes and Service Improvements are key outputs from Capacity Planning (SD 6.2)
Capacity Management should preempt performance Problems (SD 6.2)
Management will then refer those Incidents or Problems to Resource Capacity Management (2.3, SD 6.2.2,
6.2.3)
Service and Resource Capacity Management must be proactive, anticipate the impact that Changes will
have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3)
Capacity Management should reduce the number of urgent Changes and reduce the risk of Problems (SD
6.4.2)
It is necessary to review the Capacity Management Database to ensure the data collected is at the
appropriate level and for the appropriate values so that the monitoring is not wasting resources and not
39
Problem Management with Capacity Management
missing data vital to the Incident and Problem Management processes (SD 6.6)
Problem Management expertise may be called on to assist in resolving Problems related to capacity or
performance (SD 6.7.2)
The Capacity Management Database needs to be linked into the Configuration Management Database to
assist Service Management in assessing proposed Service Level Agreements and Problem Management in
diagnosing Problems (SD 6.7.5)
Slow performance and capacity Problems can result in Unavailability of the Service to the users (SD 6.7.9)
Problem Management with IT Service Continuity Management
Problem Management with Availability Management
Much of Availability Managements work is in the detection and avoidance of Problems

Fragility of components
Problem Management needs to work closely with Availability Management to identify trends and instigate
remedial action (2.9)
Scheduling multiple Changes within one downtime can increase Availability, but it has the risks of
increased complexity in Release Management and increased complexity for Problem Management when
something goes wrong (SD 8.5.6)
Incident and Problem Management should provide input into the Availability reports to highlight Problem
"black spots" and areas for increased preventative maintenance (SD 8.7.7)
40
6. Configuration Management
Management
6.1.
6.1. Configuration Management Synopsis Tools
Goals Configuration Management Database
Account for all IT assets Software configuration management tools
Provide CIs to other Processes Change Management support (impact analysis)
Sound basis for IM, PM, CM & RM Automation for configuration auditing
Verify and correct CIs Automation for release deployment
Definitive Software Library
Benefits Definitive Hardware Store
Accurate information on CIs Document management system
Control valuable CIs Design, analysis and build tools
Adhere to legal obligations Report generation tools
Help Financial planning
Make Changes visible Activities
Contribute to Contingency planning Configuration Management planning
Improve Release Management Configuration Identification
Security by controlling versions Control of CIs
Reduce unauthorized software Configuration status accounting
Perform Impact Analysis on Changes Configuration verification and audit
Trend data for Problem Management CMDB back-ups, archives and housekeeping
Add value to the SM organization
Correct & accurate CIs to support SM Inputs
Defined procedures and tools Incidents, Problems, Known Errors & RFCs with updates
Identify, label, record CIs with history SW & HW for DSL/DHS
Train organization on control processes Configuration audits
Reporting and auditing
Outputs
Key Performance Indicators Forward Schedule of Changes
Unauthorized configurations Projected Service Availability
IR & PR from wrongly made Changes RFC, assessment and updates
RFCs failed due to bad CIs or version control Releases from DSL/DHS & library
Cycle time to approve & implement Changes Updated CIs and relationships
Licenses unused Management information
Exceptions found in configuration audit Linkages to the CDB
Unauthorized IT components
Manager’s Duties
Possible Implementation Problems Implements CM policy agreed with Service Manager
CIs at wrong level Develop/improve CM systems
Inadequate analysis & design Propose/agree CM scope, Plan, standards & procedures
Schedules overly ambitious Awareness campaign
Commitment lacking Arrange for recruit/train of staff
Too bureaucratic Propose/agree CI conventions & standards
Routinely circumvented Provides management information
Processes inefficient or errors in process RFC impact assessment & updates CI/RFC per Change
Unrealistic expectations about tool Configuration Audits and corrective actions
Tool lacks flexibility
Insufficient Change or Release processes Other Roles
Unrealistic expectations about process Configuration Librarian
Controls not in place
41
42
6.2.
6.2. Configuration Management Goal Statement
The goals of Configuration Management are to:
• Account for all the IT assets and configurations within the organization and its
services
• Provide accurate information on configurations and their documentation to
support all the other Service Management processes
• Provide a sound basis for Incident Management, Problem Management, Change
Management and Release Management
• Verify the configuration records against the infrastructure and correct any
exceptions
6.3.
6.3. Configuration Management Benefits
• Provide accurate information on CIs and their documentation
• Controlling valuable CIs
• Facilitating adherence to legal obligations
• Helping with financial and expenditure planning
• Making software Changes visible
• Contributing to contingency planning
• Supporting and improving Release Management
• Improving security by controlling of the versions of CIs in use
• Enabling organizations to reduce the use of unauthorized software
• Allowing the organization to perform impact analysis and schedule Changes
safely, efficiently and effectively
• Provide Problem Management with data on trends (SS 7.4.1)
6.4.
6.4. Configuration Management Critical Success Factors
"Providing everyone working in Service Management and support with correct and
accurate information on the present configurations with their physical and functional
specifications
Defining and documenting the procedures and working practices to be followed
Identifying, labeling and recording the names and versions of the CIs that make up the
IT services, infrastructure and their relationships
Controlling and storing definitive, authorized and trusted copies of specifications,

documentation and software
Reporting the current status and history of all items on the IT infrastructure
Ensuring that all Changes to CIs are recorded as soon as practicable
Tracking and reconciling the actual state of the IT infrastructure against the authorized
configuration records and data
Educating and training the organization in the control processes
Reporting metrics on CIs, Changes and Releases
Auditing and reporting exceptions to infrastructure standards and Configuration

Management procedures" (SS 7.5.2)
43
6.5.
6.5. Configuration Management Key Performance Indicators
• "Occasions when the ‘configuration’ is not as authorized
• Incidents and Problems that can be traced back to wrongly made Changes
• RFCs that were not completed successfully because of poor impact assessment,
incorrect data in the CMDB, or poor version control
• The cycle time to approve and implement Changes
• Licenses that have been wasted or not put into use at a particular location
• Exceptions reported during configuration audits
• Unauthorized IT components detected in use" (SS 7.7.2)
6.6.
6.6. Configuration Management Possible Implementation Problems
• CIs are defined at the wrong level with too much detail
• Implementation is attempted without adequate analysis and design
• Tactical schedules are overly ambitious
• Commitment is lacking
• The process is perceived to be too bureaucratic or rigorous
• The process is routinely circumvented
• Processes are inefficient and error-prone
• Expectations of what the tool can do are unrealistic
• The chosen tool may lack flexibility
• Configuration Management implemented without Change and Release
Management
• Expectations about the process are unrealistic
• Proper configuration control is not in place (SS 7.4.2)
6.7.
6.7. Configuration Management Tools
• Configuration Management Database
• Software configuration management tools
• Change Management support (impact analysis)
• Automation for configuration auditing
• Automation for release deployment
• Definitive Software Library
• Definitive Hardware Store
• Document management system
• Design, analysis and build tools
• Report generation tools
6.8.
6.8. Configuration Management Inputs and Outputs
All of the ITIL Service Management processes and functions are dependent upon the
Configuration Management process. The primary interfaces, however, are with Service
Desk, Incident Management, Change Management and Configuration Management.
Those flows are included in this document.
Inputs:
• Incidents, Problems, Known Errors and updates

• RFC data and status updates
• SW & HW for DSL/DHS
• Configuration audits
44
Outputs:
• Forward Schedule of Changes

• Projected Service Availability
• RFC, assessment and updates
• Releases from DSL/DHS & library
• Updated CIs and relationships
• Management information
• Linkages to the CDB
Activities:
• Configuration Management planning

• Configuration Identification
• Configuration structures and the selection of CIs
• CI types and life-cycles
• CI relationships
• Identification of software and document libraries
• Identification of configuration baselines
• Naming conventions
• Labeling CIs
• Control of CIs
• Registration of new CIs and versions
• Software developed in house
• Off-the-shelf CIs
• New CIs and versions from building and releasing
• Updating CIs
• License control
• Updating and archiving configuration records of
withdrawn/decommissioned CIs
• Protecting the integrity of configurations
• Updating the CMDB after checking the physical items
• Configuration status accounting
• Configuration verification and audit
• CMDB back-ups, archives and housekeeping
• Adding value to the Service Management organization
6.8.1. Configuration Management Inputs and Outputs for the Incident Life-Cycle
The primary focus of the Service Desk will be Incident Management. The relationship of
Incident Management with the Configuration Management Database is illustrated below.
45
46
6.8.2. Configuration Management Inputs and Outputs for the Incident Life-Cycle
Start The Incident Life-Cycle begins with first notification of an Incident. The
majority of all Incidents will be reported to the Service Desk, but some
Incidents currently route directly to an alternative support process.
Incident Whether the Incident is directly reported to the Service Desk or to an
alternative support process, the first action to take is to create an
Incident Record. Incident Records are to be stored in the Configuration
Management Database to facilitate matching against the Configuration
Item and to support trending and reporting against Configuration Items.
The Incident Management process is responsible for restoration of
normal service. The scope boundary for Incident Management must be
clearly defined so that Incident Management has a clear delineation
from Problem Management. Once Incident Management has reached
that boundary, it is the responsibility of Incident Management to
escalate to Problem Management.
Problem Escalation to Problem Management is documented by creating a
Problem Record in the Configuration Management Database. Problem
Records should be in the Configuration Management Database for
reasons similar to those listed above for Incidents. Additionally, it is
important that searches and reports can quickly identify the linkages
between Incidents and Problems.
The flow through Problem Management is divided into Problem Control
and Error Control. The primary duty of Problem Control is to take
symptoms and isolate them to the underlying cause. Once isolated, the
underlying cause can be defined as a Known Error.
Known Error ITIL defines a Known Error as: “An Incident or Problem for which the root
cause is known and for which a temporary Work-around or a permanent
alternative has been identified. If a business case exists, an RFC will be
raised, but, in any event, it remains a known error unless it is
permanently fixed by a Change.” It is important that Known Errors be
recorded in the Configuration Management Database to:
1) Allow Problem Management to link the Known Error to the
Problem Records and thus to the Incident Records
2) Allow the Service Desk to advise the user on the status of the
investigation into a permanent resolution to their Problem
3) Allow Configuration Management to advise Change Management
with the list of Configuration Items
Request for Change Once it is recognized that a Change is required in order to resolve a
Known Error, the Problem Management team must to create a Request
for Change. The Request for Change belongs in the Configuration
Management Database so that it can be linked to the Known Error, and
thus linked to the Problem Records, Incident Records and underlying
Configuration Items.
47
Change Authorized The status of the Request for Change must be tracked. The flow through
the Change Management process is described elsewhere in this
document. Each status update, however, must be recorded in the
Configuration Management Database so that it is clearly visible to all
who need status. The Service Desk, as the primary interface to the
users, will use this status, via the linkage to the user’s Configuration
Items, to advise the users as to the progress on resolving their Problem.
Change tested, Release Management must be able to update the Request for Change
Implemented and and appropriate Configuration Items to document the progress of their
Released work.
End The Incident Life-Cycle ends when the underlying Problem has been
resolved to the satisfaction of the user and all tributary Incidents closed.
6.8.3. Configuration Management Inputs and Outputs for Change Management

The complexity of the interface between Change Management and Configuration
Management is illustrated in the following diagram and text.
6.8.4. Configuration Management Inputs and Outputs for Change Management

48
Request for Change A Request for Change is the entry point into the Change Management
Register and process. It is important that all Requests for Change be recorded in the
allocation RFC Configuration Management Database so that they can be properly linked
number to the Configuration Items that will be affected.
Reports & Many Changes have prerequisites. It is the responsibility of
Configuration audit Configuration Management to ensure that the Configuration Items are
to check accurate so that the impact assessment can proceed.
environment
CMDB CMDB stands for Configuration Management Database. This is the
central repository for all configuration information. It is also
recommended that all Incident Records, Problem Records, Known Errors
and Requests for Change be linked through this repository.
Definitive Software The library in which the definitive authorized versions of all software CIs
Library are stored and protected. It is a physical library or storage repository
where master copies of software versions are placed. This one logical
storage area may in reality consist of one or more physical software
libraries or file stores. They should be separate from development and
test file store areas. The DSL may also include a physical store to hold
master copies of bought-in software, e.g. a fireproof safe. Only
authorized software should be accepted into the DSL, strictly controlled
by Change and Release Management.
The DSL exists not directly because of the needs of the Configuration
Management process, but as a common base for the Release
Management and Configuration Management processes.
Assess Change Management is dependent upon Configuration Management to
Analyze impact, provide an accurate and comprehensive description of the impact from
broker agreement the proposed Change. Change Management will then use that
where assessors assessment during evaluation and approval.
differ
Reports on CIs, The key benefit of a Configuration Management Database is the
areas & parties definition of the relationships between Configuration Items.
impacted Configuration Management makes use of those relationship definitions
when assessing the impact that a proposed Change will have on the
infrastructure and on the vital business functions.
Approved Change The Change Advisory Board will meet and reject, approve or approve
with conditions.
Update CM records It is the responsibility of Configuration Management to record the status
of the Request for Change in the Configuration Management Database.
This is an on-going effort, but it is highlighted here as a reminder of
the importance of this effort.
Implement Change The Change Management process will authorize a release schedule
This will involve pre- based upon the details accompanying the Request for Change. Release
release testing Management will then ensure that the appropriate development and
where software testing processes are followed.
changes are required
49
Release & distribute When the Release is ready, Release Management is authorized to begin
new versions of distributing the Release. Implementation of the Release, however, must
software and follow the pre-approved schedule.
hardware with
documentation
Baseline, release When the Release is ready, Release Management will provide
software from DSL & Configuration Management with a release package. Configuration
update DSL & CM Management is responsible for uploading the Release into the Definitive
records Software Library and updating the appropriate Configuration
Management Database records.
Post- “Following successful implementation of Changes to resolve errors, the
Implementation relevant Known error record(s) is closed, together with any associated
Review Incident or Problem records. Consideration should be given to inserting
Has change met into the process an interim status, on the Incident, Known Error and
originator's Problem records, of ‘Closed pending PIR’ to ensure that the fixes have
expectations? actually worked. A Post-Implementation Review (PIR) can then confirm
the effectiveness of the solution prior to final closure.”
Close Change The Change can only be closed when the user has verified that the
Problem has been resolved.
Check all CM records It is the responsibility of Configuration Management to insure that all of
were updated the linked Requests for Change, Known Errors, Problem Records,
Incident Records and Configuration Items are appropriate updated to
record the implementation of the Release and the resolution of the
Problem.
End The end of this Process.
6.9.
6.9. Configuration Management Process Flow
6.9.1. Configuration Management Process Flow Diagram
50
6.9.2. Configuration Management Process Flow Description
Aspect Description
New When Configuration Management first initiates, it is necessary to begin
planning for the Configuration Management Process. This same task
recurs whenever significant changes are scheduled.
Planning ITIL defines planning as “defining the purpose, scope, objectives,
policies and procedures and the organizational and technical context,
for Configuration Management.”
Identification ITIL defines Identification as “selecting and identifying the configuration
structures for all the infrastructure’s CIs, including their ‘owner’, their
interrelationships and configuration documentation. It includes
allocating identifiers and version numbers for CIs, labeling each item,
and entering it on the Configuration management database (CMDB).”
The key distinction between an ITIL Configuration Management
Database and a simple asset tracking system is the ability to define and
track the relationships between the Configuration Items.
Control Control is the core within Configuration Management. ITIL defines this
as “ensuring that only authorized and identifiable CIs are accepted and
recorded, from receipt to disposal. It ensures that no CI is added,
modified, replaced or removed without appropriate controlling
documentation, e.g. an approved Change request, and an updated
specification.” That definition is too succinct in that Control is the daily
activity for the Configuration Management group.
On Demand While Planning, Identification and Control flow in a linear sequence,
“Status Accounting” and “Verification and Audit” are only executed as
required.
Status Accounting ITIL defines Status accounting as “the reporting of all current and
historical data concerned with each CI throughout its life cycle. This
enables Changes to CIs and their records to be traceable, e.g. tracking
the status of a CI as it changes from one state to another for instance
‘under development’, ‘being tested’, ‘live’, or ‘withdrawn’.” This is the
activity of generating reports, updating status and supplying data to the
other ITIL processes.
Verification and Periodically it is best practice to validate the Configuration Items by
Audit performing a physical inventory of the assets. ITIL defines this activity
as “a series of reviews and audits that verify the physical existence of
CIs and check that they are correctly recorded in the Configuration
management system.”
6.10.
6.10. Configuration Management Relationships with other Service Management Processes
Please refer to the prior section for the relationship of Configuration Management with
Service Desk, Incident and Problem Management
Configuration Management with Change Management
Provide an accurate representation of the infrastructure to support other ITIL processes (2.6)
Verify that no Configuration Items are modified without going through the Change Management process
Configuration Management works together with Change Management and Release Management to deploy
51
Configuration Management with Change Management
new and updated deliverables

Policies should be jointly developed by Configuration Management, Change Management and Release
Management
Configuration Management is responsible for assessing the impact from proposed changes (2.6)
Configuration Management needs to document the history of changes for each Configuration Item
Configuration Management is responsible for verifying that the environment is compatible with the
proposed change
New builds should be verified against the specifications and documented as an "as-built" configuration
Audits should be conducted by Configuration Management to insure that all changes have gone through
the proper process
Items and subject to Change Management (2.6, 3.2)
It is best practice to implement Change and Configuration Management at the same time
Configuration Management is responsible for assessing the impact from proposed changes
Configuration Management needs to document the history of changes for each Configuration Item
The manager of the Configuration process can also manage the Change process
Management
Change Management depends upon the accuracy of the configuration data to ensure the full impact of
making Changes is known (2.7)
Configuration Management
Management with Release Management

Configuration Management works together with Change Management and Release Management to deploy
new and updated deliverables
Policies should be jointly developed by Configuration Management, Change Management and Release
Management
Release Management is responsible for populating the Definitive Software Library
Release Management must insure that all changes are reflected in the Configuration Management
Database
Details about the build process and build environment should be recorded when a build is moved into the
Definitive Software Library
Release Management is dependent upon the success of Configuration Management (2.6)
Release Management is to insure that the required software, hardware, documentation, etc are properly
archived (DSL, DHS, etc) and that only authorized versions are installed
Release Management coordinates all Changes with Configuration Management and Change Management
(2.8)
Release Management works with Configuration Management and Change Management to insure that the
Configuration Management Database is accurately maintained (2.7)
Release Management should work to update the Configuration Management Database during the build
cycle in anticipation of the release
When a Release is managed in phases, the Configuration Management Database should use a unique
identifier to link the individual releases into one Release
The Definitive Software Library must be protected from unauthorized change
All additions to the Definitive Software Library must have corresponding entries in the Configuration
Management Database
The Configuration Management Database should designate where the Release is to be applied
The Configuration Management Database should be updated with status to indicate receipt of the media,
52
Configuration Management
Management with Release Management
etc.
The detail description on how to build the Release should be a Configuration Item
The detailed description of the test environment should be a Configuration Item
The process for disposing of retired assets must be documented
Configuration Management should ensure that all pre-requisites have been met
Configuration Management should ensure that the Release has been successfully applied to all designated
locations
Configuration Management and Release Management can work as one organization or can be combined
with Change Management
Minimizing the number of variants will make Release Management easier
Ideally the users should be able to quickly determine the version of every component on their desktop
from one screen
Configuration Management with Service Level Management
Provide an accurate representation of the infrastructure to support other ITIL processes (2.6)
Service Level Management can use the Configuration Management Database to house details about the
services and link those services to Configuration Items
The Service Catalog can be stored as Configuration Items in the Configuration Management Database
Changes to a Service Level Agreement must be reflected in the Service Catalog
Configuration Management with Financial Management
Configuration Management is responsible for verifying receipt of new Configuration Items

The Configuration Management Database describes the corporate assets
Financial Management needs to know the components utilized by each business unit especially when
Charging is in place (2.6)
Financial Management works with Capacity, Configuration and Service Level Management to estimate the
costs for the desired Capacity (2.2, SD 5.1.5)
5.1.6)
Cost is an attribute of a Configuration Item (SD 5.1.5)
The IT Accounting group must be trained on the fundamentals of Capacity, Change, Configuration and
Service Level Management (SD 5.5.9)
Financial Management should conduct periodic audits to ensure that the interfaces into Configuration,
Capacity and Service Level Management are working and provide the necessary workload information (SD
5.7.11)
Financial Management should work with Configuration Management to ensure that the Configuration Items
are up-to-date and accurate (SD 5.7.11)
53
Configuration Management with Capacity Management

The Capacity Plan and other Service Management Plans should be identified in the Configuration
Management Database
Capacity Management should work with Change, Configuration and Release Management to create and
implement Requests for Change to ensure that appropriate Capacity is available (2.3)
The performance requirements for a Service should be recorded as Configuration Items (SD 6.2.1)
The capacity and configuration of Configuration Items should be accessible from both the Capacity
Management Database and the Configuration Management Database (SD 6.2.1)
The Capacity Management and Configuration Management Databases can be merged into one database
(SD 6.2.1)
Capacity Management monitoring is linked through the Configuration Management Database to Changes
both to predict the probable impact and to asses the actual impact (SD 6.3.2)
Configuration Management with IT Service Continuity Management

The definition of the Configuration Items and the copies in the Definitive Software Library can be used
during disaster recovery
Service Continuity and Availability Management rely on the Configuration Management Database to
identify components to perform risk analysis and component failure impact analysis (2.6)
Configuration Management should verify that the restored configuration matches the prior configuration
A successful Service Continuity program is dependent upon rigorous Configuration and Change
Management processes (SD 7.1.4)
Service Continuity is dependent upon Configuration Management for the definition of the core
infrastructure (SD 7.1.8)
Recovery planning requires an in-depth understanding of the relationships between the components in the
infrastructure (SD 7.3.3)
Configuration Management with Availability Management
Configuration and monitoring data on each component is used in Availability planning
The Configuration Management Database serves Availability Management through definitions of the
configuration and by recording Incidents, Problems and Requests for Change (SD 8.8.2)
54
7. Change Management
55
7.1.
7.1. Change Management Synopsis Too bureaucratic
Goals Cultural difficulties with single CM system
Standardized methods Process circumvented
Efficient and prompt handling of Changes Dependent on Configuration Management
Minimize impact from Change
Improve day-to-day operations Tools
CMDB with CI, IR, PR, KE and RFCs
Benefits
IT aligned with business Activities
Increased visibility and communication Filtering Changes
Improved risk assessment Managing Changes and the Change Process
Reduced impact from Changes Chairing the CAB and the CAB/EC
Fewer Changes backed-out Reviewing and closing RFCs
Provide data to PM and Availability Management reporting
Increased productivity of users
Fewer IT diversions Inputs
Ability to absorb more Changes RFCs
Enhanced business perspective on IT CMDB
FSC
Critical Success
Success Factors
CM requires an appropriate tool Outputs
Implement CM with Configuration & Release FSC
Plan, test and train for CM process RFCs
Management commitment CAB minutes
Audit trails in the tool Management reports
CAB requires authority
Introduce regular Change Slots Manager’s Duties
Receive, log, prioritize, filter RFCs
Key Performance Indicators Agenda, plan & conduct CAB & CAB/EC
Number of Changes, grouped Authorize Changes based on CAB
Breakdown reasons for Change Issue FSC via Service Desk
Number successful Liaise & coordinate Change process
Number backed-out Update log & RFC
Number secondary Incidents Provide management reports & trends
Number and trends on RFCs
Size of review backlog Other Roles
High RFCs due to fragile components Change Advisory Board
Prior year comparison Change Advisory Board/Emergency Committee
Number of RFCs rejected
56
7.2.
7.2. Change Management Goal Statement
The goal of the Change management process is to ensure that standardized methods
and procedures are used for efficient and prompt handling of all Changes, in order to
minimize the impact of Change-related Incidents upon service quality, and consequently
to improve the day-to-day operations of the organization.
7.3.
7.3. Change Management Benefits
• "Better alignment of IT services to business requirements
• Increased visibility and communication of Changes to both business and service-
support staff
• Improved risk assessment
• A reduced adverse impact of Changes on the quality of services and on SLAs
• Better assessment of the cost of proposed Changes before they are incurred
• Fewer Changes that have to be backed-out, along with an increased ability to do
this more easily when necessary
• Improved Problem and Availability Management through the use of valuable
management information relating to changes accumulated through the Change
Management process
• Increased productivity of Users – through less disruption and, higher-quality
services
• Increased productivity of key personnel through less need for diversion from
planned duties to implement urgent Changes or back-out erroneous Changes
• Greater ability to absorb a large volume of Changes
• An enhanced business perception of IT through an improved quality of service
and a professional approach" (SS 8.4.1)
7.4.
7.4. Change Management Critical Success Factors
• CM requires an appropriate tool
• Implement CM with Configuration & Release
• Plan, test and train for CM process
• Management commitment
• Audit trails in the tool
• CAB requires authority
• Introduce regular Change Slots
7.5.
7.5. Change Management Key Performance Indicators
• “The number of Changes implemented in the period, in total and by CI,
configuration type, service, etc
• A breakdown of the reasons for Change (User requests, enhancements, business
requirements, service call/Incident/Problem fixes, procedures/training
improvement, etc)
57
• The number of Changes successful
• The number of Changes backed-out, together with the reasons (e.g. incorrect
assessment, bad build)
• The number of Incidents traced to Changes (broken down into problem-severity
levels) and the reasons (e.g. incorrect assessment, bad build)
• The number of RFCs (and any trends in origination)
• The number of implemented Changes reviewed, and the size of review backlogs
(broken down over time)
• High incidences of RFCs/PRs (Problem Records) relating to one CI (these are
worthy of special attention), giving the reasons (e.g. volatile User requirement,
fragile component, bad build)
• Figures from previous periods (last period, last year) for comparison
• The number of RFCs rejected
• The proportion of implemented Changes that are not successful (in total and
broken down by CI)
• Change backlogs, broken down by CI and by stage in the Change Management
process" (SS 8.7)
7.6.
7.6. Change Management Possible Implementation Problems
• The process is perceived to be too bureaucratic or rigorous
• Cultural difficulties in getting staff, Customers and Users to adopt a single
Change Management system
• The process is routinely circumvented
• Change Management implemented without Configuration Management
7.7.
7.7. Change Management Tools
"For all but the smallest of organizations, a Configuration management-based tool,
capable of storing all relevant configuration items (CIs), and the important relationships
between them, should be used. Such a tool should have the following facilities:
• Requests for Change (RFC) and Problem Records (PR) stored upon the same
database, in an easily accessible format
• The ability to identify the relationship between RFCs, PRs and CIs
• The capability to link RFCs to projects
• The means to identify easily the other CIs that will be impacted whenever a
Change to any specific CI is proposed
• Automatic production of requests for impact and resources assessment to the
‘owners’ of the impacted CIs
• The ability for all authorized personnel to submit RFCs from their own terminal
or location
• The ability to ‘progress’ requests through the appropriate stages of
authorization and implementation and to maintain clear records of this progress
58
• The ability to allow Change Management staff, Change builders, testers, etc to
add text to Change records
• Clear definition of back-out procedures should a Change cause problems
• Automatic warnings of any RFCs that exceed pre-specified time periods during
any stage
• Automatic prompting to carry out reviews of implemented Changes
• Automatic generation of management and trend information relating to Changes
• The ability to build Changes
• Automatic production of Forward Schedule of Changes (FSC)
• A process/workflow feature" (SS 8.8)
7.8.
7.8. Change Management Inputs and Outputs
Inputs:
• Requests for Change

• Configuration Management DataBase
• Forward Schedule of Changes
Outputs:
• Updated Forward Schedule of Changes

• Updated Requests for Change
• Change Advisory Board (CAB) minutes and actions
• Change Management Reports
Activities:
• Filtering Changes
• Managing Changes and the Change Process
• Chairing the CAB and the Change Advisory Board/Emergency Committee
• Reviewing and closing Requests for Change
• Management reporting
59
7.8.1. Change Management Inputs and Outputs Diagram
7.8.2. Change Management Inputs and Outputs Description

Incident, Problem, The Configuration Management Database (CMDB) is the central
Known Error and repository for ITIL information. A Change is initiated with a Request for
Request for Change Change (RFC). That RFC should be linked to the relevant data in the
linked to CMDB including a history of Incidents and Problems. The Known Errors
Configuration Items that this RFC is to resolve and indirect linkages to all of the
Configuration Items that will be impacted by this Change.
Change Management The details underlying this Change Management process must be
Process and Policy documented in predefined processes and policies. The Change Manager
uses those policies when assigning the Change to a Category, assigning
a Priority and assessing the RFC. Other players in the Change
Management process include the roles of Change Initiator, Change
Builder, Independent Tester, Change Implementer, Change Advisory
Board and Change Advisory Board / Emergency Committee. All of those
roles and their responsibilities must be defined in the Change
Management policies.
60
Build, Few Changes are truly new. Thus, those responsible for building the
implementation and product, defining the implementation, testing and back out plans should
back-out templates, have standard templates to work from. Additionally, when this work
policies and plans overlaps with Release Management and Configuration Management then
policies for those processes must also be referenced.
Results from Testing ITIL recommends assigning the testing of the Change, the
implementation plan and the back out plan to an Independent Tester.
That tester will report the results of those tests to the Change Builder
and the Change Manager.
Results from The results from implementing the Change will be reported to the
Implementation Change Manager along with any secondary Incidents or Problems
generated by the Change process.
User evaluation of An RFC is only successful if the user is satisfied that the Problem(s)
results addressed by this RFC have been successfully resolved.
Change Management The flow through the Change Management process is illustrated in the
diagrams immediately below this section.
Request for Change The Change Manager is responsible for coordinating the Change and
status updates, providing updates to the Configuration Manager so that the RFC can be
assessment and updated.
schedule
Forward Scheduled This output is from the Configuration Management process and is
of Change, and included here only to fill in an obvious gap.
Planned Schedule of
Availability
Communication with This output is from the Configuration Management process and is
Service Desk, Users, included here only to fill in an obvious gap.
Customers and other
ITIL processes
Change Review Periodic Change Reviews will be scheduled. The Change Review can
assessment, process either be done by the Change Manager or by the Change Advisory Board
adjustments and (CAB). The purpose for the Change Review is to assess the success of
process metrics the Change and evaluate the process.
7.9.
7.9. Change Management Process Flow
The Change Management Process Flow has been separated into three. The first diagram
illustrated the Authorization Flow. The second diagram shows the Implementation Flow.
The first and second diagrams are really one process, separated into two diagrams to
simplify the presentation. The third diagram is an alternate path that should be followed
when the Change requires urgent processing.
61
7.9.1. Change Management Authorization Flow Diagram
62
7.9.2. Change Management Authorization Flow Description
Aspect Description
Start The Change Management process formally begins with the creation of a
Request for Change (RFC). This process can begin with a form
transmitted through email. The person who creates the RFC is called the
Change Initiator.
Change Manager The Change Manager assesses the RFC for completeness.
filters requests
Configuration The Configuration Manager is responsible for administration of the RFC.
Manager logs the All RFCs will be stored in the Configuration Management Database
RFC (CMDB). After the Change Manager filters the RFC, the Configuration
Manager will enter the RFC into the CMDB.
Accepted The Change Manager can either accept the RFC for processing, or reject
it and return it to the Change Initiator for correction.
Change Manager The Change Manager will review the RFC and assign an initial priority.
assigned initial
priority
Configuration The Configuration Manager will shadow the Change Manager and record
Manager updates log the priority in the CMDB.
Urgent ? If the RFC is Urgently needed, the Change Manager will divert the RFC
from the normal flow over to the Urgency Flow.
See Urgency Flow The Urgency Flow is documented later in this document.
Change Manager The Change Manager will continue the evaluation of this RFC and assign
decides on category it to the appropriate category based upon the scope of the Change.
Configuration The Configuration Manager is responsible for identifying the impact by
Manager reports on examining the linkages in the CMDB.
impact
Category ? Appropriate Categories must be defined, and then processing must be
defined for each. The categories illustrated here are typical, but only
illustrative.
Use Standard When the same Change Process is used repeatedly, it should be
Processes packaged and presented to the Change Advisory Board (CAB) as a
“standard process”. Once authorized by the CAB, the standard process
can be repeatedly invoked without requiring authorization for each
invocation.
Change Manager There should be a category of change that is within the jurisdiction of
authorizes and the Change Manager. When an RFC fits into this category, the Change
schedules Manager can authorize execution and then forward the RFC to the CAB
for review.
63
Aspect Description
Change Manager There should be a category of change that is beyond the jurisdiction of
sends to CAB the Change Manager, but within the jurisdiction of the CAB. When an
unauthorized RFC fits into this category, the Change Manager will review and assess
the RFC and then forward the RFC to the CAB for action.
Executive There should be a category of change that is beyond the jurisdiction of
Management sends the CAB. These types of changes are so major in their scope or impact
to CAB authorized or cost that they require authorization from Executive Management.
Executive Management must have a defined process for reviewing and
authorizing these RFCs. Once authorized, the RFC will be sent to the
CAB for review.
CAB review and The CAB must review all RFCs. Based upon the category specific flow,
assessment the CAB may review the RFC only for informational purposes or may be
called upon to review the RFC and decide to authorize or reject the RFC.
Configuration The Configuration Manager continues to shadow the RFC and update the
Manager issues electronic copy to report on status updates. The Configuration Manager
Forward Schedule is also responsible for distributing the Forward Schedule of Changes
(FRSC) to disseminate information so that actions can be coordinated.
Authorized ? If the RFC is authorized, then it continues through the flow into the
Implementation Flow. Otherwise, it is returned to the Change Initiator
for modification.
See Implementation This process flow was separated into segments only to simplify the
Flow presentation.
64
7.9.3. Change Management Implementation Flow Diagram
65
7.9.4. Change Management Implementation Flow Description
Aspect Description
Authorization Flow The Authorization Flow is illustrated earlier in this document.
Change Builder It is the responsibility of the Change Builder to create the product,
builds and devises document the implementation plan and document the back out plan.
plans
Configuration The Configuration Manager will shadow the Request for Change (RFC)
Manager updates log and record status updates as the process continues.
Independent Tester Testing should be performed by someone other than the Change
tests the change Builder. Testing needs to evaluate the product, the implementation plan
and the back out plan.
Test successful When the test is successful, the Change is ready for implementation.
However, if the testing is not successful, the results must be given to
Change Builder to correct.
Change Manager The Change Manager is responsible for the schedule and coordination of
coordinates the Change. Note, however, that the Change Manager works closely with
implementation the Configuration Manager even on this step.
Configuration The Configuration Manager is responsible for verifying that the product
Manager informs is managed. If this is software, it must be properly checked into the
users Definitive Software Library. The Configuration Manager is also
responsible for informing the users. Early notification was provided in
the Forward Schedule of Changes. More imminent notification must
follow the predefined process.
Working ? Following implementation, the Change Implementer is responsible for
verifying whether or not the Change resolved the Problem and whether
or not the Change has created secondary Incidents or Problems. Based
upon that assessment, the Change will either be left in place or
removed.
Change Builder While the ITIL guide states that the “Change Builder” is the person that
executes back out executes the back out plan that actually depends upon the status of the
plan Release Management process. If a Release Management if fully
implemented, then there will be a designated Change Implementer with
privileges in the production environment. With Release Management, the
Change Builder will probably not have the privileges required to
implement the change or execute the back out plan.
Change Manager Periodic Change Reviews will be scheduled. The Change Review can
performs Change either be done by the Change Manager or by the Change Advisory Board
Review (CAB). The purpose for the Change Review is to assess the success of
the Change and evaluate the process.
66
Aspect Description
Configuration If the Change was successful, the Configuration Manager is now
Manager updates authorized to close the RFC. If the Change was backed out, then the
RFC Change Manager needs to work with the Change Initiator to create a new
RFC. The old RFC will then be linked to the new RFC so that the history
is available to aid in correcting the prior defects.
Implement Success ? Whether a Change was successful or failed must be determined by the
users.
To Start Even though the implementation may have been successful, the Change
might not resolve the Problem. The Problem may have compound
sources. For example, implementing a Change to address known
Problem on a database server may be successful, and yet not yield the
desired performance because of an undiagnosed bottleneck on the web
server.
Closed When the Change has been successfully implemented, the user confirms
that the results are satisfactory, and the Change Review confirms the
process, then the RFC can be formally closed.
67
7.9.5. Change Management Urgency Flow Diagram
68
7.9.6. Change Management Urgency Flow Description
Aspect Description
Authorization Flow The Authorization Flow is illustrated earlier in this document.
Change Manager The Change Manager must assess the degree of urgency. If possible, a
calls meeting meeting of the full Change Advisory Board (CAB) should be convened. If,
however, the urgency does not permit that delay, then the Change
Manager must call a special meeting of the Change Advisory Board /
Emergency Committee (CAB/EC). The process for this invocation must
be defined. The CAB/EC can be a predefined set of members or the
CAB/EC can be defined as a simple quorum of the standard committee.
CAB or CAB/EC Urgency is a predefined category of Change. The process for the CAB or
assesses the Change CAB/EC urgent assessment must be defined and will probably be a
subset of the full assessment that the CAB would undertake for a
“Significant” Change, as described under the Change Authorization Flow
earlier in this document.
Urgent ? If the CAB or CAB/EC concludes that this Change is not appropriately
categorized as an Urgent Change, then this Request for Change (RFC) is
returned to the standard Change Authorization Flow.
Change Builder It is the responsibility of the Change Builder to create the product,
urgently prepares document the implementation plan and document the back out plan.
Change
Time for Testing ? Testing is a vital quality assurance check. On occasion, however, the
Urgency of the Change is such that authorization is granted by the
Change Manager to bypass the testing requirement.
Independent Tester Testing should be performed by someone other than the Change
does urgent testing Builder. Testing needs to evaluate the product, the implementation plan
and the back out plan.
Test successful When the test is successful, the Change is ready for implementation.
However, if the testing is not successful, the results must be given to
Change Builder to correct.
Change Manager The Change Manager is responsible for the schedule and coordination of
coordinates the Change. Note, however, that the Change Manager works closely with
implementation the Configuration Manager even on this step.
Working ? Following implementation, the Change Implementer is responsible for
verifying whether or not the Change resolved the Problem and whether
or not the Change has created secondary Incidents or Problems. Based
upon that assessment, the Change will either be left in place or
removed.
69
Aspect Description
Change Manager Although the Change Manager is unlikely to be the person that actually
executes back out executes the back out plan, Urgent Changes must be fully managed by
plan the Change Manager.
Change Manager Because of the rapid pace of an Urgent Change, the Configuration
ensures records are Manager is often informed retroactively. It is the responsibility of the
updated Change Manager to ensure that proper documentation is maintained so
that the Configuration Manager can document the RFC.
Configuration As well as possible, the Configuration Manager will shadow the Request
Manager updates log for Change (RFC) and record status updates as the process continues.
Change Manager Periodic Change Reviews will be scheduled. The Change Review can
performs Change either be done by the Change Manager or by the Change Advisory Board
Review (CAB). The purpose for the Change Review is to assess the success of
the Change and evaluate the process.
Configuration If the Change was successful, the Configuration Manager is now
Manager updates authorized to close the RFC. If the Change was backed out, then the
RFC Change Manager needs to work with the Change Initiator to create a new
RFC. The old RFC will then be linked to the new RFC so that the history
is available to aid in correcting the prior defects.
Implement Success ? Whether a Change was successful or failed must be determined by the
users.
To Start Even though the implementation may have been successful, the Change
might not resolve the Problem. The Problem may have compound
sources. For example, implementing a Change to address known
Problem on a database server may be successful, and yet not yield the
desired performance because of an undiagnosed bottleneck on the web
server.
Closed When the Change has been successfully implemented, the user confirms
that the results are satisfactory, and the Change Review confirms the
process, then the RFC can be formally closed.
7.10.
7.10. Change Management Relationships with other Service Management
Management Processes
Please refer to the prior section for the relationship of Configuration Management with
Service Desk, Incident, Problem and Configuration Management
Change Management with Release Management
Change Management authorizes the change while Release Management implements the change
Groups of concurrent changes should be bundled into a Release
Pre-defined "standard" changes do not need to go back to the Change Advisory Board as the process is
pre-approved
Management
70
Change Management with Release Management
Release Management works with Change Management to agree to the contents of each Release
Release Management coordinates all Changes with Configuration Management and Change Management
(2.8)
Release Management works with Configuration Management and Change Management to insure that the
Configuration Management Database is accurately maintained
A Release is defined by the Requests for Change that are resolved in it
Change Management should ensure there is User Acceptance of the build before it is released
The policies and procedures also need to be under Change Management
The organizations Release policies is normally incorporated into the Change Management plan
Updates to the environment, such as the addition of new hardware, operating systems or languages, often
require changes to the release policy
Standard processes can be pre-authorized such as a process for the installation of specific software onto
desktops
The detailed Release plan should be included in the Change Management plan
The status of the release should be tracked through Change Management, including failures
The status on the Request for Change and the status on the Release should be tracked through the same
tool
Require users to go through a Change Management process to add any software to their desktops
Change Management with Service Level Management
Service Level Management can initiate a Request for Change based upon feedback from a customer
The Service Level Manager should be on the Change Advisory Board
Availability, Capacity, Continuity and Service Level Management should evaluate the probably impact from
each Change
A properly implemented Change Management process will have a positive impact on Service Level
compliance
The customer needs to be included in the process, as appropriate
The Change Management process should be documented in the Service Level Agreements so that Users
know the procedure for requesting a Change, the projected target time and the impact of implementing a
Change (2.7)
The Change Management (and Release Management) tracking tool must support whatever tracking is
agreed to in the Service Level Agreement
The Service Level Agreements must be subject to a Change Management policy
Changes to a Service Level Agreement must be reflected in the Service Catalog
Operational Level Agreements and Underpinning Contracts must be managed through a Change
Management process and reviewed at least annually
The Service Level Agreement can include targets for implementing Requests for Change
Service Level Management is responsible for assessing the impact of Changes on service quality and
Service Level Agreements both before the Change and after (2.1)
71
Change Management with Financial Management
Each Change must be reviewed to ensure the Change is within the budget or that the Change can be
justified through benefit/cost analysis
5.1.6)
Most business separate core services from optional services and charge separately for Changes, except
where those Changes are part of the process of meeting the Service Level Agreements (SD 5.4.3)
Financial Management should attend the meetings of the Change Advisory Board and process all Changes
to the Financial Management Process through the Change Management process (SD 5.7.1)
Changes to the infrastructure and Services must be processed through Change Management and may
require Changes to the Financial Management processes (Accounting and Charging) and to the Service
Level Agreements (SD 5.7.2)
Financial Management should conduct periodic audits to ensure that the Change and Problem
Management processes are strictly followed (SD 5.7.11)
Change Management with Capacity

Capacity Management
Capacity Management identifies and recommends changes to meet the business needs
Improvement in Availability or Capacity need to go through Change Management
Capacity Management can assist by building a model of the proposed change to study the impact on the
infrastructure
each Change
Capacity Management assists Change Management by assessing the impact a Change will have on Capacity
requirements (SD 6.1.1, 6.2)
Change Management needs to feed Capacity Management the Forward Schedule of Changes (SD 6.2)
Capacity Management needs to work through Change Management when a Change will require Changes to
insure sufficient Capacity (2.3, SD 6.2, 6.7.3)
Capacity Management may recommend Changes to take advantage of new technology, in response to the
retirement of components or Services, in response to Changes or in response to business needs (SD 6.2.1)
Capacity Management should have a representative member on the Change Advisory Board (SD 6.2.1,
6.7.3)
have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3)
Resource Capacity Management should evaluate technology updates and recommend cost effective
Changes (SD 6.2.3)
Capacity Management monitoring is linked through the Configuration Management Database to Changes
both to predict the probable impact and to asses the actual impact (SD 6.3.2)
Once Capacity Management identifies tuning opportunities, those recommendation must be processed
through Change Management (SD 6.3.4, 6.5.3, 6.7.3)
Capacity Management is responsible for "application sizing" to estimate the resources required for a new
72
Change Management with Capacity
Capacity Management
application and works with Application Management to plan for resiliency (SD 6.3.8)
Capacity Management should have representation on the Change Advisory Board to asses the risk in
Changes and thus preclude Problems (SD 6.4.2)
Capacity Management should reduce the number of urgent Changes and reduce the risk of Problems (SD
6.4.2)
The Capacity Management Database must be encompassed within a Change Management policy (SD 6.5.2)
Implementation and updates to the monitoring for Capacity Management must be managed through
Change Management (SD 6.5.3)
Changes recommended by Capacity Management must be cost justifiable (SD 6.7.7)
The Service Continuity aspects of Changes to Capacity must be assessed by Capacity Management so that
IT Service Continuity Management can evaluate updates to the continuity planning (SD 6.7.8)
Resiliency improvements must be assessed for their impact on Capacity, while Capacity improvements
must be assessed for their impact on Availability (SD 6.7.9)
Change Management with IT Service Continuity Management
Change has the potential to impact continuity

each Change
A successful Service Continuity program is dependent upon rigorous Configuration and Change
Management processes (SD 7.1.4, 7.6)
Change Management processes must be used to ensure the currency and accuracy of the Continuity Plan
through established processes and regular reviews (SD 7.1.8, 7.3.4)
Service Continuity is not focused on long term risks such as competitive pressures. Those types of risks
must be managed through business strategy and worked through an on-going Change Management
process (SD 7.2.2)
Resiliency improvements must go through the Change Management process (SD 7.3.2)
Change Management is a risk reduction activity (SD 7.3.2)
Each Change must be assessed for the effect it may have on Service Continuity plans, and those plans may
need to be revised and retested (SD 7.4.1)
Change Management with Availability Management
Change has the potential to impact continuity

Improvement in Availability or Capacity need to go through Change Management
each Change
Each Change should be evaluated for security implications
Availability Management will give Change Management guidance on the agreed maintenance schedule
Change Management should give Availability Management the Forward Schedule of Changes
Planning for Availability early in the design will avoid the expense of making Changes later in the project
73
Change Management with Availability Management
(SD 8.4.1)
The time allotted for a Change (preparation, implementation, verification) should be defined as a Service
Maintenance Objective (SD 8.5.6)
Change Management should report on the impact from poor planning and the number of Changes that
have overrun the Service Maintenance Objective (SD 8.7.7)
74
8. Release Management
Bypassed during emergencies
8.1.
8.1. Release Management Synopsis Reluctance to build both in dev & test environments
Goals Difficulties implementing in remote environments
Plan & oversee rollout Perception process is cumbersome & expensive
Design & implement efficient procedures Unclear ownership
Ensure HW & SW is traceable, secure & authorized Insufficient testing staff and environment
Communicate and manage Customer expectations Lack of understanding of the Release contents
Liaison with CM to agree content & rollout plan Testing environment not matching Live
Implement Releases in conjunction with CM & RM Reluctance to back out once started
Secure software in DSL
Ensure CMDB is updated Tools
RFC & Release status database
Benefits Release automation linked to CMDB
Improved Quality of Service via success rate Software Configuration Management tools
Consist, faster, accurate Release process SCM linked to PRs and RFCs
Minimization of disruption Build automation
Assurance of quality HW & SW Automatic upload to DSL from Build tool
Stable test & live environments Automation for distribution & installation
Better use of Users in testing Automatic prerequisite verification
Grouping releases for efficiency Desktops locked-down
Better expectation setting by publishing schedule Reload from image files
Audit trail Remote control for implement & troubleshooting
Safeguarding HW & SW Remote monitoring
Ability to absorb more Changes
Ability to build and control remotely Activities
Savings through consistency in multiple locations Release Planning
Smoother transition from development to Live Designing, building and configuring a Release
Release acceptance
Critical Success Factors Rollout planning
Clearly defined roles & responsibilities Communication, preparation and training
Well defined processes Distribution and installation
Accurate & complete Configuration Items Inputs
Implement RM with Configuration & Change Business needs
Technology options
Key Performance Indicators
Releases built & implemented on schedule Outputs
Number of releases backed-out Agreed release contents and schedule
Number of Build failures Release contents into the DSL
Legal compliance Implemented Releases
No licenses wasted
No reversion to prior versions Manager’s Duties
No unauthorized SW in use Propose, agree & implement processes
All activities logged in CMDB Liaise, coordinate, monitor and report
Actual Release matches planned
Other Roles
Problems Change Builder
Resistance to change Independent Tester
Teams most in need have least time Change Implementer
Circumvention of the process
75
8.2.
8.2. Release Management Goal Statement
The goals of Release Management are:
• To plan and oversee the successful rollout of software and related hardware
• To design and implement efficient procedures for the distribution and
installation of Changes to IT systems
• To ensure that hardware and software being changed is traceable, secure and
that only correct, authorized and tested versions are installed
• To communicate and manage expectations of the Customer during the planning
and rollout of new Releases
• To agree the exact content and rollout plan for the Release, through liaison with
Change management
• To implement new software Releases or hardware into the operational
environment using the controlling processes of Configuration management and
Change Management – a Release should be under Change Management and may
consist of any combination of hardware, software, firmware and document CIs
• To ensure that master copies of all software are secured in the Definitive
software library (DSL) and that the Configuration management database (CMDB)
is updated
• To ensure that all hardware being rolled out or changed is secure and traceable,
using the services of Configuration Management
8.3.
8.3. Release Management Benefits
• "A greater success rate in the Release of hardware and software and therefore an
improved quality of service delivered to the business
• Consistency in the Release processes of the hardware platforms or software
environments
• Minimization of the disruption of the service to the business through
synchronization of Releases within packages involving hardware and software
components from different platforms and environments
• Assurance that the hardware and software in live use is of good (or known)
quality, because the Releases are built properly, from hardware and software
components that have been subject to quality control and effective testing, and
have been constructed under Change Management
• Stable test and live environments, because Changes are normally combined into
Releases and so there should be fewer individual implementations
• Better use of User resources because of combined efforts when testing new
Releases – this also means that it will be easier to justify the cost of system-wide
regression testing
• Minimization of regression-testing requirements, offering greater coverage than
is possible with small Changes that occur frequently or too close together
76
• Better expectation setting within the organization on publication of a Release
schedule in advance
• Error reduction through the controlled Release of hardware and software to the
live environment, e.g. avoiding incorporating an incorrect version into the
Release
• A complete record (or audit trail) of Changes to the live environment is
maintained, both of software distributions and of hardware Changes
• Proper control and safeguarding of hardware and software assets, upon which an
organization may be heavily dependent
• An ability to absorb high rates of Change to the live systems, effectively and
without adversely affecting IT service quality – this is achieved by releasing a
large number of Changes together as a single, controlled and well-understood
Release
• The ability to build and control the software used at remote sites from a central
location
• Savings in support costs through the ability to maintain consistent software over
a large number of locations
• Reduced likelihood of there being illegal copies of software in use at any location
• Easier detection of wrong versions and unauthorized copies of software
• Reduced risk of unnoticed introduction of viruses or other malicious software
• Reduced time to Release and fewer delays
• Fewer Releases to be rolled out to Customers
• Smoother transitions of Releases from the development activities (projects) to
the Customer’s business environment" (SS 9.4.1)
8.4.
8.4. Release Management Critical Success Factors
• Are roles and responsibilities clear?
• Are the rollout procedures sound?
• Is there adequate budget and resource committed to complete the Release?
• Have all the necessary RFCs been raised and authorized, and is it planned to
update the CMDB?
• Have all training issues been considered: end users, IT support staff, Release
Management staff?
• Has technical support for the rollout been properly planned and agreed?
• Are there any software licensing issues to consider during the rollout (e.g.
software copyright protection schemes such as dongles, or authorization
passwords)?
• Have all the Capacity Management issues been considered and planned (e.g.
response times and LAN traffic)?
77
• Do the plans conform to the organization’s Release policy? For example, a
company might state that it intends to allow any person to access any
application from any workstation; or they may allow or disallow individuals from
installing their own software.
• Are there any software/hardware dependencies? For example, some software
may only work on certain hardware combinations; or some software may only
work with certain other software prerequisites.
• Does the rollout plan fit in with the established Service Management and support
procedures?
• Are there any installation issues not yet resolved?
• Has operational acceptance testing been included in the plans?
• Is there a procedure to verify successful implementation of a Release?
• Are there any outstanding, hardware, cabling, network or environmental issues
(e.g. power supplies)?
• Have clear acceptance criteria for the system going live been agreed?
• Is there a clear procedure for approving the stage sign-offs and the final sign-
off of the Release?
• Does the rollout plan conflict with any other planned Changes?
• Has the emergency fix policy been determined?
• Has a thorough back-out plan been produced and tested?
• Has the schedule for a specific Release been published?
• Have the Service Desk, Technical Support, Service Level Manager and the
Customers and Users been informed?
• Has the SLA and any OLAs or contracts been reviewed and revised?
• Has the Business Continuity Plan been updated to reflect the Changes?
8.5.
8.5. Release Management Key Performance Indicators
• "Releases built and implemented on schedule, and within budgeted resources
(but care should be taken to isolate any problems that are outside the control or
responsibility of Release Management, such as application development delays)
• Very low (ideally no) incidence of Releases having to be backed out due to
unacceptable errors (note however that software Releases need not be entirely
error-free; a decision can be made to go ahead with a Release despite the
presence of errors, provided that they are of a minor nature, and within the
permitted fault tolerances – see Chapter 6, Problem Management)
• Low incidence of build failures
• Secure and accurate management of the DSL
• No evidence of software in the DSL that has not passed quality checks and no
evidence of reworks on any software that was extracted from the DSL
• DSL sizing matching the demand for space, and timely and accurate
housekeeping of the DSL
• Compliance with all legal restrictions relating to bought-in software
78
• Accurate distribution of Releases to all remote sites
• Implementation of Releases at all sites, including remote ones, on time
• No evidence of unauthorized reversion to previous versions at any site
• No evidence of use of unauthorized software at any site
• No evidence of payment of license fees or wasted maintenance effort, for
software that is not actually being used at any particular location
• No evidence of wasteful duplication in Release building (e.g. multiple builds of
remote sites, when copies of a single build would suffice)
• Accurate and timely recording of all build, distribution and implementation
activities within the CMDB
• A post-mortem carried out on all Release activities, and all necessary corrective
or follow-up action taken, together with any process improvements
• The planned composition of Releases matching the actual composition (which
demonstrates good Release planning)
• IT and human resources required by Release Management being subject to good
ongoing forward planning" (SS 9.7.1)
8.6.
8.6. Release Management Possible Implementation Problems
• "There may be some initial resistance from staff who are familiar with the old
procedures and who may not welcome change. To overcome this, the benefits of
the new procedures should be carefully explained during an awareness
campaign, and there should be a close working relationship with the team
implementing the Changes.
• Experience has shown that those teams that are in most need of help with
Release Management often have the least time to adopt it. One way round this is
to look for minimal-impact ways to gain a foothold and to provide them with
some hands-on assistance at the beginning.
• Circumvention of the Release Management procedures may be attempted. This
needs to be dealt with firmly, particularly if it involves the installation of
unauthorized software, as this is the most likely cause of viruses or untested
software that make support very difficult and costly.
• Staff may also be tempted to bypass the standard procedures to install an
emergency fix. This should be banned, and disallowed by software security rules
as far as possible.
• There may be some reluctance to carry out a controlled build in the test
environment, relying instead on copying over software from the development
environment.
• In a distributed system, difficulties may arise if new versions of software or
hardware are not installed and activated on time at remote locations. The use of
software distribution tools, backed up by regular audits, can help avoid this
problem.
79
• Some people (including IT management) may view the Release Management
procedures as cumbersome and expensive. Nevertheless, they are almost
invariably necessary to cope efficiently and effectively with software Changes.
• Unclear ownership and responsibilities between operational groups and
development teams (project teams) may exist – for instance, there may be a lack
of understanding about who is responsible for managing components of a
Release at different points in the Release cycle.
• Insufficient resources available for adequate testing will reduce the effectiveness
of these procedures, or a high number of variants in the live environment may
limit complete testing.
• If sufficient machine and network resources are not available, then it may be
impossible to build and test new Releases and equipment adequately, or in a
timely fashion. Time needs to be allowed in testing for a Release to fail the first
time and be reworked. Similarly, back-out procedures should be proven in a
controlled test environment.
• A lack of understanding of the Release contents, build and installation
components, can lead to mistakes.
• Testing in one area may be acceptable but may fail in another area – e.g.
different infrastructure or parameters not set to the same values.
• Staff may be reluctant to back out from a Release, and there may be pressure to
transfer inadequately tested software and hardware into the live environment.
• Poor, restricted or non-representative testing environments and procedures may
exist." (SS 9.4.2)
8.7.
8.7. Release Management Tools
• A system for tracking the status of the Request for Change and the Release
• Ideally the deployment of the release should be automated and linked to the
Configuration Management Database to automatically determine the locations to
receive the Release
• Software Configuration Management tools for archiving and building
• Ideally the Software Configuration Management tools should link to the Service
Desk tool and automatically retrieve the list of Problems and Requests for
Change that are incorporated into this Release
• The build process should be automated and automatically determine the
components that need to be recompiled to generate the Release
• An ideal build tool will automatically populate the Definitive Software Library
• Automation for software distribution and installation
• Automation to verify the prerequisites
• Desktops should be locked-down to make the Release installation more reliable
• New desktops can be built from images
• Remote control for implementing the Release and troubleshooting
• Remote monitoring
80
8.8.
8.8. Release Management Inputs and Outputs
Inputs:
• Business needs
• Technology options
Outputs:
• Agreed release contents and schedule

• Release contents into the DSL
• Implemented Releases
Activities:
• Release Planning
• Designing, building and configuring a Release
• Release acceptance
• Rollout planning
• Communication, preparation and training
• Distribution and installation
8.8.1. Release Management Inputs and Outputs Diagram
8.8.2. Release Management Inputs and Outputs Description

Development Whether this Release is for software, hardware or processes, there
Environment should be a clear separation of environments.
Controlled Test The Development Environment should be an area where adverse
Environment consequences will not impact the business. The Development
81
Live Environment Environment is not under Change or Release Management. The input
into the Release process from this environment is status, and the
finished product.
The Controlled Test Environment works best when it closely mimics the
Live Environment, does not allow adverse consequences to impact the
business, but facilitates joint access by those building the Release and
those testing the release. Note that ITIL strongly recommends that the
tester should not be involved with the actual build.
The Live Environment is the production environment. Release
Management uses the tools of Configuration Management to verify that
the Live Environment meets all of the prerequisites for the Release.
Release Management The primary activities of Release Management are illustrated in this
diagram. The sequencing of those activities is illustrated in the
subsequent process flow.
82
Release Policy The Release Policy must be developed. This Policy must define what
constitutes a Release. For example, is an upgrade to the monitor on 100
desktop systems a Release, a group of 100 Releases, or does this
“change” fall into the “business-as-usual” exemption from Release
Management? The specific topics that must be covered in the Release
Policy include the definition of categories, the requirements for testing,
notification and acceptance. ITIL recommends that the Release Policy
include:
• “Guidance on the level in the IT infrastructure to be controlled by
definable Releases (e.g. whole application systems or individual
program files)
• Release naming and numbering conventions
• A definition of major and minor Releases, plus a policy on
issuing emergency fixes
• Direction on the frequency of major and minor Releases (e.g. the
norm for an organization might be to have a schedule planned a
year in advance to contain a major Release every three months)
• Identification of business-critical times to avoid for
implementations, and how these should be managed (e.g. an
organization may decide to avoid changing its payroll system in
the last two weeks of each month, thus giving a predictable
window into which new Releases can be planned)
• Expected deliverables for each type of Release (e.g. installation
instructions and Release note)
• Guidance as to how and where Releases should be documented
(e.g. which tool to use and how)
• The policy on the production and degree of testing of back-out
plans
• The agreed role: responsibility of the central Release
Management function in technical reviews of the application
architecture and design
• A description of the Release Management control process (e.g.
review meetings, progress assessments (checkpoints), escalation,
impact analysis and checking of co-requisites)
• Documentation of the exact configuration of the DSL and the
definition of acceptance criteria for new software additions (see
below for some sample rules)”
83
Release Planning “Planning Release Management should include:
• Release policies and procedures
• Release roles and responsibilities of all staff
• Responsibilities of central Release Management staff
• Tools to support the Release of hardware and software into the
live environment, e.g. software distribution
• Staff to support Release Management
• Training
• Guidelines for the scheduling of events within an organization
and the production of outline Release schedules for predictable
events (where, for example, an organization might mandate that
all events be recorded in a certain way or use a particular event
database)
• Template documents to assist with the planning of specific
Releases
• The management and use of appropriate and effective build and
test environments
• Ensuring that correct Release mechanisms are in place
• Ensuring that there is sufficient space in the build, test,
distribution and live environments for a successful Release
Procedures should be documented for:
• Designing, building and rolling out a Release to the organization
• Software Release and distribution, including control and
maintenance of the DSL
• Purchasing, installing, moving and controlling software and
hardware that are relevant to Release Management
• The management and use of any supporting tools and facilities
• Release Management tracking, review, risk management and
Problem escalation”
Design and develop, Note that although this illustration and much of the discussion
or order and regarding Release Management is focused on the software development
purchase the cycle, Release Management applies equally to software, hardware and
software processes. The typical software development cycle begins with the
requirements and design and proceeds into development. The typical
hardware acquisition cycle begins with requirements, solicitation,
evaluation, purchase, receiving and disposition. Process development
must also be managed through Change and Release Management. For
example, implementing a Change in the requirements for testing a
Release must begin with an RFC, obtain authorization from Change
Management, and then proceed into Release Management to manage
the definition, design, testing and implementation.
84
Build and configure Release Management is responsible for ensuring there are defined
the Release processes and verifying that those processes are consistently followed.
Fit-for-Purpose In software, for example, the development group is responsible for
testing creating the code, assembling the code into a build area, building the
code, and performing predefined testing, including regression testing.
Automated tools can aid in insuring there is accuracy and consistency in
each of those steps.
Release Acceptance “The testing of the Release should be performed by independent
business staff and involve IT staff to verify any changed support
procedures. Any back-out procedures should be tested as part of this
activity, which should prove that the built Release can be installed and
run as required. This includes testing both the installation procedures
and the function of the final system.
Testing should cover the installation procedures and the functional
integrity of the resultant system. There should be a sign-off for each
stage of testing. The final acceptance and sign-off for the Release to go
into the live environment should be an agreed stage of the Change
management process. All levels of support should be involved in the
testing of major Releases.
Release acceptance should be performed in a controlled test
environment that can be reinstated to known configurations of both
software and hardware. These configurations should be described in the
Release definitions and stored in the CMDB, along with any other related
CIs.”
85
Roll-out planning “Rollout planning extends the Release plan produced so far to add
details of the exact installation process developed and the agreed
implementation plan. Rollout planning involves:
• Producing an exact, detailed timetable of events, as well as who
will do what (i.e. a resource plan)
• Listing the CIs to install and decommission, with details on the
method of disposal for any redundant equipment and software
• Documenting an action plan by site, noting any implications of
different time zones on the overall plans (e.g. an international
organization may well not have a single common Release window
when none of its systems is being used throughout the world)
• Producing Release notes and communications to end users
• Planning communication
• Developing purchasing plans
• Acquiring hardware and software where, because this often
involves the acquisition and deployment of numerous high-value
assets, the rollout plan should include the procedures to be
followed for their secure storage prior to rollout and the
mechanisms to trace their deployment during the
implementation (which could involve the use of asset tags or
other electronically readable labels)
• Scheduling meetings for managing staff and groups involved in
the Release”
Communication, “Customer liaison staff, Customers and support staff need to know what
Preparation and is planned and how it might affect them. This is normally accomplished
Training through training sessions, periods of parallel working, and involvement
in the Release acceptance stage. Problems and Changes that need to be
made during rollout should be communicated to all parties to keep them
informed and to set their expectations. This activity normally includes
running a series of rollout planning meetings with all of the interested
parties to ensure that the plans are properly reviewed, checkpoints are
established and all parties agree their responsibilities.
It is important to publicize the Release mechanism. It is also important
to publicize any constraints to end users (for example that it may not be
possible to affect an update to all PCs overnight in a large
organization).”
86
Distribution and Distribution, Installation and Activation can be sequenced over time or
Installation completed all at once. For example, a software patch can be distributed
to a large number of servers in advance, but only downloaded to
desktop systems at the authorized time. Or, the Telco lines can be
installed and a set of communications equipment pre-positioned but
only activated at the authorized time.
Configuration The Configuration Management Database (CMDB) is the central
Management repository for ITIL information. A Change is initiated with a Request for
Database (CMDB) Change (RFC). That RFC should be linked to the relevant data in the
CMDB including a history of Incidents and Problems. The Known Errors
that this RFC is to resolve and indirect linkages to all of the
Configuration Items that will be impacted by this Change. Once the
Release is completed, the CMDB must be updated to show that Change.
Definitive Software The Definitive Software Library (DSL) is administered by Configuration
Library (DSL) Management. But, as ITIL notes “the DSL exists not directly because of
the needs of the Configuration Management process, but as a common
base for the Release Management and Configuration Management
processes.”
ITIL defines the DSL as “the library in which the definitive authorized
versions of all software CIs are stored and protected. It is a physical
library or storage repository where master copies of software versions
are placed. This one logical storage area may in reality consist of one or
more physical software libraries or file stores. They should be separate
from development and test file store areas. The DSL may also include a
physical store to hold master copies of bought-in software, e.g. a
fireproof safe. Only authorized software should be accepted into the
DSL, strictly controlled by Change and Release Management.”
Note that the DSL only applies to software releases. Hardware releases
will be processed through the Definitive Hardware Store (DHS), while
process releases should be processed through the appropriate
Document Management System.
8.9.
8.9. Release Management Process Flow
The Release Management Process Flow shown below is overlaid on top of the Change
Management Implementation Flow. Please refer to the Change Management portion of
this document for a description of the Change and Configuration Management activities
shown on this diagram.
87
8.9.1. Release Management Process Flow Diagram
88
8.9.2. Release Management Process Flow Description
Aspect Description
Release Planning “Planning Release Management should include:
• Release policies and procedures
• Release roles and responsibilities of all staff
• Responsibilities of central Release Management staff
• Tools to support the Release of hardware and software into the
live environment, e.g. software distribution
• Staff to support Release Management
• Training
• Guidelines for the scheduling of events within an organization
and the production of outline Release schedules for predictable
events (where, for example, an organization might mandate that
all events be recorded in a certain way or use a particular event
database)
• Template documents to assist with the planning of specific
Releases
• The management and use of appropriate and effective build and
test environments
• Ensuring that correct Release mechanisms are in place
• Ensuring that there is sufficient space in the build, test,
distribution and live environments for a successful Release
Procedures should be documented for:
• Designing, building and rolling out a Release to the organization
• Software Release and distribution, including control and
maintenance of the DSL
• Purchasing, installing, moving and controlling software and
hardware that are relevant to Release Management
• The management and use of any supporting tools and facilities
• Release Management tracking, review, risk management and
Problem escalation”
Designing, building Release Management is responsible for ensuring there are defined
and configuring a processes and verifying that those processes are consistently followed.
Release In software, for example, the development group is responsible for
creating the code, assembling the code into a build area, building the
code, and performing predefined testing, including regression testing.
Automated tools can aid in insuring there is accuracy and consistency in
each of those steps.
89
Aspect Description
Release Acceptance “The testing of the Release should be performed by independent
business staff and involve IT staff to verify any changed support
procedures. Any back-out procedures should be tested as part of this
activity, which should prove that the built Release can be installed and
run as required. This includes testing both the installation procedures
and the function of the final system.
Testing should cover the installation procedures and the functional
integrity of the resultant system. There should be a sign-off for each
stage of testing. The final acceptance and sign-off for the Release to go
into the live environment should be an agreed stage of the Change
management process. All levels of support should be involved in the
testing of major Releases.
Release acceptance should be performed in a controlled test
environment that can be reinstated to known configurations of both
software and hardware. These configurations should be described in the
Release definitions and stored in the CMDB, along with any other related
CIs.”
Roll-out planning “Rollout planning extends the Release plan produced so far to add
details of the exact installation process developed and the agreed
implementation plan. Rollout planning involves:
• Producing an exact, detailed timetable of events, as well as who
will do what (i.e. a resource plan)
• Listing the CIs to install and decommission, with details on the
method of disposal for any redundant equipment and software
• Documenting an action plan by site, noting any implications of
different time zones on the overall plans (e.g. an international
organization may well not have a single common Release window
when none of its systems is being used throughout the world)
• Producing Release notes and communications to end users
• Planning communication
• Developing purchasing plans
• Acquiring hardware and software where, because this often
involves the acquisition and deployment of numerous high-value
assets, the rollout plan should include the procedures to be
followed for their secure storage prior to rollout and the
mechanisms to trace their deployment during the
implementation (which could involve the use of asset tags or
other electronically readable labels)
• Scheduling meetings for managing staff and groups involved in
the Release”
90
Aspect Description
Communication, “Customer liaison staff, Customers and support staff need to know what
Preparation and is planned and how it might affect them. This is normally accomplished
Training through training sessions, periods of parallel working, and involvement
in the Release acceptance stage. Problems and Changes that need to be
made during rollout should be communicated to all parties to keep them
informed and to set their expectations. This activity normally includes
running a series of rollout planning meetings with all of the interested
parties to ensure that the plans are properly reviewed, checkpoints are
established and all parties agree their responsibilities.
It is important to publicize the Release mechanism. It is also important
to publicize any constraints to end users (for example that it may not be
possible to affect an update to all PCs overnight in a large
organization).”
Distribution and Distribution, Installation and Activation can be sequenced over time or
Installation completed all at once. For example, a software patch can be distributed
to a large number of servers in advance, but only downloaded to
desktop systems at the authorized time. Or, the Telco lines can be
installed and a set of communications equipment pre-positioned but
only activated at the authorized time.
8.10.
8.10. Release Management Relationships with other Service Management Processes
Please refer to the prior section for the relationship of Release Management with Service
Desk, Incident, Problem, Configuration and Change Management
Release Management with Service Level Management
A Release can be a change in procedures or agreements and is not limited to hardware and software
deployments
Policies must be defined on how to deal with failures
Policies must be defined to describe the Service Level impact when a Release applied to one component
impacts a Service that is dependent on that component
Service Levels must be considered with each Release, especially if new hardware or software is to be
acquired
A Release may require the re-negotiation of vendor support contracts
The Change Management (and Release Management) tracking tool must support whatever tracking is
agreed to in the Service Level Agreement
Release Management with Financial Management
The release may require acquisition of resources

91
Release Management with Financial Management
5.1.6)
Release Management with Capacity Management
It is necessary to plan for the growth of the Definitive Software Library

Must insure there is sufficient space in both the build, test, distribution and live environments for the
release
Release Management needs guidance from Capacity Management both when planning how to deploy a
Release and immediately prior to executing the Release to avoid impacting the capacity of disk space,
network bandwidth, etc. (SD 6.7.4)
Capacity Management should work with Change, Configuration and Release Management to create and
implement Requests for Change to ensure that appropriate Capacity is available (2.3)
Release Management with IT Service Continuity Management
It is important that the Definitive Software Library be protected so that it can be available for recovery
Release Management with Availability Management
The Security implications must be evaluated with each Release

The integrity of the update must be ensured whether transmitted through media or over a network
The integrity of the Definitive Software Library must be maintained
The time allotted for a Change (preparation, implementation, verification) should be defined as a Service
Maintenance Objective (SD 8.5.6)
92
9. Service Level Management
9.1.
9.1. Service Level Management Synopsis
Goals Inadequate authority/seniority for SLM negotiation
Maintain and improve IT Service quality Inadequate UCs
Constant cycle of agree, monitor, report and act Unclear responsibilities
Better relationship with Customer IT bias when business does not know own needs
SLA too lengthy or verbose or unfocused
Benefits
Benefits SLAs not properly communicated
Services designed to meet SLRs Company views SLM as an overhead
Improved relationship with satisfied Customers Focus on contracts instead of relationships
Clear roles and responsibilities
Specific targets Tools
IT aligned with business Service Catalog
Clear and consistent expectations Service Level Agreements
Service monitoring to find and improve weak areas Operational Level Agreements
Service monitoring identifies training needs Underpinning Contracts
Underpins supplier management Service Level Requirements
Demonstrates value to enable Charging Accurate Configuration Items
Monitoring and reporting from CDB
Clear and accurate SLAs Activities
Regular reviews Produce Service Catalog
Monitoring to confirm compliance Plan, draft, negotiate & agree the SLA
Clear communication to Customers, Users & staff Monitor, report & review
Service Improvement Programs
Key Performance
Percent of services covered by an SLA Inputs
Inputs
Percent of SLAs backed by OLA and UC Prior informal processes & artifacts
SLAs monitored and reported regularly Input from Customer, User, IT & vendors
Review meetings with minutes Monitoring and reporting
Issues raised in reviews are worked and resolved Incidents, Problems, breaches and near misses
Percent of SLAs, OLAs and UCs needing review
Percent met and percent breached Outputs
Severity of the breaches SLM processes & artifacts
Are breaches reviewed effectively? Formal Catalog of Services
Are service levels improving? Finalized SLA, OLA and UC agreements
Are Customer perceptions improving? Negotiations, agreements and periodic reviews
Are IT costs decreasing for stable services? Reports
Requests for Change
Monitor and match perceptions before agreeing Manager’s Duties
Ensure targets are achievable Create & maintain Service Catalog
Verify targets prior to agreeing Formulate, agree, maintain, monitor, report & review on
Unrealistic SLAs SLM, SLAs, OLAs & UCs
Inadequate focus, resources and time given to SLM Negotiate & agree SLRs
93
9.2.
9.2. Service Level Management Goal Statement
Statement
The goal for SLM is to maintain and improve IT Service quality, through a constant cycle
of agreeing, monitoring and reporting upon IT Service achievements and instigation of
actions to eradicate poor service – in line with business or cost justification. Through
these methods, a better relationship between IT and its Customers can be developed.
9.3.
9.3. Service Level Management Benefits
“The improvements in service quality and the reduction in service disruption that can be
achieved through effective SLM can ultimately lead to significant financial savings. Less
time and effort is spent by IT staff in resolving fewer failures and IT Customers are able
to perform their business functions without adverse impact.
Other specific benefits from SLM include:
• IT Services are designed to meet Service Level Requirements

• Improved relationships with satisfied Customers
• Both parties to the agreement have a clearer view of roles and responsibilities –
thus avoiding potential misunderstandings or omissions
• There are specific targets to aim for and against which service quality can be
measured, monitored and reported – ‘if you aim at nothing, that is usually what
you hit’
• IT effort is focused on those areas that the business thinks are key
• IT and Customers have a clear and consistent expectation of the level of service
required (i.e. everyone understands and agrees what constitutes a ‘Priority One’
Incident, and everyone has a consistent understanding of what response and fix
times are associated with something called ‘Priority One’)
• Service monitoring allows weak areas to be identified, so that remedial action
can be taken (if there is a justifiable business case), thus improving future
service quality
• Service monitoring also shows where Customer or User actions are causing the
fault and so identify where working efficiency and/or training can be improved
• SLM underpins supplier management (and vice versa) – in cases where services
are outsourced the SLAs are a key part of managing the relationship with the
third-party in other cases service monitoring allows the performance of suppliers
(internal and external) to be evaluated and managed
• SLA can be used as a basis for charging – and helps demonstrate what value
Customers are receiving for their money.
The cumulative effect should lead to a gradual improvement in service quality and an
overall reduction in the cost of service provision.” (SD 4.2.1)
9.4.
9.4. Service Level Management Critical Success Factors
• Each Service Level Agreement must be clearly and accurately documented
94
• Regular reviews
• Established monitoring to confirm compliance
• Monitoring of the process
• Clear communication to the Customers, Users and support staff (SD 4.2.3)
9.5.
9.5. Service Level Management Key Performance Indicators
• What number or percentage of services are covered by SLAs?
• Are underpinning contracts and OLAs in place for all SLAs and for what
percentage?
• Are SLAs being monitored and are regular reports being produced?
• Are review meetings being held on time and correctly minuted?
• Is there documentary evidence that issues raised at reviews are being followed
up and resolved (e.g. via an SIP )
• Are SLAs, OLAs and underpinning contracts current and what percentage are in
need of review and update?
• What number or percentage of service targets are being met and what is the
number and severity of service breaches?
• Are service breaches being followed up effectively?
• Are service level achievements improving?
• Are Customer perception statistics improving?
• Are IT costs decreasing for services with stable (acceptable but not improving)
service level achievements?
9.6.
9.6. Service Level Management Possible Implementation Problems
• “Monitoring of pre- SLA achievements (particularly achieving the same
perception as that held by the Customers) – this is perhaps the most difficult
problem that must be addressed first, as it impacts upon the next three
• Ensuring targets are achievable before committing to them
• Verifying targets prior to agreement
• SLAs that are simply based upon desires rather than achievable targets
• Inadequate focus, resources and time – often SLM is seen as something that can
be done ‘in the margins of time’ – the ongoing resources are sometimes
overlooked
• Not enough seniority/authority given to Service Level Management to push
through negotiations/improvements
• SLAs may not be supported by adequate contracts or underpinning agreements
(see Paragraph 4.4.8)
• The responsibilities of each party are not clearly defined, creating a danger that
some things fall ‘between the cracks’ and both parties deny responsibility for
them
• Being IT based rather than business aligned, especially where the business does
not know its requirements
95
• SLAs may be too lengthy, not concise, not focused
• SLAs are not properly communicated
• For companies, SLM may be seen as an overhead rather than a Chargeable
service
• Many IT and business people seeing the SLM process primarily as an exercise in
contract arbitration, to the exclusion of one of the primary aims of the SLM
process: relationship building – as a result, the SLM process can become an
exercise in ‘relationship breaking’. “ (SD 4.2.3)
9.7.
9.7. Service Level Management Tools
• Service Catalog
• Service Level Agreements
• Operational Level Agreements
• Underpinning Contracts
• Service Level Requirements
• Accurate Configuration Items in the Configuration Management DataBase
• Monitoring and reporting from the Capacity Management DataBase
9.8.
9.8. Service Level Management Inputs and Outputs
Inputs:
• Existing informal Service Level Management process and supporting artifacts

• Existing informal Catalog of Services
• Existing SLA, OLA and UC agreements and templates
• Input from Customers, Users, support groups, Internal "vendor" groups, external
vendors and other ITIL processes
• Monitoring and reporting
• Incidents, Problems, breaches and near misses
Outputs:
• Updated Service Level Management process and supporting artifacts

• Formal Catalog of Services
• Finalized SLA, OLA and UC agreements
• Negotiations, agreements and periodic reviews
• Reports
• Requests for Change
Activities:
• Produce Service Catalog

• Plan, draft, negotiate & agree the SLA
• Monitor, report & review
• Service Improvement Programs
96
9.8.1. Service Level Management Inputs and Outputs Diagram
9.8.2. Service Level Management Inputs and Outputs Description

Existing informal Service Level Management exists in every organization. The goal is not
Service Level to create a new process, but to identify the existing processes, refine
Management and then formalize those processes.
process and
supporting artifacts
Existing informal The list of Services provided and supported often exists only in a very
Catalog of Services scattered form. It can be derived from the history of prior Incidents and
by canvassing the Users, Customers and support groups.
Existing SLA, OLA Service Level Agreements (SLA), Operational Level Agreements (OLA) and
and UC agreements Underpinning Contracts (UC) already exist. Sometimes those agreements
and templates only exist in informal conversations and assumptions. All of those
preexisting “agreements”, both formal and informal, must be
documented and used as an input into the formal process.
97
Input from The development of SLAs, OLAs and UCs is an iterative process that
Customers, Users, requires the creation of a draft, review and discussion on the draft,
support groups, revision and more iterations until the agreements can be finalized. Initial
Internal "vendor" input can come from surveys, conversations and meetings.
groups, external
vendors and other
ITIL processes
Monitoring and Availability and Capacity Management must work to implement
reporting monitoring to ensure that every metric defined in the SLA is monitored.
Periodic reports must be prepared by Availability Management to
document SLA compliance, breaches and near misses.
Incidents, Problems, Service Level Management must work with Availability and Capacity
breaches and near Management to review the history of prior Incidents, Problems, breaches
misses and near misses to identify opportunities for improvement.
Service Level The process flow through Service Level Management is documented in
Management the following diagram.
Updated Service Service Level Management must periodically review the process used to
Level Management define the SLA, OLA and UC agreements. These reviews should produce
process and updated process documents and templates for SLAs, OLAs and UCs.
supporting artifacts
Formal Catalog of ITIL defines the Service Catalog simply as a: “written statement of IT
Services services, default levels and options.” The Service Catalog is produced by
Service Level Management to document the comprehensive list of agreed
Services. The development of the catalog may go through many
iterations as the customers, users and IT surface the variety of Services
that are already in place. This activity is included at this point in the
diagram to designate the importance of capturing every new Service as it
will it is still in planning.
Finalized SLA, OLA There must be a formal point at which the SLA, OLA or UC is agreed.
and UC agreements When this step is not formalized misperceptions continue as the support
group, the user group, the customers and vendors work towards
different objectives.
Negotiations, “Using the draft agreement as a basis, negotiations must be held with
agreements and the Customer(s), or Customer representatives to finalize the contents of
periodic reviews the SLA and the initial service level targets, and with the service
providers to ensure that these are achievable.”
98
Reports SLA compliance reports should be distributed periodically, and agreed.
Distributing a report that shows full compliance when the users believe
there have been several serious breaches will undermine the process
unless the discrepancy can be mutually resolved.
“The SLA reporting mechanisms, intervals and report formats must be
defined and agreed with the Customers. The frequency and format of
Service Review Meetings must also be agreed with the Customers.
Regular intervals are recommended. Periodic reports should fit in with
the reviewing cycle.”
Requests for Change Availability and Capacity Management are expected to generate
Requests for Change (RFC) when improvements are cost justifiable.
Service Level Management may also launch a formal Service
Improvement Program (SIP) to search for improvements when there is a
trend towards breaches.
9.9.
9.9. Service Level Management
Management Process Flow
9.9.1. Service Level Management Process Flow Diagram
99
9.9.2. Service Level Management Process Flow Description
Aspect Description
Planning The key planning activities identified by ITIL are:
• “Appointment or nomination of Service Level Management and
any necessary supporting staff – Annex 4A gives a description of
the Role of a Service Level Manager
• Production of a mission statement
• Definition of the objectives and scope of the function
• An awareness campaign to win support for the function and to
advise people how and when they might be affected
• Definition of roles, tasks and responsibilities
• Quantification of activities, resources, funding, quality criteria
• Identification of risks
• Planning of a Service Catalogue and an SLA structure
• Drafting of a pilot SLA format
• Identification of support tools, particularly for SLA monitoring
• Setting and agreeing Incident priority levels and escalation paths,
with Customers, and Internal and External providers (in
conjunction with Service Desk and Problem Management)”
Implementation Implementation is an iterative process. The sequence of steps
Implement SLAs recommended by ITIL is described in the following rows of this table:
Catalog of Services, Draft, Negotiate, Review UCs and OLAs, Agree SLA.
Catalog of Services ITIL defines the Service Catalog simply as a: “written statement of IT
services, default levels and options.” The Service Catalog is produced by
Service Level Management to document the comprehensive list of agreed
Services. The development of the catalog may go through many
iterations as the customers, users and IT surface the variety of Services
that are already in place. This activity is included at this point in the
diagram to designate the importance of capturing every new Service as it
will it is still in planning.
Draft Developing a Service Level Agreement (SLA), Operational Level
Agreement (OLA) or Underpinning Contract (UC) is a complex process. It
is important to prepare an initial version and get feedback from the
appropriate groups. Does this draft meet the needs of the Customers
and the Users? Does Capacity Management agree that the metrics are
measurable and achievable? Do Availability Management and Service
Continuity Management agree that cost effective resiliency is in place?
100
Aspect Description
Negotiate “Using the draft agreement as a basis, negotiations must be held with
the Customer(s), or Customer representatives to finalize the contents of
the SLA and the initial service level targets, and with the service
providers to ensure that these are achievable.”
Review UCs and A UC is an Underpinning Contract with an external vendor. An OLA is an
OLAs Operational Level Agreement with an internal organization. Most
Services have dependencies on other organizations, internal and
external. For example, an SLA for the availability of a web portal may be
agreed between a Customer, such as the Dealers, and an organization,
such as the UNIX support group. But the availability of the UNIX server is
dependent upon the Underpinning Contract. And the availability of the
web portal is dependent upon availability of the network service
provided by the Network Operations group.
Agree SLAs There must be a formal point at which the SLA, OLA or UC is agreed.
When this step is not formalized misperceptions continue as the support
group, the user group, the customers and vendors work towards
different objectives.
Manage the ongoing Managing the ongoing process has three supporting activities that run
process concurrently: Monitor, Report and Review. The description of each is
included in the following rows of this table.
Monitor “Existing monitoring capabilities should be reviewed and upgraded as
necessary. Ideally this should be done ahead of, or in parallel with, the
drafting of SLAs, so that monitoring can be in place to assist with the
validation of proposed targets.
Nothing should be included in an SLA unless it can be effectively
monitored and measured at a commonly agreed point. The importance
of this cannot be overstressed, as inclusion of items that cannot be
effectively monitored almost always results in disputes and eventual loss
of faith in the SLM process. A lot of organizations have discovered this
the ‘hard way’ and as a consequence, have absorbed heavy costs both in
a financial sense as well as in terms of negative impacts on their
culture.”
101
Aspect Description
Report SLA compliance reports should be distributed periodically, and agreed.
Distributing a report that shows full compliance when the users believe
there have been several serious breaches will undermine the process
unless the discrepancy can be mutually resolved.
“The SLA reporting mechanisms, intervals and report formats must be
defined and agreed with the Customers. The frequency and format of
Service Review Meetings must also be agreed with the Customers.
Regular intervals are recommended. Periodic reports should fit in with
the reviewing cycle.”
Review Service Level Management is responsible for reviewing compliance and
acting to correct negative trends.
Periodic reviews Service Level Management is also responsible for periodic, formal
reviews with the Customers.
Review SLAs, OLAs Service Level Management must review each SLA, OLA and UC at least
and UCs annually. Based upon the experiences during the prior period Service
Level Management and the Customer should negotiate for changes to
the agreements and revisions to the Service.
Review SLM process Service Level Management must periodically review the process used to
define the SLA, OLA and UC agreements. These reviews should produce
updated process documents and templates for SLAs, OLAs and UCs.
Established Function The cycle of Implementation, Managing and Reviewing is an ongoing
process. New agreements are negotiated and managed. The reviews will
disclose opportunities for improvement that must then be negotiated,
managed and reviewed again.
9.10.
9.10. Service Level Management Relationships with other Service Management Processes
Please refer to the prior section for the relationship of Service Level Management with
Service Desk, Incident, Problem, Configuration, Change and Release Management
Service Level Management with Financial Management
Service Level Agreements form a foundation for Charging

Charging will help control the Customer's expectations
When Charging is not in place, senior management must assist in managing the Customer's expectations
Insure the service vendors can support the Service Level Agreements
Charging arrangements and penalties should be described in the Service Level Agreement
5.1.6)
The Manager of Financial Management may be the same person as the Manager of Service Level
Management (SD 5.1.2, 5.5.7)
102
Service Level Management with Financial Management
Current best practice for Charging is to charge a fixed amount for an agreed Capacity, determined by the
service agreed in the Service Level Agreement (SD 5.1.2)
Financial Management must work closely with Service Level Management to determine the cost of the
services as an input into the development of the Service Level Agreements and Charging structure (SD
5.1.5)
The more flexibility there is in the Service Level Agreement, the more flexibility there will be in Charging -
- but the complexity of each adds an overhead to those Processes (SD 5.1.5)
Charging can help regulate the Customers usage, but it also entitles the Customer to influence the
decisions about the Services (SD 5.1.6)
It is important to do a Workload estimate and forecast when preparing a Budget. Such estimates and
forecasts are also required for the preparation of Service Level Agreements and for Capacity Management
(SD 5.2.3, 5.5.4)
Service Level Agreements must be in place and be representative of actual service before implementing
Charging (SD 5.4.2)
To be market competitive, the infrastructure resources must be properly managed, costs well controlled
and service delivered according to expectations (SD 5.4.2)
The Customer needs forecasted pricing to help in establishing their Service Level Requirements (SD 5.4.6)
Changes to the infrastructure and Services must be processed through Change Management and may
require Changes to the Financial Management processes (Accounting and Charging) and to the Service
Level Agreements (SD 5.7.2)
Service Level Agreements must include statements about what to do if the Customers workload changes
above or below threshold levels (SD 5.7.5)
Change to Services and to Service Levels should be handled by Service Level Management and must
incorporate the impact to Financial Management (SD 5.7.8)
5.7.11)
Audits of Financial, Capacity and Service Level Management should be synchronized and conducted every
quarter initially and every six months subsequently (SD 5.7.11)
Service Level Management with Capacity Management
The Service Catalog should be the starting place for a Business Impact Analysis, Workload Analysis or
Capacity Management evaluation
Insure that every item in the Service Level Agreement can actually be monitored accurately
The Capacity Plan should identify how the service provider plans to comply with the Service Level
Agreements (SD 6.1, 6.2.3)
Service Level Agreements, Service Level Requirements, Service Level breaches and the Service Catalog are
103
Service Level Management with Capacity Management
key inputs into Capacity Planning (SD 6.2)

Recommendations on Service Level Agreements and Service Level Requirements are outputs from Capacity
planning (SD 6.2)
Capacity Management is responsible for ensuring that all metrics identified in the Service Level
Agreements are monitored, evaluated and reported, and together with Resource Capacity Planning,
identifying appropriate actions to correct any deficiencies (SD 6.2, 6.7.6)
Capacity Management is responsible for implementing Changes in order to prevent Service Level breaches
(SD 6.2)
Capacity Management is responsible for insuring that the Service Level metrics are measurable and
achievable (SD 6.2.1)
The primary focus of Service Capacity Management is on managing service performance to ensure it
achieves the targets in the Service Level Agreements and Service Level Requirements (SD 6.2.2)
Service Capacity Management informs Service Level Management of breaches or near-misses against the
Service Level Agreements (SD 6.2.2, 6.6)
Management will then refer those Incidents or Problems to Resource Capacity Management (SD 6.2.2,
6.2.3)
have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3, 6.7.6)
Resource Capacity Management should evaluate technology updates and recommend cost effective
Changes (SD 6.2.3)
The monitoring performed by Resource Capacity Management must support the metrics required by
Availability Management for Service Level Agreement verification (SD 6.3.1)
The monitoring data should be used to identify the baseline and to identify trends both to identify Service
Level Agreement breaches and near misses and also to predict future resource usage and predict business
growth patterns (SD 6.3.2)
The Capacity Management Database should house all of the metrics required to support Service Level
compliance as well as the thresholds established for the Service Level Agreements and Service Level
Requirements (SD 6.3.5, 6.5.2)
Planning for Capacity Management should include a review of the as-is and requirements from the other
Service Management areas especially Service Level, Availability and Financial Management (SD 6.5.1)
Capacity Planning should be worked in conjunction with planning for the other Service Management
processes, especially Service and Availability Management (SD 6.5.2)
Capacity Management should assist Service Level Management with Operational Level Agreements (and
Underpinning Contracts) as well as Service Level Agreements (SD 6.7.6)
Capacity Management should work with Service Level Management when there is a Service Improvement
Program to address a weak area (SD 6.7.6)
104
Service Level Management with IT Service Continuity Management
Service Continuity must work with Service Level Management to ensure there is a clear understanding of
the obligations of IT Service Delivery (SD 7.1.8)
Service Continuity, Implementation Planning must evaluate each Service Level Agreement to determine
which will remain in effect in the event of a disaster and what the business implications are for failing to
meet that SLA during the recovery (SD 7.3.3)
Service Level Management with Availability Management
Insure that every item in the Service Level Agreement can actually be monitored accurately
Service Review meetings should be held monthly, or at least quarterly to review the results and initiate a
Service Improvement Program if warranted
It is better to include Unavailability measures than Availability measures in the Service Level Agreement
Some of the most important targets set in the Service Level Agreements relate to service Availability and
thus require Incident resolution within agreed periods (2.1)
All new Service Level Requirements, Service Level Agreements, Operational Level Agreements and
Underpinning Contracts should consider Availability (SD 8.? and 8.5.3)
Low rate of failure and rapid resumption of service after an Incident are keys to consistently meeting the
Service Level Agreements on Availability
Availability Management provides guidance on the achievable Availability level to Service Level
Management for new Services and for changes (SD 8.? And 8.5.1)
Service Level Management feeds Availability Management the Service Level Agreements so that Availability
Management can implement monitoring and reporting
Regular reviews conducted by Service Level Management should also consider the current level of
Availability (SD 8.4.1)
The Service Level Management reports can describe the cost of Unavailability as number of users, number
of transactions, or preferably as the cost of the Unavailability (SD 8.4.2)
It is important that the Service Level Agreement clearly define the meaning of Availability (SD 8.5.1)
Service Level Management communicates with the business and represents Availability Management (SD
8.5.1)
Service Level Management provides input into the Availability Plan regarding future business needs (SD
8.6.3)
A Service Improvement Program is an output from Service Management and it is a project focused on IT
quality while an Availability Plan is a long term plan but it is focused on Availability (SD 8.6.3)
105
10.
10. Financial Management
Cost exceeds the benefit
10.1.
10.1. Financial Management Synopsis Monitoring inaccurate, irrelevant or too costly
Goals
Cost effective stewardship of IT resources Tools
Account fully for spend on IT Services Corporate General Ledger system
Attribute costs to appropriate Services Interface to extract data from Corporate GL
Provide detailed business cases for Changes Reports on resource usage
Ability to calculate costs & establish Cost Model
Benefits Spreadsheets for budgets & Cost Model
Increased confidence in budgeting Means to input data from other SM Processes
Accurate cost information
More efficient use of IT resources Activities
Increased IT professionalism Budgeting
Accounting
Critical Success Factors Charging
SLM assessment on Charging impact on usage Inputs
IT Services efficient & effective at reasonable cost Estimated costs and cost types
Depreciation schedules
Key Performance Indicators Service Catalog and Configuration Items
Accurate cost recovery and expenditure profiles Service Workloads
Charges applied are seen to be fair
IT organization provided with expected income Outputs
Customers & Users behavior & perceptions change Costing model
Charging rates and policies per Service
Possible Implementation Problems ROI, ROCE, TCO
Limited IT understanding can add complexity
Delayed getting information from other groups Manager’s Duties
Shared staff from outside IT with right experience Develop FM policies on Budget, Accounting & Charging
Capacity Plan and IT strategies not complete Implement & maintain FM processes
Senior management may resent this overhead Assist with financial planning for IT & Customers
Costing may restrict IT response to Users
106
10.2.
10.2. Financial Management Goal Statement
For an in-house organization, the goal should be:
• To provide cost-effective stewardship of the IT assets and resources used in

providing IT Services’.
In a commercial environment, there may be a goal statement that reflects the profit-
making and marketing aims of the organization.
The aims for any IT Services organization should include:
• To be able to account fully for the spend on IT Services and to attribute these
costs to the services delivered to the organization’s Customers
• To assist management decisions on IT investment by providing detailed business
cases for Changes to IT Services
10.3.
10.3. Financial Management Benefits
• “Increased confidence in setting and managing budgets
• Accurate cost information to support IT investment decisions
• Accurate cost information for determining cost of ownership for ongoing
services
• A more efficient use of IT resource throughout the organization
• Increased professionalism of staff within the IT organization" (SD 5.1.7)
10.4.
10.4. Financial
Financial Management Critical Success Factors
• "Senior management must fully understand the implications and costs of the
introduction of IT Accounting and Charging and fully support it
• Service Level Management must provide information on the impact on service
levels of different usage patterns that may result from Charging (and also to help
to ensure delivery of service in accordance with User expectations)
• IT Infrastructure Management should be set in place to ensure that IT Services
provided are efficient and effective, at reasonable cost" (SD 5.5.6)
10.5.
10.5. Financial Management Key Performance Indicators
• "Cost recovery profiles and expenditure profiles prove to be accurate
• Charges, where applied, are seen to be fair
• The IT organization is provided with the expected income/level of profits
• IT Customers’ and Users’ behavior and perceptions change" (SD 5.5.5)
10.6.
10.6. Financial Management Possible Implementation Problems
• "IT Accounting and Charging are often new disciplines in IT Services and there is
limited understanding of leading practice in Cost Modeling and Charging
mechanisms which could lead to over-complex or ineffective systems
107
• IT Accounting relies on planning information provided by other processes both
within and outside of IT Services Management which may not be routinely
available, delaying the project
• Staff combining accountancy and IT experience are rare, so many activities may
need to be shared with staff from outside IT Services who may not have this as
their priority
• The IS strategies and objectives of an organization may not be well formulated
and documented and prediction of Capacity requirement not accurate
• Senior business managers may not recognize the benefits of IT Accounting and
Charging and may resent the administrative overheads and the limitations on
workload
• The IT organization may not be able to respond to Changes in Users’ demands
once costs become an influence
• The IT Accounting and Charging processes are so elaborate that the cost of the
system exceeds the value of the information produced
• The monitoring tools providing resource usage information are inaccurate,
irrelevant or cost too much to develop and maintain" (SD 5.1.9)
10.7.
10.7. Financial Management Tools
• Corporate General Ledger (GL) system
• A means of extracting the required data from the GL system
• Reports on resource usage
• Ability to calculate costs based upon the established Cost Model
• Spreadsheets or customized tools for developing budgets and Cost Models
• A means of inputting data from the other Service Management processes
10.8.
10.8. Financial Management
Management Inputs and Outputs
Inputs:
• Estimated costs and cost types

• Depreciation schedules
• Service Catalog and Configuration Items
• Service Workloads
Outputs:
• Costing model
• Charging rates and policies per Service
• Return on Investment, Return on Capital Employed, Total Cost of Ownership
Activities:
• Budgeting
• Accounting
• Charging
108
10.8.1. Financial Management Inputs and Outputs Diagram
10.8.2. Financial Management Inputs and Outputs Description

Hardware All IS expenditures for hardware including servers, network devices, the
cabling and the infrastructure required to support this hardware.
Software All IS expenditures for software including purchases, development and
maintenance.
Employment All IS expenditures for the workers within the organization. For an
accurate representation, this should be the burdened cost including
benefits.
Accommodation All IS expenditures for facilities and utilities including the floor space for
the systems and the workers.
External Service “It is now common to buy in services from external parties (external
services) that are a mixture of cost types, for example an outsourced
service for providing an organization’s application development or the
provision of a data center. It may be difficult to break down this cost
(into each of the first four categories), as it is likely to contain elements
that are indivisible or that the supplier will not wish to detail. It is easier
and more usual to categorize this as an External Service Cost.”
109
Transfer “Transfer costs are those that represent goods and services that are sold
from one part of an organization to another (often within a multi-
national or other large organization that has a sophisticated internal
accounting system). Transfer costs may be for:
• Hardware (an IT organization buying PCs on behalf of a business
Customer)
• Software (the corporate Finance Department producing control
mechanisms for IT to manage their costs)
• People (the HR overhead levied by the corporate HR department)
• Accommodation (a charge made by the Facilities Management
department)”
Cost Elements All of the details regarding the costs of Hardware, Software,
Employment, Accommodation, External Service and Transfer Costs are
cost elements. The Cost Elements are then analyzed and categorized
into Capital costs and Operational costs.
Direct Costs “Direct Costs are those clearly attributable to a single Customer.”
Indirect Costs “Indirect Costs (sometimes called overheads) are those incurred on
absorbed by each behalf of all, or a number of, Customers which have to be apportioned
service to all, or a number of, Customers in a fair manner.”
Unabsorbed Indirect “Any Indirect Costs, which cannot be apportioned to a set of Customers
Costs (sometimes called Unabsorbed Overheads), have then to be recovered
from all Customers in as fair away as is possible, usually by uplifting the
costs calculated so far by a set amount.”
Costs-by-service The purpose for this accounting process is to arrive at the cost for each
Service delivered by IS.
Total Cost of all IT The total of the costs attributable to each Customer should equal the
services Total Costs incurred by the IS organization. ITIL describes the process of
verifying that the total attributed costs match the total incurred costs as
the “Balance Check”. ITIL notes “This ‘balance check’ can be applied to
costs divided in other ways e.g. by service or by location; always, the
sum of the parts should equal the whole.”
Service A These boxes are placeholders for all of the different Services offered by
Service B this IS organization.
Service C
Service D
110
10.9.
10.9. Financial Management Process Flow
10.9.1. Financial Management Process Flow Diagram
10.9.2. Financial Management Process Flow Description

Aspect Description
Business IT The process of Financial Management should be based upon an annual
requirements budget including the current and forecasted needs of the Business for IS
services.
IT operational plan Budgeting enables an organization to:
(including Budgets) • Predict the money required to run IT Services for a given period
• Ensure that actual spend can be compared with predicted spend
at any point
• Reduce the risk of overspending
• Ensure that revenues are available to cover predicted spend
(where Charging is in place)
Cost Analysis IT Accounting enables an organization to:
(Accounting) • Account for the money spent in providing IT Services
• Calculate the cost of providing IT Services to both internal and
external Customers
• Perform cost-benefit or Return-on-Investment analyses
• Identify the cost of Changes
Charges Charging enables an organization to:
• Recover the costs of the IT Services from the Customers of the
service
• Operate the IT organization as a business unit if required
• Influence User and Customer behavior (note the discussion in
Paragraph 5.4.2)
Financial targets The agreed goals for this period.
111
Aspect Description
Costing models “To calculate the costs of IT Service provision, it is necessary to design a
framework in which all known costs can be recorded and allocated to
specific Customers, activities or other category. This is called a Cost
Model. Most Cost Models are based on calculating the cost for each
Customer but other models can be developed to show the cost for each
service or the costs for each location.”
Charging policies The Charging Policies are a set of defined and agreed processes for
assessing the Charges for Services.
Feedback of Periodic review should be conducted in conjunction with Service Level
proposed changes to and Capacity Management to ensure that the required services are
business delivered with cost-effective utilization of the capacity. The total amount
Charged must also be reconciled with the total IS expenditure.
10.10.
10.10. Financial Management Relationships with other Service Management Processes
Please refer to the prior section for the relationship of Financial Management with
Service Desk, Incident, Problem, Configuration, Change, Release and Service Level
Management
Financial Management with Capacity Management
5.1.6)
IT Accounting can be used to determine the exact costs of resource usage down to CPU, file store and
bandwidth but it is rarely advisable to use this as the basis for Charging as the costs of so doing may
outweigh the benefits (SD 5.1.2)
Current best practice for Charging is to charge a fixed amount for an agreed Capacity, determined by the
service agreed in the Service Level Agreement (SD 5.1.2)
It is important to do a Workload estimate and forecast when preparing a Budget. Such estimates and
forecasts are also required for the preparation of Service Level Agreements and for Capacity Management
(SD 5.2.3, 5.3.11, 5.3.14, 5.5.4)
It is best to calculate the Standard Rates and leave them in place for a year, or until the discrepancy
exceeds some threshold, and absorb Changes during the year (SD 5.3.11)
Charging can be used to assist with Demand Management (SD 5.4.2)
To be market competitive, the infrastructure resources must be properly managed, costs well controlled
and service delivered according to expectations (SD 5.4.2)
Senior manager must be prepared to specify what they require from the systems and how these systems
should interface with other systems in the organization (e.g. Capacity Management) (SD 5.5.6)
112
Financial Management with Capacity Management

Service Level Agreements must include statements about what to do if the Customers workload changes
above or below threshold levels (SD 5.7.5)
5.7.11)
Audits of Financial, Capacity and Service Level Management should be synchronized and conducted every
quarter initially and every six months subsequently (SD 5.7.11)
Capacity Management should work with Financial Management to assist in influencing future demand (SD
6.1)
Capacity Management should work with Financial Management to aggregate the corporate need into
purchasing leverage, improve long range planning and phase the purchasing (SD 6.1.1)
Costing and Charging recommendations are key outputs from Capacity Planning (SD 6.2)
Business Capacity Planning is responsible for forecasting future business needs (SD 6.2)
Capacity Management is responsible for implementing Changes in order to prevent Service Level breaches
(SD 6.2)
Capacity Planning requires financial data to accurately plan the cost of proposed upgrades (SD 6.3.5)
Demand Management can use Charging to influence usage patterns (e.g., time of day) or curtain excessive
usage, but this must be managed carefully to avoid antagonizing the users (SD 6.3.6, 6.6, 6.7.7)
Proper Capacity Planning will help preclude unwarranted expenditures and assist in deferring required
purchases until shortly before they are needed (SD 6.4.2)
Capacity Management monitoring must itself be cost justifiable (SD 6.4.3)
Financial data, such as the cost of devices, should be extracted into the Capacity Management Database to
support modeling and planning (SD 6.5.2)
Changes recommended by Capacity Management must be cost justifiable (SD 6.7.7)
Financial Management with IT Service Continuity Management
5.1.6)
IT Accounting must be planned for in the Service Continuity Plan. Either IT Accounting can be dropped
during the recovery period, or IT Accounting must be tested as part of the Disaster Recovery testing (SD
5.6.5)
Individual contingency plans for aspects of the infrastructure need to be unified and focused on the critical
business functions to ensure that the available budget is applied in the most appropriate way (SD 7.3.1)
The recovery options chosen must balance the potential impact against the cost of the recovery (SD 7.3.2)
The balance between expenditures on resiliency and those on a comprehensive fail over strategy depends
upon how much impact can be caused by a short term disruption (SD 7.3.2)
The benefits and costs of each recovery option must be evaluated (SD 7.3.2)
Insurance is important to Service Continuity (SD 7.3.2)
113
Financial Management with Availability Management
Management
5.1.6)
Availability Management gives Financial Management data on the cost of Unavailability
Financial Management provides Availability Management with the costs for propose upgrades (SD ? And
8.6.3)
Higher Availability requirements will cost more and must be cost justifiable (SD 8.4.1, 8.6.1)
Planning for Availability early in the design will avoid the expense of making Changes later in the project
(SD 8.4.1)
Financial Management can use profit/cost models to assist in quantifying the cost of Unavailability (SD
8.7.7)
114
11.
11. Capacity Management
Analysis
11.1.
11.1. Capacity Management Synopsis Tuning
Goals Implementation
Ensure cost justifiable IT Capacity always exists Storage of Capacity Management data
Match Capacity to current & future Business needs Demand management
Modeling
Benefits Application sizing
Increased efficiency and cost savings Production of the capacity plan
Reduced risk
More confident forecasts Inputs
Add value to applications lifecycle Technology
SLAs, SLRs and Service Catalog
Critical Success Factors Business plans and strategy
Accurate business forecasts IS/IT plans and strategy
Knowledge & accuracy of IT plans & strategy Business requirements and volumes
Understanding current & future technologies Operational schedules
Ability to demonstrate cost-effectiveness Deployment and development plans and programs
Interaction with other effective SM Processes Forward Schedule of Change
Ability to plan & implement to match business Incidents and Problems
Service reviews
Key Performance Indicators SLA breaches
Timely & accurate resource forecasts in Cap Plan Financial plans
Ability to monitor all Services and components Budgets
New technology implemented in line with business
Old technology does not cause SLA breaches Outputs
Capacity cost-effective to met business needs Capacity Plan
Capacity planned accurately CDB
Planning & implementation reduces Incidents Baselines and profiles
Reduce lost business from inadequate Capacity Thresholds and alarms
New Services implemented to match the SLR Capacity reports (regular, ad hoc and exception)
Recommendations are acted upon SLA and SLR recommendations
Costing and charging recommendations
Possible
Possible Implementation Problems Proactive changes and service improvements
Over committed expectations Revised operational schedule
Vendor influence Effectiveness reviews
Lack of information Audit reports
Complexity in a distributed environment
Complexity to design & implement monitoring Manager’s Duties
Ensure appropriate monitoring data into CDB
Tools Product Capacity Plan
Monitoring tools Evaluate increase/decrease based on SLRs
Capacity management DataBase Management information with trends & forecasts
Capacity Plan Size HW for utilization, Service Level & cost
Linkages to the CMDB Assess and test new technology
Trend modeling tools Report performance against SLAs
Forecasting tools Plan for future demands
Tuning tools Tuning and Changes for optimization
Recommend Resolutions to performance Problems
Activities Recommendations for Demand Management
Monitoring
115
11.2.
11.2. Capacity Management Goal Statement
The Capacity Management process’s goal is "to ensure that cost justifiable IT Capacity
always exists and that it is matched to the current and future identified needs of the
business."
11.3.
11.3. Capacity Management Benefits
• Increased efficiency and cost savings
• Reduced risk
• More confident forecasts
• Value to applications lifecycle
11.4.
11.4. Capacity Management Critical Success Factors
• "Accurate business forecasts
• Knowledge of IT strategy and plans, and that the plans are accurate
• An understanding of current and future technologies
• An ability to demonstrate cost-effectiveness
• Interaction with other effective Service Management processes
• An ability to plan and implement the appropriate IT Capacity to match business
need" (SD 6.6)
11.5.
11.5. Capacity Management Key Performance
• "Resource forecasts
• Timely production of forecasts of resource requirements
• Accurate forecasts of trends in resource utilization
• Incorporation of business plans into Capacity Plan
• Technology
• Ability to monitor performance and throughput of all services and
components, as appropriate
• Implementation of new technology in line with business requirements
(time, cost and functionality)
• The use of old technology does not result in breached SLAs due to
problems with support or performance
• Cost-effectiveness
• A reduction in panic buying
• No significant over-Capacity that can’t be justified in business terms
• Accurate forecasts of planned expenditure
• Plan and implement the appropriate IT Capacity to match business need
• Reduction in Incidents due to poor performance
• Reduction in lost business due to inadequate Capacity
• New services are implemented which match SLRs
• Recommendations made by Capacity Management are acted upon"
(SD 6.6)
116
11.6.
11.6. Capacity Management Possible Implementation Problems
• Over expectation
• Vendor influence
• Lack of information
• Complexity of the effort in a distributed environment
• Complexity in designing and implementing the monitoring
11.7.
11.7. Capacity Management Tools
• Monitoring tools
• Capacity Management DataBase
• Capacity Plan
• Linkages to the Configuration Management DataBase
• Trend modeling tools
• Forecasting tools
• Tuning tools
11.8.
11.8. Capacity Management Inputs and Outputs
Inputs:
• Technology
• SLAs, SLRs and Service Catalog
• Business plans and strategy
• IS/IT plans and strategy
• Business requirements and volumes
• Operational schedules
• Deployment and development plans and programs
• Forward Schedule of Change
• Incidents and Problems
• Service reviews
• SLA breaches
• Financial plans
• Budgets
Outputs:
• Capacity Plan
• CDB
• Baselines and profiles
• Thresholds and alarms
• Capacity reports (regular, ad hoc and exception)
• SLA and SLR recommendations
• Costing and charging recommendations
• Proactive changes and service improvements
• Revised operational schedule
• Effectiveness reviews
117
• Audit reports
Activities
• Monitoring
• Analysis
• Tuning
• Implementation
• Storage of Capacity Management data
• Demand management
• Modeling
• Application sizing
• Production of the capacity plan
11.8.1. Capacity Management Inputs and Outputs Diagram
11.8.2. Capacity Management Inputs and Outputs Description

Technology Technology impacts Capacity Management in two ways. First, technology
improvements allow Capacity Management to upgrade to bigger capacity
faster resources and thus prevent or resolve Capacity Problems. At the
same time, technology opportunities motivate the desire for new
services and new features that have the potential to negatively impact
Capacity. Capacity Management must continually evaluate technology
improvement opportunities. Capacity Management must also validate
that every Request for Change properly addresses Capacity concerns.
118
SLAs, SLRs and Service Level Agreements and Service Level Requirements define the
Service Catalog agreed service that is contractually required. Capacity Management must
review each proposed agreement to insure that the defined metrics can
be monitored and can be achieved cost effectively. The Service Catalog
then defines the agreed schedule of available services.
Business plans and Capacity Management is required to evaluate the business plans and
strategy strategy to determine the Capacity forecast.
IS/IT plans and The IS/IT department often defines strategic objectives such as
strategy migration to a new architecture, new facility, or the introduction of a
new technology. Capacity Management is responsible for assessing
those plans and deriving a Capacity forecast.
Business These inputs define the current needs of the business. Capacity
requirements and Management is responsible for implementing monitoring to record the
volumes current usage and derive trendlines to predict future growth.
Operational Operational schedules are important both for verification of Service
schedules Level Agreements and for demand balancing. The Operational Schedule
should include the hours that a service is provided as well as the hours
agreed for planned maintenance. Demand balancing uses the
operational schedule when seeking opportunities to migrate activities to
off-peak time slots.
Deployment and The development plans, like the business and IT plans must be
development plans examined to forecast the future Capacity requirements.
and programs
Forward Schedule of The Forward Schedule of Changes lists all of the planned changes, the
Change services that will be impacted and the agreed time allocated for the
planned maintenance. Capacity Management is responsible for
evaluating each Request for Change to verify sufficient Capacity is
available or to recommend modifications to the RFC that will preempt
the forecasted Capacity Problem.
Incidents and Incidents and Problems feed into the Capacity Management process
Problems when escalated to Capacity Management for investigation. Additionally,
both Incident and Problem Management will use the Capacity
Management Database when analyzing Incidents and Problems.
Service reviews Service Level Management must perform periodic reviews of the Service
Level Agreements, Operational Level Agreements and Underpinning
Contracts. These reviews require the assistance of Capacity Management
to assess compliance, near misses and breaches.
119
SLA breaches Service Level Agreement breaches are an input into Capacity
Management because each must be recorded and evaluated. Based upon
that evaluation, Capacity Management is responsible for defining
appropriate improvements to the infrastructure.
Financial plans Financial plans are an input into Capacity Management because those
plans will include future infrastructure changes proposed by other
departments in the company.
Budgets Budgets constrain the scope of improvements that Capacity
Management can justify in annual the Capacity Plan.
Business Capacity “This sub-process is responsible for ensuring that the future business
Management requirements for IT Services are considered, planned and implemented
in a timely fashion. This can be achieved by using the existing data on
the current resource utilization by the various services to trend, forecast
or model the future requirements. These future requirements come from
business plans outlining new services, improvements and growth in
existing services, development plans etc.”
Service Capacity “The focus of this sub-process is the management of the performance
Management of the live, operational IT Services used by the Customers. It is
responsible for ensuring that the performance of all services, as detailed
in the targets in the SLAs and SLRs, is monitored and measured, and
that the collected data is recorded, analyzed and reported. As necessary,
action is taken to ensure that the performance of the services meets the
business requirements. This is performed by staff with knowledge of all
the areas of technology used in the delivery of end-to-end service, and
often involves seeking advice from the specialists involved in Resource
Capacity Management.”
Resource Capacity “The focus in this sub-process is the management of the individual
Management components of the IT Infrastructure. It is responsible for ensuring that
all components within the IT Infrastructure that have finite resource are
monitored and measured, and that the collected data is recorded,
analyzed and reported. As necessary, action must be taken to manage
the available resource to ensure that the IT Services that it supports
meet the business requirements. In carrying out this work, the Capacity
Management process is assisted by individuals with specialist knowledge
in the particular areas of technology.”
Capacity plan The Capacity Plan is the annual forecast of expenditures required to
maintain the infrastructure Capacity. It must account for the
expenditures required to meet planned business and IT growth.
120
CDB The Capacity Management Database is linked to the Configuration
Management Database to support all of the Service Management
processes. The monitoring metrics and thresholds used to evaluate
Service Level Agreements are stored in the CDB to support SLA
compliance reviews. Costing data is stored here to support the creation
of the Capacity Plan. Incident Management and Problem Management
use the CDB to review performance and capacity metrics while
investigating Incidents and Problems. Capacity Management uses those
same metrics for performance modeling when assessing Requests for
Change and while planning future expenditures.
Baselines and After monitoring metrics have been accumulated in the CDB for a period
profiles of weeks, it is possible to assess a “normal” pattern of resource and
capacity utilization. Those “normal” values then become the baseline for
evaluating Requests for Change and business growth.
Thresholds and Capacity Management should be proactive to the greatest extent
alarms possible. Thresholds are defined both to check compliance with Service
Level Agreements and to activate preemptive alarms. Capacity
Management should feed automated Incidents to the Service Desk to
warn of an impending Capacity Problem. For example, an alarm set to
trigger at 90% of capacity can reach the Service Desk before the
remaining capacity is consumed. And that will allow the Service Desk to
take proactive steps to prevent a disruption in Service.
Capacity reports Capacity reports are used by Capacity Management in planning, by
(regular, ad hoc and Incident, Problem and Capacity Management in researching Incidents
exception) and Problems, and by Availability, Capacity and Service Level
Management when researching Service Level Agreement compliance and
breaches.
SLA and SLR Capacity Management is responsible for evaluating services and
recommendations assessing the achievable service levels. Capacity Management should
make recommendations both on the measurability of each metric
defined in the proposal and on the probability of complying
successfully.
Costing and Capacity Management is responsible for assessing the cost of
charging enhancements and for assessing the cost of services delivered. Charging
recommendations can be used both to recoup those costs and as a way of influencing
demand.
Proactive changes Capacity Management is responsible both for recommending Changes to
and service address recurring Problems and for anticipating growth and making
improvements recommendations to Change before the growth leads to Problems.
121
Revised operational Capacity Management can offer guidance on arranging the schedule for
schedules batch jobs, backups and other recurring tasks to minimize the number
of Capacity Problems. For example, staggering the backup cycle to
spread the network load over a broader period of time can result in
fewer failed jobs and better overall performance.
Effectiveness reviews The Capacity Management process should be reviewed for effectiveness
and efficiency at regular intervals to ensure that:
• It is producing the required output at the required times for the
appropriate audience
• Its activities are cost effective
Audit reports Periodic audits must be performed to insure that the metrics gathered
into the Capacity Management Database are neither excessive nor so
sparse as to be of insufficient value.
11.9.
11.9. Capacity Management Process Flow
Capacity Management does not have a simple sequential process flow. The activities in
Capacity Management are illustrated in the figure immediately below. Those activities
are iterative, i.e. cyclical. Additionally, Capacity Management has several on-demand
activities that occur sporadically. Those activities are illustrated in the subsequent
diagram.
11.9.1. Capacity Management Process Flow Diagram for Iterative Activities
122
11.9.2. Capacity Management Process Flow Description for Iterative Activities
Aspect Description
Implementation An assessment should be undertaken to ensure that resources that
service vital business functions and all services covered by Service Level
Agreements are monitored. Where there are existing gaps in monitoring
and whenever a Change is made each component should be evaluated
and monitored in a cost effective manner. All implementations must be
managed through the Change Management process.
Monitoring Monitoring should be implemented through a Request for Change and
then remain active until a future Request for Change authorizes
retirement.
Analysis Analysis should occur proactively to investigate trends and anticipate
Problems. Analysis is also triggered reactively when a Problem is
escalated to the Capacity Management group.
Tuning Resource optimization will occur when an Analysis reveals a weakness.
Tuning efforts must be coordinated with Availability and IT Service
Continuity Management to ensure there is no adverse impact. All Tuning
efforts must be evaluated against the criteria set for the Change
Management process.
Resource utilization Resource utilization thresholds are proactive thresholds. The intent is to
thresholds monitor the capacity or resource utilization and automatically generate
an Incident when the monitoring threshold is breached. These
thresholds should be set low enough that the Service Desk can process
the Incident and take action to prevent the Incident from impacting the
Service provided to the users. Care must also be taken to set the
thresholds high enough to avoid generating an excessive number of
Incidents, where most of those Incidents would have self-corrected.
SLM thresholds Service Level Management thresholds are reactive thresholds. Once the
Service Level has been breached, it is imperative that the Service Desk
act quickly to minimize the disruption to the Service.
Capacity The Capacity Management Database is linked to the Configuration
Management Management Database to support all of the Service Management
Database processes. The monitoring metrics and thresholds used to evaluate
123
Aspect Description
SLM exception Service Level breaches must be monitored and reported.
reports
Resource utilization Resource utilization exceptions must be monitored and evaluated. Cost
exception reports effective action should be planned to prevent recurrence.
11.9.3. Capacity Management Process Flow Diagram for On-Demand Activities
11.9.4. Capacity Management Process Flow Description for On-Demand Activities

Aspect Description
Business Capacity “This sub-process is responsible for ensuring that the future business
Management requirements for IT Services are considered, planned and implemented
in a timely fashion. This can be achieved by using the existing data on
the current resource utilization by the various services to trend, forecast
or model the future requirements. These future requirements come from
business plans outlining new services, improvements and growth in
existing services, development plans etc.”
Service Capacity “The focus of this sub-process is the management of the performance
Management of the live, operational IT Services used by the Customers. It is
responsible for ensuring that the performance of all services, as detailed
in the targets in the SLAs and SLRs, is monitored and measured, and
that the collected data is recorded, analyzed and reported. As necessary,
action is taken to ensure that the performance of the services meets the
business requirements. This is performed by staff with knowledge of all
the areas of technology used in the delivery of end-to-end service, and
often involves seeking advice from the specialists involved in Resource
Capacity Management.”
124
Aspect Description
Resource Capacity “The focus in this sub-process is the management of the individual
Management components of the IT Infrastructure. It is responsible for ensuring that
all components within the IT Infrastructure that have finite resource are
monitored and measured, and that the collected data is recorded,
analyzed and reported. As necessary, action must be taken to manage
the available resource to ensure that the IT Services that it supports
meet the business requirements. In carrying out this work, the Capacity
Management process is assisted by individuals with specialist knowledge
in the particular areas of technology.”
Iterative activities The iterative activities were described in the previous section of this
document.
Demand According to ITIL “the primary objective of Demand Management is to
Management influence the demand for computing resource and the use of that
resource.” Demand Management encompasses all activities that seek to
level the resource utilization to minimize the peak usage.
Modeling Modeling is any activity that attempts to predict the behavior of the
resources that will result from a defined workload.
Application Sizing ITIL states that “the primary objective of application sizing is to estimate
the resource requirements to support a proposed application Change or
new application, to ensure that it meets its required service levels.”
Storage of Capacity The Capacity Management Database (CDB) “…is the cornerstone of a
Management Data successful Capacity Management process.” Capacity Management is
responsible for the configuration, administration and maintenance of
the CDB and of the monitoring utilities required to gather resource and
capacity metrics.
Production of the The Capacity Plan describes the activities that Capacity Management
Capacity Plan proposes to undertake in order to maintain the required level of service
during the next twelve months. This plan should include a complete
description of proposed Changes and the cost justification for each.
CDB The Capacity Management Database is linked to the Configuration
Management Database to support all of the Service Management
processes. The monitoring metrics and thresholds used to evaluate
125
11.10.
11.10. Capacity Management Relationships with other Service Management Processes
Please refer to the prior section for the relationship of Capacity Management with
Service Desk, Incident, Problem, Configuration, Change, Release, Service Level and
Financial Management.
Capacity Management with IT Service

Service Continuity Management
Capacity Management should work with Service Continuity to assess the capacity requirements for the Vital
Business Functions (SD 6.1.1, 6.7.8)
The Service Continuity aspects of Changes to Capacity must be assessed by Capacity Management so that
IT Service Continuity Management can evaluate updates to the continuity planning (SD 6.7.8)
Service Continuity must work with Capacity Management to ensure that business requirements are fully
supported through appropriate IT hardware resources (SD 7.1.8)
Capacity Management with Availability Management
Resource Capacity Management works with Availability Management to assess and improve the resiliency
of the infrastructure (SD 6.2.3)
The monitoring performed by Resource Capacity Management must support the metrics required by
Availability Management for Service Level Agreement verification (SD 6.3.1)
The monitoring data should be used to identify the baseline and to identify trends both to identify Service
Level Agreement breaches and near misses and also to predict future resource usage and predict business
growth patterns (SD 6.3.2)
The Capacity Management Database should house all of the metrics required to support Service Level
compliance as well as the thresholds established for the Service Level Agreements and Service Level
Requirements (SD 6.3.5)
Capacity Management is responsible for "application sizing" to estimate the resources required for a new
application and works with Application Management to plan for resiliency (SD 6.3.8)
Capacity Planning should be worked in conjunction with planning for the other Service Management
processes, especially Service and Availability Management (SD 6.5.2)
Slow performance and capacity Problems can result in Unavailability of the Service to the users (SD 6.7.9)
Resiliency improvements must be assessed for their impact on Capacity, while Capacity improvements
must be assessed for their impact on Availability (SD 6.7.9)
Configuration and monitoring data on each component is used in Availability planning
Availability Management should complete a Component Failure Impact Assessment to help Capacity
Management plan resiliency for new Services or components
Capacity Management should give Availability Management the details regarding how resiliency will be
achieved
Capacity Management provides input into the Availability Plan regarding scenarios for changing the
infrastructure
The Availability Plan and Capacity Plan are complementary and should be aligned with the budget cycle (SD
8.6.3)
Capacity Management may provide reports such as Response Time analysis to augment the Availability
metrics and highlight Capacity issues (SD 8.7.6)
126
Capacity Management with Availability Management
The Capacity Management Database serves Availability Management by housing performance data and by
providing input into planning (SD 8.8.2)
127
12.
12. IT Service Continuity Management
12.1.
12.1. IT Service Continuity Synopsis Activities
Activities
Goals Initiation
Support overall Business Continuity Management Requirements
Ensure IT resources can be recovered within required Implementation
and agreed business timescales Operational Management
Benefits Inputs
Strive for lower insurance premiums SLAs and UCs
Comply with regulatory requirements IRs, PRs, RFCs, resolutions and history
Improve relationship with Business CIs and their relationships
Marketing of ITSCM to clients and Customers
IT credibility with shareholders and clients Outputs
Competitive advantage Updated SLAs, UCs and Standby Agreements
Revised RFCs
Critical Success
Success Factors RFCs to improve ITSCM & Availability
Management commitment Identified Critical Business Functions
Allocation of resources for plan & test
Commitment from IT Manager’s Duties
Integration with Business Continuity Plan Develop & manage the ITSCM Plan
Ensure recovery can be achieved
Key Performance Indicators Ensure all IT Services prepared and able
Identification of Critical Business Functions Testing, reviews and communication
Defined strategy for recovery of CBF Negotiate & manage contracts
Number trained Manage IT Service during crises
Number of successful tests
Other Roles
Possible Implementation Problems BCM Steering Committee
Management commitment BCM Manager
Insufficient resources
Failure to test
Tools
Business Impact Analysis
ITSCM Plan
Spreadsheets or tools for risk assessments
Scripts for testing & simulations
128
12.2.
12.2. IT Service Continuity Management Goal Statement
The goal for ITSCM is to support the overall Business Continuity Management process by
ensuring that the required IT technical and services facilities (including computer
systems, networks, applications, telecommunications, technical support and Service
Desk) can be recovered within required, and agreed, business timescales.
12.3.
12.3. IT Service Continuity Management Benefits
ITSCM supports the corporate Business Continuity Management process to:
• Strive for lower insurance premiums

• Comply with regulatory requirements
• Improve the relationship between IT and the Business
• Provide for the positive marketing of ITSCM to clients and Customers
• Organizational credibility in protecting the interests of shareholders and clients
• Competitive advantage
12.4.
12.4. IT Service Continuity Management Critical Success Factors
• Allocation of resources for plan & test
• Commitment from IT
• Integration with Business Continuity Plan
12.5.
12.5. IT Service Continuity Management Key Performance Indicators
• Identification of Critical Business Functions
• Defined strategy for recovery of CBF
• Number trained
• Number of successful tests
12.6.
12.6. IT Service Continuity Management Possible Implementation Problems
• Insufficient resources
• Failure to test
12.7.
12.7. IT Service Continuity Management Tools
• Business Impact Analysis
• ITSCM Plan
• Spreadsheets or tools for risk assessments
• Scripts for testing and simulations
12.8.
12.8. IT Service Continuity Management Inputs and Outputs
Inputs:
• Service Level Agreements and Underpinning Contracts
129
• Requests for Change, Problem resolutions, Availability and Capacity
improvements and the prior history of Incidents and Problems
• Configuration Items and the relationships between them
Outputs:
• Updated Service Level Agreements and Underpinning Contracts and Standby

Agreements
• Revised Requests for Change, Availability and Capacity improvements. Also new
Requests for Change to improve ITSCM and Availability
• Identification of the critical business functions and the components required to
provide those services
• IT Service Continuity Plan components integrated into the Business Continuity
Plan
Activities:
• Initiation
• Requirements
• Implementation
• Operational Management
12.8.1. IT Service Continuity Management Inputs and Outputs Diagram
130
12.8.2. IT Service Continuity Management Inputs and Outputs Description
Service Level The agreements between IT and the customers and service providers
Agreements and define the expectations for service delivery. These agreements must be
Underpinning reviewed to assess the implications should a disaster or significant
Contracts disruption occur.
Requests for Each Change to the infrastructure has the potential to alter the
Change, Problem requirements for Service Continuity. For example, if the primary dealer
resolutions, interface is migrated to a new platform, it is important that the fail over
Availability and platform be sufficiently compatible that it can still run the applications
Capacity required to provide the critical business functions.
improvements and The prior history of Incidents and Problems must also be assessed for
the prior history of the information they reveal about the weaknesses in the current
Incidents and infrastructure.
Problems
Configuration Items IT Service Continuity Management is responsible for prioritizing a
and the relationships recovery to restore the critical business functions first. The
between them Configuration Management Database should contain the relationships
that are required to ensure that the restored functions are capable of
delivering the required service to the users. For example, restoring the
database and web servers will not guarantee service to the users unless
all of the appropriate network components are also restored.
IT Service Continuity The activities within ITSCM are identified in the subsequent Process
Management Flow.
Updated Service ITSCM is expected to make recommendations to Service Level and
Level Agreements Financial Management to ensure that the Service Level Agreements and
and Underpinning Underpinning Contracts deal fairly with a significant service disruption.
Contracts and Additionally, ITSCM should define the requirements for standby service
Standby Agreements agreements including alternate sites, systems and components and
arrangements for staffing.
Revised Requests for ITSCM does not typically review every RFC as it occurs. Availability
Change, Availability Management or Security Management may represent the interests of
and Capacity Service Continuity on the Change Advisory Board to provide that
improvements. Also oversight. But, ITSCM is required to perform periodic reviews to assess
new Requests for the cumulative change and then update the Continuity Plans
Change to improve accordingly. Those reviews must occur at least annually.
ITSCM and
Availability
131
Identification of the Availability and Service Continuity are costly services. It is important to
critical business assess the benefits and costs of each alternative. The primary focus
functions and the needs to be on those services that are critical to the business and give
components other services secondary importance. The relationships in the
required to provide Configuration Management Database are vital to this activity as those
those services relationships highlight all of the auxiliary components that must be
planed for in order to restore the critical business functions.
IT Service Continuity The efforts of ITSCM must be documented in the IT Continuity Plan. That
Plan components plan must then be incorporated into the larger effort to provide overall
integrated into the Business Continuity. For example, the IT Continuity Plan may define how
Business Continuity to quickly procure hardware and temporary services if a fire damages a
Plan parts depot. But it is Business Continuity and not ITSCM that is
responsible for replenishing the inventory and defining temporary
alternative shipping points.
12.9.
12.9. IT Service Continuity Management Process Flow
12.9.1. IT Service Continuity Management Process Flow Diagram
132
12.9.2. IT Service Continuity Management Process Flow Description
Aspect Description
Initiate BCM The Initiation Phase includes:
• Policy setting
• Specify terms of reference and scope
• Allocate resources
• Define the project organization and control structure
• Agree project and quality plans
Business Impact The purpose for a Business Impact Analysis is to assess how much the
Analysis business stands to lose and how quickly those losses will escalate in the
event of a service disruption. The analysis begins by identifying:
• Critical business processes
• The potential damage or loss that may result
Additionally the analysis must assess:
• The nature of the loss, i.e. loss of income, reputation, etc.
• How the loss is likely to escalate after a disruption
• The resources required to support the essential services
• The time required to recover to the critical services
• The time required to fully recover all services
The resulting business recovery objectives should define:
• The time for the minimal services to be restored
• The schedule for implementing a full recovery
Risk Assessment Risk assessment is a well defined topic in many areas of business. ITIL
recommends using a technique known as CRAMM. The key steps in the
ITIL Risk Assessment process are:
• Identify the potential risks
• Assign a probability to each risk
• Assign a level (impact) ranking to each risk
This assessment can be made qualitatively, using rankings such as
“low”, “medium” and “high” or quantitatively using numeric assessments.
The next step in the assessment is to identify possible countermeasures
(avoidance) and risk reduction techniques (mitigation).
133
Aspect Description
Business Continuity Following Risk Assessment, the next step is to define a Business
Strategy Continuity Strategy. Note that this strategy must be flexible and adapt to
the business cycles. For example, order placement during a sales
promotion may be the highest priority, while one month later parts
inventory may take precedence.
The strategy must also identify a balance between expenditures on risk
reduction and those on a comprehensive fail over strategy. The weight
given to risk reduction depends upon the impact that can be caused by
a short term disruption. Typical risk reduction steps include:
• A comprehensive set of backups, stored off-site
• Elimination of single-point-of-failures, such as a single source
for power or connectivity
• Dual-sourcing for outside services
• Infrastructure resiliency
• Security controls
• Technology improvements such as a fire suppression system
• Improved procedures including Change Management
Planning for the recovery option must consider:
• People and facilities (accommodation)
• IT systems, network, software, data and documentation
• Critical services including utilities
• Critical assets including paper documents and reference material
134
Aspect Description
Organization and The organizational structure recommended by ITIL has three layers:
Implementation • Executive – responsible for crisis management
Planning • Co-ordination – responsible for coordinating the overall effort
• Recovery – teams responsible for executing predefined plans to
recovery specific aspects of the infrastructure
Planning falls into three levels. At the top level the plans are:
• Emergency Response Plan
• Damage Assessment Plan
• Salvage Plan
• Vital Records Plan
• Crisis Management and Public Relations Plan
At the next level:
• Accommodation and Services Plan
• Computer Systems and Network Plan
• Telecommunications Plan
• Security Plan
• Personnel Plan
• Finance and Administration Plan
Additionally each recovery team must develop a detailed plan describing
the steps to take during a recovery of a specific aspect of the
infrastructure.
Implement Risk Risk reduction measures are actions taken to minimize the risk that a
Reduction Measures full disaster fail-over will be required. Measures to improve the
infrastructure resiliency should be managed by Availability Management,
but those same measures aid IT Service Continuity Management.
Implement Stand-by It is important to have contractual arrangements in place in advance.
Arrangements Such arrangements should include:
• Stand-by facilities
• Build-out of the stand-by facility to the required level
• Arranging for stand-by systems
• Verifying the continuity readiness of external service providers
135
Aspect Description
Develop Recovery Recovery planning should be carried out to ensure that:
Plans • There are sufficient details to enable a technical person not
familiar with the system to be able to follow the procedures –
involve people who are not familiar with the system to perform a
recovery test
• The recovery plans include key detail such as the data recovery
point, a list of dependent systems, the nature of the dependency
and their data recovery points, system hardware and software
requirements, configuration details and references to other
relevant or essential information about the system
• A check-list is included that covers specific actions required
during all stages of recovery for the system, for example after
the system has been restored to an operational state,
connectivity checks, functionality checks or data consistency and
integrity checks should be carried out prior to handing the
system over to the business.
Develop Procedures “The ITSCM plan is dependent on specific technical tasks being
undertaken. It is necessary that these are fully documented and
comprehensive so that any literate IT person can undertake the recovery.
Procedures need to be developed to include the:
• Installation and testing of replacement hardware and networks
• Restoration of software and data to a common reference point
which is consistent across all business processes
• Different time zones in a multinational organization
• Business cut-off points”
Initial Testing “An initial technical test can usually be done without the need to involve
the business. However, for subsequent tests it is prudent to get the
business to be involved to ‘prove’ the capability and to aid mutual
understanding of the activities and resources needed to achieve the
common goal of business recovery.”
Education and “This ensures that all staff are aware of the implications of Business
Awareness Continuity and of Service Continuity and consider these as part of their
normal working routine and budget.”
Training “IT may be involved in training the non-IT literate business recovery
team members to ensure that they have the necessary level of
competence to facilitate recovery.”
136
Aspect Description
Review and Audit “A regular review of all of the deliverables from the ITSCM process needs
to be undertaken to ensure that they remain current. With respect to IT
this is required whenever there is a major Change to the IT
Infrastructure, assets or dependencies such as new systems or networks
or a change in service providers, as well as when there is a change in
business direction, business strategy or IT strategy. As organizations
typically have rapid change, it is necessary to invest in an ongoing
review program and incorporate ITSCM into the organizational business
justification processes. New requirements will be implemented in
accordance with the Change control process.”
Testing “Following the initial testing it is necessary to establish a program of
regular testing to ensure that the critical components of the strategy are
tested at least annually or as directed by senior management or audit. It
is important that any changes to the IT Infrastructure are included in the
strategy, implemented in an appropriate fashion and tested to ensure
that they function correctly within the overall provision of IT Services.”
Change Management “Following tests and reviews and in response to day to day Changes,
there is a need for the ITSCM plans to be updated. ITSCM must be
included as part of the Change Management process to ensure that any
Changes in the Infrastructure are reflected in the contingency
arrangements provided by IT or third parties. Inaccurate plans and
inadequate recovery capabilities may result in the failure of ITSCM.”
Assurance “The final process in the ITSCM lifecycle involves obtaining assurance
that the quality of the ITSCM deliverables is acceptable to senior
business management and that the operational management processes
are working satisfactorily.”
12.10.
12.10. Continuity Management Relationships with other Service Management Processes
Please refer to the prior section for the relationship of IT Service Continuity Management
with Service Desk, Incident, Problem, Configuration, Change, Release, Service Level,
Financial and Capacity Management.
IT Service Continuity Management with Availability Management
Service Continuity works with Availability Management on resiliency and other risk reduction measures (SD
7.1.4, 7.1.8, 7.3.3)
The Service Continuity process is often managed under the department responsible for Security (SD 7.2.3)
Individual contingency plans for aspects of the infrastructure need to be unified and focused on the critical
137
IT Service Continuity Management with Availability Management
business functions to ensure that the available budget is applied in the most appropriate way (SD 7.3.1)
BSS 7799, the British Standard on Information Security Management, includes Service Continuity (SD 7.3.1)
The balance between expenditures on resiliency and those on a comprehensive fail over strategy depends
upon how much impact can be caused by a short term disruption (SD 7.3.2)
Resiliency improvements must go through the Change Management process (SD 7.3.2)
Risk reduction measures must be evaluated for Security implications. For example, out sourcing may
reduce the internal risk, but increase the exposure of confidential data to an outside party (SD 7.3.2)
Availability Management must work with Service Continuity to ensure the data can be recovered using
mirroring, RAIDs, backups, off-site storage, etc. (SD 7.3.2, 7.5)
Availability Management is not responsible for Business Continuity Management, but the two processes
have much in common
The Business Impact Analysis is a key input into Availability Management planning
Service Continuity works with Availability Management to determine which Services are Vital Business
Functions
Service Continuity works with Availability Management to assess and improve resiliency
Service Continuity provides input into the Availability Plan regarding business impact and resiliency
improvements (SD 8.6.3)
Service Continuity works with Availability Manage to balance between recovery options and risk reduction
measures (SD 8.9.1)
138
13.
13. Availability Management
Continuous Improvement
13.1.
13.1. Availability Management Synopsis Technical Observation Post
Goals Availability Plan
Optimize ability
Deliver cost-effective & sustained Availability Activities
Determine business requirements Determine Availability required for new/changed Service
Match IT capabilities to business requirements Identify VBF and impact from IT component failure
Provide alternatives & costing to fill gaps Determine targets for reliability and maintainability
Monitor & measure to ensure Availability is provided Establish measurements
Continuous improvement to optimize
Inputs
Benefits Business Availability requirements
Single point of accountability Business impact assessment
IT Services meet business requirements Availability, reliability and maintainability requirements
Availability is cost justified Incident and Problem data
Agree, monitor & measure Availability to support SLM Configuration and monitoring data
Identify shortfalls, identify & implement corrections Service level achievements
Business & User perspective to ensure optimal usage
Frequency & duration of failures reduced over time Outputs
Outputs
IT mindset moves from reactive to proactive Availability and recovery design criteria
IT is seen to “add-value” to the business IT infrastructure resilience and Risk Assessment
Agreed targets: Availability, reliability & maintainability
Critical Success Factors Reports on Availability, reliability & maintainability
Clearly defined and agreed SLAs achieved
Accurate business forecasts Availability monitoring
Knowledge & accuracy of IT plans & strategy Availability improvement plans
Understanding current & future technologies
Ability to demonstrate cost-effectiveness Manager’s Duties
Interaction with other effective SM Processes Define & execute AM processes
Ability to plan & implement to match business Ensure Services designed for required Availability
Monitor, measure & report on Availability per SLAs
Key Performance Indicators Optimize with cost effective improvements
Percent Unavailable Reduce over time frequency & duration of Unavailability
Duration Identify & progress corrective actions
Frequency of failure Forward looking Availability Plan
Impact of failure

Reluctance to appoint an Availability Manager
Difficulty understanding how AM can make difference
Current Availability is viewed as good enough
Resistance to authority of Availability Manager/Process
AM not empowered to influence IT
Tools
Component Failure Impact Analysis
Fault Tree Analysis
CRAMM
System Outage Analysis
Expanded Incident Lifecycle
139
140
13.2.
13.2. Availability Management Goal Statement
The goal of the Availability Management process is to optimize the capability of
the IT Infrastructure, services and supporting organization to deliver a cost
effective and sustained level of Availability that enables the business to satisfy its
business objectives.
This is achieved by determining the Availability requirements of the business and

matching these to the capability of the IT Infrastructure and supporting
organization. Where there is a mismatch between the requirement and capability,
Availability Management ensures the business is provided with available
alternatives and associated cost options.
Availability Management should ensure the required 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 continuously to optimize the Availability of the IT Infrastructure,
services and supporting organization, in order to provide cost effective
Availability improvements that can deliver evidenced business and User benefits.
13.3.
13.3. Availability Management Benefits
• "A single point of accountability for Availability (process owner) is
established within the IT organization
• IT Services are designed to meet the IT Availability requirements
determined from the business
• The levels of IT Availability provided are cost justified
• The levels of Availability required are agreed, measured and monitored to
fully support Service Level Management
• Shortfalls in the provision of the required levels of Availability are
recognized and appropriate corrective actions identified and
implemented
• A business and User perspective of IT Service Availability is taken to
ensure optimal usage and performance of the IT Infrastructure is
achieved to deliver maximum benefit
• The frequency and duration of IT Service failures is reduced over time
• IT support organization mindset moves from error correction to service
enhancement; from reactive to proactive attitude
• The IT support organization is seen to ‘add value’ to the business" (SD
8.3.5)
13.4.
13.4. Availability Management Critical Success Factors
• Clearly defined and agreed SLAs
• Accurate business forecasts
141
• Knowledge & accuracy of IT plans & strategy
• Understanding current & future technologies
• Ability to demonstrate cost-effectiveness
• Interaction with other effective SM Processes
• Ability to plan & implement to match business
13.5.
13.5. Availability Management
Management Key Performance Indicators
• Percent Available or Percent Unavailable
• Duration
• Frequency of failure
• Impact of failure
13.6.
13.6. Availability Management Possible Implementation Problems
• "The IT organization view Availability as a responsibility of all senior
managers and therefore are reluctant to justify the costs of appointing a
single individual as accountable for Availability
• The IT organization and supporting organization have difficulty
understanding how Availability Management can make a difference
particularly where the existing disciplines of Incident Management,
Problem Management and Change Management are already deployed
• The IT organization view current levels of Availability as good so see no
compelling reason for the creation of a new role within the organization
• There is resistance to process ownership and the concept of an
accountable individual/role who has authority over all the IT support
organization
• The IT organization fail to delegate the appropriate authority and
empowerment to enable the process owner for Availability Management
to influence all areas of the IT support organization" (SD 8.3.5)
13.7.
13.7. Availability Management Tools
• Component Failure Impact Analysis (CFIA)
• Fault Tree Analysis
• C Risk Assessment and Management Method (CRAMM)
• System Outage Analysis (SOA)
• The Expanded Incident Lifecycle
• Continuous Improvement
• Technical Observation Post (TOP)
• Availability Plan (SD 8.6.2 and 8.9)
13.8.
13.8. Availability Management Inputs and Outputs
Inputs:
• Business Availability requirements

• Business impact assessment
142
• Availability, reliability and maintainability requirements
• Incident and Problem data
• Configuration and monitoring data
• Service level achievements
Outputs:
• Availability and recovery design criteria

• IT infrastructure resilience and Risk Assessment
• Agreed targets for Availability, reliability and maintainability
• Reports of Availability, reliability and maintainability achieved
• Availability monitoring
• Availability improvement plans
Activities:
• Determine the Availability requirements for new or Changed Services

• Identify the Vital Business Functions and the impact from an IT
component failure
• Define the Availability targets for reliability and maintainability
• Establish measurements
13.8.1. Availability Management Inputs and Outputs Diagram
13.8.2. Availability Management Inputs and Outputs Description

Business Availability The Customers need to work with Service Level Management and
requirements Availability Management to document the Availability
requirements and evaluate the cost-effectiveness of achieving
that level of Availability.
143
Business impact A Business Impact Assessment (BIA) should be completed for each
assessment Vital Business Function (VBF)
“The identification of critical business processes, and the
potential damage or loss that may be caused to the organization
resulting from a disruption to those processes. Business impact
analysis identifies:
• The form the loss or damage will take
• How that degree of damage or loss is likely to escalate
with time following an incident
• The minimum staffing, facilities and services needed to
enable business processes to continue to operate at a
minimum acceptable level
• The time within which they should be recovered”
Availability, “Availability Management needs to ensure that the design activity
reliability and for Availability looks at the task from two related but distinct
maintainability perspectives:
requirements • DESIGNING FOR AVAILABILITY: This relates to the technical
design of the IT Infrastructure and the alignment of the
internal and external suppliers required to meet the
Availability requirements for an IT Service.
• DESIGNING FOR RECOVERY: This relates to the design
points required to ensure that in the event of an IT Service
failure, the service can be reinstated to enable normal
business operations to resume as quickly as is possible.”
Incident and “It is important to recognize that every Incident passes through a
Problem data number of stages. These are described as follows:
• Incident start
• Incident detection
• Incident diagnosis
• Component repair
• Component recovery
• Service restoration (and verification)
This ‘lifecycle’ view provides an important framework in
determining amongst others, systems management requirements
for Incident detection, diagnostic data capture requirements and
tools for diagnosis, recovery plans to aid speedy recovery and
how to verify that IT Service has been restored.”
144
Configuration and “Availability Management should take a proactive role in
monitoring data identifying and progressing cost justified Availability
improvement opportunities. The ability to do this places reliance
on having appropriate and meaningful Availability measurement
and reporting. To ensure Availability improvements deliver
benefits to the business and Users it is important that Availability
measurement and reporting reflects not just IT component
Availability but Availability from a business operation and User
perspective.”
Service level “The Service Level Management ( SLM ) function is normally
achievements responsible for communicating with the business on how their
Availability requirements are to be met and ultimately negotiating
the SLA for the IT Service. Availability Management therefore
provides important support to the SLM function during this
period.
While higher levels of Availability can often be provided by
technology investment there is no justification for providing a
higher level of Availability than that needed and afforded by the
business. The reality is that satisfying Availability requirements is
always a balance between cost and quality.”
Availability The process of Availability Management is documented, below.
Management
Availability and “The role of Availability Management within the design activities is
recovery design to provide:
criteria • The specification of the Availability requirements for
hardware and software
• The requirements for Availability measurement points
(instrumentation)
• The requirements for new/enhanced systems management
• Participation in the IT Infrastructure design
• The specification of the reliability, maintainability and
serviceability requirements for components supplied by
internal and external suppliers
Validation of the final design to meet the minimum levels of
Availability required by the business for the IT Service”
145
IT infrastructure “To assess the vulnerability of failure within the configuration and
resilience and Risk capability of the IT support organization it is recommended that
Assessment the proposed IT Infrastructure, service configurations, service
design and supporting organization (internal and external
suppliers) are subject to a formal Risk Analysis. CRAMM is a
technique that can be used to identify justifiable countermeasures
that can protect the Availability of IT Systems."
Agreed targets for The agreements for Availability are documented in the Service
Availability, Level Agreements (SLA). Each SLA must document the agreed
reliability and Availability or Unavailability target, the method of measuring
maintainability Unavailability and agreements for maintenance windows.
Reports of "In order to satisfy the differing perspectives of Availability,
Availability, Availability Management needs to consider the spectrum of
reliability and measures needed to report the ‘same’ level of Availability in
maintainability different ways. Measurements need to be meaningful and add
achieved value if Availability measurement and reporting are ultimately to
deliver benefit to the IT and business organizations. This is
influenced strongly by the combination of ‘what you measure’
and ‘how you report it’.”
Availability “A key output from the Availability Management process is the
monitoring measurement and reporting of IT Availability. This provides the
basis for:
• Establishing measures of Availability and agreeing
Availability targets with the business
• Monitoring of the actual Availability delivered versus
agreed targets
• Identifying unacceptable levels of Availability that impact
the business and User
• Reviewing Availability with the business and User
representatives
• Reviewing Availability with the IT support organization
• Continuous improvement activities to optimize
Availability"
146
Availability “The impetus to improve Availability comes from one or more of
improvement plans the following:
• The inability for a new IT Service to meet its SLA on a
consistent basis
• Period(s) of IT Service instability resulting in unacceptable
levels of Availability
• Availability measurement trends indicating a gradual
deterioration in Availability
• Unacceptable IT Service recovery and restoration time
• Requests from the business to increase the level of
Availability provided
• Increasing impact on the business and its Customers from
IT Service failures as a result of growth and/or increased
business functionality
• A request from SLM to improve Availability as part of an
overall SIP
• Availability Management monitoring and trend analysis”
147
13.9.
13.9. Availability Management Process Flow
13.9.1. Availability Management Process Flow Diagram
13.9.2. Availability Management Process Flow Description

Aspect Description
Define business The Customers need to work with Service Level Management and
Availability Availability Management to document the Availability
requirements requirements and evaluate the cost-effectiveness of achieving
that level of Availability.
148
Aspect Description
IT infrastructure Availability can be analyzed through techniques including:
analysis and • Component Failure Impact Analysis ( CFIA )
capability review • Fault Tree Analysis (FTA)
• CRAMM
• Calculating Availability
• Calculating the cost of Unavailability
• Developing basic IT Availability measurement and
reporting
• Developing business and User measurement and reporting
• Systems Outage Analysis (SOA)
• The Incident ‘lifecycle’
• Continuous improvement methodology
• Technical Observation Post (TOP)
Availability models “Modeling tools are required to forecast Availability and to assess
the impact of Changes to the IT Infrastructure. Inputs to the
modeling process include descriptive data of the component
reliability, maintainability and serviceability.
A spreadsheet package to perform calculations is usually
sufficient. If more detailed and accurate data is required a more
complex modeling tool may need to be developed. The lack of
readily available Availability modeling tools in the marketplace
may require such a tool to be developed and maintained ‘in-
house’.”
Agree Availability The agreements for Availability are documented in the Service
requirements Level Agreements (SLA). Each SLA must document the agreed
Availability or Unavailability target, the method of measuring
Unavailability and agreements for maintenance windows.
Specify Define the cost-justifiable level of Availability, reliability,
serviceability maintainability and serviceability requirements in agreements and
requirements negotiate those requirements into Underpinning Contracts with
Negotiate external vendors.
serviceability into
contracts
Specify reliability, Define the cost-justifiable level of Availability, reliability,
resilience and maintainability and serviceability requirements in agreements and
maintenance negotiate those requirements into Operational Level Agreements
requirements with internal service suppliers.
Negotiate into SLA
agreements
149
Aspect Description
Test for meeting Audits need to be conducted to insure that the monitoring is
Availability effective and the data is accurate.
requirements
Monitor compliance “A key output from the Availability Management process is the
to Availability measurement and reporting of IT Availability. This provides the
requirements basis for:
• Establishing measures of Availability and agreeing
Availability targets with the business
• Monitoring of the actual Availability delivered versus
agreed targets
• Identifying unacceptable levels of Availability that impact
the business and User
• Reviewing Availability with the business and User
representatives
• Reviewing Availability with the IT support organization
Continuous improvement activities to optimize Availability"
13.10.
13.10. Availability Management Relationships with other Service Management
Processes
Please refer to the prior section for the relationship of IT Service Continuity
Management with Service Desk, Incident, Problem, Configuration, Change,
Release, Service Level, Financial, Capacity and IT Service Continuity Management.
150

ITIL Study Guide

Uploaded by

Document Information

Original Description:

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 Study Guide

Uploaded by

Copyright:

Available Formats

ITIL Study Guide

It is my understanding that teaching materials may contain up to 10% of a publication without

Critical Success Factors Inputs

• Data feeds (assets, etc)

• Management Information and Monitoring

• "Receiving calls, first-line Customer liaison

3.8.1. Service Desk Inputs and Outputs Diagram

Service Desk with Problem Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk with Configuration Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk with Change Management

Service Desk with Release Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk with Service Level Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk with

Service Desk can be the customer interface to the ITIL processes.

Service Desk with Capacity Management

Service Desk can integrate with IT Service Capacity Management.

Service Desk with IT Service Continuity Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk with Availability Management

Service Desk can be the customer interface to the ITIL processes.

• Reduced business impact of Incidents by timely resolution, thereby increasing

• Improved monitoring, allowing performance against SLAs to be accurately

• Incident detection and recording

4.8.1. Incident Management Inputs and Outputs Diagram

4.9.1. Incident Management Process Flow Diagram

4.10.1. Incident Management Line Escalation Diagram

4.10.2. Incident Management Line Escalation Description

Incident Management with Configuration Management

Incident Management with Change Management

Requests for Change are not regarded as Incidents.

Incident Management with Release Management

Incident Management with Service Level Management

Incident Management with Capacity Management

Incident Management often finds options for beneficial system enhancement

Incident Management with IT Service

Incident Management with Availability Management

• “Incident details from Incident Management

5.8.1. Problem Management Inputs and Outputs Diagram

5.9.1. Problem Management Problem Control Process Flow Diagram

5.10.1. Problem Management Error Control Process Flow Diagram

5.10.2. Problem Management Error Control Process Flow Description

Problem Management with Configuration Management

Problem Management with Change Management

Request for Change is submitted in order to implement a resolution

Problem Management with Release Management

Problem Management with Service Level Management

Problem Management with Financial Management

Resolutions need to be cost effective

Problem Management with Capacity Management

Problem Management with IT Service Continuity Management

Problem Management with Availability Management

Much of Availability Managements work is in the detection and avoidance of Problems

Defining and documenting the procedures and working practices to be followed

Controlling and storing definitive, authorized and trusted copies of specifications,

Ensuring that all Changes to CIs are recorded as soon as practicable

Educating and training the organization in the control processes

Reporting metrics on CIs, Changes and Releases

Auditing and reporting exceptions to infrastructure standards and Configuration

• Incidents, Problems, Known Errors and updates