Connect981 – Content Dev

RSC Topic: Manufacturing Execution Systems (MES)

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

  • What is MES and MOM?

    MES and MOM are closely related concepts, but they are not interchangeable. In most industrial and regulated environments, MES is treated as a specific system layer, while MOM refers to a broader set of operations management capabilities that may span several systems.

    What is MES?

    A Manufacturing Execution System (MES) is the layer between ERP and the shop floor that manages and records the execution of production in near real time. In practice, an MES typically covers some or all of the following functions:

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

    • Order dispatching and sequencing from ERP or planning systems to specific lines, cells, or machines
    • Electronic routing and enforcement of process steps (e.g., operations, resources, tools)
    • Electronic batch records or device history records, including operator sign-offs in regulated industries
    • Data collection from machines, test equipment, and operators (parameters, measurements, events)
    • In-process quality checks, holds, and nonconformance logging
    • Material tracking, work-in-process (WIP) visibility, and basic genealogy
    • OEE and basic performance metrics based on actual production events

    MES is usually a specific, named application (or closely integrated set of applications) that must be validated, integrated with existing systems, and maintained under change control. It is commonly positioned as the “system of record” for what actually happened during production.

    What is MOM?

    Manufacturing Operations Management (MOM) is a broader management discipline and capability set. It includes MES-like execution functions but also spans planning, quality, maintenance, and performance management at the operations level.

    Depending on the vendor and plant, MOM may encompass:

    • Production operations management (execution, dispatching, WIP, genealogy)
    • Quality operations management (in-process checks, SPC, deviation/CAPA integration, release workflows)
    • Maintenance operations management (basic asset status, coordination with CMMS, downtime categorization)
    • Inventory and material operations (material movements, consumption, kitting, limited warehouse functions)
    • Performance and analytics (KPIs, OEE, losses, bottleneck analysis, shift/plant dashboards)

    Some vendors brand their entire operations suite as a MOM platform, of which MES is one module. Others use “MOM” more as an architectural or process reference model (for example, based on ISA-95), even when the actual systems are a mix of MES, LIMS, QMS, CMMS, and custom tools.

    How do MES and MOM relate in real plants?

    In brownfield, regulated environments, the relationship between MES and MOM is often shaped by existing systems and constraints rather than by clean reference models:

    • MES as a subset of MOM: Many organizations treat MES as the execution subset of a broader MOM strategy. MOM capabilities may be spread across MES, QMS, LIMS, CMMS, data historians, and reporting tools.
    • Overlapping functions: Quality and maintenance functions in MES often overlap with standalone QMS and CMMS. Which system is the “source of truth” for a given function (e.g., nonconformance, calibration) must be defined explicitly.
    • Multiple MES-like systems: Plants may run several MES-like applications (line control systems, LIMS, custom shop-floor IT) that together form the effective “MOM” landscape, even if none is labeled as such.
    • ERP vs. MOM boundaries: In some implementations, ERP holds more detailed production and inventory logic, leaving MES relatively thin. In others, MES/MOM absorb more logic to keep ERP simpler. The split is rarely identical across sites.

    Why does the distinction matter in regulated, long-lifecycle environments?

    The MES vs. MOM distinction matters less as terminology and more as a way to think about responsibility, integration, and validation:

    • Scope and expectations: Labeling a project as “MES” tends to focus scope on execution and electronic records. Labeling it as “MOM” often implies broader changes to quality workflows, maintenance coordination, and performance reporting.
    • Validation and change control: In regulated contexts, MES changes can directly affect product records, electronic signatures, and traceability. Expanding MES into a full MOM platform increases validation scope and change-control overhead.
    • System coexistence: A MOM vision usually has to coexist with existing MES, QMS, PLM, LIMS, and historians. Full replacement strategies frequently stall due to qualification burden, downtime risk, and integration debt. Incremental integration and clear system-of-record choices are usually safer.
    • Traceability and genealogy: Deciding where genealogy, batch history, and device history records are mastered (MES vs. other MOM components) impacts auditability, data integrity controls, and cross-system reconciliation efforts.

    What should a practitioner focus on when hearing “MES” vs. “MOM”?

    When these terms come up in projects or vendor discussions, it is useful to clarify:

    • Which concrete functions are in scope (e.g., EBR/DHR, routing control, in-process quality, OEE, maintenance, material management)
    • Which systems are intended as system of record for each function, given existing ERP, QMS, LIMS, CMMS, PLM, and historians
    • How validation, change control, and audit trails will be managed across these systems
    • What the migration or coexistence path looks like, recognizing that wholesale replacement of legacy MES or QMS is often infeasible in one step

    In summary, MES is typically the execution-focused system layer on the shop floor, while MOM is a broader operations management scope that may involve multiple systems. The exact boundary between them depends heavily on plant history, vendor choices, and regulatory constraints, so definitions should always be tied back to specific functions, data ownership, and system responsibilities.

  • Aircraft on Ground (AOG)

    Aircraft on Ground (AOG) commonly refers to a condition where an aircraft is unable to fly or return to service because of an unscheduled technical, maintenance, inspection, or parts-related issue that must be resolved first.

    In aerospace operations, AOG is both an operational status and a priority condition. It is used to signal that restoring the aircraft to an airworthy, serviceable state has become urgent, often triggering expedited maintenance activity, parts sourcing, logistics coordination, engineering review, documentation updates, and approval workflows.

    The term includes situations such as unexpected component failure, missing or delayed replacement parts, inspection findings, damage, or unresolved maintenance actions that prevent dispatch. It does not usually refer to routine planned downtime, scheduled heavy maintenance, or normal aircraft parking unless those situations have escalated into an unscheduled inability to return the aircraft to operation.

    How the term is used in operations

    AOG often appears in MRO, fleet maintenance, supply chain, and manufacturing support workflows as a high-priority event. Organizations may use the term to classify:

    • an aircraft currently grounded
    • an urgent maintenance work order or service request
    • a critical parts shortage tied to a grounded aircraft
    • an expedited logistics or supplier response
    • a priority escalation across maintenance, planning, and procurement teams

    For example, an ERP, MES, or MRO system may flag an order as AOG when a required serialized part, repair action, or release record is blocking return to service.

    Common confusion

    AOG is often confused with general downtime or backlog. The difference is urgency and operational consequence. A machine outage in a factory is not usually called AOG unless the term is being used informally by analogy. In aviation, AOG specifically relates to an aircraft that is grounded or at immediate risk of being grounded.

    AOG can also refer to the urgent response process around the event, not only the grounded condition itself. For example, teams may say they are handling an AOG shipment or an AOG order, meaning the shipment or order supports a grounded aircraft.

    Manufacturing and supply chain relevance

    In regulated aerospace environments, AOG events often expose dependencies across maintenance records, part traceability, inventory accuracy, supplier responsiveness, and document control. Because the issue is time-sensitive, organizations commonly need fast visibility into part availability, configuration, lineage, open nonconformances, and current work status across connected systems.

  • What is the ISA-95 hierarchy of plants?

    ISA-95 does not define a hierarchy of plants as a corporate org chart. Instead, it provides two related but distinct structures:

    • a functional hierarchy of control and information levels (Levels 0 to 4), and
    • a physical & organizational breakdown of manufacturing locations and equipment (enterprise, site, area, etc.).

    1. ISA-95 functional levels (0 to 4)

    These levels describe what types of functions and systems operate where, not who reports to whom:

    In practice, this connects to a connected execution platform when teams need to turn the answer into repeatable execution habits.

    1. Level 0 – Process
      Physical production process and material transformation (machines, utilities, operators interacting with equipment).
    2. Level 1 – Basic Control
      Real-time control of equipment and processes (PLCs, DCS, motion control, basic interlocks).
    3. Level 2 – Monitoring & Supervisory Control
      Supervisory control and visualization (SCADA, HMIs, historian data collection, alarm management).
    4. Level 3 – Manufacturing Operations Management
      Execution and coordination of production at the plant / site level (MES, LIMS, WMS, detailed scheduling, batch management, electronic records).
    5. Level 4 – Business Planning & Logistics
      Enterprise-level planning and logistics (ERP, APS, supply chain planning, order management, financials).

    This stack is often drawn as a hierarchy, but it is really a functional separation of concerns and interfaces between real-time control and enterprise systems.

    2. ISA-95 physical and organizational model (plant-related hierarchy)

    Within this functional context, ISA-95 defines a physical & organizational breakdown of production. The most plant-relevant part is:

    • Enterprise: The overall company or corporation.
    • Site: A geographically distinct location (often what people informally call a “plant” or “factory”). One enterprise usually has multiple sites.
    • Area: A logical or physical subdivision within a site (e.g., machining hall, assembly area, mixing area, cleanroom block).
    • Production line / process cell: A coordinated set of equipment used to produce a specific product or product family.
      • Production line is more typical in discrete/assembly manufacturing.
      • Process cell is more typical in batch/continuous processes.
    • Unit: A major processing or production unit operation (e.g., reactor, filler, paint booth, CNC cell, test cell).
    • Equipment module: A functional grouping of equipment within a unit that executes specific operations (e.g., dosing skid, robot + vision cell, clamp and torque station).
    • Control module: The smallest control-level elements (e.g., a valve, pump, actuator, drive, sensor group) that can be commanded individually.

    This structure is used to model where manufacturing happens and how equipment is organized, not to dictate reporting lines or business ownership. A large regulated company may call each site a “plant” and group several sites under one enterprise.

    3. How this relates to “hierarchy of plants” in practice

    In many organizations, people use “plant hierarchy” loosely to mean a mix of:

    • Enterprise > Region > Site > Area > Line / Cell
    • ERP organizational structure (company code, plant, storage location)
    • CMMS asset hierarchy
    • MES equipment and location model

    ISA-95 can provide a common reference, but it does not prescribe a corporate hierarchy of plants. Instead, it provides consistent levels and object types so that ERP, MES, QMS, PLM, and automation systems can map to a shared model.

    4. Brownfield and regulated environment considerations

    In regulated, long-lifecycle environments, the ISA-95 model usually has to be layered on top of existing structures rather than imposed from scratch:

    • Legacy definitions of “plant” and “site” in ERP and regulatory filings may not match ISA-95 terms exactly. Changing them can affect validated processes, product registrations, and audit trails.
    • MES and SCADA often already have their own equipment models. Aligning them to the ISA-95 structure typically requires careful mapping, not wholesale replacement.
    • Validation and change control limit how aggressively you can restructure the hierarchy. Even a “naming alignment” may be a controlled change in GxP or aerospace environments.
    • Integration debt (custom interfaces, point-to-point data flows) may rely on existing plant codes, line IDs, and area names, which complicates cleanup or standardization.

    Because of these realities, full replacement of your existing plant and equipment hierarchies with a “pure” ISA-95 model often fails or stalls, largely due to:

    • qualification and validation burden for reconfigured MES/ERP structures,
    • downtime required to migrate and verify data and interfaces,
    • complexity of reconciling multiple legacy hierarchies across sites and vendors, and
    • traceability risks if historical records must be re-keyed or remapped.

    A more practical strategy is typically to map existing plant/site/area/line concepts to ISA-95 objects and use those mappings in integration and master data management, rather than attempting a single big-bang hierarchy replacement.

    5. Key takeaways

    • ISA-95 defines functional levels (0–4) and a physical & organizational hierarchy (enterprise, site, area, line/cell, unit, equipment module, control module).
    • It does not define a corporate reporting hierarchy or guarantee that your “plant” concept matches a single ISA-95 level.
    • In brownfield, regulated environments, treat ISA-95 as a reference model for mapping rather than a mandate to redesign your entire plant hierarchy.

  • Production Control

    Production control commonly refers to the coordinated set of activities and systems used to plan, release, monitor, and adjust manufacturing work so that it meets required schedule, quantity, quality, and compliance targets.

    What production control includes

    In industrial and regulated manufacturing environments, production control typically covers:

    • Translating plans into executable work, such as turning production plans or MRP outputs into work orders, shop orders, or batches.
    • Scheduling and dispatching work to specific lines, machines, cells, or operators based on priorities, capacity, and constraints.
    • Releasing and staging orders, materials, tools, and documentation (including approved work instructions and specifications).
    • Monitoring execution of work-in-process (WIP), tracking status, yields, deviations, and bottlenecks.
    • Adjusting the schedule in response to unplanned events such as equipment downtime, material shortages, or quality issues.
    • Coordinating with quality and compliance processes, including required approvals, revision control for instructions, and traceability requirements.

    Operationally, production control is often implemented through a combination of ERP/MRP systems, Manufacturing Execution Systems (MES), and planning or scheduling tools, plus defined procedures and roles (for example, planners, schedulers, or production control coordinators).

    How production control shows up in workflows

    In day-to-day plant operations, production control may involve:

    • Generating and approving work orders or batch records in ERP/MRP, then dispatching them via MES or another system.
    • Ensuring the correct, current revisions of work instructions and specifications are available at the point of use.
    • Sequencing jobs on shared resources to align with due dates, changeover constraints, and regulatory or customer priorities.
    • Tracking order status and WIP, and communicating changes to operations, maintenance, quality, and supply chain teams.

    Relationship to planning and scheduling

    Production control is closely related to, but distinct from, other planning activities:

    • Planning and MRP focus on what to make and when, at an aggregate level (demand, capacity, material requirements).
    • Production control focuses on converting those plans into executable shop-floor work and keeping it on track.
    • Detailed scheduling (finite scheduling, dispatching) is often considered part of production control or tightly integrated with it.

    Common confusion

    • Production planning vs. production control: Planning is about designing future production (forecasts, master schedules, MRP). Production control manages execution and adjustment of actual work orders on the shop floor.
    • Shop floor control vs. production control: Shop floor control usually emphasizes tracking WIP and operations status. Production control is often broader, spanning order release, scheduling, and coordination with planning and quality.

    Link to the work order process

    In many plants, production control functions are responsible for generating, releasing, or dispatching work orders. Work orders may originate in ERP or MRP, be routed through MES for execution, and must follow formal approval and change processes in regulated environments. Production control ensures that only approved, correctly revised orders and instructions reach the shop floor and that order progress is monitored and updated.

  • How does MES improve decision-making speed?

    A Manufacturing Execution System (MES) improves decision-making speed by shortening the time between something happening on the shop floor, someone noticing it, understanding its impact, and responding in a controlled way. In regulated environments, this is less about “real-time magic” and more about reliably surfacing the right signals early enough that qualified people can act without bypassing procedures. The net effect is fewer delays caused by missing data, conflicting numbers, and unclear ownership, provided the MES is correctly integrated, validated where required, and consistently used.

    Real-time visibility instead of delayed reports

    MES can collect data directly from machines, operators, and sensors so teams see near real-time throughput, downtime, scrap, and WIP instead of waiting for end-of-shift or end-of-day summaries. This reduces the lag between an issue occurring and being visible to production, quality, and maintenance, especially where paper logs or manual spreadsheets are still common. Automated calculation of metrics such as OEE, cycle times, and yield means engineers and supervisors spend less time reconciling and validating basic numbers before they can decide. In brownfield plants, the benefit is constrained by what is actually integrated: old equipment, partially connected cells, or manually entered data will still introduce delays and potential errors.

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

    Structured alerts and escalation paths

    MES can trigger automatic alerts when parameters drift out of spec, a line stops, or a critical order falls behind, rather than relying on someone to notice and send an email or make a call. Predefined workflows route issues to the appropriate role (maintenance, quality, production lead) with clear ownership, reducing the idle time caused by ambiguity over who should act. Escalation rules can enforce time-based handoffs (for example, if an issue is not addressed within a defined window, it is raised to the next level), which speeds up attention to high-risk events. However, poorly tuned thresholds or generic escalation rules can generate noise, leading users to ignore alerts and slowing real decisions, so regular review and change control on these configurations are critical.

    Standardized data for faster analysis

    By centralizing production, quality, and performance data, MES reduces the need to merge spreadsheets, machine printouts, and paper logs before deciding what to do. Shared definitions (for example, what counts as downtime, scrap, or rework) reduce time lost debating the numbers and allow cross-functional teams to converge on actions faster. Standard reports and dashboards give everyone the same view of the situation, which is particularly important when operations, quality, and engineering are dispersed across shifts or sites. These advantages depend on strong master data, alignment with ERP and QMS, and disciplined governance; if different systems define key metrics differently, MES can actually prolong discussions instead of shortening them.

    Integrated quality, traceability, and impact assessment

    When in-line checks and SPC rules are configured in MES, quality drift can be highlighted early, enabling earlier interventions instead of waiting for final inspection or customer complaints. Linked genealogy, process parameters, operator actions, and test results allow teams to narrow potential root causes more quickly when defects, escapes, or deviations appear. This can significantly shorten the time between detecting a quality problem and scoping its impact (for example, which lots, orders, or customers are affected), which is a major driver of decision speed in regulated environments. The actual benefit relies on consistent data capture at the point of use and on robust interfaces with QMS and LIMS; gaps or manual workarounds can slow investigations despite having an MES.

    Guided responses and decision support

    MES can embed predefined responses, checklists, and standard work for common issues such as recurring equipment faults, material nonconformances, or minor deviations. This reduces the time teams spend figuring out what to do from scratch and supports more consistent, auditable actions without shortcutting required approvals. Dashboards that highlight bottlenecks, at-risk orders, and constrained resources help leaders prioritize where to intervene first rather than reacting to the loudest issue. In heavily regulated or aerospace-grade contexts, these workflows still need to align with validated procedures and change control; speeding decisions must not come at the expense of traceability or documented rationale.

    Risks, limits, and dependency on implementation quality

    More data does not automatically mean faster or better decisions; without focused dashboards, filters, and clear roles, MES can overwhelm users and slow them down. Misconfigured alerts, thresholds, or routing rules can drive quick but poor decisions or large numbers of nuisance alarms that users learn to ignore. If operators and supervisors do not trust the MES, or if informal channels (radio calls, side spreadsheets, paper notes) remain the primary source of truth, decision speed will still depend on those slower, fragmented methods. In legacy, mixed-vendor environments, incomplete integration and long equipment lifecycles mean some processes will always be partially manual, so realistic expectations are that MES will speed up many decisions, not all of them.

    What ultimately determines the speed gains

    In practice, the improvement in decision-making speed from MES depends less on the software brand and more on configuration quality, integration depth, data discipline, and user adoption. Plants that invest in clear governance for metrics, thresholds, and workflows, and that keep these aligned with validated procedures, see faster and more consistent decision cycles. Those that treat MES as a passive data repository or attempt a big-bang replacement of multiple legacy systems without managing qualification, validation, and downtime risks often struggle to realize speed gains. Over time, incremental integration and carefully managed change, rather than wholesale system replacement, tend to deliver more sustainable improvements in how quickly and confidently decisions can be made.

  • What gaps do aerospace manufacturers most commonly encounter when relying on ERP alone?

    ERP is central for finance, contracts, and high-level planning in aerospace, but it is not designed to be a full manufacturing execution, quality, or compliance system. When plants lean on ERP alone, the recurring gaps tend to fall into several categories.

    1. Execution control and digital traveler gaps

    Most ERPs can define routings and operations, but they typically lack the depth needed for regulated aerospace execution on the shopfloor:

    In practice, this connects to materials planning and erp integration when teams need to turn the answer into repeatable execution habits.

    • Limited digital travelers and routing detail: ERP work orders rarely manage step-level signoffs, in-process checks, hold points, or special process controls with the granularity auditors expect.
    • Weak enforcement of operation sequence: ERP might show the route, but cannot reliably prevent out-of-sequence work, skipped steps, or unapproved rework paths.
    • Minimal real-time WIP visibility: Status updates are often manual, delayed, or batched, so supervisors and program managers lack true current-state visibility.
    • Rework and deviation handling: Ad hoc, paper, or spreadsheet processes are used for rework paths, concessions, and deviations, which are hard to trace back through ERP alone.

    These limitations often push plants to paper travelers, shadow databases, or custom add-ons, all of which increase validation and maintenance overhead.

    2. AS9100 / AS9102 evidence and audit-readiness gaps

    ERP typically supports document storage and basic quality modules, but common gaps appear for aerospace-grade compliance:

    • First Article Inspection (AS9102) integration: ERP rarely manages characteristic-level FAI plans, ballooning, measurement records, and change-driven FAI triggers in a controlled manner.
    • Process audit and LPA evidence: Layered process audits and internal process audits are often run outside ERP (forms, spreadsheets, point tools), with weak linkage back to product, part numbers, and work orders.
    • Traceable signoffs: ERP electronic signoff, if present, often lacks robust user attribution, reasons codes, and time-stamped trails across every operation and inspection step.
    • Fast, targeted evidence retrieval: During an AS9100 or customer audit, assembling a complete evidence package from ERP alone (traveler, WI version, training, cal certs, NCRs) is slow and often incomplete.

    These gaps do not mean ERP cannot contribute to compliance, but they do mean additional systems or customizations are typically required to be genuinely audit-ready.

    3. Traceability, genealogy, and configuration control gaps

    Aerospace programs demand fine-grained traceability that often exceeds native ERP capabilities:

    • Serial/lot genealogy across complex assemblies: ERP can track lots and serials, but managing multi-level as-built structures with all associated process data is usually cumbersome or incomplete.
    • Configuration-controlled as-built: Linking each unit to the exact drawing revision, model, and spec set applied at the time of build is rarely well-governed inside ERP.
    • Linkage to process conditions: ERP typically does not capture machine, tooling, program revision, test parameters, or operator details in a way that forms a usable digital as-built record.
    • Rapid recall or escape response: When a defect or escape is detected, isolating affected units based on full genealogy (material lots, operators, machines, programs, external processors) is difficult using ERP alone.

    As a result, many aerospace manufacturers rely on MES, custom databases, or manual logs to achieve acceptable levels of traceability and genealogy.

    4. Quality, NCR, and MRB workflow gaps

    ERP often has quality modules, but they are generally designed around transactional posting more than detailed quality execution:

    • NCR workflow complexity: MRB reviews, dispositions, rework routes, concessions, and customer approvals are frequently handled outside ERP due to workflow rigidity and limited configurability.
    • Linking NCRs to as-built context: Tying a nonconformance to specific operations, tools, machines, WIs, or operators is rarely seamless in ERP.
    • Root cause and CAPA follow-through: 8D, RCCA, and CAPA are often run in dedicated QMS tools or spreadsheets, detached from ERP work orders and travelers.
    • Real-time inspection data: Characteristic-level measurements, SPC, and gage data are usually captured in separate systems or on paper and then summarized, if at all, into ERP.

    This fragmentation makes holistic quality analysis and closed-loop improvement harder, and it increases risk during customer and regulatory reviews.

    5. Digital work instructions and training record gaps

    ERP document modules generally do not provide operator-friendly execution guidance or complete training traceability:

    • Contextual, step-level work instructions: Operators often access static PDFs or paper printed from ERP, without interactive guidance, conditional logic, or embedded media.
    • Version control at the operation level: ERP may store document versions, but it often cannot enforce that the correct WI revision is presented and acknowledged at each specific operation.
    • Training and qualification linkage: Proving that a specific operator was trained and qualified on the exact revision of a WI or spec at the time of work is typically handled in HR or LMS tools, not ERP.
    • Change-impact analysis: When a WI, spec, or model changes, ERP alone rarely supports impact assessment across open work orders, in-process units, and operator training requirements.

    In aerospace, these gaps directly affect auditability and can drive conservative, paper-heavy processes to manage risk.

    6. Real-time operations performance and constraint visibility gaps

    ERP reports on costs, deliveries, and high-level performance, but it is weak at real-time operational diagnostics:

    • No native machine connectivity: Downtime reasons, OEE, NPT, scrap by cause, and work-center bottlenecks often require separate data collection or MES.
    • Limited view of in-shift performance: Supervisors lack live dashboards of execution status, queue times, and capacity constraints at the operation level.
    • Root-cause visibility: ERP usually aggregates data at too high a level, obscuring patterns linked to specific operations, tools, programs, or suppliers.

    This pushes plants to spreadsheets and standalone tools, which are hard to maintain and validate, especially across multiple programs and sites.

    7. Supplier and outside processing orchestration gaps

    ERP covers purchase orders and receipts, but it often underperforms in orchestrating critical aerospace supplier workflows:

    • Outside processing visibility: ERP can show that parts are at an outside processor but not easily expose operation-level status, certifications in progress, or constraints by special process.
    • Data and cert collection: CoCs, special process certs, FAI reports, and inspection data from suppliers usually live in email, portals, or shared drives, not tightly linked and searchable through ERP.
    • Multi-tier risk visibility: ERP rarely provides insight beyond direct suppliers, limiting proactive risk management for critical parts and special processes.

    These constraints show up acutely when customers or regulators ask for end-to-end traceability across the supply chain.

    8. Brownfield reality and why “ERP-only” strategies struggle

    In most aerospace environments, ERP must coexist with legacy MES, PLM, QMS, and plant-floor systems. Full replacement or “ERP does everything” strategies often stall or underperform due to:

    • Qualification and validation burden: Extending ERP into deep execution, quality, and compliance functions requires extensive validation and change control, especially for already-certified operations.
    • Downtime and rollout risk: Retrofitting ERP into every execution workflow across mixed equipment and facilities can introduce unacceptable downtime and disruption.
    • Integration complexity: PLM, QMS, machine data, and supplier portals must still integrate. Simplifying to a single ERP often just moves, not removes, integration challenges.
    • Long equipment and program lifecycles: Many existing tools are tied to qualified processes, customer approvals, or long-term contracts, making wholesale replacement with ERP functions risky.

    For these reasons, many aerospace manufacturers keep ERP as the system of record for planning and finance, while relying on complementary MES, QMS, PLM, and execution tools for the detailed, regulated workflows ERP is not built to handle.

    Practical implication

    Relying on ERP alone in aerospace is typically feasible only for smaller scopes or less-regulated work. For complex programs and certified production, most plants end up layering validated execution, quality, and traceability capabilities around ERP rather than expecting ERP itself to close all operational gaps.

  • Level 3

    Level 3 commonly refers to the manufacturing operations management layer in the ISA-95 / Purdue reference models. It sits between enterprise business systems (Level 4) and process/control systems (Level 2) and focuses on coordinating, tracking, and optimizing day-to-day production.

    What Level 3 includes

    In an ISA-95 style architecture, Level 3 typically covers systems and functions such as:

    • Manufacturing Execution Systems (MES) and Operations Management
    • Detailed production scheduling and dispatching of work to lines or cells
    • Production tracking, work-in-process management, and order status
    • Quality data collection, in-process checks, and nonconformance logging
    • Material consumption, inventory status on the shop floor, and genealogy
    • Maintenance execution records and equipment status reporting
    • Performance monitoring, including OEE and other operational KPIs

    Level 3 is typically implemented by one or more software systems (for example MES, LIMS, maintenance systems, or custom operations applications) that:

    • Exchange order, recipe, and master data with ERP and planning systems at Level 4
    • Send instructions and receive events, measurements, and alarms from Level 2 control systems
    • Maintain operational records that support traceability, investigations, and audits in regulated environments

    What Level 3 does not cover

    Level 3 does not usually include:

    • Enterprise resource planning, long-term planning, or financial processes (these are Level 4)
    • Real-time control, interlocks, or direct actuation of equipment (these are Level 1 and Level 2)
    • Field instruments and sensors themselves (these are Level 0)

    Operational meaning in industrial environments

    In day-to-day operations, Level 3 is where production supervisors, planners, and quality or maintenance personnel interact with systems to:

    • Release and manage work orders to specific machines or lines
    • Record execution data such as batch steps, operator actions, or test results
    • Monitor current status of equipment, orders, and constraints on the shop floor
    • Generate reports used for compliance, deviation analysis, and continuous improvement

    In regulated manufacturing, Level 3 records often provide key evidence for traceability, product genealogy, and adherence to defined procedures.

    Common confusion

    • Level 3 vs. MES: MES is a common example of a Level 3 system, but Level 3 is a conceptual layer. A site can have multiple applications collectively fulfilling Level 3 functions.
    • Level 3 vs. Level 2 (SCADA / DCS / PLC): Level 2 focuses on control and supervision of equipment in real or near-real time. Level 3 focuses on managing and recording production workflows and resources over longer time horizons (minutes to days).
    • Level 3 vs. Level 4 (ERP): Level 4 handles business planning, order management, and financial aspects. Level 3 turns those plans into executable shop-floor activities and returns actual production data.

    Relationship to ISA-95 context

    Within the ISA-95 standard, Level 3 is part of the model used to define clear interfaces between business systems such as ERP (Level 4) and manufacturing operations and control systems (Levels 0 to 2). Defining what belongs to Level 3 helps structure data models, responsibilities, and integration points in complex industrial plants.

  • mass balance

    Mass balance is a quantitative accounting of all material entering, leaving, generated within, and accumulating in a defined system, to verify that total mass is conserved over a given period or process step.

    Core concept

    In industrial and manufacturing contexts, a mass balance typically:

    • Defines a system boundary, such as a unit operation, line, or entire plant.
    • Identifies all material inputs (raw materials, intermediates, utilities where applicable) and outputs (products, byproducts, waste, emissions).
    • Accounts for internal generation or consumption of species through reactions or transformations.
    • Considers accumulation or inventory change inside the system (e.g., tank levels, WIP changes).

    The general relationship is often expressed as: input + generation − output − consumption = accumulation.

    Use in manufacturing and regulated environments

    Mass balance is commonly used to:

    • Check that production and consumption records are consistent (for example, raw material issued vs. finished goods and waste recorded in MES or ERP).
    • Support yield calculations, loss tracking, and variance analysis across batches, campaigns, or continuous runs.
    • Provide evidence that material movements are traceable and plausible, supporting data integrity and reconciliation in regulated manufacturing.
    • Model and design processes, for example in process engineering, scale-up, or capacity planning.

    Operationally, mass balance may be implemented as automated checks in MES, data historians, or reporting tools, or as periodic engineering calculations based on production and quality data.

    Relation to MOM and system integration

    Within Manufacturing Operations Management (MOM) and integrated MES/ERP environments, mass balance checks can be configured as rules or validations. For example, a MOM “rule” might verify that, for a given batch or order, the sum of all recorded outputs and losses is consistent with the issued materials within predefined tolerances. Such rules depend on clearly defined procedures, data sources, and system boundaries.

    What mass balance is not

    • It is not limited to chemical reactions; it applies to any material flow where mass is conserved, including discrete, hybrid, and process manufacturing.
    • It is not the same as energy balance, although the two are often used together in process engineering.
    • It is not by itself a safety or compliance certification; it is an analysis or check that can support quality and compliance activities.

    Common confusion

    • Mass balance vs. inventory reconciliation: Inventory reconciliation compares recorded stock levels to physical counts. Mass balance uses process and movement data to check conservation of mass across defined boundaries. The two are related but not identical.
    • Mass balance vs. yield: Yield is typically a performance metric (e.g., good product output vs. theoretical or input). Mass balance is the underlying accounting that helps explain where material went (product, rework, scrap, waste, hold, etc.).