1

ITIL
ITIL is an acronym for Information Technology Infrastructure Library. It is a
collection of best practices for IT Service Management. ITIL was first published by the
OGC (Office of Government Commerce) of the Government of the United Kingdom in
the late 1980s. All the best practice guidelines outlined in ITIL were put together by
Subject Matter Experts who were approached and requested by the OGC to do so. This
was because of the increasing trend of companies to use IT or IT related services to run
their business and also to provide service to their customers. Updates to the original
ITIL library were done in 2001 and 2002 which included updates related to the internet
and e-commerce.

Service Desk
When a company provides an IT Service to its customers, they are bound to have
questions or just might run into problems for which they need a place from where they
can get quick answers, quick resolutions or at least, a quick workaround to their
problems so that they can carry on with their work and with their lives.
Customers get easily frustrated if they cannot get help – just when they need it.

An IT Service Desk is meant to be a single point of contact for customers who have a
problem with the services they are receiving from the IT Service Provider. This is where
they will report Incidents, RFCs (Requests for Change) or just any other problem.
Conversely, the IT Service Provider can also use the Service Desk as a channel through
which he can communicate to his customers.

Service Desks are also known as Customer Help Desk, Help Desk, Hotline, Call Center,
Customer Hotline etc.. But we will just call it Service Desk. which is nothing but an IT

https://tnind.wordpress.com
Service Desk. (You need to remember this.)

Why should you have a Service Desk?

 A good Service Desk helps to reduce Customer’s complaints.

 It increases Customer’s satisfaction.
 It reduces Service downtime and wastage of manpower.
 Increase Customer retention.
 2

The Service Level Agreement (SLA) contains specific details about the hours of
availability of the service, the time take to resolve an issue and the time within which the
user must receive a response from the Service Desk. It is important for the Service Desk
personnel to be aware of the SLA parameters.
Some organizations have a Service Desk which is a single point of contact for any issue
they might face – from IT Problems to the-lift-is-not-working issues. But we are going to
consider a Service Desk which deals only with IT related issues.

An IT Service Desk is responsible to:

 Monitor incidents and user’s queries.
 Keep the user updated about the progress.
 Follow up with any second level team and push for a quicker resolution.
 Make sure that SLAs are not breached.
A good IT Service Desk must have:
 Well trained Service Desk personnel (with good people skills).
 A properly organized system to record and track incidents.
 The Service Desk system should be able to identify similar incidents, even if
previously reported/fixed.
 Should have a proper knowledge base which can be used as an important reference
point.
 Service Desk Team should be technically competent to deal with users’ issues as and
when they arise.
 Proper channels of communication with the other disciplines like Problem
Management (for help when there is a major problem), Service Level Management
(so that SLAs can be adhered to), Configuration Management (so that the user’s

https://tnind.wordpress.com
equipment can be identified whenever required) & Availability Management (for
analysis of Service Desk related data which could help improve Services).
Types of IT Service Desks:
 Local Service Desk – to take care of regional/local users.
 Centralized Service Desk – which serves users from all geographical regions.
 Virtual Service Desk – is a collection of many local Service Desks, where calls are
routed to the most appropriate Service Desk, based on the issue, time of day, location
of user and so on.
 3

How to contact an IT Service Desk?

An IT Service Desk gets its inputs from two major sources – Human
Sources and Machine Sources.
 Humans can contact the IT Service Desk by Telephone, Fax, Email etc.
 Machines send out system generated alerts to the IT Service Desk.

Escalations:
An escalaton is the process where an incident is forwarded to a higher level or a more
expert team for better resolution. Escalation can be of two types:
 Functional Escalation: Where an issue is passed on to a more competent team
(Example: Escalating an issue to the Level 2 support team due to lack of enough
expertise to solve a certain problem).
 Hierarchical Escalation: Where an issue is passed up the management chain
because of lack of authority to do something. (Example: Escalating to the Service
Desk Manager).

