Problem Management

Problem Management
http://wiki.en.itprocessmaps.com/index.php/Problem_Management#Problem_Record
Objective: The objective of ITIL Problem Management is to manage the lifecycle of all
Problems. The primary objectives of Problem Management are to prevent Incidents from
happening, and to minimize the impact of incidents that cannot be prevented. Proactive
Problem Management analyzes Incident Records, and uses data collected by other IT
Service Management processes to identify trends or significant Problems.
Part of: Service Operation
Process Owner: Problem Manager
Contents
[hide]
1Process Description
2Sub-Processes
3Definitions
4Templates | KPIs
5Roles | Responsibilities
6[ Infobox ]
Process Description
Essentially, the activities and process objectives of ITIL Problem Management are
identical in ITIL V3 and ITIL V2.
ITIL Problem Management

A new sub-process Major Problem Review was introduced in ITIL V3 to review the
solution history of major Problems in order to prevent a recurrence and learn lessons for
the future.
In ITIL 2011 the new sub-process Proactive Problem Identification has been added to
emphasize the importance of proactive Problem Management.
In Problem Categorization and Prioritization, it has been made clearer that categorization
and prioritization should be harmonized with the approach used in Incident Management,
to facilitate matching between Incidents and Problems. The process overview of ITIL
Problem Management is showing the most important interfaces (see Figure 1).
The concept of recreating Problems during Problem Diagnosis and Resolution is now
more prominent. This sub-process has been completely revised to provide clearer
guidance on how this process cooperates with Incident Management.
Note: The new ITIL 2011 books also contain an expanded section on problem analysis
techniques and examples for situations where the various techniques may be applied.
Sub-Processes
These are the ITIL Problem Management sub-processes and their process objectives:
Proactive Problem Identification
Process Objective: To improve overall availability of services by proactively

identifying Problems. Proactive Problem Management aims to identify and solve
Problems and/or provide suitable Workarounds before (further) Incidents recur.
Problem Categorization and Prioritization
Process Objective: To record and prioritize the Problem with appropriate

diligence, in order to facilitate a swift and effective resolution.
Problem Diagnosis and Resolution
Process Objective: To identify the underlying root cause of a Problem and initiate
the most appropriate and economical Problem solution. If possible, a
temporary Workaround is supplied.
Problem and Error Control
Process Objective: To constantly monitor outstanding Problems with regards to

their processing status, so that where necessary corrective measures may be
introduced.
Problem Closure and Evaluation
Process Objective: To ensure that - after a successful Problem solution the Problem Record contains a full historical description, and that related Known
Error Records are updated.
Major Problem Review
Process Objective: To review the resolution of a Problem in order to prevent

recurrence and learn any lessons for the future. Furthermore it is to be verified
whether the Problems marked as closed have actually been eliminated.
Problem Management Reporting
Process Objective: ITIL Problem Management Reporting aims to ensure that the
other Service Management processes as well as IT Management are informed of
outstanding Problems, their processing-status and existing Workarounds (see
"Problem Management Report").
Definitions
The following ITIL terms and acronyms (information objects) are used in the ITIL
Problem Management process to represent process outputs and inputs:
Known Error
A Known Error is a problem that has a documented root cause and a Workaround.
Known Errors are managed throughout their lifecycle by the Problem
Management process. The details of each Known Error are recorded in a Known
Error Record stored in the Known Error Database (KEDB). As a rule, Known
Errors are identified by Problem Management, but Known Errors may also be
suggested by other Service Management disciplines, e.g. Incident Management, or
by suppliers.
Known Error Database (KEDB)
The Known Error Database (KEDB) is created by Problem Management and used
by Incident and Problem Management to manage allKnown Error Records.
Problem
A cause of one or more Incidents. The cause is not usually known at the time
a Problem Record is created.
Problem Management Report
A report supplying Problem-related information to the other Service Management

processes.
Problem Record
The Problem Record contains all details of a Problem, documenting the history of
the Problem from detection to closure (see: ITIL Checklist Problem Record).
Suggested new Known Error
A suggestion to create a new entry in the Known Error Database, for example
raised by the Service Desk or by Release Management. Known Errors are
managed throughout their lifecycle by Problem Management.
Suggested new Problem
A notification about a suspected Problem, handed over to Problem Management

