Process Patterns: Recognizing Recurring Behavior in Operations

What Characterizes a Process Pattern

The pattern does not necessarily describe the entire process from beginning to end. Its value often lies precisely in revealing a limited segment: for example, the typical sequence of measurement, clarification, and rework, or a recurring combination of a material change and an additional test.

Repetition alone makes behavior neither right nor wrong. A frequent pattern can represent an established procedure, a tolerated workaround, systematic rework, or a data collection error. Only comparison with requirements, context, and substantive assessment gives it operational meaning.

Example: Recurring Rework in a Batch Process

A simplified, illustrative comparison considers two different batch paths. In the first, the subsequence Measure → Rework → Measure again is followed by the regular review and release. In the second, an additional test occurs between the repeated measurement and the regular review. Both paths begin with the completion of manufacturing.

The complete sequences differ, but the highlighted contiguous segment is the same. Pattern discovery here focuses on that segment: In which cases does it occur, under what conditions, and with what outcome?

In the illustrative 20-case example in the variants article, four cases of one path and two cases of the other contain this subsequence. That is six out of 20 cases, or 30 percent. The count is of cases with at least one occurrence; it is not a general quality metric for local process models.

The subsequence does not yet explain why rework was necessary. That would require examining, for example, the original measurements, the reasons for rework, and the outcomes. The shared segment narrows the investigation without treating all affected batch paths as equivalent.

The Same Subsequence in Two Different Paths

The process variants in the example differ because of the additional test. The contiguous subsequence “Measure → Rework → Measure again” occurs in both. Pattern discovery examines this segment; variant grouping examines the complete sequences.

The counting rule must specify whether it counts cases with at least one occurrence or individual occurrences. Otherwise, a case with two rework rounds could inadvertently enter a case-based proportion twice. Permitted intervening activities and gaps also belong in the pattern definition.

From Individual Events to Recurring Behavior

Process events record which activity was performed, when, and in what context. An individual event is initially an observation. Recurring structures can become apparent only when many comparable executions are considered together.

This requires events to be comparable in substance. Activities with the same name can have different meanings when performed under different SOP versions, on different products, or by different roles. Conversely, the same operational behavior may have different names in several systems. Unambiguous identities, controlled activity names, and an understandable context must therefore precede pattern discovery.

A pattern does not arise from visual similarity alone. It must be definable: Which activities belong to it? Which sequence or concurrency matters? What gaps may occur between the events? For which objects, periods, and process conditions should the repetition apply?

Process patterns do not replace data checks. Duplicate, missing, or incorrectly assigned events can create artificial patterns.

Structures That Process Patterns Can Represent

Local process models can express frequent behavior in greater detail than a simple list of consecutive activities. Research describes sequence, choice, concurrency, and loops in particular as structures that can be modeled.^[1]

• Sequence: Activity B regularly follows activity A.
• Choice: After A, either B or C is performed depending on a condition.
• Concurrency: B and C can occur independently or in varying order before D begins.
• Loop: A test or processing step is repeated until a state is reached.
• Omission: An optional step occurs only in particular situations.
• Handoff: An object, task, or responsibility repeatedly moves between roles or departments.

These forms should not be inferred hastily from individual temporal sequences. Concurrency, for example, requires more than varying order in a few cases. The selected model, data quality, and domain interpretation determine which structure is actually supported.

Local Patterns Instead of a Single Overall Model

A complete process model typically aims to describe behavior from the beginning to the end of a process instance. In highly variable processes, this can produce a hard-to-read model that allows almost any sequence. Local process models select a different scope: they describe frequent behavior within event sequences without having to explain the entire process.

Tax and his coauthors position local process models between classical process discovery and sequential pattern mining. They can include choice, concurrency, and loops alongside sequences while remaining focused on limited segments of behavior.^[1]

This local view is particularly useful when an organization is not asking about “the one process” but about a specific recurring relationship: Which steps frequently precede rework? Which tests occur together for a particular material group? At which handoff does an additional request for clarification regularly arise?

Frequency Is Only One Selection Criterion

