The indicators: forecast and error
A forecast without a measure of its error does not help anyone decide. The most used indicators compare forecast and actual once the period is closed; bias says whether the forecast tends to sit above or below.
WAPE = Σ |actual − forecast| ÷ Σ actual
MAPE = average of |actual − forecast| ÷ actual, period by period
Bias = Σ (forecast − actual) ÷ Σ actual
Band = the range where the actual value is expected to fall, with the chosen probability
WAPE is sturdier than MAPE for items that sell very little in some periods. The guide to demand forecasting compares methods and has a forecast error calculator.
What the dashboard shows
- Forecast against actual sales by item and family, with the band around the forecast.
- Error by family: WAPE and bias over recent weeks, to know where the forecast can be relied on and where it cannot.
- Items at risk of running short: those where the forecast for the coming weeks exceeds available stock.
- Error over time, to notice when a model starts to get worse.
The data you need from the database
| Data | Typical fields | What it is for |
|---|---|---|
| Sales or shipments | date, item, quantity, store or customer | The history to forecast from |
| Items | code, family, status (active, phasing out, new) | Grouping and excluding discontinued items |
| Stock | item, warehouse, quantity | Comparing with the forecast |
| Promotions calendar | item, period, kind of promotion | Explaining peaks instead of chasing them |
The promotions calendar often lives in an Excel file: it is loaded as a source of its own.
The steps in Muvia
In New source choose PostgreSQL, give the server and a read-only user, and select sales, items and stock. Muvia copies them on the schedule you choose, incrementally and over an encrypted TLS connection.
A query prepares the history at the level you reorder, for example item and week.
A predictor of the Forecast kind is created from that query in four steps (what, from where, when, alarm) and returns the expected value with a band; the ready-made forecast needs no training. If your data scientist already has a model, it is uploaded as a file and tried before it is activated.
A flow applies the forecast every night and writes a forecast table; another query compares it with actual sales and calculates WAPE and bias.
The dashboard shows forecast, actual and band; an alarm flags the items where the forecast exceeds stock.
The pitfalls of sales history
- Sales are not demand: on days when the item was out of stock, sales were zero but demand was there. Mark those days and do not use them as if they were real demand.
- Promotions: a promotional peak teaches the model a demand that does not exist without the promotion. The promotions calendar is what separates it.
- New items: with no history, the forecast leans on the family or on similar items, with a wider band.
- Level of detail: forecasting by item, day and store is noisier than by family and week. Choose the level by how you reorder.
Frequently asked questions
Not to start: Muvia's ready-made forecast starts from a query and needs no training. If your team already has a model, it is uploaded as a file and Muvia runs it every night next to the data.
A predictor's versions cannot be edited: the first becomes active, later ones are candidates that a person promotes or rejects, and you can go back to a retired version.
It depends on the data and the items, and nobody can say in advance. That is why the dashboard measures error once each period closes: that is what will tell you where the forecast can be relied on.
The path is the same. The demand forecasting use case reads sales from SQL Server and stock from Oracle.