In short: Netting, offsetting and explosion are deterministic arithmetic, so every surprise in the output was already present in the inputs. Discrete lot sizing turns a smooth requirement at the parent into a spiky one at the component, which is order batching creating amplification inside your own planning logic before any supplier or forecast is involved. Instability under a rolling horizon is a property of re-solving a lot sizing problem every week on shifted data, and the cost-optimal rule is among the worst offenders. Four dampeners exist, each buying stability with a different currency, and the measurement that tells you which one you need takes an afternoon.
Monday's run finishes and about a quarter of the planned orders have moved since Friday. Reschedule-in messages on purchase orders that looked settled, a works order pulled forward two weeks, a component release that grew by 35 units for no reason anyone can name. The planner working that queue checks the master schedule and finds one change: a customer moved 25 units out of week six. Nothing else touched the file.
The run is right. It did the arithmetic it was given, on the data it was given, and the arithmetic has a property that most planners meet as a nuisance long before anyone explains it to them.
Three operations, and nothing else
Joseph Orlicky set the logic out in 1975 and it has not changed since. A requirement arrives at a level of the bill of materials. The system nets it against what is already there, which means on hand stock plus scheduled receipts minus whatever safety stock you told it to protect. Whatever is left is a net requirement. It offsets that net requirement backwards by the item's lead time to get a planned order release date. Then it explodes the release through the bill of materials at the usage quantity, and the result becomes a gross requirement at the next level down, where the same three operations run again.
Netting, offsetting, explosion. Everything else in an MRP module is parameters and exception messages.
That matters because it fixes where you can look when the output is strange. There is no statistics in the run, no learning, no judgement. The output is a pure function of the master schedule, the bill of materials, the lead times, the lot sizing rules, the safety stock settings and the inventory record. If the plan is wrong, one of those six is wrong, and the exception message is telling you which one only by accident.
The lot size makes the lumpiness
Take a finished item with 70 on hand, a two week lead time and a supplier who ships in multiples of 100. Weekly requirements over the next eight weeks run 30, 30, 60, 30, 30, 70, 30, 30. That is a fairly calm demand pattern, 310 units with a peak just over double the average.
Project it forward. The balance holds until week three, where a receipt of 100 is needed, then again in week five and week seven. Offset by two weeks, the planned releases are 100 in week one, 100 in week three and 100 in week five, and nothing at all in the other five weeks.
Now explode that into a component used two per unit, with 300 on hand, a two week lead time and a supplier minimum of 500. The component's gross requirements are 200, nothing, 200, nothing, 200, and then nothing for three weeks. Running the same netting logic gives one purchase order, 500 units, released in week one.
Follow what happened to the shape of the signal. Demand at the top was continuous and mildly variable. One level down it is an on off pattern. Two levels down it is a single order for most of a quarter's usage, and the supplier looking at it has no way to tell that the underlying consumption is steady. Nobody forecast badly and no supplier misbehaved. The batching rules did it.
Lee, Padmanabhan and Whang named order batching as one of the four causes of demand amplification in their 1997 Management Science paper, and this is that cause operating entirely inside one company's planning run. The usual response is to attack it at the parent level with a smarter lot sizing rule, which brings its own problem.
The rules on offer are familiar. Lot for lot orders exactly the net requirement each period, which removes the lumpiness and pays for it in setups. Fixed order quantity and economic order quantity impose a size and let the coverage fall where it lands. Period order quantity converts an economic quantity into a number of periods of coverage. Wagner and Whitin published the dynamic programming solution in 1958 and it gives the cost-minimising schedule for a known, finite, time-varying demand series. Silver and Meal published a heuristic in 1973 that extends the coverage period while the average cost per period keeps falling, and part period balancing takes a similar shape with a different stopping test.
Any of these is defensible. The trouble starts when the demand series they are solving against moves every week.
Nervousness is what re-solving looks like
Set the ordering cost at 300 and the holding cost at one per unit per period. Requirements over the next few periods are 100, 60, 40, 60.
Run Silver and Meal's test. Covering one period costs 300 per period. Covering two gives (300 plus 60) over two, which is 180. Covering three gives (300 plus 60 plus 80) over three, which is about 147. Covering four gives (300 plus 60 plus 80 plus 180) over four, which is 155, so the average has turned up and the rule stops. This period's order is 200 units, covering three periods.
Next week a customer trims the period four requirement from 60 to 35. That is a small change, 25 units, three periods out. Re-run the test on the shifted horizon and the four period option now costs (300 plus 60 plus 80 plus 105) over four, which is about 136, below the three period figure. The rule now covers four periods and this period's release becomes 235.
Demand fell and the immediate order rose by 35 units, and the order that was going to be placed in period four has disappeared. Downstream, that release change explodes into every component, where each item's own lot sizing rule reacts to it, and the reaction is not proportional to the change that caused it.
Steele described this in Production and Inventory Management in 1975 and gave it the name that stuck. Blackburn, Kropp and Millen compared dampening strategies in Management Science in 1986 and reported the result that still surprises people: the cost-optimal lot sizing rule tends to be among the least stable under a rolling horizon, because optimality means the solution sits exactly on a boundary that small data changes cross. Carlson, Jucker and Kropp had already proposed the direct fix in Management Science in 1979, adding an explicit cost of changing a previously planned setup to the lot sizing objective so the arithmetic itself resists moving.
The useful reframing is that instability is the visible edge of a decision you made when you chose to re-solve the whole problem every cycle. A regeneration run has no memory of the plan it published last week and no reason to prefer it.
Four dampeners, four different bills
Freezing. Fix the schedule inside a window and let the run change nothing within it. Sridharan, Berry and Udayabhanu showed in Management Science in 1987 that freezing a longer portion of the horizon improves stability with a cost penalty that flattens out, so the middle of the range usually buys most of the available stability. The bill is responsiveness inside the frozen window, paid by whoever wanted the change.
Safety stock or safety lead time. Whybark and Williams drew the distinction in Decision Sciences in 1976 and it holds up. Safety stock covers uncertainty in quantity. Safety lead time covers uncertainty in timing. Applying safety stock to a timing problem inflates the balance without moving the date the run is worried about, which is the most common misapplication in the parameter file.
Lot for lot at the upper levels. Batching low in the bill of materials, where the parts are cheap and the setups are real, and running lot for lot high up, where a batching decision propagates through the widest fan-out, keeps the amplification away from the levels that multiply it.
A change cost inside the objective. The Carlson approach, now available in most planning engines as a rescheduling penalty or a plan stability weight. It is the only one of the four that treats stability as something the optimiser is aware of.
Pick by cause. If the underlying series is stable and the plan still churns, the lot sizing rule is doing it and the last two apply. If the series itself moves every week, freezing is a way of refusing to react and the pressure moves upstream to whoever keeps changing the schedule.
Capacity is not in the run
MRP offsets by a fixed lead time regardless of how loaded the resource is that week. A one week lead time is a one week lead time whether the line is at 40 percent or 110 percent, so the run will happily publish a schedule the plant cannot build. Checking that publishable schedule against a resource profile belongs to rough cut capacity planning (EE7), and turning it into a sequence the plant can actually run belongs to finite capacity scheduling (I6).
The practical consequence is that lead times in the item master are frequently doing capacity's job. Someone extended a lead time from three weeks to five because orders kept arriving late, the lateness was queueing rather than supply, and now every net requirement for that item is offset by two weeks of phantom capacity buffer that inflates work in progress across the whole bill.
Where this stops
The arithmetic is exact and its inputs are not. Bill of materials accuracy, unit of measure and scrap factors decide the answer completely, and that is a data problem with its own discipline (EE8). A run against a bill that is 98 percent accurate at each of four levels is working from a structure that is right about 92 percent of the time end to end, and no dampening strategy fixes that.
The deeper limit is that lead time is treated as a constant when it is a function of load, which means MRP is solving a queueing system with a parameter. Everything in the paragraphs above about nervousness assumes the lead times themselves hold still, and in a plant running near capacity they do not.
A fair reading of the pull methods is that a well parameterised MRP carrying honest buffers and a pull system sized on the same consumption end up in a similar place on stable, repetitive items, and they diverge on variety and volatility. Card based replenishment (J17) is the version of that comparison worth reading next.
Measure your own instability before you tune anything. Take the last four weekly runs, and for each pair of consecutive runs count the planned releases inside the cumulative lead time window that changed date or quantity, as a percentage of the release lines in that window. Under about five percent you have a parameter question. Over twenty percent you have a schedule that is being rewritten upstream, and no setting inside the MRP module will absorb it.