Ask ten people in a company to describe how an order, a hire, or a refund actually gets done, and you will get ten different stories, none of them matching the official one. That gap between the process people think exists and the one that really runs is where delay, rework and frustration live. Process work is the discipline of closing that gap: drawing the real thing, redesigning it, and deciding honestly whether you need a tune-up or a teardown.

The quick version

  • Process design is deciding how a piece of work should flow, the sequence of steps, who does what, and where decisions get made, to reliably turn an input into an outcome a customer values.
  • Process mapping is drawing that flow so a group can see it together. The honest version is the current state (how it really runs today, warts and all), which you draw before the future state (how it should run).
  • Re-engineering is the radical end of the scale: not improving the existing process, but scrapping it and redesigning from scratch around the outcome. Powerful, and historically prone to overreach.
  • The choice that matters: incremental improvement (cheaper, safer, slower) versus radical redesign (faster gains, far higher risk). Most of the time you map first, improve the flow, and reserve "obliterate" for processes that are genuinely beyond repair.

The idea in depth

The first move is always the same, and it is unglamorous: draw the process as it actually is. The single most useful version of this comes from Toyota's tradition, written down for a Western audience by Mike Rother and John Shook in Learning to See (Lean Enterprise Institute, 1999). Their tool, value-stream mapping, insists you map the current state first: every step a product or request passes through, the time it spends being worked on versus the time it spends waiting, and where information flows. The title is the whole point. You are learning to see the work, because most of the waste is invisible until it is on the wall in front of a team.

Map the current state before you propose a single change. And do it by walking the actual work, not by inviting managers to describe it from memory. Follow one real order, one real ticket, one real candidate end to end, and write down what truly happens at each handoff, queues between steps included. The revelation is almost always the same: active working time is a tiny fraction of total elapsed time. The work isn't slow because people are slow. It's slow because it spends most of its life sitting in a queue.

An honest limitation. Value-stream mapping was born on a factory floor, where a unit is physical and steps are visible. In knowledge work, approvals, software delivery, professional services, the "unit" is information and the queues are invisible inboxes, so the map is fuzzier and more contested. It still works, but treat it as a shared model to argue over, not a precise measurement. Its job is to make a team see the same picture and agree where the pain is.

