Purpose

Document the proper process, business and technical, for the use of Problem Management within berkeley.service-now.com. This will encompass the default behaviors of ServiceNow, our customization (both direct and indirect) and our existing usage of Problem and it’s related modules.

Definition of a Problem

For our purposes, Problems reduce to:

Problems are issues with manageable items (CIs or potential CIs) that can cause an outage or degradation to a service, and thus incidents.
Problems with items that are not manageable cannot be resolved since the item is not manageable.
According to ITIL 4, a problem is a cause, or potential cause, of one or more incidents. Problems can be raised in response to a single significant incident or multiple similar incidents. They can even be raised without the existence of a corresponding incident. For example, monitoring may reveal an issue that has not yet resulted in an incident but if left unchecked it may cause more issues. In layman’s terms, a problem is the representation of the cause or potential cause of one or more outages.

Source

User Roles

role	description
problem_coordinator	Works on a Problem or Problem Task and manages it through its lifecycle Could be a limited group such as service owners who use problem
problem_task_analyst	problem_task_analyst Works on a Problem Task and manages it through its lifecycle Could be part of ITIL, or limited to groups we know will use Problem

Menu Modules

Module	Description	Notes
Create New	Create a new problem from scratch
Assigned to Me	Problems directly assigned to me or a delegate
Known Errors	Problems with a state of Known Error This is no longer used, There is a “Create Known Error Article” UI Action when you right click on the header. The other Known Error module links to those articles
Open	Problem with Active True
Open - Unassigned	Problems with Active True and Assigned To is empty
Pending	Problems with a state of Pending Change
Known Errors	Problem where a Known Error KB Article has been created. These problems have a KB Article in a Known Errors KB and a reference to the KB article in the problem
All	All Problems
Overview	A dashboard of problems Uses a PA Dashboard

Business Process

Overview

Problem Management Process

Discovery

Problems can be created by:

Discovery of a problem from an incident
Discovery of a problem from a major incident
Discovery of a problem from an outage
Discovery of a problem from an unmanaged discovery process (“stumbled upon”, etc)

Assessment

This is where problems are:

Confirmed
Estimation of scope of problem is established
Problem is Priotized
Communcation with those impacted begins (Service Owners, Service Desks, Managers)

Root Cause Analysis

This is where problems are:

Investigated
Scope of problem confirmed
Communication of impacted continues
Priotity is confirmed
Root Cause is established and documented

Fix In Progress

This is where the problems are:

Fixed in sub production
Fix is reviewed
Change Record made (Multiple Changes may be made and linked to a problem record)
Resolution of a change does not resolve the Problem
Change Board reviews and approves the process (if needed)
Fix is applied to production
Change Record Closed
If a problem cannot be resolved, or if the fix is cost prohibitive, you can accept risk. This indicates the risk of the problem continuing did not outweigh the cost of a fix. The problem is closed.

Resolved

This is where the resolution is communicated to those impacted

Closed

This is where the Fix is confirmed

A problem cannot be reopened

Technical Process

Overview

Any itil roled user can see and update the problem record
problem_coordinator role is required to progress a * problem record through the stages.
problem_coordinator inherits itil role as itil is required to edit problem records, but not required for problem tasks
problem_task_analyst does not inherit itil and does not require itil to work on problem tasks. * problem_task_analyst is licensed as an itil user and costs the same.

Problem Management Technical Process

New

Problems can be created by:

Right clicking on the header of an Incident or Major Incident and selecting “Create Problem”
In the case of an unplanned outage, you want to create a major incident to manage the service interruption and create the problem from the major incident
New button on Problem record list

Once a problem is created and ready for assessment, click Assess

Assigned to is required to progress to Assessment
Assigned to must have role “problem_coordinator”

Assessment

Create Problem tasks if desired
After the problem has been confirmed, scoped, prioritized and communicated, click Confirm
If this is a duplicate of another problem, you can click Mark Duplicate
- You will need to provide the problem record this is a Duplicate of.

Root Cause Analysis

