Assume the Plant Burned Down Last Night.

In 1951, a vice-president at Bell Telephone Laboratories in Murray Hill called roughly forty section heads into a room and told them something absurd. The entire American telephone system had been destroyed overnight. Their job, starting now, was to design its replacement.

They were given two rules. Whatever they designed had to be technologically feasible — no science fiction. And it had to be operationally viable — it had to work inside the laws, the economy and the environment that actually existed. Beyond that, nothing about the system they had spent their careers maintaining was allowed to constrain them.

What came out of that room, over the following months, reads today like a list of the next fifty years: touch-tone dialling, call waiting, call forwarding, voicemail, caller ID, conference calling, the speakerphone, speed dialling — and the mobile phone. Of everything the telephone system would become, the exercise missed only two things: photography and the internet.

One detail shows how the method actually bites. The subgroup working on the handset — which included a young operations researcher named Russell Ackoff — was not trying to invent the push-button phone. It was trying to eliminate wrong numbers. Working backwards from "a system in which you never misdial", they specified a small device that would let you check the digits before sending them. The push-button telephone was a by-product of asking what perfect would look like. Nobody got there by improving the rotary dial.

The method has a name, and a doctorate behind it

What that vice-president ran is now called idealised design, and Ackoff spent the rest of his life formalising it (Ackoff, 1981). The device is deliberately violent: assume the system you are responsible for was destroyed last night. It no longer exists; it cannot constrain you. Now design its replacement — not the system you predict, not the one you can afford, but the one you would build today if you were free to.

The design is bounded by three constraints and nothing else:

Then, and only then, you turn round and work backwards from that design to Monday morning. The gap between the ideal and the actual becomes your agenda — not a wish list, but a route.

Why this bites hardest in a brownfield plant

Readers of this newsletter run plants with thirty or forty years of history in their concrete. And here is the uncomfortable truth about kaizen in that setting. Continuous improvement is a hill-climbing algorithm. It is superb at it, and it belongs to the people doing the work, which is why it lasts. But hill-climbing has a property no enthusiasm changes: it can only take you to the top of the hill you are already standing on. It cannot see the higher ground across the valley, because every step towards it is, at first, a step downhill.

Your layout is where it is because of a decision made in 1987. Your routings encode a machine you no longer own. Your planning logic works around a constraint removed in 2011 that nobody told the system about. Thirty years of diligent improvement has made you excellent at the plant you have — which is not the same thing as being anywhere near the plant you could have.

Now put AI on top of that. The overwhelming majority of industrial AI projects I see are automating the compromise. A model that predicts scrap caused by a layout nobody would choose. A scheduler that optimises around a constraint three managers old. A dashboard reporting, in beautiful real time, on a process that shouldn't run that way at all. The technology works perfectly. It makes the wrong plant slightly more efficient — and, worse, it makes the wrong plant permanent, because now there is capital, code and a vendor contract holding it in place.

Michael Hammer said this in 1990 in four words that have aged well: "Don't automate, obliterate." Ford had 500 people in accounts payable and was about to buy a system to make them faster. Their partner Mazda ran the same function with five. Ford stopped, redesigned the process rather than the paperwork around it, and cut the department by about 75% (Hammer, 1990). The automation project would have delivered perhaps a fifth of that — and locked the rest away for a decade. Swap "accounts payable" for "your OEE reporting", and 1990 for now.

But the ideal has to be designed by the people who know the plant

There is a graveyard on the other side of this argument, and it deserves equal billing. Business process reengineering became notorious for exactly the failure you'd predict: brilliant future-states designed by clever people in a room, imposed on a workforce whose accumulated process knowledge was treated as an obstacle. Technically elegant, socially illiterate, and much of it did not survive contact with the floor.

The most expensive recent demonstration is not a consultancy at all. In 2018, Tesla built what its founder called an "alien dreadnought" — a Model 3 line automated to a degree no car plant had attempted, designed around an ideal of a factory with almost no people in it. It did not work. The conveyor network was ripped out. Musk's own public summary is the most useful sentence any executive has written about manufacturing automation: "excessive automation at Tesla was a mistake… Humans are underrated" (Musk, 2018).

That is not an argument against designing the ideal. It is an argument for Ackoff's second and third constraints — which the alien dreadnought comprehensively failed. A design that removes the people also removes the system's ability to improve itself, which makes it, by Ackoff's own definition, not an idealised design at all. So the method has two halves, both load-bearing: discontinuous in ambition, participative in method. The people affected by a system must be the ones who design it. Not consulted. Not surveyed afterwards. In the room, holding the pen.

