Challenging batch record
design in MES projects
An MES project is the best opportunity in a decade to question every step in your batch records.
Kieran Higgins
Senior MES Manager
Published 5th August 2026
ON THIS PAGE
"Because that's the way it's always been done."
The step in question was a manual transcription of equipment data into a paper logbook, done three minutes after the equipment had already recorded the same data to the historian. The transcription was then signed, witnessed, and reviewed during batch release. That had gone on for eleven years: eleven years of three-minute transcriptions, of dual signatures, and of batch records that swelled by an extra line every time the equipment ran.
When I asked who reviewed the data in the paper logbook downstream, the answer was no one. The steps original purpose had been to verify that the historian was accurately capturing data during a six-month commissioning period, and that purpose no longer existed. The step had outlived its reason, and nobody had ever removed it because nobody had ever asked.
This is what happens when batch records are designed by accretion. It is also the biggest and quietest opportunity sitting inside almost any MES implementation project.
How batch records become museums
Pharmaceutical batch records are not static documents. They accumulate steps over the life of a product, and each addition usually arrives for a sensible reason.
Consider a batch that fails an in-process check. The site investigates, identifies a gap in the verification chain, and adds a confirmatory step to close it. The step goes through change control, is signed off by quality, and every subsequent batch carries it. Three years on, the upstream equipment is replaced and the original gap no longer exists, yet the step remains in place, because removing it would mean opening a change control of its own, and there is rarely the time for that.
A regulator asks a pointed question about reconciliation during an inspection. The site responds by adding a manual reconciliation step. The auditor moves on, and the step stays. Five years later the underlying system has been replaced by one that performs the reconciliation automatically, but the manual step is still in the batch record, because nobody has tied it back to the original observation.
An experienced operator retires and takes with them a small piece of tribal knowledge about why a particular timer is set the way it is. The site, unsure whether to change anything, leaves the timer untouched. Six months later a process improvement could have reduced cycle time by 12%, but nobody knows enough about the reasoning behind the original setting to propose the change.
Multiply this across twenty years of operation, three or four ownership changes, dozens of CAPAs, and a dozen regulatory inspections, and you get what most pharma sites are running in 2026: a batch record that functions more like a museum, where each step is a small monument to a moment in history that nobody still at the site can fully recall.
The MES window
Every site we work with is sitting on years of accumulated process debt. Most know it, at least in the abstract. Few have ever been given the institutional space to do something about it.
The MES implementation is that space.
An MES project is the rare occasion at a pharma site when four conditions exist at the same time: a funded budget specifically for process and batch record work; executive sponsorship that creates top-down permission to question existing procedures; a cross-functional team (operations, quality, MSAT, automation, IT) sitting in the same room at the same time, with the same agenda; and an external partner with no political stake in the existing process design.
These conditions do not exist during normal operation. During normal operation, every proposed change is judged against the cost of executing the change, which is non-trivial in a regulated environment. The default outcome of normal operation is “leave it alone,” and that default is what causes the accretion in the first place.
The MES window inverts the default. For 4 to 12 months, depending on project scale, the default becomes “we are going to look at this.” It is the only period in a typical decade where a site can ask, with structural permission, whether a step should still exist. Once the MES goes live, that window closes for another ten to fifteen years.
Sites that recognise this end up building very different MBR design processes from sites that don’t. If you treat the MES project as a process redesign that happens to result in a digital batch record, you exit with leaner MBRs, fewer deviations, and an MES that ages well. If you treat it instead as a digital batch record project that happens to require some process discussion, you exit with a digital monument to whatever accretion was in place on the day the gap analysis began.
What process challenge actually looks like
Process challenge does not mean the consultants come in and redesign your batch records for you. It is a discipline applied to every step in every existing record, and it comes down to three questions.
Why does this step exist? This is a question about the reason, not about what the step does, which is usually obvious from the procedure. Why is it there? Whose risk does it address? Which CAPA, which inspection finding, or which historical event drove it into the batch record in the first place?
Does the reason still apply? Often it doesn’t. The equipment that drove the verification step has been replaced, the regulator that asked the question has been satisfied, and the tribal knowledge that justified the timer no longer matters because the upstream process has changed. A step whose originating reason no longer applies is, by definition, a step that has outlived its function.
If we removed this step tomorrow, what would break? This is the question that surfaces hidden dependencies. Sometimes a step looks redundant but is in fact load-bearing for some other part of the process, such as a downstream reconciliation that depends on the manual entry, or a quality review pattern that relies on the dual signature. Where there is a real dependency, the step stays; where there isn’t, it goes.
These three questions, applied without sentiment, are not glamorous, and they are not what an MES vendor will lead a sales conversation with. But they are what separates an MBR that compresses your process from one that ossifies it.
The EBR overload trap
A particular trap waits on the other side of process challenge: the temptation to use the MES’s capabilities to build something more elaborate than the process actually needs.
The fact that you can put a data field in an electronic batch record doesn’t mean you should. The MES can prompt for a verification at every step, but that doesn’t mean every step needs one. Configurable workflow lets you branch, loop, and add dynamic prompt logic, and none of that is a reason to do so unless the process calls for it.
EBRs that try to capture everything the platform supports tend to fail in two predictable ways. First, they become difficult to execute on the shop floor, with operators clicking through prompts that have no bearing on the work they’re doing. Second, they become difficult to maintain, with every minor process change requiring a disproportionate amount of EBR development effort.
The discipline of process challenge applies inside the EBR design just as much as it applies to the legacy process. The question to keep asking is not what the MES can do, but what this process actually needs the MES to do, and nothing more.
This is the part of EBR design that is hardest to discipline. The MES vendor has every incentive to show you the platform’s capabilities, and the internal team has every incentive to capture data it might one day want. The right answer is to do less, deliberately, and to revisit the design six months after go-live once real production data is available.
What to do about it
Here are three principles for a project team that wants to go into MBR design and use the MES window properly.
First, decouple the “is” from the “should.” Walk the existing process and document what is actually done today, in detail. Then, in a separate session with the same people but a different posture, ask which of those steps should still exist. Conflating the two conversations is what causes accretion in the first place.
Second, require an origin story for every retained step. If a step is going to stay in the new MBR, somebody must be able to articulate where it came from and why it still applies. Steps whose origin nobody remembers, or whose original justification has lapsed, become candidates for removal. The point here is not really removal; it is justification. The burden of proof shifts from “why should we change this?” to “why should we keep this?”, and that single inversion does more for batch record quality than any amount of MES configuration.
Third, give challenge authority to someone outside the line. The people who run the process every day are too close to it to challenge it well, quality is too close to the regulatory history, and IT and automation are too close to the systems. The challenge function needs to sit with someone, internal or external, who has no political stake in the answer. This is where an experienced MES partner earns their fee.
Eleven years of transcriptions
In the second hour of that process review I mentioned at the start, after we had walked through the manual transcription step, the operations lead and I talked through the three questions. Why does this step exist? It existed to verify the historian during commissioning. Does the reason still apply? No, the commissioning ended long ago. If we removed this step tomorrow, what would break? Nothing.
The step came out of the batch record that afternoon, and eleven years of three-minute transcriptions and dual signatures ended in a single conversation.
The site’s next batch ran eleven minutes faster than the one before it, and over the course of the year that single change recovered roughly 140 production hours. No new technology had been introduced, no equipment upgraded, and no new MES feature installed. The saving came purely from someone finally asking the question.
That is what the MES window is really for. The technology is only the occasion for the work; the work itself is the challenging of every step.
Skipping the process challenge work described here is one of the most common and most expensive ways a site can spend seven figures on an MES and end up no better off than before. In the next article in this series, we look at why roughly 70% of MES projects miss their original scope, schedule, or business case, and what the sites in the other 30% are doing differently.
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.