Follow Recommended Business Process
Create Problem tasks if desired
After Root cause has been confirmed and work is about to be started, click Start Fix
- Cause Notes and Fix Notes are required to progress to Fix in Progress
If this is a duplicate of another problem, you can click Mark Duplicate
- You will need to provide the problem record this is a Duplicate of.

Fix In Progress

Fix the problem as needed
Create Problem tasks if desired
Change Record made (Multiple Changes may be made and linked to a problem record)
- Resolution of a change does not resolve the Problem
Change Board reviews and approves the process (if needed)
Fix is applied to production
Change Record Closed
After Root cause has been confirmed and work is about to be started, click Resolve

Resolved

Review and confirm that the problem has not continued or reappeared.
Create Problem tasks if desired
If the problem is confirmed resolved, click Complete
If the problem has not been resolved, click Re-Analyze
- This put the problem is Assess, but you have a few new options for the remainder of the problem life cycle
  - Cancel
    - Cancels the problem, not the assessment
    - This puts the resolution code of Cancelled
    - You must provide a Cancelled Reason
  - Accept Risk
    - See “Will Not Fix” on this document

Closed

The problem is closed. Any open Problem Tasks are cancelled.
If the problem has not been resolved, click Re-Analyze
- This put the problem as Assess, but you have a few new options for the remainder of the problem life cycle
  - Cancel
    - Cancels the problem, not the assessment
    - This puts the resolution code of Cancelled
    - You must provide a Cancelled Reason
  - Accept Risk
    - See “Will Not Fix” on this document

Will not fix

During Reassess (labeled assess but gotten to after it as been resolved or closed), Root Cause Analysis and Fix in Progress, you can mark a problem as you will not fix it and accept the risk.
If a problem cannot be resolved, or if the fix is cost prohibitive, click Accept Risk.
This will close the problem with a resolution code of Risk Accepted. This indicates the risk of the problem continuing did not outweigh the cost of a fix. You will need to provide a Risk Accepted Reason. You can note a workaround has been applied. If you select Workaround Applied, you will need to provide a workaround entry.

Problem Tasks

Overview

Any ITIL can update and view problem tasks, but only users with the role “problem_task_analyst” can progress through the stages.
Users with “problem_task_analyst” role do not need ITIL to update or progress problem tasks. This allows non ITIL users to work on problems, including communication etc. A user with “problem_task_analyst” consumes the same license cost as an ITIL user

Types

General

General Type of Problem Task

Root Cause Analysis

Same as general, but has a Analysis Information tab that contains

Cause Code: Cause notes
Proposed fix notes
Workaround

Those fields are required to close the task. Those fields are not copied to the problem record

Stages

This overview is brief as the tasks required to resolved a problem will vary from problem to problem.

New

Click Assess to accept the task and continue work.

Assess

Determine the scope of the task and click Start Work to continue

Work in Progress

Once the work has been completed, click Complete to continue.

General Tasks
- Required Fields:
  - Close notes
RCA Tasks
- Required Fields:
  - Cause Code
  - Cause notes
  - Proposed fix notes
  - Workaround

Closed

Can be reopened with Re-Assess

This will put the task in Assess, but you have a few new options for the remainder of the task life cycle
- Cancel
  - Cancels the task, not the assessment of the task
  - This puts the close code of Cancelled
  - You must provide a Cancelled Reason

Data Definition Dictionary

Problem

