Connect981 – Content Dev

RSC Topic: Manufacturing Execution Systems (MES)

How production work is routed, tracked, and controlled on the shop floor.

  • work-in-process

    Operational meaning

    Work-in-process (WIP) commonly refers to all partially completed units, assemblies, or lots that are somewhere between the release of raw materials and the completion of finished goods. It includes any product that has entered a production process but has not yet passed all required operations, tests, and verifications.

    In accounting and inventory terms, WIP is usually tracked as a distinct category from raw materials and finished goods. It may carry both material and applied labor/overhead value, depending on the costing method used.

    Use in manufacturing and regulated environments

    In industrial and regulated manufacturing environments, work-in-process typically includes:

    – Components and assemblies in fabrication, machining, or subassembly operations
    – Units in queue at work centers, test stations, or inspection points
    – Kits that have been issued from stock and are being assembled
    – Items that have been built but are waiting for required inspections, documentation, or release

    WIP is often managed and tracked in MES and ERP systems using work orders, operations, routing steps, or production orders. Traceability requirements (for example in aerospace, pharma, or medical devices) mean WIP must usually be linked to:

    – Specific orders, configurations, or serial numbers
    – Material lots, batches, or heat numbers
    – Process parameters, test results, and quality records

    Boundaries and exclusions

    Work-in-process generally includes:

    – Any item that has been formally released to production and has at least one operation started
    – Rework units that are back in process under controlled documentation

    It generally excludes:

    – Raw materials or components that have not yet been issued to a production order
    – Finished goods that have completed all required operations, tests, and documentation and are ready for shipment or stocking as sellable inventory
    – Spare parts or service parts held outside of active production

    Relation to systems and inventory control

    In integrated ERP–MES–shop floor environments, WIP is usually represented by:

    – Open production orders and their current operation/step
    – Quantities at each work center or buffer location
    – Status codes (for example, in-process, on hold, under inspection, in rework)

    Accurate WIP tracking is important for:

    – Inventory accuracy and financial valuation
    – Schedule visibility and capacity planning
    – Traceability and compliance in regulated industries

    Physical WIP (what is actually on the floor) can diverge from system WIP (what ERP/MES shows) when transactions are delayed, workarounds are used, or routing and documentation do not match real practices.

    Common confusion and alternate usage

    Two near-synonymous terms are widely used:

    – **Work-in-process (WIP)** – more common in manufacturing of discrete items and regulated production contexts
    – **Work-in-progress (WIP)** – often used interchangeably, especially in construction or project environments

    On this site, both usually refer to physical or digital product units in an intermediate, unfinished production state. This should not be confused with:

    – **Workload** or task queues for people or departments
    – **Projects-in-progress** in engineering or IT, which may be tracked as WIP in project management but are not inventory

    Site context: inventory inaccuracies and aerospace manufacturing

    In aerospace and other highly regulated manufacturing, work-in-process is a frequent source of inventory discrepancies. Typical contributors include:

    – Kits issued from ERP that are partially consumed or substituted on the floor without timely transactions
    – Assemblies moving between operations or cells without proper WIP movement or booking
    – Engineering changes that alter bills of material or routings while units are mid-process
    – Rework performed under deviation or concession that is not reflected in system WIP quantities and locations

    In this context, careful alignment between ERP, MES, and shop-floor practices is needed so that system records of WIP quantities, locations, and statuses match the actual physical items in process.

  • Manufacturing operations

    Manufacturing operations commonly refers to the end-to-end set of activities, resources, and control processes used to convert requirements into finished, shippable product. It spans how a plant plans work, moves and transforms materials, runs equipment, verifies quality, and releases product in a controlled and documented way.

    Scope and components

    In regulated industrial environments, manufacturing operations typically include:

    • Planning and scheduling: Translating demand, orders, and forecasts into production plans, detailed schedules, and capacity loading.
    • Material and information flow: Receiving, storing, staging, kitting, and issuing materials, along with the data needed to execute work.
    • Production execution: Running processes and equipment, following work instructions, capturing process parameters, and recording labor and machine usage.
    • In-process and final quality control: Inspections, tests, measurement, sampling, and review activities that verify product meets specified requirements.
    • Release and shipment: Batch or lot review, disposition decisions, documentation of compliance, and preparing product for shipment.
    • Supporting processes: Maintenance, calibration, change control, deviation handling, training, and documentation that enable consistent and compliant operation.

    These activities usually span multiple systems such as ERP, MES, LIMS, SCADA, historians, and quality systems, along with paper or hybrid records. In brownfield plants, they often involve both legacy and modern technologies that must work together to maintain traceability and control.

    Operational meaning

    Operationally, manufacturing operations defines how work is actually performed on the shop floor and how it is coordinated with planning, supply chain, and quality. Typical operational concerns include:

    • Defining routings, work centers, and standard operating procedures.
    • Ensuring accurate, timely data capture for genealogy, traceability, and investigations.
    • Coordinating maintenance and change control so that equipment and processes remain in a qualified or validated state.
    • Monitoring key performance indicators such as throughput, yield, OEE, and schedule adherence.

    Common confusion

    • Manufacturing operations vs. manufacturing process: The manufacturing process usually refers to the technical steps that transform materials into product. Manufacturing operations is broader and includes planning, control, documentation, quality activities, and supporting functions around those process steps.
    • Manufacturing operations vs. operations management: Operations management is the discipline of planning, organizing, and improving operations. Manufacturing operations describes the actual activities and system landscape being managed.

    Relation to integration and compliance

    In regulated manufacturing, manufacturing operations are expected to be traceable, documented, and consistently executed. This often drives integration between OT and IT systems, alignment with models such as ISA-95, and use of MES or related platforms to coordinate execution, records, and review.

  • Does ISO 22400 define manufacturing operations management (MOM) differently from MES?

    ISO 22400 does not create a new, conflicting definition of Manufacturing Operations Management (MOM) compared with MES. Instead, it largely follows the IEC 62264 / ISA‑95 view: MOM is a functional scope, and MES is one of the main categories of systems used to implement that scope.

    How ISO 22400 treats MOM vs MES

    ISO 22400 is a standards family focused on manufacturing KPIs (for example OEE and related metrics) and how to structure them. When it refers to MOM and related layers, it aligns with the ISA‑95 / IEC 62264 concept of a MOM level that sits between enterprise planning (ERP) and shop-floor control (SCADA, DCS, equipment controllers).

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    Within that structure:

    • MOM is the collection of business and technical functions that manage production, quality, logistics, and maintenance execution at the plant level.
    • MES is typically the primary software category that implements many MOM functions, but not the only one. LIMS, APS, maintenance systems, and custom applications can all be part of the MOM layer.

    ISO 22400 does not redefine MES itself; it assumes the widely used industry notion of MES as an execution system that carries out a subset of the broader MOM responsibilities.

    The practical difference in real plants

    In a regulated, brownfield environment, the gap between MOM scope and what your MES actually does can be significant:

    • One MES may handle electronic travelers, work-in-process tracking, and basic quality, but leave maintenance, detailed scheduling, or laboratory workflows to other systems.
    • Some sites run multiple MES-like systems by line, plant, or product family, which together fulfill MOM functions.
    • Legacy or homegrown tools (Access databases, spreadsheets, custom web apps) may carry key MOM functions that are not reflected in the vendor MES brochure.

    Seen through the ISO 22400 / ISA‑95 lens, all of these systems, integrations, and procedures form your actual MOM environment. MES is one important implementation component, not the full definition of MOM.

    Why this matters for KPIs and ISO 22400

    Because ISO 22400 is about KPIs and their relationships, its use of MOM is primarily to:

    • Clarify where KPI data should originate in the architecture (for example, MOM vs ERP vs control systems).
    • Distinguish between KPIs describing execution (MOM/MES layer) and those about higher-level planning or business performance.

    For an aerospace or other regulated operation, that means:

    • You should not assume that adopting an MES product automatically gives you a complete MOM layer as envisioned in ISO 22400.
    • KPI design and data lineage need to reflect the actual mix of MES, QMS, LIMS, PLM, maintenance, and custom tools in use.
    • Traceability, validation, and change control have to be applied across the full MOM scope, not just the MES application.

    Coexistence with existing MES and other systems

    In long-lifecycle, highly regulated plants, fully replacing MES or rebuilding the MOM layer around a single new platform is rarely straightforward. Qualification burden, integration complexity, downtime risk, and the need to maintain historical traceability often make incremental change the only viable path.

    In that context:

    • Use ISO 22400 and the MOM concept to map functions and data ownership across your existing MES, ERP, PLM, QMS, and maintenance tools.
    • Identify which MOM functions are not covered by your current MES and where KPI data is fragmented or unreliable.
    • Plan integrations and changes under formal change control and validation, focusing first on the MOM areas that most affect safety, quality, and regulatory exposure.

    This approach treats MOM as the functional blueprint and your MES as one (important) building block, consistent with how ISO 22400 and ISA‑95 use the terms.

  • digital travelers

    Digital travelers are electronic versions of traditional manufacturing job travelers or route cards. They live in MES or related execution systems and follow a part, assembly, or work order through all required operations, capturing routing, work instructions, in-process data, and signoffs in a structured, traceable form.

    What digital travelers include

    In regulated industrial and aerospace environments, a digital traveler commonly contains:

    • Work order identifiers and part or assembly numbers
    • Configured routing and required operations or work centers
    • Linked digital work instructions, drawings, and specifications
    • Process parameters and required data collection (dimensions, torque, pressure, etc.)
    • Inspection points, quality checks, and hold points (e.g., FAI, in-process inspection)
    • Electronic signatures, timestamps, and operator/inspector IDs
    • Links to materials, lots, serial numbers, and other genealogy or traceability data
    • Nonconformance, deviation, or rework records associated with the work order

    How digital travelers are used in operations

    Operationally, the digital traveler acts as the primary execution container for a work order:

    • Operators use it to see the next operation, applicable instructions, and required data entries.
    • Supervisors and planners use it to monitor status, queues, and bottlenecks across the routing.
    • Quality and compliance teams use it as a core evidence source for traceability, audits, and investigations.

    In many MES deployments, the digital traveler is the mechanism that enforces routing logic, ensures that required steps and inspections are completed in sequence, and prevents work from advancing without required data or approvals.

    Relationship to routing

    Routing defines the planned sequence of operations that a part or assembly must follow. The digital traveler applies that routing to a specific work order and records the actual execution path, including:

    • Which operations were performed, in what order, and at which resources
    • Actual times, quantities, and performance data
    • Any deviations, skips, or alternate routings used

    In this sense, routing is the plan, while the digital traveler is the live, data-bearing instance of that plan for a particular order or serial number.

    Use in regulated and aerospace manufacturing

    In aerospace, defense, and other regulated sectors, digital travelers are closely tied to requirements for traceability, device history records, and audit evidence. They often integrate with:

    • ERP systems for order creation, materials allocation, and completion reporting
    • PLM or document control systems for controlled drawings and specifications
    • QMS or NCR systems to record nonconformances and corrective actions against a specific work order

    They are commonly used to demonstrate which instructions, revisions, and inspections were in effect at the time of build for a given serial number or lot.

    Common confusion

    • Digital traveler vs. digital work instructions: A digital traveler is the container for routing, status, and records for a specific work order. Digital work instructions are the content that tells an operator how to perform an operation. A traveler often links to one or more work instruction documents.
    • Digital traveler vs. DHR or batch record: A digital traveler is focused on execution and in-process control as work is performed. A Device History Record or batch record is typically the compiled, finalized record of all relevant data after production is complete, which may draw heavily from traveler data.
    • Digital traveler vs. ERP work order: An ERP work order defines what needs to be produced and at what quantity and due date. The digital traveler manages and records how that work is executed on the shop floor.

    Tie to digital operations rollouts

    When teams implement a digital operations layer or MES in brownfield, regulated plants, digital travelers are often one of the first execution capabilities deployed. They provide a structured way to move from paper packets to controlled, traceable electronic records while reusing existing routings and gradually integrating quality and traceability requirements.

  • Equipment State

    Equipment state commonly refers to the current operating condition or status of a specific piece of equipment, asset, or line as recognized and tracked by control systems, manufacturing execution systems (MES), maintenance systems, or other monitoring tools.

    In industrial and regulated manufacturing environments, equipment states are usually represented as a defined set of codes or labels that describe what the equipment is doing at a point in time. These can be used for control logic, production tracking, quality decisions, maintenance planning, and performance metrics such as OEE.

    Typical examples of equipment states

    Exact state models vary by site, standard, or vendor, but common categories include:

    • Running / Operating: The equipment is producing or executing its intended process.
    • Idle / Waiting: The equipment is capable of running but not currently executing work (for example waiting for material, operator, or authorization).
    • Down / Faulted: The equipment cannot run due to a failure, alarm, interlock, or other fault condition.
    • Setup / Changeover: The equipment is being adjusted between products, batches, or formats.
    • Maintenance: The equipment is in planned or unplanned maintenance, cleaning, or calibration.
    • Offline / Powered down: The equipment is not available to the production system, often powered off or disconnected.
    • Hold / Locked: The equipment is prevented from use due to a quality, safety, or compliance hold or authorization requirement.

    How equipment state is used in operations

    Equipment state information is typically generated and consumed across multiple layers of industrial systems:

    • Control and OT systems: PLCs, DCS, and SCADA systems detect conditions (for example interlocks, sensor states) and set or infer the equipment state for real-time control and alarms.
    • MES and production systems: MES applications capture equipment states for scheduling, dispatching, batch execution, electronic batch records (eBR), and production event logs.
    • Maintenance and asset systems: CMMS/EAM tools may consume state data to trigger work orders, track run hours, or schedule preventive maintenance.
    • Performance monitoring: OEE and other analytics use equipment state to segment time into productive, planned, and unplanned loss categories.

    In regulated environments, equipment state can also be relevant for determining whether equipment is qualified, within calibration, or permitted for use in a specific process or lot, with related evidence recorded in quality or validation systems.

    Common confusion

    • Equipment state vs. equipment mode: “Mode” often refers to how equipment is being controlled (for example automatic, manual, local, remote). “State” typically describes what the equipment is currently doing or its availability. Some systems combine both, but they serve different purposes.
    • Equipment state vs. equipment condition: “Condition” is often used for health or degradation (for example good, worn, needs service). “State” is more about operational status at a point in time.
    • Equipment state vs. batch or process state: Batch or process state focuses on the product or procedure (for example charging, reacting, filling), while equipment state focuses on the asset itself. They are related but not identical.

    Relation to standards and models

    Industry standards and reference models often define or influence equipment state models, including:

    • Manufacturing operations models that define equipment status categories for availability and performance calculations.
    • ISA-95 style hierarchies where equipment state is part of the information exchanged between control systems and MES/ERP.
    • Vendor-specific state models in packaging, process, or discrete equipment that map into plant-wide OEE and downtime structures.

    When integrating systems, it is common to map vendor- or site-specific equipment states to a standardized set used for plant-wide reporting and compliance documentation.

  • Can MES improve inventory accuracy without replacing my existing ERP?

    Short answer

    Yes, a manufacturing execution system (MES) can improve inventory accuracy without replacing your existing ERP, but only if three things are true: the MES is integrated cleanly to ERP, operators actually use the MES as the system of record on the shop floor, and master data and processes are aligned. MES typically tightens control around real-time material consumption, WIP, and finished goods movements that ERP cannot reliably capture on its own. However, MES will not correct structural issues such as bad item masters, weak process discipline, or uncontrolled workarounds in your current environment. In regulated plants, any change to how inventory is tracked must go through proper validation, change control, and training, which often becomes the real constraint.

    How MES helps inventory accuracy in practice

    MES usually improves the *granularity* and *timeliness* of inventory movements, rather than replacing ERP’s role as the financial and planning system of record. On the shop floor, MES can enforce material issues against specific work orders, record actual consumption versus standard, and track WIP location and status in near real time. This reduces the lag and manual transcription errors inherent in paper travelers, spreadsheets, or late ERP backflushing. MES can also support serialized or lot-tracked components and finished goods, which is often crucial in aerospace and other regulated industries. When integrated correctly, these MES events update ERP inventory balances and reservations more accurately than manual postings alone.

    In practice, this connects to MES execution control when teams need to turn the answer into repeatable execution habits.

    What still stays in ERP

    Even with a strong MES, ERP typically remains the system of record for inventory valuation, MRP, and customer order management. Item masters, BOMs, routings, and costing structures usually originate in ERP (or PLM) and are consumed by MES. Physical inventory, cycle counting, and financial posting logic (e.g., GL accounts, standard cost updates) usually stay in ERP and must remain authoritative. In most brownfield environments, trying to move all inventory logic into MES and decommission it in ERP creates significant integration, validation, and audit complexity. The more realistic strategy is to let MES handle execution detail and ERP handle planning and financials, with well-defined boundaries and reconciliations.

    Dependencies and constraints that determine actual benefits

    The impact on inventory accuracy is highly dependent on data quality and process maturity, not just the MES software. If BOMs, routings, or units of measure in ERP are wrong, MES will simply record bad assumptions more precisely. If shop floor staff bypass barcoding or do bulk adjustments at the end of shifts, the theoretical accuracy of MES will not materialize. In regulated environments, master data changes, integration mappings, and new transaction flows often require documented impact assessments and re-validation. Without disciplined change control and training, you can actually introduce new discrepancies between ERP and MES inventories rather than reducing them.

    Integration and coexistence with your current ERP

    To improve inventory accuracy without replacement, the MES must coexist with ERP through stable, transparent interfaces. Typically, ERP sends work orders, BOMs, and item data to MES, while MES sends back material consumption, production completion, scrap, and sometimes WIP status. Poorly designed integrations—batch jobs with long delays, incomplete error handling, or ambiguous ownership of fields—often cause data mismatches and reconciliation headaches. In aerospace-grade contexts, integration changes are subject to the same scrutiny as system changes, which means they must be documented, version-controlled, and tested under change control. The most sustainable pattern is clear definition of which system owns which data element, how frequently it synchronizes, and how discrepancies are detected and resolved.

    Failure modes and tradeoffs to watch for

    A common failure mode is running dual entry: operators enter movements in MES but someone still posts adjustments or issues directly in ERP, causing divergence in inventory balances. Another is partial MES usage where only some lines or some materials are tracked in detail, leading to a hybrid environment that complicates reconciliation and KPIs. Over-automating backflushing without reliable scanning or equipment integration can make errors harder to detect because they look like clean, automated postings. There is also a tradeoff between strict MES enforcement (which can slow operators if workflows are poorly designed) and flexibility (which can invite workarounds that erode inventory accuracy). In regulated plants, tightening controls via MES may expose existing process weaknesses and force organizational changes that are more disruptive than the software deployment itself.

    Why replacing ERP to fix inventory is usually a bad idea

    Replacing ERP solely to address inventory accuracy issues is rarely justified in aerospace-grade or similarly regulated environments. ERP replacement triggers large-scale re-validation, retraining, data migration risk, and potential disruption to order management, finance, and compliance reporting. Long equipment and system lifecycles mean many integrations (to MES, QMS, PLM, lab systems, and custom tools) must be rebuilt and requalified, which increases downtime and risk of traceability gaps. In contrast, adding or upgrading MES to improve inventory execution can often be scoped line-by-line or plant-by-plant, with more controlled impact. Even then, you must plan for validation, regression testing of integrations, and clear migration paths for any existing shop floor data capture mechanisms. In most cases, stabilizing and extending the current ERP with a properly integrated MES is less risky than starting over.

    Practical steps to use MES to improve inventory accuracy

    In practice, improving inventory accuracy with MES starts with clarifying the target: which materials, which areas (raw, WIP, finished goods), and which error sources you are trying to reduce. From there, define a minimal but complete set of MES transactions: how operators will record issues, returns, scrap, nonconformances, and completions on each operation. Align MES transactions with ERP posting logic, then configure and validate integrations so that every MES event translates into a predictable ERP movement. Pilot on a limited scope where you can measure before/after accuracy and adjust workflows before scaling. Throughout, keep documentation, training, and change control at the same level of rigor you would apply to any system that affects traceability, batch records, or financial reporting.

  • What is ERP vs MES?

    ERP and MES are complementary, not competing, in most industrial and regulated environments. The distinction is mainly about scope and level of detail.

    What ERP does

    Enterprise Resource Planning (ERP) systems coordinate the business side of operations across the enterprise. Typical ERP responsibilities include:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • Customer orders, contracts, pricing, and invoicing
    • Master data for parts, customers, suppliers, and cost structures
    • Material Requirements Planning (MRP) and higher-level capacity planning
    • Purchasing, inventory valuation, and warehouse movements
    • Finance, general ledger, and cost accounting
    • High-level production orders and due dates

    ERP answers questions like: “What should we build, by when, for which customer, using what materials, and at what expected cost?” It rarely manages the second-by-second reality of the line or cell.

    What MES does

    Manufacturing Execution Systems (MES) operate at the plant and line level. They translate ERP-level plans into executable work, and collect detailed production and quality data. Typical MES responsibilities include:

    • Dispatching operations to specific lines, machines, or work centers
    • Sequencing and scheduling at the shift or hour level
    • Operator guidance (e.g., digital work instructions) and data collection
    • Enforcing process steps, routings, holds, and approvals
    • In-process quality checks and nonconformance capture
    • Traceability and genealogy of lots, serial numbers, and components
    • Real-time status for WIP, machines, and OEE-related metrics

    MES answers questions like: “What is happening right now on the line, what exactly was done to this unit, by whom, using which materials, tools, and parameters?”

    How ERP and MES typically work together

    In a brownfield, regulated environment, neither ERP nor MES is realistically the single system of record for everything. Coexistence and integration are the norm:

    • Order flow: ERP creates production orders based on demand and MRP, then passes them to MES for detailed scheduling and execution.
    • Execution feedback: MES reports completions, scrap, rework, and consumption back to ERP so inventory, cost, and delivery promises stay accurate.
    • Traceability: MES usually holds the fine-grained genealogy and process history, while ERP may store summary batch/lot info for commercial and logistics use.
    • Change control: Engineering changes and master data typically originate in PLM or ERP, and must be synchronized carefully into MES under formal change control.

    The quality of this integration strongly affects performance. Poorly integrated ERP/MES setups often result in duplicate data entry, mismatches in BOMs and routings, and gaps in traceability that are problematic in audits.

    Why not just use ERP instead of MES (or vice versa)?

    Vendors sometimes position ERP or MES as capable of doing “everything.” In high-complexity, regulated manufacturing, there are real constraints:

    • ERP as MES: While some ERPs offer shop floor modules, they often lack the depth needed for detailed routing control, enforcement of work instructions, parameter capture, or unit-level genealogy that regulators and customers expect.
    • MES as ERP: MES is not designed for financials, taxation, revenue recognition, or multi-plant aggregated planning. Using MES for these roles usually breaks down at scale or under audit.
    • Regulatory expectations: For aerospace, medical, defense, and similar sectors, auditors expect clear traceability, validated systems, and consistent master data. Stretching either ERP or MES far beyond its core role increases validation burden and risk.

    Full replacement strategies (for example, trying to retire ERP and do everything in MES, or forcing all shop-floor execution to happen only in ERP) often fail because:

    • Qualification and validation costs for a single mega-system become very high.
    • Downtime needed for cutover is unacceptable on critical assets.
    • Integration complexity with existing PLM, QMS, SCADA, historians, and custom tools is underestimated.
    • Traceability and change-control requirements are harder to meet in one large, frequently changing platform.

    Key tradeoffs when defining ERP vs MES boundaries

    In practice, each plant draws the line between ERP and MES slightly differently. Typical boundary decisions include:

    • Where MRP lives: Material planning usually stays in ERP, but short-horizon sequencing and dispatch often belong in MES.
    • Where WIP is tracked: ERP typically tracks WIP at coarse levels (operation or work center), while MES handles exact units, stations, and timestamps.
    • Where quality data lives: MES often stores in-process checks and equipment parameters; QMS or ERP may hold final disposition, complaints, and cost of poor quality summaries.
    • How master data is governed: BOMs and routings may be mastered in PLM or ERP, then replicated into MES. Good change control and version governance are critical to avoid divergence.

    The “right” split depends on your existing stack, data quality, validation constraints, and the cost of disturbing qualified processes.

    Implications for regulated and long-lifecycle operations

    For plants with long equipment lifecycles and strict regulation:

    • Expect to keep both ERP and MES for many years and evolve interfaces rather than replace core systems outright.
    • Any shift of functionality across the ERP/MES boundary should be treated as a controlled change, with impact assessment, re-validation where necessary, and clear migration of historical data and evidence.
    • Traceability design should assume that auditors may request cross-system evidence trails that span ERP orders, MES execution records, SCADA/historian data, and QMS cases.

    In summary, ERP plans and accounts for the business of manufacturing, while MES executes and records the physical reality on the shop floor. In real plants, they are tightly coupled systems with overlapping edges, not interchangeable platforms.

  • How does S88 work?

    S88 (ISA‑88) works as a standard way to model and execute batch processes so that processes, recipes, and equipment can be specified, automated, and changed in a controlled and reusable way. It provides a common language between operations, engineering, quality, and automation rather than a specific software product.

    Core idea: separate product logic from equipment control

    The most important way S88 works is by splitting the problem into layers:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • Product & process intent: what needs to happen to make the batch (procedures, operations, phases, parameters, limits).
    • Equipment & control: what units, valves, motors, and instruments exist and what they are capable of doing.

    This separation lets you change equipment (for example, run the same recipe on another train) without rewriting the process logic from scratch, and it improves traceability of changes. In practice, this only works if the control system, MES/batch system, and procedures are implemented and maintained to follow the S88 models.

    S88 equipment model: how the plant is structured

    S88 defines a hierarchical way to describe equipment involved in batch processing:

    • Enterprise / Site / Area: administrative and physical context (e.g., company, plant, production area). Often mapped to ERP/MES site and area definitions.
    • Process Cell: a collection of units and supporting equipment that can make one or more types of product.
    • Unit: a major processing element that performs process steps on material (e.g., reactor, blender, granulator).
    • Equipment Module: groups of equipment inside a unit that can perform specific functions (e.g., dosing module, CIP module).
    • Control Module: the lowest level, such as a valve, motor, or PID loop.

    Automation and MES/batch systems use this structure to configure recipes, allocate equipment, and capture data in a consistent way. In brownfield environments, mapping existing mixed-vendor and legacy equipment into this model often exposes naming conflicts, inconsistencies, and missing metadata that need to be resolved.

    S88 procedural model: how the batch recipe is structured

    S88 also standardizes how the procedural steps of a batch are represented:

    • Procedure: full sequence for a batch or product run.
    • Unit Procedure: part of the procedure that runs on a specific unit (e.g., charge and react in Reactor 1).
    • Operation: a logical step within a unit procedure (e.g., heat, agitate, hold).
    • Phase: the smallest executable step, typically implemented in the control system (e.g., open valve, start agitator, ramp temperature).

    In a compliant batch control system, operators start and monitor procedures and unit procedures, while the control system executes phases. This allows clear mapping between SOPs, recipes, and automation logic, which supports review, validation, impact assessment, and root cause analysis.

    Recipe types and reuse

    S88 defines several recipe categories that work together:

    • General recipe: equipment-independent description of how to make a product type.
    • Site recipe: adapts the general recipe to a specific site (constraints, materials, utilities).
    • Master recipe: site- and equipment-specific definition used as the approved template for execution.
    • Control recipe: instance created when a specific batch is scheduled and executed.

    This structure supports change control and versioning. QA and engineering can approve a master recipe, while individual control recipes capture actual parameters, deviations, holds, and operator interventions. To realize this in a regulated environment, you need recipe lifecycle governance (draft, review, approval, release) integrated with QMS and document control, and validated tools for version management.

    How S88 works in real systems

    In practice, S88 works through:

    • Model-driven configuration: batch engines (often part of DCS or MES) are configured using S88 equipment and procedural models rather than custom ad hoc code.
    • Standard naming and structures: consistent naming for units, phases, and parameters simplifies alarm management, historian use, and data integration.
    • Modular automation: phases and equipment modules are designed as reusable blocks that can be combined into different operations or recipes.
    • Integration with higher-level systems: MES, ERP, LIMS, and QMS reference S88 entities (batches, units, recipes) for genealogy, electronic batch records, and quality review.

    How cleanly this works depends heavily on existing automation architecture, vendor capabilities, historical design decisions, and how rigorously the standard is followed across projects and integrators.

    Benefits, with constraints

    When implemented with discipline, S88 can provide:

    • Consistency across lines and plants: shared models and naming reduce custom one-off logic.
    • Faster change with better impact assessment: changes can be localized to specific recipes, units, or phases and traced for validation and quality review.
    • Clearer batch records: data can be organized by batch, unit, phase, and parameter, supporting investigations and audits.
    • Reuse of engineering effort: proven modules and phases can be used across multiple products and product variants.

    However, S88 is a conceptual standard, not a turnkey solution. Achieving these benefits depends on:

    • The capabilities and configuration of your DCS/PLC/MES/batch software.
    • Consistency across integrators and automation teams.
    • Governed recipe and configuration management tied to change control.
    • Alignment with validation strategy, including documented requirements, test plans, and traceability.

    Brownfield and long-lifecycle realities

    In regulated, long-lifecycle plants, S88 adoption is rarely a clean “greenfield” exercise. Typical realities include:

    • Mixed control platforms across units and areas, with varying support for S88 constructs.
    • Legacy hard-coded batch logic embedded in PLCs that is expensive and risky to refactor.
    • Limited downtime windows, which often prevent big-bang migrations to a model-driven S88 batch engine.
    • High validation and qualification burden, which makes wholesale replacement of batch logic difficult to justify.

    Because of these constraints, full replacement of existing batch systems with a new “pure S88” stack is often not viable. Incremental approaches are more realistic, such as:

    • Standardizing naming and hierarchies to align with S88 without rewriting all logic.
    • Creating S88-style phases and equipment modules for new products or expansions, while leaving validated legacy logic in place.
    • Using S88 models in MES and electronic batch records for data organization and traceability, even if lower-level control is only partly aligned.

    Typical failure modes and tradeoffs

    S88 can fail to deliver value if:

    • It is treated as an IT or automation standard only, without involving operations, QA, and validation in the design.
    • Recipes and equipment models are implemented inconsistently across lines or integrators.
    • Version control and change management for recipes and phases are informal or fragmented across tools.
    • There is an expectation that adopting S88 alone will guarantee compliance or audit outcomes. It does not.

    The tradeoff is usually between:

    • Stricter adherence to S88 (more design effort, more initial cost, cleaner models, easier long-term maintenance), and
    • Local, tactical implementations (faster in the short term, but harder to maintain, extend, and validate consistently).

    Most regulated plants land somewhere in the middle, applying S88 where it offers clear, justifiable benefit and incrementally refactoring legacy assets as they undergo major change or revalidation.