ITIL Foundation Guide

IT Service Success
FOUNDATION
STUDY GUIDE
© 2006 IT Service Success 1

The Foundations of IT Service Management
IT Service Success
FOUNDATION STUDY GUIDE.............................................................................1

The Foundations of IT Service Management...................................................2
The Importance of IT Service Management.....................................................6
What is IT Service Management? ...................................................................7
Why use ITIL? .................................................................................................9
What exactly is ITIL?.....................................................................................11
Benefits of ITIL explored................................................................................13
Additional benefits of adopting ITIL:...................................................14
ITIL Processes................................................................................................15
1 Service Desk..............................................................................................15
1.1 Function........................................................................................15
1.2 Mission..........................................................................................15
1.3 Goals.............................................................................................16
1.4 Benefits.........................................................................................17
1.5 Understanding the customer / user..............................................17
1.6 Organization.................................................................................17
1.7 Staffing.........................................................................................18
1.8 Structure.......................................................................................18
1.9 Tools.............................................................................................20
1.10 Metrics........................................................................................21
1.11 Challenges..................................................................................22
2 Incident Management................................................................................23
2.1 Mission..........................................................................................23
2.2 Goals.............................................................................................23
2.3 Definition......................................................................................23
2.4 Scope............................................................................................24
2.5 Benefits.........................................................................................24
2.6 Process.........................................................................................24
2.7 Incident Classification ..................................................................25
2.8 Escalation.....................................................................................25
2.9 Incident Manager Responsibility...................................................26
2.10 Tools...........................................................................................26
2.11 Metrics........................................................................................27
2.12 Challenges..................................................................................29
3 Problem Management................................................................................30
3.1 Mission..........................................................................................30
3.2 Goals.............................................................................................30
3.3 Definition......................................................................................30

3.4 Process.........................................................................................31
3.5 Benefits.........................................................................................31
3.6 Relationship between Incident, Problem, Known Errors and
Changes...............................................................................................32
3.7 Reactive Problem Management....................................................33
3.8 Proactive Problem Management...................................................33
3.9 Common Techniques....................................................................34
3.10 Major Problem Reviews...............................................................34
3.11 Tools...........................................................................................34
3.12 Metrics........................................................................................35
3.13 Challenges..................................................................................35
4 Change Management.................................................................................36
4.1 Mission..........................................................................................36
4.2 Goals.............................................................................................36
4.3 Why Change Management?..........................................................37
4.4 Benefits.........................................................................................37
4.5 Change Categories........................................................................39
4.6 Key Roles......................................................................................40
4.7 Process.........................................................................................42
4.8 Tools.............................................................................................44
4.9 Metrics..........................................................................................44
4.10 Challenges..................................................................................45
5 Configuration Management........................................................................46
5.1 Mission..........................................................................................46
5.2 Goals.............................................................................................46
5.3 Definitions.....................................................................................46
5.4 Scope............................................................................................47
5.5 Benefits.........................................................................................48
5.6 Process.........................................................................................49
5.7 Relationships with other Processes...............................................49
5.8 Key Terms.....................................................................................50
5.9 Configuration Manager's Responsibilities.....................................52
5.10 Tools...........................................................................................52
5.11 Metrics........................................................................................54
5.12 Challenges..................................................................................56
6. Release Management................................................................................58
6.1 Context.........................................................................................58
6.2 Mission..........................................................................................58
6.3 Goals.............................................................................................58
6.4 Appropriateness............................................................................59
6.5 Key Terms.....................................................................................59
6.6 Relationship to Configuration Management..................................60
6.7 Scope............................................................................................61
6.8 Benefits.........................................................................................61
6.9 Process.........................................................................................62
6.10 Release Management's Responsibilities.....................................63
6.11 Integrated Plans..........................................................................63
6.12 Tools...........................................................................................64
6.13 Metrics........................................................................................64
6.14 Challenges..................................................................................64
7 Capacity Management...............................................................................66
7.1 Mission..........................................................................................66
The Mission of Capacity Management is to: .......................................66

“Understand the organizations operation and IT infrastructure to
ensure that all current and future capacity and performance aspects of
the business requirements are provided cost effectively at the right
time”....................................................................................................66
Effective Capacity Management means "No Surprises!".....................66
7.2 Goals.............................................................................................66
7.3 Scope............................................................................................66
This scope covers three core areas: ...................................................67
7.4 Benefits.........................................................................................67
7.5 Process.........................................................................................67
7.6 Capacity Manager's Responsibilities.............................................68
7.7 Capacity Database........................................................................68
7.8 Tools.............................................................................................69
7.9 Metrics..........................................................................................69
7.10 Challenges..................................................................................71
8 Availability Management..................................................................72
8.1 Mission..........................................................................................72
8.2 Goals.............................................................................................72
8.3 Scope............................................................................................72
8.4 Key Terms.....................................................................................73
8.5 Benefits.........................................................................................73
8.6 Techniques....................................................................................74
8.7 Process.........................................................................................76
8.8 Tools.............................................................................................77
8.9 Metrics..........................................................................................77
8.10 Challenges..................................................................................78
9 IT Service Continuity..................................................................................79
9.1 Mission..........................................................................................79
9.2 Goals............................................................................................79
9.3 Scope............................................................................................79
9.4 Benefits.........................................................................................80
9.5 Process.........................................................................................80
9.6 Metrics..........................................................................................81
9.7 Challenges....................................................................................81
10 Service Level Management......................................................................82
10.1 Mission........................................................................................82
10.2 Goals...........................................................................................82
10.3 Scope..........................................................................................83
10.4 Benefits.......................................................................................83
10.5 Process.......................................................................................84
10.6 SLA Content................................................................................84
10.7 Tools...........................................................................................85
10.8 Metrics........................................................................................85
10.9 Challenges..................................................................................85
11 Security Management..............................................................................86
11.1 Mission........................................................................................86
11.2 Scope..........................................................................................86
11.3 Benefits.......................................................................................86
11.4 Process.......................................................................................87
11.5 Relationships with other disciplines............................................87
11.6 Metrics........................................................................................88
11.7 Challenges..................................................................................88

Organizations That Promote ITIL ..................................................................89
ITSMF............................................................................................................90
THOMPSON PROMETRIC................................................................................91
Thomson Prometric is the recognized global leader in testing and
assessment services, providing paper-and-pencil, Internet and computer-
based testing solutions. It offers a fully integrated testing system that
includes test development, test delivery and data management capabilities.
.......................................................................................................................91
Since 2002, Thomson Prometric and EXIN have collaborated on the delivery
of the ITIL Foundation exams in English. As a result, EXIN can improve the
accessibility of EXIN's IT Service Management (ITIL) exams for more
candidates worldwide, and test them in the highly secure, consistent
Thomson Prometric Testing Center environment, while providing candidates
with improved flexibility in choosing both the test date and location. .........91
www.prometric.com......................................................................................91

The Importance of IT Service Management
Over the years the reliance on IT services has never been more
prevalent. As Businesses grow, the IT services they utilize and rely on
become more complex, competitive. Alongside this the environments
have become more regulated. IT Managers are challenged daily with
the co-ordination and working in partnership with the business to
continuously deliver high quality IT services. IT Management is
concerned with the effective and efficient use of the four Ps :
People
Processes Products
Partners
With all this in mind a need has arisen for the creation of a standard
set of practices to manage the IT services being delivered. As a result
of this requirement the Information Technology Infrastructure Library
(ITIL) was created.
ITIL is widely recognized throughout the world, and may well be the
most widely accepted approach to managing and delivering IT services
today.
This guide will cover the following topics:
 What is Service Management and its importance

 What is ITIL?
 Why organizations should use ITIL
 The ITIL Processes
 The basic concepts of ITIL
 The benefits of ITIL
 Organizations that promote ITIL
 The ITIL framework

This guide will provide you information on the above topics, in non
technical, easy to understand terms with the objective being that upon
completion of this document you will have a good understanding of ITIL
that can be used a the basis for your ITIL Foundation Learning
Program.
What is IT Service Management?

IT Service Management is a top-down, business driven approach for
the management of IT that intentionally addresses the strategic
business value generated by the IT organization and the need to
deliver a high quality IT service.
IT Service Management is designed to focus on the issues that IT

organizations face on a daily basis - the people, the processes and the
technology issues.
Whilst IT Service Management as a concept is related to ITIL it is not

the same. When comparing the two, ITIL can be seen as an instance of
an ITSM framework, whilst also containing a subsection specifically
entitled ‘IT Service Management’.
IT Service Management within ITIL is the combination of the Service

Support and Service Delivery volumes. These are explained in more

detail later in the document.

Why use ITIL?
ITIL is popular because of the proven best practices that it offers. The
demand for information about ITIL continues to grow. Among other
reasons for investigating ITIL recommendations, one common
motivation is to learn about knowledge and best practices necessary
for achieving compliance with Sarbanes-Oxley and other IT governance
requirements. Another thing to consider is that ITIL is the only
consistent and comprehensive documentation of best practice for IT
Service Management.
Most IT-departments are event driven and operate in a reactive

environment, with day to day activity spent resolving issues, i.e.
service unavailable. Not only are these situations frustrating, but they
are also costly. The choice to adopt and implement is in the majority
based on the fact that the organization is able to understand better the
Total Cost of Ownership (TCO) and the actual activities undertaken
within the IT-department.
ITIL provides a proven method for planning, processes, roles and the
how they interact and communicate.
There are a number of reasons why organizations choose to adopt ITIL?
• The existing resources are failing to meet the needs of the

business demands & are becoming too expensive
• The customers perceive the current service(s) being delivered as
poor quality & unreliable
• Potential for audits to raise concerns regarding reduced
accountability & inability to be benchmarked.
• Major incidents are impacting revenue and service restoration is
becoming timely and expensive.
• To support strategic business objectives.
• To support and initiate a restructure, consolidation & corporate
governance
• To improve service based on proven Industry Best Practice &
standards
• Finally to improve service to customers and to stop re-inventing
the wheel
ITIL as with other model frameworks can provide an excellent structure

that companies and organizations can follow. Basically, employees can

work towards the same goals that are supported by a clear and specific
structure.

What exactly is ITIL?
Originally produced in the late 80’s – early 90’s as a set of more than
40 volumes, however, thankfully, this has now been reduced to a set of
six books that describe IT Service Management Best Practice. ITIL has
now become the de-facto standard in Service Management and as it
focuses on the best practice it can be tailored according to need. Over
the years ITIL has now become relevant to all organizations, whether
they be Public or Private sector.
The six volumes are:
• Service Support
• Service Delivery
• Planning to implement Service Management
• ICT Infrastructure Management
• Applications Management
• The Business Perspective
The library is intended to assist organizations to provide high quality IT

services, whilst faced with the challenges of budgets, skill shortages,
complexity of systems, rapid change and growth, current and future
user / customers requirements and the ever growing challenge of
increasing customer satisfaction.
Whilst the books offer guidance on the provision of quality IT services,

with the focus being on quality, it is worth noting that the books also
offer guidance on the accommodation and environmental facilities
needed to support IT.
√ The books are the only comprehensive, publicly available

guidance for IT service management.
The collections of volumes are produced by the OGC – Office of

Government Commerce (previously known as CCTA).
√ The books are best practice guidelines describing the ‘what’

rather than the ‘how’.
Whilst the UK Government created ITIL via the CCTA, it is quickly being
adopted throughout the world as the standard for best practice in the
delivery of IT Services. The main focus of ITIL is the IT Service
Management (ITSM)

