Making Different Execution Paths Visible and Comparable

Process Variants: How Actual Execution Paths Differ

20 cases are distributed across four process paths. Which differences count as a separate variant, and which remain within the same group?

System KnowledgeNESS Online GmbHPublished: Last updated:

Brief definition: Process variants are distinct execution paths of the same process under consideration. In a simple trace-based perspective, cases with the same ordered sequence of activities form one variant. [2]

What Process Variants Mean

A variant is initially a data-based grouping. It is neither automatically an approved process path nor a deviation. Whether an observed path is permissible, undesirable, necessary, or merely the result of poor event data requires substantive assessment.

Example: Four Paths to Release or Hold

A simplified, illustrative event log contains 20 completed cases. In this example, two cases belong to the same variant if and only if their complete activity sequences match. The scope begins with the completion of manufacturing and ends with release or hold.

VariantActivity SequenceCasesShare
AComplete manufacturing → Measure → Review → Release1260%
BComplete manufacturing → Measure → Rework → Measure again → Review → Release420%
CComplete manufacturing → Measure → Rework → Measure again → Additional test → Review → Release210%
DComplete manufacturing → Measure → Review → Place on hold210%
TotalAll cases considered20100%

B and C are different variants even though they share the rework sequence. The additional test changes the complete sequence. Conversely, two cases of variant A can take different amounts of time or consume different resources without belonging to different variants under this grouping rule.

The table contains no time or consumption measurements. It therefore cannot identify either the fastest variant or a cause of rework. Initially, it shows which execution paths occur and how often in this illustrative dataset. For performance analysis, the individual cases would need to be connected to the corresponding measurements and comparison conditions.

First Define When Two Sequences Count as Equal

In the 20-case example, the complete activity sequence is the equality rule. B and C are therefore different because of the additional test. Times, material quantities, and the people performing the work do not change this assignment here. A different question might require a different comparison rule.

Clearly defined process events are a prerequisite. Combining the start and completion of a test produces different sequences than considering them separately. Switching from batches to tasks as cases also changes the grouping.

For overlapping activities, an artificial total order can create differences that arise only from sorting. Schuster and colleagues investigate variants from partially ordered event data.[2] Simultaneity and sequence must therefore be handled explicitly.

Cases still running at the boundary of the observation period must not be treated as aborted without review. Technical duplicate deliveries must likewise be distinguished from actual repetitions. Both decisions change the visible variants and belong in the documented data preparation. The Process Mining Manifesto identifies incomplete event data, outliers, and the assignment of events to cases as challenges in data preparation, without addressing these two situations individually.[1]

From an Individual Trace to a Recurring Variant

In a classical event log, the events of a case are ordered temporally or logically. The resulting sequence is called a trace. If a case contains activities A, B, C, and D, its trace can be represented simply as ⟨A, B, C, D⟩.

When the same sequence recurs in other cases, those executions are assigned to the same trace variant. The Process Mining Manifesto describes event logs as the starting point for discovering, monitoring, and improving real processes.[1] The variant perspective condenses many individual cases without merging them into a single average process.

This condensation is useful because real logs can quickly contain thousands of cases. Instead of examining each batch separately, it is possible to first identify which activity sequences occur frequently, rarely, or only during a particular period. From the variant, the analysis can then return to the specific cases and their complete context data.

Variants Differ in More Than Additional Steps

One process sequence can differ from another in several ways:

  • Insertion: An additional test, correction, or rework step occurs.
  • Omission: An expected activity does not appear in the trace.
  • Order: Two activities are performed in a different sequence.
  • Repetition: An activity or subsequence is performed multiple times.
  • Branching: A decision leads to an alternative process path.
  • Termination: The case ends before an expected completion state.

For large sets of variants, a simple list is often insufficient. Comparison methods can examine differences at the level of individual activities, directly-follows relationships, or complete traces. Taymouri, La Rosa, and Carmona show that fine-grained comparisons can produce many individual differences and therefore propose a statistical analysis of complete trace structures.[3]

The appropriate representation depends on the question. For a specific deviation investigation, a single additional review step can matter. For a comparison between two sites, a pattern of several related differences may be more informative.

Process patterns focus on such recurring local structures, which can occur within several complete variants.

Frequency Shows Prevalence, Not Quality

One of the simplest analyses is the frequency distribution. It shows how many cases are assigned to each variant and what share of the log under consideration each represents. Often, a large proportion of all executions can be described by a few variants, alongside many rare paths.

This distribution must not be hastily read as a ranking of good and bad processes. The most frequent sequence may contain a systematically practiced but substantively undesirable shortcut. A rare variant may represent a correctly controlled special case, a necessary safety path, or a low-volume product type.

Rarity is nevertheless a useful selection criterion. Newly appearing or unusual paths can be reviewed specifically. The operational context must be preserved, however: a path that is rare overall may be entirely normal for a particular product class or process state.

Throughput Time and Outcome Complement the Process Path

Two cases can have the same activity sequence yet differ significantly. One completes the process in two days, while the other takes two weeks. Variant analysis should therefore consider time, outcome, and resources alongside the control-flow perspective.

For each variant, comparisons can include throughput time, waiting time, rework quantity, material consumption, energy use, scrap, release rate, or the number of required tests. These metrics do not automatically explain causes, but they indicate which variants warrant closer investigation.

