ITIL Foundation

Essential for
IT Service Management
Course Outline
ITIL/ITSM Overview
ITSM - Service Support
Service Desk
Incident Management
Problem Management
Change Management
Configuration Management
Release Management

ITSM - Service Delivery

Service Level Management
Availability Management
Capacity Management
IT Service Continuity Management
Financial Management for IT Service

1
ITIL Overview

ITIL Service Management

ITIL overview

ITIL = IT Infrastructure Library

Developed in the Late 1980s

CCTA (Central Computer and Telecommunications Agency)
= Office of Government Commerce (OGC)
OGC website URL http://ww.ogc.gov.uk
ITIL website URL http://www.itil.co.uk

ITIL is a Best Practice Framework

Public Domain

ITIL Philosophy Scaleable Process driven
approach

3
The ITIL Objectives

Key Objectives

Align IT services with the Current and Future needs of the
business and its Customersboth internal and external

To improve Quality of the services delivered

Reduce long term Cost of service provision

4
ITIL Service Management

Service Support Functions:

Service Desk

Incident Management

Problem Management

Change Management

Configuration Management

Release Management

Service Delivery Functions:

Service Level Management

Availability Management

Capacity Management

IT Service Continuity Management

Financial Management for IT Service

5
Service Support
including:
Service Desk
Incident Management
Problem Management
Change Management
Configuration Management
Release Management
Service Desk
Objectives:

Supports the agreed IT service provision by ensuring the
accessibility and availability of the IT organization and by
performing various supporting activities.

To act as the central point of contact between the User and
IT Service Management for all Calls, Questions, Requests,
Complaints and Remarks

To restore the service as quickly as possible

To handle Incidents life-cycle and request and provide an
interface for other activities

To support business activities

To generate reports, to communicate and to promote

7
Service Desk
Service Desk Essentials:

Not a Process but a function

Single point of contact / Restore service ASAP

Tasks: Customer Interface, Business Support, Incident
Control & Management Information

Concentrates on incident lifecycle management

Incident: Unexpected disruption to agreed service

Priority determined by business impact and urgency

Correct assessment of priorities enables the deployment of
manpower and other resources to be in the best interests of
the customer

8
Service Desk
Setting up a Service Desk:

Understand the business needs and requirements

Define clear objectives

Obtain support, budget and resources

Advertise and sell benefits / communicate quick wins

Involve and educate users / train support staff

Types of Service Desk:

Local Service Desk

Central Service Desk

Virtual Service Desk
(Several service desks)

9
Service Desk
Different Desks (by different skill level)

Call Center:
Handling large call volumes of telephone-based transactions.

Help Desk:
To manage, coordinate, and resolve Incidents as quickly as
possible.

Service Desk:
Allowing business processes to be integrated into the Service
Management infrastructure. It not only handles Incidents,
Problems and questions, but also provides an interface for other
activities. (e.g. Change requests, maintenance contracts,
software licenses, SLM)

10
Incident Management
Objectives:

To restore normal service as quickly as possible

Minimize the adverse impact on business operations

Ensuring that the best possible levels of service quality and
availability are maintained according to SLAs.

Incident Definition:
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.

11
Incident Management

Service Request:
Every Incident not being a failure in the IT Infrastructure.

Problem:
The unknown root cause of one or more incidents.

Known Error:
A condition that exists after the successful diagnosis of the root
cause of a problem when it is confirmed that a CI (Configuration
Item) is at fault.

Category:
Classification of a group of Incidents (Application, Hardware, etc.)

12
Incident Management
Incident Life-Cycle:

Accept Service Event, Register and Consult the CMDB

Classification

Solve

Closure

Reporting:

Daily reviews of individual Incident
and Problem status against service levels

Weekly management reviews

Monthly management reviews

Proactive service reports