Incident Management
What is an Incident?
An incident is any event which is not a part of the Standard Operation of a Service and
which causes or may cause an interruption to or reduction in the quality of that Service.
The aim of Incident Management is to restore normal services as quickly as possible.
Some best practices:
 All inquiries should be recorded as incidents.
 Service Requests (request for a standard operational item, eg: password resets)
should be recorded as incidents.

https://tnind.wordpress.com
 A request for a new product or service should be recorded as a Request for Change
(RFC).
 Automatically generated incidents (such as hardware or network failure) should also
be recorded as incidents.
 4

The Incident Life-Cycle

DETECTION & RECORDING:

 Provide a unique ID for each incident, even if it is a known issue.
 Record how the incident was reported – what were the Services and Configuration
Items affected?
 Classify the incidents – like Hardware, Software or Service Requests.
 Match the current incident against previously reported incidents.
 Assign a priority to the incident. (Priority of an incident is determined by the Impact,
Urgency, Availability of resources and the existence of certain parameters in the
Service Level Agreement [SLA]).
 Provide initial support to the incident or provide a workaround. If it is a new
workaround provided by the IT Service Desk, record it for future use.
 If the incident cannot be resolved, escalate the incident functionally.
INVESTIGATION & DIAGNOSIS:
 This may lead to resolution of the Incident right away or having it funcationally
escalated ( to Level 2 support.) If that process is taking too much of time, it might
also get heirarchically escalated.
RESOLUTION & RECOVERY:
 This can be done by raising an RFC and getting it implemented. Recovery just means
“restoring a service or an ICT component back to its previously working condition“.
INCIDENT CLOSURE:
 This happens upon confirmation of resolution of the problem by the user.
Note:
 Impact is the measure of the level of effect the incident has on the business, for

https://tnind.wordpress.com
example: number of users affected or amount of revenue lost because of the incident.
 Urgency indicates the timescale within which the incident needs to be resolved.
For an incident to be considered High Priority – both the Impact & Urgency should be
high.
 5

Problem Management
What is a Problem? – A Problem is “an unknown, underlying cause of one or more
Incidents“.
Did you know? 80% of incidents are caused by 20% of ICT infrastructure
components!
Problem Management is responsible to minimize the adverse effects of the Incidents
and Problems caused by errors in the (ICT) Infrastructure on the business and to
proactively prevent the occurrence of such errors, incidents and problems.
Problem Management looks for the underlying causes of Incidents and Problems and
provides long-term (permanent) resolutions. It functions both Proactively and Re
actively:
 Proactively: by trying to prevent the occurence of issues by intelligently analyzing
problem trends and available statistics.
 Reactively: by identifying underlying problems which are causing the incidents and
find a permanent resolution or an immediate workaround.

When Problem Management successfully identifies a problem and a suitable resolution

to it – the resolution is implemented through the Change Management
process.
Prioritization of problems is generally done by the “Pain Factor (PF)”. (The Pain Factor
is nothing but the number of people affected by the problem and the impact it is having
on the business.) So, higher the PF, higher the priority.

Responsibilities of the Problem Management team:

 Problem Control: Transform Problems into Known Errors by identifying the root

https://tnind.wordpress.com
cause of the problem and providing a temporary workaround. (This converts a
Problem into a Known Error.)
 Error Control: Resolves the Known Errors under the control of Change
Management as soon as possible and whenever it is financially justifiable.
 Proactive Prevention of Problems: Carry out trend analyses and provide
support to the organization.
 Providing Management Information from Problem Data: Carry out trend
analyses and provide support to the organization.
 Conducting Major Problem Reviews: This is done after a major problem has
been resolved so that future problems can be prevented.
The Problem Management process consists of the following stages:
 6

 Identification: The first step is to identify a new Problem. If there are no matching
records in the existing Problem or Known Errors database, then it is classified as a
new Problem.
 Recording: A new record is created and a unique ID is assigned. All related
Configuration Items are linked to it as well as all related Incidents/Known Errors.
 Classification: The Problem is classified appropriately and the impact of the
