Digital Transformation Roadmap in Manufacturing: From Proof of Concept to Scale

Most industrial proofs of concept work and still never reach production. The problem is almost never the technology: it is that the pilot was designed to demonstrate, not to scale. This article explains pilot purgatory, the architecture and organisation decisions that separate an isolated case from a platform, and how to measure honestly whether a digital initiative is scaling or just accumulating demos.

Pilot purgatory: why most PoCs never scale

In almost any mid-sized industrial plant there is a discreet graveyard of pilots: an energy consumption dashboard that stopped updating when the intern who built it left, a vibration sensor installed on a pump that nobody looks at, a quality prediction model that lived for three months on an engineer's laptop. None of them failed in the strict sense. All of them proved what they were meant to prove. And none of them went any further.

That intermediate state is often called pilot purgatory: the initiative is not dead (it worked, there are photos, it featured in the results presentation), but it is not alive either (it is not operated, not maintained, and generates no recurring value). Consultancies such as McKinsey have been pointing out for years that most industrial companies starting digitalisation programmes get stuck in this phase, and field experience confirms it: the bottleneck of industry 4.0 is not launching pilots, it is getting out of them.

It pays to understand why this happens, because the intuitive explanation (lack of budget, resistance to change, immature technology) is usually wrong. A pilot and a production system are different objects that share an appearance. The pilot answers the question "is this technically possible here?". The production system answers a very different one: "who operates this on a Tuesday in August when the connection fails and the person who built it is no longer around?". When the pilot is designed only for the first question, answering it brings you almost no closer to the second.

We will use one example throughout the article: a company with four machining plants that launches a downtime monitoring pilot in one cell of its main plant. The team connects three machines, stands up a dashboard and in eight weeks proves it can see stoppages in real time and classify them. The pilot is a success. Two years later, those three machines are still the only connected ones of the more than eighty the group owns. Nothing failed. Simply, nothing that was built worked for machine number four.

The root causes: five decisions taken badly on day one

A pilot's fate is largely decided before the first sensor is installed. There are five early decisions that, taken with demonstration logic, condemn the scale-up:

In our machining example, the team chose the three most modern machines in the plant, with OPC UA as standard, precisely because they were easy. The group's real fleet was dominated by old controls with no native connectivity. The pilot proved something true about a fleet that did not exist. That is the most common trap: selection bias turns the pilot into a demonstration under ideal conditions, and scale lives in the real ones.

The second root cause is economic and fits in one sentence: the pilot has a project budget and the scale-up needs an operating budget. The project ends, the team is congratulated and the money runs out. Nobody budgeted the second year's licences, the maintenance of the connectors or the hours of the person who looks after the system. When the organisation discovers that recurring cost, without the energy of the launch, the default decision is to let the pilot die quietly.

How to design a scalable pilot from the start

A scalable pilot is not a bigger or more expensive pilot. It is a pilot with different design constraints. The criteria that follow apply to almost any industrial digital initiative, from OEE monitoring to predictive maintenance:

1. Choose the case for representativeness, not for ease

Before choosing where to pilot you need an honest map of the starting point: which machines exist, which protocols they speak, which data exists and in what state, what capabilities the team has. That map is exactly what a good operational diagnosis produces: a photograph of the real conditions the scale-up will have to live in. With the map in front of you, the rule is simple: the pilot case should look like the 50th percentile of the fleet, not the 95th. If 70% of the machines are old and without native connectivity, at least one machine in the pilot must be too.

2. Budget the replica, not just the pilot

The question that organises the whole design is: how much will it cost, and how long will it take, to connect case number two, number ten and number fifty? If the answer is "the same as the first one", the pilot is not designing a platform, it is producing craftwork. A reasonable target is for each replica to cost a decreasing fraction of the original pilot, because the common layer (acquisition, data model, dashboards, alerts) is already paid for. That marginal cost of replication is the most useful scalability indicator there is, and it should be estimated in writing before starting.

3. Separate the specific from the reusable from the first commit

Every project has a case-specific part (the connector for that particular machine, the logic of that process) and a reusable part (how signals are named, where time series are stored, how alerts and users are defined). The scalable pilot keeps that boundary explicit even if it costs a little more at the start. The acid test: if tomorrow you had to connect a machine in another plant, what percentage of the work would already be done?

4. Involve IT and the future operators, not just the builders

A pilot built behind the IT department's back scales badly by definition: sooner or later it will need networking, security, backups and corporate accounts, and that toll is paid with interest when it is negotiated after the success rather than before the start. The same applies to the future operators: if the shift leader has not touched the dashboard during the pilot, he will not use it in production.

5. Define the stop criterion and the scale criterion in advance

A serious pilot has two written exits before it starts: which result justifies scaling (and at what pace, with what budget already reserved) and which result justifies stopping. The absence of both is what manufactures purgatory: without a scale criterion nobody signs off the next investment, and without a stop criterion nobody dares to cancel. The pilot hangs suspended between the two decisions nobody defined.

From isolated case to platform

Scaling does not mean repeating the pilot many times. It means changing the object: moving from solving one case to building the capability to solve cases. That capability has three layers worth distinguishing:

