Phase 1 — See

Step 1 — Map the whole system, including the office and the data layer

Question: Where does an order enter, which databases and interfaces does it trigger, and what happens to it until the customer is running the machine?

Do: Map from customer enquiry to commissioning, not from goods-in to goods-out. Treat quotation, configuration, procurement and scheduling as stations with their own queues, batch sizes and rework loops. Mark what is made and what is bought.

Mapping the physical flow is not enough. For each stage, record where the information comes from, whether it arrives automatically or by hand, which system holds it, and who is allowed to change it.

Output:* one map — office, data layer and shopfloor together — with times and data sources on it.

Mistake: mapping only the shopfloor, because that is where the machines are.

A note on tools: process mining software such as Celonis reconstructs how a process actually runs from the timestamps in your systems, rather than from how it is documented. It is strong for the office and order flow and weak for anything not logged — manual steps, paper, most shopfloor work. It is also worth remembering that it faithfully reconstructs whatever structure your systems record, including a bad one.

Step 2 — Find the constraint, and find out who can change anything

Question 1: Which step limits output — for the orders you actually receive?
Question 2: How many people could draw a dependency map of the factory, and what else are they responsible for?

Do 1: Check the constraint for your most common order mixes, not nameplate capacity. Capacity in units is meaningless without a mix. Simple and complex orders load different stations, and the constraint moves between them.

Do 2: Change requires capacity in the people who must carry it. Look at the workload of the key interface roles — usually IT or OT — and at how much of their time is already committed to keeping production running.

Output 1: the constraint named for each typical mix.
Output 2: an honest picture of the capacity of the people without whom no change reaches the factory.

Mistake: quoting one capacity figure for a factory that builds different products.

If the answer to the second question is one or two people, and those people are also the breakdown response, then the firm's capacity to change is whatever is left of them after production has taken its share — which in practice is close to nothing. They need to be relieved of responsibilities before any transformation can start. More importantly, when the dependency map exists only in two people's heads, the company does not have organisational capacity at all. It has personal capacity, and the two look identical right up to the moment either person is unavailable.

Step 3 — Find where the time goes

Question: Of the weeks between order and delivery, how many are spent actually working on the machine?

Do: Compare hands-on time with total lead time. Then split lead time into before and after production starts. In configure-to-order firms much of it is waiting in the office — clarification, engineering, procurement, scheduling.

Output: the share of lead time that is real work, and the share that passes before production begins.

Mistake: speeding up machines when the orders are waiting on paperwork.

Step 4 — Know what complexity costs

Question: Do you know what your most complex variant costs compared with your simplest?

Do: Allocate overhead by what variants actually consume — changeovers, engineering hours, planning effort, special handling. When this is not done, complex variants look more profitable than they are, and variety keeps growing.

Output: a realistic cost comparison across variants, which the sales configurator and the price list should reflect.

Mistake: averaging overhead across everything, which hides the cost of variety.

Complexity consumes scarce constraint capacity inside a factory. So, even if a more complex product variant seems more profitable on paper, you can't assess profitability independently of the resources and variability the product imposes on the system.

This knowledge about complexity is distributed across parties with different KPIs and different goals, and that is where conflict sits. Any change to the process landscape must account for those conflicts, or they will decide the outcome.

Phase 2 — Decide

Step 5 — Simplify before you digitize

Question: If we digitize this process as it stands, are we simply making the current mess permanent?

Do: Remove steps, variants, handoffs and data fields that exist only because of history, before building systems around them. Digitizing first freezes the process, because every system built afterwards depends on the old structure.

This is where most transformation projects are lost. Simplification challenges the goals and KPIs of individual departments directly. Conflict can be constructive, but when a change competes with a department's own targets it turns destructive, and what emerges is not a simpler process but a negotiated one — every requirement accommodated, nothing removed. Compromise of that kind nullifies the effort.

Output: a simplified process that is worth digitizing.

Mistake: moving the old process into new software and calling it transformation.

Step 6 — Test the proposed change against the constraint

Question: Will this investment raise output, or only make one department more comfortable?

Do: Ask of every proposal:

1. Which step does it change in the overall process landscape, and is that the constraint under our real mix?

2. Does it shorten processing time, changeover time, or waiting time?

3. Does it reduce variation, or only measure it?

4. Does it improve quality upstream of the constraint, so the constraint wastes less time on rework?

5. Does it let us handle more variants without losing capacity?

Questions 1, 4 and 5 cannot be answered by one department alone. That is why good proposals are rare and local ones are common.

Output: keep, redesign, or drop — with the reason written down.

Mistake: judging an investment by what it does to its own station.

A note on question 4. Improving quality at a station upstream of the constraint means less rework downstream. A part scrapped after the constraint has already consumed constraint capacity that cannot be recovered, so upstream quality is not a local matter — it is capacity, bought indirectly. Better data availability shortens reaction time and supports this, which is one of the few cases where instrumenting a non-constraint station genuinely pays.

Phase 3 — Change

Step 7 — Test whether the organization can carry it out

Question: We understand the technology — can our organization actually change around it?

Concept: Absorptive capacity. Firms first recognize the value of new knowledge and take it in, then transform it and put it to use. The first part is usually done well near the top. The second happens on the shop floor and at the office stations. The gap between them is where programs stall, because the change crosses departmental lines.

