ERP vs. MRP: How Material Planning Fits Inside ERP

In 1964, Joseph Orlicky at IBM built one of the first computerized Material Requirements Planning systems for J.I. Case's tractor plant, replacing a manual reorder-point approach that treated every component's inventory the same way regardless of what it was actually used to build. That reorder-point method worked reasonably well for independent demand items — things a company sells directly, but it broke down for dependent demand: components that are only needed because something else is being built. MRP was the fix, and it's the direct ancestor of the ERP systems manufacturers run today.

What MRP actually calculates

Say a distributor needs to ship 100 units of a finished product in six weeks. The bill of materials shows each unit requires 3 units of a particular component, so the gross requirement is 300 units of that component. MRP nets that gross requirement against what's already available — say 40 units on hand, plus 100 more already on order and due to arrive in three weeks — leaving a net requirement of 160 units still needed. If the component's supplier lead time is two weeks, MRP works backward from when it's actually needed on the shop floor and tells the buyer to place that order now, rather than five weeks from now when someone happens to notice the shelf is running low. That backward scheduling — netting demand against supply and offsetting for lead time — is the entire core of what MRP does, run across every component on every bill of materials, for every open order, simultaneously.

MRP II: adding capacity and finance

By the 1980s, MRP had expanded into Manufacturing Resource Planning, commonly called MRP II, which layered in rough-cut capacity planning (can the shop floor actually produce this schedule given available machine and labor hours), shop floor control, and a connection to standard costing so that material and labor plans tied back to financial projections. That expansion mattered because pure material planning without a capacity check can generate a schedule that looks fine on paper and is physically impossible to execute — MRP II was the fix for planning material and capacity together instead of as two disconnected exercises.

How ERP absorbed MRP as a module

In 1990, Gartner coined the term "ERP" to describe the next expansion beyond MRP II: systems that pulled in finance, human resources, and distribution alongside manufacturing planning, under one shared database instead of a manufacturing-specific system that happened to also touch accounting. Modern ERP systems built for manufacturers still run MRP as a core module — the underlying math hasn't fundamentally changed since Orlicky's original logic, but it now operates as one function inside a much broader system rather than a standalone application.

What's different about running MRP inside ERP vs. standalone

The practical difference shows up in data freshness. A standalone MRP system historically ran on batch data — inventory counts and open orders imported nightly, meaning the MRP calculation was always working from numbers that were, at best, a day old. Inside a modern ERP, purchasing, inventory, and MRP all read from the same live database, so a sales order entered at 10 a.m. factors into that afternoon's MRP run instead of waiting for tomorrow's batch. For a company with long, unpredictable lead times, that gap between a nightly batch and real-time visibility is often the difference between catching a shortage with weeks of runway and discovering it the week material was supposed to ship.

Common MRP settings that trip people up

MRP's math is deterministic, but the inputs are policy decisions that get set once during implementation and then forgotten, often incorrectly:

• Lot sizing rules — lot-for-lot orders exactly what's needed each period; fixed order quantity always orders the same batch size; economic order quantity (EOQ) calculates an optimal batch size based on ordering cost versus carrying cost. Using EOQ on a component with highly irregular demand can generate orders that don't match actual need, creating exactly the overstock EOQ was supposed to prevent.
• Safety stock — a buffer against demand variability and supply uncertainty, but set too high across too many items and it silently ties up working capital that nobody notices until a cash flow review asks why inventory keeps growing faster than sales.
• Planning time fence — the near-term window where MRP shouldn't automatically reschedule open orders, because a supplier or the shop floor may already be committed to the current plan and a system-generated change would just create confusion without actually being achievable.

When MRP doesn't fit

MRP assumes a reasonably stable bill of materials — build the same thing repeatedly against a known recipe. Make-to-order and engineer-to-order manufacturers, where each job may have a unique or heavily modified BOM, often find pure MRP logic a poor fit, since a system built for a stable production plan runs against an operation that's redesigning the product on nearly every job. Those environments typically lean more on project-based planning — treating each order as its own mini-project with its own schedule and resource plan — with MRP logic still handling the more standardized, repeatedly-purchased components underneath the custom work, rather than running the entire operation.

DRP: the same logic applied to distribution

Distribution Requirements Planning takes MRP's core mechanic — netting demand against supply and offsetting for lead time, and applies it across a network of warehouses instead of a bill of materials. Instead of components feeding into a finished product, DRP nets projected demand at each regional warehouse against what's on hand and in transit, then works backward from the central distribution center's shipping lead time to determine when each warehouse needs a replenishment order. A distributor running DRP inside the same ERP that runs MRP for its own light assembly work gets both calculations off the same live inventory data, rather than running a separate standalone tool that has to be reconciled against the ERP's numbers after the fact.

A multi-period MRP example

Extending the earlier example across several weeks shows how MRP actually schedules orders, not just single quantities:

Week	Gross requirement (Component B)	Scheduled receipt	Projected on hand	Planned order release
1	0	—	40	—
2	0	—	40	160 (for week 4 need)
3	0	100	140	—
4	300	160	0	—

Reading the table: on-hand inventory of 40 units at the start covers nothing against the 300-unit gross requirement due in week 4. The 100 units already on order arrive in week 3, bringing available inventory to 140 — still short of the 300 needed. MRP nets the remaining gap (160 units) and, seeing a 2-week supplier lead time, releases that planned order in week 2 so it lands in time for the week 4 requirement. This is the calculation MRP runs automatically, every week, across every component on every open order — the exact bookkeeping a manual reorder-point system has no reliable way to replicate at scale.

Where MRP data quality actually breaks

MRP's math is only as good as the data feeding it, and the two most common sources of bad output are rarely the software itself. An inaccurate bill of materials — a component quantity that's wrong, or an engineering change that updated the physical product but never got reflected in the BOM record — produces confidently wrong requirement calculations that look completely legitimate on screen. Inaccurate on-hand inventory counts, drifting from reality through unrecorded scrap, miscounted cycle counts, or transactions posted to the wrong location, have the same effect: MRP nets requirements against a number that's simply not true. Manufacturers that run tight cycle counting programs and enforce BOM change control as a disciplined process tend to trust their MRP output; manufacturers that don't tend to end up manually double-checking MRP's suggestions anyway, which erases most of the time savings the system was supposed to provide.