RESEARCH & HISTORICAL NOTE
Reengineering, ERP and Automation: lessons AI transformation should not repeat
Enterprise AI is arriving after three decades of large-scale process redesign, enterprise systems and workflow automation. That history contains a recurring warning: powerful technology creates limited organizational value when it is used mainly to accelerate inherited work.
The old mistake has a new interface
In 1990, Michael Hammer argued that organizations were using information technology to mechanize existing ways of working when the larger opportunity was to redesign the process itself. The provocation was aimed at an era of databases, networks and expert systems, but the underlying problem is immediately recognizable in enterprise AI.
A weak AI programme starts with the existing task inventory and asks where a model can save minutes. A stronger transformation starts with the outcome, reconstructs the flow of evidence and decisions required to produce it, and only then decides what should be performed by people, deterministic software, predictive models, generative systems or agents.
AI can make an obsolete process faster. That is not the same as making the organization better.
1990s: reengineering moved the unit of analysis from task to process
Business process reengineering challenged functional fragmentation. Instead of optimizing each department separately, the process became the design object: an end-to-end sequence organized around an outcome. Hammer’s examples emphasized fewer handoffs, information captured at source, decisions located closer to the work, and technology used to make previously impossible process designs feasible.
The durable insight was not radicalism for its own sake. It was that technology changes the constraints under which work was originally designed. When those constraints disappear, preserving the old structure can preserve unnecessary coordination, queues, controls and information transfers.
Automate the task
Preserve roles, handoffs and approval paths; insert technology into individual steps.
Redesign the flow
Start with the outcome; remove avoidable handoffs and reconstruct information and decision flow.
Redesign the work system
Reallocate cognition, evidence, authority and action across humans and multiple forms of machine intelligence.
ERP solved fragmentation by imposing integration
The enterprise-systems wave attacked another problem: incompatible local systems and fragmented organizational data. ERP integrated transactions and created shared process and information structures across finance, procurement, operations, supply chain, HR and other functions. This integration could produce substantial control and coordination benefits.
But integration also had a cost. An enterprise system is never merely software. Its data structures, workflows, roles, permissions and configuration embody assumptions about how the organization should operate. Implementation therefore became organizational design by another name. Where companies treated ERP as an IT installation, they often discovered the organizational consequences late—during process harmonization, data migration, role redesign, training and cutover.
AI transformation inherits this lesson. A model can be deployed in weeks while the surrounding organization remains unchanged. That speed can disguise the harder work: deciding which source is authoritative, who owns the workflow, which decisions may be delegated, how exceptions are handled, what evidence must be retained and how performance will be measured.
Automation taught enterprises to distinguish flow from judgement
Workflow, BPM and robotic process automation made repeatable digital work increasingly executable. They were strongest where rules, interfaces and exception conditions could be specified. They also exposed a familiar failure mode: automating a brittle process can make brittleness operate at machine speed.
Generative and agentic AI expand the automation frontier because they can interpret unstructured material, synthesize context, generate intermediate work and choose among tools. That does not eliminate the distinction between routine execution and accountable judgement. It makes the boundary more important.
THE TRANSFORMATION STACK
Five layers have to change together
What AI transformation should carry forward
1. Start with outcomes, not tools
Tool-first programmes inherit the vendor’s unit of analysis. Transformation needs the organization’s unit of value. That may be an order fulfilled, a project decision made, a maintenance intervention completed, a customer issue resolved or a management cycle shortened.
2. Treat information architecture as work architecture
ERP demonstrated that shared data structures change coordination. AI intensifies this dependency. Retrieval, recommendations and agents are only as useful as the identity, provenance, freshness, permissions and semantics of the evidence they can access.
3. Remove work before automating it
Every transformation should ask whether a step exists because of an old constraint: information scarcity, slow communication, departmental boundaries, manual reconciliation, limited analytical capacity or the historical need to route expertise through hierarchy. Some steps should be augmented. Some should be automated. Some should disappear.
4. Redesign authority explicitly
Classic reengineering moved decisions closer to the work. AI adds a new question: whether machine systems may participate in or execute those decisions. The answer should vary with consequence, reversibility, uncertainty and the quality of available controls.
Increasing machine authority requires increasing evidence, control, observability and fallback capability.
5. Design exceptions before scale
Happy-path automation is easy to demonstrate. Operational systems are defined by what happens when inputs conflict, permissions fail, a model is uncertain, a tool returns an unexpected result or the real world departs from the process model. Exception design is part of the architecture, not a later governance layer.
6. Measure the system, not the prompt
Task-level speed and output quality matter, but enterprise value appears in system outcomes: cycle time, throughput, quality, decision latency, rework, risk, service, cost and capacity. A faster draft that creates more review work downstream can be locally impressive and globally negative.
What should not be repeated
The AI-era synthesis: redesign without repeating big-bang reengineering
The strongest lesson is not to recreate the most aggressive version of 1990s reengineering. AI systems are probabilistic, rapidly changing and increasingly embedded in live workflows. Organizations need a method that is ambitious about redesign but disciplined about operational evidence.
This changes the transformation pattern. Instead of freezing a target operating model and implementing it through a multi-year programme, organizations can establish a bounded redesign, operate it under real conditions, measure system outcomes and revise the allocation of work and authority as capability changes.
That is where the historical strands converge. Reengineering contributes process-level redesign. ERP contributes integrated enterprise data and controls. Automation contributes executable workflow. AI contributes new cognitive and increasingly agentic capability. The management task is to assemble them into a coherent operating system.
Sources and further reading
- Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review, July–August 1990.
- Thomas H. Davenport, “Putting the Enterprise into the Enterprise System,” Harvard Business Review, 1998.
- World Economic Forum, Organizational Transformation in the Age of AI, 16 March 2026.
- McKinsey & Company, “AI is changing work. Now it has to change the organization”, 5 October 2026.