One company, eleven ways of doing things.
Every plant solved its own problems, and every solution worked. What you have now is a portfolio where the same capability exists in six variants, none of them wrong, and none of them talking to the others.
Manufacturing portfolios diverge by site rather than by department. A plant commissions a system because it needs one, tailors it to its own process, and runs it for fifteen years. Multiply that across a dozen facilities and several decades of acquisitions, and you get an estate where the same function — production scheduling, quality management, maintenance — exists in six incompatible forms.
None of this was a mistake. Plant-level autonomy is often exactly why those facilities run well. The cost shows up elsewhere: in the reporting layer that has to reconcile six data models, in the integration middleware nobody wants to touch, and in the licence and support fees for six vendors where one would do.
The complicating factor is that a meaningful share of these systems sit close to the plant floor. An application that looks like a reporting tool on the inventory may be the thing that tells a line when to stop. That changes the risk profile of a retirement decision completely, and it is why generic rationalization approaches tend to stall here.
You'll recognise this if
Before anything can be consolidated, you need to see the same capability across every site side by side — which plant runs what for scheduling, quality, maintenance, warehouse management and reporting, and how far each has been customised from its original state.
This map is what converts an abstract argument about standardisation into a concrete one. Two plants running the same product at the same version is a merge. Two plants running different products with fifteen years of divergent customisation is a migration project, and the difference needs to be visible before anyone commits to a target state.
The single most important thing to establish early is which applications have a dependency on operational technology — historians, SCADA, MES, line control — and which merely look like they do.
Applications on the OT side of that boundary come out of the normal rationalization flow and into a separate, slower track with plant engineering involved. Applications that turn out to be safely on the IT side, which is usually more of them than the initial assumption suggests, can be handled at normal pace. Getting this line drawn accurately is what unblocks the rest of the programme.
A migration scheduled without reference to the production calendar will eventually collide with a shutdown, a seasonal peak, or a qualification run, and the plant will win that argument every time.
We sequence changes against planned maintenance windows and site-specific constraints from the start, which usually means the technically obvious order is not the order we run in. It also means the schedule survives contact with operations, which a technically optimal one generally does not.
The consolidation business case that fails is the one built on licence arithmetic alone. Two systems at a combined $400K becoming one at $250K looks compelling until the data migration, master data reconciliation, requalification and retraining are costed.
We estimate migration effort as a distinct line before any consolidation is committed to. Some plant consolidations that look obvious on licence cost do not survive that analysis — and establishing that during planning is a considerably better outcome than establishing it halfway through a cutover.
Want the numbers for your estate?
A free 30-minute assessment: the top three savings opportunities we can see in your portfolio, and a first step you can act on.
01
Inventory across every facility, mapped to capability rather than to vendor, with customisation depth recorded per site.
02
The IT/OT boundary established with plant engineering, separating what can move at pace from what cannot.
03
A per-capability target, with migration effort priced before any consolidation is approved.
04
Site by site, sequenced against production and maintenance calendars, starting with the lowest-risk facility.
Where This Starts
Manufacturing engagements are consolidation problems more often than they are pure rationalization ones — the applications are largely justified individually, and the cost sits in running six variants of the same capability.
Platform ConsolidationNo, and treating that as the goal is a common way for these programmes to fail. The objective is to remove redundancy that costs money without buying anything — not to impose uniformity for its own sake. Some plant-level variation is genuinely justified by process, product or regulatory differences, and the analysis should establish which variation is earning its keep.
Two mechanisms. Anything with an OT dependency comes out of the standard flow and runs on a separate track with plant engineering involved. Everything else is sequenced against the production and maintenance calendar rather than against a fiscal timetable, and we start with the lowest-risk site so the approach is proven before it reaches a critical facility.
With the capability map across sites, and then with the corporate and administrative layer rather than the plant floor. Overlapping finance, HR, procurement and reporting systems from unmerged acquisitions usually hold a substantial share of the recoverable spend at a fraction of the operational risk, and finishing that layer builds the credibility needed for the harder conversations.
They are treated as a constrained tier, similar to how we handle clinical systems in healthcare. Requalification effort is costed into any change affecting them, and where the requalification cost exceeds the saving we say so rather than pushing the consolidation through.
Related Insights
More on Platform ConsolidationBook a 30-minute call. No commitment, no sales pitch — just the three biggest opportunities we can see.
Book Your Free Assessment