Automating a bad process just speeds up the error

An auto parts distributor, 210 people. Registering a new supplier took 11 days and passed through six pairs of hands: purchasing filled in a form, tax checked the documents, legal reviewed the contract, finance entered it in the ERP, purchasing double-checked the entry, and leadership approved. They bought an automation for the form.

After the automation, registration took 9 days. The form, which used to take a day to circulate, now arrived in seconds — and sat waiting in the same queue as always. The company had automated the one part of the process that wasn't the problem.

01The idea: don't automate, obliterate #

Michael Hammer published the article that named process reengineering in the July 1990 Harvard Business Review: Reengineering Work: Don't Automate, Obliterate. The argument was blunt and uncomfortable for the technology industry of the day: companies were using computers to run faster the very processes that shouldn't exist in that shape.

Hammer observed that most administrative flows had been designed decades earlier, under constraints that no longer existed — information on paper, no instant communication, manual checking because there was no other way to verify anything. Automating that design preserves rules that only made sense inside the old constraints.

It's fair to record the other side. The reengineering wave of the 1990s did real damage: it became a synonym for headcount cuts and, as Thomas Davenport wrote in 1995 in a self-criticism of the movement he helped create, it ignored the people who ran the processes. The part of Hammer that aged well is the diagnosis, not the brutality of the execution.

02Why AI made this more urgent #

In 1990, automating was expensive and slow, which acted as a natural filter: it was only worth it for important processes, and somebody thought about it first. Today, building an automation takes an afternoon, and an AI agent can take over an entire step in a week. The filter is gone.

That changes the nature of the risk. An automation on top of a bad process doesn't just speed up the error: it freezes it. The odd rule that existed because a director asked for it in 2019 is now encoded, with someone depending on it, and changing it becomes an IT project.

It's worth saying this plainly, even though it's our own business: whoever sells automation and agents has an incentive to skip the step of rethinking the process. It's a terrible deal for both sides. An agent dropped onto a confused flow produces inconsistent results, loses the team's trust in three weeks, and burns the subject inside the company for two years.

03The math of rushed automation #

The scale of that mid-size Brazilian distributor of 210 people (figures in Brazilian reais), with 25 supplier registrations a month. Conservative, explicit premises:

Want to see how this looks inside a real operation? Explore the platform.

The math: each registration consumed about 5.5 hours of human work across the six pairs of hands. Remove the double check and have legal and tax review in parallel, and it drops to about 2.2 hours. That's 3.3 hours × 25 registrations × 12 months = 990 hours a year; at R$ 90 an hour, roughly R$ 89 mil, plus the effect of lead time on supplier negotiations. And only then does automation come in — on a three-step flow, where it's worth far more.

04Where this stalls in practice #

1. Nobody knows why the step exists. The most common answer is 'it's always been this way'. Without the reason, nobody feels authorized to remove it — and automating looks like the safe route.
2. Automation gets bought department by department. Each area automates its own piece, and the flow between areas, where most of the waiting lives, stays untouched.
3. Rethinking a process is political work. Removing a check means someone gives up a control. Automating offends nobody, which is exactly why it gets chosen.
4. There's no record to decide with. Without knowing how much time each step really takes, the choice of what to automate is made on intuition — usually the most visible step, not the most expensive one.

05What data-driven management answers #

Deciding what to remove requires knowing where the time goes. When each step records when it started and when it ended, the conversation stops being about one department's opinion and becomes about the queue that's actually there. It's the same reading behind the map of the seven wastes in the office, and it prevents the classic mistake of optimizing far away from the real bottleneck.

Our position on the order of things has been the same for a long time, and it doesn't change because we sell automation: first make the flow visible, then remove what shouldn't exist, then standardize, and only then automate or bring in an agent. The processes, automations and agents modules in the platform were designed in that sequence — partly because an agent without a defined process has no way of knowing what's correct. It's worth seeing how this applies area by area, and if your case is specific, talking to us before automating usually saves an entire project.

One final warning, in the spirit of the self-criticism the movement itself made in the 1990s: rethinking a process touches the work of real people, who almost always know better than any diagram where the flow breaks. Doing it without them is how reengineering got its bad name.

The question isn't what can be automated. It's what should stop existing before anyone automates it.