Results become comparable only when the units of reference and contextual conditions match. Higher energy consumption may result from an unnecessary loop, but equally from a larger batch, a different product type, or required temperature control. Variant analysis should therefore consider sequence, performance, and operating conditions together.

Comparison Groups Need Understandable Context Boundaries

An overall distribution across all cases can hide relevant differences. Useful segments may include site, product, line, SOP version, shift, supplier, material class, or period. It can then be investigated whether a variant occurs with similar frequency everywhere or is tied to particular conditions.

Segmentation must be defined transparently before substantive conclusions are drawn. If groups are repeatedly changed until a conspicuous difference appears, the risk of random or misleading results increases. Very small groups can also give excessive weight to individual special cases.

A good analysis therefore shows absolute case counts, the period, inclusion and exclusion rules, and relevant contextual differences alongside percentages. This keeps it clear whether a pattern is robust or merely the result of a very narrow filter.

Variants Change Over Time

A variant distribution is always tied to the period under consideration. After a new SOP version, an equipment change, training, or a change in material source, familiar paths can shift and new variants can emerge. An overall picture spanning several years can hide these changes.

A comparison over time therefore requires consistently defined activity and object references. Otherwise, a simple renaming appears as a new process path or a change in granularity as an additional work step. Versions of the process definition, event schema, and analysis rule should be documented together with the analysis period.

The question is not only whether a variant is new. Its share, duration, affected product or material groups, and outcome are equally relevant. This makes it possible to assess whether a controlled change actually has the expected effect or merely produces different process patterns.

A Group Assignment Must Be Verifiable Down to the Case

Variant C contains two cases in the example. For both, it must be possible to identify the original events that form the sequence, including the additional test. If the group representation and individual cases do not match, the foundation of the comparison is already questionable.

A sample check therefore follows the path back from the variant to the event sequence and its preparation. It can reveal assignment errors but does not replace a complete review of the dataset. Filters and grouping rules must be retained so the analysis can be repeated.

Unrecorded work remains invisible. Missing or inconsistent events can distort variants.

Multiple Objects Create Multiple Possible Variant Perspectives

Real operational processes do not always follow exactly one case number. A batch uses materials, passes through tasks and tests, uses equipment, and can split or merge with other objects. Different process variants result depending on which object is chosen as the case.

Object-Centric Process Mining preserves relationships between events and multiple objects. OCEL 2.0 supports many-to-many relationships and qualified links between events and objects.[4]

The variant question does not disappear. It becomes more precise: Should the path of a batch, material, sample, task, or piece of equipment be compared? Should several object lifecycles be considered together? The answer depends on the operational question and must not be determined solely by the most technically convenient identifier.

Variants and a Discovered Process Model Are Different Views

A variant list preserves specific activity sequences. Process Discovery generalizes many executions into a process model that can express alternatives, concurrency, loops, and recurring structures.

The two views complement one another. The discovered model provides a shared overview of observed behavior. Variants, by contrast, show which specific paths actually occur in the log and with what frequency. A model can allow behavior that was not observed in full in any of the cases considered; a variant list remains limited to the existing sequences.

An investigation can navigate from the model to an unusual path, from there to a variant, and finally to individual cases. This keeps the abstract structure connected to actual execution.

A Variant Is Not Yet a Deviation from the Intended Process

Variant analysis describes differences within observed behavior. Whether a path conforms to the expected model is assessed through conformance checking. This requires a domain requirement or formal specification as the comparison basis.

A frequent variant can be fully conformant, partially deviate, or reveal a substantively necessary special case missing from the intended model. A rare variant can likewise be correctly modeled and permissible. Variant frequency and model conformance are therefore separate characteristics.

This distinction prevents a typical misconception: the most frequent observed sequence does not automatically become the new standard. Reasons, outcomes, risks, and applicable requirements must first be assessed. Only then can a decision be made about whether to adjust the intended process or change actual execution.

Grouping Execution Paths from 420+ According to a Rule

Execution paths within 420+ are grouped according to a defined comparison rule. The path back from a group to its batches and events makes differences in outcome, duration, and working conditions open to investigation.

Linking material, SOP version, person or role, and result within the task context provides part of the data foundation for Process Mining.

The Additional Test Explains the Difference Between B and C

B and C share a rework sequence yet remain different variants under the chosen rule. Two cases of A, by contrast, can take different amounts of time and still belong to the same variant. The equality rule determines which difference is counted.

A variant analysis is therefore understandable when it explains the grouping, case count, and data scope. Statements about performance or causes require the corresponding measurements and investigation of individual cases.

Primary Sources and Further Reading

  1. IEEE Task Force on Process Mining, Process Mining Manifesto, in: Business Process Management Workshops, LNBIP 99, 2012, pp. 169–194. Original source
  2. Daniel Schuster, Lukas Schade, Sebastiaan J. van Zelst, and Wil M. P. van der Aalst, Visualizing Trace Variants From Partially Ordered Event Data, in: Process Mining Workshops (ICPM 2021), Lecture Notes in Business Information Processing 433, 2022, pp. 34–46. Original paper
  3. Farbod Taymouri, Marcello La Rosa, and Josep Carmona, Business Process Variant Analysis Based on Mutual Fingerprints of Event Logs, in: Advanced Information Systems Engineering, CAiSE 2020. Original paper
  4. OCEL Standardization Working Group, Object-Centric Event Log 2.0, 2023, particularly event-to-object and object-to-object relationships. Original specification