Why spare parts demand forecasting fails
The classic picture of a spare parts warehouse: a fast-moving sensor is out of stock and an order is stalled, while hundreds of SKUs sit nearby that have not sold once in a year.
Both problems grow from the same root: manual procurement planning based on last year's spreadsheet and a "feel" for the warehouse. Spare parts demand forecasting is noticeably more complex than it appears from a sales report.
Demand for parts is intermittent and jagged: one SKU sells once a quarter, another moves in batches after seasonal load on the fleet.
Demand forecast error arises where history is not split into failure replacement, scheduled maintenance, and one-off procurement for a specific repair. A "period average plus safety stock" calculation sees neither the component lifecycle nor part interchangeability.
Forecast error costs in both directions. One way, stockouts of parts in the warehouse: manufacturer delivery takes weeks, while equipment downtime and missed repair deadlines hit the entire chain.
The other way, dead stock: buying with a "just in case" buffer freezes working capital and shelf space, and some SKUs become obsolete without ever receiving an order.
Next, we break down how this is addressed: why forecasts need to be calculated separately by part classes, what data usually already resides in the accounting system, and why without a clear division of roles between human and model, any automation quickly reverts to the previous manual planning.
What forecasting at the warehouse group level delivers
Manual planning relies on threshold rules: reorder when the balance crosses the reorder point, in a quantity "like last time." For rare parts, this falls apart: for a single SKU the series is too short to separate seasonality from randomness, so inventory either freezes as excess or turns into stockout and emergency reorder.
Calculated planning produces a forecast at the warehouse group level: within a group the series is denser, revealing trend, seasonality, and the substitution effect.
The forecast is delivered not as a single number but as an interval by error quantiles, then allocated to SKUs in proportion to their share of shipments: demand forecast accuracy is preserved both for the group and for a specific part.
Safety stock grows out of the interval: for fast-moving SKUs it is tied to the upper error quantile and lead time, for rare ones to failure risk and order completeness.
This yields measurable effects: a 20–40% reduction in excess stock without a drop in part service level, higher inventory turnover by removing non-moving stock, and a sharp reduction in the share of emergency reorders.
We align metrics with the industry vocabulary: in SCOR these are forecast accuracy, turnover, and service level, so the effect is visible not only in the model report.
Warehouse workload becomes even: receiving runs without peaks, space and people do not sit idle between emergencies, and the planner deals not with firefighting stockouts but with exceptions the model has flagged as atypical.
Comparison of inventory planning approaches
The approach is chosen not by "sophistication" but by catalog structure: how many SKUs there are, what share is seasonal, how often demand changes, and how long the history is for each SKU.
Hard replenishment rules support fast-moving SKUs, statistical demand models support seasonal groups, and a trained model supports sparse demand across a large catalog.
Below are four schemes, their applicability conditions, and the points at which each stops maintaining the target service level.
| Approach | When it fits | Where it breaks |
|---|---|---|
| Hard warehouse replenishment rules: reorder point, min-max thresholds, safety stock from average consumption | Fast-moving SKUs with stable demand and short lead time | A shift in sales pattern or supplier disruptions: averages lag by months, inventory freezes |
| Statistical demand models: smoothing and seasonal decomposition | Pronounced demand seasonality and a long, stable history for the SKU | Rare SKUs with short history: estimate variance is higher than demand itself |
| Trained model on history and features: promotions, analogs, supply schedule | Large catalog, with data on substitutes and supply | Requires clean data and regular retraining, otherwise it degrades silently |
| Hybrid planning scheme: model provides demand level, rules provide supply | Heterogeneous catalog where fast-moving and rare SKUs coexist | Harder to maintain: two prediction loops and explicit interfaces between them |
The hybrid planning scheme is compatible with the current procurement loop: the forecast is written into the same place where replenishment rules already operate, so the transition is done by SKU groups without stopping supply.
Teams usually start with seasonal groups, where the shift is visible through turnover and dead stock share, and only then extend the model to sparse SKUs.
Implementation stages: from data audit to handover
Procurement planning breaks not on the calculation but on the input data: one part has multiple SKUs in the catalog, write-offs are recorded without linking to equipment, and some replacements are processed manually.
Until this is sorted out, any spare parts demand forecast merely reproduces the current mess. Therefore, the implementation stages of planning follow a fixed sequence: from historical data audit to handover of the solution into operation.
- Historical data audit. We export warehouse movements and replacement history for the entire available period, consolidate duplicate SKUs, and restore installation dates. The output is a table where each replacement is linked to a part, equipment unit, and date.
- Calculation scheme. We link the spare part to the component, equipment model, and maintenance schedule, and identify groups with common consumption logic: fast-moving, rare, and new without history.
- Demand model setup. We define the forecast dimension: warehouse, region, group. We incorporate seasonality, trend, and lead times, and calculate safety stock and reorder point from the expected error.
- Forecast quality validation. The calculation is tuned on a historical interval and validated on a holdout period that was not used in tuning: we compare error by group and against manual planning.
- Handover of the solution into operation. We move the calculation into the accounting system, document the recalculation and update procedure, train the planner, and hand over the documentation.
After that comes support: quarterly we compare actuals with the forecast and adjust settings if the equipment fleet or supply conditions change.
Configurations, procedures, and documentation delivered
We deliver the package to your repository and walk through it together during acceptance: we check not the presence of files but the reproducibility of the result on your data.
Each document is tied to a specific artifact in the system, so updating settings and updating the description happen as a single change.
- Demand model configuration: planning horizons, seasonal profiles, separate rules for SKUs with rare sales, retraining thresholds, and conditions under which the model reverts to the previous version.
- Data flow diagram: sources of sales history, inventory, lead times, and order statuses; cleaning and aggregation points down to warehouse–SKU–week level; delays at each stage.
- Replenishment procedure: reorder points and safety stock by part class, rounding to multiple packaging units, priorities during stockouts, and manual adjustment rules.
- Model documentation: feature descriptions, quality metrics on the holdout period, analysis of typical errors, and applicability boundaries: where the forecast loses accuracy.
- Responsibility matrix: who approves threshold changes, who owns the SKU master data, who investigates forecast-to-actual variances, and within what timeframe.
- Operating instructions: restarting recalculation, rolling back configuration, adding a new warehouse or sales channel without code changes.
Separately, we provide a log of setting changes and the results of control scenarios: they show how the system behaves during a demand spike and during a supply interruption. Describe your task and we will come back with an assessment and a plan.
Project: warehouse excess stock reduced threefold
The client is a network of service centers with a distributed warehouse: several thousand SKUs, where some parts move daily and others sell in single units per year. Planning was based on average sales over past periods, without seasonality or linkage to equipment models.
The buyer hedged and topped up "just in case": the warehouse grew faster than revenue, while fast-moving SKUs still went into stockout.
We assembled a unified loop: warehouse movement history, a compatibility master data set, a service campaign calendar, and seasonal profiles.
The forecast is calculated separately for each part–region–horizon combination, and the replenishment rule translates it into a reorder point and safety stock for the target service level.
The buyer receives a recommendation directly in the accounting system, not an export for manual review.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Dead stock share in the warehouse | 24% of SKUs | 8% |
| Stockouts on fast-moving SKUs | 11% of requests | 3% |
| Inventory turnover | 2.3 turns per year | 6.1 |
| Emergency purchases outside the plan | 18% of orders | 5% |
| Monthly forecast deviation | ±38% | ±14% |
We also set up a control loop: regular retraining on fresh movements, tracking forecast bias, and automatic reversion to the previous rule if accuracy drops. This removes the main risk: the calculation silently becoming outdated after a change in assortment or supply conditions.
What if you already have your own planning system?
An existing planning system is not an obstacle but a loop we integrate into rather than replace. The first step is to capture the current replenishment rules: reorder point, safety stock, multiple and minimum batch, constraints by warehouse and lead time.
These rules already contain knowledge of the business specifics, and there is no reason to lose them during the transition.
Next comes comparison with the current process on history: we run past periods through the calculation and through the existing rules, and see where recommendations diverge and why.
Usually the causes are explainable: seasonality, one-off promotions, SKU replacements, planner manual adjustments. We analyze variances by SKU group together with those who manage them manually.
Integration with the accounting system is built so that the planner does not change their usual route: the forecast lands in the same order document as before.
In 1С, exchange runs through exports or an intermediate database; we map SKU master data and cross-replacements in advance, otherwise the calculation will run on SKUs that are not in orders.
We migrate rules one by one: valid constraints (multiple, lead times, minimum batch) are left as is, outdated ones are rebuilt.
The transition is gradual: we run one group in parallel, compare recommendations with human decisions, and set a variance threshold at which the calculation goes for review.
Rollback means returning to the previous rule for a specific group, without stopping the entire planning process.
Questions about data, seasonality, and model accuracy
At project start, the same technical concerns come up: whether there is enough history, what to do with new SKUs, and how to distinguish seasonality from a one-off spike. Briefly, here is how we address them in practice.
What if sales history is incomplete?
One or two seasons for active SKUs is enough; we combine rare SKUs into groups by category and interchangeability. We smooth gaps and breaks from accounting system changes before training; otherwise the model will fill them in as a demand decline.
How do you forecast new SKUs without sales history?
For them we use the profile of analogs and the category demand curve: the model adopts the seasonality pattern and the pace of reaching planned volume. Once actuals accumulate, the SKU moves to its own forecast.
How does the model distinguish seasonality from one-off spikes?
We describe seasonality with separate features: month, holidays, promotions, supply schedule. We flag outliers during data preparation and remove them from training; a spike left in the sample overstates the forecast for the entire horizon and creates excess stock.
How do you monitor forecast quality after launch?
We compare the forecast with actual shipments for each SKU and category, track systematic bias and the share of SKUs within the acceptable corridor. We retrain the model on schedule and adjust features when the assortment or supply logic changes.
Let's discuss your inventory planning task
To move from general discussion to numbers, little is needed: an export from the accounting system and a description of how planning is currently set up. That is enough to run a pilot calculation on your history and show how the model behaves on your SKUs, not on demo data. To discuss the task in concrete terms, it is worth preparing for the first meeting:
- SKUs and history depth: which groups we plan inventory for and how many periods of warehouse movement are available.
- Granularity and horizon: whether we plan by day, week, or month, and how far ahead the decision is needed.
- Demand features: region, channel, customer type, seasonality, promotions, SKU interchangeability.
- Supply constraints: lead times, minimum batches, packaging multiples, warehouse capacity.
- Inventory management rules: target service level, safety stock, what is considered a stockout and excess stock.
- Data quality: gaps, manual adjustments, outliers, SKU and supplier changes.
- Access and owners: system export, test environment, who accepts the result and approves the procedure.
After that we come back with an assessment and work plan: stages, implementation timelines, control points, and the scope of handover into operation: documentation, model retraining procedures, and instructions for planners.
Describe the task in whatever format is convenient for you; we will respond to the point and propose a work sequence.
