MES vs ERP: which system should actually track what happens on the floor?

The question usually arrives in a disguised form. Someone asks why the ERP says a job took four hours when everyone on the floor knows it took nine, or why standard costs have been wrong for two years, or why the same product line is profitable on one shift and not on another.

The answer is nearly always the same: the ERP is doing exactly what it was designed to do, and what it was designed to do does not include knowing what happened on the floor.

What each system is genuinely for

Question	ERP	Execution layer (MES)
What should we make and when?	Yes	No
What did it cost, for the accounts?	Yes	Feeds it
Do we have the materials?	Yes	No
What is running on machine 4 right now?	No	Yes
Why did operation 20 take 90 minutes instead of 45?	No	Yes
Who ran this batch and on which tooling?	Rarely	Yes
Where did today's scrap come from?	Quantity only	Quantity, cause, operation
Can we trace this shipment back to its raw material lot?	Partially	Yes
Time granularity	Order, shift or day	Event, to the minute

The pattern is clear once you see it. The ERP answers planning and financial questions at order granularity. Execution questions need event granularity, and event granularity is a different data model — not a report you can add to an ERP that was never capturing the events.

Symptoms that you are missing the execution layer

• Standard costs that nobody trusts and that get “adjusted” annually by feel.
• Delivery promises made by asking someone, because the system cannot say what capacity is committed.
• Scrap recorded as a quantity with no cause, so it can be counted and never reduced.
• A whiteboard, or a spreadsheet, that is the real schedule. The ERP schedule is a document; the whiteboard is the truth.
• Traceability that takes days. A customer asks which batch a unit came from, and answering means going through paper.
• Improvement projects that argue about data rather than about what to do.

Two or three of these is normal in a growing manufacturer. All six means you are managing production on anecdote.

What to build first, and in what order

The most common failure here is scoping a complete manufacturing execution system and delivering nothing for a year. Build it as increments, each independently useful.

Increment 1 — work order tracking (2–4 weeks). Operators start and stop operations on a tablet or scanner. The system records who, what, which machine, when. That is all. It sounds trivial and it is the foundation for everything else, because it converts production from a monthly total into a stream of events. On our published bands this is a $3,000–6,000 focused module with a clickable prototype in the first two weeks.

Increment 2 — stop reasons and scrap causes. When an operation pauses, one tap selects a reason from a short list you defined with the floor, not for them. Same for scrap. This is what turns “we lost 40 hours” into “we lost 40 hours, 26 of them to changeovers on one cell”.

Increment 3 — live shop floor view. What is running, what is queued, what is late. One screen, visible to planning and to supervisors. This is where the operators start getting something back for the data they enter, which is what sustains data quality.

Increment 4 — quality and traceability. Inspection results captured at the operation, linked to batch and material lot. Increasingly required rather than optional given EU traceability and product data obligations — see EU export compliance.

Increment 5 — scheduling against real constraints. Only now. Scheduling built on assumed cycle times is arithmetic; scheduling built on measured ones is planning. You need increments one and two to have run for a few months before this is worth doing.

Increment 6 — OEE and analysis. Derived from data already being captured. If OEE is your starting point rather than your output, the numbers will be manual, disputed and abandoned.

Making capture fast enough to survive

This is where these projects live or die, and it is a design problem rather than a technical one.

• Under ten seconds per event. Scan a work order, tap start. Scan, tap stop. If it takes longer, it will be reconstructed from memory at the end of the shift, and reconstructed data is worse than none because it looks real.
• Big targets, gloved hands, poor light. Design for the actual environment. A dense web form designed on a laptop fails on the floor.
• Short lists, defined with operators. Twelve stop reasons that people recognise beat forty that were written in an office. You can always split a category later once you see the data.
• Work offline. Factory wifi drops. The device should queue events and sync when it reconnects, never block the operator.
• Show them something. A screen displaying today’s output, or how the line is running against plan, changes data entry from a tax into a feedback loop.
• Never use it to discipline individuals. The fastest way to destroy data quality permanently is to use the first month’s numbers in a performance conversation. Announce this rule before go-live and keep it.

Integration with the ERP

Keep the boundary clean, and the two systems stay reconcilable.

• The ERP owns items, BOMs, routings, work orders, stock valuation and costing.
• The execution layer owns events: starts, stops, quantities, scrap, causes, operator, machine, batch.
• Pull work orders and routings from the ERP. Do not re-enter them.
• Post back completions, material consumption and scrap on a defined cadence.
• One work order identifier, shared. Every reconciliation problem we have seen in this pattern traces back to two systems inventing their own keys.
• Reconcile daily in the first weeks: quantities completed in the execution layer against quantities posted in the ERP, with differences investigated rather than tolerated.

More on connecting systems is on the integrations page; the manufacturing scope is on the manufacturing page.

Buy or build?

If the answer turns out to be “buy”, the product-by-product comparison with each vendor’s own published prices is kept on one page rather than repeated here: manufacturing ERP for mid-size companies.

