How to Understand the Variants in Your Process
Based on the feedback that we get from our Disco users, they really like the variant analysis functionality and see this as one of the most useful tools for their process analysis. For example, an IT Process manager of a telecommunications company recently said:
Using variants we can learn which routes are better to deal with our incidents!
So, we thought it’s about time to do a blog post on how you can analyze the variants in your process using Disco.
Watch the screencast above to get a quick tour and read on to get a detailed description of the variant analysis possibilities in Disco. You can also follow the steps yourself using the free demo version of Disco.
Why variants are important
Variants show us how much we tend to underestimate the complexity in our processes: If you ask a process owner how many variants she thinks there are in her process, a typical answer is “10” or “15”. Meanwhile, the actual number of variants is often close to 100. We have seen literally millions of variants for some processes.
Furthermore, variants provide us with a simple, sequential view on the process execution. For example, in the discovered process map above you get a bird’s eye view on the analyzed purchasing process and you can see that there is a very dominant loop involving a process step that makes changes to the original purchase requisition (see activity Amend Request for Quotation Requester).1
However, we can’t see how a single case moves through the process, or how many cases go through this extra loop once, twice, or even more often. To get a grip on a typical process execution pattern from start to end, we need to look at the variants.
Variants are important because:
- The way we think: People think in scenarios. It’s much easier for us to understand a sequence of steps when we think about typical process execution patterns.
- Mainstream vs. exceptions: The frequency of a variant tells you how frequent a specific execution pattern is and lets you distinguish main stream variants from outliers and exceptions.
- Variation in your process: The total number of variants alone tells you how much variation you have in your process. Following standard procedures is crucial to deliver constant quality and efficient services.
- Cleanup: They help you spot data quality problems and let you see if you have still incomplete cases that first need to be filtered out before proceeding with your analysis.
By understanding the variants in your process, you can find out which patterns deliver a good (or bad) performance. You can then actively promote the well-performing variants for a better and more consistent process performance.
What exactly is a process variant?
Process variants are about variation in the process flow:2
A process variant is a unique path from the very beginning to the very end of the process.
In other words, a process variant is a specific activity sequence, like a “trace” through the process, from start to end. For our presentations and courses we created a simple illustration of process mining that also helps to understand what a variant is (see below).
You can read this picture as follows:
- Over time, different activities are performed for a number of cases (i.e., process instances) and recorded in the database or log file of the IT system (on the left).
- We take these data records as the starting point and first reconstruct the activity sequences that were performed for each case, Case 1 – Case 3 (in the middle).
You can see that Case 2 is similar to Case 1 but slightly different: Activity B and C are performed in a different order.3
In Case 3 we can see a repetition of activity D.4
- With process mining we take all these variations of the process into account and construct the overall process map (on the right). So, what we are doing is turning low-level transaction data from our IT systems into factual process maps that objectively visualize the flow of the process as it really took place.
Process variants are in between the raw data and the process map. In the illustration above we have three different activity sequences for the three cases. But we would see repetitions of these activity sequences if we would look at more cases.
So, a process variant is a particular activity sequence, which can be followed by just one or by many cases. Precisely this frequency, that is, the number of cases that follow a particular variant, is very interesting because it shows us what the frequent patterns are in our process.
Inspecting process variants
Here is how you can analyze your process variants in Disco.
Once you have imported your data, you see a process map that provides you with a bird’s eye view on your process as shown above. From there, you can change to the ‘Cases’ tab (see below).
In the ‘Cases’ tab you get a complete list with the history of all the cases in your data set (Complete log in the upper left corner). But in addition, you also get a list of variants. In this example, you can also see is that there are 98 variants in total for just 608 cases.
The variants are sorted by their frequency. Variant 1 is the most frequent variant: With 88 cases it accounts for almost 15% of all cases in the data set, Variant 2 covers 77 cases (about 13%), etc. In many processes, inspecting the top 5-10 variants helps you understand up to 80% or 90% of the whole process.
In the screenshot above, Variant 3 has been selected and you can see that you get a list of the 63 cases that follow this variant. So, all 63 cases (case 538 is selected at the moment) follow the same process pattern: They start with activity Create Purchase Requisition, perform activity Analyze Purchase Requisition as a second process step, and then they stop: The third most frequent pattern is related to stopped purchase requests! Perhaps the purchasing guidelines need to be updated to avoid the waste of processing these additional requests in the first place.
By looking at the variants you can understand how much variation there is and how your most frequent process patterns look like. You can also look at the less frequent variants and find out why they did not follow the standard procedure.
When you change to the ‘Statistics’ tab (see above), then you can inspect the average case duration for each variant to see which variants tend to be slow and which are fast. The table also provides an overview about the number of steps that were performed (an indication of effort) and how many cases are covered by the variant (indicates impact).
You can export this overview (like any table in Disco) by performing a right-click and pressing the button Export to CSV…
Filtering based on process variants
You can also use the variants to focus your analysis on either the mainstream behavior (or precisely the exceptional cases) using the Variation filter.
In the screenshot above, we have focused on the five most frequent variants by limiting the filter to variants that contain at least 32 cases or more. As we can see, this covers just about 5% of our variants but 50% of all cases in the process.
When you apply the filter, then you get a filtered view on how the process looks like for just these five variants (see above).
We could now further analyze the throughput times, bottlenecks, and data attributes for these mainstream process variants and compare them to the performance of the more exceptional cases to gain a deeper understanding of how we can improve our process.
The essence of the variant analysis is that by understanding the mainstream variants, you can improve and enhance the normal process. By understanding the exceptional variants, you can reduce your variation and deliver a more consistent performance.
Have you used process variant analysis yourself? What have you learned about your process? Let us know in the comments!
This process step should not be there in the first place because it is wasting resources and delaying the completion of the process. ↩︎
I am sure there are alternative interpretations of ‘process variant’ out there. Just have a look at this recent BPTrends discussion about the meaning of such simple terms as ‘Process’, ‘Process instance’, and ‘Workflow’ (you need to be a member of the group to see the discussion). Feel free to share your alternative definition of ‘process variant’ in the comments if you have any! ↩︎
Imagine, for example, that while for Case 1 the customer first ordered (A), then paid (B), and then we shipped the product (C), we had shipped the product (C) for the customer in Case 2 before we received the payment (B) because its one of our long-term customers and we know they will pay. ↩︎
For example, we might have sent out two proposals in this case. ↩︎