Problem on the Service Levels are determined so that relevant resources can be
assigned to resolve it.
 Investigation: The Problem is investigated so that a resolution is identified and it
can be classified as a Known Error.
 Diagnosis: Techniques such as Kepler Tregoe analysis and Ishikawa Fishbone
analysis are used. The end result again is the identification of a resolution or a
temporary workaround to the problem so that it is converted into a Known Error.
 Review & Closure: After every Problem is resolved – it is thoroughly reviewed so
that the following questions can be answered:

1. What was done right?

2. What was not done right?

3. What could have been done better?

4. How can we prevent it from happening again?

CHANGE MANAGEMENT

https://tnind.wordpress.com
What is a Change? – Change is the process of moving from one defined state to
another.
Change Management is responsible to ensure that standardized methods and
procedures are used for the efficient and prompt handling of all changes in order to
minimize the impact of any related incident(s) on the (IT) service.

Change Management implements all the changes in an organization with minimum

disruption to the IT services. It also carries out appropriate Impact Analyses before the
implementation of the change and has a backout plan in place, in case the change does
not work out in line with the expectations of the organization.
 7

Change Management balances the need for the change against the risks to
the IT infrastructure and will proceed only if:
 The impact is manageable.
 The cost is reasonable.
 The benefits to the business are worth it.
Change Management authorizes all changes to the IT infrastructure through the Change
Advisory Board (CAB). The CAB is formed by a team of experts within the organization.

It is not necessary to approach the CAB for approval of all RFCs. In some cases, this
responsibility can also be given to the Problem Management team or even the
Operations Team. This is discussed in more detail in the later sections.

ITIL mandates that end-users are kept informed of any changes much in advance – this
is done through Forward Schedules for Change – which lists out all the details of the
change, including when it would occur and all the services and components that would
be affected as a result of it.

All changes are released into the organization through the Release Management process.

The Change Management process starts with a Request for Change (RFC).

Some of the important sources of RFCs are:

 From the Service Desk.
 From Problem Management.
 When a new CI (Configuration Item) is introduced into the organization.

https://tnind.wordpress.com
 Whenever there is a requirement for a new or changed IT service.
 From a customer or end-user.
 Any new legislation or laws.
The Change Advisory Board (CAB) is made up of:
 A Change Manager (The Change Manager chairs all CAB meetings.)
 Representativs of the IT Service Management team.
 Representatives of the customer.
 Representatives of the users.
 Representatives of developers, other consultants and other experts.
The CAB is responsible to:
 Review all RFCs and approve them if it meets the business requirements.
 8

 Else the RFCs will be rejected.

 Keep a record of all RFCs, irrespective of wether it has been accepted or not.
 Advice on the grouping of changes into “Releases” so that there is little or no
disruption to the organization.
The CAB EC:
 Stands for Change Advisory Board Emergency Committee.
 Consists of the Change Manager, a senior IT representative and a senior
representative from the organization.
 Usually assembles at a short notice to review and authorize any urgent RFCs.
The Change Management Process:
 An RFC is generated to trigger the Change Management process.
 The Change Manager receives the RFC and approves or rejects it, as appropriate.
 Appropriate entries are made into the CMDB and the RFC is then indicated as a
Change Record.
 The Change Manager allocates a priority to the change, after assessing the Impact
and Urgency.
 The priority can either be “Standard Change” or “Urgent Change”.
 The change is Categorized as “Standard”, “Minor”, “Significant” or “Major”.
 “Standard” changes are usually the low-risk and frequently occurring ones and do
not require authorization by the CAB. Example: upgrading a user’s computer or
replacing a piece of hardware in a user’s computer.
 “Minor” changes are usually authorized by the Change Manager himself who then
informs the CAB later.
 CAB authorization is needed for “Significant” and “Major” changes.
 If the RFC is approved, it is then implemented through the Release Management

https://tnind.wordpress.com
process after circulating a Forward Schedule for Change.
 If the Change is successfully implemented, it is then reviewed by the Change
