MES vs ERP: Planning, Execution, and Record Authority

MES vs ERP is most useful as a comparison of responsibilities, not a contest between application names. Enterprise resource planning addresses the business plan and its commercial consequences; manufacturing execution addresses the work performed and its operational evidence. For an implementation decision, ask which records authorize work, which record actual activity, and which support inventory, financial, or quality decisions.

Do not turn that distinction into a universal ownership rule. An ERP manufacturing module might capture production activity. A separate MES might receive orders, manage execution, and return selected transactions. A broader platform might contain both sets of functions. Evaluate the configured arrangement rather than assuming that the label on an application establishes its authority.

Treat this table as a proposed comparison framework, not a description of every ERP or MES. Start with a consequential decision—such as promising stock or closing an order—and trace its inputs backward. That exercise exposes whether a displayed quantity is planned, physically observed, posted, or authorized for use.

This guide concentrates on the planning-to-operations boundary. Evaluate quality-process responsibilities, production-record formats, and eDHR implementation separately; a planning-to-execution comparison is not a product specification.

For evaluation purposes, describe the execution work you need: presenting the applicable instructions, associating materials with an order, capturing quantities and observations, managing local exceptions, and returning business transactions. Then identify which application or controlled procedure performs each activity. Do not assume that every MES supplies every function, or that an ERP cannot supply one.

ISA's public ISA-95 overview describes Level 3 as manufacturing operations management and Level 4 as business planning and logistics. It places MES and other operations systems in its Level 3 discussion and ERP in Level 4, and identifies the interface between those levels as a primary concern. This is useful vocabulary for discussing activities, not evidence that your installation must contain two separate applications.

ISA's 2020 commentary explicitly describes the levels as logical boundaries. Its public overview also says the model prioritizes activities rather than technologies. Use those public explanations to organize questions; they are not paid standard clauses or a mandatory deployment architecture.

A single platform still needs these distinctions. Conversely, two applications need not maintain two editable versions of every fact. A useful boundary minimizes competing authority while preserving the evidence each decision needs. Reducing application count and reducing ambiguity are different objectives.

Define authority below the system name. An item identifier, an engineering revision, an order quantity, a physical movement, and a quality status can have different decision owners even when stored together. Write down who can originate each value, who can change it, which copies are informational, and what happens when copies disagree.

These are proposed allocations, not standards mandates. Your technical definition might originate outside both ERP and MES. Your warehouse may maintain physical-location evidence separately from the inventory ledger. Decide which source answers each question rather than forcing a whole record into a single ownership box.

For shared records, identify field-level authority and transition rights. Planning might control the requested quantity while production controls actual completion observations. That is not permission for both to edit the same completion value. A receiving copy should carry provenance and its last accepted version so users can distinguish an authoritative change from an overdue synchronization.

Finally, assign a human escalation route. Integration staff can diagnose a rejected message without having authority to substitute a material, change an order baseline, or release stock. Name the person who can make each decision and the evidence that person needs.

Packet PKT-438 covers order WO-438 revision 2 for 100 BK-27 storage brackets, product revision C. Baseline BASE-6 binds BOM-27 revision 4 and routing RT-27 revision 6. One BL-27 revision B blank becomes either one bracket or one scrapped workpiece. No additional material, rework, or process loss is stipulated.

Tess owns technical definitions and master data; Owen owns order scope. Mara owns production observations and physical material accounting. Dev owns ERP posting acceptance and order-accounting reconciliation. Niko diagnoses interface behavior. Bea owns quality-status decisions. These assignments are local choices, not a required staffing pattern.

Mara's physical count finds 100 blanks consumed, 96 nonscrap brackets, four scrapped workpieces, and ten unused staged blanks. The ten are returned to STORE. Of the 96 brackets, 90 are in FG-HOLD and six are in QA-BAY. An expected check record for those six is unavailable at the snapshot; their acceptability remains unresolved.

The proposed contract distinguishes four states. Source-recorded means an origin has recorded a statement; it does not prove the statement is correct. Received means the destination has the delivery. Applied means a destination transaction or status change occurred. Business-accepted means the responsible owner accepted the evidence for its specified business purpose. None of these terms means product release.

For this exercise, every quantity event carries its event identifier, line identifier where relevant, record revision 1, WO-438 revision 2, BASE-6, item and lot, signed quantity, unit, locations, source time, schema S1, and MAP-12. Delivery identifiers and receipt times are separate. Status records instead carry their own increasing status revision and decision reference.

The proposed duplicate key is source namespace plus event identifier plus line identifier. A retry preserves that key and the original payload. A changed payload under the same key is a conflict for investigation, not an update. Corrections use new identifiers and explicit links. This rule is a design choice to test, not a claim of guaranteed exactly-once interoperability.

The table follows source chronology, not arrival order. C1 arrives before its location prerequisite. Q2 arrives after Q3. O1 partly succeeds. Those distinctions are intentionally visible rather than collapsed into a single green or red message status.

Business acceptance here includes named human reconciliation. Another design might automate some transaction acceptance under approved rules. Either way, specify what the acceptance means and what evidence supports it; do not let a transport acknowledgment silently acquire financial or quality authority.

For C1, a missing acknowledgment creates uncertainty about posting, not proof of failure. Niko searches the receiver using C1's business key. Dev confirms PC-21 before accepting the reconciliation. The retained evidence includes both deliveries, the initial uncertainty, and the recovered posting reference. Blindly creating a new consumption identifier would defeat the proposed duplicate rule.

For the out-of-order transfer, the chosen policy holds C1 until T1 establishes stock in STAGE. A different installation might reject the event and require resubmission. Either policy needs a visible dependency, an escalation owner, and a tested recovery path. A queue that silently waits forever does not answer the business question.