Packaged MES products exist and are strong in industries with heavy regulatory validation requirements, or where equipment vendors supply integrated systems.

Building is usually the better answer when your process is unusual — mixed discrete and process steps, heavy customisation per order, subcontracted operations in the middle of a routing, or a plant layout no product models cleanly. That describes a large share of mid-size manufacturing, and it is exactly the situation where a package forces you to record what it expects rather than what you do.

The economics also differ. Packaged systems typically charge per user or per machine, which is awkward when the users are every operator on every shift. A custom build carries no per-seat licence, which changes who can be included — and including everyone is the point of an execution layer. The wider trade-off is set out on package vs custom.

What the data usually reveals in the first month

Companies expect an execution layer to confirm what they already believe. It rarely does. Four findings recur often enough to be worth predicting.

Setup and changeover is larger than anyone thought. Run time is visible and gets managed. Changeover happens between the things people watch, and it is routinely the single largest recoverable loss. Once it is measured, it is usually also the cheapest to reduce.

Waiting is not idleness. Machines stop because material has not arrived, because a fixture is on another job, because a quality decision is pending. These have different fixes and get recorded identically as “down” until stop reasons exist.

Standard times are wrong in both directions. Some operations take half the standard, some take triple. Averaged across a month the total looks broadly right, which is why the error survives for years and why quoting is unreliable while it does.

Scrap concentrates. It is rarely distributed evenly across products and shifts. It clusters on a particular operation, a particular tool, or a particular changeover sequence, and the cluster is invisible until scrap carries a cause code.

None of these findings is comfortable, and all four are actionable, which is the point. If the organisation is not prepared to act on uncomfortable findings, the honest recommendation is to spend the budget elsewhere.

Hardware and capture: the boring decisions that determine success

• Devices. Rugged tablets on stands at cells, or shared terminals at stations. Handheld scanners where operators move. Personal phones work for maintenance and quality rounds and rarely for line work.
• Identification. Barcodes on work order travellers are the cheapest reliable method. QR codes carry more and tolerate damage better. RFID solves specific problems at meaningfully higher cost — justify it per use case, not as a platform choice.
• Network. Assume it drops, because it will. Local queueing with background sync is not an optimisation; it is the difference between a system operators trust and one they route around.
• Login. Badge scan or a four-digit code. Anything requiring a password typed on a touchscreen with gloves will be shared between operators within a week, and shared logins destroy the attribution the whole system exists to capture.
• Power and mounting. Unglamorous, and the most common reason a pilot cell works and the second cell does not.

Decide these with the people who will use them, on the floor, before the build. Every one of them is cheap to change in week one of design and expensive to change after fifty devices are deployed.

The realistic caution

An execution layer does not improve anything by itself. It tells you the truth about where time and material go, and the truth is often that the biggest loss is in changeovers, or in waiting for material, or in one product line nobody wanted to examine.

If nobody is going to act on that, do not build it. If somebody is, start with one cell and one increment, and expand only after the data is being used to make a decision.

Delivery bands and timelines are on the pricing page, the segments we typically build for on who we build for, and a first module can be scoped through the quote form.

Frequently asked questions

Do we need a separate MES, or can our ERP handle production?

Most ERPs can record that a work order was completed. Few record what happened during it at a useful granularity — start and stop times per operation, machine, operator, downtime reason, scrap and its cause. If you only need cost postings, the ERP is enough. If you need to know where time actually goes, it is not.

What is the first thing to measure on the shop floor?

Time. Specifically, the gap between planned and actual duration per operation, and the reasons for stops. Almost every other improvement metric is derived from that, and most companies discover their biggest losses in setup and changeover rather than in run time.

Is OEE worth calculating?

Yes, provided the inputs are captured automatically and the definitions are agreed before anyone sees a number. OEE calculated from manually entered data measures reporting discipline rather than equipment. Agree what counts as planned downtime first, in writing, or the number becomes a debate instead of a decision tool.

Do operators actually record data reliably?

Only if it takes seconds. A tablet with large buttons and a scan-to-start flow gets used; a form with fourteen fields does not. If capture takes longer than about ten seconds per event, expect the data to be filled in at the end of the shift from memory, which makes it worse than no data.

How does an execution layer connect to the ERP?

The ERP remains the system of record for orders, BOMs, stock valuation and costing. The execution layer pulls work orders and routings from it, records what happened, and posts back completions, consumption and scrap. One identifier per work order, shared, and no duplicated master data.

What does this cost to build?

On our published bands, a focused first module — work order tracking with start and stop capture on the floor — runs $3,000–6,000 over 2–4 weeks with a prototype in the first two weeks. A multi-department system covering scheduling, quality and maintenance runs $8,000–15,000 over 4–8 weeks.

Related guides

• ERP customer portal vs dealer portal: which one your network needs
• AI automation: how European, Gulf and Turkish buyers differ
• AI workflow automation vs RPA: choosing the right layer

Service page: Package vs custom