ISBN 0-9524706-1-6

9 780952 470618

£9.95 net
published in the UK by the
IT Service Management Forum Limited 1 1
 The IT Infrastructure Library
About This Guide

IT Service Management This pocket guide has been designed as a handy reference book for Information
Version 2.1.b Technology (IT) Service Management practitioners and for those taking the
Foundation Certificate in IT Service Management. It is a complementary
publication to the complete IT Infrastructure Library (ITIL), which is
Written by: Ivor Macfarlane discussed in more detail in the section on IT Service Management Best
Colin Rudd Practice.

Edited by: Derek Cambray

The guide explains the processes involved in the two key areas of Service
Management, and their application to the complete service life-cycle:
Published by: itSMF Ltd
Webbs Court
 Service Support
8 Holmes Road
Earley  Service Delivery
Reading RG6 7BH
United Kingdom The advice contained within the guide is neither definitive nor prescriptive, but
is a set of guidelines based on ITIL best practice. It is of benefit and is
Te l: +44 (0)118 926 0888 applicable to all IT organisations irrespective of size or the technology in use.
Fax: +44 (0)870 706 1531 The guidelines should be adapted and adopted to fit each organisation
e-mail: [email protected] individually, based on the organisations’:

 Business
© Copyright itSMF, 2001
This version first published March 2001  Culture
Minor updates published May 2002, October 2002 and May 2003  Structure
 Environment
Based on other copyright material with the permission of the copyright  Processes
owners. The itSMF would like to thank the contributors to an extensive
international quality review process for their comments. The IT Service Management pocket guide begins with, and reinforces, the key
message that IT services are there solely to support the business and its
ITIL® is a registered trademark of the Office of Government Commerce (OGC). efficient and effective operation.
© Crown copyright material reproduced with the kind permission of OGC and
the Controller of Her Majesty’s Stationery Office (HMSO).

ISBN 0-9524706-1-6
1 2
 Contents 1 The Philosophy of Service Management

About This Guide 2 The three key objectives of Service Management are:
Contents 3  To align IT services with the current and future needs of the business
1 The Philosophy of Service Management 4 and its Customers
2 IT Service Management Best Practice 5  To improve the quality of the IT services delivered
3 Implementing Service Management 8  To reduce the long-term cost of service provision.
4 Service Support Overview 10
IT has been widely utilised for decades but more recently the Internet has
5 Service Desk 11 demonstrated that for many modern e-business based organisations:
6 Incident Management 15
“IT is the business”
7 Problem Management 19 and
8 Configuration Management 23 “The business is IT”
9 Change Management 28 It is essential therefore to recognise the absolute dependence of most
10 Release Management 35 businesses upon the Information and Communications Technology (ICT)
infrastructure and the quantity, quality and the availability of the information
11 Service Delivery Overview 40
that such an infrastructure provides and supports.
12 Service Level Management 41
The challenges facing the IT Managers of today are to co-ordinate and work in
13 Financial Management for IT Services 46
partnership with the business to create new business opportunities. This has
14 Capacity Management 52 to be achieved while reducing the Total Cost of Ownership (TCO). The main
15 IT Service Continuity Management 58 method of realising this goal is the reduction of the overall management and
16 Availability Management 64 support costs, while developing new business models to maintain or improve
the quality of service delivered to the business. In order to do this the correct
17 The Importance of Communication 69
business and IT processes need to be developed and implemented. The
18 Further Guidance and Contact Points 70 management of IT is all about the efficient and effective use of the three P’s:
people, processes and products (tools and technology).
The ITIL philosophy adopts a process driven approach which is scaleable to fit
both large and small IT organisations. It considers Service Management to
consist of a number of closely related and highly integrated processes. To
realise the key objectives of Service Management these processes must use the
people and the products effectively, efficiently and economically in the delivery
of high quality, innovative IT services aligned to business processes.

3 4
 ITIL Service Management
2 IT Service Management Best Practice Service Management processes are at the heart of ITIL and are considered as
two core areas:

Best practice in IT Service Management has evolved since 1989, which saw the Service Support Service Delivery
publication of the first elements of the IT Infrastructure Library (ITIL) by the Service Desk*
UK Government’s Central Computer and Telecommunications Agency
(CCTA), (now the Office of Government Commerce (OGC)). Incident Management Service Level Management

Available best practice now comprises integrated guidance from OGC and the Problem Management Financial Management for IT Services
British Standards Institution (BSI). Its use is supported by a qualification and Configuration Management Capacity Management
training structure that has been adopted world-wide to recognise professional
Change Management IT Service Continuity Management
competence in IT Service Management.
Release Management Availability Management
The written guidance ranges from detailed advice on each process within ITIL,
through the DISC-PD0005 Code of Practice to the formal BS15000 standard,
* Note that Service Desk is a function not a process.
specifying required practices for organisations.
The following diagram illustrates the need for generic guidance, such as that
Service Support generally concentrates on the day-to-day operation and
from ITIL and BSI. This guidance should be supported by an organisation’s
support of IT services while Service Delivery looks at the long term planning
own internal processes and procedures.
and improvement of IT service provision.

BSI5000 Key Definitions

Achieve This
DISC PD0015 Standard
Workbook Customer: recipient of a service; usually the Customer management
Management
DISC PD0005
Overview has responsibility for the funding of the service.
Code of Practice
Process Provider: the unit responsible for the provision of IT services.
OGC
Questionnaires ITIL Definition
Supplier: a third party responsible for supplying or supporting
Internal Processes Deployed underpinning elements of the IT services.
Solution
and Procedures
User: the person using the service on a daily basis.
Figure 1: Guidance and Standards

5 6
 Publications

Within ITIL, a major re-write exercise has been undertaken in order to 3 Implementing Service Management
consolidate and bring the material up to date, eliminate duplication, and
enhance navigation. The result is a series of publications within a defined
framework. Organisations should not be over ambitious when implementing Service
Management. Most will already have elements established and in operation.
Therefore, the Service Management implementation activity is actually one of
process improvement.

Where do we Vision and

want to be? business objectives

Where are Assessments

we now?

How do we get where Process improvement

we want to be? or re-engineering

Figure 2: The ITIL Publication Framework How do we know Metrics &

we have arrived? Measurements

Best practice guidance and detailed information on the processes themselves

can be found in the appropriate sections of the Service Support and Service
Delivery books. This pocket guide summarises the main elements from these Figure 3: Process Improvement Model
publications.
The complete range of ITIL and BSI publications are available from the IT Tools to assist with assessment and planning are available including self-
Service Management Forum (itSMF). See Section 18 Further Information and assessment products such as BSI’s workbook: PD0015.
Contact Points.
Service Management processes can be implemented consecutively or
simultaneously and each process can be broken down into a series of activities.

7 8
 Overall process improvement is an iterative activity and would normally
consist of the following stages: 4 Service Support Overview
 Process Improvement Definition
- Reviewing where we are now
- Defining the mission statement The following diagram illustrates the major interfaces and deliverables within
- Setting goals and objectives the Service Support processes:
- Defining roles and responsibilities. Business, Customers and Users
 Communication
- Raising the awareness
Management Incidents Communication
- Publishing and circulating information Tools
Queries Updates
Enquiries
- Seminars, briefings and workshops. Work-arounds
 Planning
Incidents Incidents Service
- Producing statement of requirements Desk Changes
- Designing the process improvements Incident
Management Customer
- Producing the plan Survey Releases
Reports
- Identifying resources and defining the training Problem
Management
- Completing a cost / benefit analysis
- Obtaining management commitment. Service reports
Incident statistics Change
 Implementation Audit reports Management
- Developing and improving the processes Problem statistics
Trend analysis Release
- Implementing the plan with reviews and reports Problem reports Management
- Developing and customising the tools Problem reviews Change schedule
Diagnostic aids CAB minutes Configuration
- Training IT staff, Customers, and Users Audit reports Change statistics Management
- Producing documentation, procedures, and deliverables Change reviews
Audit reports Release schedule
- Testing Release statistics
Release reviews
- Measurement and reporting of metrics. Secure library CMDB reports
 Review and Audit Testing standards CMDB statistics
