MRP vs ERP: Where One Ends and the Other Begins

The short answer

MRP is a calculation. ERP is a system of record. An ERP typically contains an MRP function; MRP is not a smaller ERP, it is one of the things an ERP does.

The confusion is historical rather than conceptual, and the history is worth two paragraphs because it explains why the terms overlap the way they do.

How the terms arrived

Material requirements planning came first, in the 1960s, answering one question: given what we intend to build and what we already have, what must we buy or make, and when? That is all it did, and it was a significant advance over ordering by intuition.

MRP II — manufacturing resource planning — extended it in the 1980s to capacity: not just the materials but the machine hours and labour needed, and whether the plan was achievable at all.

ERP generalised that in the 1990s to everything else the business runs on: finance, HR, sales, procurement, all against one shared data model. The lineage is why an ERP's planning function still looks like MRP — it is MRP, now sharing a database with the general ledger.

What MRP actually computes

Three inputs, one output. The inputs:

• The master production schedule: what finished goods you intend to produce, in what quantity, by when.
• The bill of materials: what each finished item is made of, level by level.
• Inventory status: what is on hand, what is already on order, and what is already committed to other demand.

The output is a set of planned orders — purchase orders for bought parts, work orders for made parts — each with a quantity and a date.

The core step is netting. For each item, at each level, MRP asks: how much is required, how much do I already have or expect, and what is the difference? That difference is the net requirement. It then offsets the date backwards by the item's lead time, so the order is placed early enough to arrive when needed.

A netting example

You plan to build 200 lamps in week 10. Each needs 1 arm assembly; each arm assembly needs 2 arm tubes.

1. Gross requirement for arm assemblies in week 10: 200.
2. On hand: 50. Already on order: 30, arriving week 8. Net requirement: 120.
3. Arm assembly build lead time is 2 weeks, so a work order for 120 is planned for release in week 8.
4. That order creates a gross requirement for 240 arm tubes in week 8.
5. Arm tubes on hand: 100, none on order. Net requirement: 140.
6. Purchase lead time is 3 weeks, so a purchase order for 140 tubes is planned for release in week 5.

That cascade — level by level, netting then offsetting — is the whole of MRP. Everything else is refinement: lot sizing, safety stock, scrap allowances, firm-planned orders that the next run must not move.

Why MRP runs are famously wrong

MRP is arithmetic on three inputs, so it inherits every error in them, and amplifies them through the explosion.

Inventory accuracy is the usual culprit. If the system believes you hold 100 arm tubes and you hold 60, MRP under-orders by 40 and the shortage surfaces on the line. This is why cycle counting is a prerequisite for MRP rather than a nice-to-have: below roughly 95% inventory accuracy, the output is not trustworthy enough to act on.

Lead times are the second. They are usually entered once at item creation and never revisited, so the plan is offset by a number that described a supplier relationship from years ago.

Lot sizing: how much, not just when

Netting tells you a shortfall of 140 units. It does not tell you to order 140 — that is the lot-sizing rule, and the choice materially changes how much stock you carry.

• Lot-for-lot: order exactly the net requirement. Minimum stock, maximum number of orders. Right for expensive items and short lead times.
• Fixed order quantity: always order in a set batch — a pallet, a reel, a furnace load. Right where the supplier or the process imposes the quantity.
• Minimum and multiple: a floor plus a rounding rule. Order at least 500, in multiples of 100. The most common real-world setting.
• Period order quantity: group every requirement in the next two weeks into one order. Fewer deliveries, more stock.

Economic order quantity sits behind these as the textbook answer — the batch size where ordering cost and carrying cost balance. It is useful as a sanity check and poor as an operating rule, because it assumes steady demand and ignores the supplier's actual constraints.

Time fences, and why plans flap

An MRP run recomputes everything from current data. Run it daily and the plan changes daily — sometimes for a trivial reason, like one sales order moving by a day, which cascades into rescheduled work orders at every level below it.

This is system nervousness, and it is the most common reason production teams stop trusting the plan. If today's schedule contradicts yesterday's for no visible reason, people revert to judgement.

Time fences are the fix. The horizon is divided into zones with different rules:

The frozen zone has to be at least as long as your build lead time. Shorter, and the system can reschedule an order that is already being made.

Firm planned orders do the same job for an individual order: pinned so no run may move or resize it, no matter what the arithmetic says. The right use is an order you have already committed to a supplier.

What MRP II added

MRP answers whether you will have the materials. It says nothing about whether you have the hours, which is why its plans can be arithmetically perfect and physically impossible.

Capacity requirements planning takes the planned orders, applies each item's routing — the operations, the work centres, the setup and run times — and produces a load profile per work centre per period. The output is the question MRP cannot ask: this plan needs 420 hours on the CNC cell next week, and the cell has 300.

What you do about it is a decision rather than a calculation — move work earlier into spare capacity, add a shift, subcontract, or move the promise. The value is seeing it three weeks out instead of on the morning it fails.

Do you actually need MRP?

Not every manufacturer does, and running it badly is worse than not running it.

Reorder points are enough when demand is relatively steady, BOMs are shallow, and components are shared across products. Each item is replenished on its own level and the arithmetic in the previous guide covers you.

MRP earns its complexity when demand is lumpy or project-driven, when BOMs are deep enough that a change at the top cascades several levels, when components have long lead times that must be committed before firm orders exist, or when you build to order and every order has a different structure.

The honest test: if you can answer "what do I need to buy this week" by looking at stock levels, you do not need MRP. If answering it requires exploding a schedule through several levels of assembly, you do — and a spreadsheet will not hold that for long.