ITIL Incident Management

'Real World' definition of Incident Management: IM is the way that the Service Desk puts
out the 'daily fires'.

An 'Incident' is any event which is not part of the standard operation of the service and
which causes, or may cause, an interruption or a reduction of the quality of the service.

The objective of Incident Management is to restore normal operations as quickly as

possible with the least possible impact on either the business or the user, at a cost-
effective price.

Inputs for Incident Management mostly come from users, but can have other sources as
well like management Information or Detection Systems. The outputs of the process are
RFC’s (Requests for Changes), resolved and closed Incidents, management information
and communication to the customer.

Activities of the Incident Management process:

Incident detection and recording

Classification and initial support
Investigation and diagnosis
Resolution and recovery
Incident closure
Incident ownership, monitoring, tracking and communication

These elements provide a baseline for management review.

Incident Management Quick Overview

Mission Statement
Restore normal state IT service operations as quickly as possible to minimize the adverse
impact on business operations.

Process Goal Achieve the process mission by implementing:

• ITIL-aligned Incident Management Policies, Processes and Procedures
• Incident escalation standards
• Dedicated Incident Management Process Owner
• Incident classification categories
• Incident reports
• Incident communications and education for IT staff
Critical Success Factors (CSFs)
The Critical Success Factors are:
• Maintaining IT Service Quality
• Maintaining Customer Satisfaction
• Resolving Incidents Within Established Service Times

Key Activities The key activities for this process are:

• Detect and record incidents
• Classify incidents
• Provide initial incident support
• Prioritize incidents based on impact and urgency
• Investigate and diagnose incidents
• Resolve incidents and recover service per agreed service levels
• Close incidents
• Maintain ownership, monitoring, tracking and communications about incidents
• Provide management information about Incident Management quality and operations

Key Performance Indicators (KPIs) Examples of Key Process Performance Indicators

(KPIs) are shown in the list below. Each one is mapped to a Critical Success Factor
(CSF).

Maintaining IT Service Quality

• Number of Severity 1 incidents (total and by category)

• Number of Severity 2 incidents (total and by category)
• Number of other incidents (total and by category)
• Number of incidents incorrectly categorized
• Number of incidents incorrectly escalated
• Number of incidents bypassing Service Desk
• Number of incidents not closed/resolved with workarounds
• Number of incidents resolved before customers notice
• Number of incidents reopened

Maintaining Customer Satisfaction

• Number of User/Customer surveys sent

• Number of User/Customer surveys responded to
• Average User/Customer survey score (total and by question category)
• Average queue time waiting for Incident response

Resolving Incidents Within Established Service Times

• Number of incidents logged

• Number of incidents resolved by Service Desk
• Number of incidents escalated by Service Desk
• Average time to restore service from point of first call
• Average time to restore Severity 1 incidents
• Average time to restore Severity 2 incidents

The Difference Between Incident Management And Problem Management

Incidents and Service Requests are formally managed through a staged process to
conclusion. This process is referred to as the "Incident Management Lifecycle". The
objective of the Incident Management Lifecycle is to restore the service as quickly as
possible to meet Service Level Agreements. The process is primarily aimed at the user
level.

Problem Management deals with resolving the underlying cause of one or more
Incidents. The focus of Problem Management is to resolve the root cause of errors and to
find permanent solutions. Although every effort will be made to resolve the problem as
quickly as possible this process is focused on the resolution of the problem rather than the
speed of the resolution. This process deals at the enterprise level.

Incidents, problems and known errors

Incidents may match with existing 'Problems' (without a known root cause) or 'Known
Errors' (with a root cause) under the control of Problem Management and registered in
the Known Error Database ( KeDB ). Where existing work-arounds have been developed,
it is suggested that accessing these will allow the Service Desk to provide a quick first-
line fix. Where an incident is not the result of a Problem or Known Error, it may either be
an isolated or individual occurrence or may (once the initial issue has been addressed)
require that Problem Management become involved, possibly resulting in a new problem
record being raised.
Incidents and changes
Incidents are the result of failures or errors in the IT infrastructure. The cause of Incidents
may be apparent and the cause may be addressed without the need for further
investigation, resulting in a repair, a Work-around or a request for change (RFC) to
remove the error.
Where an incident is considered to be serious in nature, or multiple occurrences of similar
incidents are observed, a problem record might be created as a result (it's possible that the
Problem will not be recorded until several incidents have occurred). The management of
a problem varies from the process of managing an incident and is typically performed by
different staff and therefore is controlled by the Problem Management process. When its
'root cause' has been identified, it becomes a 'known error'. Finally, a request for change
(RFC) may be raised to modify the system by resolving the known error. This process is
covered by the Change Management process.
A request for new additional service is not regarded as an incident, but as a Request for
Service (RFS).

Incident management processes

The main incident management processes are the following:
Incident detection and recording
Classification and initial support
Investigation and diagnosis
Resolution and recovery
Incident closure
Incident ownership, monitoring, tracking and communication
Establish incident framework management
Evaluation incident framework management

Examples
Incidents should be classified as they are recorded, Examples of incidents by
classification are:
Application
service not available
application bug
disk-usage threshold exceeded
Hardware
system-down
automatic alert
printer not printing

ITIL spends lots of time on the things you could do but little time on the basics
required to get started. This leads to lots of questions about where to start,
understanding how much you are already doing, and even when to stop and move
on to the next process or activity.
ITIL v3 defines an Incident as an unplanned interruption to service, or a reduction
in the quality of a service. Incident Management (IM) is the term used to describe
the process responsible for managing incidents. The main goal of IM is to restore
service to users as quickly as possible. When you handle a call or email from a
customer or user experiencing something wrong with a service you provide, you
are "doing" IM. ITIL explains the reasons for Incident Management and how to
setup an Incident Management process.
Related Articles
ITIL: Listen to Your Admins
ITIL Service Management for Enterprise Networks
Understanding ITIL for Network Service Delivery
There are many aspects to carrying out IM (explained in detail within ITIL), however,
there are just six things you need to do. If you do these six things consistently then there
is a very good chance you are "doing" IM well enough to achieve the benefits the ITIL
describes ...