Process mining: how event data reconstructs the way work runs

1The problem it addresses

Most organisations can produce a diagram of a core process on request. Far fewer can say how that process behaved last Tuesday, which route the majority of cases took, or where the slowest tenth of cases lost their time.

This is not a documentation failure so much as a measurement gap. Customer onboarding, payments, order management and supply chain logistics all execute across several systems, and no single system holds the end-to-end record. Each reports its own segment accurately, and the assembled picture exists nowhere.

The practical consequence is that improvement work begins from an account of the process rather than an observation of it — and the difference between those two is usually where the cost sits.

2Inputs and mechanism

Every interaction inside an enterprise system leaves a record. Approving a loan, releasing a shipment, posting an invoice: each writes a row somewhere, with a time attached. Process mining assembles those rows into cases and reconstructs the sequence.

Event log

The input. At minimum, each event carries a case identifier (which order, which loan), an activity name (what happened) and a timestamp (when). Additional attributes — user, cost centre, plant, product — enable segmentation.

Case

One instance of the process from start to finish. The unit of analysis.

Variant

A distinct sequence of activities. A process with a documented four-step path routinely shows dozens of variants in practice; counting them is often the first useful output.

Conformance

The comparison between reconstructed execution and the designed process. What it measures is deviation, not error — some deviation is competent handling of a case the design did not anticipate.

From this, the reconstruction produces the real flow of work including variations, exceptions and loops that no participant would have described, because from inside a process they do not look like deviations. They look like Tuesday.

A modern platform extends this by connecting to source systems directly through read-only integration — SAP, ServiceNow, Pega and comparable systems — and maintaining the model continuously rather than rebuilding it per study. Simulation of a proposed change against observed volumes is a further extension, allowing an intervention to be tested before it is funded.

3What it makes visible

Four categories of finding recur across deployments, regardless of sector.

• Waiting. Time between activities rather than within them. In most processes this dominates total cycle time, which is why interventions aimed at working faster tend to disappoint.
• Rework. Cases that move backward — reopened, returned, re-entered. Individually cheap and collectively expensive, and invisible in reporting that counts only completions.
• Variation. The same designed process executing differently across regions, entities or teams, which makes benchmarking between them unreliable until it is quantified.
• Exception paths. Low-frequency routes carrying disproportionate delay. These are the highest-yield target precisely because they are rare enough to have escaped attention.

The value of these findings is that they are quantified. Everyone involved in a process suspects where the friction is; a reconstruction settles which suspicion is correct and how much the friction costs.

4Reported effects

Deployments in this field report improvement in four areas. The figures below are drawn from RE-ViVE engagements and should be read as observed ranges rather than forecasts.¹

The manufacturing result is the clearest illustration of why this technique matters to finance rather than only to operations. A rework loop inside a warehouse is an operational nuisance; the same loop expressed as a twelve percent monthly delay in working capital is a treasury problem. Neither the operations team nor the finance team could see that connection from their own systems.

5Limits of the technique

There is also a cadence limit. Traditional implementations are built as studies: extract, model, analyse, report. Reported effort for that approach runs to 100–300 hours per process,² and the resulting model begins to decay as soon as operations change. In environments where product mix, staffing or regulation shift continuously, the analysis describes a business that has already moved.

This limitation, rather than any weakness in the technique itself, is what continuous process intelligence exists to address: the same reconstruction, maintained rather than repeated.

6Deployment

The established pattern is narrow and read-only.

1. Select one processChoose a workflow that is already causing measurable pain and whose performance can be assessed clearly. Order to cash, onboarding and claims are common starting points because volume makes patterns legible.
2. Grant read-only accessTo the systems that process touches. No modelling workshops, no configuration changes, no write access to production.
3. Capture the baselineBefore any intervention. This is cheap at the start and impossible to reconstruct afterwards, and without it no improvement claim can be substantiated.
4. Review and prioritiseVariants, bottlenecks, rework patterns and manual dependencies, ranked by measured cost rather than by which team raised them.

The reason to start narrow is evidentiary rather than technical. A single process produces findings that the operating team can check against what they already believe, and that comparison is what establishes whether wider deployment is worth funding.

—References