√ ITSM is divided into two main areas, Service Support and Service
Delivery.
These two areas are made up of 10 disciplines

Benefits of ITIL explored
Fact : IT is what drives businesses today!
The profitability and shareholder loyalty of an organization is

dependent on the high availability, dependability, security and
performance of IT services. This
has made the maturity or immaturity of IT management highly visible.
By improving the IT processes, the organization can begin to:
o Improve project deliverables and the time to deliver;

o Improve resource utilization;
o Reduce the need for rework;
o Improve availability, reliability and security of mission critical IT
services;
o Be more competitive in the market place;
o Justify to the business the cost of service quality;
o Provide services that meet business, customer and user
demands
o Eliminate redundant work
o Integrate central processes
o Document and communicate roles and responsibilities in service
provision
o Learn from previous experience
o Measure the services offered and the customer satisfaction
linked to these services
o Provide demonstrable performance indicators
Some intangible Benefits of ITIL:
During the past decade, the reshaping of business functions as

processes have become a well know and reputable strategy for
reducing costs, reducing cycle times, and improving quality and
customer satisfaction.
There is a growing appreciation that IT is a key driver of business

process improvement. This has led to a predictable change in the
expectations for the IS organization to follow the process changes
occurring within the finance, sales, marketing and manufacturing
arenas.
In some cases, this has led to the formation of such organizational

structures as relationship managers, steering committees and user
councils to improve the alignment of business and IT planning.
A further consequence of the change has been to look at functionally

disconnected IT activities as linked sets that share common
information and customers.
Other benefits include improved staff satisfaction as a result of clear

and defined processes.
Additional benefits of adopting ITIL:
o Aligns IT services to present and future needs of the business

and its customers
o Better accessibility to services for users through single point of
contact
o Speedy responses to customer enquiries and complaints
o Improved team work and communication
o Better identification of areas for improvement
o Pro-active approach to service provision
o More favorable perception of services provided
o Improved quality of IT-related information for optimal
management and decision-making
o Reduced impact on the company’s business activities
o Better management and control over the IT system’s
infrastructure
o More effective and efficient usage of resources related to service
provision and subsequent cost reduction potential
o Higher IT system users’ productivity due to reduced down times
o Improved first line resolution rates
o Enhanced customer care and higher customer satisfaction
o Improved control of SLA performance
o Strengthened IT infrastructure
o Eradicate loss and inconsistent records of information, incidents
and customer enquiries
o Reduced numbers of incidents
o Discovery and implementation of permanent solutions Reduced
expense in developing processes, procedures and instructions
o Cost justifiable service quality
o Reduced costs due to centralized integrated processes
o Reduced costs due to ‘learning from past experience’
o Clearly defines functions, roles and responsibilities

o Improve the communication between the IT departments and its
customers
o Everyone speaking to same language
o IT Services that meet the business, customer and user demands
o Improve customer satisfaction – better measurements of
availability and performance of the IT service
o Support the business processes and provide IT services that
meet the particular business requirement
o Improve productivity and efficiency due to knowledge and
experience
o Improved employee satisfaction and potential to improve staff
retention levels
o Professional training and qualifications for IT personnel
o Everyone speaking to same language
ITIL Processes
1 Service Desk
1.1 Function
Function - Not A Process!
The IT Service Desk is not a core ITIL Process it is in fact a function.

However it is a very important function. Just because it is not classed
as a process does not mean that the Service Desk is any less well
organized, structured or controlled.
Service Desks need to have quality procedures, training programs,

scripts, tools and controls to help assure its performance.
1.2 Mission
The Service Desk acts as the central point of contact between the User
and the IT Service Management Organization. The Service Desk
handles both Service Requests and Incidents. The Service Desk
provides an effective interface to other activities such as Incident
Management, Problem Management, Change Management,
Configuration Management, Release Management, Service Level
Management and IT Service Continuity Management

1.3 Goals
The goals of the Service Desk are to:
o Provide a single point of contact between users and IT Service

Management.
o Reduce costs by the efficient use of resources.
o Ensure long term user/customer satisfaction.
o Handle user requests effectively.
o Reduce the business impact of incidents.
o Provide management information and reports.

1.4 Benefits
The Service Desk will provide a number of benefits:
o Ease of accessibility, a known contact point that is always

available.
o Central point of contact provides peace of mind that there's only
one place to communicate with the IT Service Organization when
reporting an Incident.
o Knowledgeable and helpful contact point, the user feels
confident that the right people and focus has been applied to
their Incident or Service Request.
o Useful 'filter', to prevent unnecessary Incidents (e.g. My PC's not
working - Is it switched on?) entering the IT Service Organization.
o Provision of reports and management information to help
maintain agreed service levels with the business.
1.5 Understanding the customer / user
The Service Desk will ensure that they:
o Really know and understand the user community.

o Understand the business drivers.
o Understand the Services used.
o Appreciate the impact of failure and downtime.
o Manage location, language and cultural challenges.
o Understand the management structure of the IT Service
Organization.
o An intelligent contact point that is helpful and works on behalf of
the user.
1.6 Organization
The Service Desk must ensure that it's organized well to provide:
o Appropriate hours of coverage.

o Levels of flexibility.
o Correct staffing levels.
o Appropriate skills provided.
o Appropriate knowledge.
o Suitable structure.

1.7 Staffing
Staff considerations to include:
o Systems and service understanding, technical awareness and

local business appreciation.
o Know the business and IT Service Organizational structure and
understand the management hierarchy.
o Interpersonal skills are vital to be efficient and effective.
o These include: empathy, ownership, drive, determination,
communication, patience and often language skills.
1.8 Structure
There are three well known structures for a Service Desk:
A "Local" Service Desk will support local business needs. It should be

fit for purpose and highly in tune with what the business users need.
Operating standards and processes are required to maintain consistent
quality of service.
A "Central" Service Desk supports multiple locations and sometimes

multiple geographies. The business is distributed. Centralization
provides a consistent service experience. Standards are maintained
and staffing levels and expertise can be controlled easier. This usually
leads to lower overall operating costs.
A "Virtual" Service Desk operation is location independent. Sometimes

Service Desk Analysts work from home or across a number of
locations. This is more common in large multi-national organizations
where multi-language assistance is required. Users feel like they are
communicating locally. Standard operating practices, processes and
user experience must be upheld. Management of the "Virtual" Service
Desk is more challenging due to the complexity, time zone difference
and language differences. Usually a local or regional team leader or
manager is appointed to act as the leading representative.
In addition, many large Service Desks operate a "Follow the sun"

Service. Here, "Follow the Sun" Service Desk Operations provide 24 X 7
X 365 support for large organizations or multiple global contracts.
Service Desk support is routinely 'switched' across time zones to

match the availability of staff. From a business perspective it is usually
cheaper to pay for staff between 0900 and 1700. Processes,
procedures and standards for the ongoing ownership and escalation of
incidents and requests is more challenging.

1.9 Tools
An Integrated IT Service Management Tool is a must for any effective

IT Services Organization. Such tools provide the capability to log an
incident or service request, record progressive actions, apply time and
date stamps, automate escalation and notification events against the
logged item and provide management information reporting at varying
levels.
The Tool must also be capable of providing workflow to enable

individual tickets to be worked across the many ITIL processes. For
example an Incident ticket can be assigned to a support group for
investigation and diagnosis.
An effective Service Desk may also utilize several other supporting

tools to increase the level of user responsiveness and overall
automation. If these supporting tools are integrated (or interface with)
the overarching IT Service Management tool - then overall levels of
inter-operability are enhanced.
Such tools include: Known Error Database, CMDB and Diagnostic

Scripts with Automated Resolution Actions. In addition, due to the
volume and frequency of calls received by any Service Desk, a suitable
call management system is typically required. Call management
systems provide queuing capabilities, call routing and transfer,
interactive voice response (IVR), and in more advanced cases
computer telephony integration (CTI) functionality. Again, if this
functionality is integrated within the overarching IT Service
Management Tool, then the overall control and visibility of tickets
logged will be considerably enhanced.

1.10 Metrics
Typical Service Desk Metrics Include:
o #calls taken,
o #incidents logged,
o #service requests logged,
o #calls abandoned (user hangs up),
o #calls answered within xx seconds,
o average call duration, calls waiting
o #calls logged per Service Desk analyst.
More advanced Service Desk Metrics include:
o #calls resolved first time,

o #calls passed to Support team x,
o #times a call was re-assigned,
o age of a call,
o average age of a call
o and #calls resolved within Service Levels.
An important aspect of the Service Desk operation is Service Quality

and User Satisfaction. Feedback forms, sample call backs and
workshops are common methods for determining how well the Service
Desk is performing and is an excellent way to learn how the Service
Desk can improve further.
An Integrated IT Service Management Tool and Call Management tools

provide the Service Desk with the capability of producing real-time and
historic reports on a wide range of metrics. It is not the production of
these reports that is important but the level of review, action and
decisions taken on the information provided that really counts.
The Service Desk Manager is responsible for the regular production of

management information and reports that provide vital feedback on
performance and improvement activities for IT Service Management

1.11 Challenges
Typically the Service Desk faces many day to day, medium term and
long term challenges. Included in these, but not limited to, are:
o Staffing levels.
o Staff skills and capabilities.
o Dealing with peaks in call volume.
o Managing high impacting incidents.
o Absorbing necessary information to be able to provide an
effective service.
o Maintaining IT Service quality as the Organization becomes more
complex, the number of service increases or the Organization
changes/grows.

2 Incident Management
2.1 Mission
“The mission of Incident Management is to restore normal

service operation as quickly as possible with minimum
business disruption to ensure the best levels of availability and
service are maintained”
Remember:
- Normal Service Operation - As Quickly as possible - Minimum

disruption - Best levels of availability.
2.2 Goals
The goals of Incident Management are to:
o Restore normal service operation

o Minimize adverse business impacts
o Ensure the best possible levels of availability and service quality
o Improve staff utilization and efficiency
o Protect user and customer satisfaction
2.3 Definition
What is an Incident?
An incident is any event that:
o Is not part of the standard operation

o Is a deviation away from normal working practice
o Causes (or may cause) an interruption in service
o Causes (or may cause) a reduction in service quality
NOTE: An Incident is NOT the same thing as a Problem!

2.4 Scope
The scope of Incident Management covers:
o Applications – Hardware
o Service Requests
o Service Availability
o Deviations from normal service (Service Levels)
It is important to remember that Incident Management handles regular

Incidents, Service Requests and Major Incidents.
2.5 Benefits
The benefits of Incident Management are:
o Reduce the impact of Incidents by focusing appropriate

resources, in a timely manner
o Proactive identification of enhancements or repeat occurrences
o Improve the monitoring of performance against known Service
Levels
o Ensuring that Incident Records have the correct details within
them, both at the start of the Incident and throughout its life.
o Ensuring that Incident Records are correctly labeled at closure
time to enable proactive trend analysis of Incidents.
o Improve user and business satisfaction levels
o Provide assurance for the business and IT Service Management
that the right people and things are executed at the right time.
2.6 Process
The Incident Management process involves the following activities:
o Detection and recording

o Classification and initial support
o Investigation, diagnosis and escalation (if required)
o Ongoing Incident ownership, monitoring, tracking and
communication
o Incident Closure