13
Incident Management
Impact
The likely effect the incident will have on the business (e.g.
numbers affected, magnitude)
Urgency
Assessment of the speed with which an incident or problem
requires resolution (i.e. how much delay will the resolution
bear)
Priority
The relative sequence in which an incident or problem
needs to be resolved, based on impact and urgency

14
Incident Management
Known Structural
Incident Error Resolution

Error in Problem RFC

infrastructure

Relationship between incidents, Problem and Known Errors

15
Incident Management
Escalation
IT Service
Manager

Hierarchical (authority)
Service Desk 2nd Line 3rd Line
Manager Manager Manager

Service Desk 2nd Line 3rd Line

Support Team Support Team Support Team
Functional (competence)

16
Problem Management
Objectives:

Stabilizing IT services through:
Minimizing the consequences of incidents
Removal of the root causes of incidents
Prevention of incidents and problems
Prevent recurrence of Incidents related to errors

Improving productive use of resources

17
Problem Management
Key Activities:

Problem Control

Error Control (including raising RFCs Request for Change)

Proactive Prevention

Identifying Trends

Management Information

Post Implementation Review (PIR)

 Problem control Known errors

Incident details  Error Control RFC
Updated
CMDB  Proactive prevention Problem record
Defined  Identifying trends Closed Problem
record
workarounds  Reports
Management
 Completion of problem reviews Information

18
Problem Management
Problem Control:

Goal:
To identify the root Cause

Activities:
Identification
Classification
Assign Resources
Investigation and Diagnosis
Establish Known Error

19
Problem Management
Error Control:

Goal:
Bridges the development and live environments

Activities:
Error Identification and Recording
Error Assessment
Recording Error / Resolution (Send out RFCs)
Error Closure

Known Error: An Incident or Problem for which the root cause

is known and temporary Work-around or a permanent
alternative has been identified.

20
Problem Management
Proactive Problem Management:

Goal:
The activities aimed at identifying and resolving problems
before incidents occur.

Activities:
Trend Analysis
Targeting Support Action
Providing Information to the Organization

Known Errors resulting from Development should be made

known to the Helpdesk.

21
Change Management
Objectives:

To implement approved changes efficiently, cost-effectively
and with minimal risk to the existing and to the new IT
infrastructure. Only approved changes made, risk and cost
minimized.

22
Change Management
Key Activities:

Logging & Filtering Changes

Managing Change Process

Managing Changes

Chairing CAB and CAB/EC

Review and Closure

Management Information

 Filtering changes
RFCs  Managing Changes and Change FSC
process RFCs
CMDB
CAB minutes
 Chairing the CAB and actions
Forward Schedule
 Reviewing and closing RFCs Reports
of changes (FSC)
 Management reporting

23
Change Management
Types of Change:

Basic Change
Priority: Based on Impact+Urgency
High, Medium, Low (Urgent?)
Category: Based on business impact
Minor, Significant, Major

Urgent Change
A change that needs to be implemented more quickly

Standard Change
An accepted solution to an identifiable and relatively
common set of requirements (e.g. set up of User profile,
Password reset)

24
Change Management
Impact of Change:

Category 1
Little impact on current services. The Change Manager is entitled
to authorize this RFC.

Category 2
Clear impact on services. The RFC must be discussed in the
Change Advisory Board. The Change Manager requests advice
on authorization and planning.

Category 3
Significant impact on the services and the business. Considerable
manpower and/or resources needed. The RFC will have to be
submitted to the board level (CAB/EC Change Advisory Board
/ Emergency Committee)

25
Change Management
Priority Setting:

Urgent
Change necessary now (otherwise severe business impact)

High
Change needed as soon as possible (potentially damaging)

Medium
Change will solve irritating errors or missing functionality (can be
scheduled)

Low
Change leads to minor improvements

A change backout plan must always be possible.

Change management always ends with a review of the

change.
26
Change Management
A RFC may include following Items:
 RFC Number
 Description
 Reason for Change
 CI
 Name
 Date
 Change priority (Immediate, High, Medium, Low)
 Impact and resource assessment
 Back out plan
 Risk assessment
 Impact on business continuity and contingency plans
 Etc..

