Process Mining vs Process Discovery for Retail Operations: How to See How the Work Really Runs Without Event Logs or ERP Connectors

If you want to see how a cross-system retail process like replenishment, accounts payable or promo execution actually runs before you automate it, start with process discovery rather than process mining. Process mining reconstructs a process from the event logs your ERP and other systems of record produce. Process discovery establishes the same truth by watching how the work runs across screens, documents, emails, interviews, handoffs and exceptions. For most retail processes, discovery is the faster and more honest path, because the steps that actually decide the outcome happen in places no event log records.

The practical answer: do not start with a data-engineering project to extract and clean event logs. Map the real process directly from how teams execute it today, get that map approved by the people who own the work, then make the approved map the control surface that runs the work daily. That is the difference between charting a process and running it.

Key Takeaways

• Process mining is powerful, but it can only see the steps your systems of record write down. The decisions that drive a retail process usually happen somewhere else.
• The real cross-system process lives in screens, emails, spreadsheets and handoffs. To understand it, you have to watch how the work actually runs, not just read the log.
• You do not need an event-log project, an ERP connector or months of workshops to map a process. You can discover it directly from how teams execute it today.
• The exceptions are the process. The cases that go sideways consume most of the effort, so map where the handoffs and workarounds cluster.
• Insight only pays off when it becomes action. The goal is not another dashboard, it is an approved map that runs the work and proves it followed the approved path.
• By the end of this guide you will know how to pick a process, map how it really runs, fix it, and turn the approved map into governed daily execution in weeks.

Why event-log process mining misses the retail process you actually run

Process mining promises a living picture of your enterprise: connect the data, mine the event logs your systems already produce, and the process emerges objectively. It is a real capability. It is also a partial one, and the gap matters most in exactly the processes a retail transformation lead cares about.

An event log only sees what a system of record happens to write down. A replenishment decision involves a buyer reading a forecast on one screen, checking supplier availability on another, exchanging a few emails, overriding a number in a spreadsheet, and pinging a colleague on chat to confirm. The ERP records the purchase order. It does not record the upstream judgment calls that produced it. Accounts payable looks clean in the ledger and chaotic in the inbox, where invoices arrive as PDFs, get matched by hand, and stall on exceptions that never touch a structured table.

This is not a corner case. Most of the information a retail process depends on is unstructured and lives outside the systems of record, in documents, emails, spreadsheets and screens. The cross-system process runs largely in that unstructured layer. So when mining sees only the part that gets logged, it produces a confident map of the wrong layer.

Then there is the cost of the data itself. Building clean event logs is the bulk of a mining project, because the logs rarely come from a single table or system. Before you learn anything about your process, most of the project is gone on plumbing. That delay is part of why these efforts lose momentum before they ever change how the work runs.

Why task mining, dashboards and consulting workshops do not close the gap

If event logs miss the desktop layer, task mining offers to record it: capture keystrokes and clicks and complete the picture. But task mining produces another stream of raw exhaust that still needs stitching, interpretation and a dashboard at the end. It stops at observation. You now have two monitoring tools and the same unanswered question: what do we do about it?

That question is where transformations die. The failure is rarely a lack of insight. It is insight that never becomes durable action.

Consulting-led mapping has the opposite problem. Lean and Six Sigma workshops interview teams and document the as-is and to-be process, which is valuable, but slow, expensive, and built on what people say they do rather than what they actually do. The map is stale the day it ships, and it has no connection to the running system, so reality drifts away from the diagram immediately.

The pattern across all three approaches is the same. Each builds a representation of the process and then leaves a gap between the representation and the running work. The bigger that gap, the more the automation built on top of it breaks.

How to discover process truth without event logs, then run it

Here is a discovery method you can follow that needs no data-engineering project, no ERP connector, and no months of workshops. It treats the screens your team already uses as the source of truth.

Step 1: Pick one cross-system process and define the outcome. Choose replenishment for one category, AP for one supplier group, or one promo cycle. Write the outcome in plain terms you can check later: invoices cleared per week, time to resolve an exception, stock-out rate. A scoped process with a measurable outcome is what keeps discovery honest.

Step 2: Map how the work actually runs, across every surface. Capture the real path the way Duvo Clarity does it: from screens, interviews, documents, handoffs and exceptions, with no event log or connector required. The goal is the true path, including the spreadsheet override, the email approval and the workaround nobody documented, not the idealized path on a slide. As you map, write down for each step who does it, which screen or document it happens in, what triggers it, and where it hands off to someone else.

Step 3: Surface the exceptions, because the exceptions are the process. In retail operations the cases that go sideways consume most of the effort. Map where the application switching, the chasing for status and the manual handoffs cluster. Those clusters are where time and money leak, and they are your first automation target.

Step 4: Get the map approved by the people who own the work. Walk the discovered map past the buyers, AP clerks and category leads. When they confirm it, you have an approved process map: agreed allowed actions, evidence requirements, approval gates and exception routing. Be specific about what an agent is allowed to do on its own, what needs a human to approve, and which exceptions should escalate and to whom. This approval is what makes the map safe to run.

