Automating a broken process makes it faster at being broken

There is a specific kind of failure that happens when you give a broken process more speed. The errors do not disappear. They propagate faster, across more people, with less time to catch them before they cause damage. This is what most automation projects actually deliver, and it is not because the technology was wrong.

The mistake is almost always made before a single line of automation logic is written. Someone identifies a process that is slow or manual, decides to automate it, picks a tool, and builds. What they skip is the step that determines whether any of that effort is worth anything: understanding what the process actually does.

Map what is happening, not what is supposed to be happening

Every process has two versions. There is the version that exists in documentation, in onboarding materials, in the manager's mental model of how things work. And there is the version that people actually follow — the one with the workarounds, the manual corrections, the steps that exist because something upstream broke three years ago and nobody fixed the root cause.

These two versions are rarely the same. Often they are not even close.

If you automate the documented version of a process, you will build something that does not match how the work is actually done. People will route around it. They will find ways to continue doing things manually because the automated version does not handle the edge cases they encounter every day. The system gets ignored, or worse, it runs alongside the manual process and nobody is sure which one is correct.

The process mapping step is not glamorous. It involves sitting with the people who do the work and asking them to walk you through exactly what they do — not what they are supposed to do. It means following a piece of work through every stage and noting where it actually goes, not where the flowchart says it goes. It means asking questions like: what happens when the submission is late? What do you do when the data does not look right? Who do you contact when the system does not have what you need?

The answers to those questions are where the real process lives.

What happens when this step is skipped

A common scenario: a team runs a monthly reporting cycle. The process, on paper, is straightforward — data comes in from regional managers, gets compiled into a report, gets distributed. Someone decides to automate the compilation step. They build a flow that pulls the incoming data and formats it into the standard report template.

What they did not discover, because they did not map the actual process, is that three of the twelve regional managers consistently submit data in a different format. The person who has been doing this manually for two years knows who they are and quietly reformats before compiling. That knowledge is not written down anywhere. The automated flow has no idea. It either fails on those submissions or produces a report with corrupted data, and now the error is no longer caught by a human who recognises it — it is distributed to leadership.

The automation did not cause this problem. The problem already existed. But the automation removed the human checkpoint that was silently compensating for it.

The right order

Process design comes before tool choice. Tool choice comes before build. This is not a slow approach — it is the approach that produces systems that actually work at the end of it.

When you map a process properly, you will find inefficiencies that have nothing to do with technology. Manual steps that exist only because of a system limitation that was resolved two years ago. Duplication that happens because two teams were never told the other was doing the same thing. Approval chains that add two weeks to a timeline because nobody has ever questioned whether the approvals are necessary.

Fix those first. Remove them at the process level. Then automate what remains — the clean, stripped-down version of the process that does only what it needs to do.

That is what gets built correctly. That is what people actually use.