Process mining and traditional process mapping both promise you a picture of how your business actually runs, and they disagree with each other far more often than anyone expects. One builds that picture from what people say happens. The other builds it from what your systems recorded happening. When a team finally puts the two side by side, the gap is rarely a rounding error — it is usually the reason the last automation project underdelivered.
That gap matters commercially. Most improvement programmes are scoped from a workshop diagram, and most workshop diagrams describe the version of the process that everyone agrees on rather than the version that runs on a wet Thursday when someone is on leave. Process mining exists because that discrepancy is expensive, measurable and, until fairly recently, invisible.
This guide is the working comparison. It covers what each method really is, where each one wins outright, what data you need before mining is even possible, what both cost in the UK, the seven factors that decide most real cases, where mining projects stall, and the hybrid pattern that experienced teams settle on. It draws on our business process automation and data analytics practice, and it is written for the person who has to defend the choice in a budget meeting.
If you are still one level up — deciding whether to automate at all, or which process to start with — read how to choose the first process to automate first and come back here once you know what you are investigating.
Table of contents
- What process mining and traditional process mapping actually are
- Where traditional process mapping still earns its place
- Where process mining wins outright
- The event log: what process mining needs before it can start
- Process mining vs traditional process mapping: the seven deciding factors
- What process mining finds that a workshop never will
- What process mining costs in the UK
- Where process mining fails and projects stall
- A five-question test to choose between them
- The hybrid pattern: process mining plus mapping
- A 90-day process mining pilot that produces evidence
- Governance, privacy and the questions process mining raises
- How to measure whether process mining paid for itself
- Frequently asked questions about process mining
- References
What process mining and traditional process mapping actually are
The two get compared as if they were rival products. They are not. One is a facilitated human exercise that produces a model; the other is a data analysis technique that produces evidence. Naming that difference precisely is most of the work, because it explains every trade-off that follows.
Traditional process mapping is a structured conversation
Process mapping puts the people who do the work in a room, walks the process step by step, and records the result as a diagram — usually in BPMN, a swimlane chart or a simple flowchart. The output is a shared model of intent: this is the sequence, these are the decision points, this is who owns each handoff. It captures reasoning, exceptions people remember, and the political reality of who actually signs things off.
Process mining reconstructs the process from system records
Process mining takes the transaction logs your systems already write — an ERP, a CRM, a service desk, a case management tool — and reassembles them into an event log. Each row needs three things: a case identifier, an activity name and a timestamp. From thousands of those rows the algorithm rebuilds the real sequence of events, including every path nobody drew, and reports how often each one ran and how long it took.
The dividing line is evidence versus intent
Every practical difference below follows from that single line. Mapping tells you what the organisation believes it does and why. Process mining tells you what the systems recorded, at what frequency, in what order, with what delay. Neither is the truth on its own. A map without evidence is a hypothesis; an event log without context is a pile of timestamps nobody can interpret.
Neither one is the modern option
The instinct that mapping is old-fashioned and mining is the serious analytical choice is wrong often enough to be costly. Plenty of high-value processes have no usable event log and never will. Plenty of process mining projects produce a beautiful discovery model that nobody can act on because no one asked why the variants exist. Judge the process and the data, not the reputation of the method.
| Factor | Traditional process mapping | Process mining |
|---|---|---|
| Source of truth | Participant recollection | System event logs |
| Time to first output | Days | Weeks, mostly data work |
| Prerequisite | Availability of the right people | A usable event log |
| Captures why | Yes, this is its strength | No, only what and when |
| Captures frequency | Estimated, often badly | Measured exactly |
| Finds unknown variants | Rarely | Reliably, this is its strength |
| Covers offline and manual steps | Yes | No, invisible to the log |
| Repeatable after changes | Needs another workshop | Re-run the query |
| Typical UK cost | £4,000–£15,000 | £25,000–£120,000 first year |
| Best fit | New, manual or cross-organisation processes | High-volume processes inside one system |
Where traditional process mapping still earns its place
There is a class of problem where reaching for an event log is simply the wrong instinct, and an experienced team recognises it quickly. These are the cases where mapping is not the cheap compromise — it is the correct analytical answer.
Processes that leave no digital trace
A great deal of real work happens in email threads, phone calls, spreadsheets on a shared drive and conversations at a desk. None of it writes a timestamped event with a case identifier. If the bottleneck is a manager who mentally triages a shared inbox each morning, no amount of tooling will surface it. A two-hour workshop will, in the first ten minutes.
Processes that do not exist yet
You cannot mine a process you have not run. Designing a new onboarding journey, a new approval route or a service that launches next quarter is a design exercise, and mapping is the right tool for design. The same applies to any process being rebuilt from scratch, where the current-state log describes a system you are about to switch off.
When you need the reasoning, not the sequence
Event logs answer what and when. They are silent on why. Why does finance hold every invoice over a threshold for two days? Because of a fraud incident in 2019 that nobody has revisited. That is the single most valuable sentence in the whole exercise, and it exists only in someone’s head. Mapping is how you extract it.
Cross-organisation and cross-system journeys
When a process spans your systems, a supplier’s portal and a customer’s inbox, no single log covers it. Stitching partial logs together is possible but expensive, and the joins are exactly where the delays hide. Mapping the end-to-end journey first tells you which segment is worth instrumenting, which is a much cheaper question to answer.
Building shared understanding before you spend
There is an organisational benefit that has nothing to do with analysis. Getting four departments to agree on what the process is, in one room, resolves disputes that would otherwise surface halfway through a build. Our change management work consistently finds that this alignment is worth more than the diagram it produces.
Where process mining wins outright
The opposite class is equally clear once you know the signals. These are the situations where a workshop diagram will mislead you, and where the difference between belief and evidence is large enough to change the decision.
High-volume processes where averages hide the problem
Purchase-to-pay, order-to-cash, claims handling, service desk ticket resolution: anything running thousands of times a month has a distribution, not a duration. Process mining shows you the whole distribution — the median case that closes in two days and the nine per cent tail that takes six weeks and consumes most of the cost. A workshop reports the median and forgets the tail exists.
When you suspect the documented process is fiction
If a team has a certified process map and persistent performance complaints, those two facts are usually connected. Conformance checking compares the real log against the intended model and quantifies the divergence. It converts “people work around the system” from a suspicion into a number, with named activities and case counts attached.
Finding rework loops nobody counts
Rework is the most reliably underestimated cost in any operation, because each individual instance feels like a one-off. Process mining counts them. Seeing that a purchase order is modified after approval in nearly a quarter of cases, and that each modification adds days, reframes the entire improvement conversation.
Building the business case for automation
This is the commercial argument that wins budget. An automation proposal built on estimated volumes is a guess; one built on measured frequency, measured cycle time and measured rework is an appraisal. If you are assembling that case, our automation ROI calculator guide shows how to turn these measurements into a defensible five-year number.
Continuous monitoring after the change
A map is a snapshot that starts decaying immediately. An event log query is a living measurement you can re-run monthly to confirm the improvement held. This is the benefit teams underrate at purchase and value most eighteen months later, and it is the one genuine argument for a platform subscription over a one-off analysis.
The event log: what process mining needs before it can start
This is the section that decides whether a project is feasible, and it is the one most often skipped in vendor conversations. Process mining is a data problem wearing a process costume. If the data is not there, nothing else in this article applies.
The three mandatory columns
Every process mining event log needs a case identifier that groups events belonging to one instance, an activity name describing what happened, and a timestamp saying when. That is the minimum. A fourth column naming the resource or user unlocks handover and workload analysis, and any additional attribute — value, region, customer segment — lets you slice the results in ways that make them actionable.
Where the data usually lives
Most usable logs come from a small number of places: ERP tables, CRM activity histories, ITSM ticket audit trails, workflow engine histories and database change logs. Systems built around cases tend to log well. Systems built around documents tend not to. Our data management and analytics team spends most of a typical engagement here, not in the mining tool.
The extraction is the real project
A realistic split on a process mining engagement is seventy per cent data engineering, thirty per cent analysis. Timestamps arrive in different time zones or with only date precision. Case identifiers change when a record is split or merged. Activity names are inconsistent across modules. None of this is exotic, but all of it takes time, and any proposal that treats extraction as a preliminary step is understating the cost.
Data quality decides the answer
Garbage timestamps produce confident, wrong conclusions — a genuinely worse outcome than no analysis at all. Run a quality assessment on the log before you trust a single chart: completeness, granularity, ordering, duplicate events. Our data quality assessment checklist covers the checks that matter, and tools such as Great Expectations automate most of them.
Personal data is almost always in scope
An event log naming who did what and when is personal data under UK GDPR, and it can support inferences about individual productivity. That engages data minimisation and, depending on how the output is used, may require a DPIA. Settle this before extraction, not after the first dashboard alarms someone.
| Question you need answered | Mapping | Mining | Why |
|---|---|---|---|
| What is the intended sequence? | Strong | Weak | Intent is not logged |
| How often does each path run? | Weak | Strong | Counted directly from cases |
| Where does time disappear? | Weak | Strong | Timestamp gaps are exact |
| Why does this control exist? | Strong | None | Reasoning lives with people |
| What happens in email and calls? | Strong | None | No event is written |
| Who hands off to whom? | Partial | Strong | Resource column reveals it |
| How much rework is there? | Weak | Strong | Repeat activities are countable |
| Did last year’s fix hold? | Weak | Strong | Re-run the same query |
Process mining vs traditional process mapping: the seven deciding factors
Most teams do not need a philosophical answer. They need to know which one to buy this quarter. These seven factors settle the overwhelming majority of real cases, roughly in priority order.
Volume decides more than anything else
Below roughly two hundred cases a month, process mining has little to say that a careful workshop will not tell you faster and cheaper. Above a few thousand, the variant distribution becomes the entire story and no human can hold it in their head. Volume is the first filter, and it eliminates a lot of candidate processes immediately.
System containment decides feasibility
A process that lives inside one system with a decent audit trail is straightforward to mine. One that hops between four systems and a shared mailbox requires an integration project before any analysis begins. Ask where the case identifier survives across systems; if the answer is nowhere, process mining is a data programme, not an analysis.
Suspicion of a gap decides the value
If nobody believes there is a discrepancy between the documented and the real process, discovery will confirm what you already know and the return is low. The value of process mining scales with how wrong you expect the current documentation to be — and, uncomfortably, with how much the organisation resists that possibility.
Stability decides the shelf life
Process mining a system that is about to be replaced tells you about software you are switching off. Pointing process mining at a stable, high-volume process that will run in its current form for three more years gives you a baseline you can measure improvements against. Match the analysis lifespan to the process lifespan.
Budget decides the scope, not the method
A twelve thousand pound budget buys a genuinely useful mapping exercise across several processes, or roughly a third of a first mining engagement. Neither is wrong. What fails is a process mining project scoped to a mapping budget, which typically stops after extraction and delivers a dashboard nobody trusts.
Analytical capability decides whether it sticks
A discovery model is not self-explanatory. Somebody has to interpret variants, distinguish legitimate exceptions from failures, and translate findings into changes. Without that person, the platform becomes shelfware within a year. This is the single most common reason process mining fails, and it has nothing to do with the tooling.
The decision you need to make decides everything
Work backwards from the decision. “Should we automate this?” needs measured volumes and cycle times — mine it. “How should this new service work?” needs design — map it. “Why do our customers complain about this journey?” needs both, in that order.
What process mining finds that a workshop never will
It helps to be concrete about process mining output, because “you get visibility” is a sales phrase rather than a deliverable. These are the specific findings that recur across engagements, and each one has a direct commercial consequence.
The long tail of variants
A process everyone describes in six steps typically runs in several hundred distinct variants. Most are harmless one-offs. A handful account for a large share of cost and delay, and those are invisible to any method that samples. Ranking variants by frequency multiplied by duration produces the improvement backlog automatically.
Waiting time, separated from working time
The most useful number process mining produces is the gap between activities. Work that takes eleven minutes of effort routinely takes nine days of elapsed time, and the difference is queueing. Automation aimed at the eleven minutes saves almost nothing. Automation aimed at the queue transforms the process, and only the log tells you which is which.
Rework loops and their true cost
Seeing an activity repeat within the same case is the clearest signal in the whole discipline. Approve, reject, amend, re-approve. Once you can count those loops and attach the elapsed time to them, the argument for fixing the upstream data quality problem writes itself.
Handover patterns and the ping-pong effect
With a resource column, you can see cases bouncing between two teams, each returning it to the other. Nobody involved perceives this as a loop; each individual sees a reasonable handoff. In aggregate it is often the largest single source of delay, and it is a pure coordination problem rather than a technical one.
Conformance gaps that matter for audit
Comparing the real log against the intended model shows exactly where controls are bypassed — approvals granted after the purchase order was raised, segregation of duties breached by a shared account. This is genuinely valuable to internal audit and often justifies the project on its own, independently of any efficiency benefit.
What process mining costs in the UK
Cost is where most process mining conversations become vague, so here are the realistic ranges. These reflect UK mid-market engagements rather than global enterprise programmes, and they assume you are paying for expertise rather than only for software.
Traditional process mapping
A focused mapping exercise for a single process — preparation, two facilitated workshops, validation and a documented model — typically lands between £4,000 and £8,000. A broader programme covering a department’s processes runs £12,000 to £30,000. Internal delivery is cheaper in cash terms but consumes senior operational time, which is rarely free.
The process mining platform
Commercial process mining licences generally start around £25,000 to £50,000 a year for a single process at mid-market scale, rising steeply with the number of processes, cases and connectors. Open-source process mining options remove the licence cost entirely but shift the burden to your own engineering capacity, which is a real trade rather than a saving.
The implementation nobody budgets for
Extraction, transformation, validation and getting a first trustworthy model usually costs £20,000 to £60,000 for a first process, less for each subsequent one on the same system. Budget for this separately. The single most common cause of a stalled project is a business case that funded the licence and assumed the data would be straightforward.
Ongoing capability
Someone has to own the analysis. Whether that is a fractional specialist or part of an analyst’s role, allow £15,000 to £40,000 a year of capacity. Without it the subscription renews unused. Appraise the whole five-year figure using the HM Treasury Green Book approach rather than comparing year-one costs.
| Cost line | Mapping (one process) | Mining (first process) | Mining (each additional) |
|---|---|---|---|
| Software or licence | £0–£1,000 | £25,000–£50,000 | £5,000–£15,000 |
| Data extraction and prep | Not applicable | £20,000–£60,000 | £6,000–£20,000 |
| Facilitation or analysis | £4,000–£8,000 | £10,000–£25,000 | £5,000–£12,000 |
| Internal time consumed | 15–30 person-days | 25–60 person-days | 10–20 person-days |
| Elapsed time to insight | 2–4 weeks | 8–16 weeks | 3–6 weeks |
| Annual running cost | Refresh as needed | £40,000–£90,000 | Incremental |
Where process mining fails and projects stall
The process mining failure modes are consistent enough to be predictable, which means they are also avoidable. Every one of these is a scoping or ownership problem rather than a technology problem.
The event log never materialises
Six months in, the extraction is still incomplete because the source system’s audit table was never designed to be queried at volume, or because the case identifier does not survive a merge. This is the most common failure and it is knowable in week one. Insist on a data feasibility assessment before any licence is signed.
The discovery model is unreadable
An unfiltered model of a complex process is a dense tangle sometimes called a spaghetti diagram, and it persuades nobody. The skill is in filtering to the variants that matter and presenting three findings rather than three hundred. That skill is scarcer than the software, and it is what you are really buying from a partner.
Findings arrive with no owner
An analysis that identifies £400,000 of annual rework achieves nothing if no one is accountable for acting on it. Agree in advance who receives the findings, what mandate they have, and which budget funds the remediation. Without that, process mining becomes an expensive way to generate agreement that something should probably be done.
The organisation reads it as surveillance
Because logs identify individuals, staff can reasonably interpret the exercise as performance monitoring. If that perception takes hold, data quality degrades as people work around the system, and you have made the problem worse. Communicate the scope early, aggregate by team rather than individual where possible, and be explicit about what will not be measured.
It becomes a permanent dashboard nobody opens
The subscription renews, the dashboard exists, and nobody has looked at it since the launch presentation. Prevent this by attaching the analysis to a decision cycle — a quarterly operations review with named owners — rather than treating it as an always-on reporting asset. The GDS guidance on measuring success is a useful discipline here.
A five-question test to choose between them
If you want to reach a defensible answer in ten minutes, answer these five questions honestly. Three or more yes answers point clearly to process mining; two or fewer point to mapping first.
Does the process run more than a thousand times a month?
Below that threshold, a facilitated workshop plus a sample of real cases usually reveals the same problems for a fraction of the cost. Statistical methods need volume to say anything a careful human observer would not.
Does it live substantially inside one or two systems?
If a single case identifier can be traced through most of the journey, extraction is a manageable task. If the process crosses four systems and a mailbox, you are scoping an integration project first and should say so.
Do you genuinely suspect the documentation is wrong?
Be honest about this one. If operations and finance both report symptoms that the documented process cannot explain, the gap is real and worth measuring. If everyone is comfortable, expect confirmation rather than discovery.
Is there a specific decision waiting on the answer?
An automation investment, a restructure, an audit finding, a service redesign. If no decision is pending, the analysis will be interesting and then forgotten. Tie it to something with a date and a budget attached.
Do you have someone to interpret the results?
Not a licence administrator — an analyst who can look at a variant distribution and say which three findings matter. If that person does not exist and you are not hiring or contracting them, buy the mapping exercise this year and revisit.
The hybrid pattern: process mining plus mapping
In practice, mature teams stop treating process mining and mapping as a choice. The two methods answer different questions and the sequence in which you ask them determines how much you spend. This is the pattern that consistently works.
Map first, at low resolution
Spend a day producing a deliberately rough current-state map. You are not trying to be accurate; you are trying to establish scope, identify which systems hold the data, and surface the questions worth measuring. This costs very little and prevents pointing process mining at the wrong process, which is the expensive mistake.
Apply process mining second, to test the map
Extract the log and compare reality against the rough model. The divergences are the findings. Because you arrive with specific hypotheses rather than an open-ended exploration, the analysis is faster and the output is far easier to communicate to a steering group.
Return to the room to explain the anomalies
This is the step teams skip, and it is where most of the value sits. Take the top five divergences back to the people who do the work and ask why. Some will be failures worth fixing. Others will be sensible adaptations to a rule that no longer makes sense, and those are the quickest wins available.
Design the future state on evidence
Now design the target process, with measured volumes, measured cycle times and known exception rates behind every assumption. If automation is the answer, the specification is already written, and choosing between workflow automation, RPA and AI agents becomes a technical decision rather than a guess.
Keep the log query as the control
Once the change ships, the same query becomes your verification that it worked. This is where process mining earns its subscription: not the initial discovery, but the ability to prove three months later that the cycle time actually moved. Our intelligent automation engagements treat this as a required deliverable.
A 90-day process mining pilot that produces evidence
If you have decided to test process mining, scope it as a pilot with a defined end date and a decision at the end of it. An open-ended rollout is how budgets get consumed without a verdict being reached.
Days 1–15: choose the process and prove the data exists
Pick one process, high volume, contained in one system, with a decision waiting on the answer. Then extract a two-week sample of the log and confirm the three mandatory columns are present and coherent. If they are not, stop here — you have saved the entire budget and learned the most important thing.
Days 16–40: build the full extraction
Pull twelve months of history, normalise activity names, resolve time zone issues and validate case counts against a known figure from the source system. Reconciling total case volume against an independent report is the single check that catches most extraction errors before they become conclusions.
Days 41–60: discover, filter and quantify
Produce the process mining discovery model, then immediately filter it. Rank variants by frequency times duration, isolate rework loops, and calculate waiting time between the three or four transitions that dominate. Aim to leave this phase with no more than five findings, each with a number attached.
Days 61–75: validate the findings with the people involved
Take those findings to the operational teams. Expect to discard at least one as a data artefact and to have another completely reinterpreted by someone who knows why the exception exists. This step is what separates a credible report from a provocative chart.
Days 76–90: decide and cost the next step
Convert surviving findings into costed recommendations, and make an explicit call on whether to extend, pause or stop. A pilot that concludes “the data is not good enough yet, here is what to fix first” is a successful pilot, and far cheaper than discovering that in year two.
Governance, privacy and the questions process mining raises
Because process mining operates on records of individual activity, it carries obligations that a mapping workshop does not. Handling them properly is straightforward; handling them late is not.
Establish the lawful basis before extraction
Decide and document why you are processing this data and under what basis. Legitimate interests is commonly appropriate for process improvement, but it requires a balancing assessment, and that assessment should exist in writing before the extraction runs rather than being reconstructed afterwards.
Aggregate by role, not by name
Handover analysis rarely needs individual identities. Pseudonymising the resource column to a team or role preserves almost all analytical value and removes most of the risk and most of the objection. Reserve identifiable analysis for specific, documented audit purposes.
Be clear about automated decisions
If findings will feed a system that makes decisions about people without human involvement, the ICO guidance on automated decision-making applies and additional safeguards are required. Most process improvement work does not reach this threshold, but check rather than assume.
Tell people what you are doing
Announcing the exercise, its scope and its limits costs one email and prevents the surveillance narrative that derails these projects. Say what is being analysed, what is not, and who sees the output. Teams that skip this consistently report worse data quality within weeks.
Treat the log as a security asset
A consolidated event log is a rich description of how your business operates and who has access to what. Hold it to the same standard as the source systems — access control, retention limits and encryption. The NCSC 10 Steps to Cyber Security is the appropriate baseline.
How to measure whether process mining paid for itself
Process mining generates findings easily and benefits rarely, because the gap between the two is organisational. Measuring the right thing keeps that gap visible.
Measure realised change, not insights delivered
The count of findings is a vanity metric. The honest measure is how many findings became changes that shipped, and what those changes did to cycle time, rework rate or cost per case. Track that ratio from the first engagement; if it stays near zero, the problem is ownership rather than analysis.
Re-run the baseline query on a schedule
Because the measurement is a query, re-running it quarterly is nearly free and it is the strongest evidence you will ever have about whether an improvement held. Improvements decay. Detecting that decay early is worth more than the original discovery.
Compare against the counterfactual honestly
Some improvement would have happened anyway. Attributing every gain to the tooling makes the next business case harder to defend when someone checks. Follow the appraisal discipline the National Audit Office applies to public spending and state your assumptions explicitly.
Watch the cost of the capability, not just the licence
Total annual process mining cost is the licence plus the data engineering plus the analyst time. Compare that against realised savings each year at renewal. A capability that costs £70,000 and delivers £90,000 of verified improvement is worth keeping; one that delivers findings nobody actioned is not, whatever the dashboard shows.
Frequently asked questions about process mining
Do we need a commercial platform to start?
No. A first process mining assessment can be done with open-source libraries and a competent analyst, and that is often the right way to test feasibility before committing to a subscription. What you cannot skip is the data engineering, which costs the same either way.
How much history do we need?
Twelve months is a good default, because it captures seasonal variation and gives enough volume for rare variants to appear. Six months works for very high-volume processes. Anything under three months risks mistaking a temporary pattern for a structural one.
Can it work across multiple systems?
Yes, provided a case identifier can be reliably traced across them. That usually requires a mapping table and some engineering. Treat it as a second-phase capability rather than something to attempt on a first process mining project.
Is this the same as robotic process automation?
No. RPA executes work; process mining analyses how work currently flows. They pair well — mining identifies the highest-value candidates and RPA implements them — but they solve different problems and are frequently confused in vendor material.
What if our data quality is poor?
Then fixing the data is the project, and that is a legitimate finding rather than a failure. Poor logging usually indicates gaps in how the underlying systems are configured, and those gaps are causing problems well beyond your inability to analyse them.
Should we map or mine first?
Map first, roughly and cheaply, to establish scope and generate hypotheses. Then mine to test them. Doing it in the other order means paying full extraction cost to discover you analysed the wrong process, which is the most expensive mistake available in this field.
References
OMG Business Process Model and Notation 2.0
HM Treasury, The Green Book: appraisal and evaluation in central government
GDS Service Manual: measuring success
ICO guidance on data minimisation
ICO guidance on data protection impact assessments
ICO guidance on automated decision-making and profiling
NCSC 10 Steps to Cyber Security
DAMA Data Management Body of Knowledge
Great Expectations data quality framework
Microsoft Power Automate getting started
