Process mining or simulation? The past against the future
Process mining reconstructs from system logs how a process actually ran: variants, real lead times, loops, rule violations. It needs an event log with case ID, activity and timestamp. Process simulation instead computes a process that does not exist yet (after an automation, at double the volume, with a different allocation of roles), and needs no log, only volumes, ranges and capacities. Rule of thumb: to know what happened yesterday, mining is right; to know what happens tomorrow once step 3 is automated, simulation is. Together they are strong: mining supplies the inputs a simulation would otherwise have to estimate.
Table of contents
The difference in one sentence
Process mining looks back and measures. Simulation looks forward and computes.
Everything else follows from that: the data requirements, the limits, and the question of which one solves your problem.
What process mining does
From the logs of your systems (ERP, ticket system, workflow engine) the actual flow is reconstructed. Three columns are required:
Case ID | Activity | Timestamp
---------------|-----------------------|------------------
INV-2026-0418 | Invoice recorded | 2026-03-02 09:14
INV-2026-0418 | Sent for approval | 2026-03-02 09:22
INV-2026-0418 | Approved | 2026-03-09 16:40
Out of that comes:
- The real flow, not the documented one. Regularly a surprise.
- Variants: how many different paths do cases actually take? Double-digit counts are normal, triple-digit not rare.
- Real lead times per step and per variant, measured rather than estimated.
- Loops and rework: how often a case goes back.
- Rule deviations: approvals granted after payment; four-eyes checks that were one eye.
Tools in this class include Celonis, SAP Signavio Process Intelligence, UiPath Process Mining, Apromore, Disco and the open-source library PM4Py.
The prerequisite is hard: without a continuous log across system boundaries there is no analysis. Processes running by email, phone or paper leave no trace. In administrative processes that is often exactly where the waiting sits.
What process simulation does
It rebuilds the flow as a model and lets cases run through it artificially: with drawn arrivals, drawn processing durations, limited capacity. What it needs is volumes, ranges, capacities and a calendar. Estimates are legitimate as long as they remain visible as assumptions.
Out of that comes:
- The constraint under variation, computed for the peak day rather than the mean.
- Lead time as a band of P50 and P90, for a state that does not exist yet.
- The migration of the constraint after a measure.
- The value of a change in money, before against after.
Side by side
| Process mining | Process simulation | |
|---|---|---|
| Question | What happened? | What happens if …? |
| Basis | Event log from systems | Assumptions: volumes, ranges, capacities |
| Prerequisite | Continuous logging | None, three numbers per step suffice |
| Strength | Truth about the current state | A statement about a state that does not exist |
| Blind to | anything not logged | anything you do not assume |
| Typical effort | Weeks to months, with IT | Half a day, without IT |
| Typical cost | Platform, data integration, operations | Tool licence, usually far smaller |
| Output | Variants, metrics, deviations | Constraint, band, before/after in money |
The confusion that costs money
"We will do mining first and then we will know what the automation delivers."
No. Mining tells you very precisely how long data entry takes today. What it does not tell you is what happens when entry takes half as long tomorrow. Because then the full volume hits the next step, which is throttled today, and the constraint moves. That knock-on effect is in no log, because it has not happened yet.
Some mining platforms now offer simulation components. Ask the same two questions there as of any other tool: does it represent queues in front of busy steps, or does it sum durations along paths? And does the result arrive as a band or as a single number?
The reverse holds too: a simulation claiming to know the current state exactly is overreaching. It knows the assumptions you entered. The cross-check with Little's Law (work in progress ÷ daily throughput against computed lead time) is therefore mandatory, not optional.
How the two work together
The strongest combination is unspectacular: mining supplies the inputs a simulation would otherwise have to estimate.
| Simulation input | From mining |
|---|---|
| Arrival volume and peak factor | Timestamp of the first activity per case |
| Processing duration as a range | Differences between start and end events, as a distribution |
| Routing shares | Frequency of variants |
| Loops and rework | Return jumps in the log |
| Abort rate | Cases without an end event |
Having both replaces the weakest part of a simulation, the estimated inputs, with measured ones. Having only one means knowing which question you cannot answer with it.
The decision
Choose process mining when:
- a continuous event log exists or can be created at acceptable effort,
- nobody knows how the process actually runs,
- compliance, variants or rework is the question,
- you want to measure continuously rather than decide once.
Choose simulation when:
- you want to evaluate a change before it happens,
- the process runs outside systems (email, phone, paper),
- the decision is being made this month,
- you need a number in money that somebody will sign.
Both, when you have a log and still want to compute forward. That is the normal case in larger organisations, and the sequence is: measure first, then compute.
Frequently asked
Do I need an event log for a process simulation?
No. Simulation computes assumptions, not logs. What it needs is volumes, processing durations as ranges and capacities per step. Estimates are legitimate as long as they stay visible as assumptions. An event log helps because it replaces those inputs with measured values, but it is not a prerequisite.
Can process mining answer what-if questions?
Only up to a point. A log contains what happened, not what would happen. The central effect of a measure, namely that the constraint afterwards moves to another step which then takes the full volume, has not happened yet and therefore appears in no log. Some platforms offer simulation components; check there whether queues are represented and whether the result comes as a range.
Which is cheaper?
Usually simulation, and often by orders of magnitude. Mining costs platform, data integration, privacy review and ongoing operation, and rollout takes weeks to months. A simulation for a scoped process costs half a day of work and needs no IT. The comparison is unfair, though: the two deliver different things.
Our process runs mostly by email. What helps?
Simulation. A process without continuous logging leaves no usable event log, and waiting time inside inboxes never appears there anyway. For a simulation model, what the participants know is enough: how many cases arrive, how long handling takes and how much capacity exists.
Should we introduce mining first and simulate afterwards?
Only if the mining rollout is planned anyway. It is not a prerequisite for simulation, and a decision due this month does not wait for a project that takes six months. Conversely, the combination makes sense once the log exists: then measured values replace estimated inputs.
Run the numbers on your own process
FlowVisual turns the figures in this article into a model that runs, with your volumes, your capacities, your range.
Guide: seven steps to the number- Comparison
Digital twin or simulation? The difference is the wire
A digital twin is a simulation model with a data connection. That connection is the entire difference. It turns an afternoon into a project with an operations budget.
Read - Comparison
Process mapping or process simulation? What each one can do
A process map ends half the misunderstandings in a workshop. The other half starts with the first numeric question, and there no diagram helps, whatever the notation.
Read - Comparison
Process improvement software: seven categories, one misunderstanding
“Process improvement software” is not a product but seven product categories with seven different purposes. Buy the wrong one and you end up automating a step that was never the constraint.
Read