for further investigation, possibly leading to the formal logging of a Problem.
Suggested new Workaround
A suggestion to enter a new Workaround in the Known Error Database, for

example raised by the Service Desk or by Release Management. Workarounds are
managed throughout their lifecycle by Problem Management.
Workaround
Workarounds are temporary solutions aimed at reducing or eliminating the impact

of Known Errors (and thus Problems) for which a full resolution is not yet
available. As such, Workarounds are often applied to reduce the impact
of Incidents or Problems if their underlying causes cannot be readily identified or
removed.
Templates | KPIs
Key Performance Indicators (KPIs) Problem Management

Problem Management templates and checklists:
Checklist Problem Record, and

Checklist Problem Priority
Checklist Closure of a Problem
Problem Report template
Roles | Responsibilities
Problem Manager - Process Owner
The Problem Manager is responsible for managing the lifecycle of all Problems.
His primary objectives are to prevent Incidents from happening, and to minimize
the impact of Incidents that cannot be prevented.
To this purpose he maintains information about Known Errors and Workarounds.
Responsibility Matrix: ITIL Problem Management

Problem
Manager
ITIL Role | Sub-Process
Applications
Analyst[3]
Technical
Analyst[3]
Proactive Problem Identification
A[1]R[2]
Problem Categorization and

Prioritization
AR
Problem Diagnosis and Resolution
AR
Problem and Error Control
AR
Problem Closure and Evaluation
AR
Major Problem Review
AR
Problem Management Reporting
AR
Remarks
[1] A: Accountable according to the RACI Model: Those who are ultimately accountable
for the correct and thorough completion of the Problem Management process.
[2] R: Responsible according to the RACI Model: Those who do the work to achieve a
task within Problem Management.
[3] see Role descriptions...
[ Infobox ]
Link to this
page:
http://wiki.en.itprocessmaps.com/index.php/Problem_Management
Languages:
English | Deutsch | espaol
Image:
ITIL Problem Management (.JPG)
Author:
Stefan Kempter, IT
Process Maps
Process Description Sub-Processes Definitions Templates Roles

Categories:
ITIL V3
ITIL 2011
ITIL process
Service Operation
Problem Management
TIL KPIs Service Operation
ITIL Process: Service Operation according to ITIL 2011

Source: Key Performance Indicators for ITIL Service Operation from the ITIL Process
Map
back to: ITIL Key Performance Indicators
Contents
[hide]
1ITIL KPIs Incident Management

2ITIL KPIs Problem Management
3[ Infobox ]
ITIL KPIs Incident Management

Key Performance Indicator
(KPI)
Number of repeated Incidents
Definition
Number of repeated Incidents, with known

resolution methods
Number of Incidents resolved remotely by the

