- Home
- Lean Corner
- From Pilot Site to Enterprise Standard: Five Decisions That Determine Whether Lean Scales
From Pilot Site to Enterprise Standard: Five Decisions That Determine Whether Lean Scales
- Decision 1: Who Builds the Standard at Each Site
- Decision 2: Find Who “Catches Fire” Before Deploying the Tool
- Decision 3: Treat Training as a Separate Step, Not a Consequence
- Decision 4: Measure Problem Visibility, Not Outcome Metrics
- Decision 5: Treat the Rollout as a Learning Process, Not a Project
- What This Looks Like Across a Multi-Site Network
The pilot almost always succeeds. Teams are engaged, the site director is involved, early results arrive quickly. Then comes the rollout to other sites, and the trajectory changes. Not because Lean does not work elsewhere, but because five decisions were made by default, without being properly thought through. They are reversible if identified early. They become structural if left to take root.
Decision 1: Who Builds the Standard at Each Site
The wrong default. The methods team or the central lean office writes the standard at the pilot site and then “deploys” it to the others. Best practices are documented, training materials prepared, presentation sessions scheduled. This seems logical. It is the source of the problem.
The right approach. The standard must be built at each site, with the practitioners at that site.
Here is an example of what I observed that illustrates why. A team of French methods engineers visits a Toyota line in Japan. They observe, document, and measure. They return to France and present the operators with a standardised line modelled on the Japanese one. The response: a flat refusal and a production stoppage. A Japanese sensei then takes the same brief. He visits each operator individually, watches them work, and builds the standard with them. A few weeks later, every operator has their own standard sequence. Comparisons happen naturally, discussions follow, improvements accumulate. A few months later, the line has closed most of the gap to the Japanese reference line.
Decision to make: the pilot site’s standard is a reference, not a template to duplicate. Each site rebuilds its own, starting from the reference, with its own operators.
Decision 2: Find Who "Catches Fire" Before Deploying the Tool
The wrong default. Deploy by geography or org chart. Train site managers at a central seminar, hand them the toolkit, set a deployment target.
The right approach. Before arriving on a site, identify the person who will carry the approach locally.
It is not necessarily the site director. It is often a team leader, a shift supervisor, sometimes a night-shift manager. The method: run kaizen sessions at the site not to improve indicators, but to observe who engages naturally. Who asks precise questions? Who tries things without being asked? Then train that person first, give them time, and build around them.
A tool that arrives at a site without a local carrier arrives in a desert. Forms will be filled in. Indicators will look correct. Meetings will happen on time. And Lean will be dead six months after the deployment team has moved on.
Decision to make: the site deployment schedule must include a prior step of identifying the local carrier. A site with a carrier and no toolkit still improves. A site with a toolkit and no carrier does not.
Decision 3: Treat Training as a Separate Step, Not a Consequence
The wrong default. Assume the written standard transmits itself. Run a one-hour presentation, distribute the document, consider training done.
The right approach. Training on a standard is a separate step, with someone who observes the actual gesture in real conditions.
A morning brief, a day of production, and nobody to review what happened at the end of the shift: that is the equivalent of a football team playing matches without ever analysing performance. Gestures become fixed, right or wrong, with no possibility of correction. Training on a standard means planning the debrief: someone who observes the work in real conditions, sees where it breaks down, and corrects before the wrong habit becomes the new unwritten standard.
Writing does not transmit. What transmits is doing the work together, in real conditions, with someone who spots where things break down and corrects in the moment. The standard is the support for training, not its substitute. Across a multi-site network, this means deciding explicitly: who trains whom, by what method, with what time allocated to observing the actual work, not in a classroom.
Decision to make: for each site, define who will be trained, by whom, and how much time the trainer will spend observing the gesture in real conditions.
Decision 4: Measure Problem Visibility, Not Outcome Metrics
The wrong default. A site reports no problems for two months running. That is not a result. That is the signal something is not working.
The right approach. In Lean, the right signal is not the absence of problems. It is their visibility.
A site that surfaces no problems is not necessarily performing better than the others: it is hiding them. The attern is easy to to recognize once you look for it: when teams sense that raising a problem triggers pressure rather than support, they stop raising problems. Indicators remain correct because issues are handled locally, under the carpet, without collective learning.
The lean rule is simple: nothing under the carpet. A well-used anomaly board, teams that escalate without hesitation, a line manager who presents unresolved problems in the Tier 2 review: these are the signals of a living programme. A site’s drift is not detected on KPIs. It is detected in what no longer surfaces.
Decision to make: add a problem-surfacing indicator to the deployment dashboard. This is not a performance indicator. It is a health indicator for the programme.
Decision 5: Treat the Rollout as a Learning Process, Not a Project
The wrong default. Assume that because the standard has been written, teams trained, and tools installed, the deployment is complete. This assumption is at the core of most scaling failures. Call it the process dream. Assuming that because something is written down, teams across twenty sites will apply it uniformly. It is completely unrealistic.
The right approach. Plan learning loops, not just deployment milestones.
The resistance that appears at sites is not always outright refusal. It is often “we have always done it this way”: a protective reflex, not bad faith. Teams have developed ways to compensate for systemic dysfunctions, often invisible to management. They are being asked to replace those compensations with a new method whose benefits they cannot yet see.
What changes the dynamic: accepting that sites learn at different speeds, and that each site will discover things the pilot did not. Those discoveries must be able to surface and enrich the group standard. A rollout without a mechanism for feeding local learning back to the group produces sites that look compliant on paper and a standard that stops progressing.
Decision to make: define who is responsible for surfacing site-level learnings and updating the group standard. That role must exist before the rollout begins, not after.
What This Looks Like Across a Multi-Site Network
On a single site, these five decisions can be managed informally. The site director knows their teams, sees whether problems are surfacing, and adjusts in real time. Across five or ten sites, these five decisions stop being informal whether you plan for them or not. Before your next site goes live, write down who owns each one, and who gets told when a site’s answer changes.
In iObeya, each site’s boards stay the site’s own, while the group level reads the same board data rather than a separate report. That is what lets a group lead see whether problems are still surfacing at each site without asking each site to restate them.
The question is not “do we have a digital lean deployment tool”, instead it is “can we see, from the group level, whether the programme is alive at each site?”.
For platform selection criteria, see our dedicated article on visual management software.
