Demand Planning in ERP: Turning Sales History Into a Forecast You Trust

A regional beverage distributor turned on their ERP's built-in demand planning module, let it run against three years of sales history, and got a forecast that told purchasing to stock up heavily on a seasonal iced tea line in December — the exact month that product's sales historically dropped to nearly zero. The problem wasn't the software. It was that the default forecast model used a simple trailing average that treated a summer sales spike as a persistent trend rather than a seasonal pattern, and nobody had corrected it before purchasing started using the numbers.

Demand planning modules are only as good as the assumptions embedded in how they're configured, and the gap between "we have a demand planning tool" and "we have a forecast people actually trust and use" is almost always in that configuration, not in the underlying software's capability.

What demand planning inside an ERP actually does

At its core, demand planning takes historical sales data (and sometimes other inputs — promotions, pricing changes, external factors) and projects expected future demand at whatever level of granularity you need: by SKU, by location, by customer, typically by week or month. That forecast then feeds into purchasing (how much to reorder and when), production scheduling (what to build and when), and inventory targets (how much safety stock to hold). Get the forecast wrong and the errors compound downstream — the beverage distributor's bad December forecast would have tied up warehouse space and cash in unsellable seasonal stock had a purchasing analyst not caught it manually before the PO went out.

The forecasting methods that actually matter to understand

Most ERP demand planning modules offer a choice of statistical methods, and picking the wrong one for your sales pattern is the single most common cause of forecasts nobody trusts:

• Simple moving average works reasonably for stable, low-variability products with no seasonality — a steady B2B consumable, for example. It performs badly, as in the opening example, for anything seasonal, because it treats recent history as equally representative of the future regardless of the time of year.
• Seasonal decomposition / seasonal indexing explicitly separates a trend component from a seasonal pattern, which is what the beverage distributor needed for their iced tea line — it would have recognized "August is always high, December is always low" as a repeating pattern rather than noise.
• Exponential smoothing weights recent data more heavily than older data, which works well for products with a genuine trend (steadily growing or declining demand) that a flat average would understate.
• Causal/regression-based forecasting incorporates external variables — planned promotions, price changes, even weather correlation for some product categories — and is the most accurate option for products where demand is driven by something other than pure time-based pattern, but it requires more setup and cleaner input data to be worth the added complexity.

Most systems let you assign different forecasting methods to different product categories rather than forcing one method across the entire catalog, and that's usually the right approach — a seasonal product and a stable, flat-demand product shouldn't be forecast the same way just because they're both SKUs in the same system.

Inputs that a pure statistical model misses

Even the right statistical method only sees what happened historically, and history alone misses known future changes. A demand plan that ignores these produces confidently wrong numbers:

• Planned promotions or price changes. If a 20%-off promotion is scheduled for a product next month, a pure historical-average forecast has no way to know that, and will understate expected demand significantly.
• New product introductions or discontinuations, which by definition have no historical sales data at all and need a manual initial forecast, often based on a comparable existing product, until real sales history accumulates.
• Known customer-level changes — a large account that's expanding, contracting, or churning — which a SKU-level aggregate forecast won't catch unless demand planning is broken out by customer or channel for your largest accounts specifically.

The practical fix is a regular sales and operations planning (S&OP) meeting — typically monthly — where the statistical forecast gets reviewed by someone with direct knowledge of upcoming promotions, known account changes, and market conditions, and adjusted before it's finalized and sent to purchasing. Treating the system-generated forecast as a draft that a human refines, rather than a finished number that flows straight to purchasing, is the single biggest factor separating companies that trust their demand plan from ones that quietly override it constantly because it's wrong too often.

How the forecast connects to safety stock and service levels

A demand forecast on its own only says what you expect to sell. It's the second half of the calculation, safety stock, that determines how much of a buffer to carry against the forecast being wrong, and that buffer needs to be sized deliberately rather than defaulted to a flat percentage across every SKU. Safety stock should scale with two things: how volatile a product's actual demand is relative to its forecast (a product with a MAPE of 40% needs a much bigger buffer than one at 10%, even if both average the same unit volume) and how costly a stockout is for that specific product (a fast-moving, high-margin SKU where a stockout sends a customer to a competitor deserves a bigger buffer than a slow-moving item where a short delay is a minor inconvenience). Treating every product with the same safety stock rule — a flat two weeks of coverage, for instance — typically means overstocking the stable, easy-to-forecast items and understocking exactly the volatile ones where the buffer actually matters, which is a common, quiet cost sitting on top of an already-imperfect forecast.

Forecasting a genuinely new product

New product introductions deserve a specific mention because they're the case a pure statistical model handles worst — there's no historical data to project from at all. The standard approach is analog forecasting: picking an existing, comparable product (similar category, similar price point, similar target customer) and using its early sales trajectory, scaled up or down based on known differences, as the new product's initial forecast, then replacing that analog-based estimate with the product's own real sales data as it accumulates, typically after 8-12 weeks of actual sales history. Skipping this step and just guessing a round number, or worse, defaulting new products to zero forecast until the system has "enough" historical data to generate one automatically, tends to produce exactly the stockout-then-overcorrection cycle that makes a new product's first quarter on shelf far messier than it needs to be.

How to know if your current demand plan is actually working

The standard metric is forecast accuracy, typically measured as Mean Absolute Percentage Error (MAPE) — how far off, on average, the forecast was from actual demand, expressed as a percentage. There's no universal "good" MAPE number; it depends heavily on the product category. A stable, low-variability product might reasonably target under 15% MAPE, while a highly seasonal or promotion-driven product might be considered well-forecast at 30-35% MAPE. What matters more than hitting a specific benchmark is tracking it consistently over time and by product category, so you can see whether accuracy is improving, and specifically which product categories are driving the biggest misses — that's where configuration or method needs attention, not a system-wide overhaul.

A basic setup checklist

1. Segment products by demand pattern (stable, seasonal, trending, promotional) before choosing a forecasting method — don't apply one method to the whole catalog.
2. Build a monthly S&OP review into the process where a human adjusts the statistical forecast for known future changes the model can't see.
3. Track forecast accuracy (MAPE) by product category, not just in aggregate, to find where the model is actually failing.
4. For new products, use a manual analog forecast against a comparable existing item until real sales history accumulates.

The beverage distributor fixed their setup by reclassifying their seasonal SKUs to use seasonal indexing instead of a simple moving average, and adding a monthly review where their sales manager flagged upcoming promotions before the forecast finalized. Their MAPE on seasonal products dropped from over 60% to under 25% within two forecast cycles — not because the software changed, but because the assumptions feeding it finally matched how their actual demand behaved.