Wondering what your processes really look like, not what the flowchart says? Process mining reads the digital traces your systems already record and rebuilds the real process from them, showing where work flows, stalls or goes off-script.
This guide is part of our series on business process management, and it explains the method in plain terms.
| Item | Value |
|---|---|
| Minimum log fields | Case ID, activity and timestamp |
| Main technique classes | Three |
| First practical discovery algorithm | Alpha miner, in 2000 |
| Later discovery algorithm | Inductive miner |
| Typical use case | No formal process description, or doubtful documentation |
Figures and descriptions come from Wikipedia’s process mining article; they can change, so check the source before you rely on them.
What process mining actually does
Most organisations believe they know how a process runs because someone once drew it. In practice, people skip steps, repeat work, wait for approvals and invent workarounds that never reach the diagram.
Process mining starts from evidence instead of opinion. It takes event data that software already writes down, such as an order system’s transaction records, and turns it into a model of what happened.
Wikipedia notes that these techniques are used “when no formal description of the process can be obtained by other approaches, or when the quality of existing documentation is questionable”. That covers a surprising number of real workplaces.
The field also sits close to older ideas. Wikipedia records that terms like workflow mining and automated business process discovery were used in the past for related work.
What data you need: the event log
Everything starts with an event log. Each row records one thing that happened, and the log is only useful if each row can be tied to a particular run of the process.
According to Wikipedia, the logs are generally built on a case ID, an activity, a timestamp, and sometimes other information such as resources and costs. The same page states that the event log data must be linked to a case ID, activities and timestamps.
- Case ID: a unique identifier for one process instance, for example one customer order or one support ticket.
- Activity: a description of the event that occurred, such as “invoice approved”.
- Timestamp: when it happened, which lets the tool put events in order and measure waiting time.
- Optional attributes: who did it, what it cost, which department was involved.
Typical sources are the audit trails of a workflow system, the transaction logs of an enterprise resource planning system, or electronic patient records, as Wikipedia’s overview lists them.
The three main classes of technique
Wikipedia states that there are three main classes of process mining techniques. They answer different questions, and you can use them in sequence.
- Process discovery: build a model from the log alone.
- Conformance checking: compare the log with an existing model.
- Enhancement: use the log to improve or extend a model.
Process discovery
Discovery is the first step. Wikipedia says the main goal of process discovery is to transform the event log into a process model.
The discovered model can describe sequences, choices, concurrent steps and loops. Wikipedia credits the Alpha miner with being the first practical algorithm for process discovery in 2000, and notes that more powerful algorithms such as the inductive miner followed.
Conformance checking
Here you hold a designed model against reality. The result is a list of deviations: steps skipped, steps done in the wrong order, or activities nobody planned.
This is especially useful for compliance and audit questions, because it shows where practice departs from the rule rather than guessing.
Enhancement
Enhancement adds information from the log to a model, for example average waiting times at each step. The model then shows where the bottlenecks are, not just the order of activities.
Reading a discovered process map
A discovered model is usually drawn as a map of boxes and arrows, with the busiest paths shown most strongly. Real logs produce many variants of the same process, so the first map can look like a tangle.
Do not try to read everything at once. Work through the map in a sensible order:
- Start with the most common path, the “happy path”, and confirm it matches what people expect.
- Look at the rare paths next, because rework loops and exceptions usually hide there.
- Check the time between events to find where cases wait longest.
- Ask the people who do the work why a surprising path exists before you judge it.
If the notation of a designed model is unfamiliar, our guide to bpmn symbols explained helps you read the diagrams that many tools export.
From findings to better work
Mining shows what is happening; it does not decide what to change. The value comes when findings feed a deliberate improvement effort, such as the approach described in our piece on business process improvement.
A practical way to start small:
- Pick one process with a clear start and end, such as order-to-cash or ticket handling.
- Find the system that records its events and confirm it stores a case ID, activity and timestamp.
- Extract a log, clean obvious errors and run discovery.
- Compare the result with the documented process using conformance checking.
- Share the surprises with the process owners and agree what is worth fixing.
Expect most of the effort to go into data preparation. Events spread over several systems must be joined on a common case ID, and activity names often need tidying before a map makes sense.
Limits and cautions
A log only shows what was recorded. Work done by phone, in meetings or on paper is invisible, so the mined model can be incomplete.
Wikipedia also observes that conformance checking techniques are closer to optimization than to traditional learning approaches, a reminder that results depend on how the comparison is set up and interpreted.
Finally, event logs can contain personal data about who did what. Treat them with the same care as any other employee or customer records, and focus the analysis on the process rather than on individuals.
Data quality is the other common trap. Missing timestamps, inconsistent activity names and events logged in batches can all distort a map, so a quick sanity check against a few known cases is worth the time before you present any result to colleagues.
Finally, remember that a surprising path is a question, not a verdict. Sometimes it is a genuine workaround that deserves to become the standard; sometimes it is a data error. Only the people doing the work can tell you which.
Frequently asked questions
What is process mining in one sentence?
It is a way of building and checking process models from the event logs that your systems already record, so you see how work actually runs.
What data does process mining need?
At minimum a case ID, an activity and a timestamp for each event, according to Wikipedia. Resources and costs are optional extras.
How is it different from drawing a process by hand?
A hand-drawn model reflects what people remember or intend. A mined model is built from recorded events, so it shows variants, delays and deviations that nobody drew.
Can it replace process documentation?
No. It complements documentation by testing it against reality. You still need people to explain why work happens the way it does.
