The business problem
Most replenishment policies are static. A classic (s,S) policy reorders to level S when stock falls below s, and those parameters are set from average demand. When demand spikes suddenly because of a promotion, a seasonal peak or an outside event, a static policy reacts too late. The result is stockouts and lost sales, or expensive emergency orders.
Planners usually spot these shocks by gut feel. I wanted to know: can we warn planners early about how severe a shock will be, and turn that warning into a better reorder decision?
Stakeholders & requirements
I framed the solution around the people who would use it, drawing on my own years as a planner:
| Stakeholder | Need | Requirement |
|---|---|---|
| Replenishment planner | Know which SKUs are at risk before the shock hits | Shock severity forecast per SKU per week, in plain categories |
| Inventory manager | Protect service level without inflating stock | Policy parameters that adjust to the predicted severity |
| Finance | Evidence before changing policy | Head-to-head comparison against the current static policy, with significance testing |
Approach
Solution flow
- Shock definition: I used four ordinal severity classes instead of a yes/no flag, because "how bad" matters more to a planner than "whether".
- Features: lagged and rolling demand statistics, plus cyclical week encoding (sine/cosine) to capture seasonality without a hard-coded peak-season flag.
- Model selection: nested cross-validation with hyperparameter tuning. I chose Random Forest as the final model.
- Evaluation: an inventory simulation comparing adaptive and static policies SKU by SKU, with Wilcoxon signed-rank tests for significance.
Results
The adaptive policy clearly improved service level and stockout rate. The total-cost saving was real for about a third of SKUs but not statistically significant across the whole range. That finding matters: the case for adoption is about availability, not guaranteed cost cuts. I reported it that way rather than overstating the result.
What this shows as a BA
- Turning a vague operational pain ("we keep getting caught out") into a precise, measurable question
- Designing outputs around what the decision-maker actually needs
- Building an evidence base with a fair baseline and reporting results honestly, including the parts that didn't work out
Reflection
Next, I'd run a pilot with a planning team on a small SKU range and measure how often planners accept or override the recommendation. Adoption is where decision support tools succeed or fail. I'd also test cost-weighted policy rules to target the SKUs where savings are most likely.