Manufacturing execution in maintenance, repair, and overhaul looks very different from execution in a production line. In an aerospace MRO environment, the work scope is driven by aircraft condition, operator requirements, service bulletins, airworthiness directives, and the exact configuration of the tail number or serialized assembly in the shop. That means an MES for aerospace MRO must do more than route work through standard steps. It must coordinate changing workscopes, maintain serial-level history, and preserve the evidence needed for compliant release documentation.
This article is for aerospace operations, quality, and compliance teams who need to understand MES for Aerospace MRO: Managing Tail-Number-Specific Maintenance Execution. It explains the practical question this topic answers in a manufacturing execution context.
For repair stations and airline maintenance organizations, the execution layer is where inspections, findings, repair decisions, parts replacements, and approvals become a controlled digital record. This is also where teams connect planning systems, shop activity, quality checks, and technical publications into a single operational flow. For a broader view of connected MES for aerospace MRO operations, it helps to start with the role of execution in regulated aerospace environments.
For teams putting this topic into daily operation, MES execution control, MRO execution workflows, shop floor execution control help connect the concept to traceability, work-order reality, and audit-ready evidence.
The same operating model also depends on a connected execution platform, Connect981’s aerospace execution solutions, real aerospace execution examples, Connect981’s aerospace operations guidance, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.
Connect981 can serve as that execution layer for Part 145 organizations by orchestrating digital workflows across inspection, repair, subassembly routing, traceability, and release readiness without forcing maintenance teams into a rigid high-volume production model.
Regulatory Context for MRO and Repair Stations
FAA Part 145, EASA Part-145, and customer requirements
Repair stations operate under a different compliance profile than production organizations. The governing framework typically includes FAA Part 145 or EASA Part-145 requirements, plus air carrier procedures, OEM maintenance data, lessor conditions, and customer-specific contractual controls. In practice, execution software has to help enforce the approved maintenance data and the organization’s own procedures, while still allowing authorized personnel to document findings and disposition paths as work evolves.
An MRO MES should therefore support controlled routing, role-based approvals, revision-aware work instructions, and evidence capture tied to the actual maintenance event. It should not attempt to replace the regulatory framework or interpret approvals on behalf of the repair station. Its value is in making the approved process executable, traceable, and reviewable.
Differences between production and maintenance records
Production records focus on how a part was built. Maintenance records focus on the condition of an in-service article, what was found, what action was taken, what parts were removed or installed, and who approved each step. The record must often connect installed configuration, operational limits, prior maintenance history, and the maintenance data used during the event.
That distinction matters because MRO execution often starts with uncertainty. A shop may receive an engine module, flight control component, or avionics assembly with a planned scope, then expand that scope after teardown and inspection. An MES designed for repetitive manufacturing can struggle here unless it supports conditional branching, ad hoc findings capture, and controlled routing additions.
Audit expectations for digital maintenance histories
Auditors and customers generally expect a maintenance history that can be followed from intake through release. That includes timestamps, technician actions, inspection outcomes, material or component changes, and evidence that required approvals occurred. Digital systems are valuable when they preserve an attributable, legible, and reviewable history rather than scattered paper packages and disconnected spreadsheets.
For aerospace organizations, this history also needs to survive customer review, internal quality investigations, and long retention periods. An execution system should make it easy to retrieve the complete trail for a tail number, serialized subassembly, or repair event without reconstructing the story manually.
Execution Challenges Unique to Aerospace MRO
Unplanned work scope and findings during teardown
One of the defining MRO problems is that the true workload often appears only after disassembly. Corrosion, wear, out-of-tolerance dimensions, coating loss, impact damage, contamination, or undocumented prior repairs can all change the route. A usable MRO MES must let teams decompose a high-level work order into emerging tasks without losing control of approvals or traceability.
For example, a landing gear component may arrive for scheduled shop visit work. During teardown, inspectors identify bushing wear and a damaged bore that triggers additional inspection, engineering review, special process routing, and part replacement. The execution layer should be able to add those steps, assign holds, collect measurements, and document the approved path to reassembly.
Managing service bulletins and airworthiness directives
MRO execution is also shaped by mandatory and recommended actions from OEMs and regulators. Service bulletins and airworthiness directives can alter inspection criteria, replacement thresholds, or required modifications. The challenge is not just storing those references; it is ensuring the right maintenance data and task content are applied to the affected tail number or serialized assembly.
An effective MES can associate the current workscope with applicable maintenance requirements, flag open actions, and route tasks based on model, configuration, or operator program. This helps teams avoid missed compliance steps when different fleets, engine variants, or customer maintenance programs are processed in the same facility.
Clarify the operational risk
When the work behind MES for Aerospace MRO: Managing affects quality, delivery, or compliance, teams need one place to connect evidence, decisions, and shop-floor follow-through.
Handling life-limited and time-controlled parts
Life-limited parts and time-controlled components are central to many overhaul environments, especially in engines, rotating assemblies, and safety-critical systems. The execution system must track part identity, status, installed position where relevant, accumulated usage data if provided, and the maintenance action taken during the event.
This is not simply inventory control. The maintenance record has to show that the correct serialized component was removed, evaluated, replaced or reinstalled under the approved criteria, and reflected in the final configuration. When these controls are weak, release documentation becomes slower and the risk of traceability gaps rises sharply.
MES Functions for MRO Workscopes and Routing Control
Work order decomposition by assembly and subassembly
In MRO, the top-level visit or repair order is rarely enough to control execution. Teams need to break work down by module, assembly, subassembly, and component so each item can move through inspection, repair, outside processing, and reassembly with its own status. An MRO-capable MES should support this hierarchy natively.
That means a single engine overhaul event can be decomposed into fan module, compressor, combustor, turbine, accessory gearbox, and serialized piece-part activity. Each level can carry findings, routing steps, required approvals, and material transactions while remaining connected to the overall shop visit record.
Disassembly, inspection, repair, and reassembly sequences
Unlike repetitive manufacturing routes, MRO sequences often begin with controlled disassembly and condition assessment. The system should be able to record when a serialized article was disassembled, what was removed, what condition was observed, and what downstream steps were triggered. After inspection, approved repairs and reassembly tasks must be sequenced so nothing advances past required checks.
Practical controls include operation gating, hold points, mandatory data fields, attachment of images or measurement records, and inspector sign-off before the next task can begin. These controls reduce the chance of components bypassing required evaluation or reassembly proceeding with unresolved discrepancies.
Variant management for different aircraft and engine models
Repair stations frequently support multiple aircraft, engine, and component variants in the same shop. Even where the hardware appears similar, maintenance limits, manuals, tooling requirements, and approvals can differ. A strong MES architecture supports variant-specific routings and task logic rather than one generic process.
This matters for both compliance and throughput. If technicians have to manually determine which version of a route applies every time, errors increase. If the system can present the correct tasks, forms, references, and sign-off chain based on model and configuration, execution becomes more consistent and easier to audit.
Tracking Parts, Findings, and Approvals at Tail-Number Level
Serial tracking from installed configuration to shop and back
Tail-number-level maintenance execution depends on serial traceability across removal, induction, shop processing, and reinstallation or return to stock. The MES should connect the installed configuration of the aircraft or engine to the serialized article entering the shop, then maintain that identity through every work step.
For line replaceable units, modules, and piece-parts, the level of granularity may vary by process, but the principle is the same: the maintenance history should show where the item came from, what happened to it, and what its resulting status became. This is especially important when parts move between internal cells and external suppliers before coming back into the repair chain.
Recording findings, repairs, and replaced components
Findings are the operational heartbeat of MRO. The MES should let inspectors and technicians record defect types, locations, measurements, reference criteria, and disposition pathways in a structured way. It should also capture what repair was performed, what replacement component was installed, and whether additional inspections were required as a result.
Structured findings data is valuable beyond the individual work order. It supports trend analysis across fleets, operators, component families, and repair events. Over time, this can help quality and reliability teams identify recurring defects, refine maintenance planning assumptions, and adjust stocking or subcontractor strategies.
Capturing digital signatures for return-to-service
Return-to-service and release-related approvals require disciplined control. While the exact approval process depends on the organization and applicable rules, the execution system should support role-based electronic signatures, review of open discrepancies, verification of completed tasks, and confirmation that required records are attached before release documentation is finalized.
The goal is not to automate airworthiness judgment. The goal is to ensure that authorized personnel have a complete digital package to review and approve, with clear evidence of who performed the work, who inspected it, and whether all required steps were completed before release.
Connect981 as an MRO Execution and Coordination Layer
Integrating airline systems, ERP, and shop tooling
Most repair stations do not operate from a single system. Planning may live in ERP or airline maintenance software, technical data may come from OEM portals, calibration and quality records may sit elsewhere, and shop equipment may generate its own files. Connect981 can act as the coordination layer that brings these inputs into a controlled execution workflow.
Connect decisions to execution
Connect981 helps turn this kind of operational detail into traceable action, so the context behind each decision does not get lost.
That makes it possible to manage work packages, route inspections, capture technician activity, record findings, and return completion data to upstream systems without depending on paper travelers. In practical terms, the platform can support the handoff between planning, execution, quality, and documentation rather than forcing each function to maintain separate manual logs.
Example: engine overhaul shop with multiple OEM manuals
Consider an engine overhaul environment servicing multiple models with different manual sets, inspection thresholds, and subcontracted special processes. A conventional one-size-fits-all route often leads to side spreadsheets and exception handling outside the system. Connect981 can instead organize the workscope by module and serial, present the applicable workflow path, and capture findings and approvals at each stage.
When a component moves out for coating, machining, or NDT, the execution record can remain open and visible. When it returns, the system can verify receipt, attach the supplier documentation, and release the next operation only after required review. That improves continuity across the full repair chain.
Supplier and subcontractor visibility across repair chains
MRO execution often depends on subcontractors for specialized repair or processing. Without a connected execution layer, components disappear into email threads until they come back. By treating supplier handoffs as part of the controlled workflow, organizations can track shipment status, expected return, received documentation, and downstream readiness.
This matters operationally because turnaround time is frequently constrained by waiting, not wrench time. Better visibility into external processing helps planners identify bottlenecks earlier and gives quality teams a cleaner chain of evidence for outside work incorporated into the final release package.
KPIs and Continuous Improvement for MRO MES
Turnaround time, findings rate, and rework rate
The best MRO metrics start with execution reality, not only schedule promises. Turnaround time should be measured at meaningful levels such as overall visit, module, and major process segment. Findings rate helps reveal whether induction assumptions are realistic. Rework rate indicates whether repairs, inspections, or documentation controls are breaking down and causing loops.
Because the MES records work progression step by step, these KPIs can be based on actual event timestamps and status changes rather than manual estimates. That gives operations leaders a more reliable basis for capacity planning and workflow redesign.
Trend analysis on recurring defects by fleet or operator
Tail-number and operator-linked data become especially valuable when aggregated. If a repair station sees recurring damage modes on a specific fleet type, route region, or operator maintenance program, that pattern can inform spares planning, inspection readiness, and engineering feedback. The same applies to recurring supplier escapes or subcontractor-related returns.
Structured MES data turns isolated repair records into a usable reliability dataset. Even when the system is not the formal reliability platform, it can provide the execution evidence needed to support those analyses.
Using MES data to refine maintenance programs
Over time, digital execution data can help organizations improve how they plan and perform maintenance. Shops may adjust standard work packages, improve teardown sequencing, pre-stage likely replacement parts, or tighten routing controls around known problem areas. The value is practical: fewer surprises, faster release preparation, and better alignment between planned and actual work.
For aerospace MRO, that is the real promise of MES. It is not just digitizing shop paperwork. It is creating a controlled execution environment where tail-number-specific maintenance, findings-driven repairs, part traceability, and release readiness can be managed in one connected workflow.
Frequently asked questions
A manufacturing execution system (MES) is a production-focused information system that coordinates, monitors, and records manufacturing activities on the shop floor in near real time. It typically sits between enterprise systems such as ERP and the actual production equipment, lines, and cells.
Core role of an MES
In most regulated, mixed-vendor environments, an MES is expected to:
In practice, this connects to work orders and digital travelers when teams need to turn the answer into repeatable execution habits.
- Orchestrate production: Translate released orders or schedules into executable work at lines, cells, and workstations.
- Enforce process and sequencing: Ensure operators and equipment follow the defined routing, steps, and preconditions before work proceeds.
- Capture production data: Record who did what, when, where, with which materials, settings, and tools.
- Provide traceability and genealogy: Link materials, components, tools, batches, and process parameters to each produced unit or lot.
- Monitor performance: Track status, counts, downtime reasons, scrap, and rework to support KPIs such as OEE and NPT.
The exact functions implemented vary widely by plant, vendor, and regulatory context. In many brownfield sites, MES capabilities are split across multiple systems and custom integrations rather than a single monolithic platform.
Typical MES functions in regulated manufacturing
Common capabilities you see in MES deployments for regulated and long-lifecycle products include:
- Order and routing execution: Execution of work orders, routings, and operations defined in ERP or PLM, including operation start/complete, holds, and rework loops.
- Electronic work instructions: Delivery of controlled instructions, checklists, and inspection steps, often with enforced sign-offs and conditional logic.
- Data collection and parameter capture: Recording of critical process parameters, inspection results, and operator entries to support traceability and deviation analysis.
- Electronic batch records or device history records: Assembly of the executed production record for lots or serialized units, supporting audits and investigations.
- Material and component management: Tracking of component consumption, batches, shelf life, tool usage, and material substitutions, often integrated with warehouse or ERP systems.
- Quality checks within the workflow: Inline inspections, holds, nonconformance logging, and routing of suspect product to defined quality workflows.
- Real-time visibility: Dashboards of line status, WIP, bottlenecks, and alarms for supervisors and support teams.
Which of these functions live in MES versus in PLM, QMS, SCADA, LIMS, or custom applications is highly site-specific. Overlaps are common and create integration and governance challenges.
How MES fits with existing systems
In brownfield environments, MES is one system in a larger landscape, not a clean replacement of existing tools. Typical coexistence patterns include:
- ERP: ERP remains the system of record for planning, inventory valuation, and financials. MES receives production orders and material data, and returns confirmations, consumption, and scrap information.
- PLM and document control: Product definitions, routings, and controlled documents are authored and released in PLM or engineering systems. MES consumes these for execution but usually does not replace PLM.
- QMS: Nonconformances, CAPAs, and change control are often managed in a QMS. MES may create or update QMS records but rarely replaces it in regulated plants.
- SCADA / historian / equipment controllers: These systems interact directly with machines and sensors. MES typically orchestrates work and collects selected data, relying on integrations rather than direct replacement.
Attempts to use MES as a full replacement for multiple established systems often run into qualification burden, downtime risk, and integration complexity. In regulated or aerospace-grade environments, those factors can make a big-bang replacement strategy impractical.
Constraints, tradeoffs, and failure modes
The value and reliability of an MES depend heavily on:
- Integration quality: Poorly designed or fragile interfaces to ERP, PLM, QMS, and equipment undermine data consistency and trust in the system.
- Process maturity: MES enforces defined processes. If routings, work instructions, and quality criteria are unstable or poorly governed, the MES will reflect that instability.
- Validation and change control: In regulated environments, every MES change may require assessment, testing, and documentation. Overloading MES with rapidly changing logic can create a change control bottleneck.
- User adoption and usability: If the system slows operators, is difficult to use, or is frequently unavailable, workarounds and shadow processes will emerge, eroding traceability.
Typical failure modes include underestimating integration and validation effort, attempting to centralize too much logic in MES, and trying to deploy a uniform model across highly diverse lines and facilities without adequate local adaptation.
What MES is not
An MES is not, by itself:
- A guarantee of compliance, audit success, or certification.
- A substitute for sound process design, training, and leadership.
- A universal replacement for ERP, PLM, QMS, SCADA, or historians, especially in long-lifecycle, regulated operations.
Used appropriately, MES serves as a central execution layer that ties together people, process definitions, and equipment, while coexisting with the rest of a plant’s information systems and respecting validation and change control constraints.
Short answer
CMMC does not “certify” or “approve” manufacturing execution systems as products, but it does directly affect how MES is deployed, configured, secured, and governed in any environment that handles Controlled Unclassified Information (CUI) or supports DoD contracts. The obligations sit with the organization and its systems boundary, not the MES vendor. In practice, if MES touches CUI, connects to systems that process CUI, or supports contract performance, its design and operation must satisfy the relevant CMMC practices. You cannot treat MES as out-of-scope just because it is a production system rather than a traditional IT application.
Where CMMC typically touches MES
CMMC impacts MES wherever it stores, processes, or transmits information related to DoD work, such as digital work instructions, NC/CAPA records, configuration data, or genealogy/traceability records tied to defense programs. It also applies when MES is tightly integrated with systems that clearly fall in scope, such as ERP, PLM, QMS, or document control handling CUI. Even when MES itself holds minimal CUI, it can still be in scope as a critical system supporting contract performance or as a pathway into in-scope networks. As a result, CMMC considerations usually cover user access, role design, authentication methods, logging, integration interfaces, and change control for MES.
In practice, this connects to shop floor execution control when teams need to turn the answer into repeatable execution habits.
MES configuration, access, and identity under CMMC
From a CMMC perspective, MES user and role management must align with access control and identification/authentication requirements across the broader environment. That typically means enforcing least privilege in MES roles, time-bound access for temporary users, and timely revocation when personnel changes occur. Depending on your boundary design and MES capabilities, you may need central identity (e.g., directory or SSO) or compensating controls if native MES functions are limited. You should also expect to document how MES access controls are managed, audited, and periodically reviewed, and how that ties into your formal account management procedures.
Logging, audit trails, and incident response in MES
Many MES platforms provide detailed audit trails for quality and regulatory purposes, but these are not automatically sufficient for CMMC. You need to confirm which events are logged (logins, failed logins, privilege changes, configuration changes, and integration activity) and how those logs are retained, protected, and correlated with other security logs. Some plants will need additional tooling to centralize or normalize MES logs for security monitoring, which can be non-trivial in older or proprietary systems. Where MES logging is weak or opaque, you may need network-level monitoring or procedural controls to partially compensate. You should also define how MES events feed your incident response process and how you would reconstruct a timeline if a compromise occurred.
Network architecture, integrations, and OT/IT boundaries
CMMC has direct implications for how MES is connected to the rest of the environment, especially when it spans IT and OT networks. You will likely need clear segmentation between production equipment, MES servers, and corporate or cloud systems, with controlled interfaces for data exchange. Legacy integrations (e.g., flat-file shares, open database links, hard-coded credentials) often present issues under CMMC and may require rework or compensating controls. Because MES typically integrates with ERP, PLM, QMS, SCADA, historians, and test stands, each interface needs to be evaluated for data classification, authentication method, encryption, and change control. The more tightly coupled and undocumented the integrations, the harder it is to show that the overall system meets CMMC expectations.
Change control, validation, and long MES lifecycles
Manufacturing environments often run MES platforms for a decade or more, with heavy customization and regulated validation burdens. CMMC requirements do not remove those realities, but they add another layer of constraints on how and when you can change MES configurations, interfaces, or infrastructure. Security-driven changes (e.g., stronger encryption, new authentication, extra logging) may require regression testing, validation, and production downtime, which has real cost and scheduling impacts. This is one reason why aiming for a full rip-and-replace of MES “for CMMC” usually fails in aerospace-grade environments: the combined validation, qualification, downtime risk, and integration rewrites become impractical. Incremental hardening and containment architectures are more realistic than wholesale system replacement.
Cloud or vendor-hosted MES considerations
If your MES is cloud-based or vendor-hosted, CMMC still applies to how that service is used and integrated, and you remain responsible for your compliance posture. You will need clear contractual terms and technical evidence around where data resides, how access is controlled, how logs are exposed, and how incidents are handled. Multi-tenant architectures can complicate boundary definitions and may make it harder to get the level of transparency some CMMC assessors expect. Even if the vendor markets themselves as “built for CMMC” or “CMMC ready,” that does not transfer compliance to you or guarantee an assessment outcome. You must still design your overall environment, network paths, and procedures so that the MES service fits coherently into your CMMC boundary.
Practical scope decisions for MES under CMMC
Whether MES is explicitly in your CMMC assessment scope depends on your defined system boundary and data flows, but in most defense-related plants some part of MES ends up in scope. Treating MES as out-of-scope while it holds production records, routing data, or work instructions tied to CUI is unlikely to withstand scrutiny. A more sustainable strategy is to map which MES functions and integrations actually touch CUI or critical processes, then prioritize controls and hardening there. For segments of MES that do not handle CUI, containment and clear separation can help limit the scope and reduce the breadth of required changes. All of this needs to be backed by current architecture diagrams, data flow documentation, and traceable decisions about what is in or out of the CMMC boundary.
Connecting this to a typical brownfield plant
In a brownfield manufacturing site with a long-lived MES and multiple legacy integrations, you should assume some level of rework will be needed to align with CMMC, but not necessarily a wholesale MES replacement. The realistic path usually involves tightening MES access control, tuning audit trails, segmenting networks, formalizing integration patterns, and bringing MES changes under stronger configuration and change management. You will also need to accept that some older components cannot be made fully compliant and instead require compensating controls and risk documentation. Success depends less on picking a “CMMC-ready MES” and more on understanding your existing MES footprint, its connections, and the extent to which it touches CUI or contract performance data.
There is no single “correct” number of status updates
There is no universal number of status messages that should flow from execution systems back into ERP. The correct level of granularity depends on product risk, regulatory expectations, scheduling sophistication, and integration constraints between MES, ERP, QMS, and supporting systems. In a typical regulated manufacturing environment, sending a small, standardized set of well-defined status events usually balances traceability needs with system complexity. Trying to make ERP reflect every shop-floor micro-step almost always results in high integration cost, noisy data, and brittle validation obligations without proportional benefit.
In practice, most organizations arrive at a pattern of a few core lifecycle updates, plus some exception-based events. As you add more events, each one becomes a contract to maintain interfaces, documentation, and validation evidence for the long term. Because equipment and ERP lifecycles are often measured in decades, these choices are expensive to undo. It is generally safer to start with fewer, more meaningful status events and only add more when there is a clear and validated business or regulatory need.
In practice, this connects to materials planning and erp integration when teams need to turn the answer into repeatable execution habits.
Typical event patterns that work in regulated environments
Many plants converge on a small number of standard execution-to-ERP status updates for each order or lot. Common milestones include: release to production (ready), start of work, key intermediate completions (by operation or routing step), completion of production, and goods receipt into inventory. In some environments, additional messages for hold, release from hold, scrap, rework, or deviation may also be sent when they have financial, material, or planning impact that ERP must own. These events generally map to clear ERP concepts like order status, operation status, and stock movements.
Regulated environments sometimes extend this with optional events tied to quality decisions or genealogy, such as lot disposition or batch certification, when those decisions change whether ERP can plan or ship material. However, detailed quality data (measurements, nonconformance content, investigation details) usually resides in MES or QMS rather than ERP, with only summarized status or blocking flags pushed up. This separation keeps ERP relatively stable while allowing more detailed and frequently changing data structures to live in systems better suited to them.
Tradeoffs of more vs. fewer status updates
Sending more frequent status updates can improve planning accuracy, WIP visibility, and responsiveness to disruptions if the data is timely and trusted. However, each additional status type increases integration mappings, test cases, failure modes, and regression validation effort. More granular events can also expose more timing discrepancies between systems, leading to reconciliation burdens and user confusion when timestamps or quantities do not perfectly align. In highly validated environments, every extra event also grows the scope of impact analysis for changes.
Conversely, fewer status updates reduce interface volume, maintenance, and validation burden, but limit what ERP can realistically do in near real time. Coarser events might lead to less accurate order completion dates, deferred recognition of yield loss, and weaker visibility of bottlenecks at the ERP layer. You then rely more heavily on MES or other operations tools for true operational status, accepting that ERP is closer to a financial and planning system than a live representation of the shop floor. The right balance depends on whether your primary pain is lack of visibility or excessive integration complexity.
Brownfield and coexistence constraints
In brownfield environments with mixed MES, legacy ERP, homegrown scheduling tools, and limited downtime, the feasible number of status events is often constrained by what interfaces can reliably handle. Older ERPs or custom middleware may not perform well under high-frequency updates, especially if they trigger expensive recalculations like MRP runs or ATP checks. You also need to consider how existing reports, custom code, and downstream integrations interpret order status; adding new intermediate states can break assumptions embedded over decades.
Coexistence with legacy systems usually pushes you toward a small number of carefully defined, backward-compatible events. Instead of replacing existing status flows wholesale, you incrementally refine them, for example by splitting a generic “complete” into “mechanical complete” and “test complete” where required for planning or shipping. Full replacement of ERP or MES solely to achieve more granular status reporting is rarely viable in aerospace-grade contexts given the qualification effort, validation cost, and downtime risk. It is typically more realistic to let MES or another operations layer own detailed status and have ERP consume only what it truly needs.
How to decide what to send: a practical approach
A pragmatic approach is to start from ERP’s decision points rather than from every execution event the shop floor can produce. Identify where ERP must change behavior: releasing material, scheduling capacity, recognizing cost and yield, committing to customers, and managing inventory availability. For each of these decision points, define the minimal, unambiguous status events that must be fed from execution to support that decision. This creates a traceable rationale for each event you add to the interface.
From there, categorize candidate events into “must-have for compliance/planning/costing,” “nice-to-have visibility,” and “no clear owner or consumer.” Only the first category should automatically flow to ERP; the second may be handled in MES dashboards or data lakes; the third is often better left unimplemented until a clear use case emerges. Document these choices, including assumptions and dependencies, and manage them under change control. This is essential because every new status event can become a long-lived obligation for interface support, regression testing, and validation.
Typical numbers and ranges seen in practice
While there is no standard, many regulated plants settle on single-digit to low double-digit distinct execution-to-ERP status types for a given order or lot lifecycle. For example, a simple discrete assembly line might use 5–8 core statuses plus a handful of exception statuses (e.g., hold, scrap, rework). More complex batch or multi-stage processes may have 10–20 well-defined states when you include quality dispositions, inter-plant transfers, and staged inventory states. Going beyond that range is possible, but only when backed by strong integration discipline and clear business justification.
The more critical and high-variety your products, the more you should expect that the real execution detail will reside outside ERP in MES, APS, or QMS systems. In those cases, ERP typically holds a summarized representation that is stable over long lifecycles and upgrades. When you find yourself modeling every intermediate operation or machine state in ERP, that is often a signal that the boundary between ERP and execution systems is being blurred in a way that will be difficult to validate and sustain. Calibrating the number of status updates is ultimately about respecting those system boundaries while still meeting planning, financial, and regulatory needs.