Step 5: Fix the process before you automate it. Automating a broken process just makes the breakage faster. Remove the redundant approval, kill the duplicate rekeying, straighten the handoff. Optimize on paper first, while change is cheap.

Step 6: Make the approved map the thing that runs the work. This is the step that closes the gap mining leaves open. The approved map becomes the control surface, an idea called compliance by map: governed agents do the work through the same screens the team already uses, with human approval gates and audit-ready writebacks. The documented process and the enforced process are one artifact, so there is no drift between the diagram and daily reality. You can see the full method on the how it works page.

A phased rollout you can run in weeks, not quarters

Because there is no event-log extraction or integration project to stand up first, this moves at a pace event-log mining cannot match.

Phase 1: Discover and map (weeks one to two). Pick the one process, capture how it actually runs across screens and documents, and surface the exception clusters. You finish this phase with a real as-is map, not a sample of logs still waiting to be cleaned.

Phase 2: Approve and optimize (weeks three to four). Validate the map with the process owners, lock the allowed actions, evidence and approval gates, and remove the obvious waste. You now have an approved, improved process the business agrees with.

Phase 3: Execute under the map (weeks five to six). Turn on governed agents that run the approved steps through the same screens, with humans approving at the gates you defined. Every action writes back with an audit trail and a replayable run history, so you can prove the work followed the approved process.

Phase 4: Expand by exception (week seven onward). Widen coverage to the next category, supplier group or promo type. Each addition reuses the same discovery-to-execution loop, so scaling does not mean a new project each time.

How to measure success

Tie discovery to operational results, not to the existence of a dashboard. Track these by name and watch the direction of travel.

Time to first mapped process. How long it takes to get a validated as-is map. This should be weeks, not the months consumed by event-log extraction or interview cycles. It tells you whether discovery is actually faster than the alternatives.

Share of the real process captured. How much of the unstructured work, the emails, spreadsheets and handoffs, your map covers. Event logs structurally cannot reach this layer, so a high share here is the whole point of discovery.

Exception resolution time. How long it takes to clear the exception cases that dominate effort. Watch for a step-change once those steps run under the approved map, because exceptions are where the cost hides.

Touchless completion rate. The share of cases completed through the governed agents without manual rekeying. Grow it cycle over cycle as confidence in the map builds.

Provable compliance. Whether every automated action carries an audit-ready writeback and replayable history, so adherence to the approved process is something you can demonstrate rather than assume.

How Duvo helps

The honest weakness of process mining is the one it admits to: insight that does not become action. Duvo is built for that gap.

Duvo Clarity discovers process truth the way the work actually happens, from screens, interviews, documents, handoffs and exceptions, with no ERP event log or connector required. Because there is no data-engineering or integration project to stand up first, it goes live in weeks. You see the unstructured part of the process that event-log mining cannot reach, including the exceptions that drive most of your cost.

Then the approved map becomes the control surface. Through compliance by map, governed agents do the work through the same screens your team already uses, with human approval gates and audit-ready writebacks. The map that proves how work really runs is the same map that runs the work, so it never goes stale and there is no drift between the diagram and reality. If you want to weigh this against event-log mining and task mining directly, the comparison page lays it out.

See how discovery becomes daily execution for your replenishment, AP or promo process. Book a demo.

Frequently Asked Questions

What is the difference between process mining and process discovery?

Process mining reconstructs a process from the event logs your systems of record already produce, so it can only show steps those systems write down. Process discovery establishes how the work really runs by observing the actual execution across screens, documents, interviews, handoffs and exceptions. For cross-system retail processes, discovery captures the unstructured work that event logs miss, which is usually where the real decisions and the real costs live.

Can I do process discovery without event logs or an ERP connector?

Yes. That is the core of process discovery without event logs: you map the process directly from how teams execute it, not from data the ERP exported. Duvo Clarity maps process truth from screens, interviews, documents, handoffs and exceptions with no event log or connector required, which is why it goes live in weeks rather than after a long data-engineering project.

Why do so many process mining and automation projects stall before delivering value?

Because they stop at insight. Most of a process mining project goes into extracting and cleaning event logs before anyone learns anything, and even then the output is a dashboard, not action. Transformations tend to fail when the insight never becomes sustained execution, so the deciding factor is whether your method actually runs the work, not just charts it.

How does process intelligence actually turn into daily execution at Duvo?

Through compliance by map. The process map you discover and approve becomes the control surface: governed agents run the work through the same screens your team already uses, with human approval gates and audit-ready writebacks. Because the documented process and the enforced process are the same artifact, the map stays current and you can prove the work followed the approved path. This is what closes the insight-to-action gap that process intelligence tools leave open.

Which retail process should I start with for process mining or discovery?

Start with one high-cost, cross-system process where the work clearly runs across screens, emails and spreadsheets: replenishment for one category, accounts payable for one supplier group, or a single promo cycle. Define the outcome in plain terms first, then discover how it actually runs. A scoped start lets you prove value in weeks before expanding to the next area.