3.0-Updated on 2023-01-13 by Terri Kouba
2.0-Updated on 2023-01-13 by Admin Anthony Roybal
1.0-Authored on 2019-10-04 by Kellie Watters
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.
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.
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 |
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 |
Overview
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
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.
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
- Cancel
- This put the problem is Assess, but you have a few new options for the remainder of the problem life cycle
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
- Cancel
- This put the problem as Assess, but you have a few new options for the remainder of the problem life cycle
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.
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
- Required Fields:
- RCA Tasks
- Required Fields:
- Cause Code
- Cause notes
- Proposed fix notes
- Workaround
- Required Fields:
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
- Cancel
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 | |
Urgency | How important it is to restore service to impacted customers | Choices of: 1 - High, 2 - Medium, 3 - Low | See | |
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 | |
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. |
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. |
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 |