Audit reports Policy/standards
- Review and comparison of actual achievements with Audit reports
goals and objectives
- Post implementation project review
- Identifying and publicising the benefits
- Reviewing for effectiveness and efficiency
- Auditing for compliance Incidents Problems Changes Releases CIs
- Monitoring, reviewing and developing future improvements. Known Errors Relationships
CMDB
Figure 4: The Service Support Processes
9 10
 Responsibilities
5 Service Desk Most of the activities carried out by the Service Desk fall under the
responsibility of one of the IT Service Management processes. The role and
responsibilities of the Service Desk will depend upon the arrangements that
Goal the organisation has put in place. Among the tasks commonly assigned to the
Service Desk are:
To act as the central point of contact between the User and IT Service
Management. To handle Incidents and requests, and provide an interface for  Receive and record all calls from Users; deal directly with simple
requests and complaints
other activities such as Change, Problem, Configuration, Release, Service
Level, and IT Service Continuity Management.  Provide initial assessment of all Incidents; make first attempt at Incident
resolution and/or refer to 2nd line support, based on agreed service levels
Why a Service Desk?

The Service Desk, unlike other disciplines (processes) described in this book,  Monitor and escalate all Incidents according to agreed service levels
is a function essential to effective Service Management. More than just a Help  Keep Users informed on status and progress
Desk, it is the principal operational interface between IT and their Users. A
 Produce management reports.
good first impression by each of its Users is predicated upon its performance
and attitude. Often a stressful place for staff to work, underestimating its
importance, high profile, and the skills required to perform the duties well, can
Telephone Fax
severely hinder an organisation’s ability to deliver quality IT services. requests requests
The change of name from Help Desk to Service Desk demonstrates the
broader role of front line support - with more organisations looking to radically Email/voice/ Internet/ Hardware/
video browser application
increase the percentage of calls closed at first point of contact. requests requests events
The principal reasons for an organisation to invest in a Service Desk are:

 To provide a single point of contact for Users

 To deliver the high quality support critical for achieving business goals MANAGEMENT
SERVICE DESK INFORMATION
 To help identify and lower the cost of ownership for IT services as a whole
 To support Changes across business, technology and process boundaries
 To aid User retention and satisfaction
External Product Sales & Contact Internal
 To assist identification of business opportunities. service support marketing support service
support support

Figure 5: Incident Registration Inputs

11 12
 Key Considerations
Types of Service Desk
User Interaction
Three types of Service Desk structure should be considered
Expanding reporting and communication methods beyond telephone contact, in establishing the optimum set-up:
such as Internet and Intranet, email and fax, can enhance service. The Service
 Local Service Desk
Desk still provides the main communication between the User and the IT
services and:  Central Service desk
 Virtual Service Desk.
 Represents the service provider to the User
 Considers User satisfaction and perception as critical
 Depends on the right mix of people, processes, and technology to Benefits
deliver a business service.  Improved User service, perception and satisfaction
Setting up a Service Desk
 Increased User accessibility via the single point of contact
A correct Service Desk infrastructure is critical to success, and requires clear  Improved quality and faster response to User requests
ownership, defined business goals, responsibilities, deliverables, and
management commitment. The following actions need to be carried out when  Improved teamwork and communication
setting up a Service Desk:  Better managed infrastructure and control
 Ensure the business need is identified and understood  More effective and efficient use of support resources
 Obtain management support, budget and resources  Better management information for better decision support.
 Ensure the solution aligns with the service strategy Possible Problems
 Identify, achieve and communicate quick wins  User service not considered a priority
 Define clear objectives and deliverables  Lack of management commitment
 Start simply and phase the implementation  Resistance to changed working practices
 Involve and educate Users  Incorrect or insufficient resources and skill levels
 Advertise and ‘sell’ the benefits to all parties  Insufficient or inadequate marketing of Service Desk
 Train IT staff to be Service staff.  Over reliance on technology
Service Desk Technologies  Insufficient funding and budget allocation.
A number of technologies are available to assist the Service Desk. However,
remember that technology should be used to complement and enhance the
service, not replace it. The technology must support correct business processes,
adapting to both current and future demands. It is also important to understand
that automation requires an increased need for discipline and accountability.
13 14
 6 Incident Management Incident detecting
& recording

Goal
Initial classification
To restore normal service operation as quickly as possible with minimum & support
disruption to the business, thus ensuring that the best achievable levels of

Ownership, monitoring, tracking and communication

availability and service are maintained.
Why Incident Management?
Service Yes Service request
 To ensure the best use of resources to support the business request
procedure
 To develop and maintain meaningful records relating to Incidents
 To devise and apply a consistent approach to all Incidents reported. No

Investigation
Incident Definition & diagnosis
An Incident is any event which is not part of the standard operation
of a service and which causes, or may cause, an interruption to, or a
reduction in the quality of that service.

Resolution
Examples of Incidents are: & recovery

 Application unavailable or in error

 Hardware outage or constrained use Incident
closure
 Service Requests for information or assistance (e.g. a service extension).
Responsibilities
Figure 6: The Incident Life-cycle
 Incident detection and recording
 Classification of all Incidents, and initial support
 Investigation and diagnosis Role of the Service Desk in Incident Management

 Resolution and recovery The Service Desk will usually play the key role in the Incident
Management process, recording and monitoring the progress of
 Incident closure Incidents and retaining ownership of them.
 Incident ownership, monitoring, tracking and communication.

15 16
 Key Considerations
Handling of Major Incidents
Critical Success Factors for Incident Management
Major Incidents occur when there is an extreme impact on the User
 An up-to-date Configuration Management database (CMDB) community, or where the disruption is excessive. Problem
Management must be notified and should arrange a formal meeting
 A ‘knowledge base’ recording Problems and Known Error data, of people who might help. The Service Desk should ensure that a
record of actions and decisions is maintained in the Incident Record.
resolutions and workarounds

 Availability of effective automated support tools

Benefits
 Close links with effective Service Level Management.
 Reduced business impact of Incidents by timely resolution
Prioritisation
 Proactive identification of beneficial enhancements
Urgency is an assessment of the speed with which an Incident needs resolution.
 Availability of business focused information related to the Service Level
Impact reflects the likely effect the Incident will have upon the business service. Agreement (SLA)
The Priority for allocating resources to resolution of an Incident is based upon  Improved monitoring of performance against SLAs
a combination of impact and urgency, together with other relevant factors such
 Better staff utilisation leading to greater efficiency
as availability of resources.
 Elimination of lost Incidents and Service Requests
Relationship between Incidents, Problems and Known Errors

Where the cause of an Incident is not identifiable then, if investigation is  More accurate CMDB information enabling an ongoing audit while
warranted a Problem record is raised. A Problem represents an unknown error registering Incidents
in one or more Configuration Items. Once the underlying cause and a  Improved User satisfaction
workaround or correction via a Request for Change (RFC) is identified it then
 Less disruption to both IT support staff and Users.
becomes a Known Error record. Details of relationships between Incidents,
Problems, Known Errors and RFCs are held within a CMDB. Possible Problems

Known Structural  Lack of management commitment

Incident Error Resolution
 Lack of agreed Customer service levels
Error in Problem RFC
Infrastructure  Lack of knowledge or resources for resolving Incidents
 Poorly integrated or missing related processes or functions
Figure 7: Logical Flow from Error to Resolution
 Lack, unsuitability, or high cost, of software tools
Newly recorded Incidents will be matched against the database of existing
 Users and IT staff bypassing the process.
Incidents, Problems, and Known Errors. Available workarounds will be
applied to enable speedy resolution of Incidents. This knowledge base needs to
be maintained so that only relevant records are presented to the Service Desk.

17 18
  Assistance with the handling of major Incidents
7 Problem Management  Proactive prevention of Problems
- Trend analysis
- Targeting support action
Goal - Providing information to the organisation
To minimise the adverse effect on the business of Incidents and Problems  Obtaining management information from Problem data
caused by errors in the infrastructure, and to proactively prevent the  Completing major Problem reviews.
occurrence of Incidents, Problems, and errors.
Why Problem Management? Problem Control v. Error Control

 To resolve Problems quickly and effectively Problem control focuses on transforming Problems into Known
