Fluency

Process Drift

Last updated

Process drift is the gradual divergence between how a process is documented and how it is actually performed. It is why documentation goes stale almost immediately, and it is only visible against a baseline that keeps updating.

What Process Drift actually means

Drift is not misconduct and it is usually not even a decision. A system changes and someone adds a workaround. A person leaves and their replacement learns a slightly different version. Volume rises and a check gets skipped to keep up. Each adjustment is individually reasonable and locally invisible, and their accumulation is what separates the documented process from the real one.

The reason it goes undetected is that nothing in normal operations compares the two. Documentation is written once and reviewed on a cycle measured in years. Reporting measures outputs, which often look unchanged while the path producing them shifts underneath. The divergence surfaces at an audit, during an incident, or when an automation built against the documented process meets the real one and fails.

Drift has a direct cost for automation, which is that it is the main reason deployments degrade after launch. An automation encodes the process as it was understood at build time. The process keeps moving. Every increment of drift widens the gap between what the automation expects and what it receives, until enough cases route to exception handling that the automation stops paying for itself.

Detecting it requires a current reference to compare against, which is what a continuously updated baseline provides. With one, drift is a signal available in the quarter it happens, and it can be treated as information rather than as a failure: sometimes the drift is people finding a better path, in which case the documented process is what needs correcting.

Examples

The workaround that became the process

A system upgrade breaks a field mapping. Someone starts maintaining the value in a spreadsheet as a temporary fix. Two years later the spreadsheet is load-bearing and appears in no documentation.

An automation degrading quietly

An automation launched at ninety-four percent straight-through processing is at sixty-one percent eighteen months later. Nothing broke. The upstream process drifted, and the exception queue absorbed the difference.

Drift worth adopting

A team consistently omits a review step for low-value cases. Outcome data shows no increase in error rate. The drift is an improvement, and the correct response is to change the standard rather than enforce it.

Frequently asked questions

Process drift is the gradual divergence between how a process is documented and how it is actually performed. It accumulates from individually reasonable local adjustments to systems, staffing, and volume, none of which get reflected in the documentation.

Because nothing in normal operations compares the documented process to the performed one. Documentation is reviewed on a multi-year cycle, and output reporting often looks stable while the path producing the output changes underneath it.

It is the main reason deployments degrade after launch. An automation encodes the process as understood at build time while the real process keeps moving, so an increasing share of cases fails to match expectations and routes to exception handling.

By comparing current observed execution against a baseline that is itself kept current. A frozen baseline cannot distinguish drift from ordinary change, and documentation is not a usable reference because it is the thing being drifted away from.

No. Some drift is people finding a faster or safer path than the documented one, which is where the golden path comes from. The problem is not that work changes, it is not knowing that it changed, which removes the choice between adopting the change and correcting it.

Ready to deploy AI across your enterprise?

Discover how Fluency can help you continuously deploy AI.