Do we need a process-mining tool to do this?

Not to start. The first reconstruction of a single process can be done from system exports. Buy tooling when you have proven the process deserves continuous monitoring and the licence is small relative to the value being tracked.

Our data is messy. Is that a blocker?

Only for the ambition, not for the exercise. Missing timestamps and inconsistent activity names reduce precision, but the large deviations — multi-day waits, repeated approvals, abandoned cases — survive messy data.

How is this different from a process-mapping workshop?

A workshop captures how people believe the process runs. Reconstruction from system records captures how it ran. The gap between the two is usually where the cost sits.

Does GDPR affect this?

It can, because step records often include who performed each action. Treat user-level data carefully, aggregate where possible, involve works councils where they exist, and document the purpose before you export anything.

AI Opportunities

Process mining for SMBs: what transfers from the enterprise playbook, and what doesn't

Enterprise process mining assumes clean event logs, an ERP backbone and a data team. Here is how European SMB and mid-market companies get the same visibility without that stack.

Miguel Torres, Founder, Merjora · Published 4 September 2026 · Updated 4 September 2026

In short

Process mining reconstructs how a process really runs by reading timestamped records of each step from your systems. The method transfers to smaller companies; the enterprise tooling usually does not, because it assumes a single ERP, a data warehouse and analysts to maintain it. In a 50-500 person European company the practical route is a scoped reconstruction of two or three commercially important processes — order-to-cash, procure-to-pay, service intake — using exports from the systems you already run, focused on finding a small number of costly deviations rather than continuously monitoring everything.

Key takeaways

The value is in the deviations, not the map. A diagram nobody acts on costs money.
You do not need a data warehouse to reconstruct one process; you need timestamps, a case ID and an activity name.
Mid-market processes fail on handovers between systems, not inside them — that is exactly where exports still see everything.
Scope to processes with a monetary meter attached: cash collected, cash paid, orders fulfilled, cases resolved.

What process mining actually is, stripped of the category language

Every business system leaves a trail: an order created at 09:12, approved at 14:40, invoiced three days later, paid twenty-six days after that. Line those records up by case and you can see the real path a piece of work took — including the loops, the rework and the waiting time that no process document mentions.

That is the whole idea. The enterprise category adds continuous connectors, conformance engines and action automation on top, priced for companies with thousands of employees. The underlying reconstruction is available to anyone who can export three columns from their systems.

Case ID — the order, invoice, ticket or patient the work belongs to
Activity — what happened (created, approved, sent, rejected, paid)
Timestamp — when it happened
Optional but valuable: who did it, and which system it happened in

Where the enterprise playbook breaks in the mid-market

Enterprise assumption	Mid-market reality	Practical adjustment
One ERP holds the process end to end	The process crosses an ERP, a CRM, a shared inbox and two spreadsheets	Reconstruct per system and join on the case ID you already use commercially (order number, invoice number)
A data team maintains connectors	Nobody owns the data pipeline	Start with periodic exports; automate only the processes that earn their pipeline
Continuous monitoring of dozens of processes	Attention for one or two improvements per quarter	Reconstruct two or three processes, act on the top deviations, re-measure later
Deviation from the reference model is the finding	There is often no documented reference model	Use cost and cycle time as the reference: expensive paths are the finding
Licence cost is a rounding error	Licence cost can exceed the value of the improvement	Judge tooling against the value of the specific deviation you intend to fix

Enterprise assumptions versus mid-market reality

The three processes worth reconstructing first

Pick processes where a day of delay has a price. In a European mid-market company that is nearly always cash and fulfilment, not internal admin.

Order-to-cash: quote to order to invoice to payment. Delay shows up directly in working capital.
Procure-to-pay: request to purchase order to receipt to invoice to payment. Deviations show up as duplicate payments, missed early-payment terms and maverick buying.
Service or case intake: enquiry to qualification to resolution. Deviations show up as lost deals and avoidable churn.

What you are looking for in the reconstruction

Resist the urge to admire the diagram. The output that changes anything is a short list of specific, priced deviations with an owner attached.

Rework loops — the same activity repeated on the same case (re-approvals, corrected invoices, re-sent quotes)
Waiting time between steps, particularly when work sits between two systems or two people
Path variants that cost materially more than the common path, and how often they occur
Manual bypasses — cases that skip a control entirely and are corrected later
Cases that never reach an end state and are silently abandoned

Where AI fits, and where it does not

Process reconstruction is arithmetic on timestamps; it needs no AI at all. AI becomes relevant one step later, when you decide what to do about a deviation: reading the unstructured input that caused the rework, classifying and routing intake, extracting fields from documents so a handover stops requiring re-keying, drafting the chase email a person then approves.

This ordering matters commercially. Reconstruction tells you which handover costs the most; AI is one of several ways to fix it, and often not the cheapest. Sometimes the answer is a changed approval threshold or a corrected master-data field.

A realistic sequence for a 50-500 person company

Week 1 — choose one process with a monetary meter and agree the case ID with finance and operations
Week 2 — export the step records from each system that touches it; accept imperfect data and note the gaps
Week 3 — reconstruct paths, quantify the top five deviations in hours and euros, and discard the interesting-but-cheap ones
Week 4 — pick one deviation, define the fix, define how you will know it worked, and set the re-measurement date
Then repeat on the next process rather than expanding the first one

Frequently asked questions

Do we need a process-mining tool to do this?: Not to start. The first reconstruction of a single process can be done from system exports. Buy tooling when you have proven the process deserves continuous monitoring and the licence is small relative to the value being tracked.
Our data is messy. Is that a blocker?: Only for the ambition, not for the exercise. Missing timestamps and inconsistent activity names reduce precision, but the large deviations — multi-day waits, repeated approvals, abandoned cases — survive messy data.
How is this different from a process-mapping workshop?: A workshop captures how people believe the process runs. Reconstruction from system records captures how it ran. The gap between the two is usually where the cost sits.
Does GDPR affect this?: It can, because step records often include who performed each action. Treat user-level data carefully, aggregate where possible, involve works councils where they exist, and document the purpose before you export anything.

Find the process worth fixing first

Merjora maps how your business actually operates, scores each opportunity and quantifies the value range before you commit budget.

Discover your AI opportunities