Automate or Obliterate

The idea

In the July–August 1990 Harvard Business Review, Michael Hammer argued that companies had spent heavily on computers and seen disappointing returns, because they used technology to mechanise old ways of working. The processes had grown up around the limits of an earlier era: paper forms, slow communication, specialised departments and many checks. Automating them kept every one of those assumptions and simply ran them faster.

His answer was in the title: don't automate, obliterate. Start from the outcome the process exists to deliver, question the rules and steps that built up around it, and redesign the work from scratch using what modern technology makes possible. His principles included organising around outcomes rather than tasks, letting the people who use a process's output perform the process, and capturing information once, at its source.

The same trap is open again with AI. A copilot bolted onto a seven-step approval chain makes each step quicker, but the chain is still seven steps long.

Why it works

Most cost sits between the steps, not in them. Hand-offs, queues, re-keying and reconciliation take most of the elapsed time.

Old processes encode old constraints. A rule such as "finance checks every invoice against the order" made sense when information lived on paper in different buildings. When the data is shared, the rule can go, not just be automated.

Technology's real value is what it makes unnecessary. Shared data, and now AI that reads documents and drafts decisions, let one person do what once needed several departments. That gain only appears if the work is redesigned to use it.

Where it applies

• AI programmes that add assistants to existing workflows and report time saved per task, while end-to-end lead times stay the same.
• Duplicated data across applications, where whole processes exist to copy, check and reconcile the same facts held in several systems.
• Migrations and replatforming, where the default is to rebuild every screen and step the old system had.
• Shared-service and back-office functions built around hand-offs between specialised teams.

How to apply

1. Name the outcome. Describe what the customer or business receives at the end, and measure the current process end to end, not per step.
2. Map why each step exists. For each step, find the rule or constraint behind it, and ask whether it still holds.
3. Redesign from a blank sheet. Ask how the outcome would be delivered if you started today with shared data and current AI, then compare that with the current map.
4. Capture data once. Make one system the source for each fact, so reconciliation and re-keying steps disappear rather than get automated.
5. Automate what remains. Apply AI and automation to the redesigned flow, and judge it on the end-to-end outcome.

Example scenario

An insurer planned to add an AI assistant to claims handling. Each claim passed through intake, document checks, coverage lookup in two policy systems, fraud screening and approval, across four teams. The assistant was meant to summarise documents for each team.

The architects mapped the process and found most of the elapsed time was queues between teams, and that two steps existed only because policy data was held twice. They redesigned the flow: one claims handler owned each straightforward claim end to end, a single policy service replaced the duplicate lookups, and the AI drafted the coverage decision for the handler to confirm. Fraud screening ran in the background and escalated only exceptions. Straightforward claims stopped waiting in four queues.

Questions to ask

When not to use it

• Processes that already work well, where incremental automation is cheaper and less risky than redesign.
• Steps with a regulatory or safety basis, which must be understood and kept even if they look like waste.

How it misleads you