The systems view: a homeostat with no set-point is just weather

In Stafford Beer's Viable System Model, System 3 runs the inside-and-now; System 4 looks outside-and-then. The pair are held in tension by a homeostat — a mutual regulator that keeps the operation and its future in balance. System 5 supplies identity: what this organisation is for.

Here is the thing about any homeostat, whether in a factory, a body or a boiler: it regulates towards a set-point. A thermostat with no temperature set does not fail dramatically. It hums, it responds, it burns energy — and the room drifts wherever the weather takes it. An idealised design is the set-point. It is the reference signal that gives System 3's regulating something to regulate towards. Without it, "continuous improvement" is a control loop with no target: real motion, real effort, real cost-savings reported each month — and no direction. This is the honest explanation for the plant that has run kaizen faithfully for a decade and is still, structurally, the plant it was. Nothing was wrong with the improving. There was simply nothing to improve towards.

Kaizen without an idealised design is a thermostat with no temperature set. It will work perfectly, for ever, and the room will still be cold.

The part nobody expects: it extracts process knowledge

Here is the benefit almost never advertised, and now the main reason I run these in a brownfield plant. You cannot design the ideal line without saying out loud, in a room, every reason the current line is the way it is. And the moment you try, the tacit knowledge starts coming out. "We can't run that sequence because the fitter has to be there for the changeover and he's only on days." "That buffer isn't in any drawing — Piet put it there in 2009 because the upstream machine surges after a stop."

None of that is written down. None of it appears in the MES. It is process knowledge in Dan Wang's sense — the embodied know-how that is the binding constraint on whether any technology lands. Interviews do not surface it, because nobody can answer "what do you know that isn't written down?" But "design the ideal plant" surfaces it in a morning, because every constraint someone defends is a piece of knowledge made visible. Design the ideal, and you find out what your plant actually knows.

What works, and what doesn't — on real floors

What doesn't work: the digital twin of the mess. A high-fidelity model of a process that should not exist. Ask, before you fund it: would this constraint exist in the plant we would build tomorrow? If not, you are about to spend real money making a bad decision permanent.

What doesn't work: the consultant's future-state map. A future state designed for the plant and presented to it. It has no process knowledge in it, so it is wrong in ways no one in the room can see — and nobody on the floor defends it when it gets hard. This is BPR's grave.

What works: one South African plant, half a day, no consultants. The most valuable half-day I spent in a plant this year was spent not solving anything. Operators, artisans, the planner and the plant manager, one rule — the plant burned down last night; draw the one we'd build — and butcher paper. Out of it came a dozen constraints everyone had assumed were physical and which turned out to be habits, three removed within a month for almost nothing. And the AI scheduling project they were three weeks from signing solved a problem that did not exist in the design they had just drawn. That project was cancelled. The money went into the changeover work the ideal design said was the actual constraint. No algorithm would have found that.

Five moves

• Book the half-day, not the workshop series. Four uninterrupted hours, the right dozen people, and paper. If it takes a steering committee to arrange, it will not happen.
• Enforce the three constraints, out loud, all the way through. Feasible with what exists now. Viable in the world as it is. Capable of learning and adapting — if the design assumes the people out, it has failed the third test, whatever it saves.
• Put the process knowledge in the room, holding the pen. Operators, artisans, planners, the person who does the changeover. Not represented — present.
• Use the design as an investment filter, immediately. For every capital or AI project in your pipeline: does this constraint exist in the ideal design? If not, you are automating something you intend to delete. That question alone pays for the exercise.
• Convert the gap into one target condition at a time. Do not attempt the ideal. Pick the obstacle blocking you now, run one experiment, and re-aim (Rother, 2010). The ideal is the set-point, not the plan.

The bottom line

The forty people in that Murray Hill room did not have better technology than anyone else. They had a better question. Not "how do we improve the telephone system?" — which would have produced a slightly better rotary dial and nothing else — but "if it were gone, what would we build?" Brownfield manufacturing is drowning in answers right now: models, platforms, twins, copilots, dashboards, most of them aimed at making the plant we happen to have marginally better than last quarter. The scarce thing is not the answer. It is the question that tells you which plant you are supposed to be building in the first place.

So ask it, this month, in a room with the people who actually know: the plant burned down last night. What do we build? You will be surprised how much of the answer is already standing there, in overalls, waiting for someone to ask.