Work Plan in Manufacturing: Routing, Recipe & Reality

What a work plan actually is

A work plan (German: Arbeitsplan) is the executable specification of how a product is manufactured. It defines the sequence of work steps, the assigned resources, the target times, the parameter sets or recipes to load, and the inspection and release checkpoints along the way. In the MES, the work plan is the operational backbone of order execution: it is the document against which every cycle, every quality record, every OEE number and every traceability entry is anchored. Without a clean work plan, structured production control is not possible — only reactive supervision that looks like control but cannot be audited.

The vocabulary around work plans is muddled because four related but distinct concepts are routinely treated as synonyms. Separating them is the first thing that actually helps the reader.

Work plan vs. routing vs. recipe vs. BOM — four concepts, one production specification

Together these four artefacts constitute the complete production specification. The routing provides the skeleton. The work plan fills each bone with time, resource and process-logic flesh. The recipe supplies the parameter-level detail for process-oriented steps. The BOM supplies the material side. A production order without all four is incomplete — and every real-world production incident I have investigated traces back, in the end, to one of these four being either missing, outdated, or silently inconsistent with the others.

Role of the work plan in the MES

Inside the MES, the work plan governs which machine is authorised to process a given order, which recipe or parameter set must be loaded before the first cycle starts, which in-process inspections must be performed and passed, when a step is considered complete, and under what conditions the next step is released. In high-mix environments with hundreds or thousands of product variants, the MES uses the work plan to auto-select the correct version for each order based on product, variant, customer, line and regulatory classification — so that the operator on the line does not have to choose, and cannot accidentally run the wrong version.

In regulated contexts, the work plan is also the document the auditor asks for first. "Show me the work plan that was active for batch 2024-11-17-A, show me that the machine state matches it, show me the inspection records, show me the signature of the person who approved this version." If any of those evidence chains is broken, the batch is non-conforming regardless of whether the physical product is actually fine.

Work plan drift — the failure mode almost nobody names

The work plan that matters is the one that matches reality. The work plan that most plants actually have is the one that was set up some years ago and has been quietly diverging from reality ever since. This is the single most common work-plan pathology in brownfield manufacturing, and it is structurally different from the "no work plan at all" failure the glossaries focus on.

• Standard times set in the 1990s. A work plan whose target cycle time was measured on a specific machine with specific tooling and a specific product variant in 1998 — and has never been re-measured since, despite two tooling upgrades and a material change. The plan reports 62 seconds per cycle; reality is 71. Every OEE calculation using performance against this standard is systematically wrong in the same direction.
• Shadow work plans. The ERP has a work plan. The shopfloor runs a slightly different sequence that everyone on the line knows about but that was never fed back into the formal plan — because the formal change request would have taken three months. Six months later, the reported schedule and the actual schedule have diverged enough that the ERP's capacity planning is noise.
• Inspection steps that silently stopped firing. A work plan specifies an in-process inspection that requires a gauge which has been out of calibration for four months. Operators quietly skip the step. The work plan still shows it as required; the traceability record still shows it as completed; nobody has updated anything formally.
• Parameter references that point to the wrong version. The work plan references "Recipe B 2.1" but the recipe library has silently moved to 2.3 because someone retuned the process. The work plan now references a recipe version that no longer matches how the machine is actually running. Same product, same plan, different behaviour.
• Variant-specific steps that were merged or split. A variant that used to need its own work plan step has been rolled into a generic one, or vice versa, without updating the auto-selection logic in the MES. The MES now picks work plans that partially match the order, and operators compensate with manual workarounds.

A work plan management discipline that catches these drift patterns is materially more valuable than one that produces perfectly-formatted work plans on day one and leaves them to age. The single most productive meeting you can hold in a brownfield plant is a quarterly walk-through: pick five random work plans, stand at the machine with a stopwatch and an operator, and measure reality against plan. In every such walk-through I have ever conducted, at least two of the five plans were materially out of sync with how the line actually runs.

From two decades building the recipe-based work plan standard for process plants: in the early 2000s I was responsible for building the software standard that governs work plans in process-engineering plants for the beverage and wood industries. The architectural insight that took me several years and several painful production incidents to arrive at: in recipe-based process environments, the work plan and the recipe are not two separate documents that reference each other. They are a single governance object whose two halves must be version-controlled together. I saw plants — not theoretical examples, actual plants I consulted for — where the work plan was formally updated through the ERP change process while the recipe library was updated informally by the process engineer sitting next to the control system. Six months in, the work plan would reference "Syrup B, Recipe 2.1" while the control system was running Recipe 2.3. The operators could not tell. The MES could not tell. The ERP reported perfect compliance. The product quality was drifting, the scrap rate was rising, and nobody could trace the cause — because on paper everything matched. The fix we built into the software standard was boring and effective: work plans and recipes share a single versioning system, a single approval workflow, and a single audit trail. You cannot change one without the other being logged against it. Fifteen years later the plants running on that standard still have lower work-plan drift than the ones that didn't. It is not a glamorous architectural decision. It is the kind of decision that pays out quietly for twenty years.

Quality built into the plan, not inspected at the end