flowchart LR
  A(["Walk the real work
one order, end to end"]) --> B(["Draw current state
steps + queues + wait time"])
  B --> C(["Find the waste
where work sits waiting"])
  C --> D(["Design future state
remove, merge, reorder steps"])
  D --> E(["Change one thing
measure, then repeat"])
The mapping loop: see it honestly, find the waiting, redesign the flow, change one thing at a time. Leaders Loop

Improve the process, or obliterate it?

Once you can see the process, you face the strategic question: improve it or replace it? The radical answer has a famous name. In "Reengineering Work: Don't Automate, Obliterate" (Harvard Business Review, July–August 1990), Michael Hammer argued that bolting computers onto a broken process just makes it fail faster. His celebrated example was Ford's accounts-payable department: rather than automating the existing invoice-matching, Ford redesigned the process so that payment was triggered by goods received, cutting the headcount in that function dramatically. Hammer and James Champy turned the idea into a movement with Reengineering the Corporation (1993), where they defined re-engineering as "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed."

When you re-engineer, you start from the outcome and the customer, not from the current steps. Don't ask "how do we make this approval faster?" Ask "why does this need an approval at all?" Re-engineering gives you permission to delete whole steps, entire roles, entire handoffs, that exist only because they always have. That's also its danger. This is heart surgery, not physiotherapy, and you should reach for it only when incremental fixes genuinely cannot get you where you need to be.

Don't automate a broken process, you only make it fail faster.

It is worth being clear that re-engineering was not the only school of thought, and the difference matters in practice. Thomas Davenport, writing in parallel in Process Innovation (Harvard Business School Press, 1993), framed the same shift more carefully as process innovation, radical redesign enabled by information technology, but explicitly built on people and organisation, not just clean-sheet flowcharts. Davenport later argued that the harder-edged "obliterate" rhetoric encouraged companies to treat re-engineering as a synonym for layoffs. That is the fork in the road: the same map can lead to "redesign the work" or "cut the people," and only one of those reliably ends well.

Why re-engineering earned a bad name, and the honest lesson

Here is the limitation you should not skip past, because it is the most useful part of the story. By the mid-1990s, re-engineering had become notorious for failure. The widely repeated figure is that roughly 70% of re-engineering efforts failed, but the provenance deserves care. The number traces back to Hammer and Champy's own book, where they called it an "unscientific estimate" that 50% to 70% of organisations did not achieve the dramatic results they intended. It was never a measured failure rate, and Hammer himself later complained the line had been "transmogrified and distorted into a normative statement," insisting there is "no inherent success or failure rate for reengineering" (Michael Hammer & Steven Stanton, The Reengineering Revolution, 1995). The honest takeaway isn't a precise statistic; it's that the founders themselves, by the mid-90s, were walking the rhetoric back.

What went wrong was rarely the maps. It was that "radical redesign" became cover for slash-and-burn cost-cutting, and the redesigned process was dropped onto people who had been neither consulted nor prepared. Davenport, one of the movement's architects, later called it, pointedly, "the fad that forgot people." Treat process re-engineering, then, as one-third design and two-thirds change. The people who run the work should help draw the future state, and you should expect the rollout, training, incentives, who-does-what-now, to be the hard part. A brilliant flowchart that nobody owns is just expensive wall art.

This is also why, for most teams most of the time, the safer default is the improvement loop, not the teardown. Map the current state, attack the biggest queue, change one thing, measure, repeat. Reserve full re-engineering for the rare process that is so misshapen, so full of steps that exist only to compensate for other broken steps, that improving it incrementally would be polishing something you should be demolishing.

A worked example

Take a mid-sized insurer, call it Marden Mutual, whose customers complain that a simple claim takes three weeks. (Illustrative figures throughout; this is a teaching example, not a real company.) Leadership's instinct is to buy a faster claims system. Before spending, the operations lead does the unglamorous thing first: she follows five real claims end to end and draws the current state on a wall.

The map is damning in the most ordinary way. Of the roughly 21 calendar days a claim takes, the actual hands-on work, assessing, approving, paying, adds up to under four hours. The rest is waiting: a claim sits in a shared inbox for days, gets routed to an assessor, bounces back for a missing document, waits for a manager's sign-off on amounts that almost never get rejected, and queues again for payment. The "three-week process" is really four hours of work wrapped in a fortnight of queues and handoffs.

flowchart TD
  A(["Claim submitted"]) --> B{"Hands-on work
or waiting?"}
  B -->|"~4 hours total"| C(["Real work:
assess, approve, pay"])
  B -->|"~20+ days total"| D(["Waiting:
inboxes, routing, rework,
sign-off queue"])
  D --> E(["Future state:
auto-approve small claims,
request docs up front,
remove rubber-stamp step"])
  C --> E
  E --> F(["~21 days → ~4 days
(illustrative)"])
The fix wasn't a faster system, it was deleting the waiting. Most of the elapsed time was queue, not work. Leaders Loop

Now the redesign almost writes itself, and notice it needs no new software. Small, low-risk claims under a threshold are auto-approved instead of queuing for a manager whose sign-off is a near-automatic rubber stamp. The system asks for every required document up front, killing the most common bounce-back. The shared inbox is replaced by clear ownership so no claim sits unassigned. None of this is heroic re-engineering; it is honest mapping followed by the removal of steps that earned their place only through habit. The illustrative result, three weeks down to about four days, comes not from working faster but from waiting less. And crucially, the assessors helped draw the new flow, so on day one they were running their own design, not resisting someone else's.

Frequently asked questions

What's the difference between process mapping and process re-engineering?

Mapping is drawing the process so you can see it; re-engineering is one of the things you might do once you can. Mapping is diagnostic and low-risk, you always start here. Re-engineering is a radical-redesign treatment you apply only to processes that are genuinely beyond incremental repair. You can map a process and conclude it needs nothing more than a small tweak; you should never re-engineer one you have not first mapped.

Should I draw the current state or the future state first?

Current state, almost always. The instinct to jump straight to "how it should work" skips the step that creates the insight: seeing how it really works today, including the waiting and rework that nobody had measured. Rother and Shook are emphatic about this in Learning to See, the current-state map is what reveals the waste, and the future-state map is your answer to it. Designing the ideal in a vacuum tends to fix problems you don't have and miss the ones you do.

Isn't re-engineering just a 1990s fad that failed?

The branding faded and the harsher rhetoric deserved its bruising, but the core idea, redesign work around outcomes rather than automating what already exists, is permanently true and quietly everywhere. The lasting lesson from its failures is not "don't redesign processes"; it's "don't treat redesign as cost-cutting, and don't impose it on people who had no hand in it." Done with the people who run the work, radical redesign still delivers; done to them, it still fails.

How do I know whether to improve a process or replace it?

Map it, then look at the ratio of value-adding time to total elapsed time, and at how many steps exist only to compensate for other broken steps. If the flow is basically sound but leaky, improve it: attack the biggest queue and iterate. If the process is so contorted that half its steps are workarounds for the other half, incremental fixes just move the mess around, that's when a clean-sheet redesign earns its risk.

Do I need special software to map a process?

No, and starting with software is often a mistake. The most valuable maps in the lean tradition are drawn by hand, on a wall, by the people who do the work, because the point is shared seeing, not a polished artefact. Sticky notes and a marker get you 90% of the value. Reach for tooling later, to standardise or share what the group has already worked out together.

Related in the Toolkit

Process work sits at the heart of operations: the delivery method you choose is itself a process design for how work flows, and the lean tradition that gave us value-stream mapping is the same one behind continuous improvement.

Where to go next