Why Demand Planning Exists and How the IBP Planning Model Supports It

Explanation

Demand planning is the process of estimating future customer demand so that supply chain, production, and procurement teams can prepare capacity, inventory, and materials ahead of time. In most organizations, poor demand planning shows up as stockouts, expensive expediting, or bloated safety stock - all of which are visible to finance and to customers. SAP IBP for demand (running on the SAP HANA-based IBP platform) exists to give planners a collaborative, statistically supported way to generate, adjust, and consense a forecast before it is handed to supply planning. Everything in IBP demand planning sits on top of a planning model, which is the technical container defining what can be planned and at what granularity. Three concepts are essential to understand before touching any configuration: 1. Master data types and attributes - these represent business objects such as product, location, customer, or sales organization. They are loaded (via integration or flat file) into the planning area's master data tables, and they carry attributes (for example product hierarchy level, customer region) that later let you slice and aggregate data. 2. Planning levels - a planning level is a specific combination of master data types (for example Product-Location-Customer, or Product-SalesOrg) at which key figures are stored. Choosing planning levels correctly is one of the most consequential design decisions in a demand planning implementation, because it determines storage granularity, aggregation behavior, and how disaggregation will later distribute changes down to child levels. 3. Key figures - these are the actual planning data points, such as Historical Sales Quantity, Statistical Forecast, Consensus Demand Plan, or Final Demand. Key figures are defined with a unit of measure, an aggregation mode (typically SUM for quantities), and are attached to one or more planning levels through the model's key figure assignment. The time profile complements the planning level by defining the granularity of time (day, week, month) and the planning horizon. Many demand planning models use a weekly or monthly time bucket for the mid-term statistical forecast, while short-term operational adjustments might be reviewed weekly. Time profiles also define fiscal calendars, which matters when a company's fiscal year does not align with the calendar year - a frequent point of confusion in early design workshops. Once master data, planning levels, key figures, and time profiles are defined, the planning area is activated, and planners access the data either through Excel-based planning views (via the IBP Add-in) or through IBP web-based analytics apps. A typical demand planning cycle: historical shipments or orders are loaded into a History key figure; a statistical forecast job runs against that history to populate a Statistical Forecast key figure; planners review and override values, producing a Consensus Demand Plan; and finally the plan is released to supply planning as an input to gross requirements. For a beginner, the critical mental model is: demand planning in IBP is not a single screen or transaction, it is a data model (planning area) plus a business process (forecast generation, review, consensus, release) executed through configurable UI layers. Mistakes at the model level - wrong planning level, missing key figure, wrong aggregation - propagate through every downstream lesson on operators, disaggregation, and integration.

Code example

Example planning level definition (conceptual, not a specific transaction): Planning Level: PRODLOCCUST  Master Data Types: Product (PRDID), Location (LOCID), Customer (CUSTID)  Used by Key Figures:    - HISTORYQTY (Historical Sales Quantity, aggregation: SUM)    - STATFCST (Statistical Forecast, aggregation: SUM)    - CONSENSUSDP (Consensus Demand Plan, aggregation: SUM) Time Profile: WEEKMONTH  Base bucket: WEEK  Aggregated bucket: MONTH  Horizon: 24 months forward, 24 months history

Real project scenario

A consumer goods company onboarding IBP demand planning initially modeled everything at Product-Location level only, without Customer, because it seemed simpler. Three months into the rollout, the key account team asked for customer-level forecast visibility to support joint business planning with a major retailer. Because Customer was not part of the original planning level, the team had to add a new planning level, re-derive historical key figures at the new granularity, and re-run statistical forecast jobs - a multi-week rework effort that could have been avoided by including Customer as an optional dimension from the start, even if most planners initially worked only at the aggregated level.

Common mistakes

• Choosing a planning level that is too coarse, then discovering later that a required dimension (customer, channel) cannot be added without significant rework • Mixing time bucket assumptions (fiscal vs calendar) without confirming with finance and supply planning stakeholders first • Treating key figures as arbitrary fields rather than understanding their aggregation mode, which causes incorrect totals when viewed at higher levels • Loading history and forecast key figures at different planning levels, making direct comparison in planning views impossible without additional lookup logic

Best practices

• Involve supply planning and S&OP stakeholders in planning level design before building the model, since they are downstream consumers of the forecast • Include commonly requested dimensions (customer, channel) even if initially aggregated in views, to avoid costly model rework later • Document the time profile and fiscal calendar assumptions explicitly and validate them with finance early in the project • Keep key figure aggregation modes consistent across History, Statistical Forecast, and Consensus Demand Plan to allow direct comparison in planning views

Interview angle

Interviewers commonly ask candidates to explain the difference between a planning level and a planning area, or to describe how they decided on planning granularity for a past project. Strong answers reference the trade-off between storage/performance and planning flexibility, and mention that planning level changes after go-live are costly, so the design phase must gather requirements from all downstream consumers of the forecast (supply planning, S&OP, finance) before finalizing the model.