1. The data layer. A common way of acquiring, naming, storing and exposing plant data, independent of which use case consumes it. This is where the decisions on protocols, namespaces and data quality live. It is the most invisible layer and the one that most determines the marginal cost of each new case.
2. The application layer. The concrete use cases: downtime, energy consumption, quality, maintenance. If the data layer is well built, each new application is one more consumer, not an integration project from scratch.
3. The operating layer. The people, procedures and budget that keep everything above running: who responds when something fails, who onboards a new machine, who trains the shifts.

In the machining example, the version that did scale (two years and one reboot later) inverted the order of the first attempt: instead of starting with the dashboard, it started by defining how any machine in the group would be connected and named, including the old ones via gateways. The first use case took longer to become visible, but the second was deployed in weeks and the third reused 80% of the work. The deployment sequence stopped being a list of projects and became a transformation roadmap: an ordering of cases by value and dependencies, resting on a common base that is built only once.

There is an uncomfortable consequence of this change of object: the platform demands saying no to reasonable local requests. Every plant will want its variant, its naming, its exception. Yielding to all of them is going back to craftwork with a bigger budget. Governance of the data model (who decides what a signal is called and what it takes to add an exception) is as much part of the platform as the software.

Architecture decisions that condition scale

You do not need a sophisticated architecture to scale, but you do need a few decisions taken with scale in mind. The ones that weigh most in practice:

• Decouple acquisition from consumption. Machines publish their data once, to a common point, and applications subscribe to what they need. That is the principle behind patterns such as the unified namespace and publish-subscribe protocols such as MQTT with Sparkplug B. The alternative, point-to-point integrations between every machine and every application, grows in complexity with the square of the pieces and is the most frequent technical reason why case number ten costs the same as the first.
• Naming and context before volume. Ten well-named signals, with units, plant hierarchy (in the style of the ISA-95 levels) and documented meaning are worth more than a thousand cryptic tags. The cost of tidying the naming grows with every connected machine; doing it at the start is cheap, doing it with fifty machines running is a project in itself.
• Treat legacy machines as the central case, not the exception. In most European plants the fleet has an average age measured in decades. An architecture that only works with modern equipment carrying OPC UA as standard is an architecture for the brochure. Gateways, indirect signalling (electrical consumption, added sensors) and structured manual entry are part of the design, not of the patches.
• Security and segmentation from the pilot onwards. Connecting the shop floor to information systems opens an attack surface that frameworks such as IEC 62443 treat in detail. Retrofitting network segmentation and access control onto a growing deployment is much more expensive than inheriting them from the initial design, and with NIS2 (the EU directive that makes cyber risk a corporate governance duty) OT cybersecurity has ceased to be optional for much of industry.
• Buy, build or combine with a dependency criterion. The relevant question is not only the cost of each option, but what happens if the vendor disappears, raises prices or the internal team rotates. Open formats, exportable data and documented knowledge are the platform's insurance policy.

Organisation decisions: who operates what the pilot proved

Architecture decides the cost of scaling; the organisation decides whether the scale-up survives. Three organisational decisions make the difference:

Ownership with a name and a budget

Every production system needs an owner: someone whose job, not whose goodwill, includes keeping it alive. In mid-sized companies this is rarely a new department; it is usually an explicit role within operations or continuous improvement, with allocated hours and a recurring budget line. The warning sign is easy to spot: if the answer to "who looks after this?" is the name of the person who built it, with no formal remit, the system is one resignation or one sick leave away from dying.

A small central team with the plants as customers

The pattern that works best in multi-plant groups is a small central team that owns the platform (data layer, standards, common tools) and plants that consume it and deploy cases with central support. A central team that tries to execute everything becomes a bottleneck; plants that each go their own way recreate the isolated-pilot problem at a larger scale. The balance is maintained with clear rules about what is decided centrally and what in the plant.

Training and adoption as part of the rollout, not an annex

Every replicated case includes hours of shift training, adjustment of procedures and a period of coexistence with the previous method. Budgeting the replica without those hours is the organisational version of the mistake of budgeting the pilot without the operation. Adoption by the people who use the system every day is also the best detector of real value: a dashboard the shifts consult on their own initiative is contributing; one that only gets opened when management asks for it is not.

How to measure the transition to scale

Measuring the scale-up has a trap: activity indicators (pilots launched, machines connected, dashboards published) grow just as fast in a programme that scales as in one that accumulates demos. To tell them apart you need platform and value indicators:

Two nuances about this table. First, operating value is measured against a baseline taken before deployment; without a baseline, any improvement figure is an opinion. Second, the survival indicator is the hardest and the most honest: it forces you to look at last year's deployments and ask how many are still alive. A programme that does not dare to measure it probably already knows the answer.

Cadence matters too. Reviewing these indicators once a quarter, with the same seriousness as a financial close, turns scaling into a managed process. The review must be able to end in any of three decisions: accelerate, correct or stop a case that is not performing. A programme that never stops anything is not managing its portfolio; it is collecting it.

Frequently asked questions

Getting out of pilot purgatory starts with knowing the real starting point and ordering the cases on a common base. If you are in that situation, an operational diagnosis and a transformation roadmap are the first step. See the full approach at Captia Consulting.