Independent demand arises outside the system. It must be observed.
Dependent demand is implied. Demand for a component follows from the production schedule for the assembly that consumes it.
And that schedule is already known.
Forecasting dependent demand throws away information the organization already has, and replaces a calculation with an estimate.
Suppose a deck assembly takes two spindle assemblies.
If you forecast spindle demand from spindle history, you are estimating something you can compute exactly from the deck schedule.
And your forecast will be wrong in a particular way: dependent demand is lumpy, because it arrives in the batches the parent chose to order in.
It is not merely lumpy. It is made lumpy, by a decision taken one level up.
We measure that next session.
flowchart TB
DA["Mower deck assembly<br/>lead time 1"]
B["Deck belt<br/>lead time 2"]
S["Spindle assembly<br/>lead time 1"]
H["Spindle housing<br/>lead time 2"]
BR["Bearing<br/>lead time 3"]
DA -->|1| B
DA -->|2| S
DA -->|1| BR
S -->|1| H
S -->|2| BR
The number on an arc is the quantity per.
Mower deck assembly (DA), lead time 1
Deck belt (B), 1 each, lead time 2
Spindle assembly (S), 2 each, lead time 1
Spindle housing (H), 1 each, lead time 2
Bearing (BR), 2 each, lead time 3
Bearing (BR), 1 each, lead time 3Each indentation is a level. The deck assembly is level 0; the belt and spindle assembly are level 1; the housing is level 2.
The bearing appears twice. One is fitted directly to the deck, and two more sit inside each spindle assembly.
So a deck assembly consumes \(1 + 2\times 2 = \mathbf{5}\) bearings.
An item must be planned once, and after every parent that consumes it.
The bearing appears at level 1 and again at level 2. If it were planned at level 1, its requirements would be netted against stock on hand before the spindle assembly had asked for any, and the spindle assembly would then find the stock already spoken for.
So each item carries a low-level code: the deepest level at which it appears anywhere.
| Item | Appears at | Low-level code |
|---|---|---|
| Mower deck assembly | 0 | 0 |
| Deck belt | 1 | 1 |
| Spindle assembly | 1 | 1 |
| Spindle housing | 2 | 2 |
| Bearing | 1 and 2 | 2 |
Planning shallowest first: DA, then B and S, then BR and H.
If item \(i\) is a parent of item \(j\), with \(q_{ij}\) of \(j\) in one \(i\):
\[ G_{jt} = \sum_{i \in \text{parents}(j)} q_{ij}\,\mathit{Rel}_{it} \]
Releases, not receipts
A parent needs its components in hand when it starts building, and the release is when it starts.
Using the receipt row would ask for the components on the day the parent is finished, a whole lead time too late.
This is the single most common error in a hand-worked explosion.
\[ G_{\mathit{BR},t} = 1 \cdot \mathit{Rel}_{\mathit{DA},t} + 2 \cdot \mathit{Rel}_{S,t} \]
The two arrive in different periods, because the two paths through the structure have different lead times.
Keep them apart before adding them. That is what makes the bearing’s requirement row the shape it is.
Six rows over a common horizon, periods across the columns.
The last row is the record’s output. It is what the explosion reads at the next level down, and the only row a planner will act on.
\[ I_t = I_{t-1} + \mathit{SR}_t + \mathit{POR}_t - G_t \]
\[ \mathit{NR}_t = \max\left(G_t + \mathit{SS} - \mathit{SR}_t - I_{t-1},\; 0\right) \]
\[ \mathit{POR}_t = \text{whatever the lot sizing rule decides} \]
\[ \mathit{Rel}_{t-L} = \mathit{POR}_t \]
That last one is just offsetting by the lead time.
A reader meeting the record for the first time usually leaves out the net requirement row, and the \(\max\) with it. Let us see what happens.
Carry the balance forward with \(\mathit{POR}_t = 0\) throughout:
| Period | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
|---|---|---|---|---|---|---|---|
| Gross | 40 | 60 | 120 | 300 | 420 | 260 | 120 |
| On hand | -40 | -100 | -220 | -520 | -940 | -1,200 | -1,320 |
By period 17 the balance reaches \(-1{,}840\): the whole year’s requirement.
Correct arithmetic, and a useless plan.
It reports that if nothing is ordered then everything is short, which the reader knew.
Netting turns each of those shortages into an order.
The \(\max\) has a narrower job: it stops a surplus being treated as a requirement.
With nothing on hand and nothing on order, \(\mathit{NR}_t = G_t\) in every period, lot-for-lot sets \(\mathit{POR}_t = \mathit{NR}_t\), and \(I_t\) stays at zero throughout.
Suppose the deck assembly starts with 60 on hand.
Period 6 needs 40. Inside the \(\max\): \(40 - 60 = -20\).
Without the \(\max\), lot-for-lot plans a receipt of \(-20\): it cancels stock that period 7 is going to use.
With it, the net requirement is 0, the 20 units stay in projected on hand, and period 7’s net requirement falls from 60 to 40.
Safety stock is the \(\mathit{SS}\) term. It enters every period’s netting, but in effect it raises only the first net requirement by \(\mathit{SS}\); after that the plan holds \(\mathit{SS}\) units permanently and plans around what is left.
Whether safety stock belongs in a system whose entire premise is that demand is known is a real question, and the field has never fully settled it.
Allocated stock is inventory physically present but already promised elsewhere. Handled by reducing \(I_0\), to keep it out of the calculation. Nothing else changes.
plan(bill of material, master schedule):
assign every item its low-level code
sort the items by low-level code, shallowest first
for each item in that order:
if a master schedule speaks about this item:
G <- the master schedule
else:
G(t) <- sum over parents i of q(i, item) * Rel(i, t)
NR(t) <- max(G(t) + SS - SR(t) - I(t-1), 0)
POR <- the lot sizing rule applied to NR
I(t) <- I(t-1) + SR(t) + POR(t) - G(t)
Rel(t - L) <- POR(t)The sort is what makes the sum over parents safe: by the time an item is reached, every parent already has a release row.
Lot-for-lot throughout, nothing on hand, nothing on order.
| Period | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DA gross | 0 | 40 | 60 | 120 | 300 | 420 | 260 | 120 | 40 | 0 | 80 | 180 | 220 |
| DA releases | 40 | 60 | 120 | 300 | 420 | 260 | 120 | 40 | 0 | 80 | 180 | 220 | 0 |
The belt takes one per deck, so its gross requirements are the deck’s release row unchanged, and its own lead time of two months pulls them back again.
The spindle assembly takes two per deck, so its gross requirements are twice that row.
| Period | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
|---|---|---|---|---|---|---|---|---|---|
| One per deck assembly | 0 | 40 | 60 | 120 | 300 | 420 | 260 | 120 | 40 |
| Two per spindle assembly | 160 | 240 | 480 | 1,200 | 1,680 | 1,040 | 480 | 160 | 0 |
| BR gross requirements | 160 | 280 | 540 | 1,320 | 1,980 | 1,460 | 740 | 280 | 40 |
Look at the shape of the last row.
It is not the shape of the master schedule, and it is not the shape of either contribution taken alone.
Two streams arriving on different offsets add up to a pattern that looks nothing like the demand that caused it.
And nobody forecast any of it.
The bearing’s requirement reaches 1,980 in period 8, although no deck assembly is ever built in a quantity approaching that.
Five bearings per deck, and two paths through the structure, will do that.
Across the horizon: 9,200 bearings for 1,840 deck assemblies, exactly five each.
Lot-for-lot throughout costs $14,500 across 57 orders, every dollar of it setup, because no item ever carries anything from one period to the next.
A record cannot release an order before period 1.
If a receipt is due in period \(t\) and the lead time is \(L\), the release falls in \(t - L\). When that is less than 1, the order is past due: the plan has discovered a requirement it no longer has time to meet.
Past-due orders at the bottom of a structure are usually not a data problem.
They are a horizon problem.
Lead times accumulate down every path, and the horizon must lead the first requirement by the longest accumulation.
The deepest path runs assembly, spindle assembly, bearing, with lead times 1, 1 and 3. Cumulative: 5 months.
| Empty months in front of the schedule | 3 | 4 | 5 | 6 |
|---|---|---|---|---|
| Units the plan cannot release in time | 520 | 160 | 0 | 0 |
Five months of lead-in is exactly enough, and that is the cumulative lead time through the deepest branch.
So the horizon used throughout is 17 months: five empty, then the twelve-month schedule.
Activity 1: the spindle housing’s record (PDF, or HTML). Pairs, 14 minutes.
Dependent demand is calculated, not forecast, and forecasting it discards information you already hold.
Low-level codes ensure every item is planned once and after all its parents.
The explosion reads releases, not receipts. Using receipts asks for components a lead time too late.
The \(\max\) in the netting equation is the whole idea, and it turns shortages into orders instead of letting them propagate.
The horizon must lead by the cumulative lead time through the deepest branch.
Read before next session: What Lot Sizing Does to the Level Below, and Distribution Requirements Planning.
Next session:
Every rule from the dynamic lot sizing chapter can be used on an MRP record. Next session is about what happens below the level you apply it to.