Problem Management – The feedback that led to the Madrid baseline

[mattlloyd]

This is the first of a 3-part series highlighting changes coming with the Madrid release of problem management.

If you are new to problem management, you might want to start with this great ServiceNow blog from Samiksha Chaudhuri, Problem management – why do we need it?

Last year, we reached out to many of our customers for feedback on how we could make a better baseline version of Problem Management. The changes you’ll see for Problem Management in the Madrid release are a direct outcome of those discussions.

Let’s begin the series by reviewing the main feedback.

A prescriptive process for problem management

A prescriptive process would guide your problem management team step-by-step through the lifecycle of managing a problem.

Before Madrid, we had four states in problem management (Open, Pending Change, Known Error and Closed/Resolved) and customers could move a problem between any of those four states. Sometimes, this flexibility led to confusion for teams where problem management is just a part of their overall role including:

• Where am I in the lifecycle of a problem?
• What do I need to do to make progress to fix this problem?

More customers are looking to move to out of the box configurations with ServiceNow in order to adopt the best practices that have been integrated into the products. Customers want best practice states for Problem Management to help them manage the lifecycle of a problem.

Add granular roles for problem management

All problems used to be managed under the ServiceNow ITIL role. Customers want specific roles to help with:

• Deciding who has the overall responsibility for managing the lifecycle of a problem.
• Assigning problem tasks to users who may not be part of the service desk (such as application developers or users from the legal team).

Allow knowledge to be searched for and attached to a problem

Problem teams want the ability to search for and attach knowledge articles (including known error articles) to a problem. You could use Contextual Search with problem, but attaching a knowledge article as a work note was not supported before Madrid.

Allow problems to be searched

Customers want to search for problems when:

• A service desk agent working an incident wants to link to an existing problem.
• The problem team needs to search for other problems that may be relevant to this one.
• The problem team needs to search for incidents or major incidents to link to this problem.

Allow problems to remain open when a change request is completed

The problem team may have more work to do to solve a problem after the change request completes so the change request should not close the problem or the related incidents. The logical step is for the problem team to decide when a problem is closed, just as incident teams do for incidents. Completing a change request should notify the problem team but not close the problem or related incidents.

Support problems for Customer Service Management

Customer service agents need to be informed of problems. It is important to allow customer service agents to create and link to problems and be notified when a workaround or fix is made available by the problem team.

Next steps

So, that was a summary of some great feedback we gathered from our customers. Next, we’ll take a look at what’s new in Madrid.