ITSM Problem

Management

Process Guide

Last modified: November 2022

Ref: 0001029

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Table of Contents
Introduction........................................................................................................................ 3
Principles and Basic Concepts............................................................................................3
Process Scope..................................................................................................................... 5
Process Objectives.............................................................................................................. 5
Roles and Responsibilities.................................................................................................. 5
Specialist Roles....................................................................................................................
How problems are initiated................................................................................................. 9
Problem Management Lifecycle.......................................................................................... 9
Process Overview.................................................................................................................
State: New..........................................................................................................................
State: Assess......................................................................................................................
State: Root Cause Analysis.................................................................................................
State: Fix in Progress..........................................................................................................
State: Resolved..................................................................................................................
State: Closed......................................................................................................................
Other Processes................................................................................................................ 17
Incident Management.........................................................................................................
Change Management.........................................................................................................
Configuration Management................................................................................................
Knowledge Management....................................................................................................
User Experience.................................................................................................................
Process Governance......................................................................................................... 18
Measurement.....................................................................................................................
Metrics...............................................................................................................................
Process Diagrams............................................................................................................. 22
Process Scoping Considerations.......................................................................................22

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Introduction
This process guide will provide a detailed explanation on how the problem management
process is enabled within the ServiceNow platform. It is intended that this process be
followed as closely as possible. ServiceNow encourages simple, lean ITSM processes and
that is reflected in the out-of-the-box design. Additional functionality can be incorporated
into what is offered; however, this should only be in scenarios where there is a required
business outcome gained that could not be achieved using an out-of-the-box method.
Following this approach should also ease upgrade paths and the ability to expand the use
of the platform.

Principles and Basic Concepts

ITIL 4 defines the key purpose of Problem Management as being “to reduce the likelihood
and impact of incidents by identifying actual and potential causes of incidents and
managing workarounds1 and known errors.2”. ITIL further expand and explains that
“Problems cause incidents. They need to be analyzed and investigated so that
workarounds and resolutions can be identified which will in turn reduce the number and
impact of future incidents.”
Without Problem Management, you have:
 Repeat incidents, both major and minor
 Time wasted by IT staff repairing the same kind of issue, over and over.
 Reputational loss because “I’ve had the same issue for weeks and it keeps
happening and no one fixes it for good”

Problem Management activities are very closely related to incident management and the
practices need to be designed together within the value chain.
Many Problem Management activities rely on the knowledge and experience of staff
rather than following detailed procedures. People responsible for diagnosing problems
often need the ability to understand complex systems and to think about how different
failures might have occurred.

The overall flow of the problem management process can be summarized as :-

1
A Workaround is defined as a temporary way to restore service failures to a usable level
2
A Known Error Article is a type of knowledge article the problem management team can create to help with incident deflection.
A workaround or root cause may not be known.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
You can detect a problem either proactively or reactively.
Proactive problem detection is identifying problems or issues that could result in future
incidents. You may detect problems proactively by analyzing reporting trends, such as
the health of your configuration management database, or by automated system
notifications.
Start simple by asking service owners, business relationship managers and support teams
what issues they are seeing and what is worrying users. Triaging and logging these as
problems will ensure visibility.
Analysis methods outlined in this document can also help highlight if there are any
common themes.

Reactive problem detection means that one or more incidents have occurred,
prompting you to explore the underlying cause of the issue. These incidents may be
resolved, and the problem investigation is primarily meant to understand the underlying
cause and prevent the incident from recurring. In other cases the incident cannot be
resolved without a deeper dive into the root cause and the application of a workaround or
permanent fix.

Problems in ServiceNow move through a basic process that includes these stages :

There are three primary goals of the problem management process.

1. Provide a mechanism to understand the cause and permanently solve incidents
that have occurred. These are cases where the incident process may have only
identified a temporary solution purely to restore service.
2. Prevent incidents and service impacts from occurring.
3. Minimize the impact of incidents that cannot be prevented.

ServiceNow focuses on the use of automation and information to speed the path to root
cause identification and permanent resolution.
Problem Management relies heavily on:
 The CMDB for problem assignment and impact analysis
 The Incident Management process for providing details of individual related incidents
 The Change Management process for controlling changes needed to solve problems
 The Knowledge Management process for sharing information about known errors

Process Scope

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
The scope of Problem Management includes:
 The identification and diagnosis of problems through Event Management, technical
identification, and proactive Problem Management.
 The diagnosis of all problems as quickly as possible using:
