Configuring Statistical Forecast Models and Forecast Profiles
Learn how to configure forecast models, algorithms, and forecast profiles in SAP IBP Demand Planning to generate statistical baseline forecasts that planners can review and adjust.
Explanation
Statistical forecasting is the engine behind the unconstrained demand plan in SAP IBP. Before a demand planner ever touches an Excel worksheet, the system needs a forecast model configured against the planning area, and a forecast profile that tells the system which algorithm, history horizon, and parameters to use when generating a baseline statistical forecast. A forecast model in IBP is not a single algorithm choice; it is a configuration object that references key figures (typically historical sales quantity or corrected demand history as input, and statistical forecast as output), the planning level (product/location/customer or an aggregated level such as product/planning area), and the algorithm group to test. IBP typically supports algorithms such as exponential smoothing variants (single, double, triple/Holt-Winters), moving average, linear regression/trend, croston's method for intermittent demand, and best-fit logic which tests multiple algorithms and selects the one with the lowest forecast error (commonly MAPE or MAD) over a backtesting window. The forecast profile groups these settings: the history horizon (how many periods of historical demand feed the model), the forecast horizon (how many future periods to generate), the periodicity (weekly, monthly), and outlier correction settings. Outlier correction matters because a single promotional spike or a stockout-driven demand drop can badly distort an exponential smoothing model; IBP allows configuring statistical outlier correction using standard deviation thresholds before the algorithm runs, and consultants should always review corrected history against raw history to confirm corrections make business sense rather than accepting defaults blindly. A critical configuration decision is at which level forecasting should run: too granular (e.g., product/location/customer for every ship-to) suffers from noisy, intermittent data and higher compute cost; too aggregate (only at product family level) loses the ability to disaggregate accurately down to execution level. Many implementations forecast at an intermediate level (e.g., product/DC) and then use proportional or historical-share-based disaggregation profiles to allocate down to product/location/customer for supply planning consumption. Once the forecast model and profile exist, they are consumed by a demand planning operator (job) — typically executed as part of a planning job template — which reads historical actuals, applies outlier correction, runs the algorithm(s), calculates forecast error metrics, and writes results to the statistical forecast key figure. This job can be scheduled (e.g., weekly before the planner's review cycle) or run ad hoc during simulation. After the statistical forecast is generated, planners review it in the IBP Excel add-in or web UI, often comparing statistical forecast against a manually adjusted planner forecast key figure, and eventually consensus demand key figure that feeds S&OP. It's important to distinguish these key figures clearly in the model: statistical forecast should remain untouched as an audit trail, while planner overrides go into a separate editable key figure, preserving forecast accuracy tracking (MAPE/bias) over time by comparing original statistical output to actuals. In S/4HANA integration scenarios, historical sales data is typically loaded via CPI-DS (SAP Cloud Integration for data services) or the IBP integration add-on from S/4 sales orders/billing documents into the time series planning area; this is a separate topic from the algorithm configuration but directly affects forecast quality since garbage history in produces garbage forecasts out. Public cloud vs private cloud/on-premise differences mainly show up in how frequently integration jobs run and how much custom ABAP-based extraction logic is feasible — public cloud S/4 relies more on standard extractors, while private cloud/on-premise can support more customized history corrections upstream.
Real project scenario
A consumer goods company implementing IBP Demand Planning found their initial statistical forecast wildly overshooting demand every quarter-end. Root cause: quarter-end sell-in spikes from trade promotions were being read as normal seasonal demand pattern by the triple exponential smoothing model. The team reconfigured the forecast profile to apply outlier correction with a tighter standard deviation threshold and separated promotional uplift into a separate additive key figure fed by the trade promotion module, letting the base statistical forecast run cleaner and improving forecast accuracy (measured by MAPE) by double digits over two planning cycles.
Common mistakes
• Running statistical forecasting at overly granular levels causing noisy, intermittent-demand results that best-fit algorithms cannot model well • Not enabling or reviewing outlier correction, so one-time spikes or stockouts permanently distort the trend and seasonality components • Overwriting the statistical forecast key figure directly instead of using a separate planner-adjusted key figure, destroying the audit trail needed for accuracy tracking • Choosing forecast horizon and history horizon inconsistently with business cycle length, e.g., only 6 months of history for a product with strong annual seasonality • Ignoring disaggregation logic when forecasting at an aggregate level, leading to unrealistic allocations at product/location/customer level • Failing to validate history data quality/completeness after S/4 integration loads before trusting the generated statistical forecast
Best practices
• Keep statistical forecast, planner-adjusted forecast, and consensus demand as separate key figures to preserve auditability and enable accuracy tracking • Use best-fit algorithm selection with a defined backtesting window rather than manually forcing one algorithm across all product segments • Apply outlier correction and review corrected vs raw history before trusting generated forecasts, especially for promoted or newly launched products • Forecast at the most stable level that still supports required granularity, using disaggregation profiles based on historical share for finer execution-level detail • Document forecast profile parameter choices (history horizon, forecast horizon, periodicity) per product segment since one-size-fits-all rarely works across a full portfolio • Periodically re-evaluate algorithm performance as demand patterns evolve rather than treating forecast profile configuration as a one-time setup
Interview angle
Interviewers commonly probe whether a candidate understands that statistical forecasting quality depends as much on data preparation (history correction, level of forecasting) as on algorithm choice. Be ready to explain best-fit algorithm selection logic, how outlier correction affects exponential smoothing, why aggregate-then-disaggregate is often preferred, and how you would design key figures to preserve statistical forecast as an audit baseline versus planner overrides for forecast accuracy reporting.