Beyond the pilot: why manufacturing digital programmes stall, and what the plants that scale do differently

Pilot purgatory

The World Economic Forum uses the term “pilot purgatory” for this condition. Describing the origins of its Global Lighthouse Network, the Forum’s Francisco Betti recalled that in 2018 most companies were developing use cases with new technologies but struggling to deploy them at scale to achieve operational and financial impact. The network was created to identify sites that had made that transition, so that others could learn from them.

The first 16 sites were identified in a white paper published with McKinsey & Company in January 2019. Following the Forum’s announcement of 16 new awards in June 2026, the network comprises 238 sites.

Why pilots stall

Published lighthouse material and practitioner experience point to a consistent set of causes.

1. Chosen for feasibility rather than value. The first use case is selected because it is easy to demonstrate, with no measured baseline and no agreed definition of success. When the pilot ends, there is no evidence for the business case on the next line.
2. Built as a one-off. Point-to-point integrations and a data model designed for one line cannot be reused. McKinsey & Company’s Enno de Boer, speaking on the Forum’s platform, described the requirement as a horizontal technology stack in which data flows freely, rather than monolithic use cases that do not communicate with one another.
3. Capability stays with the build team. If only the external team can configure, extend or troubleshoot the solution, every additional line depends on them. De Boer identified capability building as the factor that becomes limiting most quickly.
4. No value assurance. Without a mechanism that tracks impact against a baseline, results remain anecdotal and funding for scale is hard to secure. De Boer cited value assurance and governance through a transformation office as an enabler of scale.
5. Unclear ownership. When operations, IT and engineering each own part of the solution and none owns the outcome, decisions on standards and priorities stall.

What scaling sites do differently

The practices that recur in the Forum’s material are not technology choices.

• A focused portfolio. Rather than piloting everything, De Boer advised selecting the use cases that drive the most value (in his example, about two dozen from a library of roughly 130 recurring lighthouse use cases) and making them the standard across the production network.
• Value that is quantified and tracked. In the Forum’s June 2026 announcement, Aramco Ventures’ Meshal Almashari observed that transformation becomes real when value is quantified, continuously tracked and scaled across sites and functions, not when the most technologies are piloted.
• Fundamentals alongside technology. The same announcement reported that findings from Lumina, the Forum’s platform built on network data, show the greatest impact where technology is combined with strong operational fundamentals, workforce engagement and clear strategic objectives.
• Investment in people. In the Forum’s January 2025 announcement, McKinsey & Company described empowering the frontline and building inclusive digital cultures as central to lighthouse success.
• Leadership ownership. Betti noted that for lighthouse sites the transformation is a priority for the chief executive, the leadership team and the board, which is what allows investment to be prioritised and internal barriers to be removed.
• Iterative delivery. De Boer described minimum viable products released and improved in iterations, because the technology changes too quickly for a fixed multi-year plan.
• Realistic timelines. De Boer put the typical time to create a lighthouse at nine to eighteen months.

What lighthouse results indicate, and what they do not

Lighthouse outcomes are widely quoted. The Forum reported that its January 2025 cohort observed an average 53% increase in labour productivity and a 26% reduction in conversion costs, attributed to digital solutions such as AI, machine learning and advanced analytics. These are results from sites designated by an independent expert panel for exceptional performance. They show what is achievable at the frontier, not what a typical programme should expect. A programme’s own baseline, measured before the pilot starts, is the only sound reference for its targets.

A scale-readiness test

Before a pilot is declared a success, it should be possible to answer each of the following questions with evidence.

A “no” to any question is not a reason to stop. It is the work that remains before scaling. For the measurement side, see our guide to measuring OEE; for the technical side, see connecting legacy machines.

How OrbitX approaches this

Our engagements are structured so that the same team diagnoses and delivers, the baseline is measured before anything is built, and handover is part of the scope rather than an afterthought. The scale-readiness test above is the exit criterion we set for a line pilot. See adoption, support and scale.