o Problem and error control
o Event and incident trends
o Identifying workarounds to reduce incident duration
o Identifying and implementing permanent solutions to eliminate incidents
reoccurring

Process Objectives
The objectives of Problem management are to:
 Determine the root cause of incidents, identify viable workarounds, and drive to
permanent solutions that prevent recurrence
 Maintain information about problems, associated workarounds, and permanent
solutions
 Communicate information appropriately to reduce and eliminate the number and
impact of incidents over time
 Identify and solve problems proactively to improve IT services and prevent potential
incidents from occurring

For further guidance see article : Problem Management and 10 steps to making it
successful

Roles and Responsibilities

The Process Owner for Problem Management owns the overall process around problem
management. Within Problem Management, the owner of individual problems needs to be
designated and will therefore be responsible for problem resolution.
There are different approaches to define the ownership of a problem:
 A dedicated group of process coordinators
 The creator of the problem can be the coordinator
Design the ownership that works for your organization and communicate it within the
organization.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
 Role Name Process Owner
Description The Problem Management Process Owner’s primary objective is
to own and maintain the Problem Management process. The role
of the Process Owner is usually a senior manager with the ability
and authority to ensure the process is rolled out and used by all
stakeholders.
Responsibility  Defining the overall mission of the process
 Establishing and communicating the process mission, goals,
and objectives to all stakeholders
 Documenting and maintaining the process and procedures
 Resolving any cross-functional (departmental) issues
 Ensuring proper staffing and training for execution
 Ensuring consistent execution of the process across the
organization
 Monitoring, measuring, and reporting on the effectiveness of
the process to senior management
 Continually improving the process
ServiceNow Role There is no role in ServiceNow it is a functional role to support
the process

Role Name Problem Coordinator

Description The Problem Coordinator is the responsible owner for getting a
problem permanently resolved or prevented as soon as possible.
They must also manage and co-ordinate all problems through
the process.
Responsibility  Assessing problems to ensure they are genuine
 Monitoring and controlling the detection, recording,
assignment, escalation, and resolution of problems
 Coordinating technical and service Subject Matter Experts
(SMEs)
 Documenting problem information
 Publishing workarounds
 Publishing known error articles
 Coordinating decisions on whether to apply a fix
 Deciding whether to accept the risk of not applying a fix
 Reviewing problems to check for quality and completeness
 Driving the efficiency and effectiveness of the problem
management process
ServiceNow Role The problem_coordinator role is required in ServiceNow

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
 Role Name Problem Manager
Description The Problem Manager is responsible for the overall Problem
Management process and can configure Problem Management
settings as well as act as a Problem Coordinator
Responsibility  Can configure whether a problem or problem task can be re-
opened and if so by which roles.
 Can configure whether accepting risk of not fixing this
problem moves the problem to resolved (still active) or
closed.
ServiceNow Role The problem_manager role is required in ServiceNow

Role Name Technical Support

Description Technical Support teams assist the Problem Coordinator to
investigate problems, identify and implement solutions.
Responsibility  Providing subject matter expertise
 Conducting investigation into problems
 Identifying the root cause of problems
 Identifying workarounds, and notifying Service Desk and
Technical Support of workaround availability
 Publishing known error articles
 Identifying technical solutions to eliminate faults
 Providing stakeholder communication on active problems
 Resolving problems, through Change Management where
applicable
ServiceNow Role The problem_task_analyst role is required in ServiceNow.

Specialist Roles
Request Read and Write roles
Roles to assign access permissions at a granular level when the ITSM Roles — Problem
Management plugin ([Link].problem_management) is activated.
 sn_problem_read
 sn_problem_write

These roles are added when the ITSM Roles — Problem Management plugin is installed.
The new roles added are:
 sn_problem_read: The user with this role has read access to the Problem Management
application and related records.
 sn_problem_write: The user with this role has write access to the Problem
Management application and related records.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Business Stakeholder Role
The business_stakeholder role to approve, view, or read records across the organization
and view reports.
This role is an extended form of an approver role and contains the sn_incident_read,
sn_problem_read, sn_change_read, sn_request_read, and approver_user roles.
You can assign this role to any user who is a business stakeholder to review and approve
requests only if you have the appropriate entitlement from your organization. This role is
added when the Business Stakeholder plugin ([Link].business_stakeholder) is installed.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
How problems are initiated
Directly in ServiceNow - A Service Desk Agent, Incident Manager, Problem Coordinator,
or other IT user can create a problem directly when they believe they see an underlying
issue that is worth investigating.
Directly from an Incident – Incident Managers, Service Desk Analysts, Problem
Managers, or other IT Support staff can raise a problem from an incident where they are
seeing evidence of a problem based on the incident record/s.
Automatically via Integrations - Problems can be automatically generated via external
systems such as a vendor system integration.