Tab	Field Name	Type	Data Definition	Notes
	Number	Problem Record Identifier	Begins with PRB
	First Reported By	Reference to an Incident	Incident Reference
	Category	Category of the problem	Choices of: Software, Hardware, Network, Database,	This is copied from an Incident when a problem is created from an incident, but only if the category from the incident exists in the problem. We may want to customize this to meet our needs.
	Subcategory	Subcategory of the problem	Choices of: Category: Software, Operating System, Email,Category: Hardware CPU, Disk, Keyboard, Memory, Monitor Mouse Category: Network DHCP DNS IP Address VPN, Wireless, Category: Database, Oracle, MS SQL Server, DB2	This is copied from an Incident when a problem is created from an incident, but only if the subcategory from the incident exists in the problem. We should customize this to meet our needs.
	Business Service	The business service that is impacted by the problem	Business Service reference
	Configuration Item	The CI that causes the problem impacting the business service. If a switch has failed causing an email outage, the switch is the CI	CMDB CI reference
	Status	The current status of the incident	See Technical Process
	Impact	How impact the problem is to customers using the service	Choices of: 1 - High, 2 - Medium, 3 -Low	See https://berkeley.service-now.com/kb/?id=kb_article_view&sysparm_article=KB0010891
	Urgency	How important it is to restore service to impacted customers	Choices of: 1 - High, 2 - Medium, 3 - Low	See https://berkeley.service-now.com/kb/?id=kb_article_view&sysparm_article=KB0010891
	Priority	The priority of the incident in terms of when to provide a fix	Potential values of: 1 - Critical, 2 - High, 3 - Moderate, 4 - Low, 5 - Planning	See https://berkeley.service-now.com/kb/?id=kb_article_view&sysparm_article=KB0010891
	Assignment group	The group responsible for managing and coordinating the problem. Must have users who possesses the problem_coordinator role to select assigned to	Any assignment group
	Assigned to	The individual who is responsible for managing and coordinating the problem to close.	User reference. Requires problem_coordinator role	Should be the point of contact for all unsure decisions, actions or communication. May not be responsible for such decisions, actions or communications but should be able to find individuals responsible for taking those actions. Is ultimately responsible for guiding the problem to close.
	Problem statement	A one line statement of the problem	String of length 160 characters or less
	Description	A detailed description of the problem from the perspective of it’s business impact. Technical description of the problem would be under Cause notes.
Notes	Work notes list	Users who receive some notifications. See Notifications section for details	List of User references and email addresses	Can include email addresses
Notes	Work Notes	A detailed, point in time, record of the problem’s life. Should be detailed for a new person who is familiar with the service and technology to understand without ambiguity.	Multi line text journal entry
Notes	Activities	A historical timeline of changes and notes to the problem	Includes: Comments, Assigned to, Assignment group, Attachments, Business service, Category, CI, Duplicate of, Impact, Major Problem, Parent, Priority, Resolution code, Emails, Status, Subcategory, Urgency, Work Notes	We can and should change this to meet our need.
Analysis Information	Workaround	A detailed account of how to workaround the issue.	HTML field with WYSIWYG editor Should be understandable by any user who would implement this workaround. Target audience depends on the nature of the workaround.
Analysis Information	Cause notes	A detailed description how the technical cause of the impact to the business service. Can be amended as the discovery process continues.	HTML field with WYSIWYG editor	Targets technical users who would create a resolution to the problem.
Resolution Information	Resolved By	User who clicked Resolve. If the issue is closed without ever having a resolution (Duplicate, cancelled, risk accepted), the field will be blank.
Resolution Information	Resolved	Date/Time when the resolve button was last clicked
Resolution Information	Fix notes	Detailed technical notes on how the problem was resolved		Should target technical users. Close notes targets business service owners.

Other Information	Opened by	User who opened the record
Other Information	Confirmed by	User who clicked the Confirm button. Blank if never confirmed (Marked Duplicate or Cancelled before confirmation)
Other Information	Opened	Date/Time when the problem was opened
Other Information	Confirmed	Date/Time when the problem was last confirmed. Blank if never confirmed (Marked Duplicate or Cancelled before confirmation)
Other Information	Risk accepted by	User who last clicked Risk Accepted
Other Information	Risk Accepted	Date/Time of when the risk was last accepted
Other Information	Risk Accepted reason	The reason the risk was accepted.
Other Information	Closed by	User who last clicked Complete
Other Information	Closed	Date/Time of when the last user clicked Complete
Other Information	Close Notes	Note about the resolution of the problem.		Should be targeting Business Service owners. Fix notes targets technical users
Other Information	Canceled By	User who last clicked Cancel
Other Information	Canceled	Date/Time of when the last user clicked Cancel
Other Information	Canceled reason	Detailed reason why the problem was canceled		To cancel a problem is to note it is not a real problem, has no risk and not potential fix.

