AI solution design · Databases and data
Forecasting from your own history
Learn from years of orders or jobs to predict next month's workload, and publish the forecast back where your team already looks.
Talk about something like thisThe situation
An operations team plans staffing and stock from last year's spreadsheet. The orders database holds several years of history, including seasonal patterns, promotions and the odd bad month, but nobody has had the time to use it for anything except reports.
How it works
Step by step
- 1
Check the history
Pull the data and look for gaps, one-off events and seasonality. If there is not enough good data, we say so at this point.
- 2
Set a baseline
First measure something simple, such as "same week last year". Any model has to beat that to be worth having.
- 3
Build and compare
Train a model on the history, test it on months it has not seen, and compare it with the baseline.
- 4
Publish the forecast
Write the forecast, with a range and not a single number, to a table in your database and a Power BI report.
- 5
Keep watching
Compare each forecast with what actually happened and retrain when accuracy slips.
What it is built from
- SQL Server
- Source history and a table of published forecasts
- Python and scikit-learn
- Model building and testing
- Azure Machine Learning
- Scheduled training and monitoring
- Power BI
- The forecast alongside actual figures
Safeguards
- Always compared with a simple baseline, so you know the model is earning its place
- Forecasts shown as a range, with the assumptions listed
- Accuracy tracked against actual results, month after month
- A plain-English description of what the model does and does not take into account
What you end up with
- A weekly or monthly forecast in a table and a report
- A measured accuracy figure against the baseline
- An alert when the model has drifted and needs retraining
Where to start
Start with one measure, such as weekly order volume, and prove it on past data before relying on it for the future.
More in this group
Ask your database
Managers ask a question in plain English and get a table from the SQL Server database, with the query and an explanation shown.
Read the design →Cleaning up customer data
Find likely duplicates, standardise messy free-text fields and flag bad records, with a person approving every merge.
Read the design →