Most companies I've found are trying to get a bit more efficient and automate or improve processes wherever they can, and a lot of people are using process mining today to very quickly and easily identify good candidates for automation.
I've been advising most customers who are first starting to use process mining to try and find the simplest and most repeatable processes they can and then start drilling in from there as to what sub-processes would be great candidates for some type of automation - whether that’s an AI agent, a specific workflow that triggers, or some type of integration. Often, it's these really simple processes that succeed the fastest in these automation plans, especially if it's your first AI agent workflow!
Here is a very quick video on how to achieve this with many examples or follow along below:
How to do the analysis
This approach can be applied to any workflow (Incident, HR Case, Customer Service Case, etc) and does not require any additional/special Process Mining configuration beyond the out of the box content packs offered with a given workflow.
Today I'll be working with Incidents - my goal will be to find a very specific sub-process within my Service Desk that could potentially be automated. To do this I want to find routes within my process mine that have a very high conformance rate, or in other words, low variability.
Once we have mined our data we are able to see our process along with the associated breakdowns on the right hand side. The breakdowns give us a bunch of statistics relative to specific dimensions of our overall process. In this case I have my breakdowns set to channel and I can see how my self-service process varies from my alert process, etc. I can see things like the record count of these channels, their average durations, but also their VARIANTS.
Today a big focus will be on variants. A variant is a unique path from process start to process end. So if I look at my "Phone" breakdown I can see we have 1500 unique paths (variant) that an incident can take from start to finish. This implies an inherent complexity which makes sense since we can receive any type of incident via phone, self-service, portal, etc.
Let's try changing the breakdown to another field to see if we can find some simpler trends:
In our mine I have changed the breakdown to look at the "Category" field and as I scroll through all the different categories one of them catches my eye right away. Cloud Management has a relatively high # of records but a VERY low number of Variants. At a minimum, all of my cloud management incidents follow an extremely similar path to resolution.
What makes this even more exciting is the number and average duration of these records. We have 831 of these incidents that average 2.5 weeks of time each to close (thats 41 years of time!) I would say this warrants some more investigation.
In fact when I apply this breakdown something even more interesting is surfaced:
Now that I have applied the Cloud Management filter I can visualize just that specific process. We saw earlier that there were 4 variants involved in Cloud Mgmt however now that I can see the map it's clear that the only time we deviate from the one standard process is when there is a "disagreement" over who is responsible for this incident. There are times Help Desk feels it should go to Service Desk and vice versa with the associated "On Hold" state getting involved because of it. If this process were to be automated, disagreements over ownership would not be an issue anymore.
In fact, if I drill down even further to the subcategory breakdown - I can see that all of these incidents were Failed Microservice issues. I now have a plan of attack! In an ideal world I can go out and build an AI agent to resolve these types of incidents, or trigger a workflow that can more efficiently handle these issues.
I know life isn't that simple and in the real world we will probably have to go and talk to both the Service Desk and Help Desk to better understand what exactly is being done behind the scenes to get these incidents resolved but at the very least we now have a starting point. We know that Failed Microservices is a subset we can look at to potentially automate and we can start to plan around that. Often I've found that the hardest part of automations is knowing where to start because it is so unique to every company. Hopefully this gives you an easy way to find these simple processes, because even the simple ones add up (reminder that this was 41 YEARS of time 🙂 )
Thanks for reading and as always,
If you are looking for more in-depth training you can use the Process Mining Academy library of content
You can find other Process Mining use cases here
BelalA
