Sit in on a software evaluation at a growing manufacturer and you will eventually hear a version of this exchange. Operations says the floor needs work instructions and real traceability. Finance says the ERP already has work orders. Quality says the eQMS already has document control, so the instructions should live there. IT asks, reasonably, why the company would buy a third system when two already claim to cover the same ground.
Everyone in that room is partly right, which is exactly why the conversation stalls. MES, ERP, and eQMS genuinely do touch the same nouns — work orders, documents, parts, people — and from a distance their feature lists look like they overlap by half. Up close, they are doing three different jobs, and the overlap is mostly vocabulary.
The practical consequence of getting this wrong is not that a company buys the wrong software. It is that records end up in places that were never designed to produce them: quality events buried inside ERP transaction comments, production execution forced through an approval workflow built for documents, and shop-floor traceability reconstructed by hand from three systems and a binder because no system owns it.
Three systems, described the way a plant manager would describe them
Skip the category definitions from analyst reports for a moment. Here is what each system actually does on a Tuesday.
MES: the system that runs the job at the workstation
A Manufacturing Execution System is what the operator uses while building the product. It presents the correct revision of the work instruction, sequences the steps, collects measurements and signatures at the point they happen, records which material lot and which piece of equipment were used, and enforces the rules — you cannot skip step 7, you cannot proceed with an out-of-tolerance reading, you cannot run an operation you are not trained for.
The output is not just product. It is a complete, time-stamped account of how each unit was built, produced as a byproduct of building it. MES is the system of record for execution.
ERP: the system that runs the business around the job
An Enterprise Resource Planning system decides what should be built and keeps the commercial and material picture straight. It holds the item master and bills of material, plans demand, issues purchase orders, tracks inventory balances and valuation, manages customer orders and shipments, and rolls everything up into cost and financial reporting.
ERP is where a work order is born and where it is financially closed. Between those two moments, ERP is largely uninterested in the details — and that disinterest is by design. It is a planning and accounting system, and planning systems get slow and brittle when you push step-level detail into them.
eQMS: the system that runs the quality system itself
An electronic Quality Management System manages the processes that prove your quality system works and keeps it improving: controlled documents and their revisions, change control, nonconformances and deviations, CAPAs, complaints, supplier quality, internal and external audits, and training records with qualification status.
The defining characteristic of eQMS content is that it is an event or a document requiring review and approval — something that happens occasionally, involves multiple functions, and needs a defensible trail of who decided what and why.
MES — how it was built
Execution, step by step, unit by unit. Instructions, in-process data, signatures, equipment, genealogy, live status.
ERP — what to build and what it cost
Demand, materials, inventory, purchasing, orders, planning, costing, and the master data everything else references.
eQMS — how quality is governed
Controlled documents, change control, deviations, CAPAs, audits, training, and the workflows that approve them.
Where they look like they overlap — and where they actually differ
The overlap is real, but it is narrower than the demos suggest. Three areas cause almost all of the confusion.
The word "work order" means three different things
In ERP, a work order is a planning and costing object: build 250 of part number A-1147, consume this material, absorb this labor, close it out. In MES, the same work order is an executable job: eleven operations, forty-three steps, nine data collection points, four signatures, two inspections. In an eQMS, "work order" may not exist at all, but a related concept does — the change order that released the revision the job is running to.
Same words, three different objects. When people argue about which system "has" work orders, they are usually arguing about different nouns.
Documents versus instructions
An eQMS controls documents: it owns the approval, the effective date, the revision history, and the training requirement attached to a procedure. That is document control, and it is genuinely the eQMS's job.
What an eQMS does not do is execute a document. A controlled PDF served to a tablet is still a document — the operator reads it, then records their work somewhere else. MES turns the released content into interactive steps that collect the record as they are performed. The eQMS should still own the release; MES should own the execution of what was released. We cover the practical difference in what makes great digital work instructions.
Inventory versus material identity
ERP knows you have 1,400 of component C-22 on hand, across three lots, at a certain valuation. MES knows that unit serial 000871 consumed lot 22-B at step 12, scanned by an operator at 09:41, on fixture F-3.
Both are "inventory," and both are correct. Only one of them can answer a supplier recall notification in minutes. ERP owns the balance; MES owns the genealogy. Trying to make ERP carry unit-level genealogy is where a lot of small manufacturers spend eighteen months and end up back on spreadsheets.
| MES | ERP | eQMS | |
|---|---|---|---|
| Primary question answered | How was this unit actually built? | What should we build, buy, and charge? | Is the quality system controlled and improving? |
| Primary users | Operators, supervisors, manufacturing engineers | Planning, purchasing, finance, customer service | Quality, regulatory, document control |
| Time horizon | Right now, at the step | This week to this quarter | Event-driven, weeks to months |
| Granularity | Step and unit level | Order and part-number level | Document and event level |
| Data created by | The work itself, as it happens | Transactions and planning runs | Reviews, investigations, approvals |
| Owns work instruction content | |||
| Owns execution of instructions | |||
| Owns inventory balances and cost | |||
| Owns unit-level genealogy | |||
| Owns CAPA and change control | |||
| Owns live production status | |||
| Owns training qualification |
"Partial" means the system holds or enforces part of the record but is not its source of truth. MES enforces training gates, for example, but the qualification itself is governed by the eQMS.
Which records belong where
The cleanest way to settle a system boundary argument is to stop discussing features and start sorting records. Below is the mapping that holds up in most discrete manufacturing environments, medical device included.
Records that belong in MES
Work orders in execution
The job as it is actually being run: operations, steps, sequence, and current position.
Operator activity
Who performed each step, when they performed it, and the signature applied at the point of work.
Process steps and revisions in use
The exact instruction content the unit was built to, retained with the record.
Equipment and station data
Which machine, fixture, or tool was used, and whether it was in calibration at the time.
In-process checks and measurements
Values captured at the step, with limits enforced at entry rather than reviewed later.
Traceability and genealogy
Component lots and serials consumed, linked to the finished unit that contains them.
Production status
Live position of every open job: in process, awaiting inspection, on hold, complete.
The device history record
Assembled continuously from the above, rather than compiled afterward from paper.
Rework and disposition execution
The steps performed to rework a unit, recorded against the unit, referencing the quality event.
Records that belong in ERP
Inventory balances and valuation
What is on hand, where, and what it is worth.
Purchasing and receiving
Purchase orders, receipts, supplier delivery performance, and payables.
Costing and financials
Standard and actual cost, margin, and the general ledger.
Planning and scheduling
Demand, MRP, capacity, and release of work orders to the floor.
Order management
Customer orders, shipments, invoicing, and returns.
Master data
Item masters, bills of material, supplier and customer records that other systems reference.
Records that belong in eQMS
Nonconformances and deviations
The investigation, the disposition decision, and the approvals behind it.
CAPAs
Root cause analysis, corrective and preventive actions, effectiveness checks.
Change control
Proposed changes, impact assessment, approvals, and effective dates.
Document control
Controlled procedures, specifications, and work instruction content with revision history.
Audits and complaints
Internal and external audits, findings, customer complaints, and regulatory reporting.
Training records
Who is qualified to perform what, and when requalification is due.
Common boundary mistakes, and what they cost
Quality events buried in ERP
A part fails inspection. Someone moves it to a "hold" location in ERP and types a note in the transaction comment. Operationally that is enough to stop the material from shipping, so it feels resolved.
Six months later, quality is asked whether that failure mode is trending. The evidence exists only as free text scattered across inventory transactions, so the honest answer is that nobody knows. There was never an investigation, never a disposition record, never a link to the units affected — because the system it landed in has no concept of any of those things. Holds in ERP are a material action. They are not a quality record.
Production execution forced into the eQMS
This one usually starts well-intentioned: the eQMS already controls the work instruction, so why not have operators complete it there? Within a few months the symptoms show up. Every routine build touches an approval workflow designed for documents. Operators need twelve clicks to record what took one line on paper. The system is slow at the workstation because it was built for occasional office use.
And then the real failure: people start keeping a shadow paper packet to actually run the job and back-filling the eQMS at the end of the shift. You now have the cost of a digital system and the data quality of a paper one — the exact problem covered in real-time capture versus paper travelers.
Traceability handled outside any system
The most common arrangement at small manufacturers is that genealogy lives in a binder and a spreadsheet. ERP knows the lots were consumed in aggregate; the binder knows which serials they went into, if someone wrote it down legibly.
The cost is invisible until the day a supplier issues a lot notification. Then two people spend a day defining the recall scope, and the scope they define is wider than it needs to be, because uncertainty always rounds outward. FDA traceability explained walks through the full chain.
Expecting ERP shop-floor modules to be an MES
Most ERPs include labor reporting and operation completion. That is enough to close a work order and absorb cost. It is not enough to guide a build, enforce a sequence, hold a signature at a step, or reconstruct how a specific unit was made. The gap is usually discovered after go-live, when the paper packet quietly reappears alongside the ERP terminal. Our piece on why routers are not execution covers this in detail.
The same record maintained in two systems
Training status in both eQMS and MES. Item revisions in both ERP and the instruction library. Open nonconformances tracked in a quality spreadsheet and in the eQMS.
Duplicated records do not stay synchronized, and the failure is silent. One system says the operator is qualified; the other says the qualification lapsed in March. Both are confidently wrong to somebody. One owner per record, referenced everywhere else, is the only arrangement that survives contact with a busy quarter.
How the three should connect
Clean boundaries are only half the answer. Separated systems that do not talk to each other create their own tax — re-keying, reconciliation, and three versions of "current." The goal is separation of purpose with connection of data.
Four integration principles worth holding to
One owner per record
Every record has exactly one system of truth. Other systems reference it by ID; they do not keep their own editable copy.
Link, do not duplicate
A nonconformance in the eQMS should point at the affected serials in MES. Copying the details into both guarantees drift.
Control flows down, evidence flows up
Released revisions and training qualifications flow into execution. Completed work, measurements, and events flow back out.
Integrate at the pace of the decision
Execution data needs to be current in seconds. Financial postings can be batched hourly or nightly. Do not over-engineer the slow paths.
Sequencing for a small manufacturer
Most companies with 5 to 150 employees already run an ERP of some kind, even if it is modest. Quality often runs on controlled documents and spreadsheets, which is workable longer than people expect. Execution is usually the true gap: the floor is on paper, and every other system is being asked to compensate for that.
The practical sequence is to fix whichever set of records is currently being reconstructed by hand. If your team spends days assembling a DHR, compiling a batch record, or answering "where is this order," that is an execution gap, and no amount of ERP or eQMS configuration will close it. If instead your team is losing time to CAPA tracking and audit prep across email threads, the eQMS is the higher-value move. Buying in the order a vendor recommends is rarely the same as buying in the order your records demand.
Frequently asked questions
The practical takeaway
MES, ERP, and eQMS are not competitors, and the question is not which one is most important. The question is whether each record your company produces has a clear, intentional home in the system that was designed to produce it.
When boundaries are clear, each system gets better at what it does. ERP plans and accounts without drowning in step-level detail. MES gives the floor current instructions and produces a complete record as work happens. The eQMS handles the exceptions and the controlled documents with the rigor those deserve. Traceability, compliance, and visibility come from the connections between them, not from any one system trying to absorb the others.
When boundaries are unclear, everything gets harder in a way that is difficult to attribute. Reports disagree. Audits take longer than they should. People build spreadsheets to bridge the gaps, and those spreadsheets quietly become the real system of record.
Separate by purpose. Connect by reference. Give every record one owner, and make that owner the system where the record is actually created.
Are your systems clearly separated — and still connected?
Take one record type that causes recurring friction — genealogy, a DHR, training status, open nonconformances — and ask which system creates it, which system owns it, and how many places it is stored. The answer usually explains more than a feature comparison would.