| Dimension | Automate-First Approach | Mine-Then-Redesign Approach |
|---|---|---|
| Starting point | Assumed process from a flowchart or interview | Actual process reconstructed from system event logs |
| What gets automated | Whatever the loudest stakeholder describes | The verified, most common and highest-value paths |
| Exceptions and rework | Discovered after go-live, usually via complaints | Quantified up front and designed for deliberately |
| Typical timeline to value | Fast to launch, slow to actually work | Slightly slower to launch, faster to stabilize |
| Risk profile | High risk of automating a workaround at scale | Lower risk; automation targets are evidence-based |
Why Workflow Redesign Has to Come Before AI Automation
Every automation program eventually collides with the same uncomfortable fact: the process nobody questioned for ten years was never actually the process. It was a description of the process someone wrote down once, updated occasionally, and everyone quietly worked around. When a team hands that description to an AI system or a robotic process automation build and asks it to “just do what we do,” it inherits every workaround, every duplicate approval, and every manual patch that made the paper version bearable to ignore.
This is the central argument for putting process mining ahead of any AI or automation rollout, whether the target is a simple rules-based bot, a predictive model embedded in a decision workflow, or a fully autonomous agent. Process mining tools such as Celonis, UiPath Process Mining, and SAP Signavio ingest event logs from ERP, CRM, ticketing, and case-management systems and reconstruct the process as it actually ran, timestamp by timestamp, deviation by deviation. What comes back rarely resembles the tidy swimlane diagram in the transformation deck. It looks more like a subway map drawn by someone who kept adding stations without ever removing the old ones.
Skipping this discovery step and going straight to automation design is the single most common reason AI rollouts under-deliver. Leaders assume the constraint is technology maturity. In practice, the constraint is almost always that nobody has an accurate, current picture of the process being automated, so the automation locks in inefficiency at a speed and scale no human ever could.
What Process Mining Actually Shows You
Event logs and the “spaghetti” diagram
Process mining works from three fields captured in almost every enterprise system: a case identifier, an activity name, and a timestamp. From those three fields alone, a mining engine can reconstruct every distinct path a case took through a process, how long it dwelled at each step, who or what touched it, and how often it looped back on itself. The first output most teams see is what practitioners call the spaghetti diagram: a dense, overlapping tangle of paths that reveals dozens or hundreds of process variants where the design documentation assumed one or two.
Celonis, UiPath Process Mining, and SAP Signavio in practice
These platforms differ in packaging but share a common workflow: connect to source systems, extract event logs, build a process model, then layer analytics on top to quantify bottlenecks, rework, and compliance deviations. In 2026, the category has moved beyond passive dashboards. Celonis has extended its platform with an orchestration layer and context modelling so that mined insights connect directly to action, and vendors including UiPath and Microsoft are explicitly building bridges between mining findings and automation build queues, so a discovered inefficiency becomes an automation candidate almost immediately. The practical implication for a workflow redesign program is that discovery and redesign are no longer sequential, isolated phases with a long documentation hand-off in between; they can run as a continuous loop.
From tangled reality to redesigned target state
A mined process map typically shows one dominant “happy path” carrying 60-80% of case volume, a handful of secondary variants covering another 15-25%, and a long tail of one-off exceptions. Workflow redesign uses this distribution to decide what gets automated as-is, what gets simplified, and what gets escalated to a human by design rather than by accident.
The Workflow Redesign Methodology: From Mined Map to AI-Ready Process
Process mining produces a map. It does not, by itself, produce a better process. The redesign methodology is the deliberate set of decisions a team makes once the as-is map is in hand, translating discovery into a target-state workflow that an AI system or automation layer can actually execute reliably.
Step 1: Discover the as-is process across every system it touches
Connect the mining engine to every system the process actually crosses, not just the system of record. Procurement, for instance, typically spans an ERP, an e-mail thread, a spreadsheet exception log, and a supplier portal. Mining only the ERP produces a falsely clean picture because the workarounds live in the systems nobody wired up for analysis.
Step 2: Quantify variants, exceptions, and rework loops
For each variant, capture three numbers: how much volume it carries, how long it takes relative to the happy path, and how often it loops back on itself. Rework loops are the highest-value target for redesign because they represent work being done twice, often because an upstream step failed silently the first time.
Step 3: Decide what to eliminate, simplify, or standardize before automating anything
This is the step teams skip under deadline pressure, and it is the one that determines whether the automation succeeds. A step that exists only to route around a legacy system limitation should be eliminated, not automated. A step that exists because three regional teams built three different approval chains for the same policy should be standardized, not preserved in triplicate inside a bot.
Step 4: Redesign the target workflow with AI-specific decision points
Unlike a purely human or purely rules-based process, an AI-augmented workflow needs explicit decision points defining where a model recommends and a human decides, where a model decides and a human audits after the fact, and where full autonomy is acceptable because the downside of an error is small and reversible. These decision points should be drawn directly from the risk and volume data the mining exercise produced, not from a generic maturity framework applied uniformly across every step.
Step 5: Pilot, conformance-check, then scale
Once the redesigned workflow runs live for a narrow scope, use the mining engine again, this time to conformance-check the new process against its own design. Deviations at this stage are early warning signals, not failures, and they should feed back into the redesign before the rollout scales to the rest of the organization.
| Process characteristic | Automate as-is | Redesign first, then automate | Eliminate the step |
|---|---|---|---|
| High volume, low variant count | Strong candidate | Rarely needed | Unlikely |
| High volume, many variants | Risky without redesign | Strong candidate | Sometimes, for the smallest variants |
| Low volume, exists only as a workaround | Not recommended | Possible if genuinely needed | Strong candidate |
| High rework or loop rate | Not recommended | Strong candidate | Consider for the loop-causing step only |
| Regulatory or compliance step | Only with strict conformance checks | Strong candidate for standardization | Not applicable |
Decision Points: Where Human Judgment Still Belongs
A redesigned workflow is not a fully autonomous one. Part of the redesign discipline is deciding, deliberately and in advance, which steps keep a human in the loop, which keep a human on the loop as an auditor, and which can run without a human at all. Getting this wrong in either direction is costly: too much human gatekeeping reproduces the old bottleneck inside the new system, while too little oversight on a high-stakes exception path turns a rare edge case into a public incident.
The mined data itself is the best input for this decision. Steps with low exception rates, low financial exposure per case, and clear historical precedent for the “correct” outcome are reasonable candidates for full automation. Steps with high variance, irreversible consequences, or a documented history of judgment calls that don’t reduce to a rule should keep a human explicitly in the loop, and that boundary should be written into the workflow design, not left to the discretion of whoever built the automation.
| Risk and complexity level | Recommended autonomy level | Governance requirement |
|---|---|---|
| Low risk, low complexity | Full automation, no human touch | Periodic conformance sampling |
| Low risk, high complexity | Automation with human spot-checks | Monthly exception review |
| High risk, low complexity | Automation with mandatory human sign-off | Case-by-case audit trail |
| High risk, high complexity | Human-led, AI-assisted only | Continuous monitoring plus escalation path |
Common mistake
Treating process mining as a one-off discovery exercise that happens before a project kicks off, then never running it again. Processes drift the moment people start working around the new system too, so the redesigned workflow needs the same conformance checking six months later that the original process needed on day one. Teams that mine once and never again end up automating a broken process a second time, just later.
What worked
One mid-market insurer mining its claims intake process found that 22% of cases were being manually re-keyed into a second system because the primary intake form didn’t capture a field the downstream adjuster needed. Rather than automating the re-keying step, the redesign team added the missing field to the source form, eliminating the rework loop entirely before any automation was built. The eventual bot handled a simpler, cleaner process and needed far less exception logic than the original design called for.
Governance: Conformance Checking After the Redesign Ships
Conformance checking compares the intended process model against what the event logs actually show once the redesigned workflow is live. This is the mechanism that catches silent drift before it becomes the next generation of workaround. In an AI-augmented workflow, conformance checking should also monitor the automated or model-driven steps specifically, flagging cases where a system deviates from its expected decision boundary so a human can review the pattern rather than the individual case.
For readers whose primary concern is autonomous, agentic AI systems rather than automation broadly, a companion piece on this site, Why Process Mining is the Essential Pre-requisite for Agentic AI, goes deeper into conformance checking as a real-time guardrail for agents that take autonomous action. The methodology in this article applies more broadly, to any automation or AI investment, agentic or not.
- Happy path biasTeams design for the path documented in the manual, then discover it covers a minority of real cases.
- Shadow systemsSpreadsheets and side channels that exist specifically because the system of record has a gap the redesign should close.
- Silent reworkCases that loop back through an earlier step without anyone flagging a failure, quietly doubling effort.
- Approval sprawlMultiple regional or departmental variants of the same approval chain that redesign should consolidate before automating.
- Post-launch driftUsers adapting around the new automated workflow within weeks, requiring the same discovery discipline applied again.
Industry Scenario: Redesigning a Procurement-to-Pay Workflow
Consider a manufacturer automating its procurement-to-pay cycle. A mining exercise across the ERP, the supplier portal, and email logs reveals that purchase orders above a certain value are supposed to require two approvals, but 40% of cases show a single approver overriding both steps because the second approver is frequently unavailable. Automating the documented two-approval process would have hard-coded a bottleneck the organization had already informally abandoned. The redesign team instead restructures the approval threshold, adds a delegate-approval rule for the unavailability scenario, and only then builds the automated routing. The resulting workflow processes purchase orders faster than either the old manual process or a naive automation of the old documented process would have, because the redesign closed the gap between policy and practice before locking it into software.
Metrics That Prove the Redesign Actually Worked
A redesigned, AI-augmented workflow should be measured against the same event-log data that justified the redesign in the first place, not against a generic satisfaction survey collected months later. Five metrics tend to matter most: cycle time from case creation to closure, the proportion of cases following the intended happy path versus falling into an exception handler, the rework rate measured as the share of cases that loop back through an earlier activity, the rate at which the automated or AI-assisted step escalates to a human, and the cost per case fully loaded with both technology and remaining manual effort. Tracking these five consistently, before and after the redesign, turns an anecdotal “it feels faster” into a defensible business case that survives budget scrutiny.
Leaders should also expect these numbers to move in stages rather than all at once. Cycle time typically improves first, within weeks of go-live, because the obvious bottleneck the mining exercise identified is now gone. Rework rate and exception volume take longer to fully stabilize, often three to six months, as the redesigned decision points absorb edge cases the original mining exercise under-sampled. Organizations that expect an instant, permanent step change and abandon monitoring after the first good month are the ones most likely to be surprised by drift a year later.
- Process mining
- The use of event logs from enterprise systems to reconstruct and analyze how a business process actually executes, rather than how it is documented to execute.
- Conformance checking
- A process mining technique that compares a defined process model against live event data to detect deviations, drift, or non-compliance.
- Happy path
- The most common, ideally shortest sequence of steps a case follows through a process, as distinct from exception paths and rework loops.
- Process variant
- A distinct sequence of activities that a case can follow through a process; most real processes contain dozens or hundreds of variants.
- Rework loop
- A pattern in which a case returns to an earlier step in a process, usually indicating an upstream failure, missing data, or quality issue.
- As-is versus to-be model
- The as-is model reflects the process as it currently runs; the to-be model is the redesigned target state a team designs before automating.
Key Takeaways
- Process mining reconstructs how a workflow actually runs from system event logs, exposing variants and rework the documented process hides.
- Automating a workflow before redesigning it locks in inefficiency at machine speed instead of removing it.
- The redesign methodology moves through discovery, quantification, elimination or simplification, target-state design, and piloting with conformance checks.
- Decision points for human oversight versus automation should be set using mined risk and volume data, not a generic maturity model.
- Conformance checking must continue after go-live because processes and user workarounds drift over time.
- Tools such as Celonis, UiPath Process Mining, and SAP Signavio are converging discovery and automation into a continuous loop rather than separate phases.
- This methodology applies to any AI or automation investment, not only autonomous agentic systems, though agentic deployments raise the stakes further.
FAQs
What is the difference between process mining and process mapping?
Process mapping is typically a manual, workshop-driven exercise that documents how people believe a process works. Process mining uses system event logs to reconstruct how the process actually ran, which usually reveals significant gaps between the two.
Do we need process mining software, or can we redesign workflows without it?
Small, simple, well-understood workflows can sometimes be redesigned through interviews and manual observation. Any process crossing multiple systems, teams, or exception paths benefits substantially from mining tools because human recall of process reality is consistently unreliable at scale.
How long should a process mining discovery phase take before redesign begins?
Most practitioners recommend capturing at least one full business cycle, often 30 days or more, to see seasonal variation, month-end spikes, and the full range of exception handling before drawing conclusions about the target design.
Does workflow redesign apply only to robotic process automation, or also to generative and agentic AI?
It applies to both. A generative AI assistant embedded in a customer service workflow still inherits whatever process gaps exist upstream, and an agentic system taking autonomous action needs an even more precise map, since it will act on incomplete information without pausing to ask.
What is the biggest risk of skipping the redesign step?
The biggest risk is automating a workaround at scale, turning a manageable manual inefficiency into an automated one that runs faster, touches more cases, and is harder to unwind because it is now embedded in software rather than in a person’s daily habits.
How do you decide which process variants to eliminate versus preserve?
Variants that exist because of a system limitation or a missing data field are usually candidates for elimination once that root cause is fixed. Variants that reflect a genuine business need, such as a different regulatory requirement in a specific region, should be preserved and explicitly designed into the target workflow.
Who should own the workflow redesign step: IT, operations, or a dedicated transformation team?
Ownership works best as a joint effort: operations leaders understand why exceptions exist, IT understands system constraints, and a transformation or process-excellence function facilitates the mining analysis and translates findings into a redesign decision the business can commit to.
How does conformance checking differ before and after automation?
Before automation, conformance checking measures how far the human-run process deviates from documented policy. After automation, it measures whether the automated or AI-assisted steps behave within their intended decision boundaries, catching model drift or unexpected edge-case handling early.
For a broader look at why so many AI initiatives stall before reaching production, see why most AI pilots never reach production. Data quality issues frequently surface during the mining phase itself; our companion piece on data readiness for AI covers how to fix them before they derail a redesign. Once a workflow is redesigned, measuring whether the investment paid off is its own discipline, covered in measuring AI ROI. Redesign efforts also tend to surface organizational questions; see our guide to restructuring teams around AI. Getting staff to actually adopt the redesigned, AI-augmented workflow is a separate challenge covered in change management for AI rollouts.
- Kai Waehner, “Process Intelligence Landscape 2026: Mining, Orchestration, and the Agentic AI Shift”
- Kognitos, “Process Mining vs Agentic AI: Why You Need Both (and the Order Matters)”
- KYP.ai, “Best Process Mining Tools Compared 2026: Features, Limitations and How to Choose”
- Celonis, Celosphere 2025 product announcements on Orchestration Engine and Agent Mining
- SAP Signavio Research, “Linking Business Process Logic to Automation and AI”
- Wil van der Aalst, “Process Mining: Data Science in Action”
