Designing and Configuring Planning Area Structure: Key Figures, Levels, and Time Profiles

Explanation

Once the business scope for a planning area is agreed, the configuration work moves into structural design decisions that materially affect performance, usability, and maintainability. This lesson focuses on the practical mechanics an intermediate consultant needs to master: how key figures are defined and typed, how planning levels control granularity, how aggregation and disaggregation behave, and how time profiles interact with all of this. Key figures fall into two broad categories. Stored key figures physically persist data in the planning area's underlying storage and are used for things like actual sales history, statistical forecast output, or a final consensus demand number that planners need to see and potentially override. Calculated key figures are defined by formulas that reference other key figures and are computed on the fly whenever a planning view is opened or a calculation is triggered; a common example is a variance percentage between forecast and actual, or a coverage days calculation. The trade-off is straightforward: stored key figures consume database space and require explicit population (via load or operator), while calculated key figures save storage but add runtime computation cost and depend on the correctness of underlying formulas at every level of aggregation. Planning levels define the granularity at which a key figure is planned and stored. For example, a demand plan might be entered and reviewed at product-location-customer level (a detailed level), while a mid-term capacity check might only need product-location level (an aggregated level). SAP IBP allows different key figures within the same planning area to have different planning levels, which gives flexibility but also introduces complexity: when data moves between levels, the system performs disaggregation (spreading an aggregate number down to detail, often using a proportional profile based on historical shares) and aggregation (summing detail values up). Consultants must understand which disaggregation method is applied, because default proportional spreading may not match business expectations, especially for new products with no history. Time profiles define the calendar buckets available (day, week, month, and often a planning bucket profile which can differ from a storage bucket profile). A key architectural nuance is the distinction between the time profile used for storage and the one used for display or planning in Excel; IBP allows some flexibility here, but the underlying storage grain sets a hard boundary - you cannot plan at daily detail if the planning area itself only stores weekly buckets. This is why time profile planning must anticipate the most granular need across all processes sharing the planning area. When configuring planning levels and key figures, the master data structure attributes matter directly: every planning level must be composed of attributes that exist in the master data type hierarchy (for example, product belongs to a product group, location belongs to a region). Consultants need to verify that master data attribute hierarchies are complete and consistent before finalizing planning levels, because gaps here cause aggregation errors or missing data at higher levels. Finally, structural changes to a planning area in a productive environment - adding a new key figure is generally low-risk, but changing planning levels or time profiles for existing key figures often requires a data reload and careful regression testing of planning operators, Excel templates, and any downstream integrations, since operators and views reference the exact structure defined here.

Code example

Example: conceptual definition of a planning area structure (illustrative, not exact syntax) Planning Area: DEMANDPLAN01Master Data Types: PRDID (Product), LOCID (Location), CUSTID (Customer) Key Figures:1. HISTACTUALSQTY - stored, level: Product-Location-Customer, weekly bucket2. STATFORECASTQTY - stored, level: Product-Location, weekly bucket   (calculated by forecast model, disaggregated to Product-Location-Customer for review)3. CONSENSUSDEMANDQTY - stored, level: Product-Location-Customer, weekly bucket   (planner-editable, aggregates up to Product-Location and Product-Location-Region)4. FORECASTACCURACYPCT - calculated, formula:   FORECASTACCURACYPCT = 1 - (ABS(STATFORECASTQTY - HISTACTUALSQTY) / HISTACTUALSQTY)   level: Product-Location, weekly bucket (calculated at query time, not stored) Time Profile: Weekly storage bucket, Monthly display aggregation available for reporting Design note: CONSENSUSDEMANDQTY is planned at the most detailed level because plannersneed customer-level visibility; STATFORECASTQTY is generated at a higher level to reducenoise in the statistical model, then disaggregated using a historical share profile.

Real project scenario

During a supply chain planning implementation for an industrial equipment manufacturer, the consulting team initially configured the consensus demand key figure at product-location level only, matching the statistical forecast level, to keep the model simple. Midway through user acceptance testing, regional sales planners insisted they needed to override demand at the customer level for key accounts. This required adding a new planning level for that key figure, running a full data reload, and revalidating every Excel planning view and operator that referenced the key figure, adding roughly three weeks to the timeline. The lesson learned and documented for future phases was to gather granularity requirements from every planning persona (not just the demand planning lead) before finalizing planning levels.

Common mistakes

• Setting all key figures to the most detailed planning level by default, causing unnecessary data volume and slow performance • Failing to validate master data attribute hierarchies before defining planning levels, leading to aggregation gaps • Overusing calculated key figures for complex formulas that are expensive to compute across large data volumes • Not documenting the disaggregation method assumptions, causing confusion when new products with no history get zero or skewed disaggregated values • Underestimating the effort and risk of changing planning levels or time profiles once operators and Excel templates are built on top of them

Best practices

• Gather granularity requirements from every planning persona before finalizing planning levels, not just the primary process owner • Use stored key figures for data planners need to override or that feeds downstream integration; use calculated key figures for derived metrics used mainly for analysis • Validate master data attribute hierarchies thoroughly before configuring planning levels • Document disaggregation profile choices and their expected behavior for new or low-history products • Treat any change to planning levels or time profiles as a mini-project requiring reload and regression testing, not a quick config tweak

Interview angle

Interviewers often probe whether a candidate understands the practical trade-off between stored and calculated key figures, and whether they can explain aggregation/disaggregation behavior in a real scenario. A strong answer describes a specific instance where planning level design had to be revisited due to a late-discovered business requirement, and how that was handled without destabilizing the broader model.