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.
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.
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.
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.
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.
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.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