A process pattern must occur often enough to be recognizable as repetition. Nevertheless, the most frequent structure is not automatically the most important. Very frequent, trivial sequences may contribute little analytically, while a rare pattern associated with a critical deviation may be highly significant.

Several quality dimensions have therefore been proposed for local process models, including support, confidence, coverage, language fit, and determinism.^[1] The metrics examine different properties. High coverage, for example, may accompany an overly general pattern; a very specific structure, by contrast, may capture only a few cases.

Assessment should be guided by the operational question. Interest-driven approaches therefore combine pattern discovery with utility functions and constraints so that patterns are selected not merely for frequency but for relevance to the analysis objective.^[2]

Context Determines Comparability

A pattern can appear frequent across all data yet be meaningless within a substantively comparable group. Before any assessment, it must therefore be established which executions may be considered together.

Relevant context characteristics can include product type, material group, site, equipment type, SOP version, performing role, shift, environmental conditions, or process phase. Their purpose is not to produce a desired result after the fact. They limit the comparison to situations in which the same substantive statement can be sound at all.

Temporal validity is also part of context. Recurring behavior under an earlier requirement must not be transferred to a new process version without review. When models, equipment, or responsibilities change, it must remain clear under which conditions the pattern emerged.

Patterns Need Stable Relationships

Process relationships determine which events, objects, states, and participants belong together in domain terms. Without these connections, an apparent pattern can arise from events that happen to be close in time.

In a batch process, the same activity, “Test sample,” can occur many times. For a meaningful pattern, it must remain clear which sample came from which batch, which test method was used, and which object the subsequent decision concerns. Only then can it be investigated whether a recurring sequence actually describes the same operational context.

Object relationships extend pattern discovery beyond individual case traces. A pattern can, for example, represent the repeated transition from material batch to production batch, sample, and release. It remains necessary to check whether all participating object types have been completely recorded and their roles consistently qualified.

Local Discovery Can Limit the Scope of Investigation

Process Discovery includes deriving models from event data; local models are also discovered. The distinction here lies in the scope considered. A local process model does not have to describe the entire path from process start to finish.

Many similar local models can nevertheless become difficult to navigate. Research on grouping such models addresses this redundancy.[4] Selection should support the investigation question without counting apparently different results multiple times merely because their representations differ slightly.

From a Discovered Pattern to Substantive Assessment

A discovered pattern is initially a testable hypothesis about recurring behavior. For its operational assessment, at least its frequency, affected objects, temporal distribution, contextual conditions, and possible counterexamples should be visible.

Substantive review follows: Is the structure intended? Does it arise only under particular conditions? Does it lead to a desired outcome, document a permissible exception, or show recurring rework? The same sequence may warrant different assessments depending on the product, process phase, and scope of application.

Only a documented decision may determine whether the pattern leads to a review rule, a process change, or further investigation. In process learning, a hypothesis is tested through a limited change to the process and renewed observation of its effects. If the data remain inconclusive, that result must also be recorded. Not every visible pattern calls for immediate intervention.

Process patterns do not make decisions. Substantive assessment and responsibility remain with the responsible people.

An Observed Pattern Is Not a Prescribed Control Rule

Workflow patterns describe reusable solutions to modeling and control problems.[3] The segment considered here, by contrast, is investigated in recorded processes. It can prompt a rule adjustment but does not determine it.

Likewise, co-occurrence with an outcome does not yet explain a cause. Whether rework was an appropriate response or a sign of an avoidable problem must be assessed using the individual cases.

The Open Question Lies Behind the Shared Segment

The two paths have the same rework sequence. This defines the scope of the pattern; its cause and assessment remain open. The investigation can now specifically seek the measurements, reasons for rework, and outcomes of these occurrences.

A useful process pattern thus precisely defines a recurring segment. It keeps visible what was counted and which differences persist outside that segment.

Process patterns do not prove causation. Recurring sequences can indicate a relationship but do not explain it on their own. They do not prevent a flood of results. Similar patterns must be grouped, filtered, and prioritized according to the analysis purpose.