SAP Forecast Models Tutorial (Part 1)

In SAP IBP for demand planning, a forecast model is a statistical algorithm (such as exponential smoothing variants, Croston's method for intermittent demand, or seasonal linear regression) that IBP applies to historical time series data to generate a future demand signal. The business purpose is simple but critical: manual forecasting does not scale across thousands of product-location combinations, and statistical models give planners a repeatable, auditable starting point that they then adjust with judgment (promotions, market intelligence, new product introductions).

A forecast model is never run in isolation. It is invoked through a forecast profile, which is a configuration object bundling together the statistical method, the historical key figure(s) used as input, the output key figure(s) that will store the result, the planning level (the level of aggregation such as product/location/week), and parameters like the number of historical periods to consider and forecast horizon length. The forecast profile is what a planner or administrator actually selects when running an interactive or batch forecast job.

SAP IBP typically ships model families that a consultant should know at a conceptual level: single and double exponential smoothing (for level and trend), triple exponential smoothing / Holt-Winters style models (for level, trend, and seasonality), Croston's method (for sporadic/intermittent demand with many zero-demand periods), and multiple linear regression style causal models that can incorporate independent variables such as price or promotional indicators. IBP also offers an automatic model selection capability where the system evaluates several candidate models against historical data and picks the one with the best fit based on error metrics, rather than the consultant hard-coding a single method for every product.

Key figures are central to how forecasting works technically. Historical demand is stored in a key figure (for example a corrected history or shipments key figure), and the forecast model consumes that as input, writing its output into a statistical forecast key figure. Planners can then see this statistical forecast alongside other key figures (sales orders, override forecasts, consensus demand) in the same planning view, because IBP's model is fundamentally a multi-key-figure time series structure, not a document-flow system like ECC/S4 sales order processing.

From an implementation perspective, a consultant configures forecast profiles in the demand planning app (or via the corresponding Fiori configuration UI), specifying the master data level, the historical and future key figures, the algorithm parameters, and whether the profile runs interactively or as part of a batch job. Getting this level of detail right early prevents rework: if the planning level is too granular, forecast quality suffers due to noisy history; if it's too aggregated, it loses the granularity operations needs.

For someone new to IBP, the important mental model is: history flows in, a mathematical model transforms it, a number flows out into a key figure, and that number becomes one input among several that planners reconcile into a final consensus demand plan. Nothing here talks to a transactional system directly; forecast models operate purely within IBP's in-memory planning area on time series data that has usually already been loaded or integrated from S/4HANA or other source systems.

A consumer goods company implementing IBP demand planning has three product categories: stable staple products, seasonal products (sunscreen, holiday items), and new-launch products with almost no history. The consultant sets up three different forecast profiles: a simple exponential smoothing profile for staples, a seasonal (triple exponential smoothing) profile for the seasonal category with a 52-week cycle, and a like-item/reference-based approach for new launches since there isn't enough history for statistical models to be reliable. Planners review each category's statistical forecast weekly and adjust for known events not captured in history, such as an upcoming promotion.

• Applying one generic forecast profile to all products regardless of demand pattern, leading to poor accuracy for seasonal or intermittent items
• Confusing the forecast model (the algorithm) with the forecast profile (the configuration object that invokes it), which causes confusion during configuration reviews
• Setting the historical period window too short, so seasonal patterns never get captured, or too long, so obsolete demand patterns skew the model
• Not validating that the input history key figure is actually clean (returns, corrections, outliers) before trusting the statistical output
• Assuming the statistical forecast is the final number, when it is meant to be a starting point for consensus adjustment

• Segment products by demand pattern (stable, seasonal, intermittent, new) before assigning forecast profiles
• Keep the statistical forecast key figure separate from planner-adjusted and consensus key figures so history of change is preserved
• Periodically review forecast error (e.g., MAPE) per profile to catch model drift
• Document why each forecast profile was configured the way it was, for future consultants
• Treat automatic model selection as a helpful default, not a substitute for periodic human review of model fit

Interviewers commonly probe whether a candidate understands the distinction between a forecast model (algorithm) and a forecast profile (configuration), and whether they can explain when to use Croston's method versus exponential smoothing versus a causal/regression model. Be ready to describe a real scenario where you selected or changed a model due to a demand pattern issue, and to explain how history quality affects output quality regardless of which model is chosen.