Rolling out multi-site manufacturing software across plants goes wrong the same way every time: someone tries to switch every site over on one weekend. A good multi-site rollout is the opposite — it is boring. You bring one plant live, prove the workflow, then repeat with the config already written. The three patterns that make it boring in the right way are phased sequencing (never big-bang), shared configuration across sites, and group-level roll-up that still drills down to a single job. Get those right and the second plant takes a fraction of the effort of the first.
Why the big-bang cutover fails
The big-bang appeals to finance because it looks cheap on paper: one project, one date, done. In practice it concentrates every risk into a single window. Five plants means five sets of local quirks — different label printers, different naming for the same operation, a night shift that does things its own way — and you discover all of them at once, with production stopped.
When it goes sideways there is nowhere to fall back to. You cannot compare the new system against a plant still running the old way, because there isn’t one. Support gets flooded because every operator on every floor is a first-time user simultaneously. The rollout that was meant to save money becomes the one everybody remembers for the wrong reasons.
Phased rollout removes the single point of failure. One plant is your reference. If something breaks, four sites are still running normally and you have a working comparison to debug against.
Pattern 1: Phase the rollout, plant by plant
Pick a lead site first. The best candidate is usually a mid-complexity plant — not your simplest, because it won’t surface real problems, and not your hardest, because you don’t want to fight edge cases before the workflow is proven. You want a site that represents how most of your plants actually operate.
A sensible sequence looks like this:
- Lead site, one module. Bring up the highest-value workflow first — often production tracking at the desk, so a job logged on the floor becomes the single record everything else reads from. Prove it end to end before adding scope.
- Lead site, full scope. Layer in quality, scheduling, inventory and the boards the site actually needs. Now you have a complete, working template.
- Site two, cloned config. Stand up the next plant from the lead site’s configuration, not from a blank slate. Most of the work is already done; you are adjusting for local difference, not rebuilding.
- Remaining sites, in parallel. Once two sites run the same shape, later plants can overlap. Each one is a variation on a proven pattern.
Within each site, keep terminals kiosk-simple so operators are productive in minutes rather than needing training days. Offline-tolerant terminals matter here too — a plant with patchy Wi-Fi in the far corner of the shop shouldn’t block the phase.
Pattern 2: Multi-site manufacturing software runs on shared config, not a fork per plant
This is the pattern that decides whether multi-site becomes maintainable or a swamp. The trap is letting each plant customise its own version of the software. You end up with five forks, five upgrade paths, and no way to compare plants because none of them measure the same thing the same way.
The alternative is being configurable rather than custom. Workflows, fields, validation rules and permissions change through a settings screen — not an engineering ticket — so every plant stays on the same version of the same platform. Site two doesn’t get a bespoke build; it gets the lead site’s configuration with the handful of local differences dialled in.
Genuine local variation still gets respected:
- Shared by default: the data model, operation naming, quality standards, board definitions and the core workflow. This is what lets you compare plants at all.
- Local where it must be: shift patterns, label formats, specific line layouts, language, and which optional modules a site runs.
- Governed centrally: who can change what. With role-based access and fine-grained permission levers, a plant manager can adjust their own floor without redefining a standard that belongs to the group.
Because configuration lives in settings rather than code, quarterly platform updates land on every site at once. Nobody is stranded on an old fork. Our multi-site manufacturing platform is built around exactly this: one data model, one version, configured per plant instead of forked per plant.
Pattern 3: Group roll-up with drill-down to a single job
The point of one system across plants is that leadership finally sees the group as one operation, not a stack of monthly spreadsheets that arrive a week late and never quite reconcile.
Because every plant writes to the same data model, group metrics aggregate live. An operations leader opens a view and sees OEE, throughput, scrap and on-time delivery across all sites at once — then clicks into the worst-performing plant, then the worst line, then the specific job and the reason code the operator logged. Same numbers, one thread, no export. The roll-up and the shop-floor detail are the same data at different zoom levels.
That drill-down is what makes group dashboards trustworthy. A number you can’t trace is a number people argue with. When the group scrap figure links straight down to the NCRs behind it, the conversation moves from “is this data right?” to “what do we do about it?” Live operational dashboards that read from the floor — rather than a nightly batch — are what let a Monday review discuss what happened this morning, not last week.
Pre-built boards give every plant a common language from day one. Zero Waste for production surfaces an OEE reasons Pareto and OEE trend; Zero Defects covers defect Pareto, first-pass yield and NCR aging; Zero Harm handles safety. Because they’re defined once and shared, “OEE” means the same thing at every site — which is the whole point of measuring across plants.
What “boring” looks like in practice
A multi-site rollout done well has no dramatic weekend. It looks like this:
- One reference plant running the full workflow, proving the config before anyone else touches it.
- A shared configuration that clones to the next site in days, adjusted for local difference rather than rebuilt.
- Every plant on the same version, updated quarterly, with local variation handled in settings and governed by permissions.
- A live group view that rolls up across sites and drills down to a single job and reason code.
- No re-keying anywhere — the job logged at the desk is the record quality writes to and finance draws the invoice from.
Teams that run this pattern typically see the second site come live in a fraction of the first site’s effort, because the expensive learning already happened once. That is the quiet payoff of refusing the big-bang.
If you’re planning a rollout across plants, the shape of the sequence matters more than the tooling. Start with how a phased multi-site rollout actually unfolds — one lead site, shared config, then repeat — and the multi-site part takes care of itself.
