Synthetic demo

Halden Forgeworks is a fictional company. Every figure here is an invented scenario input, not a claim about any real business.

Multi-site planning demo - built by Julia Broberg

Three plants, ordering against what they hope gets produced.

Each site plans its own island - separate systems, separate spreadsheets - and two of them buy the same long-lead valve from a supplier who reads two jumpy signals for one real demand. Sound familiar? Then here's the question worth asking: what if nobody had to order at all? This page walks one made-up manufacturer to that answer, one planning policy per item.

3 sites 11 planned items 5 Demand Driven MRP (DDMRP) policy bands 0 rows of real data

The scenario

One company, three plants that don't talk

Halden Forgeworks makes cast-iron cookware and outdoor cooking gear. It grew by acquisition, so its three plants run three planning worlds - different systems, separate spreadsheets, no shared picture. Two of them buy the same long-lead brass valve from the same overseas supplier, and neither can see the other's orders. Every order each plant places is a bet on what the other one just did.

Made up on purpose

Halden Forgeworks is invented - the company, its plants, its item numbers, and every quantity here. Nothing on this page comes from a real employer, client, or dataset. What is real is the problem: this is the pattern I have spent years inside, rebuilt from scratch so the method can be shown without anyone's data in it.

HM

Halden Main

The original foundry. Casts and enamels the core cookware line. Runs the oldest ERP of the three.

Legacy ERP
CB

Cutter Bay Assembly

Builds camp stoves and accessories. Acquired two years ago, still plans in its own spreadsheet.

Recent acquisition
RF

Rooksford Finishing

Finishing, engraving, and pack-out. Handles seasonal and custom work that spikes and then goes quiet.

Lumpy demand

The coordination problem

The shared valve, planned two ways

Item BV-38, a brass burner valve, feeds camp stoves at Cutter Bay and range-top kits at Halden Main, eight weeks from a shared supplier. Planned as two islands, each plant carries its own cushion against the same risk and can't see the other's orders. Here's where the story turns: if their bad weeks don't usually land together, how much of that doubled cushion is protection - and how much is hope with a carrying cost? Flip the switch and watch it move.

Plan the valve as

What the pooling number means

What is published: pooling independent demand reduces required safety stock, with the benefit scaling as the square root of the number of locations (Eppen 1979). The result weakens as site demands become positively correlated, and later work established that it depends on the light-tailed nature of the demand distribution.

What is my scenario input: the variability factors here, 0.55 per island against 0.45 pooled, encode partial correlation between the two plants. Price the network at the islands' own 0.55 and the safety saving goes to zero. The direction is established; the magnitude is mine, and it is the number I would want challenged first in a real review.

A note on the boundary: Kostenko and Hyndman (2006) showed the classification boundary should be non-linear rather than four rectangular cells; the original authors accepted the revision while defending theirs as the more practical scheme.

Policy bands

Policy replaces hope

Not every item deserves the same treatment, and no planner should have to hope their way through the whole board every Monday. Each item carries a demand signature - how often it actually sells, and how much a sale jumps around when it does. That signature, plus volume and lead time, decides which of five policy bands it lands in: what the system does on its own, and what stays with a human. Pick a band to filter, or open any item and it shows its work.

Halden is made up - the problem and the method are not: every policy, demand class, and buffer zone on this board is computed live from the scenario inputs - change a number and everything recalculates. Only the item and site labels and the scenario inputs themselves are typed in.

How the bands are decided

The method is public, and it isn't one average

The bands aren't a house opinion. They ride on two published ideas: a demand-classification scheme that sorts items by pattern, and demand-driven buffers that hold stock in colored zones and reorder off a net-flow signal.

The demand signature

Two numbers describe how an item sells. ADI, the average demand interval, counts how many periods pass between sales. CV squared, the squared coefficient of variation, measures how much the size of a nonzero sale jumps around.

The Syntetos-Boylan-Croston scheme splits items into smooth, erratic, intermittent, and lumpy at cutoffs of ADI 1.32 and CV^2 0.49. A smooth, steady item can stand on a buffer. A lumpy, once-a-quarter item can't, and pretending otherwise buries cash in stock that rarely moves.

The buffer, not a reorder point

Demand Driven MRP holds stock in three zones: a red safety base, a yellow coverage band, and a green reorder band. The net flow position is on-hand plus what's already on order minus qualified demand (confirmed orders and near-term spikes, not a forecast). When net flow falls into yellow, you order back up to the top of green.

Zone sizes come from average usage, the decoupled lead time (the wait the buffer actually has to cover), and two factors for lead time and variability, so a long-lead volatile part carries more safety than a short-lead steady one. Average usage itself can be read from the past, the forecast, or a blend, so no single naive mean has to carry the whole plan.

What this demo is, and isn't

This is a working illustration of a planning method on invented data. It is not a live system, not a connected planner, and not a claim that any real operation runs these numbers. Every quantity is a scenario input chosen to make the method legible in two minutes.

Where a statistical method is named, it links to a public source below. Where the demo makes a softer point, such as pooling safety across sites, it says so in plain terms rather than dressing a rule of thumb up as a proof.

Sources, verified live

The same method, at real scale

At real scale this runs across every plant and every planned item, on live ERP data instead of invented numbers, with the same logic: classify each item by its own demand, buffer off net flow, and pool the shared components. The demo is the method with the stakes removed.

How I set inventory policy across sites · [email protected]