Why MRP Is Not a Schedule
MRP (Material Requirements Planning) tells you what to make and roughly when. It has no concept of a schedule in the sense a shop floor needs one — it never decides which job runs first when two orders want the same machine at the same hour, because it was never built to look at more than one order’s timeline at once. Calling MRP output “the schedule” is the single most common category error in production planning, and it’s worth being precise about exactly where the error is, because the fix isn’t “run MRP more” — it’s adding a layer MRP was never designed to be.
What MRP actually produces
MRP’s job, mechanically, is straightforward: compare supply against demand for every item, at every level of every bill of materials, and propose actions to close the gap. Demand comes from sales orders, forecasts, and safety stock rules; supply comes from on-hand inventory, open purchase orders, and existing production orders. When it runs, MRP emits a set of action messages — New (create a purchase or production order), Change Quantity, Reschedule, or Cancel — each one carrying a proposed quantity and a proposed date, computed by working backward from a due date through the item’s lead time, or through its routing’s estimated setup and run time.
That date math is real and useful, but notice what it’s answering: when should this order’s work roughly start, assuming nothing else competes with it. MRP computes each order’s dates independently, one bill-of-materials explosion at a time. It has no step anywhere in the calculation that asks “what else is this order competing with for the same work center that same morning” — the same infinite-capacity assumption covered in finite vs. infinite capacity is baked into MRP’s date math from the ground up, because MRP predates capacity-aware planning entirely; it was solving a materials problem, not a machine-contention problem, long before “finite scheduling” was a phrase anyone needed.
MPS vs MRP, in the same system, is a scope distinction, not a capability one: Master Production Scheduling plans only the top-level, sales-driven items, while full MRP cascades that demand down through every level of the bill of materials to generate the dependent orders for sub-assemblies and raw materials underneath. Neither mode changes what’s being computed — quantities and dates — only how far down the bill of materials the calculation reaches. A finished cupcake order run through MPS alone stops at the cupcake; the same order run through full MRP also proposes the batter, the frosting, and the packaging underneath it — but at every level, top or bottom, the output is still a quantity and a date, never a position in a queue on a shared mixer.
The gap, stated precisely
Here is the sentence that gets glossed over constantly: MRP says “start Monday.” Nothing in MRP decides which job actually runs first on the mixer Monday at 07:00 if three different orders all computed out to a Monday-morning start on that same machine.
MRP produced three technically-correct dates. It did not, and structurally cannot, resolve the collision between them, because resolving that collision requires comparing multiple orders against each other on a shared resource at the same moment in time — a fundamentally different kind of computation than “work backward from this one order’s due date.” This is exactly the planning-vs-scheduling boundary covered in what is production scheduling: MRP lives entirely on the planning side of that line. It answers what and roughly when, in quantities and days. It has nothing to say about which job and in what exact order, in machines and minutes — and that second question doesn’t get easier to ignore just because the first one was answered correctly.
A shop that only runs MRP experiences this gap as a very specific, recurring failure: the numbers on the report are internally consistent and the report itself is correct — and the shop floor still doesn’t know what to run first, because nobody, human or software, ever answered that question for them. The plan and the floor diverge not from a bug, but from asking MRP a question it was never built to answer.
A worked example: three technically-correct dates, one real machine
Say a bakery takes three sales orders in the same week — vanilla cupcakes due Thursday, chocolate cupcakes due Thursday, and a red-velvet order due Friday — each for a different finished good, each drawing on the same shared mixer as its first routing operation. MRP runs a regenerative plan across all three. For each one, independently, it works backward from the due date through the routing’s estimated time and the item’s lead time, and proposes a planned production order with a computed start date. Because all three due dates cluster in the same few days and the routing times are similar, MRP proposes a Mix operation starting Monday morning for all three — not because anything is wrong with the calculation, but because each computation never looked at the other two while it ran.
The planner reviews the action messages, they look sound individually, and carries all three out. Three firm planned production orders now exist, each correctly dated, each pointed at Monday morning on a mixer that can only run one batch at a time. Nothing in MRP’s process — not the calculation, not the review step, not the carry-out — ever compared these three orders to each other on that shared resource, because comparing multiple orders against a shared resource was never the question MRP was computing an answer to. The collision isn’t a data error waiting to be found; it’s an entire category of question MRP’s math doesn’t ask.
Why running MRP more often doesn’t close it
The instinctive fix, when this gap starts to hurt, is to run MRP more frequently — daily instead of weekly, or trigger a rerun the moment a sales order changes. This helps with a real, adjacent problem (stale demand data), but it does nothing for the sequencing gap, because rerunning the same calculation more often doesn’t add a capability the calculation never had. Ten MRP runs a day still each independently compute “start Monday” for three orders on the same mixer, ten times, without ever comparing those three orders to each other. The frequency of the run and the kind of question the run answers are two separate variables, and only the second one determines whether the mixer collision gets resolved.
Worse, running MRP too aggressively introduces a cost of its own: planning nervousness. Because MRP’s lot-sizing and lead-time offset logic can be sensitive to small input changes, a minor shift in a top-level forecast or a single sales order can cascade down through every level of the bill of materials, quietly changing the proposed dates and quantities on dozens of lower-level planned orders that had nothing directly to do with the change. A single sales order for the finished good, bumped by a customer from 200 units to 220, can ripple downward through every sub-assembly and raw-material level of that item’s bill of materials — a batter quantity here, a packaging-component reorder point there — each recomputed and re-dated, even though the shop floor’s actual near-term reality barely moved. A planner who reruns MRP constantly and carries out every action message without review can end up chasing a plan that rewrites itself daily — not because the shop’s real situation changed that much, but because the calculation is sensitive enough that it looks like it did. The discipline that controls this (reviewing action messages rather than blindly carrying them all out, and running a full regenerative plan on a deliberate cadence rather than reflexively) is real and worth having — but it manages MRP’s own volatility. It still does nothing to resolve which job runs first on a shared machine, because that was never the question nervousness-control was answering either.
It’s worth being precise that MRP nervousness and the mixer-collision problem above are two genuinely different failures, easy to conflate because both show up as “the plan doesn’t feel trustworthy.” Nervousness is MRP being too sensitive to its own inputs — producing volatile, over-reactive dates from small changes. The mixer collision is MRP being correctly stable and simply blind to a question it was never asked. Fixing one does not touch the other: a shop could run a perfectly disciplined, low-nervousness MRP process and still send three orders to the same machine at the same hour every single week, because discipline about when to rerun MRP has no bearing on what MRP is capable of computing once it runs.
What actually closes the gap
The gap between “MRP says start Monday” and “the mixer schedule says order B, then order A, then order C, in that exact order, at these exact times” is closed by adding a layer on top of MRP’s output, not by tuning MRP itself: a scheduling layer that takes the set of orders MRP has already proposed — usually once they’re firm planned or released — and does the thing MRP structurally cannot: compare every order against every other order competing for the same resource, and produce a specific, non-overlapping sequence. That’s finite-capacity scheduling, and at its fuller extent, an APS system.
The handoff point matters operationally, too: MRP’s action messages, once carried out, create the firm planned production orders that become the scheduling layer’s input. Nothing about adding a scheduling step requires changing how MRP runs, what it plans, or how often — it requires accepting that MRP’s dates are the starting proposal for a downstream question, not the final answer to it. In Microsoft Dynamics 365 Business Central, this is exactly where Business Central’s own planning worksheet hands off in practice; the Microsoft Learn overview of Business Central’s supply planning describes the planning half of this line in more procedural detail — this page has been about where that half ends.
Where SmartFlow fits
SmartFlow APS picks up exactly at that handoff: it takes the firm planned production orders Business Central’s planning worksheet has already produced, and adds the finite-capacity scheduling layer MRP was never built to provide — checking every operation against every other operation competing for the same work center, so no machine is ever double-booked in the resulting plan. It does not replace the planning worksheet or second-guess its quantities; it starts where MRP’s job ends. See the User Guide for how that handoff works in practice.
Key terms
New to the vocabulary? MRP, MPS, planned order, firm planned order, and nervousness are defined in the glossary.