27
Change Management
Change Advisory Board (CAB):

The CAB is a body that exists to approve Changes and to
assist the Change manager is the assessment and
prioritization of changes

CAB members (may vary)

Change manager

Services staff

Customer

User manager

Application developers

Experts/technical consultants

Problem manager

Service level manager

28
Configuration Management
Objectives:

Account for all the IT assets and configurations within the
organization and its services

Provide accurate information to support other Service
Management processes

Provide a sound basis for all other Service Management
disciplines

Verify records against the infrastructure and to correct
exceptions

Enabling control of the infrastructure by monitoring and
maintaining information on:
All the resources needed to deliver services
Configuration Item (CI) status and history
Configuration Item relationships

29
Configuration Management
Key Activities:

Planning
Strategy, policy, scope, objective, roles & responsibilities
Config Mgt processes, activities and procedures
CMDB, Relationships with other processes and 3rd parties
Tools and resource requirements

Identification
Selection, identification and labelling of all CIs - Relationships

Control
Authorized additions, modifications and removal of CIs

Status Accounting
The reporting of all current and historical data of each CI
Ordered, Under Repair, Live, Test .

Verification & Auditing
Reviews and audits to verify physical existence of CIs
30
Configuration Management
Configuration Management Database (CMDB)
A database that contains all relevant details of each CI and details
of the important relationships between CIs

Configuration Items (CIs)

Component of an infrastructure that is (or is to be) under the
control of Configuration Management
4 Types of CIs:

Hardware

Software

Documentation
Processes and Procedures
Technical documentation
Diagrams/Charts

IT Staff NOT USERS
31
Configuration Management
Characters of a Configuration Item (CI):
Is needed to deliver a service
Is uniquely identifiable
Is subject to change
Can be managed
(A CI has: a Category, Relationships, Attributes and a Status)

CI Attributes
 CI name
 Serial number
 Category ( hw,sw, documentation)
 Type
 Model number
 Location
 Version
 Owner
 Installation dates, acceptation dates, delivery date
 Financial information (purchase cost, maintenance cost)
 Status or lice cycle (development, test, operational, defect, archived)
 Relations ( is part of, connected to, uses)
32
Configuration Management
Relationships

..is a parent/child of..

..is a version of..

..is connected to..

..applies to..(e.g. documentation)

..is used for.. (CIs related to service)

..is a variant of.. (MS Dictionary English vs. Dutch)

33
Configuration Management
Definitions:

Configuration Baseline
Configuration of a product or system at a specific point in time
which captures both structure and details. As a reference for
further activities. (A snapshot of CMDB structure and detail)

Definitive Software Library
Location where all definitive authorized versions of all SW CIs are
stored and protected.

Configuration management vs Asset management
Asset: Component of a business process like people,
accommodation, computer systems, paper records, fax machines,
etc.

34
Release Management
Objectives:

Safeguard all software and related items

Ensure that only tested / correct version of authorized
software are in use

Ensure that only tested / correct version of authorized
hardware are in use

Right software, right time, right place

Right hardware, right time, right place

35
Release Management
Key Activities:

Define the release policies

Control of the Definitive Software Library (DSL)

Control of the Definitive Hardware Storage (DHS)

Distribute Software and Associated CIs

Carry out S/W audits (using CMDB)

Manage the software releases

Oversee build of the software releases

36
Release Management

 Release policy and planning

 Release design, build and
configuration
Release plan
Project planning  Release acceptance Test plan and
Product  Rollout planning acceptance criteria
definitions Detailed instructions
Approved RFC  Extensive testing Back-out/fall back
Test environment  Sign-off for implementation procedures
Installation media Release in
 Communication preparation and production
training Up-to-date CMDB,
 Storage of controlled software DSL
 Release distribution and installation
of software

37
Release Management
Build Management:

