This post is part of the Process Mining Use Case Series where we’ll focus on different techniques to identify process inefficiencies, non-conformant activities, and improvement opportunities.
Our product team has the privilege to talk to many different types of organizations, and one very common use case we see is this:
"Where are incidents being triggered by changes—and why?"
Or flipping the script as a change manager:
"Identify the changes that are resulting in incidents and impacting our outcomes and goals”
According to industry benchmarks, up to 80% of major incidents can be traced back to a recent change.
Yet, many organizations struggle to connect the dots due to siloed data, inconsistent process adherence or lack of visibility.
Reports can certainly tell us when it’s happening, but what teams really want is to reduce, mitigate and reduce the number of incidents and ultimately improve the quality of any change that are planned and implemented.
- Did the change process miss a step?
- Are change workflows not following best practice?
- What type of changes are more prone to an incident?
- Surface opportunities to focus governance, workflow and automation to ensure changes don't inflict unnecessary work and pain on an organization.
With ServiceNow's Process Mining we can easily start answering the hard questions of where and why incidents are caused by changes.
Let's dig into how with 2 different perspectives one from incidents and one from the change process itself.
We have a few techniques to share, but the first one will be done when we create a process mining project, and how its scoped.
1. Analyzing Incidents caused by Changes
We will use the filter conditions within the guided setup and use a simple filter condition to identify all incidents that have a change with "caused by incident".
We start that configuration by either building a new project or editing an existing project using the guided setup, then into the “filter conditions”
A simple technique is to choose and add a filter "caused by change" within the search, one case easily find that by searching on change :
Adding in the attribute to the "caused by change" with "is not empty" filters on all incidents that are caused by change to be included .
Below is an example of what one should see when you have added that filter. Generally, this should be an “and” Boolean to the additional filters.
One other technique is to focus on incidents caused by changes after an analysis is done on a larger set of incidents, all closed incidents from last month, for example. One may still want to focus on just the incidents caused by change as well, and within the analyst workbench, we can get that done using the condition filter found in advanced filters.
All is needed is to select the “caused by change” and “is not empty” to identify all incidents that have been flagged as caused by incident.
Pro tip: Once you have that filter completed in scheduled tasks, save it as a filter set for reuse in the future.
2. Analyzing Changes that caused Incidents
Another technique is from the perspective of the team that manages the change process itself.
Now as a change manager/process owner measuring successful your changes is important, as is the ability to understand where changes are causing issues with potential downtime with business impact. In this scenario, we will analyze the changes that have caused incidents and investigate and uncover potential process gaps that will surface opportunities to improve change outcomes.
We will use the same filter conditions within the guided setup and this time , use the related list condition to identify all changes that have a change with "caused by incident".
We start that configuration by either building a new project or editing an existing project using the guided setup, then into the “filter conditions” and select the “Related List Condition
Once the related list is selected, search for “caused by incident” as the related field and select that. One more thing we need to add “1” to the Greater than or Equal to. This will filter all changes that have at least 1 incident caused by a change.
The final view of the related field will result in the following within your filter for the related list condition.
