In short: The expensive decisions in an SAP IBP implementation are made in design: the planning area structure, the time profile, how key figures calculate and disaggregate, and how order data reaches the system. Planning area boundaries determine what can be reconciled without an integration job, so splitting demand from supply creates that job permanently. The time profile is close to permanent once data has been loaded against it, which means periodicity has to be settled before the first load. Size the model in cells before agreeing the design, because the arithmetic over levels, horizon and key figure count takes minutes and it changes the answer.
Three weeks into a design phase, somebody asks whether demand and supply should sit in the same planning area. The room splits. The integration lead wants one, because reconciling key figures across two areas will be somebody's job forever. The demand lead wants two, because the periodicity and the master data she needs are different from the supply team's. A decision gets made in twenty minutes, and it constrains everything that follows for the life of the deployment.
This post is about the design decisions inside an SAP Integrated Business Planning implementation that are expensive to reverse: the planning area structure, the time profile, how key figures are calculated and disaggregated, and how order data reaches the system. Whether to be on IBP at all is a different question and E3 covers it. I should say plainly that I work for a competing vendor, which is why nothing below compares products.
What the applications actually do
IBP is sold as a set of applications over a shared model. The current set covers sales and operations planning, demand, inventory, response and supply, demand-driven replenishment, and a control tower. Check your contracted scope and your release documentation for the exact list, because the packaging has changed across releases.
The practical distinction that matters for design is between time-series planning and order-based planning. Time-series planning works on key figures held at a planning level over periods: a forecast quantity for an item at a location for a week. Order-based planning works on individual supply and demand elements, closer to how an ERP represents them, and it is what response planning uses to pegged requirements against confirmed supply.
Those two representations answer different questions and they do not share a data structure. A design that assumes an uninterrupted flow from the aggregate S&OP number down to a confirmed order commitment is assuming something the architecture does not do for free. Plan the handover between the two explicitly, including which one is authoritative for a given horizon.
The planning area is the decision
The planning area is the configuration object that holds attributes, master data types, the time profile, planning levels, key figures and their calculations, plus versions and scenarios. Everything a planner sees is defined in one.
SAP ships sample planning areas that most projects copy and modify. Copying is sensible. What follows the copy is the decision that matters: one planning area for the whole enterprise, or several.
A single area gives you key figures that flow between processes without an interface, one set of master data, and consistent disaggregation across the whole model. The costs are that every change is a change to a shared object, that regression testing widens as the model grows, and that operations touching the area, such as a version copy, get slower as the model grows.
Several areas give you isolation. The demand team can change their model without a release affecting supply. Each area stays smaller and faster. The cost is that anything crossing the boundary becomes a data transfer with its own schedule, its own failure modes and its own reconciliation, and that master data has to be kept consistent in more than one place.
The rule I would apply is to split on process boundaries where the periodicity or the planning level genuinely differs and there is a natural handover, and to keep together anything where planners need to see two numbers side by side in the same view. A demand model at week and item-customer level, and a supply model at week and item-location level, can live in one area. A tactical S&OP model at month and product-family level, and a deployment model at day and item-location, are candidates for separation.
Size the model before you agree the design
The reason this decision has teeth is volume, and the arithmetic is easy to do on a napkin and rarely done.
Count the base planning level cardinality. Suppose 40,000 item-location combinations, a 104-week horizon, and 30 stored key figures. That is 40,000 times 104 times 30, or 124.8 million key figure values in the base version. Add five scenarios that are not simple overlays and you are at 624 million. Add a second periodicity that is stored rather than derived and it grows again.
Now vary the assumptions and watch what drives the number. Extending the horizon from 104 to 156 weeks adds 50 percent. Moving from weekly to daily buckets over the same horizon multiplies by seven. Adding a customer dimension to a model that was item-location, where the average item sells to 8 customers, multiplies by eight. Each of those is a request that arrives in a workshop as a reasonable-sounding sentence, and each has a multiplicative effect on the model size, which shows up later as planning run duration.
The design discipline is to require any request that multiplies cardinality to name the decision it supports. A daily bucket over 104 weeks supports nothing beyond the deployment horizon, so store daily for 13 weeks and weekly beyond it. A customer dimension is needed where the planner plans by customer and is dead weight where they do not.
Calculated and stored key figures, and the disaggregation basis
A stored key figure holds data at a base planning level and needs a rule for how it disaggregates to lower levels and aggregates to higher ones. A calculated key figure is computed at read time from other key figures.
Calculated key figures keep the model smaller and cost runtime on every view. Stored key figures cost storage and are fast to read. A model built entirely from calculations will have views that take a long time to open; a model built entirely from stored figures will be large and slow to copy.
The subtler issue is the disaggregation basis. When a planner edits a number at an aggregated level, the system spreads the change down according to a basis you configured. If that basis is a key figure that is itself zero for some combinations, the change does not reach them, and the planner sees a total that does not match the sum of its parts. This produces the single most common trust failure in a new deployment: a planner types a number, the total changes, and the detail does not add up to it.
Decide the disaggregation basis per editable key figure, write down what happens when the basis is zero, and test that case deliberately. It is a two-line design decision that prevents a category of support ticket that is very hard to explain after go-live.
The time profile is close to permanent
The time profile defines the periodicity levels the model works in. It is created early, data is loaded against it, and changing it afterwards is disruptive in a way that most other configuration is not.
Get three things right at that point. The periodicity levels you will actually plan in, including any level needed only for reporting. The horizon, forward and backward, remembering that historical periods are needed for statistical forecasting and that the amount of history you keep affects model size. And the week definition, because a fiscal week that starts on a different day from the ISO week will produce reconciliation differences with every other system in the business. Y9 covers what happens when several markets define a week differently, and the same problem appears inside a single deployment when finance and supply chain disagree.
Integration to the ERP
Batch integration of master data and time-series data typically runs through SAP's cloud data integration tooling, with the specific product depending on your release and licensing. Order-based planning needs order-level data from the ERP, which is a different integration with a different cadence.
Three design points are worth settling early.
What is authoritative for each object. Master data almost always originates in ERP. Planning parameters such as safety stock and reorder points may be computed in IBP and written back, and if they are, the write-back needs a specified cadence, an override policy and a reversal path. AA4 covers where that boundary belongs in general and AA6 covers the integration patterns.
How a correction to history is handled. When the ERP restates three months of shipments, the planning history has to be corrected, and a delta feed keyed on a change timestamp may not detect a back-dated correction. Test this case during the build rather than discovering it in month four.
What the batch window looks like. Data loads, then the statistical forecast run, then any heuristic or optimiser run, then the disaggregation, then whatever reporting extract feeds elsewhere. Add those durations at production volume, and compare the total against the window between the ERP close and the planner's start of day. Projects routinely discover in system integration testing that the chain takes eleven hours and the window is seven.
The planner surface decides adoption
The primary planning view for most IBP users is the Excel add-in, with Fiori applications covering configuration, analytics and specific processes. That has a consequence for how you run the project: template design is part of the implementation rather than a training afterthought.
A planner's template determines which key figures they see, at what level, with what filters, and how much of it recalculates when they change something. A badly designed one produces long refresh times and an unusable amount of scrolling, and the planner will export to a private workbook and work there, which reintroduces the problem the project was meant to solve. Build the templates with the planners who will use them, measure how long a typical view takes to open at production volume, and set a threshold you will not exceed.
Where this stops
Everything above is about design decisions inside the tool. None of it addresses whether the underlying data supports the plan you are configuring. A well-designed planning area fed with lead times nobody has audited and a censored sales history will produce a defensible-looking wrong answer faster than the spreadsheet it replaced. P6 covers master data governance and D1 covers censored history, and both of those workstreams should start before the configuration does.
The second limit is that the sizing arithmetic above gives you an order of magnitude and no more. Actual run times depend on your model, your calculations, your release and your provisioning, and the only reliable way to know is to load representative volume and measure. Do that in the build phase rather than in performance testing, because a design change is cheap in month two and expensive in month seven.
The third is that release detail moves. Applications get renamed, integration tooling changes, and capabilities appear. Verify any specific claim against your own release notes rather than against a post.
Start by counting the base planning level cardinality your current design implies, multiplying it by the horizon and the stored key figure count, and putting that single number in front of the design team. Most of the arguments about planning area structure resolve themselves once everybody is looking at the same order of magnitude.