2.7 Incident Classification
Incidents are classified at three stages:
1. Initially > to determine the type of Incident

2. Throughout the life of an Incident > to track changes in
classification
3. At Incident Closure > to ensure the right classification for analysis
and reporting.
Examples of Incident Classifications include:
o Fault
o Operating System
o Error Message
o Bug Low Performance
o Hardware
o Server
o Configuration
o Set-up error
2.8 Escalation
Incident escalation is critical to ensure that Incidents are managed

throughout their overall duration. The timeliness of who attends to an
Incident, when and what is done to close an Incident is assisted by
Incident escalations. Typical examples of escalations include:
o Transferring an Incident from second line support to third line

support
o Making a higher level of IT Service Management aware of the
Incident's status (or existence)
o Engaging with external (third party) support to provide
assistance with Incident Management activities.
Incident Management also concerns itself with the management of a

special category of Incident - known as Major Incidents. These are
Incidents that have a very high impact (real or potential) on the
organization.

Typically Organizations have a specially defined set of escalation
procedures for Major Incidents where senior business and IT Service
Management are more frequently appraised of status, progress and
closure information.
2.9 Incident Manager Responsibility
The Incident Manager is responsible for:
o The overall process efficiency and effectiveness

o The general operation of the function - Managing the provision of
the right skilled resources (for example across first and second
line support teams)
o Identifying, monitoring and making important decisions against
metrics
o Assuring the availability of the Incident Management function
o Producing management information reports - Managing Major
Incidents
2.10 Tools
For Incident Management the use of an integrated IT Service Tool is

paramount. Incidents are usually logged by the Service Desk and
categorized before handing off electronically to an IT support function
such as Desktop support. Here, Incidents are received and initial
support, diagnosis and escalation can occur.
Note that (typically) one overarching primary tool is used to store real-
time data and information about the status, detail and progress of an
Incident whilst other (local) tools are often used to identify and
diagnose the Incident.
Each support area usually has several tools that are application,
Infrastructure or Service specific. These supporting tools are also vital
for the Incident Management process. They enable the rapid diagnosis
of an Incident often in a very complex environment.
Smart organizations have provided the Service Desk with certain

'views' of the IT environment so that they may correctly record,
classify and begin to diagnose Incidents at the point of receipt (from
users). This saves vital minutes and leads to a better hand-off to the
support function, if needed.

2.11 Metrics
The accurate capture, storage, manipulation and presentation of