Errors. Error control focuses on resolving Known Errors via the
 To ensure resources are prioritised to resolve Problems in the most
Change Management process.
appropriate order based on business need
 To proactively identify and resolve Problems and Known Errors thus
minimising Incident occurrences Key Considerations
Errors from the Development Environment
 To improve the productivity of support staff
 To provide relevant management information. Errors in software released into the live environment should be incorporated
into the Known Error database for live services.
Problems and Known Errors
Live Applications
A Problem is the unknown underlying cause of one or more operations Release development &
maintenance
Incidents. It will become a Known Error when the root cause is
known and a temporary workaround or a permanent alternative has
been identified. Problems
Live
Known
Development Problems
Known
Error Error
database database
Responsibilities
Investigation Investigation
 Problem control & diagnosis & diagnosis
- Problem identification and recording
- Problem classification
- Problem investigation and diagnosis.
Requests
 Error control for Change
- Error identification and recording
- Error assessment Change
- Recording error resolution Management

- Error closure
- Monitoring resolution progress Figure 8: Errors in the Live and Development Life-cycles
19 20
 Incident and Problem Management differences
Incident
alert
The Incident and Problem Management processes have different imperatives.
Incident Management is concerned with restoring the service to the business
User as quickly as possible. Problem Management is concerned with
establishing the underlying causes of an Incident, and their subsequent
Assess Incident
Inform customer/ Routine and follow resolution and prevention. These goals can sometimes result in conflicting
user of Incident? routine procedures
Yes priorities.
workaround
Timing and Planning
No
Update Incident Update Incident
 Good Problem Management relies on an efficient Incident Management
count on Known
Match count on Problem process, so implement in parallel or immediately after Incident Management
Error record record
on Known Error
Yes DB?  If resources are scarce concentrate on Problem and Error Control
(reactive), and leave proactive Problem Management until later,
Update Incident Update Incident after service monitoring activities are in place and base data is captured
No
record with ID record with ID
of Known Error of Problem  Focus on a few key Problems that are causing the greatest pain to
Match the business - experience shows that 20% of Problems cause 80% of
on Problem
DB? Yes service degradation!
Update Incident Update Incident Benefits
record with record with
No
classification data classification data  Improved IT services
Raise new record  Incident volume reduction
on Problem DB
Extract resolution or Extract resolution or  Permanent solutions
circumvention from circumvention action
Known Error DB
New Problem
from Problem DB  Improved organisational learning
alert
 Improved Service Desk first-time fix rate.
Possible Problems

Support Allocate to Support  Absence of good Incident control process

required? Problem required?
Yes Yes
Management team  Lack of management commitment

No No  Undermining of the Service Desk role

Process
Incident/  Insufficient time and resources to build and maintain the knowledge base
Execute Problem Execute
resolution action resolution action  Inability to accurately assess business impact of Incidents and Problems.

Figure 9: IT Incident Matching Process

21 22
 Control

8 Configuration Management Assurance that only authorised and identifiable CIs are accepted and recorded
from receipt to disposal. It ensures that no CI is added, modified, replaced, or
removed without appropriate controlling documentation, e.g. approved RFC,
Goal updated specification. All CIs will be under Change Management control.

To provide a logical model of the IT infrastructure by identifying, controlling, Status Accounting

maintaining and verifying the versions of all Configuration Items in existence. The reporting of all current and historical data concerned with each CI
Why Configuration Management? throughout its life-cycle. It enables changes to CIs and tracking of their records
through various statuses, e.g. ordered, received, under test, live, under repair,
 To account for all IT assets
withdrawn, or for disposal.
 To provide accurate information to support other Service Management processes
Verification and Audit
 To provide a sound basis for Incident, Problem, Change and Release Management A series of reviews and audits that verifies the physical existence of CIs, and
 To verify records against infrastructure and to correct exceptions. checks that they are correctly recorded in the CMDB. It includes the process
of verifying Release and Configuration documentation before changes are
Responsibilities
made to the live environment.
There are five basic activities of Configuration Management.
Planning Level of Control

The Configuration Management plan should cover the next three to six  Identifying critical services and their components is a sensible
months in detail and the following twelve months in outline. It should be starting point for Configuration Management
reviewed at least twice a year and will include:  Although low-level detail may be required in part of the
structure, it may not be needed throughout
 Strategy, policy, scope, objectives, roles and responsibilities  Reviewing data levels and Configuration (CMDB) clean-up
exercises can help
 Configuration Management processes, activities, and procedures
 Target maximum control with minimum records.
 CMDB, relationships with other processes and third parties
 Tools and other resource requirements.
Key Considerations
Identification
Configuration Management Database
The selection, identification, and labelling of all Configuration Items (CIs). It
All detail and relationship information about CIs should be held in a single
covers recording information about CIs, including ownership, relationships,
place, the Configuration Management Database (CMDB). This single
versions, and identifiers. CIs should be recorded at a level of detail justified by
repository of information will be accessed across the Service Management
the business need - typically to the level of “independent change”.
processes and is a major driver of consistency between the processes.

23 24
 Relationships to other Processes Definitive Software Library (DSL)

Configuration Management is closely linked with the overall Service Support The Definitive Software Library is where the authorised versions of all
and Service Delivery processes, both supporting and depending upon those software CIs are stored and protected. It will comprise a single logical (but
processes. If those other processes are not already in existence they should be probably, physically multiple) filestore for developed software and a secure
planned alongside Configuration Management. physical store holding bought-in software.
(See also Release Management.)
Start Relationship to Asset Management

Configuration Management is not synonymous with Asset Management,

Incident which maintains details on assets, usually above a set value. Configuration
Management maintains not only relevant information on the assets themselves

Configuration Management Data Base

Problem but also information about relationships between assets.

Known error Setting up Configuration Management

CMDB
The planning process for setting up an appropriate function could
Request
for change take up to 6 months from inception to first phase of implementation.
Actual implementation may take much longer, but the benefits of
Change authorised Configuration Management should outweigh the costs.

Change tested implemented

& released Benefits

End
 Provides accurate information on CIs and their documentation
to support all other IT Service Management processes
 Facilitates adherence to legal and contractual obligations
Figure 10: CMDB Interfaces to Service Support Processes
 Helps with financial planning through clear identification of all
Configuration Baseline
assets and associations between them

A baseline is the configuration of a product or system established at a specific  Makes software changes visible and supports and improves Release
Management
point in time, and capturing both structure and details. It can be created as a:
 Improves security by controlling the versions of CIs in use, and enables
 Sound basis for future work
the organisation to reduce the use of unauthorised software
 Record of CIs affected and actually changed by an RFC
 Facilitates impact and trend analysis for Changes and Problems.
 A point to fall back to if (or when) things go wrong.

25 26
 Possible Problems

 CIs defined at too high or too low a level 9 Change Management

 Implementation without sufficient analysis and design of the process,
database and procedures, or without sufficient project planning
Goal
 Schedules or expectations that are over-ambitious
To ensure that standardised methods and procedures are used for efficient and
 Lack of management commitment
prompt handling of all Changes, in order to minimise the impact of any related
 Support tool lacks the required flexibility Incidents upon service.
 Process is circumvented, perceived as bureaucratic and/or is error prone Why Change Management?
 Implemented in isolation, without necessary support from Change and Changes within the IT infrastructure may arise reactively in response to
Release processes
Problems or externally imposed requirements, e.g. legislative changes, or
 Scope too wide or too narrow proactively from seeking improved efficiency and effectiveness or to enable or
 Not linked into application or project life-cycle. reflect business initiatives, or from programmes, projects, or service
improvement initiatives. Change Management can:
 Ensure standardised methods, processes and procedures are used for all
Changes
 Facilitate efficient and prompt handling of all Changes
 Maintain the proper balance between the need for Change and the
potential detrimental impact of Changes.
Responsibilities

Change Management is responsible for controlling Change to all CIs within

the live environment. It is not responsible for change within ongoing projects,
which are controlled by the project change process. However close liaison
between development project managers and the Change Manager is expected.
Change Management would typically comprise:

 Raising and recording Changes

 Assessing the impact, cost, benefit, and risk of proposed Changes
 Developing business justification and obtaining approval
 Managing and co-ordinating Change implementation
 Monitoring and reporting on the implementation
 Reviewing and closing Requests for Change (RFCs).

