Variant analysis

What is variant analysis?

Variant analysis is a step inside process mining where you look at every unique order in which a process runs through your systems. Each unique sequence of activities, from start to finish, is called a variant. One step out of place and it counts as a different variant.

Think of the routes a parcel travels between warehouse and front door. On paper there is one plan, but one parcel goes straight through, another has to loop back through a sorting centre because the address is wrong, and a third gets scanned twice along the way. Variant analysis lays out all those routes side by side, instead of squashing them into one average.

The input is an event log: a table with at least a case ID, an activity and a timestamp per event. A process mining tool groups all cases with the same step sequence into one variant, counts how often it shows up, and computes the average throughput time.

Why does variant analysis matter?

In real business processes the number of variants is almost always higher than people think. In order-to-cash or purchase-to-pay you often count hundreds or thousands of variants, even when there is only one process description on paper.

A pattern you see in most logs: a small minority of variants covers the large majority of cases, and the long tail of rare variants together represents only a sliver of volume. The useful insight often sits in that tail. Rare variants are more often the source of late deliveries, duplicate invoices and compliance issues.

Variant analysis is therefore worth doing for three reasons:

• Standardisation: you see which deviations happen often enough to be worth tackling.

• Automation: the largest variants contain repetitive hand-offs that fit a workflow engine or RPA.

• Risk and compliance: the tail shows where approvals are skipped or steps run out of order.

How do you read a variant overview?

Tools like Celonis, Fluxicon Disco and the process mining in Microsoft Power Automate show variants in a list or bar chart with three fixed ingredients per row.

• Activity sequence: the exact chain of steps, often shown as coloured tiles or a mini process map per variant.

• Frequency: the number of cases or the share of the total that followed this variant.

• Average throughput time: how long a case in this variant takes from first to last event.

By default you sort on frequency first to grab the dominant routes, then on duration to find the slow exceptions. Many tools also offer a variant DNA view that lines two or more variants up step by step, so you see exactly where they diverge.

Example: order-to-cash

Take a B2B wholesaler that takes in orders via email, webshop and EDI. On paper the process is linear: order received, credit check, picking, shipping, invoicing, payment. In the data, over six months, we see a few hundred unique variants.

The handful of most frequent variants together cover the bulk of orders. They look roughly like this:

1. The standard route: order, credit check, picking, shipping, invoice, payment.

2. The small price correction: order, price adjusted, credit check, picking, shipping, invoice, payment.

3. The split delivery: order, credit check, picking, shipping part 1, shipping part 2, invoice, payment.

The rest is a long tail of rare variants: orders that get re-approved twice, invoices credited and re-issued, deliveries with a return-and-reshipment loop. Individually they look minor. Together they account for a large share of manual interventions, complaints and DSO days. Without variant analysis those patterns vanish into an average. With it, you get them one by one on the table, with a count and a duration next to each line.

Variant versus happy path

The happy path is the variant everyone says the process should follow. Variant analysis shows how many of your cases really follow that happy path and how the rest deviates. Often the share is lower than management expects, and often there is not one but a cluster of acceptable variants that all work fine in practice.

A variant is not automatically bad because it deviates from the BPMN diagram in the procedure handbook. A variant only becomes a problem when it brings more time, more rework or more risk than necessary. Variant analysis gives you the numbers to make that call.

What do you do with the insights?

A variant overview on its own changes nothing. In practice the findings lead to three types of action.

1. Standardise. If several frequent variants do essentially the same thing with small wobbles, pick one as the new norm. Usually you lose a chunk of the smaller variants without losing any function.

2. Automate. The largest variants are candidates for a workflow engine, a Power Automate flow or RPA. You know exactly which steps run in which order and how often that happens, so you can build the business case.

3. Ask questions. For the exceptional variants you go back to the process owner. Why does this detour happen? Is it a system fault, a customer that falls outside the pattern, or a workaround that has been running for years? Sometimes a fix follows, sometimes a deliberate decision to leave the exception alone.

What you avoid is blindly collapsing every variant into one. Variation is not always waste. Some variants exist because customers, products or countries differ. The goal is not the minimum number of variants, but the right number: enough to track your real business, no more than that.