What is the difference between MES and ERP?

ERP brings together business decisions about orders, purchasing, inventory and planning. MES focuses on how a released production order is carried out and what actually happened on the shop floor. The important difference is not the label on two software products but the ownership of each decision and authoritative record. A manufacturer can manage some execution activities within an ERP. A separate MES becomes worth considering when shop-floor events, instructions, resources and quality decisions need more detailed and timely control than the existing workflow can provide.

An “ERP above, MES below” diagram can be useful, but it is not an integration design. ERP may create an order while MES dispatches it. Its product revision, material lot, operation sequence, actual quantity and closing status may then change at different times. For each attribute, a plant must decide who can change it, which system records the change first, and what the receiving system should understand from the update. A healthy API connection does not guarantee that both sides use the same definition of “completed”.

Why separate planning and execution activities?

The public description of IEC 62264-1 covers manufacturing operations management and its information exchange with enterprise activities. Level 3 concerns manufacturing operations; level 4 concerns business planning and logistics. This model helps distinguish planned work, execution, actual results and reconciliation. It does not say every company needs two software purchases or that one vendor can serve only one level. The public description is not the full paid normative text, and this article makes no standards-conformance claim for any product.

A NIST-hosted research abstract on manufacturing planning and execution similarly notes that execution software must interoperate with planning, scheduling and equipment-control systems, while information barriers among commercial products cause difficulty. The research is older and does not prescribe a modern product architecture. Its durable lesson is that interfaces and activity boundaries matter more than software category names. A plant should test its own workflow and current systems before borrowing a reference diagram.

What does ERP usually own?

Customer demand, commercial due dates, purchase orders, financial valuation, material master data and enterprise inventory accounting usually belong to ERP activities. The approved product definition, bill of materials and route may be mastered in ERP or in an integrated engineering system. “Usually” matters: a PLM or PDM system may be the real authority for a product revision while ERP consumes the released version. The owner should be identified from the plant's actual process, not imposed by a generic template.

An ERP production order does not by itself prove that the order was executed as specified. A target of 1,200 units says little about which shift ran, whether trial pieces were counted, which instruction revision the operator saw, or how a quality hold was resolved. Some ERP manufacturing modules can record this level of detail. If the current ERP handles the necessary events, operator workflow, traceability and correction history reliably, a new standalone MES may be unnecessary.

ERP can also be the commercial record for a stock movement without being the first place where the physical event occurred. A finished-goods receipt should follow a defined condition: perhaps inspection release, perhaps an approved production confirmation. The rule needs to account for material still under review, scrap and rework. Simply sending every cycle count to an inventory table is not a reliable shortcut.

What does MES usually own?

MES typically focuses on dispatching released work to resources and recording execution with its operational context. An operator may see the active order and step, scan a material lot, acknowledge the current instruction, and record completion or an exception. Machine and human events can be connected to the same order. Not every MES product offers every function, and not every plant needs them. Define the decision that lacks trustworthy evidence before choosing the tool.

The MES record of actual production is not identical to the ERP record of available finished inventory. A machine might complete 1,170 cycles, but not every part is necessarily good or released. MES or a linked quality system may distinguish 1,100 first-pass good parts, 40 scrap parts and 30 parts awaiting review. What ERP receives, and when, depends on an agreed transaction rule. Treating all 1,170 cycles as available stock would make the systems agree technically while misrepresenting the physical state.

Execution ownership also includes corrections. Who may change a downtime classification, reopen an operation, replace a scanned lot or adjust a quantity? Does the system preserve the original value, actor, time and reason? If ERP has already booked a stock movement, is the correction a reversal, an adjustment or a new event? These are part of the workflow, not implementation details to leave until after go-live.

An ownership matrix to adapt, not copy blindly

Decision or record	Common authoritative activity	Shop-floor relation	Boundary to agree
Customer demand and due date	ERP	MES may display priority	May a supervisor change priority locally?
Approved product and revision	ERP or engineering system	MES uses the version released for the order	What happens to open orders after a revision?
Material identity and available lot	ERP/WMS master records	MES records actual lot consumption	Who corrects a wrong lot scan?
Line, shift and operation performed	MES or another operations system	Machine and operator events provide evidence	How does a changed sequence return to planning?
Good, scrap and held quantity	Operations and quality records	MES or QMS records disposition	Which amount creates an ERP completion?
Invoice and financial inventory value	ERP	MES supplies operational input	When does consumption become an accounting movement?

