|Note: The ServiceNow Wiki is no longer being updated. Visit http://docs.servicenow.com for the latest product documentation.|
- 1 Overview
- 2 Incident Management Process
- 3 Continual Service Improvements to Incident Management
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 ServiceNow platform supports the incident management process with the ability to log incidents, classify according to impact and urgency, assign to appropriate groups, escalate, and manage through to resolution and reporting. Any ESS user can log in to ServiceNow to record the incident and track it through the entire incident life cycle until service has been restored and the issue has been completely resolved.
Within the platform, incidents are handled with the task record system. Each incident is generated through a variety of methods as a task record, and 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.
ServiceNow also supports many integrations with outside software. To find out more, visit the integration portal.
|Note: The incident alert management application allows you to manage communications around high-priority incidents, and is available starting with the Dublin release.|
2 Incident Management Process
The platform provides a number of tools to enable a service desk to implement the incident management process effectively.
2.1 Identifying Incidents
2.2 Logging Incidents
By default, any user can create an incident within the system. There are a number of ways to do this provided in the base system:
- Employee Self Service: ITIL users or administrators can use the Create New module in the Incident application, or select New from the Incident list. The Watch list, Incident state, and Impact fields are available on the ESS view of the Incident form and the variable formatter is not available. ESS users have write access to the Watch list and Impact fields.
- Record Producers: Using the Create a New Incident record producer in the service catalog. (Note that this record producer sets the Contact Type field of the resulting incident to Self-Service.)
- Inbound Email Actions: An email addressed to the instance mailbox can create an incident according to inbound email actions.
2.3 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 the 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.
2.4 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 an incident has on business.
- 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. In the base system, this is true on Incident forms. Priority is generated from urgency and impact according to the following data lookup rules:
|1 - High||1 - High||1 - Critical|
|1 - High||2 - Medium||2 - High|
|1 - High||3 - Low||3 - Moderate|
|2 - Medium||1 - High||2 - High|
|2 - Medium||2 - Medium||3 - Moderate|
|2 - Medium||3 - Low||4 - Low|
|3 - Low||1 - High||3 - Moderate|
|3 - Low||2 - Medium||4 - Low|
|3 - Low||3 - Low||5 - Planning|
By default, the Priority field is read-only and must be set by selecting Impact and Urgency values. To change how priority is calculated, administrators can either alter the priority lookup rules or disable the Priority is managed by Data Lookup - set as read-only UI policy and create their own business logic.
2.5 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 on 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 base system.
2.6 Escalation of Incidents
The platform has a built-in system of escalation 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.
2.7 Investigation and Diagnosis of Incidents
Like the initial diagnosis and investigation, investigation and diagnosis are largely human processes. 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 it 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.
2.8 Resolution and Recovery of Incidents
After the incident is considered resolved, the incident state should be set to Resolved by the service desk. 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 who 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 through the problem management process. If the incident creates the need for a change in IT services, the service desk can easily generate a change from the incident, which will be evaluated through the change management process.
In addition to the base system incident management workflow, a Best Practice - Incident Resolution Workflow Plugin is available to bring the incident management workflow into better alignment with ITIL v3.
2.9 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 believes that it needs to be reopened.
Incidents that are on the Related Incidents list of a problem can be configured to close automatically when the problem is closed through business rules.
If the knowledge check box is selected, a business rule is triggered by closing the incident, and a knowledge article is 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.
3 Continual Service Improvements to Incident Management
The service desk can improve the incident management process 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.
The following plugins allow you to gather additional incident information:
- Metric Definition: 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 that can then be added to homepages or automatically generated and distributed.
- Database Views: Join tables for reporting purposes.
- Vendor Ticketing: Add vendor data to incidents and integrate with Vendor Performance (starting with the Dublin release).
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 the knowledge base before creating an incident. For more information, see Knowledge Management with KCS.