What is a manufacturing execution system?

A manufacturing execution system (MES) connects a production plan to what actually happens on the shop floor. It can record which work order ran on which resource, under which instruction or product revision, using which material, and with what output, downtime and quality result. MES is not, by definition, a machine controller, a replacement for every ERP function, or a guarantee that operational data will be correct. The useful question is whether it gives each production event enough context to support a decision and a defensible record.

A plant can collect machine signals without having meaningful manufacturing execution. A counter may rise while the system does not know which order was active, whether the units passed inspection, or which material lot was consumed. Conversely, a small operation may already perform some execution activities with paper, spreadsheets and an ERP screen. The MES decision is therefore not simply whether to buy another software category. It is which activities need a controlled workflow, which records need to be linked, and where the authoritative decision belongs.

The operational question behind MES

Business planning often asks what should be made, when it is needed, and how the order relates to inventory and customer demand. The shop floor asks what is running now, which step is complete, which resources were used, and what exception needs a response. An MES can connect these views through an execution loop: receive a released order, present usable instructions, collect events from people and equipment, apply agreed validation rules, and return the appropriate results to business systems.

This loop is more demanding than moving numbers between databases. A work order, route, material, equipment identifier, shift, quality status and completed quantity must carry compatible meanings at both ends. If one system counts every machine cycle as finished output while another counts only released good units, an interface can be technically healthy yet operationally false. A useful MES design begins with definitions and ownership, not a catalogue of dashboards.

Products called MES vary greatly. One may focus on operator instructions and order status, another on traceability and in-process quality, and a third may also include maintenance, detailed scheduling or recipe functions. The ISA-95 manufacturing operations management model is a useful way to discuss activities. It does not establish that every product implements every activity, nor does mentioning ISA-95 prove conformity or certification. A buyer should ask which work is performed, who authorizes it, and which record is authoritative.

Where ISA-95 fits

ISA describes ISA-95, also associated with IEC 62264, as a framework for terminology and information exchange between manufacturing control and enterprise activities. In a simplified functional view, level 0 is the physical process; level 1 senses or acts on it; level 2 supervises and controls it; level 3 concerns manufacturing operations management; and level 4 concerns business planning and logistics. MES is usually discussed in relation to level 3 and ERP to level 4. Those levels are logical activity boundaries, not rigid product boxes or a physical network diagram.

ISA's public overview also notes that SCADA can participate in level 3 manufacturing operations activities. It would therefore be inaccurate to say that SCADA always ends at level 2 and MES always begins at level 3. A SCADA environment may collect alarms and process trends, and in some plants it may support additional operational workflows. The practical design question is where a decision is made, where its evidence is stored, and how another system receives it. The public ISA overview supports this broad model; this article does not claim to have examined the full paid normative text for detailed obligations.

The ISA-95 parts cover different modeling and exchange concerns. ISA's public description says Part 2 addresses information at the level 3–4 interface, Part 3 models manufacturing operations management activities, and Part 5 addresses transactions supporting information exchange. These descriptions are useful for framing an integration discussion. They are not a substitute for a project-specific data contract, operational procedure, security design or acceptance test.

Typical MES activities

Work-order execution links the released plan to a real operation. Depending on the plant, that may include resource readiness, operator assignment, access to the correct instruction, step completion and deviation recording. Order creation and commercial scheduling can remain in ERP or a separate planning system. MES may translate the plan into a traceable execution record without becoming the master of every planning attribute. The right boundary must be written down before integration begins.

Production data collection brings together signals and observations that have different strengths. A PLC may supply a cycle count; a barcode scan may identify material; a scale may supply a measurement; an operator may identify a reason for a stop. A cycle count does not automatically mean a good finished part. An event with an unknown timestamp, unit or equipment identity can be misleading when aggregated by shift or product. The software can help validate and relate these events, but device maintenance, calibration, operating practice and clear definitions remain necessary.

Quality and traceability activities can connect incoming checks, in-process measurements, nonconformities, rework, scrap and release decisions. In some plants, the authorized quality decision belongs in a separate QMS or laboratory system. Collecting quality data in MES does not automatically give it authority to release a product. Regulated industries may have additional electronic-record, retention, validation and signature requirements; the general MES concept does not establish compliance with them.

Material and resource traceability asks which lot went into which order or unit, which equipment and personnel performed a step, and which product or recipe revision applied. Those records only support meaningful traceability if they reconcile with purchasing, warehouse and production-consumption records. Physical movement, warehouse booking and production consumption may happen at different times. A single screen that displays a stock figure is not proof that the physical inventory is correct.

MES, ERP and SCADA: different focus, possible overlap

ERP typically owns business activities such as purchasing, financial records, sales orders, inventory master data and high-level planning. MES focuses on execution and operational evidence. SCADA typically focuses on process supervision, alarms, visualization and control-related data. These are useful distinctions, but they do not demand three vendors or three independent applications. One platform may perform several activities; another plant may divide them among specialist systems. The non-negotiable part is clear ownership of data, changes and decisions.

Suppose the approved material master lives in ERP. MES may need a synchronized identifier and the specific revision authorized for a work order, but it should not silently create a conflicting commercial material code. Suppose a machine alarm originates in SCADA. MES may associate that event with an order and downtime reason, but it should not be assumed to take over a safety-critical control function. Even if a vendor sells a combined solution, these responsibilities must be explicit.

