YaSM checklists ('YaSM document templates') provide detailed explanations of the various documents and records ('data objects') which are produced by the service management processes.
2 Example: YaSM checklist "Incident record"
Each checklist describes the typical contents of a YaSM document or record, as shown in the following example - the Incident record template.
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"
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).
A unique ID is usually allocated automatically by the application used to manage service incidents.
Date and time of incident recording.
Date and time of incident occurrence.
E.g. telephone, e-mail, intranet portal, event monitoring system.
Caller/ user contact information and callback method.
If applicable, details on how it has been established that the requester is authorized to raise the incident.
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.
Agent or support group to which the incident is assigned. This assignment may change during the lifecycle of the incident.
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.
• Type of symptom (e.g. "Hardware defect", "Software defect", "Slow performance", "Security issue", ...).
• 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.
This flag indicates that an incident is treated as a major incident.
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.
If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident".
If the incident has been raised following an event detected by an event monitoring system.
If any problems exist which are related to the incident at hand in particular, a problem record can contain a suitable workaround.
If any change requests were submitted during incident resolution.
• If the incident is linked to a (recently implemented) change.
Functional escalations (changes in the assignment of the incident to particular support agents or groups) must be recorded.
High-priority or delayed incidents usually trigger hierarchic escalations, for example to top management. Such escalations must be recorded.
This section records incident status changes (for example from "open" to "resolved").
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.
Elimination of the underlying cause vs. application of a workaround. If the incident was resolved by applying a workaround: Indication of the applied workaround.
• If a new workaround has been devised during incident resolution.
Confirmation from the customer or user that the incident has been resolved results from a satisfaction survey if one has been conducted.
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.
Is based on: YaSM "Incident record" template from the YaSM Process Map.