Here's my verdict up front: nine times out of ten, it's the data.
I've watched this movie too many times over twenty years in warehousing. A DC spends serious money on an AI demand forecasting module, the model goes live, and three months later replenishment is still driven by a veteran planner's gut feel. IT's first instinct is always "the model is wrong, let's try a different algorithm." Mine is always the same: don't touch the model yet — pull out the data you fed it and take a good look. Almost every time, that's where the problem lives.
A model is just a very diligent student. Hand it a textbook full of missing pages and typos, and you can't blame it for failing the exam.
First question: is your data even complete?
A lot of forecasting projects die at step one: the SKU master data is a mess.
A few years back I walked through a 3PL facility in Ontario, California — well over a hundred thousand square feet, north of twenty thousand SKUs — that had rolled out ML-based replenishment forecasting. Six months in, accuracy was miserable. We dug in and found that fields like product category, seasonality flag, and substitution relationships were blank for a huge share of the catalog. New items sat in the system for months with no category assigned at all. What exactly was the model supposed to learn from? Thin air?
Then there's inconsistent tagging: the same product labeled "winter style" in one DC, "Winter-2023" in another, and left blank in a third. The model sees three different products and learns the wrong patterns for all of them.
The check is simple: pull 200 random SKUs and look at category, seasonality, lifecycle status, and substitution fields. If null rates run past twenty percent, stop talking about models and go fix your master data. It's unglamorous work, but skip it and everything downstream is wasted effort.
Second question: are you even measuring the right thing?
This is the sneakiest failure mode I know. The "historical sales" your model trains on often isn't real demand at all.
Classic case: a SKU stocked out for two weeks last November, so the system recorded zero sales. The model learned "nobody wants this SKU in November" and understocked it this year — except this year there was no stockout, demand showed up as usual, and the shelf went empty. A zero during a stockout isn't demand. It's the ceiling of what you could supply. Teach the model to mistake the ceiling for the floor and it can't possibly be right.
Another one: inter-warehouse transfers. DC A runs short, so 500 units move over from DC B, and DC B's outbound log picks up 500 units of "sales." The model sees strong demand at DC B for that SKU and tells you to stock up — stocking up on phantom demand that was actually just an internal transfer. Real demand and internal moves blended into one number will skew every forecast.
And don't forget returns. In e-commerce fulfillment, gross versus net sales can differ wildly. Train on gross and the model will chronically overestimate.
The check: find the document that defines your sales metric — if one exists — and ask three questions. How are stockout periods handled — did anyone reconstruct true demand? Are transfer shipments excluded? Gross or net? If nobody can answer, or the answer is "we never dealt with that," you've found the root cause. With a muddy metric, the smarter the model, the more confidently wrong it gets.
One more thing worth saying: plenty of warehouses pipe sales data straight out of the ERP, and ERP outbound records don't distinguish "sold to a customer" from "shipped to our sister DC." Nobody does that cleaning step, so the model studies fake demand all day. I usually ask the data team to split a year of outbound records into sales, transfers, and scrap first. That single step often shrinks several SKUs' "historical demand" noticeably — and every unit that disappears was noise.
Third question: did anyone tag the events?
Forecasting models hate unexplained spikes. Sales doubled one month last year, the model memorized the pattern, and this year it stocked double — except last year's spike was a big promotion and this year there is none. Now you're sitting on dead stock.
Promotions, clearance events, influencer-driven surges, freak weather, a competitor's stockout — if none of these are tagged, the model absorbs them as "natural demand." What it learns isn't a pattern. It's noise.
The worst case I saw: three years of pandemic-era hoarding data sitting in the training set with zero annotation. The model treated those abnormal peaks as the baseline, kept everyday safety stock permanently high, and dead inventory filled two full aisles. Once that period was tagged and down-weighted, the forecast snapped back to reality.
There's also an easy-to-miss dimension: supply-side events. A supplier's late delivery, a port strike pushing inbound back three weeks — these carve inexplicable holes into the sales curve. The model can't understand "we couldn't sell because the goods never arrived." It just learns "nobody wanted this SKU that month." So your event calendar can't only track promotions. Log major supply disruptions and inbound anomalies too. Tag both sides or the picture stays incomplete.
The check: take the ten SKU-months with the wildest historical swings and ask the business team what happened. If they can explain more than half of them but the system records none of it, your event calendar is empty. Capturing event tags takes the business side ten minutes to describe and the data team maybe two weeks to implement — worth every hour.
So when is it actually the model's fault?
Once the data passes all three checks — master data complete, metrics clean, events tagged — and the forecast still misses, then yes, let's talk models. I'll be the first to agree.
Real model problems look like this: the data is clean, yet simple and complex models perform about the same, sometimes with the simple one slightly ahead. Or the demand distribution has structurally shifted — say the business moved from wholesale to retail, or from brick-and-mortar to online — and the old model learned the rules of a world that no longer exists.
Then there's feature engineering falling short. Feeding the model nothing but a sales time series, while leaving out price, inventory position, and lead time — the features the business actually runs on. That's less "wrong algorithm" than "the modeler doesn't understand warehousing." Switching algorithms won't help; bringing in someone who understands replenishment will.
In my experience, features beat algorithms in this domain almost every time. A planner who understands reorder logic plus a plain regression will usually outperform a fancy model tuned by someone who's never set foot on a warehouse floor. Warehouse demand drivers are concrete: the promo calendar, open orders, seasonality, supplier lead-time variability. Turn those into features and you'll get further than any architecture swap.
My rule of thumb is simple: if three different models score about the same on the same clean dataset, the bottleneck isn't the model. Tuning model selection on dirty data is just expensive busywork.
A data-prep checklist you can actually use
Diagnosis done — now go clean house. In this order, no skipping:
- Master data: category, seasonality, lifecycle, and substitution fields for every SKU, null rates under five percent
- Metrics: reconstruct true demand for stockout periods (at minimum, flag them), strip out transfer shipments, train on net sales
- Events: build an event calendar — promotions, clearance, freak weather, one-off bulk orders, all tagged
- Granularity: make sure forecast granularity (SKU-DC-week) matches the granularity of your replenishment decisions; right forecast at the wrong granularity is useless
- Backtest: run a three-month backtest on the cleaned data and study the error distribution before anything goes live
Most warehouses that finish these five steps discover something funny: their old model suddenly got "smarter." It was never dumb. It had just been reading a textbook full of typos.
One self-test question to take home: in the historical sales you're feeding your forecasting model right now, can you tell which rows are real demand, which are stockouts, and which are internal transfers? If you can't tell them apart, don't rush to swap models — split those three apart first. Once that question is answered, most of the mystery around bad forecasts dissolves.