Service Desk
(i.e.without carrying out work at user's location)
Number of escalations for Incidents not resolved

in the agreed resolution time
Incidents resolved Remotely
Number of Escalations
Number of incidents registered by the Service

Desk
grouped into categories
Average time taken between the time a user

reports an Incident and the time that the Service
Desk responds to that Incident
Average time for resolving an incident
Percentage of Incidents resolved at the Service

Desk during the first call
Rate of incidents resolved during solution times

agreed in SLA
Average work effort for resolving Incidents
Number of Incidents
Average Initial Response Time
Incident Resolution Time
First Time Resolution Rate
Resolution within SLA
Incident Resolution Effort
ITIL KPIs Problem Management

Key Performance Indicator
(KPI)
Definition
Number of Problems registered by Problem

Management
Average time for resolving Problems
Number of unresolved
Problem
Number of Problems where the underlying root

cause is not known at a particular time
Number of Incidents per
Number of reported Incidents linked to the same
Number of Problems
Problem Resolution Time
Known Problem
Time until Problem
Identification
Problem after problem identification
Average time between first occurance of an

Incident and identification of the underlying root
cause
Average work effort for resolving Problems
Problem Resolution Effort
ITIL-Checklists
This set of ITIL templates (ITIL document templates) can be used as checklists for
defining ITIL process outputs. The ITIL templates can also serve as guidelines which are
helpful during process execution.
During the process of updating the ITIL Process Map to ITIL V3 2011 Edition, we also
aligned our set of free ITIL templates and checklists to ITIL 2011. At the same time we
took the opportunity to revise and enhance the ITIL document templates, taking into
account customer feedback on the V3 versions.
There are now 102 checklists contained in our ITIL-2011-compliant Reference Process
Model, and we make the most sought-after ITIL templates available for you in our ITIL
Wiki.
Contents
[hide]
1ITIL 2011 Templates
2Most popular ITIL Templates
1.1ITIL Service Strategy Templates

1.2ITIL Service Design Templates
1.3ITIL Service Transition Templates
1.4ITIL Service Operation Templates
1.5ITIL CSI Templates
2.1Incident Record Template

2.2Service Portfolio Template
2.3Request for Change (RFC)
2.4Checklist CMS/ CMDB
3Templates per ITIL Process
3.1Incident Management / Service Desk

3.2Problem Management
3.3Change Management
3.4Release Management
3.5Configuration Management
3.6Design Coordination
3.7Service Level Management
3.8Capacity Management
3.9Availability Management
3.10IT Service Continuity Management
3.11Supplier Management
3.12Financial Management
3.13Service Portfolio Management
3.14Service Review
3.15Definition of CSI Initiatives
4[ Infobox ]
ITIL 2011 Templates

The following ITIL 2011 templates were submitted to an official review by APM Group;
they are thus officially ITIL licensed. These ready-to-use templates and checklists are
also a good starting point for designing ISO 20000 compliant documents and records.
ITIL
Service Strategy Templates
Service Portfolio
Financial Analysis
ITIL Service Design Templates
Service Level Agreement/ Operational Level Agreement (SLA OLA)

Service Design Package (SDP)
Capacity Plan
Underpinning Contract (UC)
ITIL Service Transition Templates
Request for Change (RFC)

Release Policy
Configuration Management System/ Databases (CMS/ CMDB)
ITIL Service Operation Templates
Incident Record
Incident Prioritization Guideline
Problem Record
ITIL CSI Templates
Service Review Report

CSI Register (Service Improvement Plan - SIP)
Most popular ITIL Templates
These are the most

sought-after, officially
licensed ITIL 2011
templates and
checklists:
Incident Record
Template
An "Incident" is
defined as an unplanned
interruption or
reduction in quality of
an IT service. The
details of an Incident and its complete history from registration to resolution are recorded
in an Incident Record.
The Incident Record template explains the structure of the data typically contained in an
Incident Record. You can use this checklist as a template when you start creating Incident
Records in your own organization.
Go to template ...
Service Portfolio Template
Are you looking for a Service Portfolio template? Our checklist will help you to get
started:
The Service Portfolio represents a complete list of the services managed by the service
provider. It contains present contractual commitments, new service development, and
retired services. This template lists the tyypical items the Service Portfolio should
include:
Details: Service Portfolio ...
A Request for Change is formal request for the implementation of a Change. An RFC,
specifying the details of a proposed Change, must be submitted to Change Management
for every non-standard Change. The RFC template explains what information is typically
contained in an RFC.
ITIL RFC template: ...
Checklist CMS/ CMDB
The CMS/ CMDB template explains the concept of the Configuration Model. It highlights
which information is typically held in the Configuration Management System (CMS) or
in Configuration Management Databases (CMDBs) to describe Configuration Items
(CIs).
Checklist CSM/ CMDB: ...
Templates per ITIL Process
If you are
looking for a
set of free
ITIL
templates,
here a basic
collection of
templates and
checklists
from our ITIL
Process Map:
Incident
Management / Service Desk
Checklist Incident Record

Checklist Incident Priority
Checklist Initial Analysis of an Incident
Checklist Incident Escalation
Checklist Closure of an Incident
Checklist Incident Report
Problem Management
Checklist Problem Record

Checklist Problem Report
Change Management
Checklist Request for Change RFC

Checklist Change Record
Checklist Change Classification
Checklist CAB Agenda
Checklist Forward Schedule of Changes (FSC)
Checklist Post Implementation Review (PIR)
Release Management
Checklist Release Policy

Checklist Release Plan
Configuration Management
Checklist CMS CMDB

Checklist Configuration Item (CI) Record
Checklist CMDB Audit Protocol
Design Coordination
Checklist Service Design Package SDP
Service Level Management
Checklist SLA OLA

Checklist Service Level Requirements (SLR)
Checklist Service Specification Sheet
Checklist Service Catalogue
Checklist Service Level Report
Checklist Protocol SLA Review
Checklist Service Quality Plan (SQP)
Capacity Management
Checklist Capacity Plan

Checklist Capacity Forecast
Checklist Capacity Report
Availability Management
Checklist Availability Improvement Plan

Checklist Availability Report
IT Service Continuity Management
Checklist ITSCM Risk Analysis

Checklist IT Service Continuity Plan
Checklist ITSCM Report

Checklist Emergency Plan
Checklist ProtocolDisaster Practice
Supplier Management
Checklist Underpinning Contract (UC)
Financial Management
Checklist Financial Analysis
Service Portfolio Management
Checklist Service Portfolio
Service Review
Checklist Service Review Report
Definition of CSI Initiatives
Checklist CSI Register (Service Improvement Plan - SIP)
[ Infobox ]
Link to this
page:
http://wiki.en.itprocessmaps.com/index.php/ITIL-Checklists
Languages:
Image:
ITIL Templates (.JPG)
Author:
Stefan Kempter, IT
ITIL-Checklists
Process Maps
Wiki.
Contents
[hide]



3.14Service Review
4[ Infobox ]
ITIL 2011 Templates

ITIL
Service Portfolio
Financial Analysis

Capacity Plan

Release Policy
Incident Record
Problem Record
ITIL CSI Templates

These are the most

licensed ITIL 2011
templates and
checklists:
Incident Record
Template
An "Incident" is
interruption or
an IT service. The
details of an Incident
and its complete history
from registration to
resolution are recorded in an Incident Record.
Go to template ...
started:
include:

Checklist CMS/ CMDB
(CIs).
If you are
looking for a
set of free
ITIL
templates,
here a basic
collection of
templates and
checklists
from our ITIL
Process Map:
Incident


Problem Management

Change Management

Release Management

Checklist CMS CMDB

Design Coordination
Checklist SLA OLA


Capacity Management



Supplier Management
Service Review
[ Infobox ]
Link to this
page:
Languages:
Image:
Author:
Stefan Kempter, IT
Process Maps
ITIL Process: ITIL 2011 Service Operation - Problem Management

Checklist Category: Templates ITIL 2011 - Service Operation
Source: Checklist "Problem Record" from the ITIL Process Map
Contents
[hide]
1Overview
2Problem Record - Contents
2.1Unique ID
2.2Date and time of detection
2.3Problem owner
2.4Description of symptoms
2.5Affected users/ business areas
2.6Affected service(s)
2.7Problem priority
2.8Relationships to CIs
2.9Problem category
2.10Links to related Problem Records
2.11Links to related Incident Records
2.12Links to related Known Errors and Workarounds
2.13Links to RFCs/ Change Records
2.14Problem status change history
2.15Activity log
3[ Infobox ]
Overview
Fig.
1: ITI
L
Problem Record - Definition and information flow.

The Problem Record contains all details of a Problem, documenting the history of the
Problem from detection to closure.
Problem Record - Contents

A Problem Record typically contains the following information:
Unique ID
(Unique ID of the Problem - usually allocated automatically by the system)
Date and time of detection
Problem owner
Description of symptoms
Affected users/ business areas
Affected service(s)
Problem priority
Priority, a function of the following components:
1. Urgency (available time until the resolution of the Problem)
2. Impact (damage caused or potential damage to the business or IT infrastructure)
3. Priority (for example expressed in codes like "Critical", "High", "Medium",
"Low", "Very Low"): The result from the combination of urgency and impact
(Note: Prioritization of Problems should follow the same rules as the prioritization of
Incidents; for further information, refer to the checklistIncident Prioritization Guideline)
Relationships to CIs
(Relationships to Configuration Items (CIs))
Problem category
Problem category, usually selected from a category-tree according to the following
example:
1. Hardware error
1. Server A
1. Component x
1. Symptom a
2. Symptom b
2. Component y
3.
1. Server B
2.
1. Software error
1. System A
2. System B
3.
2. Network error
3. ...
(Note: Problem categories should be harmonized with Incident categories to support
matching between Incidents and Problems)
Links to related Problem Records
(Links to related Problem Records - if there are other outstanding Problems related to this
one)
Links to related Incident Records

(Links to related Incident Records - if outstanding Incidents exist, whose solution
depends on the solution of this Problem)
Links to related Known Errors and Workarounds
(Links to Known Errors and Workarounds - if Known Errors and Workarounds related to
the Problem have been identified)
Links to RFCs/ Change Records
(Links to RFCs/ Change Records associated with the solution of the Problem)
Problem status change history
1.
2.
3.
4.
Date and time

Person in charge
Reason for status change
New Problem status
Activity log
Activity log/ Tasks assigned to the Problem: Most service desk systems allow
maintaining a simple log of steps carried out to resolve the Problem. Some systems,
however, also provide the means to assign "Tasks" to Problems. Akin to the Problems
they are assigned to, Tasks are typically characterized by properties like name,
description, owner, priority, etc. and contain a status history and activity log of their own.
ITIL Process: ITIL 2011 Service Operation - Problem Management

Source: Checklist "Problem Record" from the ITIL Process Map
Contents
[hide]
1Overview
2Problem Record - Contents
2.1Unique ID
2.2Date and time of detection
2.3Problem owner
2.4Description of symptoms
2.5Affected users/ business areas
2.6Affected service(s)
2.7Problem priority
2.8Relationships to CIs
2.9Problem category
2.10Links to related Problem Records
2.11Links to related Incident Records
2.12Links to related Known Errors and Workarounds
2.13Links to RFCs/ Change Records
2.14Problem status change history
2.15Activity log
3[ Infobox ]
Overview
Fig.
1: ITI
L
Problem Record - Definition and information flow.

The Problem Record contains all details of a Problem, documenting the history of the
Problem from detection to closure.
Problem Record - Contents

A Problem Record typically contains the following information:
Unique ID
(Unique ID of the Problem - usually allocated automatically by the system)
Date and time of detection
Problem owner
Description of symptoms
Affected users/ business areas
Affected service(s)
Problem priority
Priority, a function of the following components:
1. Urgency (available time until the resolution of the Problem)
2. Impact (damage caused or potential damage to the business or IT infrastructure)
3. Priority (for example expressed in codes like "Critical", "High", "Medium",
"Low", "Very Low"): The result from the combination of urgency and impact
(Note: Prioritization of Problems should follow the same rules as the prioritization of
Incidents; for further information, refer to the checklistIncident Prioritization Guideline)
(Relationships to Configuration Items (CIs))
Problem category
Problem category, usually selected from a category-tree according to the following
example:
1. Hardware error
1. Server A
1. Component x
1. Symptom a
2. Symptom b
2. Component y
3.
1. Server B
2.
1. Software error
1. System A
2. System B
3.
2. Network error
3. ...
(Note: Problem categories should be harmonized with Incident categories to support
matching between Incidents and Problems)
Links to related Problem Records
(Links to related Problem Records - if there are other outstanding Problems related to this
one)
Links to related Incident Records
(Links to related Incident Records - if outstanding Incidents exist, whose solution
depends on the solution of this Problem)
Links to related Known Errors and Workarounds
(Links to Known Errors and Workarounds - if Known Errors and Workarounds related to
the Problem have been identified)
Links to RFCs/ Change Records
(Links to RFCs/ Change Records associated with the solution of the Problem)
Problem status change history
1.
2.
3.
4.
Date and time

Person in charge
Reason for status change
New Problem status
Activity log
Activity log/ Tasks assigned to the Problem: Most service desk systems allow
maintaining a simple log of steps carried out to resolve the Problem. Some systems,
however, also provide the means to assign "Tasks" to Problems. Akin to the Problems
they are assigned to, Tasks are typically characterized by properties like name,
description, owner, priority, etc. and contain a status history and activity log of their own.
ITIL Process: ITIL Service Operation - Problem Management

Checklist Category: ITIL Templates - Problem Management
Source: Checklist "Problem Priority" from the ITIL Process Map V2
The priority of a Problem is assigned according to the following rules:
Urgency (available time until the resolution of the Problem), e.g.
Degree of severity (damage caused to the business), e.g.
1: up to 4 hrs.
2: up to 1 day
3: up to 5 days
1: High (interruption to critical business processes)

2: Normal (interruption to the work of individual employees)
3: Low (hindrance to the work of individual employees, continuation of
work possible by means of a circumventive solution)
Priority (e.g. in stages 1, 2 and 3): A function of urgency and the degree of
severity

Source: Checklist "Closure of a Problem" from the ITIL Process Map V2
The following entries are investigated with regards to their completeness and integrity
during the closure of a Problem:
Protocol of actions
History of the change in status, e.g.
Person in charge
Support group
Time and date
Description of the activity
New into Initial Analysis Completed

Initial Analysis Completed into Assigned to Specialists
...
Resolved into Closed
Documentation of the root cause of the Problem (Known Error)

Documentation of possible Workarounds
Documentation of the applied (causal) resolution
Date of Problem resolution
Date of Problem closure

Source: Checklist "Problem Report" from the ITIL Process Map V2
The Problem Manager's report includes the following information:
Statistical evaluations
Outstanding Problems
According to duration since creation of the Problem Record
According to categories
Resolution times of closed Problems
According to duration
Trend analyses
Problems with special importance regarding Availability, Capacity, IT Service
Continuity and IT Security Management
Description
Problem cause
Applied resolution strategy
Elimination of the root cause

Possible Workarounds
Time schedule for the resolution of the Problem
Other important Problems with extensive effects upon the quality of the IT
Services
Description
Problem cause


Source: Checklist "Problem Report" from the ITIL Process Map V2
The Problem Manager's report includes the following information:
Outstanding Problems
According to duration since creation of the Problem Record
Resolution times of closed Problems
Trend analyses
Problems with special importance regarding Availability, Capacity, IT Service
Continuity and IT Security Management
Description
Problem cause

Other important Problems with extensive effects upon the quality of the IT
Services
Description
Problem cause

TIL-Checklists
Wiki.
Contents
[hide]



3.14Service Review
4[ Infobox ]
ITIL 2011 Templates

ITIL
Service Portfolio
Financial Analysis

Capacity Plan

Release Policy
Incident Record
Problem Record
ITIL CSI Templates

These are the most

licensed ITIL 2011
templates and
checklists:
Incident Record
Template
An "Incident" is
interruption or
an IT service. The
details of an Incident
and its complete history
from registration to
resolution are recorded in an Incident Record.
Go to template ...
started:
include:

Checklist CMS/ CMDB
(CIs).
If you are
looking for a
set of free
ITIL
templates,
here a basic
collection of
templates and
checklists
from our ITIL
Process Map:
Incident


Problem Management

Change Management

Release Management

Checklist CMS CMDB

Design Coordination
Checklist SLA OLA


Capacity Management



Supplier Management
Service Review
[ Infobox ]
Link to this
page:
Languages:
Image:
Author:
Stefan Kempter, IT
Process Maps
ITIL Process: ITIL 2011 Service Operation - Incident Management

Source: Checklist "Incident Prioritization Guideline" from the ITIL Process Map
Contents
[hide]
1Overview
2Incident Urgency (Categories of Urgency)
3Incident Impact (Categories of Impact)
4Incident Priority Classes
5Circumstances that warrant the Incident to be treated as a Major Incident
4.1Incident Priority Matrix
5.1Indicators
5.2Identifying Major Incidents
5.3Major Incidents - Key Characteristics
6[ Infobox ]
Overview
The Incident
Prioritization
Guideline des
cribes the
rules for
assigningprio
rities to
Incidents,
including the
definition of
what
constitutes
aMajor
Incident.
Since Incident
Management
escalation rules are usually based on priorities, assigning the correct priority to an
Incident is essential for triggering appropriate Incident escalations.
An Incident's priority is usually determined by assessing its impact and urgency,
where
Urgency is a measure how quickly a resolution of the Incident is required

Impact is measure of the extent of the Incident and of the potential damage caused
by the Incident before it can be resolved.
Incident Urgency (Categories of Urgency)

This section establishes categories of urgency. The definitions must suit the type of
organization, so the following table is only an example:
To determine the Incidents urgency, choose the highest relevant category:
Category
High (H)
Description
The damage caused by the Incident increases rapidly.
Work that cannot be completed by staff is highly time sensitive.
A minor Incident can be prevented from becoming a major Incident by

acting immediately.
Medium (M)
Low (L)
Several users with VIP status are affected.
The damage caused by the Incident increases considerably over time.
A single user with VIP status is affected.
The damage caused by the Incident only marginally increases over time.
Work that cannot be completed by staff is not time sensitive.
Incident Impact (Categories of Impact)

This section establishes categories of impact. The definitions must suit the type of
organization, so the following table is only an example:
To determine the Incidents impact, choose the highest relevant category:
Category
High (H)
Description
A large number of staff are affected and/or not able to do their job.
A large number of customers are affected and/or acutely disadvantaged in

some way.
The financial impact of the Incident is (for example) likely to exceed

$10,000.
Medium (M)
The damage to the reputation of the business is likely to be high.
Someone has been injured.
A moderate number of staff are affected and/or not able to do their job
properly.
A moderate number of customers are affected and/or inconvenienced in

some way.
The financial impact of the Incident is (for example) likely to exceed

$1,000 but will not be more than $10,000.
Low (L)
The damage to the reputation of the business is likely to be moderate.
A minimal number of staff are affected and/or able to deliver an acceptable

service but this requires extra effort.
A minimal number of customers are affected and/or inconvenienced but

not in a significant way.
The financial impact of the Incident is (for example) likely to be less than
$1,000.
The damage to the reputation of the business is likely to be minimal.
Incident Priority Classes

Incident Priority is derived from urgency and impact.
Incident Priority Matrix
If classes are defined to rate urgency and impact (see above), an Urgency-Impact
Matrix (also referred to as Incident Priority Matrix) can be used to define priority classes,
identified in this example by colors and priority codes:
Impact
H M N
H 1 2 3
Urgenc
M 2 3 4
y
L 3 4 5
Priority
Code
Descripti
on
Target Response
Time
Target Resolution
Time
Critical
Immediate
1 Hour
High
10 Minutes
4 Hours
Medium
1 Hour
8 Hours
Low
4 Hours
24 Hours
Very low
1 Day
1 Week
Circumstances that warrant the Incident to

be treated as a Major Incident
Major Incidents call for the establishment of a Major Incident Team and are managed
through the Handling of Major Incidents process.
Indicators
The above prioritization scheme notwithstanding, it is often appropriate to define
additional, readily understandable indicators for identifying Major Incidents (see also the
comments below on identifying Major Incidents). Examples for such indicators are:
1. Certain (groups of) business-critical services, applications or infrastructure
components are unavailable and the estimated time for recovery is unknown or
exceedingly long (specify services, applications or infrastructure components)
2. Certain (groups of) Vital Business Functions (business-critical processes) are
affected and the estimated time for restoring these processes to full operating
status is unknown or exceedingly long (specify business-critical processes)
Identifying Major Incidents

It is not easy to give clear guidelines on how to identify major incidents although the 1st
Level Support often develops a "sixth sense" for these. It is also probably better to err on
the side of caution in this respect.
A Major incidents tend to be characterized by its impact, especially on customers.
Consider some examples:
A high speed network communications link fails and part of or all data
communication to and from outside the organization is cut off.
A website grinds to a halt because of unexpected heavy demand prior to a
deadline (for example to reserve tickets or make a legal submission) resulting in
large numbers of customers failing to meet that deadline.
A key business database is found to be corrupted.
More than one business server is infected by a worm.
The private and confidential information of a significant number of individuals is
accidentally disclosed in a public forum.
Note also that all disasters (covered by the IT Service Continuity Strategy and
underpinning ITSCM Plans) are Major Incidents and that smaller incidents that are
compounded by errors or inaction can become major incidents.
Major Incidents - Key Characteristics

Some of the key characteristics that make these Major Incidents are:
The ability of significant numbers of customers and/or key customers to use

services or systems is or will be affected.
The cost to customers and/or the service provider is or will be substantial, both in
terms of direct and indirect costs (including consequential loss).
The reputation of the Service Provider is likely to be damaged.
AND
The amount of effort and/or time required to manage and resolve the incident is
likely to be large and it is very likely that agreed service levels (target resolution
times) will be breached.
A Major Incident is also likely to be categorized as a critical or high priority incident.
Checklist Initial Analysis of an

Incident
ITIL Process: ITIL Service Operation - Incident Management

Checklist Category: ITIL Templates - Incident Management / Service Desk
Source: Checklist "Initial Analysis of an Incident" from the ITIL Process Map V2
Using the assignment of the Incident to CIs and to Product and Incident categories, the
Support Knowledge Base is searched for:
Known Solutions
Known Workarounds
Known Errors
If it becomes apparent during the initial analysis that the attributions originally assigned
were not applicable, these are corrected:
Product category, usually selected from a category-tree according to the following
example
Client PC
Standard configuration 1
...
Printer
Manufacturer 1
...
Incident category, i.e.
Hardware error
Software error
...

Source: Checklist "Incident Escalation" from the ITIL Process Map V2
The Escalation of Incidents follows pre-defined rules:
Defined triggers for Escalations, i.e. combinations of
Degree of severity of an Incident (severe Incidents are, for example,

immediately escalated)
Duration (an Escalation occurs, if the Incident was not resolved within a
pre-determined period, as for example the maximum resolution times
agreed within the SLAs)
In an ideal case this would be system-controlled triggered by customisable
Escalation rules
Defined Escalation levels in the form of an Escalation Hierarchy, for example
1st Level Support

Incident Manager
Manager of Data Processing Centre

CIO
Assigned triggers to the Escalation Hierarchy (conditions/ rules, which lead to the
Escalation to a particular level within the Escalation Hierarchy)

Source: Checklist "Closure of an Incident" from the ITIL Process Map V2
The following entries of an Incident Record are investigated for their integrity and
completeness during the closure of an Incident:
Protocol of actions
History of status changes, for example
Person in charge
Support Group
Time and Date
Description of the activity
"New" into "Initial Analysis Completed"

"Initial Analysis Completed" into "Assigned to 2nd Level Support"
...
"Resolved" into "Closed"
Documentation of applied Workarounds

Documentation of the root cause of the Service interruption
Documentation of the applied resolution to eliminate the root cause
Date of the Incident resolution
Date of the Incident closure

Source: Checklist "Incident Report" from the ITIL Process Map V2
The Incident Manager's report includes the following information:
Adherence to agreed Service Levels
Agreed Service Levels

Attained Service Levels
Major Incidents causing breaches of agreed IT Service Levels
In the past (prolonged IT Service failures etc.)
Type of event
Causes
Counter-measures for the elimination of the Incident
Measures for the future avoidance of similar occurrences
In the future (e.g. planned prolonged downtimes to IT Services)
Number of Incidents
Resolution times
Initial resolution rate
Over time
Over time
Trend analyses
Technical analysis of important or repetitive Incidents
Description

Workaround

Problem Management

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Problem Management

Uploaded by

Copyright:

Available Formats

Problem Management

ITIL Problem Management

Process Objective: To improve overall availability of services by proactively

Problem Categorization and Prioritization

Process Objective: To record and prioritize the Problem with appropriate

Problem Diagnosis and Resolution

Problem and Error Control

Process Objective: To constantly monitor outstanding Problems with regards to

Problem Closure and Evaluation

Major Problem Review

Process Objective: To review the resolution of a Problem in order to prevent