From demand forecasts to procurement decisions

Schematic

1. 1
   Business data Sales, inventory, stock availability, prices and supplier lead times from SAP Business One and related databases.
2. 2
   Preparation Cleansing, stock-out handling, demand-type classification and feature engineering in Python and SQL.
3. 3
   Forecasting Statistical, intermittent-demand, gradient-boosting and global neural models, one family per demand type.
4. 4
   Evaluation Chronological backtests against baselines and the previous approach; data-quality and anomaly checks.
5. 5
   Replenishment Forecast, uncertainty, stock, open orders and lead time combined into a recommended order per product.
6. 6
   Buyer review Procurement reviews, overrides where they know more than the data, and places supplier orders.

↻ Buyer feedback and observed outcomes feed back into data preparation and model selection at each refresh.

The decision the system supports

Priory Direct sells packaging and related products online. Keeping more than a thousand products available means placing supplier orders weeks ahead of the demand they are meant to satisfy. Order too little and customers face stock-outs; order too much and cash sits in inventory. Before the partnership, forecasting and ordering depended on the experience of the buying team and manual analysis, an approach that is hard to repeat consistently and difficult to scale across a range of this size.

The purpose of the Knowledge Transfer Partnership was to give the procurement team a dependable, regularly refreshed forecast for every product and to connect those forecasts to a recommended replenishment quantity that a buyer could review and act on.

My role

A KTP employs one researcher, the Associate, to deliver a defined project inside the company with academic supervision from the university. I was that Associate for the full 30 months. I led the technical design and development of the system: the data pipelines, the forecasting models, the evaluation framework, the replenishment logic and the reporting. The company’s management and procurement team defined the business requirements and reviewed outputs; the University of Kent provided academic supervision. The intellectual property belongs to Priory Direct.

Data and constraints

The system combined several sources from the business’s SAP Business One environment and related databases: sales transactions, inventory positions, stock-availability history, prices and promotions, and supplier lead times. Three features of the data shaped the design.

• Heterogeneous demand. A few products sell steadily every day; many sell in irregular, small quantities; some sell rarely. No single model suits all of them.
• Short and interrupted histories. New products have little history, and periods when a product was out of stock hide the demand that would have occurred.
• Operational fit. A forecast is only useful if it arrives before the ordering decision is made and in a form the buyer can act on.

Approach

I treated the project as a decision problem first and a modelling problem second.

1. Baselines before models. Simple methods (naive, seasonal naive and moving averages) were established first so that every later model had to demonstrate a genuine improvement.
2. Chronological backtesting. Models were evaluated on rolling time-based splits that mimic how the system would be used: fit on the past, forecast the horizon the buyer cares about, compare against what actually happened.
3. Model families compared. Exponential smoothing and ARIMA-type methods; intermittent-demand methods for sparse series; gradient-boosted models with engineered features (XGBoost, LightGBM); and global neural forecasting models trained across the whole product range.
4. Selection by demand type. Rather than choosing one winner, products were classified by their demand pattern and each class routed to the approach that performed best for it, with a simple fallback when a product had too little history to support anything else. This idea is the subject of a manuscript in preparation.
5. From forecast to order. Forecasts, their uncertainty, current stock, open orders and supplier lead times were combined into a replenishment recommendation for each product, expressed in the units a buyer orders in.
6. Controls. Data-quality checks (completeness, consistency, schema), anomaly flags and reproducible, logged runs, so that unusual outputs could be traced to their cause before anyone acted on them.

Evaluation

Every model was judged in the same chronological backtest, across the product range, against the approach the business used previously. In those backtests the selected models improved forecast performance by approximately 28–30% relative to that incumbent approach. Improvements of this kind are never uniform across a range: regular-demand products are where models gain most, while for the sparsest series any method struggles and the fallback rules matter more than the model.

Two points of honesty are worth stating. The figure summarises backtest performance, not a measurement of business profit. And the comparison is with the business’s previous method, not with a published benchmark, so it says how much better the business’s forecasts became rather than how the models compare with the wider literature.

What the buyer sees

The output is a regularly refreshed table per product: the forecast for the ordering horizon, an indication of its uncertainty, current stock and open orders, and a recommended order quantity with the reasoning behind it. Buyers review the recommendations, override where they know something the data does not, and place orders.

Limitations and what remains human

• Forecasts cannot anticipate events absent from the data, such as a new large customer or a supplier failure. Buyers remain responsible for those judgements.
• For the sparsest products the system’s main contribution is consistency and a sensible fallback, not a precise forecast.
• Adoption depended as much on explaining the outputs and building trust with the procurement team as on model performance. The partnership included regular sessions with management and buyers, and the outputs changed in response to their feedback.

What this approach suits

The same structure applies to any organisation that must order ahead of uncertain demand across a wide range of items: e-commerce retailers, wholesalers, spare-parts operations and food or consumables businesses. The specific models matter less than the discipline of baselines, chronological evaluation, selection by demand type and an output that fits the buyer’s workflow. If you have a problem like this, I would be glad to discuss it.