MRP (Material Requirements Planning) derives time-phased material demand from the master production schedule, the bill of materials and inventory on hand — through three operations: BOM explosion, gross-to-net netting and lead-time offsetting. From over 1,200 projects at Dreher Consulting across the DACH Mittelstand we know: MRP is not just material requirements planning in a warehouse module — it is the methodological ancestor of MRP II and the grammar of every modern ERP production module. Architecture before software. Buyers who skip the three operations write a vague specification and buy software into a methodological vacuum.
What is MRP? Definition, three core questions, three foundational operations
MRP is the time-phased method that calculates material demand per component and per period from a master production schedule, a multi-level BOM and the inventory on hand. It answers three core questions — what, how much, when and where — and rests on three mathematical operations that recur in every ERP production logic.
The Chartered Institute of Procurement & Supply (CIPS) defines MRP as a time-phased disposition method that generates gross requirements and offsets them against inventory to derive net requirements. The lexicon entry in Computer Weekly condenses the three core questions: what, how much, when and where. Three operations drive the methodology:
- BOM explosion. From end-product demand the multi-level bill of materials derives requirements per sub-assembly and per part. A five-level BOM generates five tiers of gross requirements.
- Gross-to-net netting. Inventory, open purchase orders and safety stock are subtracted from gross requirements. What remains is the net requirement — the trigger for procurement or production.
- Lead-time offsetting. The net requirement date is shifted backward by the procurement or production lead time. The result is the start date of the order.
The Cambridge Institute for Manufacturing (IfM) describes these three steps as the universal algorithm of every material requirements calculation — vendor-independent. Reading an ERP system definition without recognising the MRP mechanics underneath misses half of the configuration workload.
The historical trail — MRP, MRP II, ERP
MRP is the methodological ancestor of ERP. Orlicky published the methodology in 1975, Wight extended it in 1984 to MRP II by adding capacity and finance, Gartner coined the term ERP around 1990. This trail is the grammar of every modern production software — the specification must reflect it.
Joseph Orlicky developed one of the first productive MRP systems in 1964 at Black & Decker, documented in the QAD blog on Joseph Orlicky. In 1975 he published the methodological classic Orlicky — Material Requirements Planning, McGraw-Hill; the work is the blueprint for every subsequent MRP system.
Oliver Wight published Manufacturing Resource Planning (MRP II) in 1984 and extended the pure material-demand logic to capacity planning, shop-floor control and financial integration. MRP II became the bridge between materials management and enterprise-wide resource planning. Gartner coined ERP around 1990 — today's ERP system definition would be incomprehensible without that history.
Three lines converge today: the German PPS tradition (production planning and control), the Anglo-Saxon MRP/MRP II tradition, and the modern ERP suites from SAP, Microsoft, Oracle and proALPHA. They share the same methodological foundation — a specification that does not name it cleanly ends up comparing apples and pears.
Project example — DACH machinery builder, five-level BOM, eight-hour MRP run
At a Mittelstand DACH machinery builder (anonymised, around 320 employees), the nightly MRP run took eight hours because procurement lead times were kept in Excel in parallel with the ERP. Appointing a master-data owner plus a clear data policy made the run reliable again. We have seen this pattern repeatedly across DACH machinery in the last 24 months.
The company — five-level BOM, around 18,000 active item numbers, classic variant manufacturing — ran a second-generation ERP. Material requirements planning was nominally executed every night. In practice it ran for eight hours, and in five out of ten nights it broke off before the last BOM level had been exploded.
The cause was not in the algorithm. Across more than 240 master-data records, procurement lead times were maintained in two parallel worlds — once in the ERP, once in an Excel file kept by purchasing. With every run the Excel file was transferred manually, with errors. Lead-time offsetting calculated with outdated values; the MRP run stretched because planned dates blocked each other.
In numerous DACH machinery and Mittelstand engagements in the last 24 months we have seen the same pattern: a named master-data owner, clear rules for master data, and consistent Excel decommissioning. Six weeks later the MRP run completed in 95 minutes and stayed stable. From over 1,200 projects: noticeably shorter project duration if the master-data question is resolved before ERP selection — not afterwards.
What MRP guides in the DACH region leave out
Three points that rarely surface in German-language MRP guides or vendor pitches — yet in the DACH Mittelstand they regularly decide between success and project abort. They follow from over 1,200 projects at Dreher Consulting and the consistent application of the MRP classics.
1. MRP is specification grammar, not module description
Common reading in the Mittelstand: MRP is a module that is either purchased or not. Contrary to most vendor narratives, the decisive factor is not the data sheet but whether the three foundational operations — BOM explosion, netting, lead-time offsetting — fit the multi-level BOM, variant logic and procurement lead times of the specific company. Architecture before software.
2. Master-data quality is the entry ticket to MRP — not a vendor topic
Vendor pitches position AI-driven demand forecasting as a differentiator. Our experience contradicts that framing: AI in MRP does not replace clean master data — it amplifies what is already there. The majority of MRP problems in the DACH Mittelstand are master-data and interface problems, not algorithm problems. A company that maintains lead times and safety stocks in Excel will fail with even the most expensive new system.
3. MRP capabilities separate differentiators from commodities
Many Mittelstand companies list MRP as a single bucket. We decompose it into capabilities — multi-level BOM, variant configurator, lot-sizing, disposition strategy, secondary demand planning — and classify each as differentiator or commodity. Differentiators land as must-haves, commodities as standard. The output is an architecture-validated Lastenheft, not a generic feature list.
Our take
An MRP conversation without algorithm understanding, without master-data realism, and without a capability bridge to the specification ends in a feature comparison. Architecture before software, every time.
MRP in the modern ERP stack — VDI 5600, S/4HANA and the DSAG 2026 numbers
In the modern ERP stack MRP logic sits at the planning layer above the MES (Manufacturing Execution System). VDI 5600 Part 1 is the architecture reference. The DSAG 2026 report shows: MRP and production planning remain almost entirely in the classic ERP core — pure cloud is the exception in the Mittelstand.
The VDI 5600 Part 1 — Manufacturing Execution Systems places MRP and PPS on the planning layer above the MES and defines the interface to shop-floor control. ERP selections without VDI 5600 as architecture rubric risk duplicated function blocks between ERP and MES — and the master-data redundancies that cost twice as much in implementation.
The DSAG Investment Report 2026 (around 198 SAP users across D/A/CH) shows that 42 percent plan high-to-medium investments in SAP S/4HANA On-Premises, only 6 percent in S/4HANA Public Cloud. MRP logic stays almost entirely in the classic ERP core. SAP positions MRP today as integral to S/4HANA with MRP Live — historical MRP logic on in-memory technology, planning in seconds rather than a nightly batch.
The Trovarit study "ERP in Practice 2024/2025" (more than 1,700 DACH companies) puts vendor service quality increasingly under scrutiny — materials management and MRP functions remain a load-bearing evaluation criterion. From over 1,200 projects at Dreher Consulting we know: A company entering ERP selection without a documented target process landscape has no reliable data basis for MRP — and a prepared process architecture noticeably shortens the later implementation. In plain terms: The selection is decided by architecture fit, not the MRP feature list.
Common mistakes in MRP rollouts in the Mittelstand
Four failure patterns appear repeatedly in MRP rollouts in the DACH Mittelstand. All four are avoidable if addressed before ERP selection. None has its root in the algorithm or in a module data sheet. The root lies in organisation, accountability and data policy.
- Mistake 1: MRP as module selection, not methodology. Vendor feature lists are compared rather than asking whether the three operations fit the BOM. Fix: anchor the MRP grammar in the specification first, then evaluate vendors.
- Mistake 2: lead times and safety stocks in Excel. Master data lives outside the ERP, MRP runs work with outdated values. Fix: a master-data owner per material group, clear maintenance rules, Excel decommissioning.
- Mistake 3: lot-sizing undefined. EOQ, exact requirement, Wagner-Whitin or period policy — the choice determines inventory and on-time delivery. Fix: document the disposition strategy per ABC/XYZ class.
- Mistake 4: MES interface undefined. Duplicated function blocks between ERP MRP and MES cause master-data redundancies. Fix: appoint process owners, use VDI 5600 as referee.
Our take: The mistakes are organisational and methodical, not technical — and that is exactly where vendor-neutral ERP consulting earns its keep. Architecture before software, every time.
Frequently asked questions
MRP (1960s, Orlicky) is pure material requirements planning: from the master production schedule, the bill of materials and inventory the material demand is calculated. MRP II (1980s, Wight) extends the methodology with capacity planning, shop-floor control and financial integration — the resource perspective is added. ERP (1990s, Gartner coinage) integrates MRP II with all other business functions — sales, procurement, HR, financial accounting — in a common data foundation. Methodically MRP is the ancestor of ERP, not a synonym.
Four master-data classes are indispensable: multi-level bills of materials with correct quantities, routings with valid throughput times, material master records with procurement lead times and safety stocks, and inventory in real time. From over 1,200 projects at Dreher Consulting: the majority of MRP problems in the DACH Mittelstand are master-data and interface problems, not algorithm problems. Maintenance outside the ERP — typically in Excel — leads regularly to unreliable planning runs.
Lead-time offsetting is the third foundational operation of the MRP algorithm: after BOM explosion and gross-to-net netting, the net requirement date is shifted backward by the procurement or production lead time. The result is the start date of the purchase order or the production order. The Cambridge Institute for Manufacturing describes this step as the universal component of every material requirements calculation — vendor-independent.
In our projects across more than 1,200 Mittelstand engagements we have established a clear order: first anchor the MRP grammar in the specification — three foundational operations, variant logic, multi-level BOM, disposition. Then split the capabilities into differentiators and commodities. Only then evaluate vendors — on architecture, not the feature list. A clean MRP preparation shortens the project duration in our projects noticeably.
Next steps
Before any production-grade ERP selection, a four- to eight-week preparatory step pays off: MRP grammar in the specification, master-data owners per material group, a capability bridge into vendor evaluation. Skipping it risks a doubly expensive restart after eighteen to twenty-four months.
To deepen these topics, see our vendor-neutral ERP consulting and our digitalisation services. We work vendor-neutral — MRP methodology is the sober referee. We also recommend the wiki entries on PPS systems, the ERP system, the Lastenheft and master data, and on process owners. Case studies are in our insights; for a 30-minute conversation with Dr Dreher reach us via the contact page.
30 minutes with Dreher Consulting
A structured pre-clarification of your MRP foundations — the three operations in the specification, master-data owners per material group, and the capability bridge into vendor evaluation, vendor-neutral and drawn from over 1,200 projects across the DACH Mittelstand.