For O1, transaction scope is explicitly line-level. A batch-level success flag would hide the rejected six; a batch-level replay without line protection could duplicate the posted 90. Niko must establish why QA-BAY has no approved mapping. Dev must authorize any destination mapping, and Bea must confirm that the mapped location preserves the intended restrictions. No correction has been authorized by 10:40.

For status, the proposed rule permits a newer, self-contained restrictive hold to apply despite a missing earlier revision. It records the history gap until Q2 arrives. Q2 then fills historical context without replacing revision 3. This is a deliberate policy for this packet, not a universal instruction to accept sequence gaps or order events by timestamp alone.

For C2, the investigation distinguishes an erroneous recorded quantity from physical consumption. R1 reverses the erroneous posting; C3 records the supported quantity. Neither changes the physical count. The reason C2 was recorded as 44 remains under investigation, so numerical correction does not close the data-entry issue.

First count deliveries, then identify unique business events, then interpret corrections, and finally compare applied transactions with physical evidence. These are different operations. Removing duplicates alone does not repair a wrong source quantity; correcting that quantity does not apply a rejected output line.

The two wrong totals are deliberately labeled as invalid summaries. They are not alternative inventory values. The consumption comparison uses signed EA events for the same material and order; the output comparison uses EA events for the finished item. Do not add those item populations together as though they were interchangeable stock.

The physical accounting also distinguishes transactions with similar signs. U1 moves ten unused blanks back to STORE. R1 has a negative consumption quantity but moves nothing physically. S1 records four scrapped workpieces already included in consumed material; subtracting four more blanks would double-count their material use.

At the snapshot, material inventory agrees numerically with the corrected consumption record. Output inventory does not yet agree. Even after the six-piece posting is repaired, the quality hold can remain. Physical existence, ERP posting, accepted accounting, and authorized release answer different questions and need separately labeled quantities.

Retain summary SUM-438-1, which incorrectly used delivery totals of 160 consumed and 192 produced, and mark it unsuitable for decisions. Create SUM-438-2 from the reconciled event interpretation: 100 consumed, 96 physically produced, 90 posted, four scrap, six unposted, and zero released. Preserve the calculation definition and snapshot time with each version.

Do not merely repair the dashboard. Identify who received the earlier summary and which decisions relied on it. In this fictional packet, Owen withdraws a draft availability calculation based on 192 pieces. Dev defers final order close while the six-piece difference remains. Bea maintains the hold pending the missing check evidence. None assumes another owner's correction resolves their own decision.

In routine operation, choose reconciliation frequency from decision timing and consequence, not a universal weekly or monthly schedule. Display backlog age, missing acknowledgments, rejected lines, sequence gaps, and unresolved physical differences. Define who can continue which activities during an outage. Restoring connectivity is a technical event; it does not establish that physical work and business records agree.

An ERP shop-floor module is a candidate when it can demonstrate the required execution and evidence behaviors in your configuration. A separate MES is a candidate when its operational capabilities justify another integration and operating responsibility. Neither conclusion follows from plant size, regulated status, or a feature-list comparison alone.

Give each candidate the same packet and decision questions. Ask an operator to identify the governing revision, a planner to interpret available quantity, a finance owner to explain a reversal, and a quality owner to locate the controlling hold. Record demonstrated behavior, configuration dependencies, custom work, and anything not shown.

Compare operating effort as well as acquisition cost: maintaining mappings, investigating failures, managing access, preserving historical evidence, and reassessing changes. A dedicated execution application can introduce worthwhile specialization and additional coordination. A consolidated application can simplify some handoffs while concentrating change impact. Require evidence for the trade-off that matters to your operation.

Prefer an interface whose documented behavior and support arrangements you can evaluate. Specify transaction boundaries, error responses, identifiers, units, revisions, and recovery behavior before relying on it. Documented interfaces are an evaluation criterion, not a promise that upgrades will preserve behavior.

Record expected behavior before execution, then retain inputs, actual results, configuration, unresolved issues, and the resulting acceptability decision. These tests are proposed evaluation activities; they have not been performed against a current application. A demonstration that stops before receiver posting cannot establish that posting worked.

When either application, mapping, unit definition, permission model, or status calculation changes, assess affected decisions and historical data. Repeat relevant challenges and include retrieval of older records. If the duplicate key changes, test old deliveries against the new configuration. If a location mapping changes, determine what happens to already-rejected lines rather than assuming the queue repairs itself.

Plan changes with an identified authority arrangement for work already in progress and a recovery decision if results are unacceptable. Avoid promising upgrade survival or failure prevention. The useful deliverable is evidence showing what the tested configuration does, what remains uncertain, and who accepts the resulting operating limits.

For selected medical-device production or quality-management intended uses, FDA's Computer Software Assurance guidance provides a relevant risk-based perspective. It describes establishing and maintaining confidence that software is fit for its intended use, with assurance effort informed by the risk of compromised device safety or quality if the software fails.

The guidance is nonbinding and its scope is medical-device production or quality-management software. It is not a universal mandate for ERP or MES projects across regulated industries, and it does not provide recommendations for design-and-development verification or validation of device software functions. The household-bracket packet is not a medical validation example.

If your selected use falls within that medical scope, connect each intended function to its failure consequences and evidence needs. Do not classify an entire application solely by its name. The following mapping connects this guide to selected medical manufacturing questions without claiming to answer a complete readiness assessment.

Use the related medical guides for their own questions rather than importing their bodies into this comparison. The central MES versus ERP decision remains generic: establish authority, demonstrate the crossings, reconcile differences, and keep business acceptance distinct from physical execution and disposition.