Sales and Operations Planning
Integrated Business Planningintermediate

Designing the S&OP Planning Model: Key Figures, Levels and Time Profiles

Learn how to design an S&OP planning area's key figures, planning levels, and time profiles to support aggregate reviews and detailed execution consistently.

Explanation

Once the business case for S&OP is understood, the next step in an IBP implementation is designing the planning model that will carry the S&OP process. This is a configuration-heavy task performed in the IBP configuration workspace (via the 'App Configuration' / Manage Planning Areas capability and the Excel add-in's model configuration workbooks), and it directly determines whether the S&OP cycle will be fast, trustworthy and maintainable, or slow and error-prone. Key figures are the measurable facts in the model: Sales History, Statistical Forecast, Consensus Demand, Supply Plan, Target Stock, Production Capacity, Gross Margin, and so on. Each key figure is defined with a data type (quantity, currency, percentage), an aggregation behavior (sum, average, last value), and a planning level - the combination of master data attributes (product, location, customer, period, version) at which it is stored and calculated. A critical design decision is choosing the planning level granularity for each key figure. Executive S&OP key figures (like Consensus Demand Value in currency) are often stored or displayed at product family/region/month, while operational key figures (like Constrained Supply Plan) need product-location/week or even day. IBP supports disaggregation (top-down: aggregate changes flow to detail using a stored disaggregation key figure or proportional splitting based on historical share) and aggregation (bottom-up: detail changes roll up automatically based on the master data hierarchy). Getting this right avoids the classic problem where the executive sees one number and the supply planner works from a different one. Time profiles define the buckets used for planning - weekly, monthly, or a combination via a planning calendar with multiple time levels (day/week/month/year). S&OP models almost always need multiple time levels because different key figures are meaningfully planned at different granularities: sales history in weeks, executive plan in months, but capacity constraints sometimes checked in days. IBP's time profile configuration lets you define a hierarchy (day rolls into week rolls into month rolls into year) so the same key figure can be viewed and edited at different time granularities in the Excel add-in without duplicating data. Master data types and attributes (product, location, customer, and any custom attributes like product family or planning group) must be modeled to support the hierarchy needed for S&OP roll-ups. This master data is typically integrated from S/4HANA or ECC via CPI-DS (SAP Integration Suite/ Data Services) or direct integration templates, and consultants must ensure the hierarchy attributes used for S&OP aggregation (e.g., product family, sales org, region) are consistently maintained at source, because IBP will only aggregate correctly if hierarchy attributes are complete and non-conflicting. Versions play a design role too: an S&OP model typically needs a Baseline version (the currently approved plan) and one or more working/what-if versions used during the monthly cycle for scenario comparison, later either promoted to Baseline or discarded. Some organizations also keep a frozen 'snapshot' version per cycle for historical accuracy tracking (plan-to-actual analysis). Performance is a real constraint: because the Excel add-in queries the HANA-based planning area live, overly granular key figures at high volumes (e.g., daily SKU-location for years of history across a global portfolio) can make S&OP workbooks slow to open or refresh. Consultants need to balance data richness against usability, often by keeping true operational detail in the demand/supply planning models and only bringing summarized, pre-aggregated key figures into the dedicated S&OP views, using stored key figures updated by batch jobs or real-time calculations depending on volume and refresh frequency needs.

Code example

ABAP Code
Example planning level and time profile design (conceptual, not a script): Key Figure: CONSENSUSDEMANDQTY  Planning Level: PRDLOC (Product x Location)  Time Level: WEEK (rolls up to MONTH for executive view)  Aggregation: SUM  Disaggregation: Proportional based on SALESHISTQTY 12-month average Key Figure: EXECDEMANDVALUE (currency, executive review)  Planning Level: PRDFAM x REGION (aggregated master data attributes)  Time Level: MONTH  Source: Calculated = CONSENSUSDEMANDQTY (rolled up) x STANDARDPRICE Version setup:  BASELINE - approved plan, read-mostly outside cycle  WHATIF_CAPACITY - scenario copy for capacity investment analysis  SNAPSHOT_2024_06 - frozen copy taken at month-end for plan-vs-actual tracking

Real project scenario

During a global consumer electronics S&OP implementation, the design team initially modeled every key figure at SKU-location-day to satisfy the most detailed supply planners. Excel workbooks for the executive S&OP review took over a minute to refresh and often timed out for regional VPs on slower connections. The consultant re-designed the model to separate an operational planning level (SKU-location-week) from an executive summary level (product family-region-month), introducing a calculated roll-up key figure for the executive view and a disaggregation key figure for pushing approved executive-level adjustments back down to SKU-location-week. Refresh times dropped significantly and the two views stayed reconciled because both referenced the same underlying stored key figures.

Common mistakes

โ€ข Modeling every key figure at the lowest possible granularity 'just in case,' causing performance and usability problems. โ€ข Failing to define a disaggregation key figure, so top-down executive adjustments cannot be pushed to detail consistently. โ€ข Inconsistent master data hierarchies (e.g., product family populated for some products but not others) breaking aggregation. โ€ข Not planning a version retention/cleanup strategy, leading to dozens of stale what-if versions cluttering the model over time. โ€ข Overlooking time profile alignment, so weekly detail and monthly executive figures do not reconcile at month boundaries (partial weeks spanning two months).

Best practices

โ€ข Separate operational detail key figures from executive summary key figures, linking them through calculated roll-ups rather than duplicate manual entry. โ€ข Define and document a disaggregation key figure or method for every top-down editable key figure. โ€ข Enforce master data hierarchy completeness (product family, region, planning group) through governance before go-live. โ€ข Use a consistent time profile hierarchy (day-week-month-year) so all key figures reconcile across granularities. โ€ข Establish version lifecycle rules (creation, promotion to baseline, archival/deletion) as part of the operating model, not left ad hoc.

Interview angle

Expect questions on how you would design planning levels and key figures to balance executive summary needs against operational planning detail, how aggregation/disaggregation works in IBP, and how you would troubleshoot a scenario where numbers do not tie out between an aggregate and detailed view. Interviewers at intermediate level often probe understanding of time profile hierarchies and version strategy as evidence of hands-on model configuration experience rather than just conceptual knowledge.