Checklist Problem Record: Difference between revisions

From IT Process Wiki
mNo edit summary
No edit summary
Line 68: Line 68:


<p>&nbsp;</p>
<p>&nbsp;</p>
<html><a rel="author" href="https://profiles.google.com/111925560448291102517"><img style="margin:0px 0px 0px 0px;" src="/skins/Vector/images/itpm/bookmarking/gplus.png" width="16" height="16" title="By: Stefan Kempter | Profile on Google+" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a></html>


<!-- This page is assigned to the following categories: -->
<!-- This page is assigned to the following categories: -->

Revision as of 15:41, 6 May 2012

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

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


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

 

A Problem Record typically contains the following information:

 

  1. Unique ID of the Problem (usually allocated automatically by the system)
  2. Date and time of detection
  3. Problem owner
  4. Description of symptoms
  5. Affected users/ business areas
  6. Affected service(s)
  7. Prioritization, a function of the following components:
    1. Urgency (available time until the resolution of the Problem), e.g.
      1. Up to 5 working days
      2. Up to 2 weeks
      3. Up to 4 weeks
    2. Degree of severity (damage caused to the business), e.g.
      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)
    3. Priority (for example in stages 1, 2 and 3): The result from the combination of urgency and the degree of severity
  8. Relationships to CIs
  9. 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):
    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. ...
  10. Links to related Problem Records (if there are other outstanding Problems related to this one)
  11. Links to related Incident Records (if outstanding Incidents exist, whose solution depends on the solution of this Problem)
  12. Links to Known Errors and Workarounds (if Known Errors and Workarounds related to the Problem have been identified)
  13. 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.
  14. Activity log/ resolution history
    1. Date and time
    2. Person in charge
    3. Description of activities
    4. New Problem status (if the activity results in a change of status)