27 28
 Start Change Initiators
From figure 11
Reject

Change builder Configuration manager

Configuration manager Builds Change, devises
Change manager Updates log with
back-out & testing plans progress reports
Initial logging of RFC
Filters requests

Independent tester
Configuration manager
Change manager Tests Change
Updates log
Allocates initial priority
No Configuration manager
Success?
Updates log
Yes Yes
Urgent? To figure 13
Change manager Configuration manager
No Co-ordinates Change Informs users,
Change manager Implementation updates log
Implement Change
Decide category using appropriate
(initial impact/resource Change builder
estimate) and/or use of Standard Change model
No
standard model Working? Back-out plans
implemented
Yes
minor significant major
Configuration manager
Change manager Change manager Change manager
Approves/rejects and Updates log
Circulates RFC’s to Circulates RFC’s to Elapsed time
schedules Changes, CAB Members Board Members
reports action to CAB

CAB members Change manager

Senior management/
Confirm Board level
Change review
impact/resource Approve/reject
estimate & priority. Changes.
Approve/reject Configuration manager
May be (Financial/Technical/
Changes. Schedule Business) No
iterative Changes To Start, Updates log, associates any
Success? figure 11 new RFC with old one
May be
iterative
No
Approved? Configuration manager Yes Configuration manager
Updates log, issues Closed Closes RFC in log
Yes forward schedule
To figure 12

Figure 11: Change Procedures - Part 1 (normal)

Figure 12: Change Procedures - Part 2 (normal)
29 30
 From figure 11
Key Considerations
Elapsed Configuration manager See
Change Advisory Board
time fig. 11
Initial logging of RFC
Change manager The Change Advisory Board (CAB) considers RFCs, and in the light of the
Calls CAB or business need makes recommendations as to whether they should be accepted
CAB/EC meeting and implemented, or rejected. Recommendations are based upon the impact on
Elapsed existing services, the cost of the Change, and other relevant factors. The CAB
CAB or CAB/EC time members are chosen to ensure all Changes can be adequately assessed from
Quickly assesses impact No
To start, figure 11
both the business and technical viewpoint. The CAB members are likely to
resources and urgency Approved?
include (dependent upon the agenda):
Yes
 Change Manager, chairing the process
No Time Change Builder Elapsed Configuration manager
for test? Urgently prepares time  Relevant IT services staff
Updates log
Change
Yes
progresses report  Suppliers, maintainers and developers
No
Independent tester Configuration manager  Customers and Users
Elapsed
Urgent testing Success?
time Updates log  Office services and other non-IT supporting services
Change manager  Experts/technical consultants.
Co-ordinates Change Yes Configuration manager
Elapsed Face to face meetings are not always used; some CAB work takes place using
implementation Updates log,
time informs users electronic communications. However occasional regular meetings, e.g. twice
No Change manager yearly, can help to maintain the good working relationships upon which
Working? Elapsed
Back-out plans
time effective Change assessment depends.
implemented
Yes
When urgent major problems arise there may not be time to convene the full
Configuration manager CAB. For these cases a CAB/EC (Emergency Committee) should be identified
Change manager
Ensures records are Updates log, with all with authority to make emergency decisions. Membership of the CAB/EC
brought up to date details to date. Sets may vary depending upon the different criteria relating to particular problems.
documentation in order
Elapsed
Change Procedures
time
Change manager The preceeding flowcharts illustrate the normal and urgent Change processes.
Review Change Where the business impact justifies it a Change should proceed via the urgent
path indicated in the flowcharts. This allows for ‘fast tracking’ of the process
Yes Configuration manager
with respect to approval channels, testing, and documentation. Urgent
Success? Close Closes RFC in log
Change procedures must not be viewed as an optional route to faster
No implementation since they carry considerably greater risks than normal
To Start, figure 11 Change procedures. The urgent procedure is typically used for emergency
Problem resolution.
Figure 13: Change Procedures - Part 3 (urgent)
31 32
 Standard Changes Possible Problems

A standard change is an accepted solution to an identifiable and relatively  Scope incorrectly set, e.g. over-stretching staff, Changes not aligned to
common set of requirements, where authority is effectively given in advance of project life-cycle, or inability to address all aspects of Change
implementation, e.g. setting up access profiles for a new employee.
 Lack of ownership and knowledge of impacted systems making impact
Change Models assessment impossible
Modern tools permit the use of sophisticated Change models that can and  Staff resistance to a process perceived as too bureaucratic
should be used to ensure the consistent implementation of common types of
changes, both major and minor, e.g. upgrade of a standard desktop software  Lack of visible management commitment and support to enforce the
product. process

 Lack of control over urgent Changes

Integration with Project Management
 Lack of an accurate CMDB.
Change Management should be integrated with the management of
large organisational programs or projects, through planning,
building, testing and implementation.

Benefits

 Better alignment of IT services to the actual business need

 Increased visibility and communication of changes to both business

and service support staff

 Reduced adverse impact of change on the IT service from improved

business and technical impact and risk assessment

 Better assessment of the cost of proposed Changes before they are

incurred

 Improved Problem, Supplier, and Availability Management through the

use of valuable management information relating to Changes

 Improved productivity of Users through less disruption and higher

quality services

 Improved productivity of key IT personnel, due to less distraction to

repair faulty Changes

 Greater ability to absorb a large volume of Changes.

33 34
 10 Release Management Development
Environment
Controlled Test Environment Live
Environment

Goal

To take an holistic view of a Change to an IT service and ensure that all aspects Release Management
of a Release, both technical and non-technical, are considered together. Release Release Develop Build & Fit for Release Roll-out Communication Distribution
policy planning or buy configure purpose acceptance planning preparation and
Why Release Management software release testing and training installation

Release Management should be used for:

 Large or critical hardware roll-outs
 Major software roll-outs
 Bundling or batching related sets of Changes.
Release Management co-ordinates the many service providers and suppliers
involved with a significant Release of hardware, software and associated Configuration Management Data Base (CMDB)
documentation across a distributed environment. and
Definitive Software Library (DSL)
Responsibilities
 Planning and overseeing the successful roll-out of new and changed
software and associated hardware and documentation Figure 14: Major Activities of Release Management

 Liaison with Change Management to agree the exact content and roll-
out plan for the Release Key Considerations

 Ensuring that all items being rolled out or changed are secure and Types of Release
traceable via the CMDB Full Release: all components of the Release are built, tested, distributed and
 Managing Customers and Users expectations of Releases and roll-outs. implemented together.
Delta Release: only those CIs that have actually changed since the last
Release Policy
Release are included.
Package Release: individual Releases, both full and delta, are grouped
A Release policy document should be produced to clarify the roles
together to form a package for Release.
and responsibilities for Release Management. There may be one
document per organisation, or an umbrella set of guidelines and Definitive Software Library (DSL)

specific details for each supported system or IT service. The DSL contains the master copies of all controlled software in an
organisation, including purchased software as well as software developed on-
site. The exact configuration of the DSL that is required for Release
Management should be defined before development commences.
35 36
 The following should be considered: Build Management

 Media The software and/or hardware components that comprise a new Release
should be assembled in a controlled manner to ensure a reproducible process.
 Naming conventions
It is quite common to automate the build process to reduce the reliance on
 Environments supported human intervention and so make it more reliable. Build management becomes
 Security arrangements the responsibility of Release Management from the controlled test
environment onwards.
 Scope
Testing and Back-out Plans
 Retention period
 Audit procedures. Releases should undergo stringent testing and User acceptance before release.
Back-out plans, to document the consequent action should a Release fail,
The CMDB should be updated and referred to throughout the Release wholly or partly, must exist. The back-out plans should be tested as a part of
Management process, concurrently with updates to the DSL. the overall Release testing process.
Change, Configuration, and Release Management
Physical CIs Information about CIs
A central function for Change, Configuration and Release Management offers
CMDB considerable advantages. Without Change Management, Configuration
DSL information will rapidly become inaccurate, without accurate Configuration
data, Change impacts are not accurately assessable, and without
Configuration and Change Management, Releases will not be controllable.
A recommended approach is to have a single Change and Configuration
Management and Release Plan that addresses:
Release Record

 Combined roles and responsibilities

