MES or ERP: which layer should hold what happens on the floor

Comparison criteria

Criteria are stated explicitly and neither option is declared a winner: which one fits depends on the constraint that binds hardest in your operation.

The boundary is a decision, not a product feature

Business systems have extended downward for years and execution products have extended upward, so the overlap is now wide enough that either can be made to cover most of the middle ground. That makes the boundary something you must define rather than discover. Write down which system owns the routing, which one holds the released revision, where labour is booked, where scrap is recorded and how it reaches costing, which one schedules to a work centre and which one sequences within it. Ambiguity here is what produces two systems disagreeing about work in progress, and a spreadsheet that quietly becomes the version everybody trusts.

Data capture is what determines whether either system is believed

Both approaches depend on someone or something recording reality. Where confirmations are typed at the end of a shift from memory or from a paper tally, the resulting record describes the shift as it is remembered, and every report built on it inherits the error. Automated capture at the operation removes most of that, but only where the capture point is designed into the process rather than added beside it. The practical test before any implementation is simple: how does a unit passing an operation become a record, and how many opportunities exist between the two for a human being to guess.

Sequencing plans and executing them are different problems

A business system plans in periods and assumes capacity that is broadly available. A plant makes decisions in minutes about which of three waiting jobs runs next, given the setup currently on the machine, the material actually in the rack and who is on shift. Neither view is wrong; they operate on different horizons. Trouble appears when the planned sequence is treated as an instruction the floor is expected to follow exactly, or when floor decisions never travel back upward. Deciding in advance who may resequence, within what limits, and how that decision returns to the plan avoids most of the friction between the two.

Frequently asked questions

Can a business system alone run a factory adequately?

For plenty of plants, yes. Where jobs are long, routings are short, volumes are modest and traceability requirements are met at lot level, stage confirmations give a workable picture and a second system would add interface maintenance without adding much insight. The signals that this is no longer enough are specific: nobody can locate work in progress without walking the floor, machine downtime is invisible, and traceability questions take days to answer by hand.

What breaks most often when the two are connected?

Master data alignment, usually. Item numbers, units of measure, routings, work centre definitions and revision identifiers have to mean the same thing on both sides, and they drift as soon as either system is maintained independently. The second recurring failure is the handling of exceptions: scrap, rework, partial completions and unplanned material issues are where the interface designers made assumptions, and where the floor immediately finds the cases nobody modelled. Both problems are governance problems rather than technical ones.

Should a plant implement one before the other?

It depends which set of problems is actually costing you. A plant that cannot promise dates, value its stock or see material shortages is describing a planning and transaction problem. A plant that plans adequately but cannot say what happened last night is describing an execution problem. Implementing both simultaneously is possible but concentrates a great deal of change on the same people, and the sequencing decision is usually better made by identifying which failures customers currently notice.