The Redesign Moves: What Changes When a Step Gets Cheap

The central idea is easy to state and hard to act on. A process is shaped around the costs it faced when it was designed. Change one of those costs substantially and the existing shape is no longer optimal, even if every individual step still works.

This is why inserting AI into a step and leaving everything else alone captures so little. The step gets faster and the process keeps a structure built for the old cost, including all the arrangements that existed to economise on the thing that is no longer expensive.

The useful question is therefore counterfactual: if producing a first draft had always been nearly free, what would this process look like? The answer is rarely the current process with one faster step.

A historical parallel makes the point. When photocopying became cheap, organisations did not merely copy faster. Document flows reorganised, because arrangements built around scarce copies stopped making sense. The second-order changes were larger than the first-order one.

What follows are six moves that recur when a production step becomes cheap. They are not a checklist to apply wholesale, and running through them against a mapped process reliably surfaces more than staring at the map does.

Batching exists to amortise a fixed cost. Where the fixed cost disappears, the batch should too, and this is the most frequently missed redesign move.

Work is batched because setup is expensive, because a specialist is only available on Tuesdays, because a report runs nightly, or because it is more efficient to do twenty at once than one at a time. Every batch introduces waiting: an item arriving just after a batch closes waits for the whole cycle.

When the per-item cost of a step collapses, the reason for the batch often goes with it. Processing items as they arrive removes an entire class of waiting, and in a process dominated by elapsed time rather than touch time, that is where the gain actually is.

The caution is that not all batching is about cost. Some exists because a human reviewer works better in focused blocks than in constant interruption, and destroying that produces a worse outcome for the reviewer even as items flow faster. Batching for attention is legitimate; batching for setup cost usually is not.

So the question per batch is which kind it is. Where the answer is that we have always done a weekly run, it is a candidate. Where the answer is that the reviewer needs uninterrupted time, leave it and protect it.

Review positions are set by the error profile of the process, and AI changes that profile, which means the review is almost always in the wrong place afterwards.

The old profile: errors correlate with effort and complexity, occur at a rate proportional to volume, and tend to look like errors. Review positioned at the end catches them because a careful reader notices something is off.

The new profile: volume rises, so the same error rate produces more errors in absolute terms. Errors are polished rather than obviously wrong, so end-of-line review is less effective per item. And the errors cluster differently, concentrating on the cases the model handles poorly rather than the cases the human found hard.

Three relocations follow.

Move review earlier, to check inputs and assumptions rather than only outputs. Verifying that the right sources were retrieved is cheaper and more reliable than verifying a finished narrative.

Move review to sampling plus targeting, rather than uniform inspection. Deep review of a risk-weighted sample beats shallow review of everything, and it is the only affordable response to higher volume.

And move some review into the process as automated checks, so a human sees only what a cheap check could not clear.

A process where review stayed exactly where it was after AI was introduced has almost certainly not been redesigned, only accelerated.

Applied against a mapped process, in roughly the order of how much they typically yield.

Eliminate compensating steps by fixing the upstream cause. The largest and least glamorous gains.

Unbatch where the fixed cost that justified batching has gone.

Relocate review to match the new error profile.

Collapse handoffs, because a step that is now cheap may not need a specialist, and the handoff itself was often more expensive than the work.

Parallelise steps that were sequential only because a scarce resource could do one thing at a time.

And expand the constraint, spending some of the gain on the step that actually governs throughput.

The ordering matters. Teams reliably start at parallelise, because it feels like design, and skip eliminate, because it feels like admitting the process was bad. The yields run the other way.

A handoff is expensive in ways that never appear in a step duration. The item queues, context is lost, the receiving person reconstructs what the sender knew, and accountability blurs in the gap.

Handoffs exist for two reasons, and only one of them survives AI.

Specialisation: the next step needs expertise the first person lacks. This is the legitimate reason, and where the expertise is genuine judgement it remains.

And capability: the next step required a skill or tool the first person did not have. This is the reason that erodes. Where drafting, formatting, translating, summarising or basic analysis previously required routing to someone else, they may no longer.

