Process Variants

A variant is one distinct path objects take through your process. Variants tell you how much your process really varies, which routes carry the volume, and which ones are quietly costing you time.

What are variants?

A variant is a unique sequence of activities. However standard your process is on paper, real execution branches: conditions, exceptions, rework and judgement calls all produce different routes.

A simple example

In the Order to Cash example, looking through Sales Orders, you see paths like these:

Straight through — created and never touched again

Create Sales Order

Blocked and released

Create Sales Order → Block Sales Order → Unblock Sales Order

Still blocked

Create Sales Order → Block Sales Order

Delivery date changed

Create Sales Order → Change Sales Order Delivery

Where variation comes from

• Business rules — high-value cases get extra review
• Exceptions — a problem triggers extra steps
• Judgement — people choose different routes
• Rework — cases loop back for corrections
• Special handling — urgent cases skip steps

Why variants matter

The main path may not be the one you designed

The most common variant is usually the process people think they run. When it accounts for 70% of objects, the process is disciplined. When it accounts for 25%, the process on paper and the process in reality have come apart, and that gap is the finding.

Rework shows up as its own route

A variant that loops back is doing the same work twice. It normally takes several times longer than the equivalent straight path, so it is worth measuring before it is worth arguing about.

Effort goes where the volume and the time are

Improvement is worth aiming at the variants that carry the most objects, the ones that take the longest, and the ones that carry the highest-value work — usually not the same three.

Using the Variants page

The page is a process map on the left and a Select Variants panel on the right.

Above the map you always see where you stand: how many variants are selected out of how many exist, how many objects that covers and what percentage of the total, with a reminder that each variant is one distinct path objects take.

The Select Variants panel

Variants are listed by frequency, most common first. Each row shows:

• The variant number — #1, #2, and so on
• Object count — how many objects took this path
• Percentage — what share of the total that is

Above the list, a coverage line reads Top N of M cover X% of objects, and hovering a row tells you the cumulative coverage up to and including it. That is usually the fastest way to find where the long tail begins.

Selecting — tick variants to draw them on the map. Select All takes or clears the lot.

Previewing and pinning — hover the eye icon on a row and that variant's path lights up on the map in a colour. Click it and the highlight is pinned, so it stays while you hover others; several variants can be pinned at once, each in its own colour. This is how you compare two routes without losing track of which edge belongs to which.

Turning a selection into a filter

Next to Select All is a With / Without toggle. It turns whatever you have selected into a filter that every other page in the project answers to:

• With — keep only objects that follow exactly the selected paths
• Without — keep only objects that do not

The filter is stored as the paths themselves, not as a list of object IDs, so it stays meaningful as new data arrives: an order that lands next week and takes the same route is in the cohort.

That makes the flow "find the rework variant → filter to it → open Compare or the copilot and ask what those objects have in common" a two-click move rather than a research project.

The rest of the page

The variants map carries the same controls as the process map: the lens chips for the object type, the right-hand rail for display, crop and fullscreen, and the All / Completed / In-Flight toggle along the bottom. If your project has no terminal events defined, the completion toggle tells you so and points at Data Scope.

Variants and parallel tracks

Where work runs concurrently, sequence is the wrong thing to compare. If three sub-assembly lines run at once, the order their events happen to be recorded in is an accident, and treating each ordering as its own variant produces dozens of meaningless variants.

Where parallel tracks are declared, variants understand them: two objects that did the same work in a different order within a lane count as the same behaviour. If your variant list looks explosively long for a process you know to be simple, concurrency is the first thing to check.

Patterns worth recognising

Linear progression — A → B → C → D. No branches, no loops. A predictable, well-defined route.

Early termination — the path ends before the final step. Rejection, cancellation, or work abandoned.

Skips — A → B → D, missing C. Conditional logic, automation, or a control being bypassed.

Rework loops — A → B → C → B → C → D. Corrections and re-reviews. Usually the slowest variants in the list.

Reordering — the same activities in a different sequence. Genuine flexibility, or concurrency that should be modelled as parallel tracks.

Escalation — extra approval steps for a subset of cases. Fine if it matches policy; worth questioning if it does not.

How to work the page

Start at the top. Read the coverage line, select the variants that make up most of your volume, and understand those routes before looking at anything else.

Then look at what should not be there. Steps in an order that should be impossible, a control being skipped, rework where you did not expect any.

Compare two at a time. Pin variant #1 and variant #2 and read the difference on the map. Where do they diverge, and what does that divergence cost?

Isolate the outliers. Deselect everything except the rare variants. A path taken twice in a year is not a process problem, but it is often a data-quality one.

Then ask why. Filter to a variant with the With toggle and take the cohort somewhere that can explain it — Compare against the rest of the population, or the copilot.

Next steps

Read the detail

• Process Map — node and edge metrics behind these paths

Let the analysis come to you

• Co-Pilot — ask what distinguishes one variant's objects from another's

Narrow further

• Filters & Exploration — combine a variant filter with attributes, timeframes and paths