Build new release
Test  Nature of the CMDB, DSL, and DHS together with associated tool and
new release library requirements
Distribute new release
to live locations Implement  Change, Configuration and Release Management procedures as they
new release relate to each other.
Figure 15: DSL and CMDB role in Release Management
Definitions

Definitive Hardware Store (DHS) Release: a collection of authorised Changes to an IT Service.

Release Unit: the portion of the IT infrastructure that is normally
An area should be set aside for the secure storage of definitive hardware spares.
released together.
Spares should be maintained at the same level as the live location, and their
Roll-out: deliver, install and commission an integrated set of
details recorded in the CMDB.
new or changed CIs across logical or physical parts
of an organisation.

37 38
 Benefits

When combined with Configuration Management, Change Management and 11 Service Delivery Overview
operational testing, Release Management can deliver:

 Improved service quality as a result of a greater success rate for

Releases and minimisation of disruption to the business The following diagram illustrates the major interfaces and deliverables within
the Service Delivery processes:
 Assurance that hardware and software in live use is of known
quality, reducing the chance of illegal, wrong, or unauthorised software
being in use Business, Customers and Users
 Better use of resources, either User, testing, or development
Queries Communication
 Greater ability of the organisation to cope with high levels of Change Enquiries Updates
Reports
 Better expectation setting for business and service support staff.
Service Level
Possible Problems Management
SLAs, SLRs,
 Resistance from staff to new procedures Requirements
OLAs
Availability Service reports
Targets
 Circumvention or inappropriate use of ‘urgent’ procedures Management
Achievements
Service Catalogue
SIP
Exception reports
 Unclear ownership and role acceptance between operational and Audit reports
development staff Availability Plan
Capacity
Design criteria Management
 Inadequate building and testing of Releases, due to insufficient Targets/Thresholds
Reports
hardware resources Audit reports Financial
Capacity Plan Management
CDB for IT Services
 Inability to recreate all possible environments Targets/Thresholds
Capacity Reports Financial Plan
 Lack of understanding of the full contents of a Release or pressure to Schedules Types & models
Audit reports Costs & Charges
roll-out before a Release is fully prepared Reports IT Service
Budgets & Forecasts Continuity
 Reluctance to back-out a failing Release. Audit reports
Management

IT Continuity Plans
BIA & Risk Analysis
Alerts and Control centres
Exceptions DR contracts
Changes Reports
Audit reports

Management
Tools & IT
Infrastructure

Figure 16: The Service Delivery Processes

39 40
  Reviewing SLAs to meet changed business needs or resolving major
12 Service Level Management service issues
 Producing, reviewing and maintaining the Service Catalogue.

Goal
Service Catalogue
To maintain and gradually improve business aligned IT service quality, Service Level Management will document the services provided to the
through a constant cycle of agreeing, monitoring, reporting and reviewing IT Customers, detailing the key features of those services, preferably
service achievements and through instigating actions to eradicate within the CMDB. This catalogue will form the basis for an
understanding of all the services offered, their components, features,
unacceptable levels of service. charges, etc.
Why Service Level Management? There may well be the need for a version of the Service Catalogue
aimed at Customers, as well as one holding more supplier-related
Service Level Management (SLM) ensures that the service targets are
information.
documented and agreed in Service Level Agreements (SLAs) and monitors and
reviews the actual service levels achieved against their SLA targets. SLM
should also be trying to proactively improve all service levels within the Key Considerations
imposed cost constraints.
Customer Focus
Service Level Management is the process that manages and improves agreed
levels of service between two parties: The Service Level Management process encourages both Provider and
Customer to realise that they have joint responsibility for the service.
 The provider, who may be an internal service department (e.g., Typically this generates:
engineering, computer department, building services), or an external
outsourcing company or third party supplier  An understanding of the Customer’s business processes and drivers
 The receiver of the service, i.e. the Customer who pays the bills.  An acceptance of the benefits of early discussions of expected changes
to workload volumes or the nature of the service
Responsibilities
 Constructive discussions on better ways of meeting the Customers’
 Negotiating and agreeing service requirements and expected service needs and of transforming business processes.
characteristics with the Customer
 Measuring and reporting of: The SLM Process

- Service Levels actually being achieved against target The SLM process creates a management framework that disciplines
- Resources required both the Provider and the Customer. SLM encourages the Customer
- Cost of service provision to consider, document and define their real business needs. SLM
generally makes the Provider more focused and accountable. By
 Continuously improving service levels in line with business processes, including the cost of the IT services in the measurements, the SLM
with a Service Improvement Programme (SIP) processes can also help improve the cost effectiveness of the services.
 Co-ordinating other Service Management and support functions,
including third party suppliers

41 42
 Content of Service Level Agreements Underpinning Contracts

As a minimum, a Service Level Agreement should include: It is important to ensure that all targets contained within both SLAs and OLAs
 A simple description of the service and the deliverables that rely on external suppliers, are underpinned by the appropriate level of
maintenance and support contracts, and are documented and agreed within
 The agreed service hours
such contracts.
 User response times, Incident response times and resolution times, and
response times to Changes
Service Level Agreement(s)
 Service availability, security and continuity targets
 Customer and Provider responsibilities Service B
Service A Service C
 Critical business periods and exceptions, (holidays, escalation, etc.). IT Service
Provider
All targets contained within an SLA should be capable of being monitored and IT Infrastructure

measured.
When the service is being provided to an external Customer the SLA will normally Operational Level Agreement(s) Contract(s)

supplement a contract that will define the minimum acceptable level of service.
Internal Organisation(s) External Organisation(s)
Structure of Service Level Agreements
Figure 17: SLA, OLA and Contract Support Structure
Some organisations have chosen to adopt a multiple level SLA structure. One
example of a three-layer structure might be as follows: Service Improvement Programme

 Corporate Level: covering all the generic SLM issues appropriate to SLAs generally concentrate on the quality of service that will be delivered in
every Customer throughout the organisation (such as response the next twelve months. In rapidly changing environments a Service
times when calling the Service Desk)
Improvement Programme (SIP) should be produced to demonstrate to the
 Customer Level: covering all SLM issues relevant to the particular Customers the steps that will be taken to improve the service in the next
Customer group, regardless of the service being used. revision of the SLA.
 Service Level: covering all SLM issues relevant to the specific service, in
relation to a specific Customer group (1 for each service covered by the SLA). Beyond SLAs

Operational Level Agreements (OLAs) Many organisations consider SLM to consist purely of the creation of
SLAs that are then promptly forgotten about. In reality a SLA is a
OLAs are also known as ‘back-to-back’ agreements. They define support means to an end, a mechanism for the management of a relationship,
requirements internally. The most common use of an OLA is to define the between Customer and Provider, for mutual benefit.
relationship between the Service Desk and internal support groups. The true benefits of Service Level Management will come only when
both parties see the benefits of their active involvement in the whole
OLAs are required to ensure that the SLA targets agreed between Customer process.
and Provider can be delivered in practice. OLAs describe each of the separate
components of the overall service delivered to the Customer, often with one
OLA for each support group and a contract for each supplier. OLAs or SLAs
may be agreed with external suppliers to supplement external contracts.
43 44
 Benefits
 Both parties have a clearer view of responsibilities and there are specific 13 Financial Management for IT Services
service targets to aim for
 Service monitoring and reviews will allow weak areas to be identified,
so that remedial action can be taken
Goal
 Misunderstandings between Customers and IT Service Providers are
avoided To provide cost effective stewardship of the IT assets and the financial
 SLM underpins supplier management and SLAs are a key part of resources used in providing IT services.
managing supplier relationships
 IT services will be designed to meet Service Level Requirements (SLRs) Why Financial Management for IT Services?
of future business requirements
Financial Management for IT Services is an integral part of Service
 SLAs can be used as a basis for charging and will demonstrate what Management. It provides the essential management information to ensure that
Customers receive for their money services are run efficiently, economically, and cost effectively. An effective
 OLAs and support contracts with external suppliers are better aligned financial management system will:
