SAP IBP

IBP plans the supply chain: forecasting demand, planning supply and inventory to meet it, running sales-and-operations planning (S&OP), and monitoring the supply chain via a control tower. It uses powerful in-memory analytics and an Excel-based planning interface for scenario and what-if planning.

• Demand Planning: forecasting.
• Supply & Inventory Planning.
• Sales & Operations Planning (S&OP).
• Supply Chain Control Tower: visibility and alerts.

One capability that shapes adoption more than the algorithms: the Excel add-in. Planners work in a familiar spreadsheet that reads and writes the planning model directly, rather than in a web interface. That is deliberate, because planning teams live in Excel, and it removes the usual argument about the tool getting in the way.

The most useful thing to understand about IBP is what it is not. It is not MRP, and the two answer different questions at different horizons.

MRP in the ERP core plans execution: what to order and make in the coming days and weeks, at material and plant level, netting against real stock and real orders. It is detailed, short horizon, and it produces documents.

IBP plans the business: demand months and quarters ahead, at product family and region level, deciding how much capacity to have and how much inventory to hold. It is aggregate, long horizon, and it produces agreement rather than documents.

The handover between them is the point. IBP's supply plan becomes the demand signal the execution system nets against, so a plan agreed in IBP arrives in the core as planned independent requirements. When somebody says the plan is wrong, the first question is which plan they mean.

The sales and operations planning process is the reason IBP exists at all: getting sales, operations and finance to agree one number each month, and IBP is the place that argument happens with data in front of it. That is why the product carries collaboration and scenario comparison rather than only algorithms.

There is also a middle ground worth naming. Production planning and detailed scheduling handles the short-horizon, constraint-based scheduling that neither MRP nor IBP does well, and a manufacturing business with genuine capacity constraints often needs all three layers rather than two.

IBP is bought in parts and roles usually name one.

Demand forecasts, using statistical models over history, with adjustments from people who know something the history does not.

Response and supply works out whether the demand can be met, either with a constrained heuristic or an optimiser, and what to do when it cannot.

Inventory calculates how much safety stock is genuinely needed at each point in the network, given variability and service targets. This is often where the fastest financial return sits, because most businesses hold safety stock by habit.

Sales and operations ties them together into the monthly process.

Control tower monitors and alerts across the network.

The planning model underneath is shared: time periods, planning levels, key figures and the attributes that aggregate and disaggregate between levels. Understanding that model is what makes any of the modules configurable rather than magic.

IBP integrates with S/4HANA (and other execution systems) exchanging demand, stock and orders, so plans drive execution and actuals feed back into planning. It succeeds much of the older APO planning and is central to modern digital supply chains.

Integration is through a data integration layer that moves master and transactional data between the execution system and IBP on a schedule. What flows in is history, stock, open orders and master data; what flows back is the agreed plan. The frequency of that exchange decides how current planning is, and a plan built on last week's stock is a plan about last week. See SAP SD for where demand originates and SAP QM for a constraint planning frequently ignores.

Learn IBP through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

Every IBP module sits on one configurable model, and understanding it is what turns the product from a set of screens into something you can build.

Planning levels define the granularity at which data exists: product by location by month, or product family by region by quarter. A key figure is stored at one level and viewed at others.

Key figures are the numbers: forecast, sales history, supply, inventory target. Each has rules for how it aggregates upward and, more interestingly, how it disaggregates downward when somebody edits an aggregate number.

Attributes and master data types describe the dimensions and their hierarchies, which is what allows the same data to be viewed by product family, by region or by customer group.

Time profiles define the periods and how they roll up.

The disaggregation rule is the concept that catches people. When a planner raises next quarter's forecast for a family by ten per cent, something has to decide how that lands on the individual products beneath it, and the answer is configuration. Getting that wrong produces a plan that changes in ways nobody intended when it is edited at the level people actually work at.

IBP is unusual among SAP products in that a technically correct implementation can still fail completely, because the output is a decision rather than a document.

Somebody must own the number. A forecast produced by a model and owned by nobody is ignored the first time it is inconvenient. The demand planner role exists to be accountable for it.

The cadence has to be real. Sales and operations planning is a monthly meeting with decisions, and if the meeting does not happen or nobody with authority attends, the system is producing reports.

One number, not several. The value comes from sales, operations and finance planning against the same figure. Where each keeps their own spreadsheet, the tool has added a fourth version rather than replacing three.

Measure forecast accuracy. Without it there is no way to know whether the model or the adjustments are helping, and no basis for improving either.

The implication for a consultant is that a large part of the work is process design and getting people to change how they meet, which is closer to change management than to configuration.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Treating IBP as a better MRP. It plans at a different level for a different horizon, and using it to schedule production produces frustration.
• A forecast nobody owns. Statistical models produce a number and the value comes from somebody accountable adjusting it.
• Planning levels that do not match how the business decides. See RE-FX and SRM for other planning-adjacent modules.

• Disaggregation rules left at defaults. Planners edit at the aggregate level, and what that does to the products underneath is configuration nobody chose deliberately.

Reading a plan is the easy half, and configuring the planning model and the integration so the agreed number reaches execution is the part you do in the course.

The question to ask of any planning implementation is who owns the number. If the answer is the system, or nobody, the tool will produce reports rather than decisions.