When boundaries are crossed, conflict becomes destructive without clear delegation from senior management. They have to be involved, and resistance has to be documented and resolved rather than absorbed.

Do: Three probes.

• When did we last retire a process or system instead of wrapping it?

• Pick one data field in a core system — can anyone explain where it came from and why?

• When a change crosses departments, what is the escalation path and how long does it take? Use a real, dated example.

Output: a predicted failure mode — what will be dropped when the deadline arrives. It can be checked later, which is what makes the exercise worth running.

Mistake: assuming that understanding a technology means being able to use it.

What a failed test looks like. A mid-size machine manufacturer, hundreds of employees, replacing an ERP system grown over decades. The ambition was genuinely architectural: a sales configurator that would generate the master template for each product directly, carrying certifications and constraints, and trigger every downstream database entry — with the legacy structures then switched off.

It did not fail because people obstructed it. Most of the resistance was substantive. Engineering wanted legacy entries removed; IT explained that specific machines still required them, for reasons accumulated over twenty to thirty years. Both were right. The problem was that nobody could hold the whole dependency map: one or two people understood the scope of what was being proposed, and the person who knew which machine needed which entry was also the person who dropped everything when a machine broke. Every data change reached the factory through that person.

Requirements were collected from every department and reconciled rather than reduced. Interfaces were designed first, but the legacy data structure cot su’t support them. Several hundred station-level applications each pulled what they needed from the databases, so changing anything meant editing an application. Nobody made a decision to descope; scope drifted away as the deadline approached.

The configurator shipped and it was a real improvement — sales now creates products in a standardized way, and downstream ordering is triggered far more automatically. The architecture underneath did not change. The front office transformed; the core did not.

Step 8 — Loosen the ties that hold change back, selectively

Question: Which of our rules, owners, and dependencies protect something essential, and which only protect someone's territory?

Concept: The capabilities that made a firm successful are frequently what stops it from changing. Change needs both movement and resistance, and the goal is a productive balance rather than removing all resistance.

Resistance is information.

For example, a colleague desperately insisted on keeping a legacy database field. This field was keeping a 20-year-old machine operational. Resistance might be organizational inertia, but it could also mean that it’s the one thing keeping a crucial machine operational.

Do: List every tie that blocks a proposed change and sort it by what it protects.

Protects Examples Treat as Action Production continuity Running orders, delivery commitments Load-bearing Change around it; stage the transition Quality and precision Tolerances, test procedures Load-bearing Keep; redesign the interfaces around it Safety and certification Approvals, regulatory steps Load-bearing Keep; plan changes within the rules Machine dependency A legacy field a machine still reads Load-bearing Document first; replace the interface, not the field Ownership of an artifact Who controls a data field or form Defended Reassign to the end-to-end process Budget or headcount Department size, cost centre Defended Negotiate openly Habit "We have always done it this way" Defended Remove

Sort tie by tie, with the person who defends it present. Loosening everything at once — which is what a crisis does — breaks load-bearing ties along with the rest, and they then have to be rebuilt at cost.

Expect more of the list to be load-bearing than you would like. In the case above, most of it was.

Output: a sorted list of ties, each with an owner and an action.

Mistake: treating all resistance as obstruction, or all of it as legitimate.

Step 9 — Make change continuous

Question: Are we set up to change again next year, while production keeps running?

Concept: Transformation is not a single project. It is an ongoing ability that rises and falls over time.

Do:

• Keep and retrain the people who know each segment. They hold the process knowledge that end-to-end redesign needs. People do not surrender knowledge that eliminates their own jobs; employment security is a condition for getting it, not a reward afterward.

• Build connections across departments: shared teams, job rotation, joint decisions.

• Formalize how change happens, so it is repeatable rather than dependent on individuals.

• Design infrastructure to be changed while running: clear interfaces, so one segment can be replaced without stopping the rest.

Output: repeat the three probes from Step 7 each year and see whether the answers are improving. The process landscape produced in Step 1 should be a living document, not a one-off exercise by a new hire who never opens it again.

Mistake: declaring transformation finished after one program.

Conclusion

Productivity improves when a firm changes how the whole system turns input into output — not when it buys faster equipment for one station, or new software so that IT can see data from every machine. The binding question is rarely what to change. It is whether the organization can agree to change it.

This method gives a manager a way to answer that question before committing the money, and to improve the answer over time.

Sources & Inspiration:

• Eliyahu Goldratt, The Goal (1984) — throughput is set by the constraint; improvement elsewhere is not improvement.

• Wallace Hopp and Mark Spearman, Factory Physics — Little's Law, the relationship between utilisation and waiting time, and why variability must be buffered by inventory, capacity or time.

• Shigeo Shingo, SMED — internal versus external setup, and why changeover time determines variant flexibility.

• Mike Rother and John Shook, Learning to See (1999) — value stream mapping.

• Michael Hammer, "Reengineering Work: Don't Automate, Obliterate," Harvard Business Review (1990); Hammer and Champy, Reengineering the Corporation (1993).

• Dorothy Leonard-Barton, "Core Capabilities and Core Rigidities," Strategic Management Journal 13, 1992 — how strengths become constraints.