Recipe Management in Manufacturing: Versions & Control

What recipe management actually is

Recipe management (German: Rezepturverwaltung) is the structured governance of every process parameter that defines how a specific product is manufactured: temperatures, times, pressures, mixing ratios, torques, machine programs, inspection limits, step sequences. A recipe is not an ingredient list. It is the complete digital specification of the process itself — the instructions a machine follows to turn raw materials into a finished product at a defined quality. In discrete manufacturing it is sometimes called a parameter set or a process program; in pharmaceuticals and chemicals the recipe concept is formalised by the ISA-88 / IEC 61512 batch standard; in food and beverage production it is the central quality artefact. Under every name the underlying question is the same: which exact process did we run to produce this unit, and can we prove it tomorrow?

The honest observation from more than three decades in process-adjacent industries: most organisations discover how important recipe management is only after their first serious quality incident, at which point the gap between what they thought was specified and what was actually running on the line becomes uncomfortably visible. The purpose of this article is to describe recipe management before that discovery happens rather than after.

Recipe vs. work plan vs. parameter set vs. BOM — four artefacts, one process specification

The vocabulary in this space is used interchangeably in buyer conversations and it should not be. Clarifying the four artefacts is the first thing that actually helps.

BOM and work plan define what and where. Recipe defines how. Parameter set is the actual byte-level image that ends up on the PLC or line controller. In mature environments these are four separate but version-linked objects. In less mature environments they get confused, merged or maintained in parallel without synchronisation, and the drift between them becomes the root cause of quality problems that appear mysterious only because the underlying data model is unclear.

The ISA-88 reference model for process industries

For batch-based process industries — pharmaceuticals, food and beverage, chemicals, cosmetics — the ISA-88 standard (internationally IEC 61512) provides the reference model that professional recipe management follows. It distinguishes four recipe levels: the general recipe (equipment-independent, the product specification), the site recipe (adapted to a specific plant's capabilities), the master recipe (bound to a specific process cell's equipment), and the control recipe (the concrete instance executed for a specific batch). The practical value of ISA-88 is less about its formal structure and more about the discipline it enforces: recipes live at multiple levels of abstraction, and confusing them produces exactly the kinds of deployment errors that cause quality incidents. A general recipe that gets edited as if it were a control recipe is a governance accident waiting to happen.

Why recipe management is business-critical — not just regulatory

The common framing is that recipe management matters for compliance — IATF 16949 in automotive, IFS and BRCGS in food, GMP in pharma, GxP generally. This is true but too narrow. Recipe management matters in every discrete manufacturing environment for a simpler reason: without it, the same product gets manufactured differently on different shifts, different lines and different plants, and the variance shows up as scrap, rework and customer complaints. The regulatory framing captures the documentation burden but misses the operational one.

The operational consequences of weak recipe management that I have seen repeatedly over three decades of MES work: yield variance between day and night shifts that nobody can explain until recipe audit reveals operators have been running "their" preferred settings; scrap rates that creep up by two or three percent per year because the recipe drifts and nobody has the authority or the process to rebaseline it; a plant in one country producing measurably better quality than the same product on the same equipment in another country because the corporate recipe standard was never actually enforced at site level; a new product launch that takes six months to stabilise because the development recipe was never formally transferred to production. None of these are regulatory problems. All of them are recipe management problems, and all of them cost more than a proper recipe management system over the long run.

From the STERIA years in food and beverage process control, 1992–1995: before I founded SYMESTIC in 1995 I spent three years at STERIA as department lead for industrial systems, responsible for process control and MES projects in German and European food and beverage manufacturing. This was before cloud, before MES as we now understand it, before most of what we take for granted today. But the recipe governance problem was already identical to the one I still encounter in 2026 when I walk into a new customer's plant. The pattern I saw in dairy, brewery and soft-drink production back then — and the pattern I still see today — is the quiet divergence between the paper recipe in the binder in the plant manager's office and the actual parameter set running on the control system. The paper recipe said: pasteurisation at 72°C for 15 seconds. The control system, after several rounds of informal tuning by the night-shift process engineer who had "solved a small foam issue" in the previous quarter, was running 74°C for 18 seconds. Nobody remembered the change. The paper had not been updated. Product quality was fine — for now. The audit was not fine: the batch records referenced a recipe version that did not match the actual process, and the auditor picked up the inconsistency within an hour. The lesson we took into SYMESTIC's architecture from the beginning is that recipe and control system must be two views of a single versioned object with a single change-control workflow. You cannot change one without the change being enforced on the other, and you cannot have parallel paper and digital copies that drift. This sounds obvious. It is not how most plants actually work, even in 2026. The single most productive audit of recipe management you can run in your own plant today: print the ten highest-volume recipes from your document system, walk to the line, and compare them to what the control system is actually executing. In my experience over 33 years, at least three of the ten will differ materially. That is the baseline. Whether you do anything about it is the question that separates plants that run on honest data from plants that run on comfortable assumptions.