There is no universal answer to “which system owns the schedule?” A plant may plan at order level in ERP, sequence operations in a specialist scheduler, and dispatch work in MES. Another may use a simpler arrangement. What matters is avoiding two independent masters for the same decision. If a supervisor changes sequence on the floor, the system needs a rule for whether that change is local, how it is recorded, and what the planning system must learn from it.

A hypothetical line example

Consider a metalworking line with a work order for 1,000 units. Assume ERP sends the product identifier, target quantity, due date and material reference. MES opens the order at an eligible line, shows the current work instruction, and records the scanned material lot. A PLC sends cycle counts. A quality operator enters inspection results and scrap. At shift end, the counter reports 980 completed cycles while the quality record shows 940 first-pass good units, 25 scrap units and 15 units awaiting review. These numbers are illustrative, not results from a Tuna Industrial Platform installation or customer.

Saying “we produced 980” does not establish what can be shipped. The 940 first-pass good units, 25 scrap units and 15 pending units explain the count but have different business meanings. The pending units might later be reworked or released after an authorized decision. MES can link their status to the order, resource, time and reason. The condition under which ERP receives a completion or inventory receipt is a shared business rule. If all 980 cycles are booked as finished stock, the systems may appear synchronized while overstating available product.

This example also clarifies the relationship with OEE. Counts may feed an OEE calculation, but Availability additionally needs a definition of planned production and operating time; Performance needs an ideal cycle time; Quality needs an agreed good-unit rule. A plant can have an MES screen and still calculate OEE inconsistently. Data definitions and event classification matter more than the presence of a particular dashboard.

Data ownership and integration rules

Before implementation, make an ownership table for product, material, bill of materials, route, work order, equipment, shift, lot, operator, quality disposition and actual quantity. For each item record the master system, the permitted editor, the event that triggers an exchange, and the response to failure. An integration may use APIs, messages, files or another mechanism. Its transport cannot resolve disagreement over the business meaning of “completed”, “good” or “released”.

Timestamps and event ordering deserve particular attention. If machine and server clocks differ, a stop can land in the wrong shift. If connectivity fails, a design may need local buffering and later synchronization. Replayed events should not create duplicate counts, and a corrected quality decision should leave an auditable history. None of these behaviors should be assumed to exist in every package. Test them with representative cases rather than accepting a feature-list checkbox.

Access and change authority matter just as much. Who may release an order, override a route, reclassify a stop, modify a scrap quantity or close a shift? Is there a record of the original value, the new value, the actor and the reason? These are practical requirements for trustworthy production data. They are also distinct from claiming that a particular implementation meets a formal security or regulatory standard. ISA-95 helps describe exchange boundaries, while the site must define its own operational and security controls.

A practical readiness sequence

Start with one decision the plant cannot currently make reliably: where an order stands, why a line stopped, which lot went into an output, or how many first-pass good units were made. Define the event vocabulary for a pilot line or product family. Agree on what counts as start, finish, stop, trial, rework, scrap and release. Include operators and supervisors in that exercise; a definition that exists only in an IT document is unlikely to survive a shift change.

Next inventory the existing ERP, SCADA, PLC, historian and manual records. Which values are actually measured, which are copied by hand, and which are estimated later? Does a counter reset at a product change? Can a user correct a mistaken scan? Then write the integration and authorization rules for order changes, lot matching, shift close, retroactive corrections and network interruption. Only after that should the team define a narrow acceptance test: can one shift's record be reconciled with source events and physical counts?

NIST's Manufacturing Extension Partnership discussion of MES for smaller manufacturers emphasizes implementation and adoption challenges alongside data collection. It specifically points to understanding the value stream and to changes in working habits. This is useful practitioner guidance, not a promise that every deployment produces the same return. Training, operator participation and a correction process are necessary if the new system is to replace shadow spreadsheets rather than add another reporting burden.

Common misconceptions and limits

“An MES makes all data automatic and correct” is false. A quality disposition may still require an authorized person or a validated measurement process. An automatic cycle counter can misclassify trials, rework or product changes. Clear exception handling may matter more than a high percentage of automated inputs.

“An MES requires replacing the ERP” is not a general rule. Existing ERP can remain the master for business data if activities and integration responsibilities are sensibly divided. Whether that is feasible depends on the actual ERP interfaces, data quality and business process. This article makes no claim of a specific certified or ready-made integration here for a particular ERP or Tuna Industrial Platform.

“MES and SCADA are identical” is also wrong, as is the assertion that they never overlap. Their usual focus differs, while ISA's public functional model leaves room for shared operational activities. Judge the implementation by where records are authoritative and how decisions flow, not only by a software label. Likewise, an MES does not necessarily replace a separate QMS, maintenance application, warehouse system or detailed scheduler.

In short, a sound MES assessment checks the chain before the feature list: the right order, resource and instruction; a trustworthy event; an explicit quality decision; a traceable correction; and a result returned to ERP without changing its meaning. The software scope should follow the plant's actual problem and its existing system responsibilities. MES is most useful as a disciplined execution and information boundary, not as a promise that a new application will automatically solve every production issue.