Define the execution record before comparing MES products
A useful manufacturing execution system requirements checklist defines how a released production order becomes verified work: the correct instruction and resource, identified materials, attributable start and completion events, quality decisions, exceptions, genealogy, and reconciled quantities. It also names which connected system owns every input and final posting.
Start with one representative route and its difficult paths, not a catalogue of screens. Include an unavailable resource, wrong material, failed inspection, split quantity, rework, scrap, delayed device event, interrupted shift, and corrected record. Ask each candidate to execute and explain the same cases.
The goal is not paperless production by itself. It is a durable evidence chain that operators can follow, supervisors can control, quality can review, planners can trust, and finance or inventory systems can reconcile.
Write an execution evidence contract for one route
Choose a bounded production path: one product family, order type, line, shift pattern, or regulated record set. Document the release conditions, product and route version, operations, resources, qualifications, tools, setup checks, materials, instructions, parameters, quality points, outputs, losses, labels, completion rules, and financial or inventory postings.
For every step, record the permitted starting states, required evidence, resulting states, actor or device, event time, receipt time, reason codes, and correction method. Separate the approved instruction from the actual event. A later instruction revision must not silently change what an operator was told yesterday.
Treat identity as a first-class requirement. Production order, operation, product version, material lot or serial, resource, tool, person, device, inspection, deviation, and output need stable keys across integrations. A readable label is useful; an ambiguous key is still ambiguous after scanning.
Cover the requirement lanes that make execution trustworthy
Definitions and release
Sites, areas, lines, cells, resources, capabilities, people, qualifications, products, BOM and route versions, operations, instructions, parameters, orders, priorities, holds, and release conditions.
Dispatch and operator work
Queues, assignment, acknowledgement, readiness checks, setup, tools, instruction presentation, accessibility, multilingual needs, shift handoff, and supervised overrides.
Materials and genealogy
Issue, verification, substitution, consumption, return, lot and serial tracking, split and merge, unit conversion, scrap, quarantine, labels, genealogy, and reconciliation.
Execution and equipment
Start, pause, resume, complete, quantities, labor, machine state, downtime, process values, edge or device connectivity, manual fallback, delayed events, and corrections.
Quality and exceptions
Checks, sampling, limits, attachments, failures, holds, deviations, nonconformance, disposition, rework, concession, release, signatures where required, and affected-product scope.
Platform and lifecycle
Roles, segregation, audit history, integrations, observability, performance, offline behavior, backup, recovery, deployment, validation evidence, support, retention, export, and exit.
Define scale in operational units: active orders, operations per order, serialized units, material scans, device events per second, concurrent stations, retained history, attachment size, sites, shift changes, network outage length, and acceptable response and recovery time. “Real time” is not a test.
Model state, exceptions, and correction before screens
Draw the permitted state transitions for orders, operations, materials, equipment availability, quality status, and output. Define who may initiate each transition, the evidence required, its downstream effects, and what happens when two signals arrive late or out of order. Do not reduce distinct states such as blocked, held, quarantined, awaiting disposition, cancelled, superseded, and completed to one generic “inactive” flag.
Exceptions are part of the operating model, not an edge case. A good requirement states whether work may continue, which quantity or serials are affected, who decides, how urgency is shown, what must be acknowledged, and how the decision changes instructions, inventory, quality, scheduling, and reporting. The related quality management requirements guide goes deeper on linked quality evidence.
Corrections should preserve the original event and add an attributable replacement, reversal, or adjustment. Editing the latest value in place makes reconciliation easier only until an investigation asks what the system knew at the time.
Map authority across ERP, MES, controls, and operations
The ISA's ISA-95 overview describes manufacturing operations management at level 3 and the exchange between manufacturing and level-4 business systems. Use that model to ask boundary questions, not to assume one product must own an entire layer. Name the authority for orders, product definitions, routes, inventory, equipment state, quality status, schedule versions, execution events, costing, and financial records.
For every interface, define the identifier, payload meaning, direction, cadence, event and receipt time, ordering, duplicate behavior, correction, retry, monitoring, reconciliation, and support owner. The API integration requirements checklist provides a reusable exchange contract. Link to the production scheduling guide when detailed sequencing or replanning is a separate decision.
MES does not need to absorb every adjacent capability. A CMMS can remain authoritative for maintenance work, while inventory, laboratory, quality, or warehouse systems keep their own controlled records. The requirement is a deliberate boundary with reconciliation—not one enormous database.
Design for safe operation, interruption, and recovery
Manufacturing availability and security decisions are joined. The NIST Cybersecurity Framework Manufacturing Profile frames manufacturing security as risk management for systems that include industrial controls. Requirements should therefore define network zones, approved communication paths, device and user identity, least privilege, privileged access, change control, logging, patch and vulnerability ownership, remote support, backups, recovery, and tested manual procedures.
State what continues during a station, site, network, device, or upstream outage. Define locally available instructions, queued events, duplicate protection, clock handling, material and quality restrictions, supervisor escalation, resynchronization, and reconciliation. “Offline capable” is incomplete until the team tests the return online.
Choose the smallest ownership boundary that solves the gap
Configure
A proven MES can represent the real route, evidence, exceptions, interfaces, security, and support model without fragile workarounds.
Extend
The core platform is sound, but a bounded operator workflow, device adapter, integration, exception queue, report, or mobile interface is missing.
Build
A distinctive execution model creates durable value, packaged assumptions repeatedly distort it, and the organization can own validation, support, and lifecycle risk.
Compare licenses, implementation, process and master-data work, hardware and edge components, integrations, validation, training, support, upgrades, observability, export, and exit. A focused custom web application may be appropriate for a bounded operator, exception, or integration layer while established systems retain transactional authority.
Run one difficult-order pilot before broad rollout
- Freeze the route and expected evidence. Record order, product, BOM, route, instructions, resources, materials, checks, outputs, and source versions.
- Run normal execution. Verify release, dispatch, setup, material issue, actuals, checks, completion, postings, and genealogy.
- Break the path deliberately. Add a wrong lot, failed check, unavailable resource, rework, scrap, delayed event, duplicate message, and device or network outage.
- Exercise authority. Confirm holds, escalation, disposition, override, signatures where required, and affected-product scope.
- Correct without erasing. Reverse or supersede an event while retaining the original evidence and downstream impact.
- Recover and reconcile. Restore connectivity, process queued events once, compare quantities and state across systems, and assign every remaining difference.
- Write the decision brief. Record configure, extend, integrate, build, or process-repair decisions with exclusions, acceptance cases, owners, rollout sequence, support, and rollback.
Manufacturing execution system FAQ
What should MES software requirements include?
Include released production orders, product and route versions, work instructions, resources and qualifications, material and lot identity, dispatch, setup verification, start and completion events, quantities and losses, quality checks and holds, deviations, genealogy, labels, approvals, electronic records where applicable, integrations, offline and recovery behavior, permissions, audit history, performance, support, and acceptance evidence.
What is the difference between MES and ERP?
ERP commonly owns commercial demand, product and order records, procurement, inventory accounting, costing, and financial posting. MES commonly controls and records the detailed execution of released work. The exact boundary varies, so requirements should identify the authority for each record and the transaction used to exchange it.
Should MES include production scheduling?
An MES may sequence or dispatch released work, but detailed finite scheduling can remain in ERP, an advanced planning tool, or a specialist scheduler. Define which system owns the approved schedule, which changes operators may make, and how execution delays return for replanning rather than assuming one product must own both planning and execution.
How should a manufacturing execution system be tested?
Run a representative order from release to reconciliation with normal work and difficult exceptions: wrong material, unavailable resource, failed check, rework, split quantity, scrap, device outage, delayed event, duplicate message, corrected record, and interrupted shift. Verify identities, permissions, instruction versions, state transitions, evidence, integrations, recovery, and final postings.