Variant explosion — why recipe management stops scaling on paper

In modern factories the number of active recipes per plant has climbed steadily over the last twenty years. A contract food manufacturer may manage 800+ recipes for private-label customers, each with market-specific variants. An automotive Tier 1 may run hundreds of parameter sets for variant-driven welding, adhesive and coating processes. A pharma contract packager may maintain dozens of recipes per line, each with its own approval workflow. Paper-based and spreadsheet-based recipe management stops being viable somewhere between 50 and 150 active recipes; beyond that, the error rate from manual selection, outdated versions and variant confusion exceeds any productivity benefit the product mix was supposed to generate. This is the tipping point at which recipe management has to become a digital governance function rather than a document-filing function.

Recipe deployment — push to PLC vs. pull by machine

Once a recipe has been defined and approved, it has to reach the machine. Two architectural patterns dominate:

• Push-to-controller. The MES actively writes the parameter set to the PLC or line controller at order release. The machine receives exactly the approved parameters for the next order. This is clean, auditable, and works well for modern controllers with proper OPC UA or equivalent write interfaces. The weakness is that it requires machines that accept external parameter writes, which many older controllers do not.
• Pull-by-machine. The controller requests its parameter set from the MES at setup time, typically via a barcode scan of the order or product. The MES responds with the approved recipe. This is the pattern most compatible with brownfield environments and legacy controllers, and it is the default in plants where machine heterogeneity is high.

The architectural choice matters because it determines where the authoritative recipe version lives. In push-to-controller, the MES is authoritative and the controller is a consumer. In pull-by-machine, the MES is still authoritative but the controller temporarily holds a copy that may or may not get overwritten at the next load. The governance discipline in both cases is the same — the MES is the single source of recipe truth — but the mechanics of how that discipline gets enforced differ by integration pattern.

Recipe ownership — the governance question most plants avoid

The hardest question in recipe management is not technical. It is: who is allowed to change a recipe, and under what process? In most plants this question has never been answered formally, and in the absence of a formal answer, informal answers emerge that are usually wrong. Process engineering believes it owns recipes because it designs the process. Quality believes it owns recipes because it is responsible for the product. Operations believes it owns recipes because the shift supervisor has to make the line run tonight. Automation believes it owns recipes because the parameters end up on the PLC they manage. Four legitimate stakeholders, four legitimate ownership claims, four slightly different mental models of what a recipe is and who gets to change it. In the absence of a formal governance model, the loudest voice on any given day wins, and recipe drift is the predictable result.

The governance model that works in my experience: process engineering owns recipe design, quality owns recipe approval, operations owns recipe execution, and automation owns recipe deployment. None of them can act unilaterally. A recipe change requires a process-engineering proposal, a quality approval, an operations acknowledgement, and an automation deployment — all logged, all versioned, all reversible. This is tedious. It is also the mechanism by which the STERIA pattern I described above does not recur. Tedious governance is what you pay instead of expensive quality incidents, and the trade is strongly in the plant's favour.

How this fits into the SYMESTIC platform

SYMESTIC manages recipes as versioned, approval-workflow-gated objects inside the MES, with integrated linkage to work plans and parameter deployment. Recipe changes follow a configurable approval chain (process engineering → quality → operations → automation) with full audit trail, and every change generates a new immutable version — the previous version is retained permanently for batch traceability. Recipes are deployed to machines via the same OPC UA and IoT-gateway connectivity layer that handles data acquisition, so that the same integration infrastructure that captures what the machine did also controls what the machine is told to do. For brownfield environments where direct parameter writes are not possible, pull-by-machine via barcode scan is the standard deployment pattern; for modern controllers, push-to-controller at order release. Bidirectional ERP integration (SAP R/3 via ABAP IDoc, Microsoft Dynamics/Navision, Infor/InforCOM, proAlpha) ensures that recipe version information is synchronised with the order record on the ERP side, so that the batch record references the recipe version that actually ran. Over 15,000 connected machines in 18 countries currently run on this foundation, including GMP-regulated pharma packaging at Klocke where the recipe-version audit trail is inspected directly under GMP scope. The architectural principle that runs through all of it is the lesson I learned at STERIA three decades ago: one versioned object, one change-control workflow, no parallel copies allowed to drift.

