Between 30 and 50 percent of the robotic process automation projects companies launch fail before they produce a return, and EY's research on the failure points not at the software but at what came before it: teams target the wrong process and skip proper scoping and documentation, then apply a traditional delivery methodology to a problem that needed a different kind of rigor first. Deloitte's Global RPA Survey found the failure compounds at scale: only 3 percent of organizations that start an RPA pilot ever get their automated workforce past that pilot stage. The bots are not the bottleneck. The documentation underneath them is.
A Century of Trying to Write Down "the One Best Way"
This is not a new problem, and the history of how people have tried to solve it tells you what a working answer looks like. In 1921, Frank and Lillian Gilbreth presented the first structured method for documenting process flow, the flow process chart, to the American Society of Mechanical Engineers in a talk titled "Process Charts, First Steps in Finding the One Best Way to Do Work" (Wikipedia). By 1947, ASME had formalized a standard symbol set built on that method, because informal charts drawn differently by every engineer were not precise enough to compare or hand off (Wikipedia). Development of BPMN, Business Process Model and Notation, began in 2000, and the Business Process Management Initiative published BPMN 1.0 in 2004 to give organizations a shared notation for their processes (Trisotech).
The turning point came in January 2011, when BPMN 2.0 added what the standard calls execution semantics, precise enough that a diagram could translate directly into automated software process components rather than just describe the process to a person (Wikipedia). BPMN 2.0.2 was later ratified as the international standard ISO/IEC 19510 (Wikipedia). Read that arc straight through: decades of documentation standards, and the real inflection point wasn't a better looking diagram, it was the moment documentation became precise enough for a machine to execute without a human filling in the gaps.
A flowchart a person can follow is not the same artifact as a specification a machine can run. Most process documentation only ever becomes the first one.
Compliance Documentation Went the Other Direction
Meanwhile, the compliance world moved the opposite way. ISO 9001:2015 eliminated the six mandatory documented procedures that the 2008 version required, replacing them with a single flexible "documented information" requirement under Clause 7.5, letting organizations size their process documentation to their own risk and complexity (NQA). That loosening makes sense for a quality management system audited by a person who can ask a team to walk through whatever the document leaves out. It is a bad model to carry into automation planning, because there is no auditor in the room when a bot hits a branch nobody wrote down. The bot does not ask a follow up question. It either has the exception coded, or the process fails silently, or it fails loudly and someone gets paged.
What Documentation With Execution Semantics Actually Looks Like
If you are scoping a process for automation, hold your documentation to the BPMN 2.0 standard, not the ISO 9001:2015 standard: write it so a machine could run it, not just so an auditor could nod along. In practice that means four things.
- Every decision point as an explicit branch. Not "someone checks if it's approved," but the literal condition and both outcomes named.
- Every exception cataloged before the happy path gets polished any further. Most process write ups over invest in the common case and treat exceptions as a footnote, but exceptions are exactly where the wrong-process, wrong-scoping mistakes EY documented tend to surface.
- Every handoff specified as inputs and outputs, not as a role. Not "it goes to accounting," but which fields, in what format, triggered by what condition.
- The document tested on someone with zero context, watching exactly where they stall. That stall point is where your bot will fail too.
Pick one process on your automation roadmap this week and run that last test before you scope any tooling. Hand the current documentation, if one exists, to someone outside the process and have them execute it literally, step by step, filling in nothing from memory or judgment. Every place they stop and ask what happens if is a branch your documentation is missing, and it is a branch that will show up in production once a bot owns the step instead of a person. Fix the document before you fund the build. That gap is the difference between joining the 3 percent of organizations that scale past pilot and joining the share that fails before the project ever pays back.