Process Mining: The Three Types, and Why Discovery Is One of Them
Process Mining is a family of techniques that analyze event logs to reconstruct how a process actually runs, in three types: discovery, conformance checking and enhancement.
Before you start
Is this your framework?
Process mining answers one question: how does this process actually run, according to the data rather than according to anyone's account of it. It reads what your systems already recorded.
It needs event data with case identifiers and timestamps. If that data does not exist, no amount of tooling helps, and the table below points at what works without it.
| If your real problem is… | You probably want |
|---|---|
| There is no usable event data, and we need the process documented | Value Stream Mapping — built by walking the process, which needs no logs Compare Process Mining and Value Stream Mapping |
| We know where the problem is and need to fix the variation | Lean Six Sigma — DMAIC, which process mining feeds rather than replaces Compare Process Mining and Lean Six Sigma |
| One step limits the whole system and the rest is noise | Theory of Constraints — the bottleneck, which a discovered model can show but not interpret |
| We need to govern and standardize processes across the organization | Business Process Management — the discipline process mining supplies evidence to |
| We want to compare our performance against other organizations | Benchmarking — external comparison, which your own logs cannot give you |
| We need to decide which measures to report on at all | Key Performance Indicators — selecting and owning measures |
| The documented process and the real one have diverged, and nobody knows by how much | Process Mining — you are in the right place |
What Is It?
Every system that handles work leaves a trail. An order management system records when an order was created, approved, picked, shipped. A case management system records who touched what and when. Process mining reads those records and reconstructs the process from them.
The value is in what that reveals. Documented processes describe how work is supposed to happen; discovered models describe how it did. The gap is usually large, and it is not made of people breaking rules. It is made of the workarounds, reworks and exception paths that everyone treats as too ordinary to mention.
There is a naming confusion worth clearing up first, because it accounts for most of the questions. Process discovery is not an alternative to process mining. It is one of its three types, and the one that works without a model to start from. The other two need a model: conformance checking compares reality against it, enhancement improves it using the log.
What separates the whole family from data mining is the case identifier. Data mining finds patterns of any shape. Process mining groups events into runs of the same process and looks at the order they happened in, which is what makes the output a process model rather than a correlation.
The honest constraint is the data. Everything here depends on logs that record a case identifier, an activity, and a timestamp, and in many organizations those three things live in different systems with no reliable key between them. Assembling them is usually the majority of the project.
Quick Reference
The types
The three types, and what each needs
All three read an event log. They differ in what else they need and what they hand back, and knowing which one you are doing prevents most of the confusion around the term.
| Type | Takes | Returns, and what it is for |
|---|---|---|
| Discovery | An event log, and nothing else | A process model built from the data with no prior assumptions. The only type that needs no existing model, which is why it gets confused with the whole field. Use it when you do not know what the process looks like. |
| Conformance checking | An event log and a model | The places where reality and the model disagree, in both directions. Use it for compliance, where the model may be a policy or a regulation rather than a diagram. |
| Enhancement | An event log and a model | An improved model, typically annotated from the timestamps with waiting times, throughput, frequencies and bottlenecks. Use it when the model is broadly right and you want to know where the time goes. |
Which one you need depends on whether you already have a model
The practical test is simple. No model, or no confidence in the one you have: discovery. A model you trust and a compliance question: conformance. A model you trust and a performance question: enhancement. Most projects start with discovery because the honest answer to "do you have a current process model" is usually no, or one written four years ago.
They also compose. A common sequence is to discover the real process, compare the discovered model against the documented one to quantify the drift, then enhance the discovered model with timings to find where the delay actually sits. That is all three types on the same log, and it is a better first project than any of them alone.
The data
What your event log has to contain
Nothing works without the log, and the log has minimum requirements. Most failed projects fail here rather than in the analysis.
| Column | What it is | Without it |
|---|---|---|
| Case ID | Which instance this event belongs to: an order number, a claim reference, a patient episode. | You have events but no processes. Nothing can be grouped into a run, so there is no sequence to analyze. This is the column most often missing across system boundaries. |
| Activity | What happened, named consistently. "Approved", "Rejected", "Sent for review". | Discovered models fragment, because the same step recorded under three names appears as three steps. |
| Timestamp | When it happened, at usable granularity. | No ordering, so no process. Date-only timestamps collapse everything within a day and are a common cause of nonsense models. |
| Resource optional | Who or what performed the step. | You lose handover analysis and the social network view, but the core analysis still runs. |
The first discovered model will look like spaghetti, and that is information
A first run on real data typically produces a model with hundreds of paths, which looks like a failure of the tool. It is not. It is the actual variation in the process, which nobody had ever seen represented, and the surprise it produces is often the most valuable output of the whole project.
Filter to the most frequent paths to make it readable, but record what you filtered. A model showing the eighty per cent of cases that follow four paths is useful; the remaining twenty per cent is where the rework, the escalations and the compliance problems live, and discarding it silently turns a finding into a tidy picture of nothing.
Core Features
- Event logs as the input: case ID, activity, timestamp at minimum
- Three types: discovery, conformance checking, enhancement
- Observed rather than reported: what happened, not what people recall
- Every variant visible: including the paths nobody documents
- Timing from the data: waiting time, throughput and bottlenecks come free
- Filtering with a record: what was excluded, stated alongside the model
Worked example
Seven weeks on plumbing, four days on analysis
An illustrative composite. A property and casualty insurer in Zurich, Switzerland, handling about 240,000 motor claims a year. The documented claims process had nine steps and a target of eleven days. Actual average settlement was twenty-six days and nobody could account for the gap.
| Stage | What it showed |
|---|---|
| Assembling the log | Events sat in three systems with no shared key. Building a reliable case ID across them took seven of the project's eleven weeks. The analysis took four days. |
| Discovery | The documented process had nine steps. The discovered model had 1,340 distinct paths, of which 6 covered 71% of claims. The nine-step path as documented was followed by 4% of cases. |
| Conformance | Comparing the discovered model against the documented one found that 31% of claims went through assessment twice. It was not in the documentation because it was not intended. |
| Enhancement | Annotating with timestamps put a median of 9.4 days on a single transition: claim documented, then waiting for a garage estimate. Not a step in the process at all, and the largest single delay in it. |
| What changed | Estimate requests moved to automatic issue at first notification rather than after assessment. The double-assessment loop traced to a routing rule that returned claims above a threshold that had not been updated since 2019. Settlement fell to 17 days over two quarters. |
Seven weeks on plumbing, four days on analysis
That ratio is the honest shape of a process mining project and it is rarely what gets budgeted. The hard part was building a case identifier that held across three systems, not running the algorithms. Anyone planning a first project should assume most of it is data engineering and staff it accordingly.
The finding worth dwelling on is the 9.4-day wait for a garage estimate. It was the biggest delay in the process and it was invisible to every previous review, because it was not a step anyone had modelled — it was a gap between two steps. Interviews cannot surface that; people describe the work they do, not the waiting between. The timestamps had recorded it all along.
When to Use
- The documented process and the real one are suspected to have diverged
- Systems already record case identifiers, activities and timestamps
- The process runs at enough volume for variation to be meaningful
- Previous improvement work relied on interviews and did not hold
- A compliance question needs evidence rather than assurance
- Delay is somewhere in a long process and nobody can say where
When NOT to Use
- The work is not recorded in systems, so there is no log to read
- Case identifiers cannot be reconstructed across the relevant systems
- Timestamps exist only at date granularity in a process measured in hours
- Low volume or highly bespoke work, where every case is its own path
- The cause is already known and the problem is that nothing gets done
- Nobody will act on a finding that contradicts the documented process
The data
How process mining goes wrong
Most process mining projects fail before any mining happens, in the data preparation nobody budgeted for.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| Underestimating the log | A project scoped as analysis that turns out to be months of data engineering | Build a small log for one process end to end before committing. The feasibility question is the case ID. |
| Filtering silently | A clean four-path model presented as the process, with the rework paths quietly removed | State what was filtered and what share it covered. The excluded paths are usually the finding. |
| Inconsistent activity names | One step appears three times under three labels, so the model fragments | Map activity names to a controlled list before analysis, and keep the mapping. |
| Date-only timestamps | A model that shows steps in impossible orders because everything in a day ties | Check granularity first. If the process moves in hours, date-level data cannot describe it. |
| Blaming the people | Deviations treated as non-compliance, so staff stop cooperating and start avoiding the system | Treat deviation as information about the design. Most workarounds exist because the model does not fit. |
| Mining without a question | An impressive model, a demo, and no decision that would have been made differently | Name the decision the analysis will inform before starting. Discovery is not an end in itself. |
| Ignoring the gaps | Attention on the steps, while the largest delay sits in the waiting between them | Look at transitions, not just activities. Waiting is rarely a modelled step and is often the answer. |
Sourced
Evidence, and how to cite it
The three types are van der Aalst's, and they are defined by input and output.
Wil van der Aalst set out discovery, conformance checking and enhancement in his 2011 book, and the same taxonomy appears in the Process Mining Manifesto published that year by the IEEE Task Force on Process Mining. The definitions are precise: discovery takes an event log and produces a model without using any a-priori information; conformance takes an existing model and a log of the same process and compares them in both directions; enhancement extends or improves an existing model using the log, for instance by using timestamps to add bottlenecks, service levels and throughput times.
van der Aalst, W.M.P. (2011) Process Mining: Discovery, Conformance and Enhancement of Business Processes. Berlin: Springer; IEEE Task Force on Process Mining (2011) Process Mining Manifesto, BPM 2011 Workshops, LNBIP 99, pp. 169–194.
Process discovery is a type of process mining, not a rival to it.
The two terms are routinely presented as competing approaches, including by vendors. They are not. Discovery is the first of the three types and is described in the manifesto as the most prominent process mining technique, which is likely why its name became attached to the whole field. The distinction that matters in practice is narrower and more useful: discovery is the only one of the three that needs no existing model, so it is the only one available when you do not have one.
IEEE Task Force on Process Mining (2011), on the positioning of the three types.
The case identifier is what makes it process mining rather than data mining.
An event log is not simply a table of records. It requires that events can be grouped into cases, each case representing one run of the process, and ordered within that case. Without a case identifier there are events but no sequences, and without sequences there is no process to discover. This is a definitional requirement rather than a practical inconvenience, and it is why so much of a process mining project is spent constructing a case identifier that holds across systems that were never designed to share one.
IEEE Task Force on Process Mining (2011), on event logs as the starting point.
A discovered model is a claim about the log, not about the process.
Discovery algorithms differ, and the same log run through different algorithms produces different models: some favor fitting every observed behavior, others favor a simpler model that misses rare paths. There is no single correct answer, only trade-offs between fitting the data, generalizing beyond it, and remaining readable. Two consequences follow. Record which algorithm produced a model and with what settings. And treat anything the model implies about behavior not present in the log as a hypothesis rather than a result.
Standard treatment of discovery algorithm quality criteria; see van der Aalst (2011) on fitness, precision, generalization and simplicity.
How to cite it.
Harvard: van der Aalst, W.M.P. (2011) Process Mining: Discovery, Conformance and Enhancement of Business Processes. Berlin: Springer.
APA: van der Aalst, W. M. P. (2011). Process mining: Discovery, conformance and enhancement of business processes. Springer.
For the principles and challenges, cite the IEEE Task Force on Process Mining (2011), Process Mining Manifesto, LNBIP 99.
Key Strengths
- Observed, not reported: immune to what people remember or prefer to say
- Shows every variant: including paths nobody knew existed
- Finds waiting: the gaps between steps, which interviews never surface
- Quantifies the drift: between the documented process and the real one
- Repeatable: rerun the same analysis to check whether a change held
Key Weaknesses
- Entirely dependent on the log: and building one is most of the work
- Shows what, not why: the explanation still comes from people
- First models are unreadable: and filtering them can hide the finding
- Invites blame: deviation read as non-compliance destroys cooperation
- Blind to unrecorded work: anything done outside a system does not exist
Sequencing
What to run before and after
Process mining tells you what is happening. Deciding what to do about it, and doing it, are separate problems.
Before
Name the decision, and check the log exists
A discovered model with no question attached produces an impressive demo and no change. And feasibility rests entirely on whether a case identifier can be built across the systems involved, which is worth testing on one process first.
During
Read the transitions, not only the steps
The largest delays usually sit in the waiting between activities rather than in the activities themselves, and waiting is never a modelled step. Pair the discovered model with a flow view to see where work queues.
After
Fix something, then rerun the same analysis
The analysis is repeatable, which most improvement evidence is not. Rerunning it on a later log tells you whether the change held, and that is the strongest thing process mining offers.
Common questions
Process mining: quick answers
What is process mining?
A family of techniques that reconstructs how a process actually runs from the event data your systems already record. Rather than interviewing people about how work is done, it reads the timestamps and shows what happened, including the paths nobody mentions because nobody thinks of them as part of the process.
What is the difference between process mining and process discovery?
Discovery is one of the three types of process mining, not a competing method. Discovery takes an event log and produces a model with no prior assumptions. Conformance checking compares an existing model against a log to find where they diverge. Enhancement uses a log to improve an existing model. Only discovery works without a model to start from.
What are the three types of process mining?
Discovery, conformance checking and enhancement. All three consume an event log; they differ in what else they need and what they return. Discovery returns a model. Conformance returns the differences between a model and reality. Enhancement returns an improved model, typically annotated with timings, frequencies and bottlenecks.
What does an event log need to contain?
Three things, minimally. A case identifier saying which instance an event belongs to, such as an order number. An activity name saying what happened. And a timestamp saying when. Without a case ID you cannot group events into runs of the process; without timestamps you cannot order them. Everything else is optional and useful.
What is the difference between process mining and data mining?
Data mining looks for patterns in data of any shape. Process mining looks specifically for the order in which things happen, and returns a process model rather than a correlation or a cluster. The case identifier is what makes the difference: it lets events be grouped into sequences, which is what a process is.
What is conformance checking used for?
Finding where reality departs from the model you thought you were running. That includes compliance work, where the model is a policy or a regulation rather than a diagram, and it can flag steps done out of order, skipped approvals, or activities performed by the wrong role. It needs a model to check against, which is what separates it from discovery.
Why do discovered models look so complicated?
Because real processes are. A first discovery run on a messy log typically produces what practitioners call a spaghetti model, with hundreds of paths. That is a finding rather than a failure: it means the process has far more variation than anyone believed. Filtering to the most frequent paths makes it readable, as long as you record what was filtered out.
How do you cite process mining?
For the field and its three types, cite van der Aalst, W.M.P. (2011) Process Mining: Discovery, Conformance and Enhancement of Business Processes, Springer. For the principles and challenges, cite the IEEE Task Force on Process Mining (2011) Process Mining Manifesto, in BPM 2011 Workshops, LNBIP 99.
Deep Resources
Frameworks related to Process Mining
- Value Stream MappingThe process drawn by walking it, for when there is no usable event data…
- Lean Six SigmaThe improvement cycle a discovered model feeds, once you know where to look…
- Business Process ManagementThe governing discipline process mining supplies evidence to…