Problem Record - Template
Definition: A problem record is a set of data with all details of a problem, documenting the history of the problem from registration to closure. A problem is defined as the underlying cause of one or more (potential) incidents, although the cause may not be known at the time a problem record is created. Often, a workaround is provided for a problem while a full resolution is not yet available.
Related YaSM service management process: Resolve problems
More checklists and document templates: Service management checklists
A problem record typically contains the following information:
Content | Description |
---|---|
Unique problem ID |
A unique ID is usually allocated automatically by the application used to manage problems. |
Problem status |
Status values could be for example "Suggested", "Open", "Deferred", "Closed", … |
Problem recording |
Date and time of problem recording. |
Problem owner |
The problem owner (in many cases, the problem manager) retains overall responsibility for the resolution of the problem, even if it is assigned during its lifecycle to specialists whose expertise is required for performing specific tasks. |
Specialist to whom the problem is assigned |
If specialist expertise is required for performing specific tasks during the resolution of the problem. This assignment may change during the lifecycle of the problem. |
Problem classification / categorization |
Problem classification is a way to add tags to problems which are instrumental in matching incidents and problems as well as analyzing outstanding problems.
Classification schemes may vary between different organizations, but problems are often classified by
|
Symptoms |
Description of symptoms. |
Priority |
Priority is often expressed in priority codes like "Critical", "High", "Medium", "Low", "Very low"). Priority is the result from the combination of urgency and impact where
Problems should be prioritized in the same way as service incidents to ensure problems and incidents can be easily related to each other (to see an example for a prioritization scheme, refer to the checklist "Incident and Service Request Policy"). |
Links to related problem records:
Links to related incident records:
Links to related event records:
Links to related change records:
| |
Escalation |
Functional escalations:
Hierarchic escalations:
|
Status changes |
This section records problem status changes (for example from "open" to "closed"). |
Underlying cause |
This section describes the root cause of the problem. Often, the underlying cause of the problem is not known at the time of creating the problem record but is identified during problem diagnosis. |
Workaround |
A workaround may be provided for a problem while a full resolution is not yet available. The specification of a workaround typically includes
This section can also contain a reference to an incident model, in particular if the incident model describes how to resolve a particular type of service incident by applying this workaround. |
Activity log / tasks assigned to the problem |
Most applications for managing problems 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. |
Problem closure information |
Resolution type:
Customer feedback:
|
Additional information |
Notes and additional information. |
Status values and lifecycle
(This information is included in the lifecycle diagram for the problem record contained in the YaSM® Process Map.)
Remark
- A problem that has a documented underlying cause and a workaround is often referred to as a "known error", to be stored as a "known error record" in the "known error data base (KEDB)". As both the underlying cause and the workaround are always linked to a specific problem, YaSM documents a problem’s cause and a possible workaround in the context of a problem (i.e. within a problem record).
- The classification of problems and incidents should use the same scheme in order to support matching between problems and incidents - which is important, for example, for the identification of known errors and available workarounds during the resolution of an incident.
Notes
Is based on: YaSM "Problem record" template from the YaSM Process Map.
By: Stefan Kempter and Andrea Kempter , IT Process Maps.
Definition › Contents/span> › Problem classification / categorization › Priority › Workaround › Remark