Walk into the average multi-site manufacturer today and count the transformation programmes. There is usually a security programme, tightening the defences around an increasingly connected plant floor. There is a compliance push, racing towards a certification deadline. There is a data-and-AI initiative, born of pressure from the board to "do something with AI." There is an estate-modernisation project, forced along by an ageing ERP and a looming support cut-off. And there is a supply-chain effort, trying to build resilience into a fragile web of dependencies.

Five programmes. Five owners. Five steering committees, five budgets, five timelines, five status decks in five different formats. Each one is sensible. Each was launched for good reasons. And together, quietly, they are working against one another.

This is the part of manufacturing transformation that almost no one names, because each programme looks so reasonable in isolation. But the fragmentation itself - the fact that these efforts run in parallel rather than as one - has become one of the biggest sources of cost, risk and stalled progress in the sector. The problem is not any of the programmes. The problem is that there are five of them.

The hidden cost of running them apart

Fragmentation is expensive in ways that never appear on a single business case, which is exactly why it survives scrutiny.

The most obvious cost is competition for the same scarce resources. There is one pool of skilled people who understand the estate, and one budget envelope, and five programmes drawing on both. When the compliance deadline looms, resource is pulled off security remediation to meet it. When the ERP migration hits a wall, the data initiative that was waiting on it stalls too. Each programme optimises for its own milestone, and the whole moves slower than any of its parts.

Then there is duplication. Each programme, left to itself, builds its own foundational understanding of the business. The security team maps the OT estate for its purposes. The modernisation team maps the application estate for its purposes. The data team builds its own view of where information lives. The supply-chain team charts its own dependencies. Four maps of overlapping territory, four times the effort, and four subtly different versions of the truth that will later have to be reconciled - or, more often, won't be.

And there is the deepest cost of all: no one can see the whole. When five programmes report up through five different lines, the trade-offs between them get made locally, by people who can only see their own piece. The decision that is right for the compliance programme may be wrong for the data foundation; the sequencing that suits the ERP migration may starve the security remediation of the very visibility it depends on. Nobody is doing anything wrong. There is simply no vantage point from which the right cross-programme decision could even be seen.

It is worth remembering, when a transformation disappoints, where the failure usually originates. Analysis of failed AI projects has found that the large majority of failures trace not to technical limitations but to organisational and leadership decisions. The same is true across transformation more broadly. The technology is rarely the thing that fails. The way we organise ourselves to deliver it is.

The truth underneath: they are one programme

Here is what the five programmes have in common, and it is the insight that changes everything. They all rest on the same two foundations.

The first is visibility - knowing what you actually have. You cannot secure an OT environment you cannot see. You cannot evidence compliance for assets you have not inventoried. You cannot rationalise an estate you have not mapped. You cannot build resilience into supply-chain dependencies you have never charted. Every one of these programmes begins, whether its owner acknowledges it or not, with the same question: what do we have, and where is it?

The second is a trustworthy, connected data layer - being able to use what you have. AI needs it, obviously. But so does everything else: real-time compliance evidence, cross-site operational insight, early warning across the supply base, the reporting that lets leadership make decisions at all. The connected data foundation is not the property of the AI programme. It is the shared substrate that every programme draws on.

We have made each of these arguments on its own - that visibility is the foundation of OT security, that compliance rests on evidence, that AI pilots stall on the data beneath them, that rationalisation begins with a map of the estate, and that supply-chain resilience is visibility applied to your dependencies. Set them side by side and the pattern is unmistakable. These are not five programmes that happen to be related. They are one programme, viewed through five different lenses, all standing on the same ground.

Build that ground once, and every initiative on top of it gets cheaper, faster and safer, because each can draw on a foundation the others have already paid for. Build it five times - once per programme, in five slightly incompatible ways - and you pay five times over and still end up with the gaps between them.

Sequence, don't just list

Recognising that the programmes share a foundation changes the central question of transformation. It is no longer "which programmes should we run?" - the answer to that is usually "all of them, they're all necessary." The real question is "in what order, sharing what foundation?"

This is where deadlines belong. A support cut-off, a certification date, a board's AI ambition - these are real and they matter, but their job is to inform the sequence, not to fracture it into five separate races. The mature approach sequences the work around the shared foundation and the dependencies between initiatives, letting the loudest deadline shape timing without letting it dictate a siloed sprint that undermines everything around it. Rationalising the estate frees the capacity that funds the security and AI work. Establishing visibility serves the security programme and the supply-chain programme at once. The data foundation that unblocks AI also powers the compliance evidence and the operational reporting. Sequenced well, each initiative feeds the next. Sequenced by whoever shouts loudest, they consume each other.

What an integrated roadmap actually looks like

None of this requires a grand, monolithic mega-programme - the kind that collapses under its own weight. Integration is lighter than that, and it comes down to a few deliberate choices.

There is one shared view of the estate and one data foundation, established early and drawn on by every initiative, rather than rebuilt inside each. There is one owner, or one governance structure, with genuine authority to make trade-offs between programmes - someone who can see the whole board, not just their own square. The work is sequenced by dependency and operational risk rather than by deadline noise, with each initiative deliberately designed to feed the next. And the whole thing is measured against business outcomes - uptime, resilience, decision speed, freed capacity - rather than against the completion of individual projects that may each finish perfectly while the business gains nothing.

The most common objection is practical: "we can't stop five moving programmes to reorganise them." You don't have to. Integration is not a big-bang replan that halts everything in flight. It is the act of establishing the shared foundation and the coordinating governance, and then letting the existing programmes draw on them instead of duplicating them. The programmes keep moving. They simply stop moving in isolation.

The convergence is already happening

There is a reason this matters now rather than someday. The underlying trends are converging whether the organisation chart reflects it or not. IT and operational technology have converged. Security, data and operations have converged. The boundaries these separate programmes were built to respect have already dissolved in the real world of the connected factory.

The only question is whether a manufacturer's strategy converges deliberately and in advance - or whether it is forced to converge by an incident that travels across all the boundaries the org chart pretended were still there. The businesses that will come through the next few years strongest are the ones bringing their transformation efforts together on purpose, now, while it is a planning decision rather than a crisis response.

So when the board asks how the transformation programmes are progressing, there is a better question hiding behind it: do our transformation programmes know about each other? One roadmap, one foundation, one line of sight across the whole. That is not more governance overhead layered onto an already crowded portfolio. It is the thing that finally makes the whole portfolio achievable.

At VE3, we help manufacturers turn a crowded portfolio of parallel programmes into a single, coherent roadmap - establishing the shared foundation of visibility and trustworthy data, and sequencing security, compliance, modernisation, AI and supply-chain resilience so that each initiative advances the others rather than competing with them. If your transformation is really five transformations, the most valuable thing you can do is make it one.

VE3 provides independent, diagnostic-led advisory to manufacturers and industrial operators, helping unite security, data, modernisation and AI into a single transformation roadmap on a shared foundation. Talk to us about an integrated transformation assessment.