Problem Management – What’s new in Madrid

[mattlloyd]

Last time we looked at the feedback that led to the Madrid baseline.

** Updated to mention this applies to Madrid and later releases.

What’s new at a glance in Madrid (introduced as part of Madrid, but also applies to later releases):

• Automated Test Framework (ATF) tests
• New roles
• Additional fields for documenting the problem
• Search for problems
• Notify when related problem tasks and change requests are done
• Communicate a workaround or fix
• Problem overview dashboard
• Create known error articles for incident deflection
• New states and guided actions to help manage a problem
• Configurable properties

Now, we’ll dig into those features in more detail, in the order of the plugin they belong to.

Problem Management – ATF Tests plugin

Activated by default.

Automated Test Framework (ATF) tests can be run after you make configuration changes such as apply an upgrade or develop an application to make sure problem management still works correctly.

Problem Management Best Practice – Madrid plugin

Activated by default for new customers (zbooted instance).

Not activated for upgrade customers, an administrator can activate this plugin.

New roles

New roles for managing problems:

New Role	Description
Problem Task Analyst	Works on a Problem Task and manages it through its lifecycle. This can include your subject matter experts and technical teams. Allows people outside of your service desk to work on problem tasks including application developers or legal team. Inherits roles: N/A – this is the minimum permission to manage problem tasks. Note: They are still tracked as fulfillers for licensing purposes, but you do not need to give them full ITIL permissions.
Problem Coordinator	Works on a Problem or Problem Task and manages it through its lifecycle. If they need help on a problem, they create problem tasks and assign them to problem task analysts. Inherits roles: Problem Task Analyst and ITIL user.
Problem Manager	Responsible for the overall Problem Management process and can configure Problem Management properties as well as act as a Problem Coordinator. Inherits roles: Problem Coordinator.
Problem Admin	A Problem Manager who can also delete Problems and Problem Tasks. Inherits roles: Problem Manager.

Additional fields

Baseline fields for documenting the problem:

Field Name	Description
First reported by	The task that first reported this problem, useful when you have multiple incidents associated with a problem. This is pre-filled when a problem is created from an incident.
Category and Subcategory	This is the same capability as already exists for incident management.
Problem statement	This is the short description field with a new label. This is based on customer feedback that people tend to provide a better short description when it is called the problem statement.

Field Name	Description
Workaround	Document the steps to work around this problem to help the service desk team resolve incidents. This field can be used for filtering and reporting. Note: This replaces the older workaround field that was part of the activity stream because that field could not be used for filtering or reporting. That older field is now hidden.
Cause notes	Document the root cause of this problem.

Field Name	Description
Fix notes	Document the steps to permanently fix this problem.

Search for problems

Contextual Search (aka Related Search Results) now supports searching for incidents and problems within the context of the record you are working on.

• The problem coordinator working on a problem can search for incidents.
• An agent working on an incident can search for a problem.

Contextual Search also now supports linking certain records together from the preview window. This saves time as there were multiple steps required to link the records on your own.

• Link an incident to a problem.
• Link a problem to an incident.
• Link an incident to another incident.

Notify when related problem tasks and change requests are done

Notify the problem coordinator that is assigned to the problem when:

• All related problem tasks for this problem are completed or canceled.
• All related fixes for this problem are completed or canceled. Fixes refer to:
  • Change Requests.
  • Defects, Enhancement or Releases (if you have Agile 2.0 from IT Business Management).

This means the problem coordinator doesn’t have to keep checking back to see the progress for those related records, instead, the problem coordinator can wait until they receive a notification that all related problem tasks or fixes are completed or canceled and then decide what to do next.

Communicate a workaround or fix

The problem coordinator can communicate when:

• A documented workaround is available for this problem using the Communicate Workaround related link action.
• A documented fix is available for this problem using the Communicate Fix related link action.

Behind the scenes these actions raise an event communicate_workaround or communicate_fix which is handled by the incident or case process. For example: unresolved incidents add the workaround information to themselves when a workaround is communicated.

Problem overview dashboard

The previous problem overview homepage has been converted to a dashboard based on recommendations from the performance analytics team.

Problem Management Best Practice – Madrid – Knowledge Integration plugin

Not activated by default, an administrator can activate this plugin.

The Knowledge Integration uses Knowledge Templates from Knowledge Management Advanced to configure and create Known Error articles. The template specifies which fields from the problem should be copied to the new Known Error article.

You can relate a Known Error article to a problem using the Primary Known Error article reference field in the Analysis Information tab.

Note: If the Primary Known Error article field is empty when you use Contextual Search to attach a Known Error article to a problem, the field is updated to refer to the attached article. 

Create Known Error articles for Incident Deflection

Use the Create Known Error article related link to create a Known Error article from this problem.

Note: The create Known Error article related link is only shown when the Primary Known Error article field is empty.

When you save the Known Error article, it will be added to the Primary Known Error article reference field.

Publish the Known Error article to make it available to users including those outside the service desk. When a user goes to the Service Portal to create an Incident (Get Help > Create Incident) any related Known Error articles will be displayed which can help with Incident Deflection.

Problem Management Best Practice – Madrid – State Model plugin

Activated by default for new customers (zbooted instance).

Note: This plugin cannot be directly activated by upgrade customers because it introduces a workflow that requires migration from the previous problem management. Please refer to the upgrade path for existing customers for more information on getting access to this plugin.

This plugin includes the best practice states, mandatory fields and actions that the problem team can use to navigate the lifecycle of a problem or problem task.

New states and guided actions to help manage a problem

The new states are: New> Assess > Root Cause Analysis > Fix in Progress > Resolved > Closed

You can read the documentation for more information about the lifecycle of a problem.

Note: Only users who have the problem coordinator, problem manager or problem admin role can manage a problem though its lifecycle.  

The guided lifecycle actions are shown in the problem form header. If more information is required to move to the next stage of the lifecycle a popup will display the necessary mandatory fields.

There are two types of problem task you can create in Madrid:

Problem Task Type	Description
Root Cause Analysis	When you need help to investigate the root cause and the resolution for a problem.
General	Used for any other kind of task.

The new problem task states are: New > Assess > Work in Progress > Closed

You can read the documentation for more information about the lifecycle of a problem task.

Note: Only users who have one of the problem management roles can move a problem task through its lifecycle.

The guided lifecycle actions are shown in the problem task form header. If more information is required to move to the next stage of the lifecycle a popup will display the necessary mandatory fields.

Configurable properties

Problem managers can configure the problem management properties including:

• The problem roles that can request to re-analyze a closed problem.
• The problem roles that can request to re-assess a closed problem task.

Next steps

Now that we have covered the new features available in Madrid, you may also want to watch this quick Problem Management ServiceNow deskside chat where I caught up with Manjeet Singh to discuss the best practices for problem management and where we are also looking to employ intelligence to help working with problems in the future.

For existing customers looking to upgrade to Madrid (or a later release) please continue to part-3 on the upgrade path for existing customers.