In short: The demand a source plant sees from its own regional sites is dependent demand, generated by replenishment rules the business owns, so forecasting it is a category error that a time phased record removes. Running MRP arithmetic at every shipping point and rolling the planned releases up gives the source a requirement stream that is knowable weeks ahead, and in a worked eight week network the plant sees 350 in one week against a true network draw of 80 a week. The comparison against independent reorder points at each node turns on visibility of timing rather than on buffer size, and the case for reorder points survives on low value items and unreliable transit.
The plant scheduler pulls up next month's requirements and finds 350 units in week one, nothing in weeks two, three and four, 200 in week five, 150 in week six, and nothing again after that. Actual consumption across the network is close to 80 a week and has been for a year. So the scheduler does what any sensible person does with a number that disagrees with reality: adds a buffer, smooths it by hand, and stops trusting the file.
The file was right. Every one of those numbers is a shipment that two regional sites are going to ask for, on a date that is already determined, and the reason it looks like noise is that nobody rolled it up in a form the plant could read.
The demand a plant sees from its own network is not a forecast
Consumption at the regional sites is independent demand and has to be forecast. Shipments from the source plant to those sites are something else. They are created by replenishment rules that the business writes, applied to positions the business can see, on transit times the business books. Every input is internal.
Andre Martin set the method out in 1983 under the name distribution resource planning, and the core move is to stop forecasting the source's demand and start deriving it. Take the same time phased record MRP uses, and run it at each stocking point in the network: forecast demand at that site, projected available balance, safety stock, planned receipts offset back by transit time to give planned shipments. Those planned shipments become gross requirements at the site that supplies them. The same arithmetic runs at the next level up, and at the top the plant's master schedule receives a requirement stream instead of a guess.
The consequence worth stating plainly is that a forecast of source plant demand and a DRP roll up are both answers to the same question, and one of them has access to information the other has thrown away.
The eight week network, worked
Two regional distribution centres, one source plant.
The northern site forecasts 50 a week, holds 180, carries 60 of safety stock, ships in quantities of 200 and sits two weeks in transit. Project it: 130, 80, then 30 in week three, which breaches the safety stock line, so a receipt of 200 is required in week three. Offset by two weeks, that is a shipment released in week one. The balance rebuilds to 230 and runs down to 30 again by week seven, which pulls a second receipt into week seven and a second release into week five.
The southern site forecasts 30 a week, holds 90, carries 40 of safety stock, ships in 150s and sits one week in transit. It breaches in week two, so a receipt of 150 lands in week two, released in week one. It breaches again in week seven, released in week six.
Roll the releases up to the plant. Week one carries 350, being the northern 200 and the southern 150 leaving on the same days. Week five carries 200. Week six carries 150. The other five weeks carry nothing.
The network draws 80 a week. The plant sees 700 units arriving in three of eight weeks. Neither number is wrong and neither is a forecast error. The pattern is a product of two shipment quantities and two safety stock settings, and if either site changed its shipping quantity tomorrow the plant's requirement pattern would change with it, with no change in consumption at all.
Once that is on the screen, three conversations become possible that were not possible before. The plant can level its own production against a requirement stream it can see six weeks out. Somebody can ask whether the northern site's 200 is the right shipment quantity given what it does to the plant. And the master schedule (MM2) receives a demand line it can actually commit to, since the spike in week one is a fact about the network rather than an opinion about the market.
Why this beats a reorder point at every node
Give each site an independent reorder point instead. The northern site orders 200 when its position hits some level, the southern site orders 150 when its position hits another, and both are perfectly reasonable local policies. The plant, meanwhile, learns about each order on the day it arrives.
The plant's problem has now changed shape. Its lead time demand is uncertain in timing even though the timing is fully determined by rules the business wrote down. To protect service, it holds a buffer sized against that uncertainty, and every unit of that buffer is paying for information the business already had and chose not to pass upstream.
The formal version of this argument is old. Clark and Scarf showed in Management Science in 1960 that the optimal policy for a serial multi-echelon system is expressed in echelon stock, meaning stock at a location plus everything downstream of it, rather than in each location's own balance. Axsäter and Rosling compared installation stock and echelon stock policies in Management Science in 1993 and found that echelon policies dominate for the assembly structures where the upper node's requirements are driven by the lower ones. Lee and Billington made the operational case in Sloan Management Review in 1992, listing the practice of managing each site's inventory independently among the common failures in multi-site supply chains.
The DRP record is the practical form of that argument. It does not compute an optimal policy. It makes the downstream position and the downstream timing visible upstream, which is the input any multi-echelon calculation needs and which independent reorder points structurally destroy.
Where the buffers should actually sit once that visibility exists is a separate calculation with its own literature (I1), and the two work together: DRP handles the timing, echelon optimisation handles the sizing.
The week the source cannot supply
Every DRP grid above assumes the plant delivers what the network asked for. When it cannot, the arithmetic inverts and this is where most implementations get their reputation.
Two behaviours are possible and they need to be chosen deliberately. Push allocation overrides the sites' own requests and distributes what exists according to a rule set centrally, usually proportional to forecast or to days of cover. Pull, or fair share, keeps the sites' requests and cuts them by a common factor, which sounds equitable and quietly favours whichever site happens to have ordered most recently.
Both corrupt the record afterwards, which is the part that gets missed. A site that received 60 percent of its request has a projected balance that no longer reflects its own policy, so next period's requirement is inflated by the shortfall and the site orders more than it needs to catch up. Run that for a few periods across several sites and the requirement stream reaching the plant now contains a component created entirely by the shortage, which is the mechanism behind rationing induced ordering that Lee, Padmanabhan and Whang identified in 1997. The defence is to keep the allocation decision outside the record: allocate on a separate pass, write the allocated quantity as a confirmed receipt, and leave the site's own requirement calculation working from what it actually needs. Store level and assortment level allocation rules are a distinct discipline (L3).
Where this stops
Transit time in a DRP record is a single number, and the arithmetic behaves as though it were reliable. On an ocean lane with a fortnight of variance, planned receipts land in the wrong buckets, safety stock at the receiving site absorbs the difference, and the precision of the roll up is misleading. Treating that variance properly is a separate piece of work (I3), and a network with high transit variance gets less from DRP than the worked example suggests.
The method also inherits every stability problem the underlying arithmetic has. A change in regional forecast changes a site's breach week, which moves a planned release, which moves the plant's requirement, and the movement grows at every level it passes through. Freezing rules and firm shipment windows near the front of the horizon are as necessary here as they are in a plant.
Then there is maintenance. A DRP model needs a live record for every item at every location, with a forecast, a safety stock, a shipping quantity and a transit time on each. For 4,000 items across 12 sites that is 48,000 parameter sets that decay quietly. Independent reorder points are the right answer for a large share of them: low value, high line count, stable consumption, where the cost of a wrong parameter is small and the cost of maintaining a right one is not. Reserve the network arithmetic for the items where the source is capacity constrained, the value is high, or the transit is long, and let the tail run on reorder points that someone reviews once a year.
The honest summary of the comparison is that DRP wins where the source has a decision to make. If the plant has ample capacity and short lead times, it can absorb whatever pattern the sites throw at it, and the visibility is worth much less than the maintenance costs.
Pick one week and one item, and check where the plant's gross requirement for it came from. If it was generated from the regional sites' planned shipments, the roll up is working. If it came from a separately maintained forecast of plant shipments while the sites also plan their own replenishment, you have two demand signals for the same units, and the difference between them is sitting somewhere in the network as stock nobody has counted.