Foundations of Demand Planning in SAP IBP
Understand why demand planning exists in SAP IBP, how the planning model and key figures underpin it, and how a demand plan flows into S&OP and supply.
Explanation
Demand Planning is the process of translating historical sales, market intelligence, and business judgment into a time-phased quantity forecast that other planning processes (S&OP, supply, response, inventory) consume. In SAP IBP, this is not a separate application but a set of capabilities built on top of a shared in-memory planning model hosted in SAP HANA. Before any forecasting logic runs, someone has to design the planning model: the master data types (for example Product, Location, Customer), the planning level (the combination of characteristics at which figures are stored and calculated, such as Product/Location/Week), and the key figures themselves (Historical Sales Quantity, Statistical Forecast, Consensus Demand, Final Demand Plan, and so on). Why this matters: every downstream decision quality depends on the model design done at this stage. If the planning level is too coarse (for example only Product/Region), you lose the granularity needed for accurate location-level replenishment. If it is too fine (Product/Location/Customer/Day), you may create excessive data volume and slow calculations. Consultants must balance business need for granularity against system performance and maintainability, and this is a design decision, not a pure configuration checkbox. Key figures are the working currency of IBP. Each key figure is defined with a unit of measure, aggregation/disaggregation behavior (for example, sum for quantities, weighted average for percentages), and a time profile (day, week, month, or a custom planning time profile that lets business users work in weeks while the system stores data at a different granularity). A demand planner typically works with a handful of key figures: History (actuals), Statistical Forecast (system generated), Marketing/Promotion Adjustment, Consensus Demand (after cross-functional agreement), and Final Demand Plan (after supply constraints, if a supply step exists downstream). The runtime flow for demand planning typically looks like this: historical sales data is loaded (via integration from S/4HANA, BW, or flat file) into a History key figure at the lowest available grain. A forecasting operator (statistical forecast profile) reads this history, applies a forecasting model (moving average, exponential smoothing, or more advanced models), and writes results into the Statistical Forecast key figure. Planners then review this in the Excel-based IBP add-in or Fiori-based planning UI, apply judgmental overrides, and the numbers are aggregated up through the planning hierarchy for management review, then disaggregated back down for execution. It is important to distinguish IBP's model-driven approach from ECC/BW-based demand planning tools like APO-DP, where planning books and macros played a similar role but were tightly coupled to a different technical stack. In IBP, the same core model can support S&OP, demand, inventory, and response/supply use cases simultaneously, provided the model is designed to accommodate all of them, which is both a strength (single source of truth) and a risk (poorly designed models create conflicting requirements across process owners). From a troubleshooting perspective, a beginner should understand that most 'wrong forecast' issues in early implementations trace back to model design problems: missing or incorrect key figure aggregation, incorrect planning level for a given key figure, or a time profile mismatch between where history is loaded and where forecasting runs. Verifying these basics before blaming the forecasting algorithm is a critical first diagnostic step.
Real project scenario
A consumer goods company onboarding SAP IBP defines its planning level as Product/Ship-To Location/Week for demand planning, but later discovers that finance wants revenue forecasts at the customer group level and supply wants replenishment at a daily grain for fast movers. The project team must decide whether to add additional planning levels, use disaggregation profiles, or introduce a secondary planning area, illustrating that demand planning model design is a cross-functional negotiation, not a one-time technical task.
Common mistakes
• Treating the planning level decision as purely a technical/config task instead of a business requirements exercise involving S&OP, supply, and finance stakeholders • Loading history at one grain (e.g., daily) but running the forecast key figure at a different, incompatible time profile without validating aggregation logic • Assuming key figure aggregation defaults (sum) are correct for all figures, including ratios or percentages that need weighted averages • Not distinguishing between IBP's model-driven single-model approach and legacy APO-DP planning books when transferring institutional knowledge from prior projects • Ignoring master data quality (missing product-location combinations) as a root cause of incomplete or zero forecasts
Best practices
• Document planning level requirements from every downstream consuming process (S&OP, supply, inventory) before finalizing the model • Validate key figure aggregation/disaggregation settings explicitly for every non-quantity key figure (ratios, percentages, prices) • Keep the time profile consistent between where history loads and where forecasting operators run, or document and test the conversion logic • Run small-scale proof-of-concept loads early to catch master data gaps before full historical loads • Treat planning model changes post-go-live as a change management exercise requiring impact analysis across all consuming processes
Interview angle
Interviewers commonly ask candidates to explain the relationship between planning level, key figures, and time profile in IBP, and to describe how a wrong model design decision surfaces later as a forecasting or performance problem. Being able to walk through a realistic example of balancing granularity against performance, and explaining why IBP model design decisions are hard to change post-go-live, signals real project experience rather than textbook knowledge.