Manager and closed.
 If the Change is not successful, the Change Manager initiates the back out plan to get
back to the previously working state.
Metrics for measurement of the Change Management process:
 Total number of changes in the defined period.
 Total number of Urgent Changes.
 Total number of changes implemented.
 Total cost for each change as against estimated costs.
 Number of rejected changes.
 9

Change Management Audits should check:

 for compliance to all Change Management procedures.
 all Software releases to ensure they have been through the proper authorization
process.
 all Incident records selected randomly through the change records.
 minutes of CAB meetings.
 Forward Schedules for Change.
 Change review records.

Release Management
What is a Release? A Release is a collection of authorized changes to an IT service.
Release Management is responsible for the implementation of all new and existing
Hardware and Software releases (along with the related documents) into the live
(operational) environment, under the controlling processes of Change Management and
Configuration management. This process is concerned with protecting the live
environment from any disruption and the Release Management activities are usually
performed under the supervision of the Change Manager.

Releases can be classified as:

 Major Software Releases and Hardware Upgrades – This usually contains large
amounts of new functionality and overrides all preceeding minor releases and
upgrades.
 Minor Software Releases and Hardware Upgrades – This usually contains small
amounts of new functionality and overrides all preceeding emergency releases and
upgrades.

https://tnind.wordpress.com
 Emergency Fixes – usually contains fixes to a small number of issues.
All changes are released as “Roll Outs“. A Roll Out includes distributing all the
Configuration Items to wherever they are used. This can be done in many ways,
forexample: by internet, email, remotely or even by sending them on CDs. But when
there are large releases to be rolled out over a vast geographical and cultural area, the
use of automated scripts are a great help. However these scripts might need passwords
to activate them.
Release Management has to maintain traceability of all the releases. We need to know
where a particular version has come from and what are the changes it contains.

The Release Management process covers the following three areas:

 10

 Development area.
 Release Management’s own pre-production area.
 Operational environment (live/production area.)
Migration from one area to another is subject to results from reviews, tests and other
relevant quality checks.

Before a Release is Rolled Out into the live environment, Operational and Customer
Acceptance tests are carried out. Operational tests ensures that anything that goes into
the live environment is supportable, maintainable and robust. All existing and planned
Backout Plans should also be fully tested.

The Contents of each Release is decided by Change Management but the Release
Management team is always kept fully informed.

Hardware and Software Releases go through the following stages before

they are Released into the live environment:
 Distribute.
 Build or Rebuild in the Live environment.
 Implementation.
It is important that each of these stages are carried out accurately before it progresses to
the next one.

Release Management is also responsible for:

 DHS – This is the Definitive Hardware Store. It is a secure location or a number of
locations where authorized versions of all hardware spares (Configuration Items in

https://tnind.wordpress.com
the live environment that exist in the CMDB) are stored.
 DSL – This is the Definitive Software Library. Again, this is a secure location or a
number of locations where copies of all authorized versions of software CI are stored.
(CI stands for Configuration Items). It can also be defined as a Physical library or
repository where master copies of all software versions are stored.
Information about the DHS & DSL exists in the CMDB (Configuration
Management Database) and Configuration Management is responsible to keep
it always updated.
Adequate protection/security should be provided to both the DHS and DSL against
eventualities like floods, earthquakes, fire and of course theft. In case of the DSL, it
should also be protected from viruses, data corruption etc.
 11

Release Unit: A Release Unit is the portion of the IT infrastructure that is normally
released together.
Release Type: There are three Release types which are as given below:
 Full Release – In a Full Release, all components of the release unit are built, tested,
distributed and released together. This is suitable for major changes and is very
expensive.
 Delta Release – In a Delta Release, only those components that have changed
since the last release are distributed. This type of release is best suited for fixes and
emergency changes and is less expensive.
 Package Release – A Package Release is a group of Delta/Full release(s) which are
