Your Process Map Is Fiction
(04)
Overview
Every transformation project starts with a process map. Most of them describe work that doesn't actually happen, and the gap between the map and reality is where the customer-value question gets buried, and where AI ROI quietly dies.
Year
2026
Industry
Operating Model / GenAI

Challenge
Pull any process map off any operations team's wall. Boxes, arrows, swim lanes. Clean. Linear. It shows the work flowing through in a tidy sequence: case opens, document arrives, system pulls data, analyst reviews, approver signs off, case closes. Six steps. The map looks like a process behaving well. Now sit next to the analyst doing the work for a day. What you'll see does not match the map. The system doesn't pull half the data because the upstream feed broke six months ago and nobody fixed it, so the analyst keys it in by hand from a PDF that arrives by email. The "approver sign-off" step has three sub-approvers in reality, one of whom is permanently on holiday and routes around through a Slack channel. Two of the six "steps" are actually one step the team merged when a system migration two years ago made the original split pointless. There are at least four exceptions the map doesn't show, and the team handles all four routinely. The map describes the process as it was designed, or as the team thinks it should run, or as the auditor needs it to look. It does not describe the process that is actually happening. And it is on this map, this fiction, that almost every AI pilot in operations gets scoped. This is the quietest, most expensive failure in enterprise AI right now. You build an AI agent to automate Step 3. The agent works perfectly. The real process never had Step 3, or had Step 3 plus three workarounds you didn't know about, or stopped doing Step 3 entirely back in 2023. The agent ships. The handle time doesn't move. Nobody can figure out why. It is not the model's fault. The deeper diagnosis comes from Lean. Any process has two kinds of work: steps that the customer — the one paying for the outcome, would consider value-add, and steps that exist only for the business's convenience. The Lean classification of everything else is captured in the TIMWOOD list: transport, inventory, motion, waiting, overproduction, overprocessing, defects. All of it is waste. In a well-designed process, that waste is small. In most operations processes that have evolved over time without a real redesign, it is the majority of the work, sometimes 70-80% of total handle time. The polished process map almost never tells you which steps are which. It treats every step as if it equally belongs there. So when you scope an AI pilot against the map, you cannot tell whether you are automating a value-add step (worth doing), or a waste step (worth eliminating, not accelerating). And accelerating waste is the single most common AI outcome in operations: a faster version of work that should not have been happening in the first place.
Impact
Here's what this looks like in practice. Take a process every investment bank runs: trade exception handling. A trade fails to settle, an exception is raised, a team investigates the break, identifies the cause, takes corrective action, and closes the exception. The map shows six tidy steps. Sit with the team and you see something different. Roughly: The exception arrives in a queue, but the analyst can't act on it until they've pulled trade details from three different systems, manually, because the systems were supposed to be integrated and never were. That's transport and motion: waste. They wait for confirmation data from the counterparty. Sometimes hours, sometimes a day. That's waiting: waste. They route the case to a subject matter expert for tricky breaks, who batches them and reviews twice a day. More waiting. About 20% of cases require rework because the initial categorization was wrong. Defects: waste. A senior reviewer signs off on every case over a value threshold, even though 95% of them are straightforward. Overprocessing: waste. The actual value-add work, diagnosing the cause and resolving the break — is maybe 15 minutes of a case that takes a day-and-a-half to close. Now along comes the AI pilot. It points an agent at exception triage — the categorization step at the front of the process. The agent works. Categorization gets faster and more accurate. Eight months later, the team reports that average time-to-close has barely moved. Of course it hasn't. The categorization step was 20 minutes out of a 36-hour cycle. The real cycle time lives in the system lookups, the counterparty waiting, the batched SME reviews, and the unnecessary senior sign-offs, all the steps the map labels as fine, and all the steps the AI didn't touch. The customer of the process, the firm's capital, the regulator, the counterparty relationship — never noticed a thing. The fix is older than AI, and it is not glamorous. Before you scope a single pilot, watch the work. Sit next to the people doing it. Not for an hour, for a day, ideally two. Note every time the analyst does something that isn't on the map. Note every email, side-channel chat, manual lookup, exception, and workaround. Then walk the process again with the TIMWOOD list in front of you and label each step: value-add, business-add, or waste. What you'll end up with is the real process map — usually two or three times more complex than the official one, with the bottlenecks and rework loops finally visible, and with most of the cycle time concentrated in steps the original designers never acknowledged. It will look messy because the work is messy. That mess is the operating model. The polished map on the wall is the marketing version. Then, and only then, you scope the AI. And here's what changes: the agent is no longer pointed at the cleanest step on the official map. It is pointed at the actual bottleneck, or — better — at the work that gets eliminated entirely once the waste is removed, leaving the AI to accelerate only the value-add that remains. There is a reason the official maps stay clean. They exist to satisfy an audience — an auditor, a regulator, a steering committee, a control framework. They describe the process the organization needs to be seen running. They are not designed to describe what actually happens, and the team maintaining them has often given up trying to keep them current, because the moment they update them to reflect reality, the reality is non-compliant and the conversation becomes uncomfortable. So the fiction persists. And every transformation, including every AI pilot, gets scoped against it. And every pilot then mysteriously underdelivers, and the post-mortem blames the model, or the data, or the change management — never the map. The work to fix this is observational, patient, and slightly uncomfortable. You are documenting a version of the process the organization has not officially acknowledged exists. You will sometimes find that the workaround is the actual control — that the unofficial Slack channel is what stops a bad trade from settling, not the official sign-off step. You will find that the team you are sitting with knows their process far better than the map suggests, and that they have been quietly making it work despite the documentation, not because of it. That is the operating model. The AI goes there, or it goes nowhere. The next time someone hands you a process map and asks where AI can help, the right answer is: I don't know yet, and neither do you. Let me sit with the team for two days, with the TIMWOOD list in hand. Then we'll talk. It does not photograph well in a slide deck. But it is the difference between a pilot that moves the number and a pilot that politely fails after six months. And it is the work that most organizations skip — which is exactly why most pilots stall.