Judgmental adjustments and forecast governance
Today let's understand when a person should reach in and change a statistical forecast by hand, and when that same habit is quietly making the forecast worse.
Priya is the demand planner for a company that sells insulated steel water bottles online. Every month a statistical model forecasts next month's unit sales for one product line, and before that number goes to the factory, Priya can adjust it herself. Over the last 12 months she adjusted it 6 times.
Here is her whole year: the statistical forecast, the adjusted forecast she actually sent to the factory, and what customers actually bought.
Look at where the adjusted forecast, the line Priya actually sent to the factory, pulls close to the actual line in some months and pulls away from it in others. That gap, and why it opens up only sometimes, is what this lesson explains.
What counts as a judgmental adjustment
A judgmental adjustment is a change a person makes to a model's forecast, by hand, before that forecast gets used. The statistical forecast is whatever the model computed from past sales. The adjustment is the amount Priya added or subtracted. The adjusted forecast is the statistical forecast plus the adjustment, and that adjusted number, not the model's own number, is what actually goes to the factory.
Build Priya's 12-month ledger: the statistical forecast, the adjustment, the adjusted forecast, and what customers actually bought.
In 6 of the 12 months, the adjustment is 0, meaning Priya left the model's number untouched. In the other 6, she changed it, by as little as 90 units and as much as 220.
Now measure how those 6 changes did overall, using mean absolute error, MAE: the average size of a forecast's miss against the actual, ignoring whether it missed high or low.
The statistical forecast alone misses by 55.42 units a month on average. The adjusted forecast, the one Priya actually sent, misses by 69.58, which is 25.6% worse. Read only this one number, and Priya's adjustments look like they made things worse across the board.
Lay the whole ledger out as a table, with each override's reason attached.
Every override in this table has a reason attached. But not every reason points to the same kind of thing: some name a fact the model could not see, and some do not.