Why 70% of Automation Projects Fail, and What the Survivors Know

By Kirill Stolbushkin

Why 70% of Automation Projects Fail, and What the Survivors Know

In the winter of 1996, a pharmaceutical distribution company called FoxMeyer decided to automate its warehouses. It bought an enterprise system, hired consultants, and drew up a plan to transform the business in eighteen months. FoxMeyer at the time was worth roughly five billion dollars. By the following year, it was bankrupt.

The failure has been dissected for three decades now, in business school case studies and on LinkedIn posts and in the kinds of conference talks where someone reads a PowerPoint slide to you and you pretend you have not already read the slide. The usual diagnosis is unrealistic timelines, or employee sabotage, or bad vendor selection. The usual diagnosis is also, in a subtle way, wrong.

What actually happened at FoxMeyer is what happens at most companies that try to automate. They took a process that was already quietly broken, a process that worked only because a group of experienced humans knew how to work around its broken parts, and they handed that process to a machine. The machine did exactly what it was told. The machine did not know about the workarounds.

McKinsey data suggests that somewhere between 30 and 50 percent of automation initiatives fail to deliver expected results. Some industry analyses put the number closer to 70 percent. The reasons given are almost always the same: poor scope management, lack of executive support, inadequate training. These reasons are not wrong, exactly. They are just the reasons people give when they have not yet asked the real question.

The real question is what the process actually does.

Automation does not fix broken processes. It makes them run faster, at greater scale, with fewer humans around to notice the fire.

Consider a mid-sized manufacturer that spent six months automating invoice processing. The team mapped every step. They identified which steps could be automated and which required human intervention. They built handoffs. They configured exceptions. The resulting system was, in a narrow technical sense, a success. Every automated step worked exactly as specified.

The invoicing process, post-automation, took longer than it had before. Staff now had to wait for systems to sync. They had to troubleshoot automation errors that did not exist in the manual version. They still had to physically move paper. A fourth human being, an adult presumably with a mortgage and opinions about coffee, still had to walk down the hall to find an approver. The process was broken before. The automation preserved the broken parts and sped up the parts that were fine. The net result was slower than doing it by hand.

This is the pattern. Organizations automate the symptoms rather than diagnose the disease. The survivors do something different.

What the survivors do first

The companies that succeed at automation share one quiet habit. Before they write a single line of code or configure a single workflow, they map the process. Not in a meeting. Not in someone's head. On paper, or in software, in a format that forces every step, every handoff, every decision rule to be stated out loud.

This sounds obvious. It is not obvious. Most process mapping efforts collapse under their own weight. The mapping takes so long that the business moves on before the map is finished. A business analyst interviews six people, produces a Visio diagram that runs across three monitors, and by the time anyone signs off, the process has already changed.

There is a reason BPMN 2.0 exists as a standard. It is the language that bridges business intent and technical execution. When BPMN works, the business analyst, the developer, and the executive all read the same diagram and see the same thing. When BPMN is treated as a drawing exercise instead of a specification, it becomes decoration.

The survivors treat the model as the source of truth. The diagram is not a sketch. The diagram is the contract.

The new possibility

For most of BPM's history, getting from "we know what we want" to "it is running in production" required three groups of people who did not quite speak each other's languages. Business analysts wrote requirements. Process modelers drew diagrams. Developers translated diagrams into code. Every handoff was a translation, and every translation lost something.

Vevos was built to collapse that distance. You describe the process in plain English. Vevos generates a professional BPMN model and complete documentation. You review and sign off. Then Conductor Agents, the Architect, the Product Manager, the Builder, the Security Agent, and the Orchestrator, build, validate, and deploy the live workflow. The model is the execution. There is no translation layer because there is no translation step.

The failure rate of automation projects is not a technology problem. It is a structural problem. Too many hands, too many handoffs, too many weeks between "we want this" and "it is running."

The survivors fix the structure. That is the whole trick.

See Vevos in Action → vevos.ai