| Note: This article applies to Fuji and earlier releases. For more current information, see Problem Management at http://docs.servicenow.com
The ServiceNow Wiki is no longer being updated. Visit http://docs.servicenow.com for the latest product documentation.
Problem Management helps to identify the cause of an error in the IT infrastructure that is usually reported as occurrences of related incidents. Resolving a problem means fixing the error that will stop these incidents from occurring in the future. While Incident Management deals with fighting symptoms to incidents, Problem Management seeks to remove the causes of incidents permanently from the IT infrastructure. Problem resolution and elimination of root cause often calls for applying a change to the configuration item in the existing IT environment.
The ServiceNow platform supports the Problem Management process with capabilities to record problems, create knowledge from problems, request changes, 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 problems in accordance with the ITIL process.
Within the platform, problems are handled using the task record system. Each problem 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 problem management team members, who will deal with the task as appropriate. Once the problem has been properly dealt with, the problem task is closed.
2 Problem Management Process
2.1 Identifying and Logging Problems
A problem can be generated in a number of ways:
- An IT staff member can generate one manually using Problem > Create New or by clicking New from the problem record list.
- An IT staff member can generate a problem from an incident.
- A record producer can be created to allow users to log problems in the service catalog.
- 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.
- If an appropriate inbound email action is configured, a problem can be generated from an email.
A problem can be associated with a configuration item using CMDB to help the problem management team see the affected item and its relationships to other configuration items.
A problem can be assigned to a user or group. This can be done manually, or using an assignment rule.
A problem can be associated with one or more incidents using a related list, using the Edit button. This will already be the case if the problem was generated from an incident. This allows the problem management team to quickly refer to the knowledge already generated by the service desk in investigating the incidents.
2.2 Investigating and Updating Problems
If the problem management team has a problem model process for dealing with certain problems, they can be codified in the system with workflows. This allows for standardization and automation of the process.
|Note: ServiceNow also provides the Structured Problem Analysis application (starting with the Dublin release) as a method for identifying the true root cause of a problem.|
The platform has an in-built system of Escalations rules which can ensure that problems are handled speedily. Two escalators are available in the system:
- Service Level Agreements - SLAs monitor the progress of the problem according to defined rules. As time passes, the SLA will dial up the priority of the problem, and leave a marker as to its progress. SLAs can also be used as a performance indicator for the problem management team.
- 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 a problem has gone a certain amount of time without being updated.
2.3 Resolving Problems
If a problem needs a change in order to be resolved, it is possible to request a change, which will be then resolved using the change management process. Once a change has been requested, the problem will appear on a related list on the change item's form. Once the problem is associated with a change item, change the Problem State to Pending Change.
It is possible to create a business rule that will close the problem automatically if the change it is associated with is closed. This automates the process of closing problems that are Pending Change. It is also possible to create a business rule that will automatically close all incidents associated with the problem if the problem is closed.
If a problem's cause has been determined but there is no permanent fix, changing the Problem State to Known Error communicates this fact to the IT staff. This helps reduce the time spent on incidents dealing with the known problem by making known errors easy to find, automatically creating a list of Known Errors. To communicate knowledge related to this problem to users, Create Knowledge from Problem can either communicate a workaround, create a knowledge base article, or create a news item. This is important in the Knowledge-Centered Support process, which reduces repeat incidents and problems, and in the Knowledge Management process.
3 Continual Service Improvements to Problem Management
The problem 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 problem management team's unique environment.