So the move is to look at each handoff and ask which kind it is. Where it is capability rather than judgement, the step can often move to whoever already has the context, which removes the queue and the context loss at once. A single person handling a case end to end, with AI supplying the capabilities they lack, is frequently faster than three specialists in sequence even when each specialist is individually better at their part.

The caution is real though. Collapsing a handoff also removes the second pair of eyes it incidentally provided. Where the handoff was doing quality work as a side effect, that has to be replaced deliberately rather than assumed away.

Applying the moves to the mapped process from the previous lesson.

ORIGINAL                          REDESIGNED

2 Log claim      8m / 4h          Auto-extract from email, human confirms
                                  8m -> 2m, 4h -> 20m

3 Chase docs     5m / 3 DAYS      ELIMINATED: form redesigned so the
                                  required fields cannot be omitted

4 Verify cover   12m / 6h         AI drafts the coverage position,
                                  handler verifies against policy: 6h -> 1h

5 Reconcile      20m / 1 DAY      ELIMINATED: the two systems were
                                  integrated. Six weeks of work, once.

6 Approval       6m / 2 DAYS      Threshold raised so 80% self-approve;
                                  senior sees the 20% that matter: 2d -> 4h

7 Notify         3m / 2h          Auto-drafted, handler sends: 2h -> 15m

TOTAL            54m / ~7 days -> 20m / ~6 hours

Notice where the gain came from. The two eliminated steps, neither of which involved AI, removed four of the seven days. The approval change, a policy decision rather than a technology one, removed most of the rest.

AI contributed real but modest improvements to touch time, and the elapsed-time gain, which is what the claimant experiences, came overwhelmingly from fixing an unclear form, integrating two systems, and changing an approval threshold.

That distribution is typical, and it is the argument for mapping before building.

This method has a lineage worth knowing, including its most misused statistic.

Business process reengineering, set out by Michael Hammer and James Champy in Reengineering the Corporation in 1993, argued for redesigning processes around outcomes rather than automating existing steps. That core insight is sound and is what this lesson applies.

The frequently quoted figure is that seventy percent of such efforts fail. Its provenance deserves attention. Hammer and Champy wrote that as many as fifty to seventy percent of organisations undertaking a reengineering effort do not achieve the dramatic results they intended, and they explicitly described this as an unscientific estimate.

It then took on a life of its own. Mark Hughes examined its evidential basis in the Journal of Organisational Change Management in 2011 and found the trail leads back to that single unscientific observation. Hammer himself later said the simple descriptive observation had been widely misrepresented and distorted into a normative statement, and that there is no inherent success or failure rate for reengineering.

So the honest position is that nobody knows the failure rate, and anyone quoting seventy percent is repeating an author's own guess that the author disowned.

What did emerge from the era, and is better evidenced, is the pattern of how these efforts go wrong: automating existing processes rather than redesigning them, ignoring the people affected, and attempting too much at once. Those are the failure modes the next lesson addresses.

The reengineering literature argued for radical redesign over incremental improvement. That framing produced both its successes and its casualties, and the sensible position is between the two.

The case for radical: incremental improvement optimises within an existing structure, and where the structure itself is wrong you can improve every step and still have a bad process. Some gains are only available by rebuilding.

The case against: radical redesign changes many variables at once, so when the result disappoints nobody can tell which change caused it. It disrupts the people doing the work, consumes political capital, and takes long enough that the situation shifts underneath it.

What resolves it is scope rather than depth. Redesign one process radically rather than five incrementally. That gives you the structural change where structure is the problem, while keeping the blast radius small enough to measure, reverse and learn from.

Two selection criteria for which process. Pick one where the map showed structural problems, compensating steps and misplaced constraints, rather than one that is merely slow. And pick one whose owner wants it, for the same reason the AI QA cursus picks a willing team.

And sequence deliberately. Do the eliminations first, since they are cheap, reversible and build credibility. Save the structural rebuild for after the easy wins have bought you the standing to attempt it.