Problem Management Lifecycle

States in any ServiceNow application serve a specific purpose. They are designed to
make it clear where in a process a record currently resides and to display progress.
States should represent a unique phase in a process where a specific set of related
activities are grouped together designed to achieve a particular outcome to move to the
next phase of the process. Our recommended Problem Management process has the
following state model:
 New
 Assess
 Root Cause Analysis
 Fix in Progress
 Resolved
 Closed

Process Overview

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
State: New

When a problem is first created, it is in a state of New. This is where very basic
information is added that may suggest a problem exists. All known information about the
symptoms experienced is captured, with enough information to warrant an investigation.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
The mandatory fields are:
 Problem statement
If other fields such as CIs are known at this point, they can still be added and will be
automatically added if they are coming from an existing incident record; however, they
do not need to be mandatory to progress. In addition, if the fields in the Assess Dialog
Form View dialog are filled, the problem is automatically moved to the Assess state
without having to manually change the state

Problem Assignment

At the New state, it is necessary to identify the appropriate assignment group to assess
the problem in the next phase of the lifecycle. This will need to be a Problem
Management group or if a dedicated function does not exist in the organization then the
group that will perform that function such as the Service Owner or Incident Management
team, these users will require the problem_coordinator role. This assignment is best
achieved by automatically updating the Assignment group field rather than letting the
user try to pick the correct group manually since this approach is prone to error.
At this point, if the assignment group is automatically updated, a member of the group
will need to choose an individual Problem Coordinator to take responsibility for the
problem on behalf of the group. This is done by populating the Assigned to field.
Once the fields are populated, the problem coordinator is expected to click the Assess
button. This will move the problem into the lifecycle where it is considered ‘live’ and
something that requires attention.
Each agent has access to the queue of problems to be worked on. In order to help the
agent decide which problem needs to be worked first, it is important to set the correct
prioritization rules in the queue, visualize the relative fields, and properly report the
problem backlog. Furthermore, idle time should be managed so that problems are
continually processed. Problems and problem tasks have a "priority" field to help the
agents. Address the issue of idle time. When (e.g. after 4 days) and how agents should be
reminded to work on an open problems or Problem tasks. It is recommended to display in
the list of fields of the problem queue the current ongoing SLA and all other fields that
can be useful in the specific context to prioritize the work.

State: Assess
At the Assess state, the Problem Coordinator is primarily assessing the problem to
determine whether it is genuine or not.
The Assigned to individual (the Problem Coordinator) will now conduct an initial review of
the problem primarily to check that it is indeed a real problem.
 If the Problem Coordinator determines that this is a duplicate problem, he or she will
click Mark Duplicate and select the problem this is a duplicate of.
 If the Problem Coordinator recognizes it is not a genuine problem, he or she will click
Cancel and populate a Canceled reason field to explain why the problem is not
considered to be genuine and explain why no further investigation is required.
 If the Problem Coordinator is comfortable to proceed with the investigation, he or she
may need to update the Priority, Service, and CI before clicking Confirm.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Establishing Priority

Problem prioritization typically drives the criticality associated with the handling of the
problem and the order in which problems will be focused on. Priority is calculated
through a combination of Impact and Urgency.
Impact is the affect that a problem has on business.
Urgency is the extent to which the problem’s resolution can bear delay.
Priority is generated from urgency and impact according to the following table.

Urgency

1 - High 2 – Medium 3 - Low

Priority Priority Priority

1 - High
1 - Critical 2 - High 3 - Medium

Priority Priority Priority

2 - Medium
2 - High 3 - Medium 4 - Low
Impact

Priority Priority Priority

3 - Low
3 - Medium 4 - Low 5–
Planning

It is possible to automatically establish the priority of the problem based on the CI that is
identified in the problem record. With this technique, the business criticality value of the
CI is used to determine the priority of the problem. For example, an online banking
service would be considered critical to a financial organization. If this CI is related to the
problem the priority can be automatically set to Critical as a result. This ensures a more
accurate and consistent prioritization of problem, as the determination of impact and
urgency can be a subjective call. If this automated method is being used this can occur
at the New state when the problem is first raised as it will be helpful to the Problem
Coordinator to see this immediately.

Categorization