Software and Hardware components for release should be
assembled in a controlled, reproducible manner.

Build Management becomes the responsibility of Release
management from the controlled test environment on wards.

Back out plans should be devised and tested as part of the
release.

Change Management allows CMDB to remain accurate.

Without Configuration data change impacts are not
accurately assessable.

Without Change and Configuration Management, Releases
will not be controllable.

38
Release Management
Types of Release:

Delta release
Only the CIs that have actually changed or are new since the last
full or delta release

Full release
All components of the release unit are built, tested and
implemented together
Example: New version of client SW

Package release
Grouping of Delta and Full releases in order to provide longer
periods of stability in the live environment
(Release Policy)

39
Service Delivery

including:
Availability Management
IT Services Continuity Management
Capacity Management
Financial Management
Service Level Management
Availability Management
Objectives:

To predict, plan for and manage the availability of services
by ensuring that:

All services are underpinned by sufficient, reliable and properly
maintained CIs

Where CIs are not supported internally there are appropriate
contractual agreements with third party suppliers

Changes are proposed to prevent future loss of service
availability

Only then can IT organizations be certain of delivering the
levels of availability agreed with customers in SLAs.

41
Availability Management
Principle 1:

Availability is at the core of business & end user satisfaction

42
Availability Management
Principle 2:

When things go wrong, it is still possible to achieve business
& end user satisfaction

43
Availability Management
Principle 3:

Improving availability begins when it is understood how IT
services integrate with and support the business

44
Availability Management
Availability Definition:

Availability is the ability of an IT Service or component to
perform its required function at a stated instant or over a
stated period of time.

Depends on:

Availability of components

resilience to failure

quality of maintenance and support

quality, pattern and extent of deployment of operational process
and procedures

security, integrity and Availability of data.

45
Availability Management
Cost of Availability / Unavailability:

46
Availability Management
Incident Lifecycle:

MTTR: Mean Time to Repair (Downtime) Time period that
elapses between the detection of an Incident and its
Restoration. Includes: Incident, Detection, Diagnosis,
Repair, Recovery, Restoration.

MTBF: Mean Time Between Failures (Uptime) Time period
that elapses between Restoration and a new Incident.

MTBSI: Mean Time Between System Incidents Time
period that elapses between two incidents. MTTR + MTBF.

47
 Availability Management
Incident Lifecycle:
Time between
failures/Uptime
(MTBF)
Detection time/ Time to repair (MTTR)

Start
Repair

Detection Start End Incident

time Diagnose Repair close

INCIDENT INCIDENT

Detection Reaction Repair Restore

time time time time

48
ITSC Management
Objectives:

To support the overall Business Continuity management
process by ensuring that the required IT technical services
and facilities can be recovered within required and agreed
business time-scales

49
ITSC Management
Why Continuity Management:

Ensuring business survival by reducing the impact of a
disaster or major failure

Reducing the vulnerability and risk to the business by
effective risk analysis and risk management

Preventing the loss of Customer and User confidence

Producing IT recovery plans that are integrated with and
fully support the organizations overall Business Continuity
Plan(BCP)

50
ITSC Management
Considerations:

IT Service Continuity options need to be understood and the
most appropriate solution chosen in support of BCM
requirements

Roles and responsibilities need to be identified and
supported from a senior level

IT recovery plans and Business Continuity plans need to be
aligned regularly reviewed, revised and tested

51
Capacity Management
Objectives:

To determine the right, cost justifiable, capacity of IT
resources such that the Service Levels agreed with the
business are achieved at the right time.

52
Capacity Management
Responsibilities of Capacity Management:

Business Capacity management (BCM)
Ensuring future business requirements for IT services are
considered and matched to capability - Demand
Management

Service Capacity Management (SCM)
Managing performance of IT services delivered to customers
and documented in SLAs - Workload Management

Resource Capacity management (RCM)
Management of components ensuring that all resources are
monitored & measured - Resource Management

