Often is the case where we know there are problems in our processes but to implement a change takes time, effort, and a ton of coordination. So when we finally do implement that change it is wildly important that we can monitor that change and how it helped.
If you are reading this post you are probably a problem solver, but many times it's hard to prove that a solution had the desired effect. Maybe it did but not to the degree you were expecting so we need to be nimble and fine tune that solution ASAP.
How do we get objective data, within a few minutes, that can show us pre vs post implementation stats (we love stats 🤓)
In today's post and video I walk you through how to use our comparison tools in Process Mining. Today I'll focus on a date but this can be expanded to anything you want to compare!
Here is a quick video on how to achieve this with many examples or follow along below:
Did your fix work? Use Process Mining to find out
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
Open your project to the Analyst Workbench view:
First thing is first, let's make some assumptions! Let's say we implemented a big change that affected our process in the middle of last year (July 1st). The change was meant to better standardize our process and help make us more efficient and I want to see what our process looked like BEFORE and AFTER that change.
Well the first thing we need to do is isolate our process for the first half of the year, to do this we will apply a condition to our process map:
My condition will state that I only want to see the incidents opened between Jan 1st to July 1st:
Once I apply this condition there is one more crucial step. That is to SAVE the filter set. We save filter sets so that we can compare them to each other later on (or we can just open these filters any time we open our process map without having to build out this condition each time):
Now we have our control set of incidents - this filter set will show us what our process looked like pre-implementation. We will do exactly the same thing to isolate our process POST implementation, the difference here is we will look at incidents opened AFTER July 1st.
Remember to save the filter set here as well.
You should now have 2 filter sets ready to compare - a pre and post implementation filter set:
Now with just this we can already compare the differences between the pre and post implementation process. We have all our standard tools at our disposal and can find some really good insights.
BUT THERE IS MORE!
We can compare both of these processes side by side and even view some comparison statistics. You can compare Model A to Model B and specify which filter set should be applied:
This is one of the many reasons to save your filter sets, you can choose saved filter sets in the comparison tool to view them side by side.
Finally we have comparison statistics which gives us a very quick summary in the differences in average duration, medians, std deviations and # of unique routes to closure between the two processes:
You can always close the comparison to look at these processes one at a time or continue to drill down into each of the processes side by side.
This was just one example of how you can use the comparison tool to really help you tell the actual story of whats going on. Good luck!
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
