The stockout was visible three weeks before it happened. The supplier's deliveries had been slipping by a day, then two, then four. Demand for that line had crept up. Both facts sat in the ERP, correctly recorded, in different tables, and nobody joined them until the shelf was empty.
That is the gap predictive ERP exists to close — not new data, just data nobody was looking at in combination.
Reporting looks backwards by design
Traditional ERP reporting answers questions about what happened. What did we sell, what did we spend, what is on hand. Excellent for accounting, which is where ERP came from, and structurally past-tense.
The questions that actually change outcomes are forward-facing. Will we run out of this before the next delivery arrives? Is this supplier about to miss? Which of next month's orders are at risk? A conventional system can answer none of these, so a person builds a spreadsheet, applies judgement, and produces a forecast whose quality depends entirely on how experienced they are.
That is not a technology gap so much as a workload one. The analysis is possible; nobody has time to do it across four thousand SKUs every week.
What the predictions actually are
Strip the marketing and there are four useful ones.
Demand forecasting. How much of each item will sell over the coming weeks, accounting for seasonality, trend, and promotions. The foundation for everything downstream — get this wrong and every derived recommendation is wrong with it.
Supplier delivery risk. Which purchase orders are likely to arrive late, based on that supplier's history, the item, the quantity, and the season. Most companies hold this in someone's head as "they're always late in December."
Stockout and overstock prediction. Combining the two above with lead times and current positions to say which items will run short, and when — early enough to do something about it.
Cash and receivables timing. Which invoices are likely to be paid late, which changes your cash forecast and your collections priority.
None of these are exotic. What is new is that they run continuously across the whole catalogue rather than on the twenty items someone had time to check.
Fig. — The output that works is a short list of things to act on, not another dashboard.
Why the data quality warning is not boilerplate
Forecasting is more sensitive to data quality than almost anything else you might build on an ERP, and the reasons are specific.
A model learns from history, so it learns your errors as patterns. If stock counts were wrong for six months after a warehouse move, the model treats that as real demand behaviour. If a product was recoded and now appears as two items, its history is split and both halves look like declining lines.
Lead times are the usual disaster. Most ERPs hold a lead time per supplier that someone entered at setup and nobody has revisited. If the field says fourteen days and reality is twenty-two, every recommendation inherits the error, confidently.
And one-off events pollute the record. The month a single customer ordered ten times normal volume looks like demand unless it is flagged as an outlier. Systems that cannot mark exceptions learn to expect them.
Before any forecasting project: check stock accuracy against a physical count, check lead times against actual receipt dates, and find the duplicate product codes. That work is unglamorous and it determines the outcome more than the choice of system.
Where it earns its keep
Inventory carrying cost. Better forecasts mean less safety stock for the same service level. In a business with significant working capital tied up in inventory, a modest reduction is a large number, and it is measurable.
Avoided stockouts. The cost of running out is usually understated because the lost sale leaves no record. Businesses that measure it — through substitution rates or customer complaints — find it larger than expected.
Purchasing time. Buyers spend a great deal of time working out what to order. A system proposing an order they review and adjust reclaims that, and the reclaimed time goes into supplier negotiation, which is where buyers actually add value.
Fewer expedite costs. Air freight to cover a late delivery is expensive and almost always the result of finding out too late. This is often the easiest saving to evidence, because expedited shipments usually sit in their own cost line and someone can tell you last year's total without much effort.
The honest picture: this is a margin improvement, not a transformation. It is worth real money in inventory-heavy businesses and close to nothing in businesses that hold little stock.
Built in, bolted on, or built yourself
There are three routes to this and they suit very different situations.
Native to your ERP. Most major vendors now ship forecasting modules. The advantage is decisive: the model already has your data, your permissions, and your audit trail, and the output appears where buyers already work. Turning on a module beats integrating a product. The limitation is that you get the vendor's approach, and depth varies enormously between vendors — some are genuinely capable, some are a moving average with a confident label.
A specialist planning tool. Purpose-built supply chain systems are considerably more sophisticated and priced accordingly. They earn their place in businesses where inventory is the core of the operation and a percentage point of accuracy is material. The cost is another integration to maintain and another place people have to look.
Building it. Rarely correct. The modelling is the easy part — demand forecasting is a well-understood problem with mature libraries — and the hard part is the data pipeline, the exception handling, and the interface buyers will actually use. Teams that build usually end up maintaining a fragile pipeline instead of improving the process.
The question worth asking your ERP vendor is specific: what does the module actually do about intermittent demand, promotional uplift, and supplier variability. Vague answers to those three tell you what you are buying.
Where it fails
Genuinely new products. No history means no forecast. Systems will produce a number anyway, based on similar items, and the confidence attached to it should be treated sceptically.
Structural breaks. A model trained on the past assumes the future resembles it. A new competitor, a regulatory change, or a sudden shift in customer behaviour invalidates that, and the model will keep forecasting the old world for a while.
Long, lumpy demand. Items ordered rarely in large quantities are statistically hard. Forecasts for them are poor and known to be poor, and a system that presents them with the same confidence as a fast-moving line is actively misleading. Ask whether yours distinguishes.
Trust, once lost. A buyer who follows a recommendation and gets burned stops following recommendations. Recovering that takes far longer than the original rollout, which is why the first few months should be conservative and closely reviewed.
Making it usable
Surface exceptions, not dashboards. A buyer does not want a demand curve for every item; they want a list of the eleven things that need a decision this week, ordered by consequence. Systems that produce beautiful analytics and no prioritised list get ignored.
Show the reasoning. "Order 400 units" is an instruction. "Order 400 units — demand up 15% over eight weeks, supplier averaging six days late, current cover 11 days" is an argument someone can agree or disagree with. The second gets followed; the first gets overridden.
Keep the human in the loop at first. Recommendations that a buyer approves, with their overrides recorded. Those overrides are the most valuable feedback you will get — a pattern of consistent overriding in one category means the model is missing something real about it.
And measure forecast accuracy explicitly, by category, over time. Without that you cannot tell whether it is working, and you cannot tell where it is not. Most implementations that quietly fail do so because nobody was tracking whether the predictions were any good.
There is an organisational point hiding in that last one. Forecasting changes who decides what to order, and buyers with twenty years of experience are being asked to defer to a system on a task they consider their craft. Handled as a productivity mandate, that goes badly. Handled as a tool that clears the routine eighty percent so they can concentrate on the difficult lines and the supplier relationships, it goes well — and their overrides make the system better, which is worth telling them explicitly.
Start with your highest-value, highest-volume items where history is clean and lead times are known. Prove it there, publish the accuracy, and expand into the messier categories once buyers are asking for it rather than being asked to use it.