with the business services required.
 Assist in the management and reduction of overall long term costs
Possible Problems
 Identify the actual cost of services and their provision
 Ensuring targets are verified and achievable before agreeing and  Provide accurate and vital financial information to assist in decision
committing to them making
 Monitoring, measuring, and reporting of actual achievements
 Identify how IT adds value to the Customer’s business
 Incorrect scoping, with inadequate resources and time
 Enable the calculation of Total Cost of Ownership and Return on
 Not enough seniority/authority given to SLM to push through Investment
negotiations/improvements
 Make Customers aware of what services actually cost, if appropriate
 SLAs may not be supported by adequate underpinning contracts or
agreements  Support the recovery of costs, from Customers if appropriate, in a fair
 SLAs may be too lengthy, not concise, not business focused and and equitable manner
therefore not used  Provide measurements of Value For Money, and provide incentives to
 Business requirements not clearly understood with no business produce quality services aligned to business needs
justification for the requested service levels
 Help influence Customer behaviour, for example by providing
 Lack of focus on business critical services/processes incentives for using non-critical resources
 A resistance to change  Encourage more efficient use of resources
 The service levels to be provided are dictated to Customers  Provide better cost information and control of external contracts
 Customer perception and expectation and suppliers
 SLM not used to trigger service improvements  Assist in the assessment and management of Changes.
 SLM not aligned with the complete service life-cycle.
45 46
 Responsibilities Business IT IT Operational plan Cost analysis Charges
requirements (Inc. Budget) (Accounting)

 Enable the organisation to account fully for the spend on IT services

and to attribute these costs to the services delivered to the 
organisation’s Customers
 
 Assist management decisions on IT investment by supporting detailed
business cases for Changes to IT services 



 Control and manage the overall IT budget and enable the fair and
Financial targets
equitable recovery of costs (by charging) for the provision of IT
services. Costing models
Key Considerations
Charging policies
Concepts

Budgeting and Accounting (mandatory): understanding the cost of providing

each service, whether recovered or not, is essential to the delivery and
Feedback proposed charges to business
maintenance of cost effective and efficient services. These activities enable an
organisation to:
Figure 18: Costing, Charging and Budgeting Cycle
 Predict the money required to run IT services for a given period
 Ensure that the actual spend can be compared with the predicted spend Charging
at any point
Charging needs to be seen as being simple, understandable, fair and
 Account for the money spent in IT services in a given period realistic. Senior IT and Business Managers will set the charging policy.
 Calculate the cost of IT service provision. Possible charging policies are:

Charging (optional): can have clear business benefits, acting as an incentive Cost: price = cost
to the Provider and giving leverage to the Customer who can demand Value for Cost-plus: price = cost ± X%
Money. Charging enables an organisation to: Going rate: price is comparable with other internal
 Recover the cost of the IT services from the Customers of the service departments’ costs within the organisation or
with similar organisations
 Operate the IT Services as a business unit if required.
Market rate: price matches that charged by external
suppliers
Fixed price: a set price is agreed for a set period with the
Customer based on anticipated usage

47 48
 Cost Elements Cost Model

Typical major cost types for an organisation’s costs might be: A framework, in which all known costs necessary to calculate the overall costs of
IT service provision can be recorded and allocated to specific Customers. Most
Type Includes
Cost Models are based on calculating the cost for each Customer but other models
Hardware Mainframes, disk storage, networks, PCs, can be developed to show the cost for each service or the costs for each location.
portables, local servers

Software Operating systems, applications, databases,

monitoring and management tools Hardware Software People Accommodation External Transfer
Service
People Payroll costs, benefits, re-location costs,
expenses, consultancy
Cost elements
Accommodation Offices, storage, secure areas, utilities

External Service Security services, Disaster Recovery Direct Costs Indirect Costs
services, outsourcing services Marketing Absorbed Unabsorbed
& Sales Manufacturing Finance Costs
Costs
Transfer Internal charges from other cost centres
within the organisation M&S Mnf F

Proportion of indirect costs which can

be apportioned to Marketing & Sales
Each cost can be categorised for accounting purposes between different
alternatives, including the following:
Marketing
& Sales M&S Unabsorbed overhead,
Either Or recovered by an uplift to all
costs of X%
Capital Operational

Outright purchase of fixed Day-to-day costs of running a Direct & Absorbed X% Uplift X% = Unabsorbed costs x100%
assets e.g. new server service: staff, electricity, Costs
Direct + absorbed costs
maintenance, consumables
An alternative method is just
Direct Indirect to divide the unabsorbed
Total cost of IT services for overheads by three collecting
Costs which can be directly Costs which must be apportioned Marketing & Sales them equally from all
allocated to a single Customer across all or a number of customers
or Customer group Customer groups
Figure 19: Cost Model of Costs by Customer
Fixed Variable

Costs fixed for a reasonable Costs that vary with usage

period of time (salaries, or time (overtime, electricity etc.)
depreciation, standing charges)

49 50
 Benefits
 Reduced long term costs 14 Capacity Management
 Increased confidence in setting and managing budgets
 Accurate cost information to support IT investment
Goal
 More efficient use of IT throughout the business
To understand the future business requirements (the required service delivery), the
 Increased awareness and professionalism within IT organisation’s operation (the current service delivery), the IT infrastructure (the
 Ensuring that the business provides sufficient funds to run the IT means of service delivery), and ensure that all current and future capacity and
services it requires performance aspects of the business requirements are provided cost effectively.
 More business-like decision making on IT services Why Capacity Management?
 Recovering IT costs in a fair manner, related to usage Capacity Management ensures that IT processing and storage capacity
 Influencing Customer and User behaviour provision match the evolving demands of the business in a cost effective and
timely manner. The process encompasses:
 Allowing comparison with alternative service Providers.
 Monitoring the performance and the throughput of IT services and
Possible Problems
supporting IT components
 Budgeting, accounting and charging are often new disciplines in IT and
there are limited skills available  Tuning activities to make efficient use of resources

 The lack of availability of planning information both within and outside  Understanding the current demands for IT resources and deriving
IT, could cause problems and delays forecasts for future requirements

 IT staff with accountancy skills are rare, so key activities may rely on  Influencing the demand for resource, in conjunction with other Service
uncommitted external resources Management processes

 Enterprise IS strategies and objectives may not be well developed and  Producing a Capacity Plan predicting the IT resources needed to
prediction of capacity not accurate achieve agreed service levels.

 Senior IT and Business Managers may resent the administrative Success in Capacity Management
overheads of financial processes Success depends on a number of factors:
 IT may not be able to respond to changes in Customer demands once  Accurate business forecasts
costs become an influence
 An understanding of current and future technologies
 The financial processes are so elaborate that the cost of the system
exceeds the value of the information  An ability to demonstrate cost effectiveness

 The monitoring tools providing resource usage information are  Interaction with other effective Service Management processes
inaccurate, irrelevant or too costly
 An ability to plan and implement the appropriate IT capacity to
 If charges are seen as excessive Customers may go elsewhere for their match business need.
IT services.
51 52
 INPUTS SUB-PROCESSES OUTPUTS Service Capacity Management (SCM):
• Technology Business Capacity Management: • Capacity Plan
Focuses on managing the performance of the IT services provided to the
• SLAS, SLRS and Service • Capacity Database
Catalogue • Trend, forecast, model, prototype, Customers, and is responsible for monitoring and measuring services, as
size and document future • Baselines and profiles
• Business Plans and Strategy business requirements detailed in SLAs and collecting, recording, analysing and reporting on data.
• Thresholds and alarms
• IS, IT Plans and Strategy This requires knowledge of:
• Capacity reports (regular,
• Business requirements and Service Capacity Management: ad hoc and exception)
volumes
 Service levels and SLAs
