As most of you know, in 1990 the Harvard Business Review published a famous essay by Michael Hammer with one of the more aggressive titles in the magazine’s history: Reengineering Work: Don’t Automate, Obliterate. The argument was direct and hard-hitting. Most corporate process work, Hammer wrote, was the product of decades of accreted inefficiency, and applying technology to it was a category error. You don’t speed up a broken process by automating it. You redesign the process around what you would do today, given the technology now available, and you ignore the constraints that produced the old design.
The essay, expanded with James Champy into Reengineering the Corporation in 1993, has become the founding text of Business Process Reengineering.
For a few years in the mid-1990s, BPR was the closest thing the consulting industry had to a religion. Then it overcorrected, produced a backlash, and the energy drained into the quieter, more methodical disciplines that rose to dominance in its wake: Six Sigma, Lean, and Operational Excellence. (Some of those movements were older than BPR.) The original radicalism faded. The underlying logic, though, never went away.
Three decades later, the logic is exactly right, and the toolkit is wrong. Hammer and Champy wrote for a world where you learned what a process looked like by interviewing the people doing it, building a current-state map, and proposing a future-state design. The current-state work was the bottleneck. It took months. It was expensive. It produced an artifact that everyone knew was incomplete, but it was the best available input, and the redesign team worked from it.
That bottleneck is now gone. And the consequence (for how re-engineering is done, who does it, and what it costs) is larger than the AI conversation has caught up with.
What Hammer and Champy got right
The central diagnosis of BPR is fundamentally sound. Hammer’s argument was that most processes are the way they are because of constraints that no longer exist: geographic distance between functions now connected by software, expertise concentrations democratized by tools, and sequencing requirements eliminated by parallel processing. The process, as performed, encodes a set of decisions made for reasons that have expired. If you redesigned the process today, with no commitment to the existing shape, you would not produce what you have. That diagnosis is more true now than it was in 1990, because the gap between the constraints under which most processes were originally designed and the constraints under which they actually operate today is wider.
What’s not worked well is the prescription. Hammer’s prescription was clean-sheet redesign. You assemble a team, map the current state, throw the map in the trash, and design from first principles. The promise was discontinuous improvement: not 10% better but 5x better.
In practice, the prescription produced two failure modes. The first was that the clean-sheet designs, however elegant, ignored too much of what made the current process work. The tacit knowledge, the regulatory constraints, the customer-experience particularities, the operational realities: these survived in the old process for reasons, and the redesigns that ignored them collapsed under contact with reality. Second, the engagements themselves became consulting deliverables more than operational transformations. The future-state design was the product. Its implementation was someone else’s problem. Many BPR programs ended with a beautiful design, a binder, and a process that hadn’t changed.
What’s different now?
Three things are different now in ways that matter for re-engineering.
One: the current state is observable in a way it wasn’t. The premise of BPR was that mapping the current state was expensive, slow, and inherently incomplete, and that this was a fact of life. It is no longer a fact of life. The current state of an operational process, at the resolution required for serious redesign, is now derivable from observation of how the work is actually performed, across systems, across variants, over time. The artifact this produces is not a map. It is a record: current, complete, behavior-based, and able to answer questions the map never could. The work that used to take a six-person team three months now takes a smaller team three weeks, and the answer is better.
Two: you can test the future state before you commit to it. This is the change that is hardest to overstate. In 1990, you knew whether a redesigned process would work by implementing it. The redesign was a hypothesis. The pilot was the test. The cost of being wrong shaped the risk-reward profile of any re-engineering effort. Today, with a faithful representation of the current process and a candidate redesign, you can simulate. You can run the redesign against historical work and ask: what would have happened? Which cases would have moved faster? Which would have stalled? Where would the agents have failed? Where would the human-machine handoffs have broken? The simulation is not perfect, but it is good enough to retire the worst ideas before they become pilots. The cost of being wrong drops by an order of magnitude.
Three: the future-state design includes agents. The 1990s redesigns assumed humans would do the work. The redesigns of the 2010s assumed humans would do the work, with software assisting. The redesigns of the next decade assume that agents will perform significant portions of the work, with humans in the loop where judgment, customer experience, or regulatory accountability demand it. This changes the design space substantially. Steps that were inviolable because humans had to do them (and humans had to be in a specific place, and humans needed certain inputs in a certain order) are now reorganizable, because the agent does not have those constraints. The design space is wider than it has been since Hammer wrote the original essay.
The modern engagement
What does a re-engineering engagement actually look like under these conditions? Let me sketch it, because I think the difference from the 1990s and 2010s versions is more concrete than the framing has suggested.
The discovery phase is shorter and deeper. Instead of three months of interviews and shadowing, you spend three weeks observing the work continuously across the systems where it happens. The output is a process record at fine resolution: every variant, every exception, every system handoff, every workaround. The record is machine-readable so that the analysis can be quantitative. You can answer, with specifics: what percentage of cases follow each variant? What is the cycle-time distribution for each? Which exceptions are recurring patterns versus one-offs? Where do inter-system handoffs consume time?
The redesign phase is bounded by simulation. Once the redesign team produces a candidate future state (usually two or three variants of it), the simulation phase tests each against the recorded historical work. The simulations don’t tell you whether the redesign will work in production; they tell you whether the redesign would have worked on the cases you’ve already seen. That’s a weaker claim than full prediction, but it’s strong enough to kill bad ideas cheaply. Candidates that look elegant but produce worse outcomes in simulation get dropped. Candidates that look conservative but produce surprising improvements get promoted.
The deployment phase is staged by variant. Instead of deploying the redesigned process to the whole population at once, the deployment moves variant by variant, in order of stability and confidence. The high-frequency, high-stability variants move first. The redesign team monitors them against the simulated predictions. Where reality matches simulation, confidence increases. Where it diverges, the redesign is adjusted before the next variant moves. The implementation becomes evidence-driven rather than calendar-driven.
The handoff is to a permanent operating function, not back to the line. This is the structural change Hammer never quite landed. The 1990s BPR engagements ended with a future-state design and a transition back to the line organization, which was supposed to run it. The redesigns that survived were the ones the line could absorb. Many redesigns the line could not absorb died quietly. Modern re-engineering, when it’s done well, doesn’t hand back to the line in the same way. It hands it to an operating function: a small team that owns the observation layer, the agent estate, the policy graph, and the continuous tuning of the process, keeping the redesign current.
What this does to the consulting model
The implications for the consulting industry are real, and not everyone in it has noticed yet.
The traditional consulting engagement was structured around the scarcity of the current-state work. The senior consultants ran the engagement. The junior consultants did the interviews, built the maps, and produced the deliverables. The economics worked because the current-state work was labor-intensive and expensive, and the firm could bill it. The redesign work, the strategic and judgment-intensive part, was a smaller share of the total hours but a larger share of the partner’s attention.
If the current-state work shrinks from three months to three weeks, and from a six-person team to a two-person team enabled by actual “observed” evidence, the engagement’s economics change. The work structure and outputs change, too.
The work that survives this transition is the work that genuinely required judgment in the first place. The work that doesn’t survive is the work that was labor-intensive because the inputs were hard to get. The redesign has not eliminated the consultant. It has, possibly for the first time in this industry’s history, made the consultant’s actual expertise the binding constraint.
For consultants who have real expertise, this is a good moment. For consultants whose value was in marshaling the labor to produce the current-state map, it is a difficult one.
What stays the same
It would be a mistake to imply that everything about re-engineering has changed. A few things haven’t.
The political work is unchanged. Process redesign, then and now, touches headcount, reporting lines, performance metrics, and turf. The hard part of re-engineering has never been the technical work of designing a better process. It has been the organizational work of getting the redesign adopted by the people whose jobs it affects. Continuous observation does not make this easier; if anything, it makes it harder, because the redesign is now backed by evidence that the line organization can’t argue with, which can produce resentment if the conversation isn’t managed well.
The change-management discipline is unchanged. Hammer’s original essays underweighted change management; Champy’s later work corrected this. The correction still holds. A redesign the operating teams don’t believe in will be undermined slowly until it fails. The fact that the redesign was data-driven doesn’t change this. Operating teams have well-developed immune systems against changes imposed from above. The redesigns that survive are the ones where operating teams are brought into the design process, their tacit knowledge is respected, and the implementation accommodates their reality.
The risk of overreach is unchanged. Hammer’s original prescription overreached, and the backlash that followed nearly killed the category. The current moment has the same risk profile. The combination of observation, simulation, and agentic execution makes it tempting to attempt redesigns that are larger than the organization can absorb. The discipline is to use the better toolkit to deliver more reliable transformations, not to attempt more ambitious ones than the organization can survive. Some teams will get this right. Some won’t.
What would Hammer write today?
Of course, I can’t get into their minds, but I guess that if Michael Hammer were writing his 1990 essay today, the title would be the same and the substance would be different. The diagnosis, that most processes encode constraints that have expired, is unchanged. The prescription (don’t automate, redesign) is unchanged. What’s new is the how. The 1990 essay had to argue against the assumption that the current process was a fact of nature. The 2026 essay has to argue against a different assumption: that the limit on redesign is the difficulty of seeing the current state and predicting the future one.
Both of those limits have been substantially relaxed. Re-engineering work has become more tractable. The risk of being wrong has gotten lower. The consultant’s role has shifted from labor provider to judgment provider. The operations function has shifted from project recipient to platform owner.
What hasn’t changed is the underlying logic: don’t automate, obliterate. Or perhaps don’t just automate, reimagine and redesign a process to encapsulate the best of the signal paths. The case for redesign is not weaker than it was in 1990. It is stronger.
The toolkit, with AI at its core, is finally ready. The discipline of using it well is the work of the next decade.