Notifications

Problem

Notification	When fired	Who receives	Content
Problem Closed	Problem moves into the Closed State	Opened By	Subject: Your problem ${number} has been closed, Body:Your problem ${number} has been closed. Please contact the service desk if you have any questions. Closed by: ${closed_by}, Short description: ${short_description} Click here to view: ${URI_REF}, Comments and Work notes: ${comments_and_work_notes}
Problem worknoted (to ITIL)	When work notes are added. Whether Assigned to is populated or not does not affect if this is sent to Opened by and Work Notes list	Assigned to, Work notes list, Opened by	Subject:Problem ${number} notification – ${short_description}, Body: <div>Short description:, ${short_description}</div>, <div>Click here to view Problem: ${URI_REF}</div>,<div>, <div><hr /></div>, </div>, <div>State: ${state}</div>, <div>Priority: ${priority}</div>, <div>Configuration item: ${cmdb_ci}</div>, <div>Opened by: ${opened_by}</div>, <div>Assignment group: ${assignment_group}</div>, <div>Assigned to: ${assigned_to}</div>, <div> </div>, <div>Description:</div>, <div>${description}</div>, <div>${mail_script:attach_links}</div>, <div>Comments and Work notes:</div>, <div>${comments_and_work_notes}</div>
Problem worknoted (unassigned)	When any update is applied to a Problem without an Assigned to. ServiceNow’s name is misleading, it sends for any update, not just work notes.	Assignment Group, Work notes list	Subject same as Problem worknoted (to ITIL), Body same as Problem worknoted (to ITIL)
Problem assigned to me	Assigned to changes, and is not empty	Assigned To	Subject:Problem ${number} has been assigned to you Body same as Problem worknoted (to ITIL)
Problem assigned to my group	Assigned to is empty, Assignment group is not empty, and assignment group is not empty	Assignment Group	Subject:Problem ${number} has been assigned to group ${assignment_group}, Body same as Problem worknoted (to ITIL)
Problem Fixes Closed	When all related records that are classified as potential fixes are closed. See configuration: List of related task records (comma-separated) to track as fixes for this Problem. Used to notify the Coordinator when the all of the related fix records are Completed or Canceled. E.g. incident.problem_id, change_request.parent	Assigned to, Work notes list Subject: ${number} fixes are all completed or canceled
Problem Tasks closed	Closed every time a problem task is closed and there are no other active problem tasks. May fire multiple times if new tasks are made after all other tasks are closed.	Assigned to, Work notes list	Subject: ${number} problem tasks are completed or canceled, Body: ${number} (${short_description}) problem tasks are completed or canceled.

Problem Task

Notification	When fired	Who receives	Content
Problem Task assigned to me	Assigned to changes, assigned to is not empty	Assigned To	Subject:Problem task ${number} has been assigned to you, Body: Short description, click here to view Problem Task, <div>Priority: [priority], <div>Configuration item: ${cmdb_ci}</div>, <div>Assignment group: ${assignment_group}</div>, <div>Assigned to: ${assigned_to}</div>, <div> </div>, <div>Description:</div>, <div>${description}</div>, <div>${mail_script:attach_links}</div>, <div>Comments and Work notes:</div>, <div>${comments_and_work_notes}</div>
Problem Task assigned to my group	Assigned to is empty, Assignment group changes, Assignment group is not empty	Assignment Group	Subject:Problem task ${number} has been assigned to group ${assignment_group}, Body same as Problem Task assigned to me
Problem Task worknoted (unassigned)	Assigned to is empty, Work Notes are changed	Assignment group, Work notes list	Subject: Problem Task ${number} notification – ${short_description}, Body same as Problem Task assigned to me
Problem Task worknoted (to assignee)	Assigned to is not empty, Work Notes are changed	Assigned to, Work notes list	Subject same as Problem Task assigned to me, Body same as Problem Task assigned to me