This is a design aid, not a standards-mandated product allocation. A warehouse system may own physical stock moves, a QMS may own quality release, and SCADA may own the initial alarm event. It is acceptable to distribute activities among applications. It is not acceptable to leave two independent masters for the same decision without reconciliation rules.

A hypothetical order: cycles are not stock

Imagine a metalworking line with a production order for 1,200 parts. Assume ERP reserves enough raw material for 1,300 parts, and MES releases the order to the line after the operator scans the material lot. At shift end the machine reports 1,170 cycles. Quality records show 1,100 first-pass good parts, 40 scrap parts and 30 parts pending inspection. The arithmetic is explicit: 1,100 + 40 + 30 = 1,170. These are invented teaching numbers, not data from a Tuna Industrial Platform customer or installation.

It would be easy to send “1,170 completed” to ERP, but its meaning is unclear. If ERP books it as finished-goods stock, available inventory is overstated by 70 units. Sending only 1,100 does not mean the 40 scrap and 30 pending parts should disappear from the operations record. One design might exchange three distinct events: good completion, scrap and quality hold. Another might retain the detail in MES and send only released stock movements to ERP. Accounting, quality and operations stakeholders must choose the rule together.

Suppose inspection approves 20 of the 30 pending parts the next day and scraps the other 10. The final good amount becomes 1,120 and total scrap becomes 50; the total is still 1,170. Silently rewriting yesterday's first-pass-good count from 1,100 to 1,120 would destroy useful history. The inspection decision needs its own time, actor and reference. ERP must then know when the extra 20 units become stock and how the additional 10 scrap units affect its records.

This distinction also matters for OEE. First-pass quality and the later commercial inventory status are different questions. The definition of a good unit and treatment of rework must be specified for the Quality component. A well-connected MES and ERP can still publish a misleading OEE figure if their metric definitions are inconsistent.

Where integration fails despite a successful connection

Identifiers are a frequent source of error. A product called “A-100” in ERP may be “A100” in MES and a numeric recipe code in SCADA. A mapping without version and audit history can attach a machine event to the wrong product. Time is another boundary: a PLC, operator terminal and server with different clocks can assign an event to different shifts. Message replay after a network outage can create duplicate inventory unless processing is designed to recognize the same event.

Correction authority is a third issue. If an operator scans the wrong lot, can MES change the record? Does quality approval become necessary? If consumption has already been posted to ERP, what compensating transaction is needed? Fourth, the data contract itself changes. ERP field revisions and MES event versions need documented handling for old messages. The interoperability problem is not solved by an endpoint alone; the meaning of an event and its failure procedure must be tested.

The plant should choose a small set of representative cases before implementation: a normal order, a wrong lot, a held batch, a stop crossing shift boundaries, an offline terminal, a repeated completion event and a retroactive quality correction. Acceptance means the physical event can be explained across all systems, not merely that both screens show similar totals.

Where do SCADA, QMS and WMS fit?

SCADA can provide machine and process conditions, alarms and supervision data. MES may connect a stop to an order, product and operational reason. That does not make every SCADA installation a fixed “level 2 only” product or mean MES takes over a safety-critical control function. Similarly, QMS may remain the authority for quality disposition, and WMS may remain the authority for warehouse movement. Moving those responsibilities into MES solely to complete a diagram could add risk rather than simplify operations.

Ask a concrete ownership question for each event: if this record is wrong, which team corrects it, which system contains the original evidence, and what trail should a customer or auditor see? If the answer is unclear, the architecture conversation has moved too quickly to product labels. The decision and record boundary comes before interface selection.

Is a separate MES always necessary?

No. A plant with a small number of lines, limited product variation, modest traceability needs and an ERP module that already handles execution adequately may gain little from another system. It could add integration maintenance and training without solving a measured problem. A plant with frequent changeovers, many resources, detailed lot or serial traceability, in-process quality or high event volume may find the existing ERP workflow too coarse for shop-floor decisions. Both are hypotheses to test, not universal procurement rules.

Trace one real order end to end before buying: who creates and releases it, where the approved instruction appears, where material and machine events originate, when quality makes a disposition, when stock becomes available, and how a correction is recorded. If the current tools support this chain reliably, a standalone MES is not compulsory. If they do not, define the missing capability from the break in the chain rather than from a vendor feature list.

NIST Manufacturing Extension Partnership guidance on MES for smaller manufacturers stresses adoption challenges and an understanding of the value stream, not only the collection of data. It does not guarantee a return for any particular plant. Operators need usable procedures and a way to correct mistakes; otherwise the new system may sit beside shadow spreadsheets. ERP and MES complement one another when planned demand and validated shop-floor results retain their meaning as they cross the boundary.