A retailer replenishes stock from a supplier. Two clocks matter: how long goods take to physically travel (lead time L), and how long the order signal takes to travel back through the information system (information lag I) — an EDI batch upload, a daily ERP sync job, or a real-time API call. Total replenishment time is L + I.
Lead-time demand: D ~ Normal( d̄(L+I), σ_d²(L+I) )
Safety stock: SS = z · σ_d · √(L+I)
Reorder point: ROP = d̄(L+I) + SS
Order-up-to level: S = ROP (base-stock policy)
d̄ = 25 units/day (fixed mean demand). z is the standard-normal quantile for the chosen cycle service level (90% → 1.28, 95% → 1.64, 99% → 2.33). Because demand uncertainty compounds over the whole replenishment window, shrinking I — pure digitization, no change to the physical supply chain — shrinks √(L+I) and therefore the safety stock needed for the same service level.
- Each simulated day the retailer sells a random quantity (mean d̄, std σ_d, floored at 0) from real inventory.
- When inventory falls to the reorder point, an order signal (cyan pulse) is fired toward the supplier and takes I days to arrive; only then does a physical shipment (amber crate) depart and take L days to arrive.
- Any day inventory would go negative counts as a stockout; the readout is the running stockout frequency, which should track the (100% − service level) target once enough days have simulated.
Real-world relevance: this is the textbook mechanism behind "digital supply chain visibility" — real-time POS/ERP data doesn't move goods any faster, but it removes information latency from the buffer-stock formula, letting a company hold less safety stock for the same reliability.