Checklist Problem Record: Difference between revisions

From IT Process Wiki
No edit summary
Line 1: Line 1:
<seo metakeywords="problem record, problem record template, problem record checklist" metadescription="The Problem Record contains all details of a Problem, documenting the history of the Problem from detection to resolution. ..." />
<seo metakeywords="problem record, itil problem record, problem record itil, problem record template, problem record checklist" metadescription="The Problem Record contains all details of a Problem, documenting the history of the Problem from detection to closure. ..." />
<imagemap>
<imagemap>
Image:ITIL-Wiki-de-es.jpg|DE - ES - Checklist Problem Record - Template Problem Record|100px
Image:ITIL-Wiki-de-es.jpg|DE - ES - Checklist Problem Record - Template Problem Record|100px
Line 7: Line 7:
</imagemap>
</imagemap>
<br style="clear:both;"/>
<br style="clear:both;"/>
== <span id="Problem Record">Overview</span> ==


'''ITIL Process''': [[ITIL V3 Service Operation|ITIL 2011 Service Operation]] - [[Problem Management]]
'''ITIL Process''': [[ITIL V3 Service Operation|ITIL 2011 Service Operation]] - [[Problem Management]]
Line 16: Line 18:
<p>&nbsp;</p>
<p>&nbsp;</p>


The ''Problem Record'' contains all details of a [[Problem Management#Problem|Problem]], documenting the history of the Problem from detection to resolution.
The ''Problem Record'' contains all details of a [[Problem Management#Problem|Problem]], documenting the history of the Problem from detection to closure.


<p>&nbsp;</p>
<p>&nbsp;</p>
__TOC__
== Problem Record - Contents ==


'''A Problem Record typically contains the following information:'''
'''A Problem Record typically contains the following information:'''
Line 24: Line 29:
<p>&nbsp;</p>
<p>&nbsp;</p>


# Unique ID of the [[Problem Management#Problem|Problem]] (usually allocated automatically by the system)
===== Unique ID =====
# Date and time of detection
(Unique ID of the [[Problem Management#Problem|Problem]] - usually allocated automatically by the system)
# Problem owner  
 
# Description of symptoms
===== Date and time of detection =====
# Affected users/ business areas
 
# Affected service(s)
===== Problem owner =====
# Prioritization, a function of the following components:  
 
## Urgency (available time until the resolution of the Problem), e.g.
===== Description of symptoms =====
### Up to 5 working days
 
### Up to 2 weeks
===== Affected users/ business areas =====
### Up to 4 weeks
 
## Degree of severity (damage caused to the business), e.g.
===== Affected service(s) =====
### "High" (interruption to critical business processes)
 
### "Normal" (interruption to the work of individual employees)
===== Problem priority =====
### "Low" (hindrance to the work of individual employees, continuation of work possible by means of a circumventive solution)
Priority, a function of the following components:  
## Priority (for example in stages 1, 2 and 3): The result from the combination of urgency and the degree of severity
# Urgency (available time until the resolution of the Problem)
# Relationships to [[Service Asset and Configuration Management#CI|CIs]]
# Impact (damage caused or potential damage to the business or IT infrastructure)
# Problem category, usually selected from a category-tree according to the following example (Problem categories should be harmonized with CI and Incident categories to support matching between Incidents, Problems and CIs):
# Priority (for example expressed in codes like "Critical", "High", "Medium", "Low", "Very Low"): The result from the combination of urgency and impact
## Hardware error
(Note: Prioritization of Problems should follow the same rules as the prioritization of Incidents; for further information, refer to the checklist [[Checklist Incident Priority|Incident Prioritization Guideline]])
### Server A
 
#### Component x
===== Relationships to CIs =====
##### Symptom a
(Relationships to [[Checklist CMS CMDB#Configuration Model and CI Types |Configuration Items (CIs)]])
##### Symptom b
 
#### Component y
===== Problem category =====
#### …
Problem category, usually selected from a category-tree according to the following example:
### Server B
# Hardware error
## Server A
### Component x
#### Symptom a
#### Symptom b
### Component y
### …
### …
## Software error
## Server B
### System A
## …
### System B
# Software error
### …
## System A
## Network error
## System B
## ...
## …
# Links to related Problem Records (if there are other outstanding Problems related to this one)
# Network error
# Links to related [[Incident Management#Incident Record|Incident Records]] (if outstanding Incidents exist, whose solution depends on the solution of this Problem)
# ...
# Links to [[Problem Management#Known Error|Known Errors]] and [[Problem Management#Workaround|Workarounds]] (if Known Errors and Workarounds related to the Problem have been identified)
(Note: Problem categories should be harmonized with Incident categories to support matching between Incidents and Problems)
# Problem Recovery Procedures: Any procedures that are required to be performed to eliminate the Problem. These procedures may need to be performed as part of removing Workarounds that have been applied while solving related Incidents.
 
# Activity log/ resolution history
===== Links to related Problem Records =====
## Date and time
(Links to related Problem Records - if there are other outstanding Problems related to this one)
## Person in charge
 
## Description of activities
===== Links to related Incident Records =====
## New Problem status (if the activity results in a change of status)
(Links to related [[Incident Management#Incident Record|Incident Records]] - if outstanding Incidents exist, whose solution depends on the solution of this Problem)
 
===== Links to related Known Errors and Workarounds =====
(Links to [[Problem Management#Known Error|Known Errors]] and [[Problem Management#Workaround|Workarounds]] - if Known Errors and Workarounds related to the Problem have been identified)
 
===== Links to RFCs/ Change Records =====
(Links to [[Change Management#ITIL RFC|RFCs]]/ [[Change Management#Change Record|Change Records]] associated with the solution of the Problem)
 
===== Problem status change history =====
# 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.


<p>&nbsp;</p>
<p>&nbsp;</p>
Line 76: Line 101:
[[Category:Checklist (ITIL)|Problem Record]]
[[Category:Checklist (ITIL)|Problem Record]]
[[Category:Service Operation|Problem Record]]
[[Category:Service Operation|Problem Record]]
[[Category:Incident Management|Problem Record]]
[[Category:Problem Management|Problem Record]]
<!-- --- -->
<!-- --- -->

Revision as of 14:53, 24 June 2012

<seo metakeywords="problem record, itil problem record, problem record itil, problem record template, problem record checklist" metadescription="The Problem Record contains all details of a Problem, documenting the history of the Problem from detection to closure. ..." />

DE - ES - Checklist Problem Record - Template Problem Recorddiese Seite auf Deutschesta página en español
DE - ES - Checklist Problem Record - Template Problem Record


Overview

ITIL Process: ITIL 2011 Service Operation - Problem Management

Checklist Category: Checklists ITIL Service Operation

Source: Checklist "Problem Record" from the ITIL Process Map

 

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 checklist Incident 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
    2. Server B
  2. Software error
    1. System A
    2. System B
  3. Network error
  4. ...

(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. Date and time
  2. Person in charge
  3. Reason for status change
  4. 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.