Service Management Checklists

 

YaSM checklists ('YaSM document templates') provide detailed explanations of the various documents and records ('data objects') which are produced by the YaSM processes.

On this page: Example - Incident record checklist

 

YaSM document templates

Each checklist describes the typical contents of a YaSM document or record, as shown in the following example. Because checklists are Microsoft Word™ documents, they can often be used as templates when creating the service management documents for a particular organization.

The YaSM® Process Map includes 75 checklists, one for every YaSM data object. In addition, there is a set of 19 checklists for the service management policies.

 

Example: YaSM checklist "Incident record"

Checklist/ document template: Incident record

Related YaSM process: LP4.6: Resolve incidents and service requests

 

Incident record: Definition

---

 

Figure 1: YaSM checklist/ document template - Example | Incident record template.

An incident record is a set of data with all details of a service incident, documenting the history of the incident from registration to closure. A service incident is defined as an unplanned interruption or reduction in quality of a service. Events that could potentially impair a service in the future are also treated as incidents (e.g. the failure of one hard-drive of a set of mirrored drives).

 

Typical contents of an incident record

---

An Incident Record typically contains the following information:

 

Unique incident ID

• A unique ID is usually allocated automatically by the application used to manage service incidents.

Incident status

• Incident status values could be for example "Raised", "Open", "Resolved", "Closed", ...

Incident recording

• Date and time of incident recording.

Incident occurrence

• Date and time of incident occurrence.

Source and method of notification

• E.g. telephone, e-mail, intranet portal, event monitoring system.

Contact information

• Caller/ user contact information and callback method.

Authorization information

• If applicable, details on how it has been established that the requester is authorized to raise the incident.

Incident owner

• The incident owner retains overall responsibility for the resolution of the incident, even if it is assigned during its lifecycle to other support agents or groups to perform specific tasks.

Assignment

• Agent or support group to which the incident is assigned. This assignment may change during the lifecycle of the incident.

Incident classification

• Incident classification is a way to add tags to incidents which are instrumental in assigning them to the appropriate support agent or group, as well as in the creation of statistics and the analysis of historical incidents.

Incident categorization

• Classification schemes may vary between different organizations, but incidents 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", ...).

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 incident
  • Impact is a measure of the (potential) damage to the business.
  For an example for a prioritization scheme, refer to the checklist "Incident and Service Request Policy".
  For recurring incidents, rules for prioritizing the incidents are typically defined in or coded into the corresponding incident models.

Major incident flag

• This flag indicates that an incident is treated as a major incident.

Target time for incident resolution

• This is the target time as committed in the applicable service definitions and agreements. Target resolution times are typically determined based on the incident’s priority.

Incident model(s)

• Applicable incident model(s).

Links to related incident records

• If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident".

Links to related event records

• If the incident has been raised following an event detected by an event monitoring system.

Links to related problem records

• If any problems exist which are related to the incident at hand in particular, a problem record can contain a suitable workaround.

Links to related change records

• If any change requests were submitted during incident resolution.
  • If the incident is linked to a (recently implemented) change.

Functional escalations

• Functional escalations (changes in the assignment of the incident to particular support agents or groups) must be recorded.

Hierarchic escalations

• High-priority or delayed incidents usually trigger hierarchic escalations, for example to top management. Such escalations must be recorded.

Status changes

• This section records incident status changes (for example from "open" to "resolved").

Activity log/ tasks assigned to the incident

• Most applications for managing incidents allow maintaining a simple log of steps carried out to resolve the incident. Some systems, however, also provide the means to assign "tasks" to incidents. Akin to the incidents 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.

Incident closure

• Closure information.

Resolution type

• Elimination of the underlying cause vs. application of a workaround. If the incident was resolved by applying a workaround: Indication of the applied workaround.

Problems raised

• A problem record must be raised, for example
  • If the incident is likely to recur and preventive action is necessary
  • If the incident has not been completely understood
  • If a new workaround has been devised during incident resolution.

Customer feedback

• Confirmation from the customer or user that the incident has been resolved results from a satisfaction survey if one has been conducted.

Additional information

• Notes and additional information.

 

Notes

---

• For particular types of recurring incidents, incident models describe how the incidents are to be resolved. In many cases, the handling of such incidents is supported by appropriately configured incident management tools (for example, there may be short-cuts to easily create certain types of incident records).
• The classification of incidents and problems should use the same scheme in order to support matching between incidents and problems - which is important, for example, for the identification of known errors and available workarounds during the resolution of an incident.

 

[ Infobox ]

Link to this page:	https://yasm.com/wiki/en/index.php/Service_Management_Checklists
Languages:	English | Deutsch
Image:	Example: YaSM checklist 'Incident Record' (.JPG)
Is based on:	YaSM "Incident record" template from the YaSM Process Map
Author | Contributor:	Stefan Kempter    and Andrea Kempter    -   IT Process Maps.

YaSM checklists › YaSM document templates › Example: YaSM checklist 'Incident record'