Proper categorization of the problem supports an easy classification and correct routing
to the right team. Furthermore, reports of problems based on the categorization can help
drive business decisions
The categorization should be meaningful and, if possible, be the same as on incident. It
should be carefully planned and analyzed. Often, too many categories are created. When
more categories are offered to the user, the less likely it is they will select the correct one
– resulting in inaccurate data.
It is recommended to use a 2-level categorization. The top level of categorization should
be the (business) services. The next level should be the Affected CI – where a CMDB
is/will be in place.
In cases without a CMDB, the categories can be used. It is not recommended to use
subcategories.
The lowest level of the categorization should determine the support group for the auto
assignment.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Services and CIs
The Service and CI fields are used to identify what is being impacted by the problem.
These fields use CMDB data which is also used across other ITSM processes therefore
creating a valuable link and traceability particularly for services. This also offers the use
of the Dependency Views feature that displays the relationship map from the service/CI in
question to other related CMDB components and will display any ongoing incidents or
changes that may exist to aid with root cause analysis.
If the Agile Development application is in use, existing defects should be searched to look
for possible causes or relationships to the problem.
Once this data has been entered the Problem Coordinator will click Confirm to move to
the Root Cause Analysis state.

State: Root Cause Analysis3

The Problem Coordinator may now need to engage one or more technical support teams
to investigate and potentially help to fix the problem. This is achieved using Problem
Tasks.

Problem Tasks
The parent problem record remains assigned to the Problem Coordinator throughout the
entire process. The Problem Coordinator creates and assigns individual tasks out to the
various technical support teams to aid in the investigation and diagnosis. Each team will
capture their own investigation and discoveries in their individual tasks and the Problem
Coordinator will review and coordinate them all. There are two types of problem tasks.
Root Cause Analysis and General. The RCA type should be selected for specific tasks
required to investigate the root cause and should be created by the Problem Coordinator
at this point.

3
A Root Cause is defined as the underlying or original cause of an Incident or Problem.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
During the Root Cause Analysis state four main activities are intended to occur:
1. Discover a workaround (if possible), the Problem Coordinator should enter it into
the Workaround field and communicate it to all open related incidents using the
Communicate Workaround related link. This populates the text from the
Workaround field into the Activity Log of all related open incidents explaining that
it is a workaround from the problem record.
2. Discover the root cause and document it using the Cause notes field on the
problem. If the Problem Coordinator needs help to discover the root cause, they
can assign a Root Cause Analysis problem task to the relevant team who will
attempt to document the cause code, cause notes, proposed fix and provide a
workaround on the problem task.
3. Discover a permanent fix for the problem to prevent it from happening in the
future, enter it into the Fix notes field and communicate it to all related incidents
(incidents must be in On Hold state with an On hold reason of Awaiting Problem)
using the Communicate Fix related link. As with the root cause, if the Problem
Coordinator needs help to discover a permanent fix, they can use a problem task
to gather that information.
4. As it could take time to implement a permanent fix it may be helpful to
communicate that this problem is known about and currently being worked on
which can help to deflect incidents. The Problem Coordinator should create and
publish a Known Error knowledge article. Known Error articles show up when an
end user goes to create an Incident via the Portal. Click the Create Known Error
article related link to create a Known Error article from a problem which creates a
link between the two records displayed in the Primary Known Error article on the
problem record. The Problem statement, Description, Workaround and Cause
notes are copied over when creating a Known Error article. The Known Error article
will be in the draft state and can then be published. If it is not deemed necessary
to publish the known error in the Knowledge Base, Service Desk Analysts and
other Technical Support users can simply search for all problems to find these and
use the information as they require it. Most commonly this will be used by the
Service Desk if they are trying to resolve an incident, find a workaround or if they
recognize a pattern of similar incidents.
These activities can all happen in parallel and may be discovered at different times
through Root Cause Analysis. It is possible that none of these are discovered, some or all
four.
If the root cause and a permanent fix are discovered, then the problem can be moved to
the Fix in Progress state using the Fix button. If a fix cannot be discovered or the fix
cannot be implemented, the Problem Coordinator can use the Accept Risk button and
provide reason why they are accepting the risk of not fixing this problem for now.

State: Fix in Progress

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Fix in Progress state represents a problem that has been investigated and is now needing
a fix. It is mandatory to enter Cause notes and Fix notes in order to move Problem from
Root Cause Analysis to Fix in Progress
The Problem Coordinator can create or relate to one or more Change Requests to show
the clear path to resolution.
Once the change(s) are implemented and the problem considered to be resolved the
State field is now updated to Resolved using the Resolve button.

