Overview of the Problem Management Process
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.
PROBLEM MANAGEMENT - OVERVIEW DESCRIPTION
The Problem
Management Process consists of the following sub process activities:
1.
Notification The identification of a problem. Examples of
a problem might be an outage, an incorrect or an unusual result. This sub
process also includes notifying the appropriate support structure that there is
a problem and a need for assistance. The initial recording of a problem,
including all relevant information that is available when the problem occurs.
This is the introduction of the problem into the management system. (Source
Incident Management Process)
2.
Problem Determination The collection, analysis, and correlation,
of data to determine and isolate the cause of the problem.
3.
Workaround and Recovery Activity to recover, workaround or
circumvent the problem, and notification to the affected clients of action
taken.
4.
Problem Resolution The identification, implementation, and
verification of solutions, and notification to affected clients.
5.
Tracking The assignment of ownership for resolving problems and
the follow-up activity to ensure that the goals for problem resolution are
being met. It includes setting priorities and escalating issues via the
appropriate system.
6.
Reporting and Control The production and analysis of reports, over
time, to determine if the problem management process is working effectively and
to identify changes that me be necessary. It also helps identify significant
results and problem trends.
PROBLEM
MANAGEMENT PROCESS FLOW (ITIL)
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.
§ 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.
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.
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.
As a problem is updated, email notifications will be sent to concerned parties. If inbound email actions are specified, the problem can be updated via email.
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.
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.
The following process
flow shows an overall ITIL based version of the Problem Management process for
resolving client problems. This illustration is meant to provide the reader
with an understanding of the general functional flow of the problem process.
PROBLEM MANAGEMENT MEASURES
The reports that are produced for the problem management
system are designed to help manage the process. Daily reports identify results
from the previous day, and any problems, which must be confronted during the
day. Weekly reports provide a summary of the previous week’s success, current
status and weekly trend information. Daily reports are primarily for
technicians. Weekly reports enable effective management of the process. Monthly
reports can also enable IT to evaluate the effectiveness of the problem
management system.
PROBLEM MANAGEMENT
PROCESS MEASUREMENTS
The problem management process measurements are used to
determine if adjustments must be made to the process:
- Cost and resource time to support the process
- Number of problems raised
- Number of known errors identified
- Number of incidents linked to problems
- Number of rejected resolutions
- Number of changes resulting in problems
- Number and cost of problems caused by changes
- Numbers of problems fixed by changes.
ROLES AND RESPONSIBILITIES
PROBLEM MANAGEMENT PROCESS OWNER
PROBLEM MANAGEMENT CONTROLLER
PROBLEM MANAGEMENT ANALYSTS