released simultaneously. This type of release is suitable in situations where changes
in one system may require changes to another.
Release Identification: Each release has to be identified. Usually, a numeric format
is used. The specific release identification policy is generally decided by the Release
Manager, after consulting with the Change Manager and the CAB. Example: A new
application can be assigned an ID like v. 1.0 and a a later, minor release with some
changes to it’s components can be identified as v.1.1. There is really no limit to the
number of such levels that can be used to identify each release.
Roll Out Types: Releases can be rolled out in any/or a combination of the following
ways:
 Big Bang Roll-outs – where all sites in the enterprise receive the releases
simultaneously.
 Phased Roll-outs – where all sites receive some functionality at the same time and
the remaining functionality at a later time.
 Pilot Roll-outs – where a single site receives all the functionality at one time,

https://tnind.wordpress.com
ahead of the others.

Configuration Management
Configuration Management is defined in ITIL as “Asset Management plus
Relationships (with other Configuration Items [CIs]). It is important to consider the
relationships between the CIs as making changes to one component can affect another
CI.
Configuration Management underpins all delivery and support processes and defines IT
assets and services as Configuration Items.
 12

Configuration Item(CI) – A Configuration Item is a part of the ICT infrastructure

(which can be a hardware, software, documentation or peopleware component). This
term can be used to indicate whole systems or just a single hardware/software
component. (In other words, a CI is “any component that has to be managed in order to
deliver an IT service”.) CIs are under the control of the Change Management process.
Configuration Management Database(CMDB) – This is a database of all
Configuration Items (CIs) in the organization. It not only contains full details of
individual components but also contains details of the relationships between them.
Configuration Structure is the hierarchy of all CIs in any configuration.

Configuration Management Plan – is a document that lays out details of

organization and procedures for the Configuration Management of any particular
product or service.
Configuration Management has the responsibility to ensure that:
 the organization has an accurate record of its ICT (Hardware,Software, & Peopleware)
assets.
 all details of the services offerred by the organization and it’s related ICT
components and any relevant supporting documentation.
 any changes to the IT service(s) are done with the least risk to the business.
+ it provides a sound basis for Incident Management, Problem Management, Change
Management & Release Management.
 configuration records are verified against the existing infrastructure and any
exceptions corrected.
Configuration Management has the following sub-processes:
Planning – consists of five sub-processes:

https://tnind.wordpress.com
 Strategy, Policy, Scope and Objectives – to establish an effective Configuration
Management System.
 Processes, Procedures, Guidelines & Responsibilities – to manage and control the
ICT assets.
 Relationship with other ITIL Processes – define how Configuration Management will
interact with other processes or vice-versa.
 Relationship with other Configuration Management teams – to exchange
information with CMDBs of suppliers, external vendors, developers etc.
 Tools & Resource Requirements – to connect the CMDB to the system and network
management tools to enable the automatic addition of CIs to the CMDB.
 13

Identification – accurately identifying and labeling the CIs with IDs, versions, types
and their relationships to other CIs.
Control – this has three sub-processes:
 Register – registering a CI when it enters the IT infrastructure.
 Update – updating the status of the CI to reflect it’s most current status.
 Archive – removing the CI from the CMDB and archiving it in a secure location.
Status Accounting – is concerned with reporting of all current & historical data about
each CI throughout it’s life cycle.
Verification – (Verification & Audit) is responsible to ensure that the information
contained in the CMDB exactly matches the live environment.
The Configuration Management Database (CMDB) – Configuration Management
monitors the relationships between Configuration Items. It stores all details about these
relationships (between CIs) in a CMDB.
A typical CMDB should contain the following information – refer to the
image below:
 Details about the ICT components (Hardware, Software, Peopleware and related
documents).
 All the services offerred by the organization and related CIs and the relationships
between these CIs.
 Details of all Incidents, Problems and Known errors.
 Details about all Changes & Releases.

ITIL – CMDB
The CMDB contains the DHS (Definitive Hardware Store) and DSL (Definitive
Software Library) which is managed by the Release Management process.

https://tnind.wordpress.com