Every automation engagement starts with someone producing the process map. It's usually a few years old, it was drawn for an audit or a system implementation, and it shows a clean sequence of boxes with one decision diamond in the middle. Everyone in the room agrees it's roughly right.
Then you sit with the team that runs the process, and inside an hour you've found the spreadsheet. There's always a spreadsheet. It exists because two systems don't talk, or because a rule changed and the form didn't, and it has been load-bearing for four years without appearing on any diagram.
This isn't an argument for more documentation. It's an argument that the gap between the documented process and the real one is not a paperwork problem — it's the specification for your automation, and getting it wrong is the most expensive kind of rework there is.
Why the two processes drift apart
The divergence is not negligence. It's what happens when a stable design meets a changing business, and the people in the middle keep things moving.
Rules change faster than systems do. A new supplier category, a new jurisdiction, a policy tightened after an incident — each one arrives as an instruction to the team long before it arrives as a change to the workflow. The team implements it the only way they can: manually, on the side.
Exceptions get absorbed rather than escalated. When a case doesn't fit, a competent person handles it and moves on. Nobody logs it as an exception, because to them it isn't one — it's Tuesday. The result is that the exception rate is invisible to management and obvious to anyone who sits with the team for a day.
And the map has no maintainer. Process documentation is produced by projects and owned by nobody afterward. It describes the process as designed on the day the project ended, which is the last day it was ever accurate.
Why automation punishes the gap
Here's the asymmetry that catches people out. Humans degrade gracefully against process variance; software does not. A person who receives a malformed case makes a judgment call, fixes it, and the process completes. An automation that receives the same case fails, or worse, succeeds incorrectly and quietly.
So variance that was previously free suddenly has a price. And because the happy path was the only thing scoped, the exception handling shows up as unplanned work in the middle of the build — which is when it's most expensive and least welcome. We've seen teams discover, three sprints in, that the "edge case" they descoped is 28% of volume.
The second-order effect is worse. Automating a process you haven't examined encodes its current inefficiency into software, at which point it becomes much harder to change than it was when it lived in a person's habits. You have paid to make a bad process permanent and fast.
Every automation project has two processes: the one in the deck and the one in production. You are going to automate one of them. The only question is whether you choose deliberately or find out later.
What real discovery looks like
Discovery doesn't mean a six-week mapping exercise with a consultancy and a wall of sticky notes. For a single workflow it's typically one to two weeks, and it's mostly these five things.
- Follow the work item, not the org chart. Trace a case end to end — from how it arrives to when it's genuinely finished, across every team and system it passes through. The interesting failures live in the handoffs between departments, which is exactly what an org-chart-shaped review never sees.
- Sit with the people doing it. Not a workshop, not a survey — actual observation, several cases, several people. Ask what they do when it doesn't work. That single question surfaces more of the real process than any document review.
- Check the map against the event log. Most workflow, ERP, and case systems record timestamps for each step. Pull them and compare the actual path frequencies to the documented flow. The variants nobody mentions show up immediately, along with the rework loops.
- Count the exceptions properly. What share of cases deviate, into how many distinct patterns, and how much of the total handling time do they consume? A workflow with 90% happy path and one common exception is a very different project from one with 60% happy path and twelve.
- Inventory the shadow tools. Spreadsheets, personal inboxes, side databases, WhatsApp threads. Each one marks a place where the official systems failed, and each one is a dependency your automation will inherit whether you plan for it or not.
Fix it before you encode it
Discovery earns its keep when it changes the design, not when it produces a nicer diagram. Three questions, in this order, before anything gets built.
- What can be eliminated? Approvals nobody reads, checks duplicated downstream, reports produced for a person who left. There's usually 10–20% of the steps that exist only because they always have. Deleting a step beats automating it every time.
- What can be standardized? Where three regions do the same thing differently for no defensible reason, converging them turns three automations into one. Where the difference is defensible — regulatory, contractual — that's a genuine branch and should be designed as one.
- What can be fixed upstream? A large share of exceptions are caused by bad inputs: a form that permits free text where it should constrain, a field that's optional and shouldn't be. Fixing the intake often removes the exception class entirely, which is cheaper than teaching software to handle it.
Only what survives those three questions should be automated. And every remaining exception needs an explicit decision: in scope for the automation, routed to a human path by design, or accepted as a known gap with someone owning it. What you cannot afford is for the exception to be discovered by the system in production.
A short worked example
A distributor wanted to automate supplier invoice processing — roughly 4,000 invoices a month, documented as a clean three-way match against purchase order and goods receipt. The business case assumed a 90% straight-through rate.
Two weeks of discovery, including a pull of eight months of event-log data, told a different story: 71% matched cleanly. Of the remaining 29%, nearly two-thirds traced to a single cause — a group of suppliers that invoiced per shipment against POs raised per order, so quantities never lined up. That wasn't an automation problem. It was a purchasing-terms problem, and procurement fixed it for the top twelve suppliers in a month.
The straight-through rate reached 84% before a line of automation was written. The build that followed was scoped against the real distribution of cases, shipped without an emergency exception phase, and landed close to its estimate — because the estimate was based on the process that existed rather than the one on the slide.
The honest takeaway
Nobody wants to spend two weeks looking at a process they're already sure they understand. It feels like delay, and it comes out of the build budget. But it is the cheapest two weeks in the project, because it converts unknown scope into known scope while changing the design is still free.
Automate the process you have, after you've improved it — not the one that was drawn for a project that ended three years ago.