Your Process Map Is Fiction — and It's Why Your Automation Failed

Your Process Map Is Fiction — and It's Why Your Automation Failed. There are two versions of every business process. There's the one in the SOP — the tidy swim lane diagram in the shared drive, signed off two years ago. And there's the one that actually happens : the workaround someone added in a spreadsheet, the exception three people handle from memory, the step that officially doesn't exist but that everything depends on. They are never the same document. And most automation projects quietly bet their entire budget on the first one being true . The failure rate is not a secret Robotic process automation has been the default answer to "we do too much manual work" for a decade. The results are, charitably, mixed. The interesting question isn't whether these projects fail. It's why they fail in the same way every time. And the answer is almost never "the software couldn't click the button." It's also, increasingly, not a fixed cost: the same data shows failure rates falling below 20% once AI is layered onto the exception handling — proof this is a design choice, not a law of nature. You automated the map, not the territory RPA is fast to stand up and brittle the moment reality diverges from the script. A bot is a set of hard coded steps against a specific screen layout and a specific input format. It assumes the documented path. So the first time a supplier sends a slightly different template, a field moves, or an approval takes an unexpected detour, the bot doesn't adapt — it breaks, silently, and the work flows back to a human who now also has to notice the bot failed. Here's how the gap opens up, in slow motion: By the time you point an automation tool at the process, the map and the territory have been diverging for a year. Automating the map faithfully reproduces a process that no longer exists. The fix is boring, and it's the whole game The unglamorous truth: you cannot automate a process you have not actually observed. Not the version in the binder — the version in the screen recordings, the system logs, the interviews with the person who really does the job. This is what process mining and process discovery are for, and it's the step teams skip because it feels like overhead. It isn't. It's the difference between automating reality and automating a wish. There's a reason the most credible operations AI work now leads with discovery rather than bots: reconcile what people say with what actually happens, attach the economics (what does this cost, what could we save), and only then decide what's safe to run. When a European grocery operator caught suppliers quietly raising prices while commodity costs fell, the win didn't come from a faster bot — it came from first seeing the real process end to end, then fixing it. [3] My Take, Your Summary The takeaway for anyone about to buy automation Before you evaluate a single tool, ask one question: does this start by showing me how my process actually runs, or does it assume I already know? If it assumes you know, it's betting on the fiction. And the fiction is why the last project failed. I'm Ramar Ranjeet Skanda — product and operations, based in Prague. I collect stories of process maps that turned out to be beautiful lies. Send me yours. Final post in this series: The Software That Logs In, Clicks Around, and Picks Up the Phone Previous Parts: The 80% of Retail Ops That Automation Never Touched.