From paper MBR to digital recipe: the challenge is not the tablet

Almost every EBR business case opens with the same picture: the operator swaps the clipboard for a tablet. The image is useful for selling the project. It is a terrible definition of the work.

A paper batch record is a document. The master batch record (MBR) says what should happen; the BPR records what someone wrote that happened. Converting that to digital is not typography. It is changing the object of control: from text a human interprets to a flow the system can enforce, evidence and version.

Programs that stall almost always trip on that leap — not on which software brand they picked.

Challenge 1: digitizing the form as it is

Paper accumulates workarounds. An extra field “because the scale does not fit”, a signature out of order “because the pharmacist only shows up in the afternoon”, a table that mixes mental calculation with observation. On paper, that reads as improvisation. In the system, it becomes a requirement.

Digitizing the MBR 1:1 usually preserves the paper’s limitation and adds licence, validation and training. The operator gains a screen. The plant does not gain enforcement.

Useful conversion starts with an uncomfortable question: what in this form exists because the process needs it — and what exists because paper did not know how to do it differently?

Challenge 2: prose vs. structured recipe

An MBR in prose is interpreted. Two competent people read the same paragraph and disagree on what counts as out of specification. A structured recipe defines step, sequence, parameter, limit, material, calculation, signature and exception path so the system validates in the moment — not in a review two weeks later.

The distance between the two formats is the bulk of the project. It is not “putting Word into the MES”. It is modelling phases, equipment, BOM and controls so the instantiated batch is traceable to the master version that generated it.

If you cannot prove which recipe version produced that record, release has no ground when the investigation tightens.

This is the same shift already discussed in the electronic batch record: enforcement, not just removing paper.

Challenge 3: paper-on-glass disguised as EBR

There is a dangerous middle ground: free-form screen, little mandatory sequence, lots of free text, exception narrated in a paragraph. It looks modern. It keeps paper’s failure mode — error found late — and still creates the illusion that “we are already digital”.

Signals:

• the operator still calculates offline and types the result
• values the equipment already has are rewritten on the screen
• a deviation becomes a comment, not a flow with decision and status
• review still goes page by page because nobody trusts the exception rule

Paper-on-glass is the worst of both worlds: system cost with form benefit.

Challenge 4: the exception rule is regulated logic

Review by exception is only defensible if the system identifies, under predefined and controlled rules, what escalates for review — and the person reviews what was flagged. If the judgement of what is “normal” stays line by line in the reviewer’s eye, there is no review by exception: there is page-by-page review under another name.

That makes the exception rule itself part of the controlled design: a limit too wide, a swallowed flag, a loose sequence produce a “clean” record that lies about the procedure.

In conversion, teams often spend months on screen visuals and far too few hours on the logic that decides what climbs for review. That is where the programme is born fragile.

Challenge 5: paper + electronic hybrid

Running both in parallel “only for the transition” becomes habit. Two truths appear: what the plant did and what the system tells. Rework, divergence and the temptation to fix the electronic after the fact kill contemporaneity.

A short hybrid, with an exit criterion, is transition. An indefinite hybrid is a new process — worse than paper, because nobody admits it exists.

Challenge 6: validation and recipe change

The configured recipe is a high-risk artefact. A step in the wrong order, a tolerance wider than the paper MBR, an exception that swallows the flag: the system does not fail loudly. It delivers a batch that looks compliant.

That is why conversion does not end at module go-live. Every recipe change needs the same change-control rigor the paper master demanded — with the aggravating fact that configuration and interface now belong in the package. That includes the exception rule itself (limits, flags, sequence): it enters the same controlled package as Challenge 4, not as a loose configuration detail.

On platforms such as NEO EBR, the value shows up when the recipe model carries sequence, limits and version — not when the tablet merely hosts a prettier form.

What usually works (without romance)

There is no magic shortcut, but there are patterns that survive the plant:

1. Rewrite the recipe with operations in the room — not only with the SOP owner. Undocumented workaround must surface before it becomes a click.
2. Structure before beautifying — sequence, limits, materials and exceptions before the visual theme.
3. Pilot one product/area — learn the recipe model before industrialising the portfolio.
4. Connect process data early — confirm instead of transcribe, or the EBR inherits paper’s weakness.
5. Treat paper-on-glass as a stage to kill — with a date, not as a destination.

The plant digitisation roadmap (readings → higher-risk record → connection) remains valid. This text zooms into the artefact in the middle: the recipe. See also the paper-to-paperless roadmap.

Questions before declaring the conversion “done”

• Does the system block out-of-sequence steps — or only suggest?
• Are limits and calculations in the flow, or still dependent on a side spreadsheet?
• Is exception a stateful flow, or a free paragraph?
• Does each EBR point to the exact master version in force that day?
• Do critical values come from equipment/historian, or from typing?
• Does the hybrid have a kill date?

If the honest answer is “almost”, you have not converted the recipe. You converted the medium.

Converting a paper recipe to digital is worth it when the tablet stops being a metaphor and the process becomes executable: enforced in the moment, versioned, with an exception release can trust. The challenge is not the tablet. It is not carrying paper hidden inside it.

In your last MBR digitisation: did you redesign the process — or photograph the form in larger pixels?

Takeaways

• Converting a recipe is not scanning the MBR; it is moving from interpretable text to an executable, versioned flow.
• Digitizing the form 1:1 preserves paper contours and calls that EBR.
• Paper-on-glass keeps late discovery of error at system cost.
• Exception rule and master version are regulated logic — not a UX detail.
• Endless hybrid and typing what the equipment already knows kill the business case.