ANLAnalytics & AIStop 4 of 6
Machine learning in supply chain
Where ML genuinely helps, from forecasting and ETAs to anomaly detection and documents, and the traps that make projects fail.
Read atChange any time
Machine learning finds patterns in historical data and uses them to predict or classify new cases. In supply chains it earns its place where there’s plenty of data and a clear prediction to make:
- Demand forecasting and sensing: many related products with drivers such as price, promotions and events.
- ETA prediction: when will this truck or container really arrive?
- Predictive maintenance: which machine is likely to fail soon, from vibration and temperature data?
- Anomaly detection: unusual invoices (possible duplicates or fraud), odd orders, sudden stock discrepancies.
- Document extraction: reading supplier invoices, purchase orders and delivery notes to cut manual data entry.
- Classification: suggesting product categories, return reasons or likely late orders.
Most ML projects that fail do so for practical reasons, not because the algorithm was wrong:
- Data quality: wrong stock records, missing promotion flags, inconsistent master data.
- Leakage: accidentally training on information that wouldn’t be known at prediction time, which gives great test scores and useless real predictions.
- Drift: the world changes, like a new channel or a pandemic, and a model trained on old patterns quietly degrades. Models need monitoring and retraining (often called MLOps).
- Adoption: planners won’t trust a black box. Simple explanations and a fair comparison with today’s method help.
Finally, a prediction isn’t a decision. A forecast of 120,000 units doesn’t say which plant should make them; that’s where optimization comes in.
Words to use
- Supervised learning
- Learning to predict a known target, such as demand or delay, from labelled history.
- Data leakage
- Using information in training that would not be available at prediction time.
- Model drift
- A model’s accuracy degrading as real-world patterns change.
The workflow
- Frame the problem: what exactly is predicted, when, and which decision uses it? “Predict whether an invoice is a duplicate before payment” is a usable frame; “use AI on invoices” is not.
- Assemble data: features known at prediction time, and labels (past outcomes) that are reliable.
- Split by time: train on the past, test on later data.
- Start simple: a rule or a linear or logistic model as the baseline, then try gradient boosting or neural networks if they beat it.
- Evaluate on business terms: errors translated into money and workload.
- Deploy and monitor: track accuracy, data drift and the decisions taken.
Evaluating a classifier
Out of 10,000 invoices, 50 are actual duplicates. The model flags 80 invoices, of which 40 are real duplicates.
- Precision = 40 / 80 = 50%: half of the flags are real.
- Recall = 40 / 50 = 80%: it catches 80% of duplicates.
- In money: reviewing a flag costs about ₹200, so 80 flags cost ₹16,000. Each duplicate caught avoids an average overpayment of ₹50,000, so 40 caught save ₹20 lakh.
At these costs, it is worth lowering the threshold to catch more duplicates even if precision falls, as long as each extra true catch is worth more than the extra reviews.
For forecasts and other numbers, use the error measures from the forecast accuracy stop (MAE, RMSE, WMAPE), again judged at the horizon the decision uses.
Explaining predictions
Planners act on predictions they understand. Tools such as SHAP values show which features pushed a particular prediction up or down: “this order is flagged late mainly because its carrier has been late on this lane and the warehouse is above capacity today.” Explanations also reveal when a model relies on something it shouldn’t.
Drift and monitoring
Models degrade when the world changes:
- Data drift: the inputs change (new products, new customers, a different mix of carriers).
- Concept drift: the relationship changes (a promotion that used to lift sales 30% now lifts them 10%).
Monitoring compares live inputs and errors with what the model saw in training, and triggers retraining or investigation when they diverge. MLOps practice adds version control for data and models, reproducible training and controlled releases.
Feedback loops
Predictions that drive actions change the data future models learn from. If a late-order model triggers expediting for flagged orders, those orders arrive on time, and a model retrained on the results may conclude the warning signs don’t matter. Keeping records of interventions, holding back a small control group, or modelling the effect of the intervention avoids teaching the model the wrong lesson.
Prediction is not causation
Most ML models predict what will happen given the patterns in past data, not what would happen if you changed something. Knowing that customers who received a discount bought more doesn’t tell you the discount caused it if discounts were offered to customers already likely to buy. Questions about the effect of an action need experiments or causal methods, such as uplift modelling for promotions.
Hidden costs
Sculley and colleagues (2015) described the “hidden technical debt” in ML systems: most of the code and effort sits not in the model but in data collection, feature pipelines, configuration, monitoring and serving infrastructure. A model that is slightly more accurate but needs fragile pipelines may cost more than it saves.
Where ML fits best
ML pays when data is plentiful and reliable, the prediction is repeated often, errors have a clear cost, and the decision process can absorb the output. Where data is scarce, decisions are rare, or rules capture the logic well, simpler methods often win.
Interview kit
Practise it out loud
Answer each question yourself before opening the model answer.
ML is valuable in supply chains where there’s lots of data and a clear prediction: demand forecasting with drivers, ETA prediction, predictive maintenance, anomaly detection on invoices and orders, and document extraction. Success depends on data quality, avoiding leakage, monitoring for drift, explainability and adoption by planners. And predictions need to feed decisions, often through optimization, to create value.
A demand model scored brilliantly in testing but performs badly live. What might have happened?
Likely data leakage: features available in the test data but not at forecast time, such as actual promotions recorded after the fact, or a random train/test split instead of a time-based one. Or drift: patterns changed after training. I’d re-check features for timing and backtest with rolling time splits.
Where would you not use machine learning?
Where data is scarce or unreliable, where a simple rule or statistical model already performs well, or where decisions must follow strict policy and explainability matters more than a small accuracy gain. ML adds cost and maintenance, so it has to clearly beat the simpler option.
Connected stops
Where this idea feeds in, or gets its inputs from.
Sources and further reading
- Bertsimas, D. & Kallus, N. (2020). From predictive to prescriptive analytics. Management Science, 66(3), 1025–1044.
- Hyndman, R. J. & Athanasopoulos, G. Forecasting: Principles and Practice (3rd ed.). OTexts.
- James, G., Witten, D., Hastie, T., & Tibshirani, R. (2021). An Introduction to Statistical Learning (2nd ed.). Springer.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems, 28.