Incident Management metrics is vital to enable IT Service Management
to make effective decisions. These decisions can be at three levels:
o On an individual Incident basis (to provide an accurate account

of the Incident's overall timeline; who did what, when)
o On a Incident Group basis (to determine specific trends, say a
particular router is failing between 0900 and 1000 every Monday
morning)
o On an overall functional level (to determine the number of
business impacts, by Incident category, per week)
Typical examples of Incident Management Metrics include:
o Number of Incidents received, by category

o Average time to close an Incident (from receipt)
o Volumes of Incidents handled, by team or an individual
o Number of Incidents not closed successfully within agreed
Service Levels and the reason(s) why
o Number of Incidents closed by the Service Desk (where usually
staff costs are lower per head than a second and third line
colleague)
o Average cost of closing an Incident
o Average cost of impact of an Incident to the business It is very
important to stress that metrics and the resulting reports must
be viewed holistically and from a number of angles before
management decisions are taken. Positively impacting one
metric (e.g. Average time to close) can negatively impact
another (e.g. Number of repeat Incidents).

2.12 Challenges
The Incident Management function face a number of day to day

challenges:
o Communication: many different IT and business users may be

involved at different stages over a prolonged period of time.
o Bypassing the Process: Sometimes users and business areas will
deliberately or unknowingly bypass the Incident Management
Process. It is critical that users understand how to access the
Service Desk to ensure that Incidents are correctly recorded and
the management process begins.
o Quality of Information: real-time information is open to people's
interpretation, sources of information vary across the life of an
Incident and facts may only come to light after the Incident has
been closed.
o Maintaining Momentum and Ownership: avoiding support teams
taking too long to diagnose an Incident, avoiding scope creep
whereby the clock is ticking and no positive decisions are being
taken - or - managing to maintain control and ownership when
much more senior people are involved in the Incident.
o Restoring Normal Service Operations: managing conflicting views
between support teams to reach a service restoration point,
deciding when to restore service, say if only a partial restoration
is possible; ensuring that resources are available if the Incident
runs over an extended duration.
o The Paradox of Restoring Services V's Obtaining Root Cause
Information (e.g. Temporary Log Files): Problem Management will
often require certain information is saved safely in order to
investigate the underlying root cause of an Incident. Performing
the save (system dump) takes valuable minutes and therefore a
'call' has to be made - "restore now" V's "find the true root cause
once and for all".
o Incident Information Volumes: Excellent information
management skills are required to correctly split, cut, slice and
dice key data and views of this data from ALL the Incident
Management data that is logged. The sheer volume of Incidents
in some operations makes this challenging. - Being Proactive V's
Reactive: Too many incoming Incidents can lead to a reactive
culture and people feel 'burnt out' over time. If little proactive
work occurs, then Incidents may recur in the Operation, fuelling
further reactive effort and burn out. The cycle needs to be
broken to have a positive effect in the medium term.

3 Problem Management
3.1 Mission
The mission of Problem Management is to:
“Minimize the adverse impact effect on the business if both

Incidents and Problems caused by errors in the IT Environment
and to proactively prevent the occurrence of Incidents,
Problem and errors”
3.2 Goals
The goals of Problem Management are to:
o Identify the true underlying root cause of Incidents

o Present workarounds and resolutions
o Initiate improvement actions
o prevent recurrences of Incidents
o minimize the adverse impact on the business
o ensure that the best levels of availability and service quality are
maintained
3.3 Definition
The definition of a Problem is:
“The UNKNOWN underlying cause of one OR MORE Incidents”
A Problem will become a Known Error when:
o The root cause is known

o A work-around or resolution has been identified
NOTE:
A workaround is also generally referred to as a "circumvention" or

"temporary fix". Root Cause is also referred to as the "underlying root
cause".
It is important to commit to memory the definitions and clear

distinctions between: An Incident, A Problem and a Known Error. These
definitions must be strictly adhered to.

3.4 Process
The Problem Management Process consists of the following activities:
Problem Control:
o Identification
o Classification
o Assign Records
o Investigation and Diagnosis
Establish Known Error Control:
o Error identification and recording

o Error Assessment
o Recording the error / resolution
o Error Closure
3.5 Benefits
There are several key benefits of Problem Management:
o Proactive prioritization of which Problems should be eliminated

first (and second...)
o Understanding of where the Organizations 'pain' areas are.
o An holistic view of where ALL of the Organizations problems are
up to in terms of status.
o The provision of permanent resolutions to Problems to help drive
IT Service Quality and business satisfaction
o Improve the opportunities for Organizational learning and pro-
activeness.
o Support the Incident Management and Service Desk functions by
providing constructive feedback on the quality of their work.

3.6 Relationship between Incident, Problem, Known Errors and Changes
Four Key Terms
It is important to understand clearly the relationship between these

four terms:
o Incident
o Problem,
o Known Error
o RFC
First, the easy and straightforward scenario: An Incident is an

interruption to IT Service. Some Incidents occur and are closed with no
further action required. Some Incidents require a change to be raised
in order to close them. Therefore Incident Management will raise a
request for change (RFC) to the Change Management function.
Now, the more complex scenario: Following the occurrence of one or

more Incidents, a Problem Manager may choose (or be asked) to raise
a Problem Record. Remember - a Problem is the unknown cause of one
or more Incidents. Once investigated and diagnosed, the Problem
Manager may then raise a known error record. (Incidentally, a known
error record could actually remain open indefinitely within a known
error database if the IT Service Organization deems it not viable, say
for reasons of cost, to raise a RFC and eliminate the root cause of the
Problem).
However, more commonly the IT Service Organization (or the business)

will deem it important enough so they can raise a request for change
(RFC) to ensure that a suitable and FULL resolution to the problem is
implemented into production.
After the implementation of a successful change, both the Known Error record
and the Problem record can be closed. But what happens to the original
Incident record?
Two scenarios are likely:
Given the nature of Incident Management is it unlikely that the Incident

record will still be open after an extended time period. Remember that
Incident records may be closed by Incident Management when the
Incident is closed I.E. Normal IT Service has resumed. So, If a
satisfactory workaround has been deployed, and normal service is
resumed, then the Incident record can be closed. This usually happens
quite quickly in most organizations.

If the original Incident has no suitable workaround then the Incident
Management function will pass the Incident details over to Problem
Management as soon as deemed necessary. Problem Management will
then work as described above, but the entire RFC cycle (described in
Change) will take place with great haste to ultimately reach a point
where a resolution can be deployed into production to restore normal
service.
At this point the Incident record can be closed (because normal service
has resumed) and both the Problem and Known Error Records may be
closed too.
3.7 Reactive Problem Management
Reactive Problem Management has to effectively deal with new

incoming Incidents. Problem Management will review Incident details,
configuration details and any defined workarounds. Problem
Management will then follow the Process steps of Problem Control and
Error Control to effectively determine the root cause of the Problem
and highlight a known error.
Problem Management can then:
o Recommend improved and more effective workarounds to

Incident Management (in case of recurrence)
o Raise Requests for Change (RFC's)
o Offer Service Improvement recommendations to the Service
Desk, Incident Management and Configuration Management.
(Note: Recommendations are not limited to these IT Service
Management functions - but more commonly occur
3.8 Proactive Problem Management
Proactive Problem Management has three elements:
o Trend Analysis: identifying faults and general problem areas that

need to be tackled.
o Targeting Preventative Support Action: by calculating the
ongoing cost of Incidents - the so called 'pain factor' - which
leads to proactive action.
o Providing relevant and targeted information to other IT Service
Management functions, such as IT Service Level Management.

3.9 Common Techniques
There are several commonly applied Problem Management techniques

that have been used in quality circles for many years:
o Kepner Tregoe
o Ishikawa Diagrams
o IS / IS NOT
o Force Field Diagrams
3.10 Major Problem Reviews
Once a major Problem has been resolved, Problem Management can

facilitate a Major Problem Review. All the staff involved in the
resolution of the Problem should attend.
Key agenda items include:
o What actually happened?

o What was the cost and impact to both the business and the IT
Organization?
o What was done right?
o What was done wrong?
o What can be improved next time?
o How can this problem be prevented from happening again?
o Review actions, agreed owners and target dates for next steps
3.11 Tools
Problem Management will dramatically benefit from the use of an

integrated toolset. Incident records should be easily accessible and
capable of quickly creating a Problem Management Record using core
data from the Incident record. From here any additional details added
to the Problem Record will, in turn, be capable of transferring into a
Change Record.
As time passes the original core details will be added too and utilized
across many ITIL Processes. This is the power of using an integrated
toolset.
Even more powerful is when the toolset is configured in such a way

that "time" is deliberately compared with the current status of the
Problem - highlighting, for example, when a breach of an SLA is due in
so many hours.

The toolset should be configured to assist all teams in the execution of
their duties.
3.12 Metrics
Key metrics for Problem Management include:
o Number of open Problems and their status

o Number of Problems closed and the elapsed time until closure
o Number of Problems that were resolved within and outside of the
agreed Service times
o Number of Problems, by category, to help drive trending
information
Additionally, Management will want to know where the 'pain' is

continually coming from and how much impact/cost it is causing the
business. These Problems should receive the highest attention and be
eliminated from the environment.
3.13 Challenges
The Problem Manager will face a series of challenges on a day to day

basis including:
o Managing the incoming volume of Problem Records V's

Progressing existing (open) Problem Records.
o Ensuring that 'what matters most' is today's focus requires a
high degree of regular prioritisation. It is useful to have criteria
established and agreed up front in order to do this without
constantly seeking higher Management's approval.
o Collaborating with multiple groups, sometimes across different
geographies and companies (third parties), means Problem
Management need to have excellent communication skills.
o Whilst all of this is happening, the Problem Manager will need to
ensure that regular daily, weekly and monthly reports are
produced for IT Service Management.

4 Change Management
4.1 Mission
The mission of Change Management is to:
“Ensure that standardized methods and procedures are used

for the efficient and effective handling of all changes, so that
the impact of any Incidents on IT Service can be minimized”
Remember that timeliness is key.
Most definitions of Change Management also include the word,

"Prompt" to reflect this.
4.2 Goals
The goals of Change Management are to:
o Ensure the efficient and PROMPT handling of changes

o Apply standard change procedures
o Minimize the impact of any Incidents
o Improve the quality and availability of IT Service.
o In addition, Change Management protects the current IT Service
delivered to the business by ensuring that formal steps must be
taken in order to implement new changes. If changes were not
formally handled, then poor quality or ill thought through
changes could be implemented and have a negative impact on IT
Service, say by causing additional Incidents

4.3 Why Change Management?
Changes to an IT environment, whether it be to a Server or an IT

Application, can either come along:
Reactively - for example, if an Incident occurs.
Proactively - for example, as part of a Service Improvement Initiative

or new Project. Therefore Change Management is a critical and
absolutely necessary part of the IT Service Organization. Change
Management provides a structured, controlled and authorized way for
changes to enter the production environment.
Change Management must:
o Ensure that ALL changes are considered and handled

appropriately
o Facilitate the prompt handling of Changes
o Maintain an overarching view of the status of all Changes.
o Maintain the balance between allowing changes to enter
production and NOT allowing poor quality or ill timed changes to
enter production. Change Management is the key guardian of
Service Quality. This is a difficult and high profile role with the IT
Service Organization. The Change Manager has to balance the
impact, cost, benefits and risk or either approving OR not
approving the Change
4.4 Benefits
There are many benefits of Change Management:
o Protecting IT Service from the negative impacts of poorly

designed/built or tested changes.
o Ensuring that the change is scheduled correctly to avoid conflicts
with important business or IT events.
o Improved productivity of business and IT people since there are
less Incidents
o Improved overall ability to handle multiple changes in the correct
sequence, allowing greater volumes of change to enter
production - and therefore provide the business benefit they
were intended to deliver.
o Ability to temporarily 'freeze' (or lock-out) all Changes to provide
total protection for IT Service. This usually occurs temporarily
when the business has a unusually high volume of activity to
perform, say a retailer over the last two weeks in December. It
can also occur for one off events, say during the first two days of

the business beginning to service a massive new customer
contract.

Change Management is sometimes (incorrectly) criticized for 'slowing
down' activities leading to the implementation of new changes.
Such criticisms are usually from people who do not understand and
appreciate the Change Management function. In modern
Organizations, Change Management does not slow down the
absorption of Change, it provides the "gentle brakes" to allow you to
slow down around corners and then rapidly accelerate.
What would happen if there was NO Change Management?
4.5 Change Categories
There are several Change Categories that are important to know:
Categorizing Changes correctly into Minor, Regular, Significant and

Emergency.
Each Category will determine how in-depth and timely the overall
assessment and approval stages are.
Ironically Emergency Changes are assessed by fewer people in less

time - but often present the most risk to IT Service.
Minor Changes will be reviewed and approved by the Change Manager

and typically do not require the approval of the formal CAB (although
some members may be called on for their opinion).
Regular Changes will be reviewed in a formal CAB
Significant Changes often require an additional level of approval by
Senior IT and Business Management.
Often the term "Routine" change is also used. These are special pre-
approved types of changes that present very low risk and potential
impact. Typically these are logged and scheduled on the Change
Management tool - but only require local area (e.g. Telecoms)
approval.

4.6 Key Roles
Change Manager
The Change Manager is responsible for:
o Day to day process management.

o Receiving, logging, prioritising and handling Requests for Change
(RFC's)
o Chairing CAB Meetings.
o Chairing CAB/EC Meetings.
o Assessing the impact, cost, benefit and risk of proposed
Changes.
o Authorising acceptable changes.
o Not approving unacceptable changes.
o Maintaining the Forward Schedule of Changes (FSC). - Publishing
the Projected Service Availability (PSA).
o Ongoing communications with teams who are designing,
building, testing and physically implementing changes.
o Post implementation review of changes.
o Initiating and acting on Improvement opportunities.
o Production of daily, weekly and monthly management
information reports.
o Overall efficiency and effectiveness of the Change Process
Change Advisory Board
The Change Advisory board is a critical part of the Change Process. The
CAB is made up of a broad range of IT and business representatives, all
of which represent a core part of the either the IT Service Organization
or the business.
The role of the CAB is to review, understand, assess and ultimately

approve or not approve each Change.
Now some changes are so small, low impact and well rehearsed that
they have special approval from the Change Manager NOT to have to
be reviewed by the CAB. Such Changes often include minor
Configuration changes to Infrastructure or when small pieces of new
functionality, that have been tested, are 'switched on'.
However, these Changes are NOT exempt from the Change

Management Process (they will still be raised and approved within the

controls and visibility of the Change Team) they just do not require the
more detailed scrutiny of the CAB.
It makes practical sense to not review every change otherwise the

Process could be perceived to be cumbersome and 'slow' down the
progression of Change into production.
For non routine Changes, the CAB will:
o Formally meet to review the Change

o Assess the change against certain criteria, appropriate to the
organization and the complexity and risk of the change
o Advise the Change Manager on which changes should be
approved or not approved, and the reasons why
o Advise on the actual scheduling and correct timing for the
change to be implemented, avoiding negative impacts to IT
Service.
CAB Attendees include :
o Interested Business area representatives.

o Incident Management.
o Problem Management.
o Configuration Management
o IT Programme Managers.
o Technical Support Representatives.
o Suppliers, Maintainers and Developers.
o Experts and Technical Consultants.
o IT Service Managers.
o The Change Manager and Change team members.
The attendees are not limited to the above list, and will differ
according to the needs of each Organization. Some Organizations
choose to only invite certain CAB members when certain types of
changes are scheduled for review. This helps to maintain the efficiency
of the Change Process

CAB Emergency Committee
The CAB Emergency Committee exists to provide an emergency

service to review, assess and ultimately approve or not approve an
emergency change.
Oftentimes, the need for Change approval will not coincide or cannot
wait for the next standard CAB meeting. This occurs most when either
action is required to protect or restore IT Service (say, as the results of
an Incident) or when some key component of a project has been
incorrectly dealt with (say, a critical data file needs updating in real-
time to ensure that another planned change will take place
successfully).
The CAB/EC is made up of a known sub-set of regular CAB members.

The CAB/EC provides essential emergency assistance to the Change
Manager to help deal with specific urgent, late or previously
unrecognised Change requests. In such cases, it is typical for the
CAB/EC meeting to take place via a conference call. Such conference
calls can happen at any time including out of office hours and at
weekends.
The 'agenda' is the same as a standard CAB, however the risk factor
(because not all the CAB are present - or there is little time to engage
with others) is typically higher.
Essentially, the CAB/EC facilitates a "fast tracking" of the normal

Change Process to try to facilitate business need whilst protecting IT
Service. A difficult balance!
4.7 Process
Process Lifecycle
The Change Process consists of the following core lifecycle stages:
o Logging and Filtering

o Prioritisation and Categorisation
o Impact and Resource Assessment
o Authorization
o Scheduling
o Change Design / Build
o Change Test
o Change Implementation
o Post Change Review
o Close

Important Activities
There are several important activities that help to underpin the

successful operation of Change Management:
o Logging and Filtering of Requests to prevent duplicate or poor

quality change requests entering the Change Management
Process
o Applying a 'Priority' to each Change. This will drive the speed of
assessment and also the level of scrutiny that's applied by the
CAB (or CAB/EC).
o Applying the Change Category (Minor, Standard, Significant,
Emergency)
o CAB members assess the information provided on a Change
Record by the Change Initiator (sometimes the same as the
person who 'raised' the change). The assessment includes a
review of impact, risk, resources and the required timing
(schedule) of the Change. - CAB members will either approve the
Change or not approve the change (stating the reasons why).
o Approved Changes are passed to the Change designer/builder
along with official notification of the approval and the specified
implementation schedule.
o The Change builder must also devise back-out plans. It's
important for the CAB to see these and appreciate that in the
event that something untoward happens, the Change can be
backed out quickly and effectively with no impact to IT Service.
o Typically, an independent test team (or test manager) will be
appointed for each specific Change. The goal is for each Change
to be fully tested before it enters production to avoid any
negative impact to IT Service

4.8 Tools
Change Management requires the use of an integrated toolset to store,

update, check and retrieve important information about each Change.
The Change Management tool should be integrated and offer workflow

capabilities from: Incident, Problem and Configuration Management; as
well as provide visibility for Change requestors, designers, builders and
testers.
The Change Management tool should be fully integrated with the

Configuration Management function, particularly with respect to the
identification, linking and real-time updates of the status of
Configuration Items.
The Change Management tool should also provide reporting

functionality to enable Change to provide Management with historic
and 'look ahead' reports. Such reports will be utilized within CAB and
CAB/EC meetings. It is also important that 'one version of the truth' is
maintained and protected at all times.
Where multiple tools (or views of data) exist - Change Management

must determine the sole source of Change information. Important
decisions must only be made from one reference source - otherwise
incorrect decisions will be taken and this may impact IT Service.
4.9 Metrics
Key metrics for Change Management include:
o Number of Changes, by priority and category, and then status.

o Number of Changes rejected by CAB, and the reason(s).
o Number of Changes approved and awaiting Implementation
o Number of Changes currently scheduled.
o Number of Emergency Changes, along with the reason why it's
an emergency - so the Change Manager can recommend (or
insist) on this type of Change becoming a regular Change next
time. The goal is to minimize the number of Emergency Changes
because these are considered higher risk.
o Number of successful V's unsuccessful (failed) Changes, by
category, by requesting area. This will help to identify where
poor quality Changes are coming from and lead to
recommendations for overall improvement

4.10 Challenges
The Change Manager will face a number of day to day challenges:
o Lack of awareness and understand of the Change Process by

the IT Organization.
o Lack of support from the CAB and/or CAB/EC - Managing the
volume of incoming Changes to avoid bottlenecks in the
receipt and assessment of Changes.
o Lack of control over the volume of emergency Changes and
the level of influence Change Management have over this
volume in the future.
o Lack of an accurate Configuration Management Database
(CMDB) to underpin the Change Process.
o Lack of knowledge and ownership of key individuals when
assessing any Change, for example not fully appreciating the
knock-on impacts of performing the change on other IT
Services.
o Ensuring that the Change function is perceived as adding
value V's 'slowing down' the absorption rate of new Changes
to support IT Service objectives and business requirements.

5 Configuration Management
5.1 Mission
The mission of Configuration Management is to:
“Provide a logical model of the IT Infrastructure by identifying,

controlling, maintaining and verifying the version of all
Configuration Items in existence”
5.2 Goals
The goals of Configuration Management are:
o Account for the existence and status of IT assets and

Configurations.
o Control and maintain the status of IT assets.
o Support all the other IT Service Management Processes.
(especially Incident, Problem, Change and Release
Management).
o To support the adherence to legal, licensing and contractual
obligations. *What's where? What's it doing? Is it 'legal'?
5.3 Definitions
Important Definitions:
o Configuration: anything that we need to record and control. A

Configuration can be broken down into a number of
Configuration Items (CI's)
o Configuration Item (CI): any individual Infrastructure component
or an item (for example an Incident Record) related to the
Infrastructure within a Configuration.
o A CI can vary considerably in type, size and complexity; ranging
from a whole system down to a specific component on a circuit
board.
o A CI can also be broken down into any number of Component
CI's.
o The hierarchy, different levels and details at each level at which
CI's are defined and grouped varies between IT Service
Organizations.

o It is Configuration Management's role to identify and standardize
on a hierarchy that is suitable for any given Organization.
5.4 Scope
The scope of Configuration Management is very important and may be

considered in two dimensions:
Across IT Services and Infrastructure - Down into CI's and different

levels of Hierarchy.
For example, Configuration Management will need to determine the

scope of what CI's will be identified and managed across the huge
range of it's IT Services and Infrastructure. Will all third party
applications be included? Will the recently acquired third party data
centre be covered and included in scope?
Secondly, the CI's levels will need to be defined and managed down for
each CI item.
For example, take a typical PC. Should the CI level be:
o PC
o Keyboard
 Mouse
• Screen
o CPU.
Should Configuration Management also identify and control the CPU's

CI's:
o CPU
o Circuit Board
 Firmware
• Chipset
o Interfaces
 Fan
Clearly "Scope" is two dimensional and the scope selected needs to

best service the needs of the IT Service Organization, to in turn, best
service the business.

5.5 Benefits
The benefits of Configuration Management:
o Provides accurate and timely information on CI's to support other

IT Service Management Processes.
o Facilitates the adherence to legal and contractual requirements
such as Software Licenses.
o Facilitates the adherence to cost controls and budgets, especially
useful for knowing how many of each item is maintained within,
say a maintenance contract. - Improves the visibility of any CI's
current status e.g. A certain Server currently has an Incident
logged against it, so Change Management can easily see this and
determine whether to go ahead and approve a Change or not.
o Improves the overall level of consistency and standardization
across a multiple CI type. For example: Are all PC's currently
running the same level of Operating System?
o Supports Security Management (note: Not a Service Support or
Service Delivery Discipline) by highlighting any "unknown" CI's
for example an "unknown" Service is connected to the core
network. What is it? Who owns it? How is it configured?
o Facilitates impact analysis for Incident and Problem
Management.
o Provides confidence for IT Service Senior Management that
everything is truly "known", is "under control" and can be
referenced in a structured way.

5.6 Process
The Configuration Management Process contains the following stages:
o Planning: The Configuration Management Plan should include:

scope and objectives, policies and standards, roles and
responsibilities, CI naming conventions and the design of the
Configuration Management Database (CMDB).
o Identification: The selection, identification and labeling of all
required Configuration Items (CI's). This covers various
information on CI's including: names, owners, relationships,
versions, status and identifiers. Naming conventions must also
be established.
o Control: This stage ensures that no CI is added, modified or
replaced without the appropriate controls. All CI's will be under
Change Management control. This stage also provides
Management assurance that only authorized CI's are recorded.
o Status Accounting: Reports are regularly produced containing
current and historical data on all CI's. It enables changes and
tracking of CI's. Accounting occurs over the lifecycle of a CI -
from order, receipt and implementation - through to ongoing
status and finally withdrawal and disposal. This stage is used to
establish baselines.
o Verification and Audit: Checks to ensure that the CMDB reflects
the physical configuration and vice-versa. For example: A check
to ensure that the live environment is correct before a major
Release. Automated audit tools should be used to assist the
Configuration Team. Also included is the formal verifying of
Release and Configuration documentation before Changes are
made to the live production environment.
5.7 Relationships with other Processes
Configuration Management is closely linked with other IT Service

Support and Service Delivery Processes:
o Incident.
o Problem.
o Known Error.
o Request For Change
o Change Authorized
o Change tested
o Implemented
o Released

5.8 Key Terms
CMDB
The Configuration Management Database (CMDB) is designed to hold

details of CI's, their attributes and their relationships. Another
important purpose of the CMDB is that is enables other IT Service
Processes to be able to use the information to support other processes
at key stages. For example: - Incident Management will ensure that
any CI currently out of normal service operation, is flagged as such in
the CMDB. This in turn, allows Change Management to make
appropriate decisions when assessing requested Changes. The CMDB
is a complex relational database that enables real-time multiple access
to many CI's. Therefore the structure, levels, organization and overall
"correctness" of the CMDB is a critical underpinning feature of IT
Service Management.
Definitive Software Library
The Definitive Software Library is a physical library which holds

definitive and authorized versions of all Software. Any access to
Software in the DSL is strictly controlled by Change Management and
Release Management. It is the 'one version of the truth', in terms of
trusted Software versions, as utilized in the live production
environment
Baseline
Baseline - A set of CI's that have been frozen at a specified point in

time. - A snapshot of the configuration acting as a key marker point to
facilitate either progression of a Change or Release - or a reversal of a
Change or Release. - The snapshot contains all structural and CI details
at any particular moment in time. - The snapshot can act as a marker
for Change or Release reversals should something go wrong. Therefore
it is an important record of a particular 'moment in time'.
Level of Control
Level of Control - The Configuration Process aims to target maximum

control with the minimum amount of records in the CMDB. This
'sweetspot' needs to be carefully thought through and planned. - Some
CI's will deliberately have more details than others. Not all CI's are
recorded to the same level. - What's appropriate to the Organization is
what matters most. - Typically, Configuration Managers will start
planning their CI levels and CMDB structure by looking at critical IT

Services and understanding what's important to record within relevant
CI's.

5.9 Configuration Manager's Responsibilities
The Configuration Manager is responsible for:
o The overall efficiency and effectiveness of the Process.

o The maintenance of the function, including the provision of
suitably skilled and experienced staff.
o The production of reports to support the goals of Configuration
Management.
o The enhancements to the Process to provide quality and
accurate information within the CMDB to support other Processes
such as Incident, Problem, Change and Release Management.
o The design, configuration and upkeep of the CMDB. This is
challenging since the CMDB will need to be kept up to date with
regular updates from all aspects of the IT Infrastructure and
targeted IT assets.
5.10 Tools
There are three important types of tool to consider for Configuration

Management:
The CMDB:
This is the heart of any Configuration Management Process. The CMDB

is the central storage area for the definition and status of all relevant
CI's. The CMDB is a complex relational database that stores, updates,
adds, removes and provides status reports on the CI's and their
relationships at many different moments in time. The CMDB should be
kept up to date at all times. However, in reality some aspects of the
CMDB will only be as accurate as the last known update. It is often
impractical to update all of the CMDB in real-time for every possible
'event' that occurs. See "agents" for an explanation.
The Integrated Toolset:
Again, with Configuration Management, the existence of an integrated

IT Service Toolset is important and will help to ensure that information
is shared in the right place at the right time. For example: details from
Incident records should automatically update the status of relevant
CI's. Similarly for Change: Any CI's currently having a Change logged
against them should be marked as such within the CMDB. The
integrated toolset will know this and can provide real-time, accurate

information as to the status of any CI. So long as the toolset and the
CMDB have been purposely configured to provide this view.

IT Asset "agents":
Each Infrastructure and Software asset in the IT Environment will need

to be registered and made known to the CMDB. Typically, assets run
"agents" which are special pieces of software that are designed to talk
to the CMDB at pre-defined intervals, or when certain events are
triggered or closed. Agents can be stored locally, say on a router, and
configured on that particular device. Agents can also be found within
the CMDB itself and can go out and seek (auto discover) assets. Third
party vendors often provide intelligent agent software for these
devices. To avoid 'traffic floods' or unnecessary updates, some assets
are configured for only major events whilst others are configured to tell
the CMDB everything that happens. Again, the configuration of agents
depends on what information the Configuration Manager requires
within the CMDB. Sometimes, the CMDB will run at a pre-defined level
of accuracy and only when necessary (say, before a major Release) will
the Configuration Manager execute special routines to obtain a
snapshot (Baseline) of absolutely everything.
5.11 Metrics
The accurate capture, storage, manipulation and presentation of

Configuration Management metrics is vital to enable IT Service
Management to make effective decisions. The CMDB in conjunction
with "agents" and the integrated toolset can achieve this.
Typical Metrics include:
o Lists of CI's, by category (used for Audit reports).

o Status of a particular group of CI's.
o The status of one CI (say, that has an Incident recorded against
it).
o The time and date stamp of when a CI was last made known to
the CMDB.
o List of all Software installed (to match against the license
agreement).
o Snapshots of ALL CI's (prior to a major release - in case things go
wrong).

5.12 Challenges
The Configuration Management function face a number of day to day

challenges:
o Designing the CMDB.
Selecting the correct 'level' at which to record, process and manipulate

CI's is a challenge. If the level is too low (detailed) then there may be
too much data for the IT Service Organization to handle and effectively
utilize. Too much data or an over-ambitious level of detail can present
other Processes with a cumbersome quantity of data to handle. Too
little data and the Processes do not receive useful information to
leverage the power of the CMDB.
o Maintaining the CMDB.
Once the level of CI's is agreed and configured into the CMDB and
agents, the challenge then becomes ensuring that the agents work as
agreed and actually do populate the CMDB with the right information
at the right time. Agents are software components and these fail
occasionally too.
o Leaving the CMDB with knowledge gaps that need to be regularly

identified and plugged.
Just think about the sheer size and complexity of this task in your IT
Organization. How many PC's do you have? How many Servers,
Printers, Software Packages, IT Services, Networks, Databases? Now,
multiply that total number by, say, three because it's assumed that
there are three related (lower level e.g. Keyboard) CI's for each known
asset. You should have a pretty big number in your head.
o Ensuring assets can 'talk' to the CMDB.
The CMDB selected will typically be bought from a major Vendor. Most
CMDB's are already fully integrated with the IT Service toolset.
However, challenges can occur when you consider how to obtain
information from another Vendors asset that uses a different way of
communicating, say a different agent. Thankfully communication
standards usually mean that this can easily be overcome - but there
are exceptions. Sometimes, separate local CMDB's are needed to
manage certain "islands" of CI's, which then feed the master CMDB.
When purchasing new assets, the IT Service Organization needs to
ensure that their agents are compatible with the selected CMDB - both
now and in the future.

o Lack of tools or tooling expertise.
All tools are not equal. Sometimes, particularly for older Assets (say,
older Network equipment) agents will not readily be available.
Decisions will need to be made about how the information is provided
to the CMDB. Sometimes intelligent scripts are written and executed
from Servers that 'go out' and interrogate the legacy equipment.
Maintaining a CMDB requires a competent IT Service Organization.
Specific skills and experience sets are valuable for the accurate
maintenance and ongoing support of the CMDB.

6. Release Management
6.1 Context
It is important to understand the context of Release Management.

Although the Release Management function is an IT Service Function -
it does have a great deal of day to day involvement with the IT
Development and Project Management part of the IT Organization.
Although staff in these areas will design, build, configure, test and
implement systems and Infrastructures; it is Release Management's
responsibility to ensure that this is achieved in a structured manner for
anything that is purposely defined as a 'Release'.
6.2 Mission
The Mission of Release Management is to:
“Apply an holistic view of a Change to an IT Service and ensure

that ALL aspects of a Release (technical and non technical) are
considered together. To ensure that releases are implemented
in a safe, structured and secure way that will protect the Live
environment from the negative impacts of Change”
6.3 Goals
The Goals of Release Management are to:
o Implement new releases.

o To oversee the rollout of software, hardware, relevant components
and documentation. - To ensure that only correct, authorized and
tested versions are implemented.
o To maintain the Definitive Software Library (DSL) and the Definitive
Hardware Store (DHS).
o To manage the Release Process with Change and Configuration
Management.
o To ensure that only properly licensed Software is in use. This means
no unlicensed or pirate software exists. It also means that unused
licenses are identified and any refunds are claimed.

6.4 Appropriateness
Release Management is most appropriate when the IT Service

Organization has to:
o Implement large or complex sets of Changes.

o Manage a series of successive major Software roll-outs.
o Group important Changes together to meet some criteria, say to
comply with legislation by a certain date.
Note - Not all Changes will be packaged into Releases. It is perfectly

feasible for Changes to be individually considered by Change
Management.
However, it quickly becomes apparent that economies of scale, lower

risk and better utilization of resources is achieved when a group of
Changes are packaged together and handled as a Release.
6.5 Key Terms
There are nine key terms that must be remembered:
o Release: A collection of authorized Changes. These can be

Minor, Major and Emergency.
o Release Unit: A portion of the IT Infrastructure that can
normally be released together.
o Delta Release: A Partial release containing only those items
that actually changed.
o Full Release: A Release containing ALL the components of the
Release unit, regardless of whether they have changed or not.
o Package Release: A grouping of Full and/or Delta Releases
usually recommended to meet some business need e.g. To
provide stability to the Live Environment.
o Roll-out: To deliver, install and commission new or changed CI's
across the Organization. In this case, changes CI's make up a
release, as defined above.
o Definitive Software Library: A physical library (usually well
protected, locked and fireproofed) containing Master copies of all
authorized version of Software and their license agreements.
This is strictly controlled by Release Management. Key
considerations include: Media, Security arrangements, retention
periods, audits, naming conventions and environments
supported.

o Definitive Hardware Store: Special area set aside for the
secure storage and protection of hardware spares. These will
reflect the parts used within the Live environment. Such items
may be used for testing or major Incident recovery but must be
carefully managed and ultimately replaced if used.
o Release Policy: An important document that states the roles
and responsibilities for Release Management. Typically Policies
contain information of the scope, standards and working
practices of the Release Management function. This is to clarify
to the other IT Service teams exactly how a Release is managed -
from planning through to implementation.
6.6 Relationship to Configuration Management
It is important to understand the relationship between the Release

Management Process and the CMDB. The CMDB holds the details of
Software, Hardware, documentation and events. It contains event
records of Changes and Releases.
A Release record is always raised to satisfy one or more Request for

Change. So the CMDB contains information that not only supports the
Release process - but also holds information about the Release itself.
The CMDB will be used to get information about a release and

information about the target environment (Development, Test and
Live).
The Release Manager and the Change Manager have the capability of
ensuring that the destination environment has the actual capability of
receiving the Change e.g. The Operating System is at the correct level
to run the Software that is transitioning.

6.7 Scope
The scope of Release Management may be defined by:
o The Release Policy document which outlines the role of Release

Management in the provision of IT Service.
o The relationships that Release Management maintains with
Change and Configuration Management.
o The criteria for when Changes should be packaged together into
Releases.
o The definition of when and what Release Management actually
do across environments: Development, Test and Live.
o The degree to which an Organization chooses to utilize Releases
Management: for example Programme Managers who are
responsible for a number of projects within a defined business or
IT area or group
6.8 Benefits
The benefits of Released Management should be considered when

combined with Change and Configuration Management since the
Processes are so inter-dependant.
There are several key benefits:
o Assurance that the right Software and Hardware is being used

with the Live environment, minimizing the chances of any illegal
or unauthorized Software or Hardware is used.
o Supports the improvement of IT Service Quality, since there will
be a greater success rate for the implementation of new
Releases, which in turn means less impact or downtime for the
business.
o Enables the IT Service Organization to handle complex Changes
as well as a greater number of overall Changes by releasing
them into the Live environment in Packages.
o Improves the utilization of building, testing and implementation
resource.

6.9 Process
The Release Management Process consists of a number of logical steps

that may be considered in line with the environments that these steps
are carried out in. Typically, most Organizations have a minimum of
three distinct environments: Development, Test and Live. These can be
supplemented with other specialized environments such as Operational
Testing (a distinct type of Test environment) and Pre-Production (a true
"mirror" of the Live environment - but considered part of Test).
Process Stages include:
o On Development: Defining and publishing the Release Policy

(See Key Terms) and Release Planning.
o On Test Environments: Developing (or purchasing) Software,
Building, Configuring bespoke packages, performing fit for
purpose Testing, Release acceptance, roll-out planning and
beginning the communication and training for the
implementation of the Release.
o On the Live environment: The distribution and installation of the
Software; and finally the commissioning of the Software.
Key considerations here include:
o Building / Configuring Packages: Components should be

assembled and built in a controlled manner using automated
tools where possible. This improves control and visibility and
minimizes human reliance.
o Testing and back-out plans: All releases must undergo careful
testing before implementation into the live environment.
Workable back-out plans should exist to enable the Release to be
quickly reversed should an untoward event occur. The back-out
plan should also e tested to ensure that it works successfully.

6.10 Release Management's Responsibilities
The Release Manager has several key responsibilities:
o To manage the overall efficiency and effectiveness of the Process

o To ensure that suitably skilled and experienced staff are
available to manage Releases. - To work with the Change and
Configuration teams to ensure that the quality of the Release
and the way it is progressed from Development, through to Test
and ultimately into Live is maintained.
o To work with Development staff and Project Staff to ensure that
Release Integrity is maintained.
o To produce regular management information reports that clearly
show the status and progress against plan of a particular
Release.
o To identify and help improve the quality of the Process.
6.11 Integrated Plans
Many IT Service experts claim that integrating Release, Change and

Configuration plans offers considerable advantages.
Remember:
o Without Change and Configuration Management, Release

Management is limited in it's ability to achieve it's goals.
o Changes will not be properly assessed and authorized.
o Configuration items will not be under the control of a CMDB, so
valuable CI information will not be available to help package and
control Released across the Development, Test and Live
environments. It is therefore recommended that a consolidated
Change, Configuration and Release plan is created for all of the
IT Service Organization to adhere too, and measure their
progress against.

6.12 Tools
Release Management will benefit significantly from the use of several

tools:
o The Integrated IT Service Tool. (See Relationship to Configuration

Management).
o The CMDB. (See Relationship to Configuration Management).
o Local Environment Tools: such as test management tools, code
packing tools and resource planning tools. Such tools provide
automation, real-time and historic reporting as well as help to
improve the overall management of each environment.
o Asset Management Tools: one that is capable of managing and
tracking an asset across it's entire life from selection and
purchase, through to delivery, build, test, implementation,
maintenance and eventually it's decommissioning. Such tools are
typically used by Financial functions.
6.13 Metrics
Release Management is concerned with the following metrics:
o Release Records, stored within the CMDB, that describe the

contents and details of a Release
o The status of components at a CI level within the CMDB for
particular environments.
o The number of CI's that are affected by a particular Release.
o The number and type of Change Records that make up a
Release.
o The successful progression of Change records as the Release
progresses across Development, Test and into Live.
6.14 Challenges
Release Management may encounter several challenges:
o Avoidance or circumvention to policy, procedures and working

practices.
o Unclear ownership of activates across Development, Test and
Live environments between IT Service Staff and Development /
Operational Staff.
o Senior Management pressure to roll out a Release before it has
been fully tested, or it is considered fully ready.
o Lack of clear understanding about what exactly is contained
within a Release leading to misconceptions on implementation.

o Lack of support from environment staff to enable Releases to
progress according to planned time scales.

7 Capacity Management
7.1 Mission
The Mission of Capacity Management is to:
“Understand the organizations operation and IT

infrastructure to ensure that all current and future
capacity and performance aspects of the business
requirements are provided cost effectively at the right
time”
Effective Capacity Management means "No Surprises!"
7.2 Goals
The goals of Capacity Management are to:
o Balance Capacity Demand against Capacity Supply in a cost

effective and timely manner.
o Understand current and future needs.
o Ensure that sufficient (not excessive) Capacity always exists.
o Ensure that IT Capacity is cost justified.
o To be forward looking and pro-active. In other words: -
o Having the appropriate capacity in place and making the best
use of it.
o Getting the timing right: too soon is money wasted but too late
causes Incidents!
7.3 Scope
The scope of Capacity Management can be wide ranging, depending
on any particular IT Service Organization.
Typical Capacity Management functions will cover:
o All applications
o All systems
o All Infrastructure
o All Networks
o All peripherals
o Human Resources (where necessary to avoid delays to the timely
provision of Capacity).

This scope covers three core areas:
o Business Capacity Management (BCM): What Capacity the

business needs to operate.
o Service Capacity Management (SCM): What Capacity the actual
Services need to operate.
o Resource Capacity Management (RCM): What Capacity the
Technology Resources need to operate e.g. Disk, CPU,
Broadband Connections.
7.4 Benefits
o There are many benefits of Capacity Management:
o Increased efficiency and cost savings.

o More economic use of the IT services.
o Removal of spare and unnecessary capacity and optimizing
current equipment.
o Reduce or eliminate unnecessary 'panic' buying.
o Reduce the risk of performance problems.
o Improved forecasting.
o Proactive awareness of potential Capacity issues.
o Improved relationships with customers and users.
o Service improvements seen through better control.
o Reduce the need for reactive support.
7.5 Process
o Performance monitoring
o Workload monitoring
o Application sizing
o Resource forecasting
o Demand forecasting
o Modeling

7.6 Capacity Manager's Responsibilities
The Capacity Manager is responsible for:
o Monitoring the performance and the throughput of IT services

and their supporting components.
o Tuning activities to make efficient use of resources.
o Understanding current demands of IT resources and producing
forecast for future requirements.
o Influencing the demand for resource, in conjunction with other IT
Service Management processes.
o Producing a Capacity Plan and predicting IT resources needed to
achieve agreed SLAs.
o Ensuring the availability of appropriately skilled and experienced
staff to run and improve the Process.
7.7 Capacity Database
The Capacity Database holds Capacity data referring to:
o The Business
o IT Services
o Technology
o Finance
o Utilization
o Performance
o
The Capacity Database interfaces with, or is integrated with, the
CMDB. Note: Do not confuse the Capacity Database with the CMDB.
They are NOT the same thing!
The Capacity Database is the absolute cornerstone of Capacity

Management. It will be used to produce critical reports such as
forecasts and plans as well as performance and Capacity reports.
This will hold existing and future capacity information. In reality, it is

unlikely to be single database, but will probably exist in more than one
location and will contain many types of data, for example:
o Business data,
o Service data,
o Technical data,
o Financial data and
o Utilization data.

7.8 Tools
The Capacity Management function should have tools such as the

following:
o The Capacity Database (see separate description).

o Performance management tools.
o Resource management tools to enable modeling, including
application sizing.
o Demand and workload management.
o Reporting tools (production of the Capacity plan).
Remember: the Capacity Management Database is used as the basis

for the production of all Capacity Management reporting. This will hold
existing and future capacity information. It is unlikely to be single
database, but will probably exist in more than one location and will
contain many types of data.
7.9 Metrics
A multitude of metrics can exist within each of the three core areas
that Capacity Management focuses on:
Business Capacity Management (BCM):

o Existing SLAs
o Future Service Level Requirements (SLRs)
o Business Plan
o Capacity Plan
o Modeling Techniques , Analytical, Simulation, Trending and Base-
lining
o Application Sizing Methods
Service Capacity Management (SCM):

o Service Levels
o Systems, networks and service throughput and performance
metrics
o Monitoring, measurement ,analysis, tuning and demand
management
Resource Capacity Management (RCM):

o Utilization metrics of the current technology
o Forecasted metrics for future or alternative technologies
o Resilience of the current systems and services.

7.10 Challenges
Capacity Management face a number of challenges:
o Customer requirements exceed technical capacity limits.

o Over expectation of the benefits realized from tuning.
o Unrealistic performance figures from equipment suppliers.
o Lack of business information due to security or commercial
restrictions.
o Inaccurate or incomplete business forecasts.
o Incomplete or inaccurate information from IT support functions.
o Too much data - data overload - unable to "see the wood for the
trees".
o Lack of financial resources.
o Lack of technical resources with the right skill set.

8 Availability Management
8.1 Mission
“Availability Management ensures services are available when

the customer needs them”
8.2 Goals
The Goals of Availability Management:
o To optimize the capability of the IT infrastructure and supporting

organization to deliver a cost effective and sustained level of
availability that enables the business to satisfy its objectives.
o This is supported by the Availability Plan. This plan is a long term

plan for the pro-active improvement of IT Availability within
imposed cost constraints of the business. The plan must contain:
goals, objectives, key deliverables and describe the operation of
the function in respect of the goals
8.3 Scope
The scope of Availability Management works right across the IT

organization and:
o Optimizes availability levels by monitoring and reporting all key

elements.
o Determines availability requirements.
o Produces the Availability Plan.
o Collects and reports on Availability data.
o Ensures SLAs are met by monitoring against them.
o Continuously reviews and improves levels of service availability.
o Works with many other IT service teams to ensure receipt of
inputs and delivers outputs to them.

8.4 Key Terms
There are 5 elements of Availability Management:
Availability: The agreed service hours when a component (e.g.

resource, hardware, software) is available. Often expressed as a
percentage and then documented in the SLA (e.g. Available time /
Agreed Service Time * 100).
Reliability: The reliability of a component to perform a required

function under stated conditions for stated period of time. Expressed
as MTBF (Mean Time Between Failure) or MTBSI (Mean Time Between
System Incidents), or number of breaks in a period. Also documented
in the SLA.
Maintainability: The ability to restore services or components back to

normal operational state. Expressed as MTTR (Mean Time To Recover).
Also documented in the SLA.
Serviceability: The support for which external suppliers can be

contracted to provide parts of the IT infrastructure. (Documented in the
Underpinning Contract).
Security: Concerned with the security of the services ensuring that

the service is delivered within secure parameters and that
confidentiality, integrity and availability are not compromised.
8.5 Benefits
There are many benefits of Availability Management:
o Effective Availability Management will influence customer

satisfaction and help to maintain or grow future business and
profitability
o Effective Availability Management will increase the overall levels
of confidence that management actually has in the IT
organization. More specifically it ensures:
o A focus point, across the IT Organization, that helps to drive up
levels of availability.
o The frequency, duration and therefore impact of IT service
failures can be reduced over time

o IT Services can be designed with the appropriate level of Service
Availability.
o This function provides true end-to-end availability reporting to
ensure that the SLM function can accurately report service
availability within their SLA's.
8.6 Techniques
In addition to tools there are a number of techniques that could be

used to provide a framework for forecasting availability:
1. CCTA Risk Analysis and Management Method (CRAMM).
Used to identify security countermeasures for the protection of IS

systems. CRAMM has a built in ‘what if’ facility so that scenarios can be
run to assess the impact of change.
2. Component Failure Impact Analysis (CFIA).
A simple technique that can be used to identify IT services that are

particularly vulnerable to failure and the configuration items on which
a large number of services are dependant. This is achieved by
populating a grid detailing configuration items on one axis and the IT
Services on the other axis.
Each configuration item would then be categorised as:

If failed does not affect IT service
If failed causes the IT service to be unavailable
Is there an alternate configuration item that can provide the service?
Is there an alternate configuration item but the service has to be
recovered?
Completion of the grid provides an easy way to identify the

configuration items on which a large scale number of services are
dependant, or you can identify which IT services are complex and are
vulnerable to failure.
3. Fault Tree Analysis (FTA)
A technique that can determine the chain of events that causes

disruption to the IT service. It examines the consequences of single
vents of chains of events in determining whether there is a failure in
the IT infrastructure.

8.7 Process
Availability Management has numerous inputs and outputs as part of

the process :
Inputs:
o Business availability requirements
o Business impact assessment
o Availability, reliability and maintainability requirements
o Incident and problem data
o Configuration and monitoring data
o Service level achievements
Process:
o Optimization of availability by monitoring and reporting all key
elements.
o Determining availability requirements in business terms.
o Predicting and designing expected levels of availability and
security.
o Production of the Availability Plan.
o Collecting, analyzing and maintaining and reporting availability
data.
o Ensuring SLAs are met but monitoring against them, including
OLAs.
o Continuously reviewing and improving availability.
Outputs:
o Availability and recovery design criteria
o IT infrastructure resilience and assessment
o Agreed targets for availability and maintainability
o Reports of availability, reliability and maintainability achieved
o Availability monitoring
o Availability improvement plans

8.8 Tools
The Availability Management tool should have the following facilities:
o Availability monitoring, calculating and reporting.

o Availability modeling.
o Incident prevention.
The tool will have multiple inputs of data from a variety of sources and
some manual capture and data entry may be required.
8.9 Metrics
The IT Availability Metrics Model (ITAMM) assists in assessing a range

of metrics and perspectives that should be considered when
establishing availability measurement and reporting.
Measurements need to be meaningful and add value. Often the data

required to calculate metrics will be taken from a number of sources
and requires a lot of manual effort.
Here are some common metrics used for Availability Management:
Service Availability is a measure of the time that the service is

actually available when compared with the scheduled time.
It is often calculated and presented as a % of the actual hours

required, for example:
Actual hours / required hours * 100% = availability
Service Reliability is usually measured as:
o Mean Time Between Service Interruption (MTBSI)

o Mean Time Between Failure (MTBF)
Service Maintainability is usually measured as:
o Mean Time To Repair (MTTR)

8.10 Challenges
There are several challenges to consider:
o Avoid availability measurements that mean nothing to the

business or the customer.
o Overcoming restrictions on not being able to measure availability
at the point of service delivery.
o Identifying and securing skilled resource for the role.
o The justification of costs to management, for example the cost of
some countermeasures such as hardware which may be seen as
redundant kit and unnecessary.
o Lack of senior management buy-in.
o Undue reliance on other Service Management functions being in
place, for example Service Desk, Configuration Management and
its associated CMDB.
o Lack of suitable software - although tools are available,
information is gathered from a number of sources, with a lot of
information being gathered manually.
o Dependency on suppliers, in particular for maintainability and
reliability.
o Difficulty in determining and understanding the business and
customer availability requirements.

9 IT Service Continuity
9.1 Mission
The Mission of IT Service Continuity:
“To manage an organization's ability to continue to provide a

known, agreed and pre-determined level of IT Service, to
support business requirements, following some kind of
interruption to the business. To recover IT Service and
Technology within required and agreed time scales to support
the overall Business Continuity process”
9.2 Goals
What are the goals of IT Service Continuity?
o Reducing the immediate and ongoing impact of a failure or

disaster on the business.
o To quickly restore IT Services to at least the minimum level that
supports the business.
o Prevent the loss of customer or business confidence, say caused
by an inability to recover service within agreed time scales.
o Reduce the overall vulnerability and risk to the business of a
failure or disaster through effective risk assessment, analysis
and risk management.
o To produce IT service recovery plans that are fully integrated
with, and fully support, the organization's overall business level
continuity plan.
9.3 Scope
Security Management impacts all Service Management disciplines. In

particular it should be reflected in the levels of confidentiality,
integrity, and availability required within the Service Level Agreements
(SLAs) and Operational Level Agreements (OLAs) under Service Level
Management.
There is also a close relationship between IT Security and Continuity

Management in that each relies heavily on the tools and techniques of
risk management.

9.4 Benefits
What are the benefits of IT Service Continuity Management?
o Management of risk leads to reduction of likelihood of disaster

occurrence.
o Management of risk leads to reduction in impact if disaster did
occur.
o Meeting regulatory requirements.
o Improved relationships between the IT organization and the
Business.
o Greater awareness by the IT organization of the business service
priorities and needs.
o Capability to recover and restore IT services in the order that the
business really needs to have the best chance of recovering.
o Reduction in insurance premiums (lower risk).
o Increased confidence in IT's ability to actually recover (since it's
been tested!)
o The perceived credibility and professionalism of IT is increased
9.5 Process
The IT Service Continuity Process is in 4 stages and purposely includes

business level terms, like Business Continuity Management.
Remember that IT Service Continuity is a critical sub-component of the

overall Business Continuity Management Process:
Initiation of Business Continuity Management (BCM).

o Requirements and Strategy for BCM
o Business Impact Analysis
o Risk Assessment
Business Continuity Strategy
o Implementation.
o Organization and Implementation Planning
o Implement Stand-by Arrangements
o Develop Recovery Plans
o Implement Risk Reduction Measures
o Develop Procedures
o Initial Testing
o Operational Management:

o Operational Assurance: (There are five activities that lead to
this being achieved)
o Education and Awareness
o Review and Audit
o Testing
o Change Management
o Training
ITIL also prescribes the benefits of continual improvement - so you

should remember that after stage 4 - you should be identifying and
implementing ongoing improvements to improve quality and reduce
costs.
9.6 Metrics
o Co-operation and commitment with organizations key

stakeholders to create and execute a recovery plan
o Effective installation of backup tools
o Effective implementation of configuration management process
and training
o Successful testing of the Service Continuity Plan
9.7 Challenges
A prevailing "That's not likely to happen to us!" attitude to risk.
o Therefore a subsequent lack of investment in resources and time

to perform the activities.
o Lack of time and available skilled resources to be involved in risk
assessment, testing and rehearsing IT service recovery activities.
E.g. "We're too busy delivering live service to rehearse for a
disaster that may or may not happen!"
o Lack of business involvement in proper planning, risk assessment
and testing leads to the IT Service Organization making best
estimates about service recovery options.
o IT is more advanced than the business in it's overall approach to
Business Continuity - leading to well structured IT recovery but
poor business involvement and execution

10 Service Level Management
10.1 Mission
The mission of Service Level Management is to:
“Maintain and gradually improve business aligned IT service

quality through a constant cycle of agreeing, monitoring,
reporting and reviewing IT service achievements and through
instigating actions to eradicate unacceptable levels of service”
Remember:
o Maintain
o Improve
o Business Aligned
o Quality
o Review Achievements
o Instigate Action
o Eradicate
o Continuous Improvement
10.2 Goals
Service Level Management is the process that manages and improves

agreed levels of service between two parties:
o The provider, who may be an internal department, for example

the IT department or building services, or an external outsourced
company or third party supplier.
o The receiver of the service, i.e. the customer who pays the bills.
Service Level Management ensures that the service targets are
documented and agreed in SLAs (Service Level Agreements)
Service Level Management monitors and reviews the actual service

levels achieved against their agreed SLA targets. Service Level
Management also plays a proactive role in the ongoing improvement of
the service levels within the imposed cost constraints.

10.3 Scope
The scope of SLM covers:
o Negotiating and agreeing service requirements with the

customer.
o Measuring and reporting of actuals against target, resources
require and cost of service.
o Continuously improving service lines in line with business
processes.
o Co-ordinating other Service Management functions and 3rd party
suppliers.
o Reviewing SLAs to meet changed business needs.
o Reviewing SLAs to resolve major service issues.
o Producing, reviewing and maintaining the Service Catalog
10.4 Benefits
The benefits of SLM are:
o Both parties have clear view of responsibilities and specific

service targets.
o Service monitoring and reviews will identify weak areas,
therefore enabling the provision of higher quality IT services.
o Prevent misunderstandings between customers and IT providers.
o SLM underpins Supplier Management, the SLAs are a key part in
managing the supplier relationships
o IT Services will be designed to meet the SLRs (Service Level
Requirements).
o SLAs can be used as a basis for charging and demonstrating to
the customer what they receive for their money!
o OLAs and support contracts with external suppliers are aligned
with the business services required

10.5 Process
The SLM process involves the following:
o Gain an understanding of the customer’s business processes and

drivers.
o Negotiate and agree service requirements and expected service
with customer and the IT Service provider.
o Produce and document a SLA that all parties agree to.
o Measure and report actuals against targets.
o Continuously look to improve the service lines in line with
changing business needs.
The SLM process creates a framework that disciplines both the

customer and the provider. SLM encourages the customer to consider,
document and define their real business needs.
SLM can make the provider more focused and accountable.
10.6 SLA Content
Typically the key elements of a Service Level Agreement are:
o General details (brief description, parties, signatories, date, and

version number).
o Service Hours.
o Service Availability (%) and reliability levels (MTBF).
o Support Levels.
o Functionality.
o Terminal Response Times.
o Throughput and batch turnaround times.
o Printing.
o Contingency and Security.
o Charging, Administration and review timetable.
o Glossary

10.7 Tools
An accurate monitoring tool is key to the content of the SLA. It is

important that metrics included in an SLA can be monitored.
If you can't monitor it, you can't report on it, therefore you can't
include it in your SLA ! SLM will rely on the tools utilized by other
support functions, for example Service Desk tool to provide incident
reports, Availability Management to provide availability % actuals,
Capacity Management for throughput information
10.8 Metrics
The metrics produced by SLM will be driven by each individual SLA. A

key output of the metrics is the continuous service improvement
program in line with the business processes and also the ability to
identify weak areas quickly.
10.9 Challenges
The SLM function face a number of challenges:
o Ensuring that targets are achievable before agreeing to

them, i.e. don't be over ambitious by trying to give the
customer what they want when you cant deliver.
o Don't be under ambitious, if you set targets that can be
easily achieved it may be seen as an excuse for a
reduction in service quality.
o Having the right monitoring tools in place to measure the
actual achievements, this will avoid disputes with the
customers.
o SLAs may not be supported by adequate underpinning
contracts.
o The content of the SLA may be too lengthy or not business
focused, therefore not used.
o SLM and other IT support functions do not fully understand
the business drivers or the need for the requested service
levels.
o Ensuring that adequate resources and time to support,
measure and report on the SLAs

11 Security Management
11.1 Mission
The mission of IT Security Management is:
“to manage information security effectively within all service
activities”
NOTE :
IT Security Management is not responsible for ensuring that

implementations of new IT Services are compliant – this is the
responsibility of the Availability manager to ensure security
requirements are clearly defined and incorporate into the solution.
11.2 Scope
o To ensure compliance with security requirements for new and

existing SLAs
o To meet external requirements that are not defined in contracts,
policies and legislation
o To provide a basic level of information relating to security to
information systems independent of external requirements
o To ensure that effective security measures are taken at
strategic, tactical and operations levels
11.3 Benefits
o Provide significant added value to information system

o Contributes to the continuity of the organization
o Assists the organization in meeting its objectives

11.4 Process
IT Security Management focuses on the following:
o Confidentiality
o Ensuring no unauthorized access to systems or data
o Integrity
o Ensures data / information is accurate and complete
o Availability
o Ensures authorized information is accessible
o Privacy
o Allowing owners of data/information to restrict access
o Verifiability
o Ensures data/information is only used for its intended
purpose
o Ensures security measures are effective
11.5 Relationships with other disciplines
IT Security Management has the following key relationships:
o Service Level Management
This relationship ensures that the services that are about to be

provided to customers are defined and achieved to include
sufficient security measures.
o Availability Management
In order to benefit from the various security measures, for example

confidentiality and integrity which can benefit system availability –
it is key that there is sufficient co-ordination between IT Security
Management, IT Service Continuity and Availability Management.
o Capacity Management
The majority of Capacity Management activities can affect

availability, this will also impact IT Security Management.
o IT Service Continuity Management
This is a key input to the SLA agreed with the customer. As security
is a key input to the Continuity plan agreed within the SLA this is an
important relationship.

11.6 Metrics
o # of security incidents recorded

o Type of security incidents recorded
o Impacts of security incidents
11.7 Challenges
o Peoples commitment to IT Security

o Peoples attitude
o Awareness throughout the organization
o Lack of systems to assist with IT Security (i.e. detection systems)

Organizations That Promote ITIL
The following are key organizations that promote and support the IT
Service Management philosophy and the importance of ITIL.
OGC
The OGC is the Office of Government and Commerce. The OGC

produce the IT Service Management volumes.
ITIL® is a Registered Trade Mark, and a Registered Community Trade

Mark of the Office of Government Commerce. IT Infrastructure
Library® is a Registered Trade Mark of the Office of Government
Commerce.
www.ogc.co.uk
www.itil.co.uk
TSO
TSO is the largest publisher in the UK by volume, publishing over

15,000 titles a year. The TSO are the publishing partner to the OGC. All
copies of ITIL books can be purchased from the TSO.
www.tso.co.uk/itil
www.tsoshop.co.uk
ISEB
It began its life as a single qualification, the NCC (National Computing

Centre) and BCS collaborated on developing the 'Certificate in Systems
Analysis and Design' for the Systems Analysis Examination Board. Due
to the development of further qualifications the Systems Analysis
Examination Board made the decision to change its name to ISEB.
The ISEB portfolio now offers a large number of IT qualifications in a
variety of disciplines.
ISEB qualifications add value to professional careers by providing both
the means and the platform for recognition and enhanced career
development.
www.bcs.org

EXIN
EXIN, the Examination Institute for Information Science, is a global,

independent IT examination provider.
EXIN is well-known worldwide for its ITIL certificates in IT Service

Management. With examinations like ITIL, ISO 20000/SQM, MOF, ASL,
DSDM, MOF and ISPL, EXIN plays an important role in the development
of international qualification standards. EXIN exams are available
in ten languages.
www.exin-exams.com
ITSMF
The itSMF is the only truly independent and internationally-recognized

forum for IT Service Management professionals worldwide. The itSMF is
a not-for-profit organization is a prominent player in the on-going
development and promotion of IT Service Management "best practice",
standards and qualifications and has been since 1991.
The itSMF provides an accessible network of industry experts,
information sources and events to help you and your staff address IT
service management issues and help you achieve the delivery of high
quality, consistent IT service internally and externally through the
adoption of "best practice".
The itSMF now boasts over 2500 member companies, blue chip and
public sector alike, and international itSMF Chapters
www.itsmf.com

THOMPSON PROMETRIC
Thomson Prometric is the recognized global leader in testing and

assessment services, providing paper-and-pencil, Internet and
computer-based testing solutions. It offers a fully integrated testing
system that includes test development, test delivery and data
management capabilities.
Since 2002, Thomson Prometric and EXIN have collaborated on the

delivery of the ITIL Foundation exams in English. As a result, EXIN can
improve the accessibility of EXIN's IT Service Management (ITIL) exams
for more candidates worldwide, and test them in the highly secure,
consistent Thomson Prometric Testing Center environment, while
providing candidates with improved flexibility in choosing both the test
date and location.
www.prometric.com

ITIL Foundation Guide

Uploaded by

Document Information

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

Uploaded by

Copyright:

Available Formats

IT Service Success

© 2006 IT Service Success 1

FOUNDATION STUDY GUIDE.............................................................................1

© 2006 IT Service Success 2

© 2006 IT Service Success 3

© 2006 IT Service Success 4

© 2006 IT Service Success 5

This guide will cover the following topics:

 What is Service Management and its importance

© 2006 IT Service Success 6

What is IT Service Management?

IT Service Management is designed to focus on the issues that IT

Whilst IT Service Management as a concept is related to ITIL it is not

IT Service Management within ITIL is the combination of the Service

© 2006 IT Service Success 7

© 2006 IT Service Success 8

Most IT-departments are event driven and operate in a reactive

There are a number of reasons why organizations choose to adopt ITIL?

• The existing resources are failing to meet the needs of the

ITIL as with other model frameworks can provide an excellent structure

© 2006 IT Service Success 9

© 2006 IT Service Success 10

The six volumes are:

The library is intended to assist organizations to provide high quality IT

Whilst the books offer guidance on the provision of quality IT services,

√ The books are the only comprehensive, publicly available

The collections of volumes are produced by the OGC – Office of

√ The books are best practice guidelines describing the ‘what’

© 2006 IT Service Success 11

These two areas are made up of 10 disciplines

© 2006 IT Service Success 12

The profitability and shareholder loyalty of an organization is

By improving the IT processes, the organization can begin to:

o Improve project deliverables and the time to deliver;

Some intangible Benefits of ITIL:

During the past decade, the reshaping of business functions as

There is a growing appreciation that IT is a key driver of business

In some cases, this has led to the formation of such organizational

© 2006 IT Service Success 13

A further consequence of the change has been to look at functionally

Other benefits include improved staff satisfaction as a result of clear

Additional benefits of adopting ITIL:

o Aligns IT services to present and future needs of the business

© 2006 IT Service Success 14

Function - Not A Process!

The IT Service Desk is not a core ITIL Process it is in fact a function.

Service Desks need to have quality procedures, training programs,

© 2006 IT Service Success 15

The goals of the Service Desk are to:

o Provide a single point of contact between users and IT Service

© 2006 IT Service Success 16

The Service Desk will provide a number of benefits:

o Ease of accessibility, a known contact point that is always

1.5 Understanding the customer / user

The Service Desk will ensure that they:

o Really know and understand the user community.

o Appropriate hours of coverage.

© 2006 IT Service Success 17

Staff considerations to include:

o Systems and service understanding, technical awareness and

There are three well known structures for a Service Desk:

A "Local" Service Desk will support local business needs. It should be

A "Central" Service Desk supports multiple locations and sometimes

A "Virtual" Service Desk operation is location independent. Sometimes