LP4.6: Resolve incidents and service requests

 

Process name: Resolve incidents and service requests - Part of: Service lifecycle processes - Operate the services

Next process: Resolve problems

 

Process description

The incident management process in YaSM (fig. 1) is responsible for resolving service incidents (reports of suspected or actual service failures) or requests for service. In the case of service incidents, the primary objective of this process is to return the service to users as quickly as possible. In some cases this involves applying a workaround if the root cause cannot be readily identified and/ or resolved.

 

Fig. 1: 'Resolve incidents and service requests'
YaSM incident management and service request management process ('LP4.6').

Compatibility: YaSM incident management is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, section 8.6), and it corresponds to the ITIL practices of 'ITIL 4 incident management', 'service desk' and 'ITIL 4 service request management'.

Sub-processes

YaSM's incident management process has the following sub-processes:

LP4.6.1: Support incident and service request resolution

Process objective: To provide support for the resolution of incidents and service requests, for example by configuring the systems to manage incidents and service requests, and by maintaining a set of incident and service request models.

LP4.6.2: Log incidents and service requests

Process objective: To record all relevant details of incidents and service requests, to verify that all required authorizations are given, and to prioritize the incidents or requests.

LP4.6.3: Fulfill service requests

Process objective: To fulfill service requests, which are typically either requests for information or requests to implement minor (standard) changes like the reset of a password.

LP4.6.4: Pro-actively inform users and clients

Process objective: To inform users of actual or imminent service failures as soon as these become known to 1st level support, so that users and clients are in a position to adjust themselves to interruptions. This process is also responsible for distributing other important information, like current security alerts.

LP4.6.5: Resolve major incidents

Process objective: To resolve a major incident. Major incidents cause serious interruptions of business activities and must be resolved with greater urgency. The aim is the fast recovery of the service, possibly by means of a workaround.

LP4.6.6: Resolve incidents in 1st level support

Process objective: To resolve an incident (service interruption) within the agreed time frame. The aim is the fast recovery of the service, possibly by applying a workaround. As soon as it becomes clear that 1st level support is not able to resolve the incident itself or when target times for 1st level resolution are exceeded, the incident is transferred to 2nd level support.

LP4.6.7: Resolve incidents in 2nd level support

Process objective: To resolve an Incident (service interruption) within the agreed time frame. The aim is the fast recovery of the service, possibly by means of a workaround. If required, specialist support groups or third-party suppliers (3rd level support) may be involved.

LP4.6.8: Monitor incidents and service requests

Process objective: To continuously monitor the processing status of outstanding incidents and service requests, so that escalations and counter-measures can be introduced if the agreed resolution times are likely to be breached.

LP4.6.9: Close incidents and service requests

Process objective: To submit the incident and service request records to a final quality control before formal closure. The aim is to make sure that the incident's or service request's resolution history is described in sufficient detail. In addition, findings from the resolution of the incidents are to be recorded for future use.

Process outputs

This section lists the documents and records produced by the incident resolution process. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.

Change record

A change record contains all details of a change, documenting the lifecycle of a single change. In its initial state, a change record describes a request for change (RFC) which is to be assessed and authorized prior to implementing the change. Further information is added as the change progresses through its lifecycle. [*]

Change status information

Current status information related to the implementation of a change. This information is sent to the change manager from the various processes that implement authorized changes. It is used by the change manager to keep the change records and the change schedule up-to-date.

CI record

Configuration information is maintained in CI records for all configuration items (CIs) under the control of the configuration manager. In this context, CIs can be of various types: Applications, systems and other infrastructure components are treated as CIs, but often also services, policies, project documentation, employees, suppliers, etc. Configuration information is stored in the configuration management system (CMS). [*]

Complaint record

A record containing the details of a customer complaint, including the actions taken to resolve the complaint. [*]

Customer survey questionnaire

A customer survey is typically based on questionnaires, aimed at getting insight into overall customer satisfaction and customers' views on specific (aspects of) services. In many cases, answers are given using a scale, for example '1: Very dissatisfied', ... , '10: Very satisfied'. [*]

Incident model

An incident model contains the pre-defined steps that should be taken for dealing with a particular type of incident. The aim of providing incident models is to ensure that recurring incidents are handled efficiently and effectively. [*]