Risk Accepted

From the Root Cause Analysis or Fix in Progress states, the Problem Coordinator can
accept the risk of not fixing the problem for now:
 Due to cost implications the business may determine it is not worth the cost of fixing
 A fix cannot be determined
The resolution code is set to Risk Accepted.
Risk Accepted problems in these situations can be reviewed by the Problem Coordinator
at appropriate intervals. The coordinator establishes whether the impact has increased,
or the situation has changed to the point where either the problem will be fixed or is no
longer required due to some other change that has occurred and resolved it. The
Problem Coordinator can then choose to re-analyze the problem, so the problem process
can then be worked through to find the solution.
The out-of-the-box default is that Risk Accepted problems are set to Closed because there
is currently no work to do on the problem at that time. You can easily see the list of Risk
Accepted problems whether they are active or closed. The overall concept is that a
problem is only active if there is work that needs to be done on it right now.
Recommendation is that Risk Accepted problems should be set to Resolved and can
remain in Resolved indefinitely. It is important to remember that this is a key difference
between Incident and Problem Management. Incident Management is concerned with the
restoration of service as quickly as possible using whatever means possible. Problem
Management is concerned with permanently resolving the issue and ensuring it will not
reoccur - therefore it is acceptable for this to take as much time as is required. There
should be no driver to close out unresolved problems purely because they are not going
to be fixed at that time and are sitting in a list of active problems.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
State: Resolved
Once the problem has been moved to Resolved state the Assigned to individual will need
to populate or update the Fix notes field with text to describe exactly what has been
done to solve the issue.
At the Resolved state it is also possible for an organization to conduct a review of the
problem if their process requires it. Additional fields can be added here to capture that
information. Alternatively, problem tasks can be assigned out by the Problem
Coordinator as required.
A set period can also be observed before setting the problem to Closed state to confirm
that the known error has been solved. If evidence suggests that the issue persists, the
state can be set back to Root Cause Analysis using the Re-analyze button. The process
can then be worked through again to continue to find the solution.
If the problem is confidently considered solved, then the Assigned to individual will close
the problem using the Complete button.

State: Closed
At Closed state, several Resolution codes are displayed. These are automatically
determined by certain actions that occurred during the process:
 Duplicate
The problem was marked as a duplicate of another problem. Any related incidents and
tasks will be moved over to the problem that this one is a duplicate of. This is
configurable in the problem properties.
 Canceled
The problem was canceled. There are very few scenarios where a problem is
genuinely canceled. This will only occur when a problem was raised in error usually
prematurely before realizing there is no real problem.
 Fix Applied
A permanent fix was applied, and the problem was resolved.
 Risk Accepted
The problem has not been resolved but it has been accepted that the solution is not
to be applied at this time. If that decision changes the problem can revert

The problem management properties determine whether a closed problem can be re-
analyzed. For example, additional incidents were added to this problem after the fix was
applied. Set the role to Nobody if you do not want to be able to re-analyze the problem.
Then if the problem reoccurs, create a new problem ticket, and set the “First reported by”
field to refer back to this problem so you can trace it.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Other Processes
Incident Management
Most problem records are triggered in reaction to one or more incidents. Incident history
helps identify trends or potential weaknesses as part of proactive problem management.
Incident records that are related to problem records which are pending resolution are
automatically updated when a problem is resolved or closed as Risk Accepted
San Diego update:
 new property has been introduced in San Diego release so Problem Coordinators can
relate any incidents including closed to a Problem so they can show the true scope of
the issue
 file attachments, attached knowledge and workaround could also be copied over from
the incident to a problem record if a corresponding property is enabled

Change Management
For problems, implementing the workaround or the permanent solution will require work
on a service, hardware, or software. Conducting this work will require a change record to
be raised. This is done by selecting the Create Normal Change or Create Emergency
Change option in the context menu.
Emergency changes typically require an incident record to be related to prove that they
are urgent enough to bypass the full process and lead times.

Configuration Management
The configuration management system underpins all records and activities related to any
CI. It contains details of the infrastructure vital to services, CIs, and their relationships.
The CMDB is used within the problem management process by relating Configuration
Items including Services to the problem. This allows Dependency Views to be used which
display the relationship between the selected CI and other CIs related up and
downstream.

Knowledge Management
Knowledge is a vital part of the problem process. Known errors are documented and
published in the knowledge base including workaround information to allow end users to
see knowledge articles and, if appropriate, make use of workaround information to help
themselves while the known error is being fixed.

