Planning procurement and inventory by "last month's average" leads to two losses at the same time: tied-up capital in dead stock and lost revenue due to out-of-stock. Demand forecasting on historical data shifts procurement from reactive to predictive. Below is an open review of what is actually done in Python in manufacturing and distribution. This is not a KT.Team case study, but an analysis of public open-source tools with links to the original sources.
What counts as the result
The business result is measured not by model accuracy, but by working capital. Nixtla states the relationship directly: a 10-20% increase in forecast accuracy delivers about a 5% reduction in warehouse costs and a 2-3% increase in revenue (nixtla.io). The logic is simple: the more accurate the forecast over the lead-time horizon, the lower the safety stock for the same product availability, the fewer write-offs, and the fewer urgent replenishment orders at a higher price. That is why the pipeline is built not around the "best neural network" but around a controlled, reproducible forecast across thousands of SKUs that fits into the reorder point formula.
The key characteristic of distribution data is intermittent demand
In retail, end-demand forecasting focuses on trend and seasonality. In distribution and spare parts warehouses, the picture is different: intermittent demand means irregular sales with frequent zero periods. This is typical for spare parts, specialized goods, and B2B item master data (nixtla.io). Classical ARIMA and Prophet perform poorly on such series: they smooth out demand and systematically overstate inventory.
There are mature statistical methods for this class of problems, and there is no need to reinvent them. Croston's method and its variants, Croston SBA, as well as TSB, ADIDA, and IMAPA, explicitly separate demand size estimation from the interval between sales. This is an example of "read before you write": instead of a homemade heuristic, you use a proven international forecasting standard.
Tool: the open-source statsforecast library
Nixtla statsforecast is an open-source library (Apache-2.0 license) for statistical time series forecasting. It includes out-of-the-box automatic models (AutoARIMA, AutoETS, AutoCES, AutoTheta, TBATS) and the full set for intermittent demand: Croston Classic, Croston Optimized, Croston SBA, ADIDA, IMAPA, and TSB (github.com/Nixtla/statsforecast).
The key for production is scale and speed. The library claims it can process 1,000,000 series in 30 minutes and run 10 benchmark models on a million series in under 5 minutes, as well as being "500x faster than Prophet" and "20x faster than pmdarima" (github.com/Nixtla/statsforecast). In practice, this means the nightly forecast recalculation across the full assortment actually fits into the window before supplier orders are generated.
What the data pipeline looks like
A public end-to-end example is the Databricks Industry Solutions solution accelerator "intermittent-forecasting." It builds forecasts at the store-item granularity, where the data contains many zero periods that standard models cannot handle (github.com/databricks-industry-solutions/intermittent-forecasting). The pipeline is split into three reproducible stages: configuration, data preparation, and training plus store-item forecast generation, orchestrated as a multi-step job.
A generalized reproducible Python pipeline looks like this:
1. Collect shipment/sales history from the ERP/accounting system into a `unique_id, ds, y` table (item, date, quantity).
2. Cleaning: restore zero periods (no sale means `0`, not a missing value), remove promo outliers, and flag shortage periods (out-of-stock distorts "true" demand).
3. Select the model family based on the series profile: smooth demand uses AutoETS/AutoARIMA, intermittent demand uses Croston SBA/TSB/ADIDA.
4. Cross-validation on historical slices (`cross_validation`), selection by MAE/RMSSE over the lead-time horizon.
5. Generate forecasts with intervals and pass them into the reorder point and safety stock calculation.
What matters architecturally
Forecasting is not a monolith inside the ERP. A sound setup moves the calculation into a separate service next to the accounting system: the ERP/WMS core is not modified, while the Python pipeline runs alongside it, reads history, and returns procurement recommendations. This provides loose coupling and portability: the model can be retrained, replaced, and handed off between teams without rewriting the core system. The models themselves are international forecasting standards rather than closed custom logic, which makes auditing easier and increases the planner's trust in the numbers.
It is also worth keeping an honest metric. Accuracy for accuracy's sake is meaningless: the model is evaluated by business impact, namely lower tied-up capital and service level (product availability), not by how nice the chart looks. That is why the pipeline includes backtesting on historical data from the start, showing how much inventory and how many stockouts each method would have produced.
Business process takeaway
The procurement process itself changes. Instead of a monthly manual average-based recalculation, the planner gets an automatic nightly forecast across the entire assortment, with separation of smooth and intermittent demand, confidence intervals, and a recommended reorder point. The human decision shifts from "calculate" to "approve exceptions." With mature open-source tools (statsforecast, Databricks accelerator), such a pipeline can be assembled by a small team and pays for itself through lower dead stock and fewer out-of-stock situations, meaning working capital, not a line in an accuracy report.
