Material requirements planning: the calculation and the data it punishes you for

What the run actually does, level by level

Demand at the top comes from customer orders and whatever forecast the business has agreed. The calculation nets that against stock on hand and open supply, then reads the product structure to work out what components the remainder needs, repeating the exercise down every level. At each step it shifts the required date backwards by the lead time held on the record and applies whatever order sizing rule is configured. The output is a set of proposed purchase and works orders with dates. Nothing in that sequence involves judgement, which is precisely the point and precisely the risk: the arithmetic will faithfully propagate any wrong figure it is given.

Three inputs decide whether the output is usable

Product structures must reflect what is really consumed, including the fasteners and consumables people leave off, and must match the revision being built. Stock records must correspond to what is physically in the racks, which is a counting discipline rather than a software feature. Lead times must be the time it genuinely takes rather than the time somebody typed in when the record was created. Weakness in any one of the three produces the same visible symptom, which is a planner who reviews every proposal by hand. Fixing the data is slower and less appealing than reconfiguring the system, and it is almost always the actual remedy.

Why the plan changes every time you run it

A small movement in a top-level date can cascade through several levels and reschedule dozens of component orders, sometimes back and forth on consecutive days. Planners call this nervousness and it destroys trust faster than any single wrong figure, because suppliers start treating your date changes as noise. The controls are structural: a period near term in which the schedule is frozen and only exceptions may change, planned orders that a planner has firmed so the run cannot move them, and sizing rules that do not amplify small variations. Deciding how far ahead the plan is allowed to be volatile is a commercial decision, not a technical setting.

The exception message flood and what to do with it

Every run generates messages telling somebody to pull an order in, push it out, cancel it or expedite it. On a plant with thousands of active items the volume is far beyond what any planner can review, so the default outcome is that all of them get ignored, including the ten that mattered. The practical response is to filter before a human sees anything: restrict attention to items where the date movement is larger than the noise, where the value or criticality justifies effort, or where the message repeats across runs. Anything nobody will act on should be suppressed rather than displayed, because visible unread messages train people to stop looking.

The calculation assumes capacity is infinite, and says so quietly

Nothing in the run asks whether the shop can actually make what it just proposed. Orders are placed where lead time offsetting puts them, which may be a week already loaded well beyond what the work centres can deliver. Plants with plenty of slack rarely notice; plants running near their limit discover that the plan is a wish list and that the real sequence is decided every morning by a supervisor. That is the boundary at which capacity planning and finite scheduling become relevant. Recognising the boundary matters, because trying to solve a capacity problem by tuning materials parameters consumes months and changes nothing.

Frequently asked questions

Why does the system keep telling us to expedite orders we already placed?

Usually because demand moved after the order went out, or because the lead time on the record is shorter than the supplier really needs, so the calculation believes the order should already have arrived. Repeated expedite messages on the same item are a data signal rather than a supply problem: check whether the recorded lead time matches recent receipts, whether the order was placed late in the first place, and whether top-level dates are churning enough to make the message meaningless.

Can planning work when our stock accuracy is poor?

Not reliably, and the failure is asymmetric. Overstated stock means the run proposes nothing, the part is missing when the job starts, and someone expedites at a premium. Understated stock means excess ordering that only surfaces later as write-offs. Most plants improve accuracy fastest by counting the small number of items that cause most of the disruption far more often than the rest, and by hunting the transactions that create the errors rather than repeatedly correcting the balances.

How often should the calculation be run?

Frequently enough that the plan reflects reality, rarely enough that suppliers are not chasing a moving target. Nightly regeneration suits most discrete plants, with an option to run on demand after a major order or a supply failure. Continuous or near-continuous recalculation is only helpful where downstream processes can absorb constant change, which few can. Whatever the cadence, the more important decision is how much of the near horizon is protected from being rewritten by the next run.