A well-designed work plan embeds quality as structural checkpoints inside the process rather than as a final gate at the end. Defined inspection operations with pass/fail criteria, mandatory approvals before a next step can start, parameter specifications with tolerance bands, automatic deviation detection when a measured value exits the tolerance — all of these are first-class elements of the work plan, not bolt-ons. The engineering consequence is significant: errors are prevented at the step where they originate rather than discovered hours later at final inspection, and the scrap that would have been produced between origin and discovery simply does not exist. In regulated environments this is mandatory. In unregulated environments it is where most of the return on MES investment quietly materialises.

Versioning and audit

Every substantial change to a work plan must be saved as a new revision with a timestamp, a responsible approver and an activation window. The batch produced on 2026-02-14 was produced against Work Plan WP-472-v3.2; the batch produced on 2026-03-01 was produced against WP-472-v3.3; the audit trail records which change was made, who approved it, and when it became active. This is the intersection between work plan management and Change Control. In a regulated context it is required by 21 CFR Part 11 and EU Annex 11. In a non-regulated context it is how you reconstruct what went wrong when a customer complaint arrives six months after the batch was shipped.

How this fits into the SYMESTIC platform

SYMESTIC manages work plans as versioned, approvable objects with built-in parameter and recipe references, configurable inspection checkpoints, and automatic selection logic for high-mix environments. Work plans are defined centrally and applied per resource, with the full version history retained as audit trail. For process-oriented deployments, work plans and recipe libraries share a common versioning system — the architectural principle that came out of the beverage-and-wood-industry software standard referenced above. Integration to SAP R/3 via ABAP IDoc, Microsoft Dynamics/Navision, Infor/InforCOM and proAlpha is bidirectional, so that the work plan and routing structures defined in the ERP stay synchronised with the executable version in the MES rather than drifting silently. Over 15,000 connected machines in 18 countries currently run against work plans managed on this foundation, including in GMP-regulated pharma packaging at Klocke where the work-plan-and-recipe audit trail is inspected under GMP scope.

FAQ

What is the difference between a work plan and a routing?
The routing describes the logical path a product takes through production — which operations, on which resource families, in which sequence. The work plan is the executable version of that routing with target times, setup times, parameter references, inspection steps and completion criteria filled in. Routing answers "where"; work plan answers "how". Both are required; neither replaces the other.

What is the difference between a work plan and a recipe?
The work plan governs step-level logic (sequence, resources, times, inspections). The recipe governs parameter-level detail within a given step (temperatures, pressures, ingredient ratios, tool settings). In recipe-dominated industries — food and beverage, chemicals, pharma, some plastics — the work plan typically references recipes rather than containing the parameter detail directly. The critical architectural question is whether work plans and recipes share a single versioning and approval system; if they do not, drift between them becomes near-certain within a year.

What is the difference between a work plan and a bill of materials?
The BOM specifies what materials are required to make the product — parts, components, raw materials, quantities. The work plan specifies how they are combined through which process steps on which resources. BOM and work plan together form the production specification; neither is sufficient without the other.

Can work plans be versioned, and is it required?
Yes, and in regulated environments it is required by FDA 21 CFR Part 11 and EU GMP Annex 11. In unregulated environments it is not legally required, but it is how traceability, cross-batch comparisons and reconstruction of production history actually work. A work plan without version control is a work plan that cannot be relied upon for anything beyond the current shift.

What happens if a product is run without a stored work plan?
The MES cannot enforce inspection steps, cannot load the correct parameters, cannot record which sequence was followed, cannot generate a traceability record. What gets produced may be physically correct, but it is operationally a black box. In regulated industries this is not acceptable. In unregulated industries it creates an invisible quality risk that typically surfaces months later as an unreproducible customer complaint.

How do work plans interact with high-mix production?
In high-mix environments the MES uses the work plan metadata (product, variant, customer, line, regulatory class) to auto-select the correct work plan version for each order without operator intervention. The quality of this auto-selection logic is one of the sharpest differentiators between working and non-working MES deployments — a system that silently picks partially-matching plans and lets operators improvise the rest is worse than no system at all, because it looks like it is working.

What is the single most common work-plan mistake in brownfield MES rollouts?
Importing the existing ERP work plans unchanged and assuming they match reality. They almost never do. Standard times from the last measurement campaign (often years ago), inspection steps that were added to the plan but are not actually performed, parameter references that point at a recipe library that has since moved on — all of these are near-universal in plants that have not been doing formal work plan management. The first serious work of an MES rollout is not importing the ERP data; it is walking the shopfloor and comparing plan to reality on five to ten representative products. See also machine data acquisition and dispatching for related execution-layer context.

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

About the author

Martin Brandel

MES Consultant at SYMESTIC. Over 30 years in industrial automation. Dipl.-Ing. Nachrichtentechnik. Built the SYMESTIC software standard for recipe-based process plants in the beverage and wood industries (2000–2011 as Head of Automation Engineering). Retrofit and PLC migration specialist (Simatic S5→S7/TIA). Expertise: MDE, BDE, machine connectivity, work plan and recipe management, OPC UA, IoT-gateway integration, brownfield retrofits, CE conformity. · LinkedIn