Process drift

What is process drift?

Process drift is a change in the way a process behaves over time. A model you discovered from last year's data stops matching what the process does now. The change can touch the control flow, the timing, the people and roles involved, the data, or the decisions being made.

Examples are easy to picture: a new approval step appears, rework drops, waiting time grows, or a different team starts handling the exceptions. Drift can be planned, through a policy change or a system release, or it can creep in unnoticed through a workaround, a capacity shortage or a shift in the mix of cases coming through.

It is the same idea as concept drift in machine learning, where the world a model was trained on quietly changes underneath it. For processes, the close relatives are model drift and data drift, which describe the same erosion for predictive models and their inputs.

The four shapes drift takes

Research on concept drift in process mining, much of it from Eindhoven University of Technology, sorts change into four patterns. Telling them apart matters, because each one needs a different comparison.

Sudden drift

Behaviour changes around a single switch-over point. A new ERP goes live on the first of the month and replaces the old order route from that day on. A time window before and after the point shows the difference clearly. Watch the cases that started under the old process and finished under the new one, and use release dates to explain a statistical signal in business terms.

Gradual drift

Old and new behaviour run side by side for a while. Teams migrate in phases, or people pick up a new way of working at different speeds, so the share of new variants climbs over weeks. A single hard cut-off date describes that badly. Splitting the data by team, region or product often shows whether the change is truly gradual or really several local sudden drifts stacked together.

Recurring and seasonal drift

Earlier behaviour comes back. A year-end close, a peak season or a periodic campaign can trigger the same variant every cycle. Recurring behaviour is not automatically a problem, and a detector with no sense of the calendar will raise the same alarm every year. Compare against the same period in earlier cycles instead of the previous month.

Incremental drift

The process shifts in small steps, for instance a throughput time that gets a little longer month after month as a backlog grows. Each step is too small to notice on its own and only becomes material over time. Control charts, trend analysis and successive windows bring it into view. Check that a trend in the average is not just a change in case mix by looking at volumes and spread as well.

What can actually change?

Control-flow drift changes the activities or their order. Performance drift affects time and queues. Organisational drift changes the resources, roles or handovers. Data drift changes the attributes of the cases themselves, like product mix or amounts, and that alone can move how the process behaves even when no rule was touched. Looking at these perspectives together helps, but it does not prove cause on its own.

How you detect it

The simplest approach compares frequencies, variants and performance between fixed time windows, with a statistical test to say whether the distributions really differ. More involved methods track the directly-follows relations between activities, the quality of a fitted model, features of each trace, or a live event stream, and look for the points where something changes.

Window size is the dial that matters. Small windows react quickly but jump at random noise; large windows are steadier but miss short or local changes. Conformance checking is a close cousin here: instead of comparing two periods, it compares the running process against the model you expected, and a rising stream of deviations is often the first hint that the process has drifted.

Process drift versus a data quality problem

A changed logger, a timezone shift or a remapped activity name can look exactly like drift. A newly mandatory event registration can look like a brand-new process step. Before drawing an operational conclusion, check the source releases, the missing data, the correlation rules and the log volumes. Keep the raw lineage and compare the same definitions over time, or the analysis ends up measuring its own data transformation instead of the process.

Process drift versus a segment difference

A new type of customer can follow different routes while the process stays stable for each type on its own. The combined event log then looks like it changed, when really the mix of segments changed. Stratify on the attributes that matter and compare within segments, watching out for small groups. A genuinely new segment can be a real business change, but it calls for a different response than process non-compliance does.

From detection to action

Confirm the pattern with concrete cases and the people who know the process, and tie it to a release, a policy, a capacity change or an outside event where you can. Then decide what should move: the model, the control limits, the staffing or the process design. Unwanted drift calls for root cause analysis; wanted drift may just need a new baseline. Version your process and predictive models by the period they are valid for, and keep watching after a change to see whether behaviour shifts again.