Checklist Problem Record: Difference between revisions
No edit summary |
m (→Activity log) |
||
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 | <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> </p> | <p> </p> | ||
The ''Problem Record'' contains all details of a [[Problem Management#Problem|Problem]], documenting the history of the Problem from detection to | The ''Problem Record'' contains all details of a [[Problem Management#Problem|Problem]], documenting the history of the Problem from detection to closure. | ||
<p> </p> | <p> </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> </p> | <p> </p> | ||
===== Unique ID ===== | |||
(Unique ID of the [[Problem Management#Problem|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: | |||
# Urgency (available time until the resolution of the Problem) | |||
# Impact (damage caused or potential damage to the business or IT infrastructure) | |||
# 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 [[Checklist Incident Priority|Incident Prioritization Guideline]]) | |||
===== Relationships to CIs ===== | |||
(Relationships to [[Checklist CMS CMDB#Configuration Model and CI Types |Configuration Items (CIs)]]) | |||
===== Problem category ===== | |||
Problem category, usually selected from a category-tree according to the following example: | |||
# Hardware error | |||
## Server A | |||
### Component x | |||
#### Symptom a | |||
#### Symptom b | |||
### Component y | |||
### … | ### … | ||
## Software error | ## Server B | ||
## … | |||
# Software error | |||
## System A | |||
## System B | |||
## … | |||
# Network error | |||
# ... | |||
(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 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> </p> | <p> </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: | [[Category:Problem Management|Problem Record]] | ||
<!-- --- --> | <!-- --- --> |
Revision as of 13: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. ..." />
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:
- Urgency (available time until the resolution of the Problem)
- Impact (damage caused or potential damage to the business or IT infrastructure)
- 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:
- Hardware error
- Server A
- Component x
- Symptom a
- Symptom b
- Component y
- …
- Component x
- Server B
- …
- Server A
- Software error
- System A
- System B
- …
- Network error
- ...
(Note: Problem categories should be harmonized with Incident categories to support matching between Incidents and Problems)
(Links to related Problem Records - if there are other outstanding Problems related to this one)
(Links to related Incident Records - if outstanding Incidents exist, whose solution depends on the solution of this Problem)
(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
- 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.