• Monitor, analyse, tune and • SLA and SLR
• Operational schedules report on service performance, recommendations  Systems, networks, and service throughput and performance
• Deployment and Development establish baselines and profiles • Costing and charging
plans and programmes of use of services, manage recommendations  Monitoring, measurement, analysis, tuning and demand management.
demand for service.
• Forward schedule of Change • Proactive changes and Resource Capacity Management (RCM):
• Incidents and Problems service improvement
Resource Capacity Management:
• Revised operational Focuses on management of the components of the IT infrastructure and
• Service reviews
• Monitor, analyse, tune and schedule ensuring that all finite resources within the IT infrastructure are monitored
• SLA breaches report on the utilisation of • Effectiveness reviews and measured, and collected data is recorded, analysed and reported. This
• Financial plans components, establish baselines
and profiles of use of • Audit reports requires knowledge of:
• Budgets components
 The current technology and its utilisation
Figure 20: The Capacity Management Process  Future or alternative technologies

Responsibilities  The resilience of systems and services.

There are three principal areas of responsibility: Key Considerations

Overlapping Activities
Business Capacity Management (BCM):

Is responsible for ensuring that the future business requirements for IT The Service and Resource Capacity Management sub-processes carry out many
services are considered, planned and implemented in a timely fashion. These similar activities. However the two sub-processes each have a very different
future requirements will come from business plans outlining new services, focus: the former is focused on the services that support the business, and the
improvements and growth in existing services, development plans etc. This latter is focused on the technology that underpins all the service provision.
requires knowledge of: Performance and Capacity Issues

 Existing service levels and SLAs Capacity Management should be the focal point for all IT performance and
capacity issues. Other technical domains, e.g. network management, may
 Future service levels and SLRs
carry out the bulk of the relevant day-to-day duties, but overall responsibility
 The Business Plan and Capacity Plan should lie with a centralised Capacity Management process.
 Modelling techniques (Analytical, Simulation, Trending, and
Baselining)
 Application sizing methods.

53 54
 Iterative Activities Capacity Management and the Business

The main Capacity Management activities of monitoring, analysis, tuning, Capacity Management must understand the technical infrastructure and its
and implementation, are iterative in nature. capabilities and also the likely effects of the use of new equipment and
technologies.

Tuning
However, even more importantly, it must also work closely with the business.
It needs to be able to translate business predictions and workload estimates
into capacity requirements, in terms of quantity, and determine when they will
Implementation Analysis
be required.
Monitoring
Business Strategy

Resource SLM SLM Resource Business Plan

Utilisation Thresholds Exception Utilisation Capacity
Thresholds Reports Exception Management
Capacity Reports IS/IT Strategy
Management
Database
(CDB) IS/IT Business Plan

Figure 22: Capacity Management and the Business

Figure 21: Iterative Capacity Management Activities
Demand Management
The Capacity Management Database
This is an important aspect of the interface between the business and Capacity
The Capacity Management Database (CDB) is used as the basis for the Management, and has the objective of influencing demand and therefore the
production of all Capacity Management reporting on existing and future capacity use of resources. It requires a full understanding of the business requirements
issues. It is unlikely to be a single database, but will probably exist in several and their demands on IT services and resources. It must be carried out
physical locations and will contain many different types of data, including: sensitively and without causing damage to the business, Customers, Users, or
 Business data the reputation of IT.
 Service data
A Balancing Act
 Technical data
Capacity Planning is essentially a balancing act:
 Financial data
 Cost against capacity
 Utilisation data.
 Supply against demand.

55 56
 Benefits

 Increased efficiency and cost savings resulting in more economic 15 IT Service Continuity Management
provision of IT services
 Deferred expenditure
Goal
 Elimination of unnecessary spare capacity and optimisation of
equipment To support the overall Business Continuity Management process by ensuring
that the required IT technical and services facilities can be recovered within
 Elimination of expensive panic buying
required and agreed business time-scales.
 Reduced risk of performance Problems and failure
Why IT Service Continuity Management?
 More confident and improved forecasting
 Early and improved awareness of capacity issues within the application IT Service Continuity Management is concerned with managing an
development life-cycle organisation’s ability to continue to provide a pre-determined and agreed level
of IT services to support the minimum business requirements, following an
 Better and more informed acquisition of IT resources
interruption to the business. This includes:
 Better relationships with Customers and Users with improved
understanding of service levels and SLAs  Ensuring business survival by reducing the impact of a disaster or
major failure
 Service improvements through better control
 Reducing the vulnerability and risk to the business by effective risk
 Less need for reactive support. analysis and risk management

Possible Problems
 Preventing the loss of Customer and User confidence
 Producing IT recovery plans that are integrated with and fully support
 Customer expectations exceed technical capacity the organisation’s overall Business Continuity Plan.
 Over expectation of the benefits to be gained from tuning
Responsibilities
 Unrealistic and unachievable performance figures from equipment
suppliers and manufacturers  The available IT Service Continuity options must be understood and
 Unavailability of necessary business information due to commercial the most appropriate solution chosen in support of the business
requirements
and/or security concerns
 Roles and responsibilities need to be identified, and endorsed and
 Unreliable and inaccurate business forecasts and information
communicated from a senior level to ensure respect and commitment for
 Incomplete or inaccurate information, particularly from distributed the process
systems, networks and PCs  IT recovery plans and Business Continuity Plans should be aligned,
 Too much data: many tools provide vast amounts of capacity and regularly reviewed, revised and tested.
information
 Lack of financial resources, and technical resources and skills.
57 58
 Roles in Normal Operation Roles in Crisis Situation Stage 1 Initiate BCM
Initiation
Board Level
Initiate IT Service Continuity, Crisis management, corporate Stage 2 Business Impact
set policy, allocate responsibilities, decisions, external affairs Requirements & Analysis
direct and authorise Strategy
Risk Assessment
Senior Management
Business Continuity
Manage IT Service Continuity, Co-ordination, direction and Strategy
accept deliverables, communicate arbitration, resource authorisation
and maintain awareness,
integrate across organisation Stage 3 Organisation and
Implementation Implementation
Junior Management Planning

Undertake IT Service Continuity Invocation, team leadership,

analysis, define deliverables, site management, liaison and
contract for services, manage reporting Implement Develop Implement
testing and assurance Stand-by Recovery Plans Risk Reduction
Arrangements Measures

Supervisors and Staff

Develop deliverables, negotiate Task execution, team membership, Develop Procedures

services, perform testing, develop liaison
and operate processes and Initial Testing
procedures

Key Considerations

IT and Business Continuity Awareness

The best way to raise awareness is to highlight the potential risks and business Testing
Review & Change
impacts facing an organisation. Awareness of the need for IT Service
Audit Management
Continuity Management will come from:
Education & Training
 The range of risks facing an organisation and its vulnerability Awareness
 The potential business impacts that could result should any of the risks Assurance
materialise
 The likelihood of each of the risks materialising Stage 4
Operational Management
 Personal responsibilities and liabilities, e.g. of directors
 External pressures, e.g. from regulators or shareholders.
Figure 23: The Business Continuity Life-cycle

59 60
 Recovery Options Risk Analysis

Options need to be considered for: Many methods of risk assessment and analysis exist, such as the CCTA Risk
Analysis and Management Method (CRAMM). This involves the
 People and accommodation
identification of risks, the associated threats, vulnerabilities and impacts
 IT systems, networks, and processes together with the subsequent implementation of cost justifiable
 Critical services such as power, water, post, etc. countermeasures.

 Critical assets such as paper records, reference material, etc.

Assets Threats Vulnerabilities
Option Description
ANALYSIS
Do nothing: Rarely used, because few business processes
can function effectively without IT. Risks
MANAGEMENT
Manual back-up: Can be an effective interim measure until the
IT service is resumed. Countermeasures
Reciprocal Organisations agree to back each other up in an
arrangement: emergency, rarely used now except for off-site
storage because of practical difficulties, e.g. Figure 24: The CRAMM Risk Assessment Model
limited excess IT capacity.
Gradual recovery: Usually consists of an empty computer Benefits
(Sometimes referred to environment in which an organisation can install
as“cold standby”) its own equipment. May be used where a  Management of risk and the consequent reduction of the impact of
business can function for a period of 72 failure
hours or more without IT services. Can be
internal or external, fixed or portable, possibly  Potentially lower insurance premiums
with guaranteed equipment delivery.
 Fulfilment of mandatory or regulatory requirements
