---
title: "Reengineering Work: Don't Automate, Obliterate"
type: source
tags: [bpr, reengineering, hammer, foundational, seminal]
authors: [Hammer, Michael]
year: 1990
venue: "Harvard Business Review 68(4), July-August 1990, pp. 104-112 (Reprint 90406)"
kind: article
raw_path: "raw/Process Frameworks & BPM/1990-hammer-reengineering-work-dont-automate-obliterate.pdf"
external_url: "https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate"
status: ingested
sources: []
key_claims:
  - "Coins reengineering as a discipline. The title slogan 'Don't Automate, Obliterate' is a direct rejection of using IT to mechanise existing processes: 'Instead of embedding outdated processes in silicon and software, we should obliterate them and start over' (p. 2)."
  - "Heavy IT investments have delivered disappointing results because companies 'use technology to mechanize old ways of doing business' rather than to enable new ones (p. 2). IT is an enabler of redesign, not a substitute for it."
  - "Reengineering is explicitly anti-incremental: 'an all-or-nothing proposition with an uncertain result' (p. 2). It rejects the cautious, step-wise posture of process rationalisation, automation, and (implicitly) TQM-style continuous improvement."
  - "Lists seven principles of reengineering (p. 5-8): (1) organize around outcomes, not tasks; (2) have those who use the output of the process perform the process; (3) subsume information-processing work into the real work that produces the information; (4) treat geographically dispersed resources as though they were centralized; (5) link parallel activities instead of integrating their results; (6) put the decision point where the work is performed, and build control into the process; (7) capture information once and at the source."
  - "Ford accounts payable case (p. 3): a benchmark against Mazda's 5-person AP department reframed Ford's target from a 20% headcount cut to a 75% reduction; the redesigned 'invoiceless processing' matches three data items rather than fourteen and eliminates invoices entirely."
  - "Mutual Benefit Life case (p. 3-4): insurance application processing collapsed from a 30-step, 5-department, 19-person sequential process (5-25 day turnaround, 17 minutes of actual work in 22 days of elapsed time) to a single 'case manager' role supported by expert systems; 60% productivity improvement, applications now in 4 hours to 2-5 days, 100 field positions eliminated."
  - "Argues that existing process structures are obsolete artifacts of the Industrial Revolution and the postwar control regime, designed for 'information poverty' and unliterate workforces (p. 4, 6); they survive only because 'we have institutionalized the ad hoc and enshrined the temporary' (p. 6)."
  - "Identifies executive leadership with real vision as the necessary condition: reengineering 'is confusing and disruptive and affects everything people have grown accustomed to' and only sustained top-management commitment can outlast 'company cynics' (p. 8)."
created: 2026-04-22
updated: 2026-04-27
---

# Hammer 1990 — Reengineering Work: Don't Automate, Obliterate

Seminal *Harvard Business Review* article (July-August 1990, Reprint 90406) that named **Business Process Reengineering** as a discipline. Hammer, then president of Hammer and Company and writing in association with the Index Group, argues that U.S. firms have squandered a decade of IT investment by automating obsolete processes instead of redesigning them. The piece is short (8 reprint pages), prescriptive in tone, and built around two case narratives (Ford accounts payable, Mutual Benefit Life) and a list of seven design principles. It is the direct conceptual predecessor of [[sources/1993-hammer-champy-reengineering-the-corporation]] and the canonical primary source for the BPR posture analysed in [[syntheses/bpm-phases-and-bpr-legacy]].

## Core argument

Hammer's thesis has three moves:

1. **Diagnosis.** Despite "a decade or more of restructuring and downsizing", U.S. companies remain unprepared for the 1990s competitive environment of rapid product cycles and customer-centric service (p. 2). "Process rationalization and automation" have failed because they preserve the underlying work design.
2. **Reframing.** Companies have used IT to "mechanize old ways of doing business... pav[ing] the cow paths" (p. 2). Most existing job designs, work flows, and control mechanisms predate the computer and were built for "information poverty" (p. 6). They are not optimisable; they must be replaced.
3. **Prescription.** "Reengineer" the business: "use the power of modern information technology to radically redesign our business processes in order to achieve dramatic improvements in their performance" (p. 2). Reengineering "cannot be planned meticulously and accomplished in small and cautious steps. It's an all-or-nothing proposition with an uncertain result" (p. 2).

The slogan "**Don't automate, obliterate**" condenses moves 2 and 3: the existing process is the problem, not the inefficiency within it.

## Principles of reengineering (p. 5-8)

Hammer enumerates seven principles distilled from companies that had already reengineered successfully:

1. **Organize around outcomes, not tasks** — one person (or team) performs all steps in a process; the job is designed around an objective or outcome rather than a single specialised task. Mutual Benefit Life's case manager is "the quintessential example".
2. **Have those who use the output of the process perform the process** — eliminate handoffs to specialised internal "service" departments by giving consumers of a process the tools to execute it themselves (e.g., operating units issuing their own purchase orders against approved-vendor databases).
3. **Subsume information-processing work into the real work that produces the information** — units that *create* information should also *process* it, rather than passing it to a downstream processing department. Ford's redesigned receiving function processes goods-receipt information directly instead of forwarding it to accounts payable.
4. **Treat geographically dispersed resources as though they were centralized** — databases, networks, and standardised processing dissolve the centralisation/decentralisation trade-off. Hewlett-Packard's 50+ purchasing units share a vendor database while preserving local responsiveness.
5. **Link parallel activities instead of integrating their results** — coordinate parallel functions while they are in process (via shared databases, communications networks, teleconferencing) rather than integrating their outputs at the end. Avoids the late, costly integration phase typical of product development.
6. **Put the decision point where the work is performed, and build control into the process** — the workers doing the work should make the decisions; the process itself should embed controls. This compresses pyramidal management layers and flattens the organisation.
7. **Capture information once and at the source** — replace repeated re-keying across "stovepipe" systems with single-entry data capture, leveraging bar coding, relational databases, and EDI.