53
Capacity Management
Definitions (cont.):

Modeling
Trend Analysis
Analytical Modeling
Simulation Modeling
Baseline Modeling

Application Sizing:
To estimate the resource requirements to support a
proposed application change to ensure that it meets its
required service levels.

CDB Capacity Data Base
Contains all Metrics, etc. Used to create a Capacity
Management Plan. Performance Management Data
populates the CDB.

54
Financial Management for IT Services
Objectives:

To provide information about and control over the costs of
delivering IT services that support customers business
needs.

Costing is a must!

55
Financial Management for IT Services
Input cost units recommended by ITIL:

Equipment Cost Units (ECU)

Organization Cost Units (OCU)

Transfer Cost Units (TCU)

Accommodation Cost Units (ACU)

Software Cost Units (SCU)

Equipment = hardware
Organization = staff
Transfer = costs which IT incurs acting as an agent for the
customer, they do not appear as a cost against the IT
departments budget
Accommodation = buildings
Software = software

56
Financial Management for IT Services
Why Financial Management:

Identify the actual cost of services provided

Provide accurate and vital financial information to assist in
decision making

Make Customers aware of what services actually cost TCO

Assist in the assessment and management of changes

Help influence customer behaviour

Positioning for charging

57
Financial Management for IT Services
Concepts:

Accounting and Budgeting (mandatory)
Understand costs involved in providing a service
Prediction of future costs
monitor actual against predicted costs
Account for monetary spend over given period

Charging (optional)
Recovery of service costs from Customer
Operate IT Division as a business unit if required

58
Financial Management for IT Services
IT Financial Cycle:

Business IT IT Operational Cost Analysis Charges

Requirements Plan (inc. Budgets) (Accounting)

Financial Targets

Costing Models
Charging Policies

Feedback of proposed charges to business

(effects behaviour)

59
Financial Management for IT Services
Cost Model:
The Cost Model will consist of COST ELEMENTS

COST Type COST Categorization

Transfer (Cross Charges)  Capital OR Operational

Hardware  Direct OR Indirect

External Services  Fixed OR Variable

Software

People

Accommodation

60
Financial Management for IT Services
Charging and Pricing Options:

Charging:
No Charging IT treated as support center
Notional Charging IT treated as cost center
Actual Charging

Pricing:
Recover of Costs IT treated as a service center
Cost Price Plus IT treated as a profit center
Market Prices IT treated as a profit center

Support and Cost centers used soft charging in which no

money changes hands; service and profit centers use hard
costing in which money is transferred between bank accounts

61
Service Level Management
Objectives:

The goal for SLM is to maintain and improve IT Service
quality, through a constant cycle of agreeing, monitoring and
reporting upon IT Service achievements and instigation of
actions to eradicate poor service - in line with business or
Cost justification.

Through these methods, a better relationship between IT
and its Customers can be developed.

62
Service Level Management
Terminology:

Service Level Requirements (SLR) Amounts Availability,
Response Time ..

Service Level Agreement (SLA) Document Client/Supplier

Operational Level Agreement (OLA) Document Internal

Underpinning Contract (UC) Document 3rd Party Suppliers

Service Improvement Program (SIP) To Maintain Business
alignment

63
Service Level Management
Service Level Agreement (SLA):

A written agreement between an IT Service provider and the
IT Customer(s), defining the key service targets and
responsibilities of both parties.

Minimum Requirements for an Agreement:
Period, Service Description, Throughput, Availability,
Response Times, Signature

Other Possible Clauses:
Contingency arrangements, Review procedures, Change
procedures, Support services, Customer responsibilities,
Housekeeping, Inputs and Outputs, Changes

SLAs must be monitored regularly and reviewed regularly

Monitor to see if service is being delivered to specification

Review to see if service specification is still appropriate

64
Security Management
Objective:

Ensure such a level of security, that the agreed availability of
the infrastructure is not compromised.

65
Q&A