Problem Record - Template

 

Definition

Fig. 1: Problem record
(YaSM checklist / document template)

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

 

Typical contents

A problem record typically contains the following information:

 

Problem Record - Contents

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 Service(s) affected Customer(s) affected Location(s) affected Infrastructure component(s) and sub-component(s) (i.e. configuration items) affected Type of symptom (e.g. "Hardware defect", "Software defect", "Slow performance", "Security issue", …) Resolution condition (e.g. "Under analysis", "Underlying cause identified", "Solution in development", "Underlying cause resolved", …) Workaround condition (e.g. "No workaround", "Workaround in development", "Workaround provided", …).
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 Urgency is a measure of the available time until the resolution of the problem Impact is a measure of the (potential) damage to the business. 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 records	Links to related problem records: If any problems exist which are related to the problem at hand. Links to related incident records: If (outstanding or resolved) incidents exist which are related to the problem. Links to related event records: If the problem has been raised following an event detected by an event monitoring system. Links to related change records: If the problem is linked to a (recently implemented) change.
Escalation	Functional escalations: Functional escalations (changes in the assignment of the problem to specialists) must be recorded. Hierarchic escalations: Problems that cannot be resolved using the standard procedures must be escalated, for example to top management. Such escalations must be recorded.
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 Preconditions for applying the workaround Instructions for implementing the workaround Instructions for removing the workaround Situations where the workaround should not be applied. 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: Elimination of the underlying cause vs. provision of a workaround (for some problems, it will not be economical to resolve the underlying cause; in such situations, the "solution" consists of providing a workaround). Customer feedback: If applicable, confirmation from the customer or user that the problem has been resolved.
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  › Problem classification / categorization  › Priority  › Workaround  › Remark