User Experience
Mobile platforms and Virtual technology can have a positive impact on how end users
interact with the end-to-end process and ultimately how the entire user experience is
perceived. Consider which touch point in the process can leverage the mobile platform to
minimize delays in the process. Tasks such as chat can all be performed on mobile
devices. Consider also how Virtual agent can be deployed to assist users in common
actions and tracking progress.

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Process Governance
Measurement
Key Performance Indicators (KPIs) evaluate the success of a particular activity toward
meeting the critical success factors. Successfully managing KPIs can be either through
repeatedly meeting an objective (maintain) or by making progress toward an objective
(increase/decrease). The Benchmarks feature gives you instant visibility into your key
performance indicators (KPIs) and trends, as well as comparative insight relative to
industry averages of your peers. You can contrast the performance of your organization
with recognized industry standards and view a side-by-side comparison of performance
with global benchmarks.
The main point of note when creating any KPIs or metrics for problem management is not
to be driven by the same measurements used for incident management. With incidents
the purpose of the process is to restore service as quickly as possible using whatever
means available. Therefore, speed of resolution is a key measurement for this process.
With problem management the purpose is to understand the underlying cause of issues
and permanently fix them no matter how long that takes or if it is even possible.
Therefore, in problem management speed of resolution is not something that should be
measured. This would drive the wrong behavior for the process and focus on closing
records rather than finding the permanent fix. Process Owners need to feel comfortable
with problem records potentially remaining open for months or even years.

Metrics
Process KPIs
 Provide information on the effectiveness of the process and the impact of continuous
improvement efforts
 Are best represented as trend lines and tracked over time
 Monitored by the Process Owner

Item Purpose

Mean time to first respond to Measure of how well response SLAs are achieved
problems, by priority

% of problems with a root cause Measure the effectiveness of problem management

identified for the failure in defining root cause

% of problem with workaround Measure the effectiveness of problem management

defined in defining and communicating workarounds

Percentage of incidents resolved by Measures the effectiveness of problem

fixing known errors management in supporting the timely resolution of
incidents

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Operational Data

Item Purpose

Problems ready to be assessed Shows all problems that require a Problem

Coordinator to assess them

Number of active problems that Highlights where there may be a process issue
have missed target response times in assessing new problems

Aged list of backlogged problems Provides visibility to unassigned work

Risk Accepted problems with new Highlights where a risk accepted problem may
incidents need to be reviewed for further work

Reports and Homepages

There are numerous default reports available in ServiceNow that can be used to generate
charts, be published to a URL, or can be scheduled to be run and distributed at regular
intervals. Users can also create custom reports.
In addition to reports, each user can create a personal homepage and add gauges
containing up-to-the-minute information about the current status of records that exist in
ServiceNow tables.
Report view access control can be used to restrict access to reports to uses who have one
of the required roles that contain the restricted resource.
Performance Analytics is recommended to report on KPIs and metrics, and answer key
business questions to help increase quality and reduce the costs of service delivery

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Performance Analytics Dashboard Examples

Performance Analytics Problem Management Dashboards provide in depth trend analysis.

These can be enabled as an ITSM Professional licensed user.

Problem Overview Open problems by priority

Basic indicators (number of open problems, number of closed
problems, number of new problems, problem backlog growth)
New problems by priority
Problem Open Open problems by priority
Average age of open problems
Average age of open problems by Priority
Open problems by Age
Problem backlog growth
Problem New % of new critical problems
New problems by Priority
Problem Closed Number of closed problems
Average close time of problems
Closed problems by Priority
Average close time of problems by Priority

Problem
Overview
Tab

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
 Problem
Open Tab

Problem
New Tab

Problem
Closed
Tab

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.
Process Diagrams
The process diagrams in editable format (Vision) can be found on Now Create LINK

Process Scoping Considerations

When scoping the process there are a range of considerations that should be made. The
following are areas to be considered when scoping the process:

Content Integration Process Security

Fields to pass from

Form design / Assignment
Incident
layout
Access to view
Problems and
Problem Tasks
Fields to pass to
State model
Knowledge

Classification
Structure
Fields to pass to
Problem Tasks
Change
Permission to
create Known
Prioritization Errors
approach Knowledge Search Reporting

© 2022 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered
trademarks of ServiceNow, Inc., in the United States and/or other countries. Other company names, product names, and logos may be trademarks of
the respective companies with which they are associated.