FAQ

What is the difference between a recipe and a work plan?
The work plan describes the sequence of operations and resources — which steps, in which order, on which machine. The recipe defines the concrete parameters within those steps — temperatures, times, pressures, programs, inspection limits. Work plan answers "what and where"; recipe answers "how". Both are required; neither replaces the other. In well-designed MES architectures they share a common versioning and approval workflow, so that neither can drift relative to the other. See also work plan and change control.

What is ISA-88 and when does it matter?
ISA-88 (internationally IEC 61512) is the standard for batch process control, widely applied in pharmaceuticals, food and beverage, and chemicals. It defines four recipe levels — general, site, master, control — and provides the governance discipline for recipe management in batch-based process industries. For discrete manufacturing it is less directly applicable but the underlying principle (recipes live at multiple levels of abstraction and must not be confused) transfers.

How many active recipes does a typical manufacturing plant manage?
This varies by industry. Simple discrete operations run dozens. Contract food manufacturers with private-label variant diversity typically run 500–1,500 active recipes across seasons and customers. Pharma contract packagers manage dozens per line but with intensive per-recipe approval overhead. The rough threshold at which paper or spreadsheet recipe management stops being viable is somewhere between 50 and 150 recipes — beyond that, digital recipe management becomes a near-requirement.

What role does recipe management play in audits?
IATF 16949 (automotive), IFS and BRCGS (food), GMP (pharma and medical devices) all verify that production-relevant process parameters are documented, approved and changed under formal control. Recipe management is the direct evidence. If an auditor asks "which recipe version was active for batch 2025-04-17-A?" and the system cannot answer conclusively with full version history, approval signatures and deployment log, the batch record is non-conforming regardless of whether the physical product is fine.

What is the most common recipe management mistake in MES rollouts?
Treating recipes as a static document library rather than as a versioned, workflow-gated object. A document library tracks that a recipe exists. Proper recipe management tracks which version was active at which moment on which equipment, who approved it, who changed it last and what the previous version said. The second most common mistake is allowing parallel paper and digital copies of the same recipe to exist, which guarantees drift within a year.

Can recipes be developed in the MES or only imported?
Both patterns are legitimate. Many plants develop recipes in a dedicated R&D or lab environment and transfer them to the production MES via formal technology transfer. Others develop recipes directly in the MES with a "development" state that is clearly separated from "approved for production." The governance requirement is that the state transition from development to production is formally approved and logged; the mechanics of where the development happens is secondary.

Who should own recipes in the organisation?
In practice, four stakeholders have legitimate claims: process engineering (designs the recipe), quality (approves it), operations (executes it), automation (deploys it to the controller). None should have unilateral authority. The governance model that works is a four-way approval chain in which a recipe change requires process-engineering proposal, quality approval, operations acknowledgement and automation deployment — all logged. This is more cumbersome than informal ownership; it is also the mechanism by which quiet recipe drift is prevented.

Related: MES: Definition, functions & benefits · OEE: Definition, calculation & practice · MES software compared · Cloud MES vs. on-premise · Work plan · Change control · BOM explosion · Dispatching · Production control module · Process data module · Production metrics module · Food & beverage · Plastics processing · Automotive · Metal processing · For production managers · For operational excellence · For COOs & plant managers.

About the author

Uwe Kobbert

Founder and CEO of SYMESTIC GmbH (Dossenheim). Over 35 years in the manufacturing industry. Dipl.-Ing. Nachrichtentechnik/Elektronik. Career: Consultant at SAS (1989–1992, Heidelberg), Department Lead Industry at STERIA Software Partner (1992–1995) with direct responsibility for process control and MES in food and beverage manufacturing, founder and CEO of SYMESTIC since 1995. Led the platform's rebuild as cloud-native on Microsoft Azure in the mid-2010s; today the platform runs in 18 countries on four continents with 15,000+ connected machines. Nominated for the Großer Preis des Mittelstandes. Self-financed, no external investors. Expertise: Manufacturing Execution Systems, OEE, shopfloor management, cloud-native manufacturing software, Industry 4.0, Lean production, process control systems, ERP-MES integration, JIT/JIS processes, batch production, automotive, food and beverage. · LinkedIn · Großer Preis des Mittelstandes profile