Don't Panic: Process Mining

Process mining reconstructs the paths that work takes from recorded events. An invoice passes through receipt and checking before approval and payment. Another returns to checking for a second visit. A third arrives at payment with no approval in its recorded journey. A total invoice count treats all three as invoices. Process mining keeps the journeys visible.

The starting point is an event log, a collection of recorded activities organized for analysis. The conventional approach supplies three coordinates for each event: which case it belongs to, which activity occurred, and when. The case represents a process instance, such as an invoice. Read its events in order and you have a trace. A variant groups traces whose activity sequences match. A repeated check separates variants even if their activity names otherwise match.

There is an inconvenient detail: a database does not know what you meant by the process. An invoice identifier follows an invoice. A supplier identifier can connect work across many invoices. Both produce sequences, but they answer different questions. Choosing the case notion is part of the analysis, not a clerical task that can safely be left to whichever column looks tidy.

Three ideas organize the field. Discovery turns the recorded paths into a model. Conformance checking places those paths beside a process model to locate differences. Enhancement adds information to a model or repairs it using the recorded behavior. The common path in a discovered map describes recorded behavior. Its popularity is not a permission slip.

A directly-follows graph connects activities recorded consecutively and summarizes their frequency. It compresses many traces into one picture. That compression loses context: you can follow combined edges along a route that no individual case traveled. Variants retain complete sequences. Formal models add execution structure, which matters when the question is what behavior a process permits.

Timing deserves the same care. The gap between the first and last recorded events gives the observed case duration. A gap between two completion events does not identify pure waiting time. Removing the final event can make a case appear faster while removing the evidence that it finished. The spreadsheet has become more cheerful; the underlying work has not changed.

Some processes refuse to fit one case perspective. One payment can settle several invoices. An object-centric event log connects events to multiple objects so those relationships remain available. It adds expressive power, while leaving the analysis question firmly in your hands.

Read the Intro for the data path and the different model types. Use the Cheatsheet to compare measures and their limits. The Exercise makes variants, elapsed times, and a stated approval rule visible in four synthetic cases. The Reference tab then takes you toward formal conformance and object-centric analysis. Treat the result as evidence about recorded execution, and test the explanation before changing the process.