Two different questions
'How many will we sell next week' is a prediction. 'Given that, which supplier should we order from, in what quantity, to which warehouse' is an optimisation.
They need different techniques, different expertise and different data. Projects routinely scope the first when the business needed the second, deliver an accurate forecast, and discover that nothing changed because the decision was never addressed.
How to tell which you have
| Signal | Points to |
|---|---|
| The answer is a number about the future | Prediction |
| The answer is a choice among options | Optimisation |
| There are hard constraints - capacity, hours, budget | Optimisation |
| Choices interact - allocating here means not there | Optimisation |
| You want to know what will happen | Prediction |
| You know what will happen and need a plan | Optimisation |
The constraint row is the clearest test. If the answer must respect limits - vehicle capacity, contracted hours, a budget - then a prediction alone cannot produce it.
Common problems that are optimisation
- Vehicle routing - which stops in which order, within driver hours
- Staff rostering - who works when, within contracts and skills
- Production scheduling - what to make in what order on which line
- Stock allocation - how to split limited stock across sites
- Price setting under capacity limits - where selling more is not always possible
Each consumes predictions - demand, duration, availability - but the decision itself comes from a solver that respects the constraints. Handing a planner a forecast and expecting them to work out the rest is how a technically successful project delivers nothing.
They work together
The usual architecture is prediction feeding optimisation. Predict demand, service time, or failure probability; then optimise the plan given those predictions and the constraints.
This has a practical consequence for scoping: the prediction's accuracy matters only insofar as it changes the optimised plan. A forecast improvement that never changes the route is worth nothing, which is a useful test for where to spend effort.
Do not build a solver by accident
Teams sometimes attempt optimisation with machine learning because that is the expertise available, training a model to imitate good plans. This usually works poorly - it cannot guarantee constraints are met, which is the entire point.
Established optimisation methods handle these problems well and have done for decades. Recognising that a problem is optimisation is often the single most valuable decision in the project, because it directs you to tools that will actually solve it.
An accurate forecast that nobody can turn into a plan has not changed anything.