Process mining reconstructs how a process really runs from the event logs in your systems: all it needs is which case each entry belongs to, which activity happened and when. From that it draws the real process — rework, loops and bottlenecks included — rather than the process the organisation believes it has. It is a diagnosis, not a treatment: it only pays off if you can then change the process fast.
What process mining is
Every time somebody registers an invoice, approves a request or closes a ticket, the system writes it down somewhere. Process mining starts from that simple idea: if you sort all those entries by case and by time, what emerges is the process, drawn by itself and without intermediaries.
The discipline began in academia — the IEEE Task Force's Process Mining Manifesto formalised it as a bridge between data science and process management — and moved into the enterprise as ERPs, CRMs and document managers started exposing their traces.
The difference from classic process analysis is one of method. In the classic approach, a consultant interviews ten people, draws what they describe and validates the diagram in a workshop. The result is the process people believe they follow: the happy path, without the exceptions nobody admits to. In mining, the starting point is data, so everything shows up — the shortcuts, the returns, and the case that sat untouched in someone's inbox for forty days.
It is the difference between asking a patient how they feel and taking an X-ray. Both inform; only one is objective.
The three data points that make it possible
Here is the good news for anyone bracing for a huge project: the minimum input is three columns. Everything else is refinement.
| Field | What it is | Example in procurement |
|---|---|---|
| Case ID | The file the entry belongs to. It is what groups steps into a story. | Purchase order number |
| Activity | What happened, with a stable name. If the same step is called three things, the map comes out broken. | "Request created", "Approved by manager", "Invoice matched" |
| Timestamp | When it happened. Durations, waits and bottlenecks all come from here. | 2026-03-14 09:12 |
| Optional | Resource, amount, site, customer type. Not needed to draw the process, but they are what explains why some cases run well and others do not. | Buyer, branch, amount |
The hard work is not the algorithm, it is the preparation: unifying the case identifier when the process crosses three systems that name it three different ways, and agreeing on activity names. Anyone who has tried to reconcile an ERP order with a document manager invoice and a CRM ticket knows exactly what we mean — and it is the same reason integrating your systems ends up being a precondition for almost everything.
The four things it almost always finds
The sector changes and the names change, but the findings repeat with striking regularity:
- Rework. Activities executed two, three or five times on the same case. An invoice that gets corrected, resent and corrected again. Nobody perceives it as a problem because each repetition, on its own, takes two minutes.
- Approval loops. The case bounces between two people or two departments. This usually means the approver receives incomplete information, not that the approver is slow.
- The real bottlenecks. They are almost never where the organisation thinks. The step everyone points at usually takes minutes; the time accumulates in the waits between steps, which have no owner and therefore go unmeasured.
- Variant explosion. A process with one path on the diagram and a hundred and fifty distinct routes in the data. Typically a handful of variants covers 80 % of cases and the rest are exceptions that became normal without anyone deciding anything.
In most administrative processes, effective working time is a tiny fraction of total elapsed time. A file that takes twelve days to close may contain less than an hour of human work. Which means optimising the task — making the person type faster — barely moves the needle: what you have to attack is the waiting. That is exactly the arithmetic behind implementing a low-code BPM with AI.
From "process mining" to "process intelligence": what changed in 2026
If you have seen the term process intelligence everywhere this year, it is not a coincidence. In May 2026, Gartner published its first Magic Quadrant under that name, replacing the process mining platforms quadrant it had published in previous years. When an analyst renames a category, it usually signals a change in what the market expects — and here it signals it quite clearly.
The practical distinction is this:
- Process mining looks backwards: it analyses history and explains how the work was executed.
- Process intelligence adds the present and the future: real-time monitoring, prediction of which cases will go off track and — the decisive part — a connection to automation, so the finding triggers an action instead of a report.
The driver underneath is AI agents arriving in business processes. An agent that decides needs to know how the process is running now, not how it ran last quarter; without that live operational context you are automating blind. We covered the governance side of this in the EU AI Act and process automation.
When it pays off (and when it does not)
Process mining is not a purchase that justifies itself. These are the three typical situations and what to do in each:
| Your situation | Process mining? | Why |
|---|---|---|
| The process crosses several systems and nobody knows where it stalls | Yes, clearly | This is what it was invented for: nobody has the full picture because each system only sees its own slice. |
| The process already runs inside a BPM | First, use what you have | The BPM already logs every step with owner and timestamp. That is your event log, and it is clean at source. |
| The process runs on email, spreadsheets and phone calls | Not yet | There is no trace to mine. A shared mailbox produces no event log. Digitise the flow first; the data then comes for free. |
Put differently: process mining presupposes that your processes already leave a digital trail. When they do not, the mining project quietly turns into a digitisation project with the wrong name — and the wrong budget.
The trap: a diagnosis does not cure
This is where most initiatives stall, and it deserves to be said bluntly: process mining improves no process. It produces knowledge. Knowledge only becomes a result if you can act on the flow, and act fast.
Suppose the analysis concludes that 34 % of supplier invoices go through an unnecessary second approval because the amount threshold was set eight years ago and never revisited. Excellent finding. Now the question is how long it takes to change that threshold:
- If the rule is hard-wired into the ERP: vendor request, quote, development queue, release window. Months.
- If the rule lives in a low-code process: edit the threshold, publish the version, and on Monday cases already take the short path. Hours.
The difference between those two scenarios is not about the analysis tool: it is process architecture. And it explains why so many companies accumulate improvement reports nobody has applied. When the cycle between "discover" and "fix" takes longer than the business takes to change, the analysis is born expired.
So the useful question before buying anything is not "which mining tool should I get?" but "when I find something, how long will it take me to fix it?". If the answer is "months", that is the problem to solve first.
How Dokuflex handles it: the process you run is the process you measure
When a process is modelled and executed in Dokuflex low-code BPM, the event log stops being a data-extraction problem: it is a by-product of execution. Every step is recorded with its case, its activity, its owner and its timestamp — exactly the fields process mining asks for.
- The history is already structured. No unifying identifiers across three systems, no normalising activity names: the workflow defines the activities, so they are named identically in every case.
- Waits are visible by design. With the whole process living on one platform, the time between steps — almost always the real problem — measures itself instead of getting lost between systems.
- Fixing is configuring. Changing an approval threshold, removing a duplicated step or rerouting a case type means editing the process and publishing the new version. The discover → fix → re-measure cycle closes in days, not quarters.
- Documents come in as data. With intelligent document processing, the invoice or delivery note becomes fields on the file from the outset, so the "someone reads the PDF and types it in" step stops being a black hole in the trace.
We do not sell a process mining platform, and it is worth saying so: if your problem is correlating traces across an SAP, a Salesforce and a bespoke legacy system, a specialist tool makes complete sense. What Dokuflex brings is the other half of the equation — a place for the process to live where the finding can be applied the same week.
Book a demo and we will walk through one of your processes with its real timings →
How to start this month without buying anything
You can get a good share of the value with a spreadsheet and some discipline. Five steps:
- Pick a process that hurts and that has data. Supplier onboarding, invoice approval, customer incident, employee onboarding. Something people complain about that leaves a trail in some system.
- Export the three columns. Case, activity, timestamp, for the last six to twelve months. If the process touches two systems, export from both and decide which field acts as the common identifier.
- Measure four figures, not forty. Average end-to-end duration; ratio of waiting time to working time; share of cases with at least one repetition; number of distinct variants. Those four are enough to start a conversation.
- Look at the worst case, not the average. Sort by duration and read the ten slowest files one by one. The average hides the problem; the long tail shows it.
- Test your ability to react. Take the smallest finding and fix it. The goal of this first cycle is not to save money: it is to measure how long you take to change a process. That number decides your entire strategy afterwards.
If at step five you discover that changing a trivial rule takes three weeks and two vendors, you now know what the real project is. Good moment to compare RPA and BPM before deciding where to start.
Frequently asked questions
What is process mining? +
Process mining is a technique that reconstructs how a company's processes actually run from the event logs its systems leave behind (ERP, CRM, document manager, BPM). Instead of drawing the process by asking people, it derives it from data: which steps happened, in what order, when and how long they took. The result is a map of the process as it happens, with every variant, rather than as it is documented.
What data do you need to do process mining? +
Three columns as a minimum: a case identifier (the file, the invoice, the order), the name of the activity that happened, and a timestamp. With those three you can rebuild the flow. Everything else — who did it, amount, site, customer type — is optional, but it is what lets you segment and explain why some cases run smoothly and others do not.
What is the difference between process mining and process intelligence? +
Process mining looks backwards: it analyses historical logs to show how work was executed. Process intelligence is the broader label the market has moved to — Gartner published its first Magic Quadrant for Process Intelligence in May 2026, replacing the one for process mining platforms — and adds real-time analysis, prediction and, decisively, a connection to automation, so that an agent or a workflow can react to what is happening rather than only to what happened.
Is process mining worth it for a mid-sized company? +
It depends on where the process lives. If the flow crosses five different systems and nobody knows where the time goes, a mining tool earns its keep. If the process already runs inside a BPM, that BPM is already logging every step with its owner and timestamp: the sensible move is to exploit that trace before buying a separate platform. And if the process still runs on email and spreadsheets, there is no log to mine — digitise it first.
What does process mining find that you cannot see any other way? +
Four things, almost always: rework (activities repeated on the same case), approval loops (cases bouncing between two people), the real bottlenecks (where waiting time piles up, which is rarely where people assume) and variant explosion (a process that has one path on paper and a hundred and fifty in the data). None of the four shows up in a diagram drawn in a workshop.
Does process mining fix the process? +
No. It diagnoses. It is the X-ray, not the treatment. Value only appears when you can change the process quickly: adjust the approval rule, remove the duplicated step, route the case to the right team. If the finding has to join an ERP development queue and come out nine months later, the report will have expired before it is applied. That is why mining pays off on top of a low-code BPM, where the change is configuration.
How do you start with process mining without buying a platform? +
Pick a process that hurts and that leaves data: supplier onboarding, invoice approval, customer incident. Export the history with the three minimum columns (case, activity, timestamp) from the systems involved, unify the case identifier and measure four figures first: end-to-end duration, waiting time versus working time, share of cases with rework, and number of distinct variants. That already tells you whether a specialist tool is warranted or whether the problem is identified and what is missing is the fix.
Sources
- Process Mining Manifesto — IEEE Task Force on Process Mining: guiding principles and challenges of the discipline.
- Gartner® Magic Quadrant™ for Process Intelligence, 5 May 2026 — first edition of the category, replacing the process mining platforms quadrant (vendor press release).
Make the gap between finding the problem and fixing it days, not quarters
Book 30 minutes: we take one of your real processes, look at the trail it leaves today, where the waiting piles up and what it would take to change the rule that should not be there. No commitment, no product pitch.