Intermediate recovery: Typically involves the re-establishment of
(Sometimes referred to critical systems and services within a 24-72 hour  Improved relationships between the business and IT through IT
as“warm standby”) period. Can be internal or external, fixed or becoming more business focused, and more aware of business impacts
portable, and consists of a computer
environment containing recovery IT equipment and priorities
that can be configured to support the business.  Reduced business disruption during an incident, with an ability to
Immediate recovery: Would involve the use of an alternative site with recover services efficiently in business priority order
(Sometimes referred to continuous mirroring of live equipment and
as“hot standby”) data. Can be internal or external and is the most  Increased Customer confidence, possible competitive advantage and
expensive option. Would only be used for critical increased organisational credibility.
business services where loss of service would
cause an immediate business impact.

61 62
 Possible Problems

 Obtaining management commitment and resources 16 Availability Management

 Gaining buy-in and assistance from the business
 The process and cost of testing and invoking plans for live services
Goal
 Availability of components, resources and data to test the IT recovery
To optimise the capability of the IT infrastructure and supporting organisation
and Business Continuity Plans
to deliver a cost effective and sustained level of availability that enables the
 Overlooking critical components, applications, and dependencies, and business to satisfy its objectives.
misinterpreting business impacts
Why Availability Management?
 Incorrect business impacts and/or business focus
Availability Management ensures services are available when the Customer
 Poor integration with other business and Service Management
needs them, and is influenced by:
processes.
 Business demand
Testing the Recovery Plan
 The cost required to meet it
Plans should be tested after initial development, and thereafter at least
 The Configuration and complexity of the IT infrastructure including,
annually, and following major Changes. Testing will range from the level of redundancy, the reliability of the infrastructure and its
inspection or walk-through, to announced testing of components, or to components, and the levels of infrastructure maintenance
full unannounced tests involving the business and IT.
 The processes and procedures used by IT services
 Human factors and external events.
Responsibilities

 Optimise availability by monitoring and reporting on all key elements

of availability
 Determining availability requirements in business terms
 Predicting and designing for expected levels of availability and security
 Producing the Availability Plan
 Collecting, analysing and maintaining availability data and reporting
on that data
 Ensuring service levels are met by monitoring service availability levels
against SLAs, and monitoring OLA targets and external supplier
serviceability achievements
 Continuously reviewing and improving availability.

63 64
 Key Considerations Availability Metrics

Elements of Availability Management The IT Availability Metrics Model (ITAMM) assists in assessing the range of
metrics and perspectives that should be considered when establishing
Availability: the percentage of the agreed service hours for which the
availability measurement and reporting. The model can be used to establish
component or service is available
what needs to be measured in order to give a comprehensive view of the
Reliability: the prevention of failure, and the ability to keep services and availability of IT services.
components operable
Frequency
Maintainability: the ability to restore services or components back to normal
Reliability
operation
Serviceability: the support for which external suppliers can be contracted to Vital business function

provide parts of the IT infrastructure Application

Response Time
Availability
Security: the implementation of justifiable controls to ensure continued IT Data

Scope

Scope
service within secure parameters, viz: Confidentiality, Integrity and
Network
Availability. (For more detail refer to the ITIL Security Management
publication, or to BS7799/ISO17799 - The Information Security Management Key components
standards.) Security should be considered in all aspects of the following Platform
diagram:
Maintainability

Duration
Customers Customers Customers Customers Customers
Figure 26: The IT Availability Metrics Model
SLAs with Availability
Measuring Availability
IT Services & IT Systems Measurements need to be meaningful and add value if availability
measurement and reporting are to ultimately deliver benefit to the IT
and business organisation. This will be strongly influenced in the
combination of “what you measure” and “how you report it”.
OLAs with Reliability & Maintainability Contracts with Serviceability

The Availability Plan

Applications Op Sys H/W Applications Op Sys H/W
Support Support Support Support Support Support The Availability Plan should be a long-term plan for the proactive
improvement of IT availability within the imposed cost constraints. The plan
should have goals, objectives and deliverables and should consider the wider
Internal Organisations External Organisations
issues of people, processes, tools and techniques as well as having a
technology focus.
Figure 25: Relationships with Support Organisations

65 66
 Availability Management Principles Benefits
 Availability is at the core of business need and User satisfaction  Addresses the fundamental business requirement for high levels of
availability
 Recognising that when things go wrong, you can still achieve User
satisfaction  Services are designed and managed to cost effectively meet specified
 Improving availability can only begin when you understand how the business requirements
technology integrates with and supports the business.  Availability levels are measured to fully support Service Level
Management
Business availability requirements Availability & recovery design criteria  Shortfalls in service levels are identified and corrective actions taken
Business impact assessment IT infrastructure resilience  Frequency and duration of IT failures is reduced
& assessment
Availability, reliability & Agreed targets for availability and  Change IT mindset from a reactive to a proactive attitude
maintainability requirements maintainability
Availability  IT support “adds value” to the business.
Incident and problem data Management Reports of availability, reliability
& maintainability achieved Possible Problems

Configuration & monitoring data Availability monitoring  Measures of availability that are meaningless to the business
 Not measuring availability at the point of service delivery
Service level achievements Availability improvement plans
 Difficulties in finding skilled and experienced staff
 Justification to management in relation to expenditure
Figure 27: The Availability Management Process
 Lack of management commitment
 Lack of suitable software
 Dependence on suppliers for serviceability data, i.e. reliability and
Useful Definitions
maintainability
High Availability: a characteristic of the IT service that
minimises or masks the effects of IT  Difficulty in determining business and Customer availability
component failure to the User. requirements
Continuous Operation: a characteristic of the IT service that  Lack of information about the IT infrastructure, if there is no
minimises or masks the effects of planned
downtime to the User. Configuration Management database.
Continuous Availability: a characteristic of the IT service that
minimises or masks the effects of ALL Business Value
failures and planned downtime to the User. Effective Availability Management will influence Customer
satisfaction and determine the perceived reliability of the business on
the market.

67 68
 17 The Importance of Communication 18 Further Guidance and Contact Points

Effective and efficient communication is part of the foundation on which the itSMF Ltd. The itSMF is a totally independent,
success of many organisations depends. In the business world there are many Webbs Court not-for-profit organisation owned and
pressures on time, and often it is communication that suffers when time and 8 Holmes Road run by its members. It promotes and
resource constraints apply. In Service Management there are many areas that Earley helps to set the standards for best
are involved in regular communication with their business Customers to Reading RG6 7BH practice in IT Service Management.
ensure that the services delivered to them meet their requirements at United Kingdom There are national chapters in many
appropriate cost. Notable examples include Service Desk, Change Tel: +44(0)118 926 0888 parts of the world. For further details
Management, and Service Level Management. Fax: +44 (0)870 706 1531 of the chapters, and how to contact
e-mail: [email protected] them, access the web site or contact
Everyone within IT has a responsibility to provide good communication but
www.itsmf.com the UK office.
there is a prime responsibility at the management level to ensure that
communication is embedded within the Service Management process.
OGC
Developing and fostering effective communication with Customers and Users Rosebery Court
of IT has always been an important issue. Very often this was something that St Andrews Business Park
was left almost to chance and to the personal actions of individuals within IT Norwich NR7 0HS
departments. In the modern business world this is not sufficient. United Kingdom
Organisations can be said to operate at three key levels; strategic, tactical, and Tel: +44(0)845 000 4999
operational, and there are specific corporate functions at each level. For IT to be Fax: +44(0)1603 704 618
fully integrated with their business Customers, effective two-way communication e-mail: [email protected]
must take place at the same three levels and also between these levels. www.ccta.gov.uk
www.itil.co.uk
The ability to listen, influence, negotiate, and agree is vital.
Many communication techniques exist, and include: seminars, reports, British Standards Institution
circulars, e-mail, memos, newsletters, meetings, awareness campaigns, focus 389 Chiswick High Road
groups, presentations, road-shows, Internet, and Intranet. London W4 4AL
United Kingdom
The Need for Improvement Tel: +44(0)208 996 9001
During review exercises of organisational, departmental, or team Fax: +44(0)208 996 7001
performance, communication is one of the most commonly mentioned e-mail: [email protected]
topics that people suggest requires improvement. www.bsi-global.com

69 70