Incident record

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). See also: Incident record checklist. [*]

Incident/ request status information

A message containing the present status of an incident or service request sent to a user who earlier reported a service interruption or submitted a service request. Status information is typically provided to users at various points during an incident's or request's lifecycle. If the resolution time exceeds or is expected to exceed the agreed time frames, status notifications are especially important to keep the user informed.

Pro-active user information

A notification to users or clients of existing or potential service failures, so that users are in a position to prepare themselves for a period of service unavailability.

Problem record

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. See also: Problem record checklist. [*]

Recovery plan

Recovery plans contain detailed instructions for returning specific services and/ or systems to a working state, which often includes recovering data to a defined consistent state. [*]

Self-help information for users

Self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.

Service request model

Service request models contain the pre-defined steps that should be taken for dealing with a particular type of service request. The aim of providing service request models is to ensure that routinely occurring requests are handled efficiently and effectively. [*]

Service request record

A record containing all details of a service request. Service requests are formal requests from a client or user for something to be provided within the framework of existing service agreements - for example, a request for information or advice; to reset a password; or to install a workstation for a new user. [*]

Service usage statistics

Statistical data on service usage by clients/ users, as a basis for producing client invoices.

Suggested changes to self-help information

A suggestion to update self-help information for users supplied by the service provider, for example as part of the support pages on the intranet.

Suggested improvement to continuity arrangements

A suggestion for improving service security. Suggestions for security improvements may originate from anywhere within the organization. [*]

Suggested process modification

A suggestion for modifying one or several service management processes. Suggestions for process modifications or improvements may originate from anywhere within the organization.

Suggested service modification

A suggestion for modifying a service, for example to improve service quality or economics. Suggestions may originate from anywhere within or outside of the service provider organization.

Support request

A request to support the resolution of an incident or problem, usually issued from the incident or problem manager when further assistance is needed from technical experts or external suppliers.

 

---

Notes:

[*] "YaSM data objects" are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see 'Incident record' template and more examples) describing its typical contents, and an associated lifecycle diagram depicting how the status of the object changes as it is created, updated, read and archived by various YaSM processes (see example).

"Other objects" are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.

Process metrics

Process metrics are used, for example, to assess if the service management processes are running according to expectations.

For suggestions of suitable metrics, please refer to the list of metrics for the incident resolution process.

Roles and responsibilities

Process owner: The incident manager is responsible for the effective implementation of the incident resolution process and carries out the corresponding reporting. He represents the first stage of escalation for incidents, should these not be resolvable within the agreed time frames in the relevant service levels.

 

Responsibility matrix: 'LP4.6: Resolve incidents and service requests'

YaSM role / sub-process		1st level supp.	2nd level supp.	Config. mgr.	Incident mgr.	Major incident team	Serv. owner	Serv. requ. fulfill. group	Techn. domain expert
LP4.6.1	Support incident and service request resolution	-	-	-	AR	-	R	-	R
LP4.6.2	Log incidents and service requests	R	-	-	A	-	-	-	-
LP4.6.3	Fulfill service requests	R	-	-	A	-	-	R	-
LP4.6.4	Pro-actively inform users and clients	R	-	-	A	-	-	-	-
LP4.6.5	Resolve major incidents	R	-	R	AR	R	-	-	-
LP4.6.6	Resolve incidents in 1st level support	R	-	-	A	-	-	-	-
LP4.6.7	Resolve incidents in 2nd level support	-	R	R	A	-	-	-	R
LP4.6.8	Monitor incidents and service requests	R	-	-	AR	-	-	-	-
LP4.6.9	Close incidents and service requests	R	-	-	A	-	-	-	-

 

Notes

Incident management process: Objectives

Is based on: The incident resolution process from the YaSM Process Map.

By:  Stefan Kempter   and  Andrea Kempter , IT Process Maps.

Related articles

The service operation process in YaSM and the ITSM frameworks.

Service Operation according to YaSM

Operational processes, and in particular incident management and problem management, are probably the most widely known (and used) parts of IT service management best practice.
[ ... Read more ]

 

Process description  › Sub-processes  › Process outputs  › Metrics  › Roles