Why Global MES Rollouts Rarely Get Cheaper After Site One
Why does the software get faster every year but most multi-site programmes don’t. Here’s the governance discipline that actually bends the curve.
Matthew Kelly
Global MES Business Owner
Published 10th September 2026
ON THIS PAGE
Why Global MES Rollouts Rarely Get Cheaper After Site One
A few years ago, I sat in a steering committee update for a top-twenty generics manufacturer running around fifteen production sites across Europe, the Americas and Asia. Someone had just presented the numbers that roughly seventy percent of those sites were still running paper batch records. That was the whole programme’s reason for existing. Of the other thirty per cent, several already had a validated MES in place but it wasn’t the same platform, was not configured to the same design standard, and wasn’t sharing as much as a template between them. The company had been fighting the same battle at every one of its fifteen-plus sites and losing ground each time.
That is the pattern I want to talk about, and I call it site-one thinking because it sits one level above everything else this series has covered. Max wrote about what happens when AI removes the friction that used to force a conversation about a single batch record. Kieran wrote about what happens inside a single MBR when nobody asks why a step exists. Ryan wrote about why a single MES project quietly misses its business case. All three are describing what happens once, at one site. The question I want to answer here is what happens when you have to get it right fifteen times over. In my experience, that’s increasingly the more common problem.
Site-one thinking
Ask a manufacturing IT leader what the hardest part of a global MES rollout is, and most describe a single-site problem like vendor selection or validation burden. They’re not wrong about any one site but at the level of the rollout as a whole, the real constraint is that every site gets treated as a fresh project, built from a blank page, so nothing about the tenth rollout is meaningfully easier than the first.
Site-one thinking is the default assumption, that this site’s process is unique enough to warrant its own ground-up design. It shows up as a reasonable-sounding objection in almost every design workshop I’ve sat in with sites thinking our line is different, our product’s more complex, we tried a template once and it didn’t fit. Treated as the default rather than the exception, though, it turns a global MES programme into fifteen unrelated local projects that happen to share a corporate logo.
The cost is visible once you track it. On one packaging rollout, the first site took eighteen months, designed from scratch. Once the team had a genuine template and the discipline to reuse it, the second site took nine months, the third took six. Nothing about the software changed. What changed was whether the team could build on what it had already learned, instead of doing it all over again.
Why does this site need to be different?
Kieran’s piece asked, of every step in a batch record: why does this exist, does the reason still apply, and what would we lose if we removed it? The same questions apply one level up, aimed at the site: why does this site need its own design? Is the reason inherited from a plant that’s since been upgraded, sold, or closed? What would this site actually lose if it used the standard template instead?
Most of the time, less is lost than the site expects. A template built properly is a well-designed starting point with clearly marked places where a site can deviate, provided it can explain why. A realistic target, in my experience, is around eighty per cent template reuse on straightforward processes like packaging, and above fifty per cent even on complex plasma or biologics processes. Both numbers can sound modest until you remember the alternative is zero.
The discipline that makes this work is a simple inversion of burden of proof: the default question stops being “why should this site follow the standard” and becomes “why should this site deviate from it.” That single change does more for programme-level cost and speed than any amount of vendor negotiation.
The template is not the constraint, the permission to deviate from it without justification is.
Know what MES is not for
Templates solve reuse but they don’t automatically prevent bloat. A template rolled out to fifteen sites with a kitchen-sink design is arguably worse than fifteen bespoke bad designs, because now the bloat is standardised too.
On every rollout of this kind, I keep a design principles document alongside the templates. The core principle: knowing what an MES is not for is at least as important as knowing what you want it to do. An electronic batch record is a recording tool, not an SOP, a deviation-handling system, or a control system. The first two already have a home in the quality system, the third in the wider manufacturing environment, and the moment an MBR tries to also be one of them, you get an over-engineered record that’s slower on the floor. A few companion rules follow naturally: don’t cater for non-routine manufacturing inside the standard record; keep automation interfaces light-touch; and capture only what’s critical to release the batch. Everything else belongs in a historian, not the batch record.
Max’s piece in this series explained why these principles matter more, not less, now that AI has entered MBR authoring. AI will faithfully reproduce whatever bloat already exists in the source material, because it has no way of knowing the sign-off on line 47 stopped mattering in 2019. What it removes is the friction that used to force someone to ask why a step still existed. At a single site, losing that friction is a design risk. Across a portfolio, it’s a reuse risk: an AI-accelerated design that skips governance doesn’t just bloat one batch record, it bloats the template that gets reused at every site that follows. It’s the same discipline Kieran described inside a single batch record, and the same gap Max identified in how those records get built, just playing out across an entire portfolio instead of being rediscovered one site at a time.
Governance is the product, not the software
Templates give you something to reuse but design principles keep what you’re reusing from drifting into bloat. Neither enforces itself and that’s what governance is actually for, and why reuse numbers hold up over time rather than eroding site by site.
The model that I’ve found to work, runs every site’s design through three structured workshops. The first is pure process, stripping out anything that can’t justify its existence before a screen is built. The second puts a working prototype in front of the people who’ll actually use it. The third finalises the design, with only minor tuning left. A global design reviewer checks each output against a documented checklist, with standing authority to send it back; if a site designs off-template anyway, the redesign cost sits with that site and not the rest of the programme.
However, none of this works without the right person holding the checklist. I spent time on the shop floor of a pharma company before I moved into MES, and it’s shaped how I run every design workshop since. A software engineer or IT business analyst, however capable, will usually take a design request at face value if it’s buildable. Someone who’s stood at a line and lived with an over-recorded step won’t. They’re the ones who catch the deviation nobody wrote down or the step that shouldn’t be there at all.
Governance of this kind is unglamorous and more effort than most programmes plan for. It’s also the actual product being delivered. The templates are reusable assets, and the governance is what keeps them reused rather than quietly diverging until you have fifteen variations of a document you called standard.
Verify the configuration, not the platform
One decision compounds directly with everything above. I draw a hard line between validating a platform and verifying a configuration. The underlying MES has usually already been validated by its vendor, at scale, across many other customers. Re-proving that it works at every one of fifteen sites is effort spent on a question already answered. What actually needs proving, site by site, is that this specific configuration does what this specific process needs it to do.
In practice that means a risk-based split. Anything touching a critical process parameter gets full dynamic verification, tested end to end; everything else gets a static verification, a documented read-through comparable to a paper-based review. Interfaces to automation and to ERP get the most scrutiny of all, because that’s genuinely where the site-specific risk sits.
This is the same principle Ryan named in his piece on the validation trap, applied at portfolio scale: risk-based effort, concentrated where it earns its keep, instead of spread evenly because evenness feels safer. At one site, that discipline saves weeks but across fifteen, it’s the difference between hitting four or five go-lives a year and not.
Why this matters more now
It would be easy to assume that faster authoring tools make this problem smaller. I’d argue the opposite is closer to true, for two reasons.
First, almost no large pharma or biotech manufacturer actually runs one MES globally, the typical global network runs a genuine mix of platforms. In that world, standardisation can’t mean “everyone’s on the same software.” It has to mean the same design principles, governance discipline, and verification approach, applied consistently regardless of which platform sits underneath a given site. Software convergence would be nice but it isn’t coming, and a governance model that depends on it isn’t a real strategy.
Second, the market isn’t slowing down. Pharmaceutical MES spend is forecast to grow from $2.37 billion in 2025 to $4.62 billion by 2030, a 14.3% compound annual growth rate, driven by electronic batch records, tightening data integrity expectations, and the shift toward biologics and cell and gene therapy. The programmes that treat governance as the product, not an afterthought to a software purchase, are the ones that will see the cost curve bend. To see the cost curve bend, the programme needs to trat governance as the product and not as an afterthought to a software purchase.
The pain points nobody puts in the business case
None of the governance discipline above shows up in a steering committee slide as “governance discipline.” It shows up, or fails to show up, as things a chief executive or CFO actually feels.
You can’t see site-one thinking from the boardroom: it shows up as an unexplained cost variance months after the workshop that caused it.
The business case assumes a falling cost curve that nothing enforces: without governance behind it, unit cost gets re-negotiated site by site, forever.
Validation cost is treated as fixed. It isn’t: the gap between validating a platform and verifying a configuration is worth roughly a third of programme cost.
AI makes this worse before it makes it better: faster documents mean drift happens faster and less visibly, because AI removed the very friction that used to force someone to notice.
That’s the case for governance as a board-level concern, not a project-management detail. AI’s real value to an executive isn’t faster authoring, that’s the domain Max’s piece is rightly cautious about. It’s portfolio-level visibility that was never achievable by hand: tracking template reuse across every open site, flagging drift the moment it happens, surfacing stalled projects without someone having to ask. The software was never the actual constraint in this story, the visibility was.
What actually bends the curve
Three things, in the order I’d insist on them.
First, build the template before you build the business case for site two. Fund the first site or two as deliberate template-building exercises, with reuse rate tracked as a real KPI from the outset, if nobody’s measuring it, nobody’s accountable for it, and it drifts toward zero.
Second, put challenge authority somewhere other than the site. The people closest to the process are the wrong people to decide alone, whether their site is really different enough to deviate. That authority needs to sit with a global function, with no local stake in the answer.
Third, separate “verify the configuration” from “validate the platform” as written policy, not a case-by-case call. Decide upfront what gets full dynamic testing and what gets a risk-based static review, and hold that line consistently across every site. Consistency is what makes the effort predictable and predictability is what makes a real go-live cadence achievable at all.
Fifteen sites, one fight
In my experience, a programme run this way looks something like five to six years, around twenty-five individual site projects, four or five delivered a year, average cost per project close to a third below what the same organisation was paying before adopting the model. None of that comes from better software. The MES underneath is usually the same platform it would have been under site-one thinking. What changes is whether the fight at site fifteen has to be the same fight as site one, or whether site one already won most of it on everyone else’s behalf.
That’s the real ROI question in a global MES programme, and it’s not often the one being asked at the start. Not “which system,” but “what, exactly, are we going to make sure we only ever have to solve once.”
About Pangaea Life Science Solutions
Pangaea Life Science Solutions is a Cork-based technology and consulting firm helping pharma and biotech manufacturers design, deploy, and optimise Manufacturing Execution Systems. We work with CIOs and operations leaders to convert paper batch records, modernise legacy MES platforms, and integrate AI into authoring and execution workflows without inheriting the process debt of the past.