MES vs ERP for Mid-Market Manufacturers

ERP plans the work. MES executes it. The two answer different questions, and most mid-market manufacturers evaluating an MES are actually missing the data layer that either one depends on.

The short version: if you cannot answer "what is running right now and how is it going," that is an MES-shaped gap. If you cannot answer "what did we quote, what did it cost, and did we make money," that is an ERP-shaped gap. If you cannot answer either because the numbers live on clipboards, neither product will fix it, and buying one will be an expensive way to find that out.

What each one is actually for

ERP is the business system of record. Quotes, orders, purchasing, inventory, scheduling, costing, invoicing. It operates in units of orders and dollars, and its natural time horizon is days to months. It answers commercial questions.

MES is the execution system for the floor. Work order dispatch, operation-level tracking, machine state, downtime reasons, scrap capture, operator sign-off. It operates in units of operations and minutes, and its natural time horizon is the current shift. It answers production questions.

The clean division: ERP knows a work order for 500 units exists and is due Thursday. MES knows unit 213 is at the deburr station, the operator is Maria, station 4 has been down 22 minutes, and Thursday is no longer realistic.

Direct comparison

The mid-market reality

Both categories were designed for large manufacturers and priced accordingly. What filtered down to the mid-market is usually a smaller edition of an enterprise product, which brings the enterprise assumptions with it.

MES carries the heavier assumption. It expects your process to already be consistent enough to model: defined routings, standard operations, known cycle times, stable work centers. A shop doing high-mix, low-volume, custom work often does not have that, and no amount of configuration creates it. The implementation stalls not because the software is bad but because it is modeling a process that does not hold still.

This is the most common mistake we see in this evaluation. A shop struggles to answer floor questions, concludes it needs an MES, and buys a system that requires the exact process maturity whose absence caused the original problem.

The layer underneath both

ERP and MES both assume the data arrives. Neither is in the business of getting a reading off a machine or out of an operator's head reliably, and both degrade badly when that input is late or wrong.

In most mid-market shops, that is the actual gap. The floor generates data continuously and captures almost none of it in a usable form. An operator reads a value, writes it on a clipboard, and someone types it into a spreadsheet at end of shift. Layering an MES on top of that does not fix the input, it puts a more expensive interface on the same twelve-hour-old number.

Build the capture layer first and two things happen. The floor questions get answered without an MES, because the data now exists. And if you later decide you do need one, you are implementing it on real data instead of aspirational data, which is the difference between a 9-month project and a stalled one. Shop floor data collection covers what that layer involves.

How to tell which one you actually need

You need ERP work if: quoting is guesswork, you find out a job lost money after it shipped, inventory counts disagree with the system, or purchasing is driven by someone walking the racks. These are commercial-side symptoms and no MES will touch them.

You need MES work if: your process is genuinely standardized, you run repeat volume, and the gap is operation-level visibility and dispatch. High-volume repetitive production is where MES pays back fastest.

You need the data layer first if: the honest answer to "what is our scrap rate on that line this week" is that someone would have to go find out. That is true in most mid-market shops, and it is the cheapest of the three to fix.

The contrarian part: most of the overlap is fine

Vendors on both sides argue the boundary because their product needs to cover more ground to justify its price. Modern ERPs include shop floor modules. MES products creep into scheduling and inventory. The overlap is real and the arguing is mostly commercial.

For a mid-market manufacturer the practical answer is usually not two systems. It is one connected system that covers the quote-to-cash chain, with real capture at the floor feeding it. Running a separate ERP and MES means maintaining the integration between them forever, and that integration is where the stale numbers and the finger-pointing live.

That is the pattern behind the marine ERP we built at GatorStep: estimating, production tracking through every stage, a customer portal, and finance all on one system, live in 2.5 months. Not an ERP plus an MES. One system that covered the chain, with capture built in.

A four-question test

1. Can you see, right now, what is running on the floor and how far along it is?
2. Do you know whether the job that shipped last week made money?
3. Is your routing standard enough that the same part follows the same operations every time?
4. Does any number reach a manager without a person retyping it first?

No to 1 and yes to 3 points at MES. No to 2 points at ERP. No to 4 means start there regardless, because both other answers depend on it.

Questions we get

Can an ERP do what an MES does? Partly, and increasingly. Shop floor modules in modern ERPs handle work order tracking and basic operation reporting well enough for many mid-market shops. Where they stop is real-time machine state and sub-minute granularity. If you need to know a machine went down 90 seconds ago, that is MES territory.

Which comes first if we need both? ERP, almost always. It holds the commercial data everything else references, and an MES without accurate part, routing, and order data has nothing to execute against.

Is MES worth it for high-mix, low-volume? Usually not in the traditional sense. The return comes from repetition, and high-mix work does not provide it. Those shops get more from flexible capture and good traceability than from operation-level dispatch.

What about MES for compliance? It helps with operation-level traceability and sign-off, which matters in AS9100 and ISO 13485 shops. It is not the only route. What an auditor wants is retrievable evidence, and the actual AS9100 software requirements can be satisfied several ways.

Our ERP vendor is selling us their MES module. Good idea? Sometimes. The integration is already done, which removes the biggest failure mode. Test it against the process-maturity question first, because a bundled module carries the same assumption about standardized routings that a standalone product does.

How long before either one pays back? That depends far more on adoption than on the product. The systems that pay back are the ones the floor actually uses, which is a design constraint and not a training exercise. Why ERP implementations stall covers the five failure modes, and adoption is the one that most often kills a system that technically works.

What is next

Before you evaluate either category, answer the four questions above. Most shops discover the binding constraint is question 4, and that is good news, because the capture layer is faster and cheaper to fix than either system and it makes both work better afterward.

If the gap is commercial, the NetSuite alternatives for manufacturers covers the ERP field, and can I build my own ERP? compares buying against building. If your floor still runs on clipboards, start there instead.