Process variant

What is a process variant?

A process variant is one distinct path through a process: a unique sequence of activities that a group of cases all followed. If a thousand orders all went "created", "approved", "shipped", "paid", they share one variant. An order that needed an extra "re-check" forms a different one.

Variants make frequent and rare behaviour comparable. They do not say a path is right or wrong on their own. A rare variant can be a perfectly legitimate but complicated case.

The most common variant is often the happy path, the clean run everyone pictures when they describe the process. Real logs usually show it is only part of the story.

From trace to variant

Every process instance leaves a trace: its own ordered list of events. A process mining tool turns each trace into a variant key, usually by stringing together the activity names in order. Traces with the same key fall into the same variant.

Per variant you can then work out the number of cases, the share of the total, the median throughput time, how much rework happened, and how cases ended. The rule for what counts as the same path can be stricter, for example including who did each step. Say which rule you used, because the number of variants shifts a lot depending on it.

A worked order example

Variant A is "created", "approved", "shipped", "paid": the straight run. Variant B adds "credit hold" and "released". Variant C is "cancelled" before shipping. Variant D approves twice because of rework.

Compare volumes and throughput times and Variant B turns out slower, but mostly for one customer segment. That is a lead, not a conclusion; further analysis has to say whether credit policy, missing data, or seasonal pressure is behind it. Variant C is not necessarily bad either: a clean cancellation can beat shipping to a customer who withdrew in time.

Process variant versus variant analysis

The variant is the group or the path. Variant analysis is the method that counts variants, compares them, and explains them: which ones finish late, in which department they appear, and which extra step makes the difference.

Do not assume the most frequent variant is the intended process. Compare it against policy, customer outcome, and what the people who run the process actually know.

Granularity and variant explosion

Fine-grained activity labels, repeated steps, and technical events quickly create many unique variants. This is called variant explosion, and it buries the patterns you care about.

Normalise labels that mean the same thing in business terms, and only filter out technical events when there is a real reason to. Merging too aggressively can hide genuine controls. A top-ten view is handy, but also check how much work sits outside the top: hundreds of small variants can add up to a large share.

What to watch out for with process variants

Check open cases separately, because their trace is not finished yet and will look like an odd short variant. Account for the extraction window and for events the source systems never recorded.

Compare performance only with enough cases behind each variant. One slow case makes a small variant statistically shaky. Use variants to ask questions, not to end them: why does this path exist, is it allowed, and which step adds value or rework? The improvement or automation decision comes after that.