Fix the process before you automate it

Because AI does not judge whether a step is necessary, it just runs it. If a task has three redundant approvals, two people copying data between systems by hand, and a step that only exists because someone left the company in 2019, AI will faithfully execute all of it, just faster and at higher volume than a person ever could. Speed does not fix a bad design. It just means the bad design now produces its output, and its errors, at machine pace.

This is not a new problem AI invented. Harvard Business Review made the same argument in 1990, before automation meant software at all: "It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over." AI changes what is technically possible to automate. It does not change the order of operations: fix the process, then automate what is left.

Ford's accounts payable department is the case Hammer used to make the point, and the numbers are worth knowing because they show the size of the gap between automating and fixing. Ford ran its invoice-matching process with roughly 500 clerks checking purchase orders, receiving documents and invoices against each other by hand across 15 steps, using 5 separate documents, and taking about 5 days per invoice. Mazda ran the equivalent process, handling comparable volume, with about 100 people.

Ford's first instinct was to speed up its existing process with better systems. The fix that actually worked was different: cut the process to 3 steps and 1 document, so a receiving clerk could clear most invoices on the spot without a paper trail to reconcile at all. Headcount dropped from 500 to about 125, a 75 percent reduction, and processing time fell from roughly 5 days to 1. The technology helped. The redesign is what produced the result.

It holds more, not less, because AI raises the stakes on getting the order right. Deloitte's 2026 Global Human Capital Trends research found that organizations that redesign work and workflows around AI, rather than layering AI on top of the process they already had, are about twice as likely to exceed their own AI ROI expectations. The gap is not the model. It is whether anyone touched the process the model was asked to run before turning it on.

A small business feels this at a smaller scale but the same shape: an AI drafting client replies on top of an inbox with no triage, three inboxes for one request type, and no agreed answer for the common question will draft confident, fast, wrong replies. The AI is not the problem. The undesigned process feeding it is.

Pick the one task you are about to hand to AI and write down its real steps, the ones people actually follow, not the version in the onboarding doc. Then ask three questions of every step: does this need to happen at all, does it need a person, and does it need to happen in this order. Cut what fails the first test, simplify what fails the second, and only then decide what AI should run.

This takes an hour for most single-owner tasks, longer for anything that crosses teams or needs sign-off from more than one person. Either way, do it before the AI tool, not after. Automating the fixed version of a process is a project. Automating the broken version and fixing it later is two projects, and the second one is harder because now people trust the automated output less.