The first three principles drive **task compression** (combining specialised steps into outcome-oriented roles); principles 4-7 redistribute **decision authority and information flow** to match the new IT-enabled topology.

## Case evidence

Hammer grounds the argument in two extended case studies:

### Ford Motor — accounts payable (p. 3)

- Initial target: a 20% headcount reduction in a 500-person North American AP organisation, achieved through process rationalisation and new computer systems.
- Benchmark: Mazda's entire AP function was 5 people. Ford reframed its target as a 5x reduction.
- Redesign: "invoiceless processing". Purchasing enters orders into an on-line database; receiving clerks check arriving goods against the database and either accept (auto-triggering payment) or reject. The accounting matching function shrinks from **14 data items to 3** (part number, unit of measure, supplier code).
- Outcome: **75% reduction in head count**, more accurate financial/material reconciliation, no invoices.

### Mutual Benefit Life — insurance application processing (p. 3-4)

- Old process: up to **30 discrete steps, 5 departments, 19 people**; turnaround 5-25 days, of which most was passing work between departments. Another insurer cited internally: 22 days elapsed, 17 minutes of actual work.
- Redesign: a single **case manager** owns the application end-to-end, supported by PC-based workstations running an expert system and connecting to mainframe automation. Specialists (senior underwriters, physicians) act as advisers, not gatekeepers.
- Outcome: applications processed in as little as **4 hours**, average turnaround **2-5 days**, **100 field-office positions eliminated**, more than **2x throughput**, and a **60% productivity improvement** demanded by the MBL president as the design target.

A scattering of smaller vignettes (an East Coast insurer's unread reports, an electronics company collapsing five sequential customer-handling steps into one customer-service representative, HP's federated purchasing, a manufacturer's customer-self-service field repair) illustrate individual principles.

## Position in the literature

- **Antecedent.** Hammer 1990 is the first article-length statement of BPR as a discipline. It precedes [[sources/1993-davenport-process-innovation|Davenport's *Process Innovation* (1993)]] — which formalises the methodology and is more measured about IT's role — and [[sources/1993-hammer-champy-reengineering-the-corporation|Hammer & Champy's *Reengineering the Corporation* (1993)]], which extends the argument to book length and adds further canonical cases (IBM Credit, Hallmark).
- **Polemic register.** Hammer writes in deliberately maximalist terms ("all-or-nothing", "obliterate", "a touch of fanaticism"). [[sources/1994-davenport-stoddard-reengineering-mythic-proportions|Davenport & Stoddard (1994)]] later push back on the resulting mythologies — particularly the claim that reengineering must be done in one big bang and from a clean slate.
- **IT framing.** Hammer's stance — "use information technology not to automate an existing process but to enable a new one" (p. 5) — anticipates the enabler-vs-imperative debate that runs through the BPM lifecycle literature and reappears in modern form in [[sources/2023-dumas-ai-augmented-bpms|ABPMS]] and [[sources/2026-calvanese-agentic-bpm-manifesto|APM]] discussions of AI as redesign substrate rather than process automator.
- **Heuristic legacy.** The seven principles are the proximate ancestor of the **29 redesign best practices** catalogued by [[sources/2005-reijers-limanmansar-best-practices-bpr|Reijers & Liman Mansar (2005)]]; Ford and MBL recur as worked examples in that catalogue.
- **Critical distance.** [[syntheses/bpm-phases-and-bpr-legacy]] uses this article as the Phase-1 anchor for the descriptive narrative of how BPM split off from BPR by retaining the process-as-unit-of-analysis while abandoning the radical-redesign posture.

## Cited from

- [[syntheses/bpm-phases-and-bpr-legacy]] — RQ1 Phase 1 anchor, RQ2 primary reference for the radical-redesign posture and its IT-enabler framing.
- [[sources/2005-reijers-limanmansar-best-practices-bpr]] — heuristics catalogue draws on Hammer's seven principles and reuses Ford / MBL as application examples.
- [[sources/2014-sharp-whats-wrong-with-this-process]] — Case-for-Action framing inherits Hammer's diagnosis of obsolete processes.
- [[sources/1993-hammer-champy-reengineering-the-corporation]] — book-length successor by the same author.
- [[sources/1993-davenport-process-innovation]] — parallel statement of the same programme with a more measured methodology.
- [[sources/1994-davenport-stoddard-reengineering-mythic-proportions]] — critical reassessment of the maximalist claims first made here.

## Connections

**Concepts:** [[concepts/bpr-heuristics]]

**Syntheses:** [[syntheses/bpm-phases-and-bpr-legacy]]

**Related sources:** [[sources/1993-hammer-champy-reengineering-the-corporation]] · [[sources/1993-davenport-process-innovation]] · [[sources/1994-davenport-stoddard-reengineering-mythic-proportions]] · [[sources/2005-reijers-limanmansar-best-practices-bpr]] · [[sources/2014-sharp-whats-wrong-with-this-process]] · [[sources/2018-dumas-fundamentals-of-bpm]]