Problem Management

[Link]
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:

[Link]

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

([Link] 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

grouped into categories

Percentage of Incidents resolved at the Service

Desk during the first call

grouped into categories

Rate of incidents resolved during solution times

agreed in SLA

grouped into categories

Average work effort for resolving Incidents

grouped into categories

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

grouped into categories

Average time for resolving Problems

grouped into categories

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

grouped into categories

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 ...
Request for Change (RFC)
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 Priority
Checklist Closure of a Problem
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:

[Link]

Languages:

English | Deutsch | espaol

Image:

ITIL Templates (.JPG)

Author:

Stefan Kempter, IT

ITIL-Checklists

Process Maps

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

2.1Incident Record Template

2.2Service Portfolio Template
2.3Request for Change (RFC)
2.4Checklist CMS/ CMDB

3Templates per ITIL Process

1.1ITIL Service Strategy Templates

1.2ITIL Service Design Templates
1.3ITIL Service Transition Templates
1.4ITIL Service Operation Templates
1.5ITIL CSI Templates

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 ...

Request for Change (RFC)
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 Priority
Checklist Closure of a Problem
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:

[Link]

Languages:

English | Deutsch | espaol

Image:

ITIL Templates (.JPG)

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

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.

Checklist Problem Priority

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

Checklist Closure of a Problem

ITIL Process: ITIL Service Operation - Problem Management

Checklist Category: ITIL Templates - Problem Management
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

ITIL Process: ITIL Service Operation - Problem Management

Checklist Category: ITIL Templates - Problem Management
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
According to categories

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
Applied resolution strategy

Elimination of the root cause

Possible Workarounds

Time schedule for the resolution of the Problem

Checklist Problem Report

ITIL Process: ITIL Service Operation - Problem Management

Checklist Category: ITIL Templates - Problem Management
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
According to categories

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
Applied resolution strategy

Elimination of the root cause

Possible Workarounds

Time schedule for the resolution of the Problem

TIL-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

2.1Incident Record Template

2.2Service Portfolio Template
2.3Request for Change (RFC)
2.4Checklist CMS/ CMDB

3Templates per ITIL Process

1.1ITIL Service Strategy Templates

1.2ITIL Service Design Templates
1.3ITIL Service Transition Templates
1.4ITIL Service Operation Templates
1.5ITIL CSI Templates

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 ...

Request for Change (RFC)
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 Priority
Checklist Closure of a Problem
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:

[Link]

Languages:

English | Deutsch | espaol

Image:

ITIL Templates (.JPG)

Author:

Stefan Kempter, IT

Process Maps

Checklist Incident Priority

ITIL Process: ITIL 2011 Service Operation - Incident Management

Checklist Category: Templates ITIL 2011 - Service Operation
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:

Relationships to CIs
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
...

ITIL Process: ITIL Service Operation - Incident Management

Checklist Category: ITIL Templates - Incident Management / Service Desk
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)

ITIL Process: ITIL Service Operation - Incident Management

Checklist Category: ITIL Templates - Incident Management / Service Desk
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

Checklist Incident Report

ITIL Process: ITIL Service Operation - Incident Management

Checklist Category: ITIL Templates - Incident Management / Service Desk
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)

Statistical evaluations

Number of Incidents

Resolution times
According to duration
According to categories
Initial resolution rate

Over time
According to categories

Over time
According to categories

Trend analyses

Technical analysis of important or repetitive Incidents

Description
Applied resolution strategy

Elimination of the root cause

Workaround