In July 1990, Harvard Business Review published an essay by Michael Hammer that named a discipline. The discipline was business process reengineering, and the essay was titled, in a phrase that has held up for thirty-five years, "Reengineering Work: Don't Automate, Obliterate." The thesis was simple and unflattering. Heavy investments in information technology had delivered disappointing results because companies were using technology to mechanise old ways of doing business. They were leaving the existing processes intact and using computers to speed them up. Hammer's line for this was that they were paving the cow paths.
The essay is more correct in 2026 than it was in 1990. The IT wave gave us decades of paved cow paths. The AI wave is on track to do the same.
Ford's accounts payable: a seventy-five percent reduction
The case study Hammer used to make the argument is the canonical illustration. Ford's accounts payable department in North America employed more than five hundred people in the early 1980s. The work was to match purchase orders against receiving documents and supplier invoices, then issue payment if the three matched. Most of the time was spent investigating mismatches. Ford's first instinct was to rationalise the process: tighten the matching, install a computer system, cut headcount by twenty percent. Then someone looked at Mazda. Mazda's equivalent department had five people. After adjusting for size differences, Ford figured its accounts payable function was five times the size it should be.
Ford did not rationalise. Ford reengineered. The new process abolished the invoice step entirely. Purchasing entered the order into a database. Receiving checked the goods against the database and accepted or rejected them. The matching went from fourteen data items to three (part number, unit, supplier code). The check generated automatically. Ford asked its vendors to stop sending invoices. Where the new process landed, Ford achieved a seventy-five percent reduction in headcount, not the twenty percent the conventional rationalisation would have produced. The old rule had been "we pay when we receive the invoice." The new rule was "we pay when we receive the goods." The seventy-five-versus-twenty number is the cleanest argument for reengineering over rationalisation that exists in the management literature.
Why business process reengineering didn't scale in the 1990s
What Hammer's discipline required, and why it did not scale beyond a handful of Fortune 500 case studies in the 1990s, was a combination of expensive things. Discontinuous thinking, which most organisations are not good at. Cross-functional teams, which most organisations are not built for. Expensive consultants, who showed up to facilitate the discontinuity and produce the swim-lane diagrams. And, crucially, an accurate picture of how the work actually happened, which had to be built from interviews and observations because no other way of getting it existed. Producing the picture was the bottleneck. Most reengineering projects either skipped this step (and produced a redesign that did not survive contact with reality) or got stuck in it (and turned into multi-year initiatives that the original sponsors lost interest in).
In 2026, the discovery bottleneck has collapsed
What is different in 2026 is that the bottleneck is gone.
Agents can shadow employees and capture interaction events directly. The discovery work that used to take twelve weeks of interviews can take days of observation, and the resulting picture is more accurate than the interview-based version because it is grounded in what people actually do rather than what they remember doing. The cost of producing the substrate Hammer's discipline always required has collapsed. For the first time, the question Hammer wanted every operator to ask (what would this work look like if you designed it from scratch with the modern toolkit?) can be asked with the data to answer it, and at a price point that does not require a Fortune 500 budget.
The implication is uncomfortable for most of what gets sold today as AI.
Most AI automation today is paving cow paths
Most "AI automation" in the market right now is paving the cow paths. RPA on top of an unchanged workflow. Copilots on top of an unchanged document. Agents on top of an unchanged ticket queue. The agent does the same work the human did, faster, and the underlying process is preserved unchanged. The customer captures some efficiency. The customer does not capture the seventy-five percent that the reengineered version of the work would deliver. The discipline that wins, the one that captures the actual value of the technology, is the one that uses the agent observation to redesign the work first, then automates the redesigned process, not the original.
A reasonable counter to all of this is that reengineering is risky and expensive and most companies do not have the appetite for it. This was true in 1990, when reengineering required armies of consultants and produced uncertain outcomes. It is less true in 2026, when agents can run the discovery phase as a side-effect of being installed and the first redesigned automation can ship in days, not months. The risk-reward of the discontinuous-thinking question shifts when the cost of producing the data needed to answer it collapses. Hammer's own framing on this point was unflattering, and worth quoting: reengineering, he wrote, "cannot be planned meticulously and accomplished in small and cautious steps. It's an all-or-nothing proposition with an uncertain result." That all-or-nothing posture is exactly what the staged, phase-gated, deck-driven engagement model that Big-4 firms run is structurally incapable of producing. The model is built to manage uncertainty by avoiding it; reengineering requires walking into it.
Hammer's seven principles still apply
Hammer's seven principles of reengineering, listed in the original essay, are worth reading in full because each of them is structurally the inverse of how Big-4 engagements still organise themselves. Organise around outcomes, not tasks. Have those who use the output of a process perform the process. Subsume information-processing work into the work that produces the information. Treat geographically dispersed resources as if they were centralised. Link parallel activities instead of integrating their results. Put the decision point where the work is performed. Capture information once and at the source. Each of these is a critique of how a leveraged services firm structures itself. None of them is a critique that the firms can address inside their existing P&L.
If you are spending money on AI to automate the process you have, you are paving cow paths. Hammer's question (what would the work look like if you designed it from scratch with the modern toolkit?) is the right question to ask first. Then automate the answer.