What Process Mining Is
Reconstructing how a process actually runs from the timestamps your systems already record, rather than from how anyone believes it runs.
Explainer
Process mining takes event records out of the systems that support a process and reconstructs what actually happened, case by case.
The core idea
Every transactional system records events with timestamps. An order created, approved, amended, shipped. Each carries a time, an identifier for the case, and a name for what occurred.
Sorted by case and by time, those events describe a path.
Aggregated across thousands of cases, the paths describe the process — including the variants nobody documented.
That is the whole mechanism. Everything else in the field is analysis on top of it.
What it replaces
Workshops, where people describe the process they believe runs.
Documented procedures, which describe the process someone designed.
Sampling, where a few cases are traced by hand.
All three are useful and all three systematically miss the exceptions, which is where most of the cost sits.
What it produces that the alternatives do not
The real variant count. A process everyone describes in one diagram usually runs in dozens of distinct paths.
Frequency. How often each path occurs, which the documentation never states.
Duration, with waiting separated from working.
Rework loops, where a case returns to a step it already passed.
Deviations from the designed path, measured rather than suspected.
What it needs
An event log: case identifier, activity name, timestamp. Three columns.
More columns help — resource, cost, attributes for filtering — and three is the minimum.
The extraction is most of the work, and it has its own section.
What it is not
Not task mining, which captures activity on individual desktops and is a different thing with different obligations. Covered separately.
Not business intelligence. A dashboard reports metrics; process mining reconstructs sequence, which is what reveals rework and waiting.
Not simulation, though tools bundle it. Discovery describes what happened; simulation predicts what might, with much weaker guarantees.
Not automation. It identifies candidates. Building them is a separate project with a separate budget.
Where it earns its place
Processes that run at volume through systems that log events.
Processes with disputed performance, where the argument is about facts nobody has.
Processes about to be automated or redesigned, where knowing the real variants prevents automating a fiction.
Compliance questions, where the requirement is to show what actually happened.
Not processes with low volume, no system support, or where the answer is already known and the constraint is willingness to act on it.
The first week
Four steps that establish whether this will work in your organisation.
Pick one process that runs at volume through one system.
Extract three columns for three months: case identifier, activity, timestamp.
Count the distinct paths. The number is almost always far higher than anyone expected, and that number alone justifies the exercise.
Show it to the people who run the process and ask whether it matches what they see.
No licence required for any of this. A spreadsheet with a pivot table gives you the variant count, and the variant count is the finding that starts the conversation.