MRP vs ERP vs MES: Match the system to the manufacturing decision
Compare MRP, ERP and MES by the decisions each supports. Map material planning, business records and shop-floor execution before choosing software.
MRP addresses material planning, ERP connects broader business records, and MES addresses production execution on the factory floor. Start with the decision you cannot make reliably, then test the relevant capability. The names do not tell you how a particular product is configured or whether you need three separate systems.
A plant may need better component planning without needing a new machine-data platform. Another may already plan purchasing adequately but lack timely production records. Those situations deserve different demonstrations.
Separate the three questions
Material requirements planning asks what material is needed, in what quantity and when. SAP's MRP explanation describes calculating material needs and recommending production or purchasing activity. Its discussion places MRP within a broader ERP environment. SAP's MRP explanation
ERP, in this comparison, is the broader business system connecting functions such as orders, purchasing, inventory and finance. MES focuses on managing, monitoring and controlling production execution, connecting enterprise planning and shop-floor activity. SAP's manufacturing execution definition
These are useful categories, not clean walls. For example, Odoo 19.0 documents Shop Floor as a companion to Manufacturing for processing manufacturing orders and work orders and recording time. A product called an ERP can therefore include execution functions. That does not establish equivalence to every dedicated MES. Odoo 19.0 Shop Floor
Put the missing decision in a row
Use this responsibility map before comparing vendor brochures. The category is a starting point for testing, not an automatic product recommendation.
| Decision you need to make | Evidence required | Capability to investigate first |
|---|---|---|
| What components must we buy for confirmed demand? | Demand, BOM, usable inventory, open supply, timing assumptions | MRP |
| Can we promise an order given purchasing and production commitments? | Connected order, supply and capacity evidence | ERP plus planning capability |
| Which operation is actually running now? | Work-order status, operator input or machine events | MES or ERP execution functions |
| Which revision and instructions should the operator use? | Approved revision, effective use and work-order instructions | Engineering and execution connection |
| Why does recorded cost differ from the expected job cost? | Actual consumption, time and financial treatment | ERP with reliable execution inputs |
| What happened when a machine stopped? | Event, affected work, response and recovery | Execution and equipment-data capability |
Write the required freshness beside each answer. “We need it eventually” and “the dispatcher must know before assigning the next order” imply different requirements. Do not turn “real time” into a checkbox without specifying which event, which record and how much delay the business can tolerate.
Follow one shortage through the boundaries
Consider an invented order for 30 assemblies. Each requires two housings. The gross requirement is 30 × 2 = 60 housings. Only 45 are usable, and this simplified example assumes no open supply and no other competing demand. The immediate gap is 60 − 45 = 15 housings.
That calculation is a material-planning question. Deciding whether to buy more, resequence production or change a promise date requires additional business information. Recording that an operator completed a partial run is an execution question. Reconciling consumption and costs depends on the records connecting those events.
Now ask the vendor to change one input: five housings fail inspection. The usable quantity becomes 40 and the simple gap becomes 20. Where is that change recorded? Who sees it? Does the plan use the revised usable quantity? What prevents rejected material from being treated as available?
These are proposed tests. The arithmetic is intentionally small; it is not a complete MRP calculation or a demonstration of any named product.
Decide who owns each record
If more than one system participates, record the authority for item IDs, BOM revisions, work-order releases, actual quantities and corrections. Two systems can display the same order number while disagreeing about its state.
For each connection, ask how a failed transfer is detected and who repairs it. Test a correction as well as the first successful transfer. A demonstration that sends “10 completed” once does not explain what happens when that entry should have been eight.
If one system supplies all the functions, ask the same questions within it. A shared product name does not remove the need for clear responsibilities and usable records.
Before selecting a category, trace a current order through the business. Circle the first decision that lacks reliable evidence. Build the demonstration around that decision and its next handoff. You may find you need a different configuration, better data, a specific execution capability, or a broader replacement. The evidence should determine which.