Data Department builds demand forecasting and inventory optimisation systems for distributors, manufacturers, retailers and restaurant chains. We forecast demand per item, location and period with an honest range of uncertainty, then turn that range into reorder points, safety stock and production plans that planners use every day. We built such a system for a distributor with more than 100,000 active spare parts.
What problems does demand forecasting solve?
A forecast is only useful when it changes a decision. The decisions we work on:
- How much to order, of which item, for which warehouse, and when.
- How much safety stock to hold for a part that sells three times a year.
- How many staff to roster and how much to prepare per store, per 15-minute slot.
- Which slow-moving or obsolete stock to stop replenishing.
- How to position stock across channels such as authorised service, dealers and direct sales.
A single number ("we will sell 40") hides the risk. We give planners a forecast with a range ("between 28 and 55, with 90% probability"). Planners then choose a service level per item and see what it costs in stock. This is why we say forecast accuracy alone is not enough.
What does a demand forecasting project need?
- At least two years of transaction-level sales or order history (item, location, date, quantity). Three years is better for seasonality.
- Item master data: categories, prices, lead times, substitutions and supersessions.
- Current stock and open purchase orders from your ERP (enterprise resource planning) system.
- Known demand drivers where they matter: promotions, price changes, holidays, weather, store openings, installed base or vehicle park.
Messy data is normal. Discovery measures how messy it is and whether that blocks the project.
What a project looks like
Discovery (2 weeks). We check the data, measure the accuracy of your current method so there is a fair baseline, and split items into demand segments. You get a go/no-go decision and a ranked list of where forecasting pays off first. Your team provides data access and a few hours with a planner.
Pilot (6–10 weeks). We build models for one category, region or channel and backtest them on your own history against your current method. The business metric is agreed on day one, for example inventory holding cost at the same fill rate. Planners review forecasts weekly and tell us what looks wrong.
Production and handover. We deploy a containerised pipeline on your cloud (AWS, Google Cloud, Azure) or on-premises servers, with daily or weekly updates written back to ERP and planning tools. We add drift monitoring and train your planners and IT team to run it.
Which forecasting method fits which demand pattern?
No single model fits every item. We segment first, then choose.
| Demand pattern | Typical method | Why |
|---|---|---|
| Frequent, regular sellers | Gradient boosting with seasonality and calendar features | Learns many drivers at once and scales to large catalogues |
| Sporadic or intermittent items | Hierarchical Bayesian or intermittent-demand models, using substitution data | Borrows strength from similar items when an item rarely sells |
| High-value items | Conservative models tuned for availability | A stock-out costs more than the holding cost |
| New items with no history | Attribute-based models that learn from similar products | Gives a starting forecast until real sales arrive |
| Short intervals (hourly, 15-minute) | Models with weather, holiday and search-trend signals | Supports staffing and production within the day |
Results from real projects
For a large automotive distribution group with more than 100,000 active spare parts across several brands and channels, we replaced legacy point forecasts with probabilistic, segmented models. The system was built on AWS (Amazon Web Services), with daily updates. Forecast accuracy improved by about 30% over the legacy method and inventory holding cost fell by about 10%. Read the spare parts case study.
For two national quick-service restaurant chains, we tested our approach on their own data. One forecast sales per store, per product, in 15-minute slots, with an average error of about 1.1 items per product per store per slot. The other forecast store-level stock and demand for 10 restaurants and 574 products and came out about 19% better than the existing baseline. Read the restaurant forecasting case study.
When is forecasting NOT the right tool?
- Too little history. If products change every season and have no comparable predecessors, planner judgment plus simple rules can beat a model.
- The bottleneck is elsewhere. If supplier lead times are unreliable or warehouse execution is the problem, a better forecast will not fix it.
- No one will change the process. If planners keep overriding everything, accuracy gains stay on paper. We check adoption early.
- Only a few items matter. A good analyst with a spreadsheet may be enough.
When the real question is allocation or scheduling under constraints, forecasting feeds into optimisation and simulation rather than standing alone.
Frequently asked questions
How much data do we need for demand forecasting?
Two years of item-level sales or order history is the usual minimum; three years helps with seasonality. Discovery tells you whether your data is enough before you commit to a pilot.
How long until we see results?
Discovery takes 2 weeks and the pilot 6–10 weeks. You see a backtest against your current method before deciding on production.
Will it work with our ERP?
Yes. Whether you run SAP, Microsoft Dynamics or an in-house system, we read data through database views, file exports or APIs (application programming interfaces) and write forecasts back the same way.
What drives the cost of a forecasting project?
The number of items and locations, data sources, integration depth, update frequency, and whether you also want inventory policy optimisation.
Does forecasting use personal data?
Usually not. Demand forecasting works on aggregated item and location data, so KVKK (Türkiye's Personal Data Protection Law) and GDPR (General Data Protection Regulation) obligations are normally limited.