What is process mining?

Every operation runs on processes. Steps happen in a sequence, with rules and expectations about what comes next, how long it should take, and what happens when something goes wrong.

Most organizations think they know how their processes work. They have flowcharts and SOPs. They have the version someone drew on a whiteboard three years ago that everyone still references.

They're usually wrong.

The documented process, if it exists, is what people agreed should happen. The actual process is what the system does. These diverge almost immediately, and they keep diverging. The longer the operation runs, the wider the gap between the map and the territory.

Process mining closes that gap. It recovers the real process. Not from interviews, documentation, or what people remember. It uses the data that the system already emits.

The core idea

Digital systems leave traces. An ERP logs when a purchase order is created. A hospital system records when a patient moves from triage to imaging. A ticketing system timestamps every state change. A robot uses logs to mark state transitions and errors.

These traces are called event logs. Each entry has three things: a case identifier (which process is it), an activity (what happened), and a timestamp (when).

That's it. Case, activity, time. From those three fields, you can reconstruct the actual process from what was supposed to happen.

Process mining takes those event logs and builds a model of the real process. Not the intended one. The one that's actually running.

A short history

Wil van der Aalst, a computer scientist at Eindhoven University of Technology, formalized process mining in the late 1990s. His work grew out of two adjacent fields: business process management (BPM), which modeled how processes should work, and data mining, which found patterns in large datasets. Process mining sat in the gap between them; using data mining techniques to discover how processes actually work.

Van der Aalst published the foundational algorithm, the Alpha algorithm, in 2004. It could take a raw event log and automatically discover the underlying process model. The log drew it and surfaced the control flow, the parallelism, and the decision points, without any human having to draw the flowchart.

The field grew slowly through the 2000s, mostly in academic research. The first commercial tools included Disco (Fluxicon), Celonis, and Minit, starting around 2011–2013. Celonis, founded in Munich in 2011, became the category's breakout company, eventually reaching a $13B valuation by applying process mining to SAP-heavy enterprises. Now there are many companies using process mining for business process intelligence. In 2026, Gartner renamed its Magic Quadrant from "Process Mining Platforms" to "Process Intelligence Platforms," reflecting how far the discipline has moved beyond its academic roots

The IEEE published the Process Mining Manifesto in 2011, signed by 77 researchers and practitioners, which codified the field's principles and made the case that process mining was a distinct discipline instead of a subset of BPM or Business Intelligence.

The three types

Process mining does three major things:

Discovery. You have event logs but no model. Discovery builds the model from scratch. You feed in the logs, and the algorithm produces a process map showing every path the process actually takes. This is the foundational capability that allows you to see the real process.

Conformance checking. You have a model (the intended process) and you have event logs (the actual process). Conformance checking compares them. Where does reality deviate from the spec? How often? By how much? This is where you find the workarounds, the skipped steps, the rework loops that nobody documented because they became normal.

Enhancement. You have a model and you want to make it better. Enhancement uses the event logs to annotate the model with performance data such as where the bottlenecks are, where the wait times cluster, where resources are overloaded. Same model, richer picture.

Why it matters

Before process mining, understanding an operational process meant one of two things: you asked the people who run it (and got the idealized version), or you instrumented it manually (expensive, slow, usually abandoned).

Now, if the data already exists in your system logs, the process model is sitting there, waiting to be recovered. No new instrumentation. No interviews. No consultants mapping sticky notes on a wall for six weeks.

The result is legibility. A process you can see is a process you can measure. A process you can measure is a process you can improve.

Where it lives today

Process mining matured in enterprise operations such as procurement, order-to-cash, accounts payable, IT service management. Anywhere a well-structured ERP or ticketing system emits clean event logs, the technique works almost out of the box.

The next frontier is less structured environments. Healthcare processes that span multiple systems. Manufacturing lines where the "event" is a sensor reading, not a database entry. Operations where the data is continuous, not discrete.

That frontier is where the field is heading. The core insight is mechanism-agnostic: recover the real process from what the system emits, then measure against it. It works anywhere a system produces traces of its own behavior. The question is how far those traces extend, and what it takes to make unstructured signals look like events.