ITIL Incident Management
From SNCWiki
| Incident Management |
|---|
|
| Related Topics |
 Get the Book |
Contents |
Overview
The goal of Incident Management is to restore normal service operation as quickly as possible following an incident, while minimizing impact to business operations and ensuring quality is maintained.
The Service-now platform supports the Incident Management process with capabilities to record incidents, classify according to impact and urgency, assign to appropriate groups, escalate, and manage through to resolution and reporting. This page attempts to detail the out-of-box functionality provided by the platform to manage incidents in accordance with the ITIL process.
Within the platform, incidents are handled using the task record system. Each incident is generated through a variety of means as a task record, populated with the pertinent information in individual fields. These tasks can be assigned to appropriate service desk members, who will deal with the task as appropriate. Once the incident has been properly dealt with, it is closed.
Service-now also supports many integrations with outside software. To find out more, visit the Integration portal.
Incident Management Process
The platform provides a number of tool to enable a service desk to implement the ITIL Incident Management process effectively.
Identifying Incidents
In addition to having users log incidents (see below), it is possible to automatically generate incidents from pre-established conditions. Business Rules use Javascript to generate an incident once a certain series of conditions have been met. It is also possible to generate incidents from outside the platform using SOAP messaging.
Logging Incidents
By default, any user can create an incident within the system. There are a number of ways to do this provided out-of-box:
- Employee Self Service - The Create New module in the Incident module, or by selecting New from the incident table
- Task Interceptor - If a user attempts to create a generic task, the task interceptor will first ask them to specify what sort of task they would like to create. In this way, tasks are always assigned a handling process.
- Record Producers - Using the Create a New Incident record produce in the service catalog.
- Inbound Email Actions - An email addressed to the instance's mailbox can create an incident according to Inbound Email Actions.
Categorizing Incidents
Incident forms have fields for category and subcategory, which allow for easy classification of incidents. These categories can be used by the system to create automatic assignment rules or notifications. For instance, with a certain assignment rule, an incident with a category of Database could automatically be assigned to a Database Group that always handles database issues.
Another important category for incidents is their Incident State. This allows the service desk to track how much work has been done, and what the next step in the process might be.
For more information, see Categorizing Incidents.
Prioritization of Incidents
ITIL uses three metrics for determining the order in which incidents are processed. All three are supported by incident forms:
- Impact - The effect on business that an incident has.
- Urgency - The extent to which the incident's resolution can bear delay.
- Priority - How quickly the service desk should address the incident.
ITIL suggests that priority be made dependent on Impact and Urgency. Out-of-box, this is true on incident forms. Priority is generated from Urgency and Impact according to the following table:
| Urgency 1 | Urgency 2 | Urgency 3 | |
| Impact 1 | Priority 1 | Priority 2 | Priority 3 |
| Impact 2 | Priority 2 | Priority 3 | Priority 4 |
| Impact 3 | Priority 3 | Priority 4 | Priority 5 |
It is possible to override this automatic priority generation simply by changing the priority field, or by altering the business rule that calculates priority (calculatePriority).
Initial Diagnosis of Incidents
Initial diagnosis of incidents is largely a human process, wherein the service desk looks at the information within the incident and communicates with the user to diagnose the problem in the incident.
To aid in the process, the service desk can consult the configuration management database, which contains information of hardware and software within a network, and the relationships between them. CMDB can be populated in two ways: Discovery and Help the Help Desk. Discovery is available as a separate product, but Help the Help Desk is available with the standard package.
Escalation of Incidents
The platform has an in-built system of Escalations rules which can ensure that incidents are handled speedily. Two escalators are available in the system:
- Service Level Agreements - SLAs monitor the progress of the incident according to defined rules. As time passes, the SLA will dial up the priority of the incident, and leave a marker as to its progress. SLAs can also be used as a performance indicator for the service desk.
- Inactivity Monitors - The inactivity monitors prevent incidents from slipping through the cracks by generating an event (which in turn can create an email notification or trigger a script) when an incident has gone a certain amount of time without being updated.
Investigation and Diagnosis of Incidents
As with the initial diagnosis and investigation, this is largely a human process. The service desk can continue to use the information provided within by the incident form and the CMDB to solve the problem. Work notes can be appended to the incident as the incident is being evaluated, which facilitates communication between all of the concerned parties. These work notes and other updates can be communicated to the concerned parties through email notifications.
Resolution and Recovery of Incidents
Once the incident is considered Resolved, the incident state should be set by the service desk as resolved. The escalators will be stopped and the service desk may review the information within the incident. After a sufficient period of time has passed, assuming that the user that opened the incident is satisfied, the incident state may be set to closed.
If an incident's cause is understood but cannot be fixed, the service desk can easily generate a problem from the incident, which will be evaluated using the Problem Management process. If the incident creates the need for a change in IT's services, the service desk can easily generate a change from the incident, which will be evaluated using the Change Management process.
In addition to the out-of-box incident management workflow, there is a Best Practice - Incident Resolution Workflow Plugin to bring the incident management workflow into better alignment with ITIL v3.
Closure of Incidents
Closed incidents will be filtered out of view, but will remain in the system for reference purposes. Closed incidents can be reopened if the user or service desk believe that it needs to be reopened.
Incidents which are on the Related Incidents list of a problem can be configured to close automatically when the problem is closed using business rules.
If the knowledge flag has been checked, a business rule will be triggered by closing the incident, and a knowledge article will be generated with the information from the incident. This is useful for Knowledge Management, and Knowledge-Centered Support, reducing the number of repeat incidents by distributing the information related to the incident.
It is also possible to generate customer satisfaction surveys upon closure of incidents. This allows the service desk to gather information about their quality of service directly from the user.
Continual Service Improvements to Incident Management
The incident management process can be improved by the service desk, using information gathered within the platform. Much of the data is already stored within the incident record. More information can be gathered by enabling auditing, which allows for an accurate review of the history of the problem. With the Metric Definition Plugin, it is possible to define the Key Performance Indicators to monitor within the system. With these metrics, and the information within the database, it is possible to generate reports, which can then be added to homepages or automatically generated and distributed. With the Database Views Plugin it is possible to join tables for reporting purposes.
Using this information, it is possible to refine automatic rules such as the assignment rules, service level agreements, or inactivity monitors to better suit the service desk's unique environment.
Unnecessary incidents can be avoided by encouraging users to consult Known Errors (ITIL Problem Management) and the Knowledge Base (ITIL Knowledge Management) before creating an incident.
