Go back to Market Research
SAP supplies enterprise resource planning, supply chain planning, warehouse management, and transportation software. Its cloud planning application, SAP Integrated Business Planning (IBP), combines demand forecasting, inventory targets, production and distribution planning, order allocation, and sales and operations planning. It connects to transactional systems such as SAP S/4HANA and provides web applications and an Excel add-in for planners. This review concentrates on IBP and the interfaces that connect its calculations to execution. (1, 2)
Overall supply chain score: 5.2/10
| Dimension | Score |
|---|---|
| Supply chain depth | 5.0/10 |
| Decision and optimization substance | 5.0/10 |
| Product and architecture integrity | 5.2/10 |
| Technical transparency | 6.4/10 |
| Vendor seriousness | 4.6/10 |
SAP provides several substantial numerical engines, organized around different planning problems. Inventory optimization treats demand and lead-time uncertainty when positioning stock against service targets. The supply optimizer chooses production, procurement, and transport quantities using a mixed-integer linear formulation, with financial costs or delivery priorities. The governing limitation is the handoff between these calculations: inventory targets pass to supply planning, while planners maintain the objectives, policies, and exceptions around them. A network-wide stocking calculation does not establish a common stochastic economic objective across the resulting purchasing and production decisions. (3, 4, 6)
The documentation makes several weaknesses unusually tangible. SAP describes performance remedies that remove discrete choices or shorten the modeled future. Its documented time-series shelf-life workflow can omit usable stock from the subsequent optimization. Meanwhile, the latest autonomous-supply-chain announcements still describe planners choosing between scenarios and approving remedies. These are consequential limits on model fidelity and productivity, even when the surrounding ERP integration works. (7, 10, 11, 12)
SAP versus Lokad
Consider a manufacturer deciding whether to buy a component now, expedite a delivery, or accept some risk of a delayed finished-product sale. SAP IBP can calculate stock targets for uncertain demand and lead times, then produce a constrained supply plan using configured costs. Its profit-maximization mode can reject demand whose sales value does not cover production, inventory, transport, and component costs. The financial calculation is explicit; its dependence on a prescribed demand and supply scenario remains central. (4, 6)
Lokad’s documented operating model puts probabilistic demand, lead times, and other relevant uncertainties into the calculation of economically ranked decisions. A Supply Chain Scientist maintains executable decision logic with the customer, while the transactional system records and executes the resulting orders. The intended unit of improvement is the reusable calculation: if supplier lateness changes which purchase is worthwhile, the correction should change future purchasing decisions without requiring another round of manual exception handling. See inventory optimization and the broader design perspective in Introduction to Supply Chain.
SAP supplies a much larger transactional and execution perimeter. A company can retain that perimeter while replacing or supplementing its planning calculations. The substantive comparison concerns how much economic information survives the planning process and how much work is required to improve it. SAP exposes extensive configuration and integration controls, but the numerical engines retain vendor-defined boundaries. Lokad’s custom decision logic also requires maintenance; its proposition depends on making that work more productive than continually adjusting forecasts, safety stocks, penalties, and planning exceptions.
What IBP computes
Uncertainty enters inventory targets
The IBP 2608 inventory documentation explicitly includes forecast error, indirect demand, lead-time variability, replenishment frequency, and lot sizes in a multistage stocking calculation. Inventory holding costs influence placement across the network. This supports a substantive treatment of supply uncertainty, beyond demand-only forecasting. The inventory FAQ describes a stochastic nonlinear solver constrained by customer service levels; the current application guide describes the objective as minimizing stocking costs while maintaining those levels. (3, 4)
The output matters. Inventory targets become inputs to response and supply planning, or pass to external operational systems. A safety-stock target summarizes uncertainty in a prescribed replenishment policy; it does not carry the full distribution of future receipts, demands, and economic consequences into every downstream decision. Two suppliers with the same average lead time can have very different tail risks, and the preferred source can depend on the margin of the finished product, alternative uses of capacity, and the options available after a delay. The reviewed material does not show these interactions entering a single stochastic purchasing-and-production objective.
SAP also separates the stock attributed to supply variability. Its calculation uses forecast or propagated demand means together with production and transport lead-time error standard deviations. This exposes a maintainable input mechanism, but not a calibrated joint distribution of disruptions and their consequences. Getting these parameters into the system, refreshing them, and checking whether their assumptions still hold are part of operating the solution. (5)
Economic costs compete with steering penalties
The supply optimizer supports both profit maximization and delivery maximization. The latter increases non-delivery penalties enough to favor fulfillment irrespective of product profitability. SAP also explicitly permits additional costs that steer sourcing preferences without representing financial expenditure. Thus, the existence of a cost objective does not ensure that the configured objective measures money. (6)
This distinction becomes visible in order-based fair-share planning. SAP adds costs according to fulfillment rates so that shortages or surpluses are distributed more evenly. One documented inventory-priority setup requires equal holding costs across locations. These are mechanisms for encoding a distribution policy. Their economic adequacy depends on whether equal treatment is actually worth its opportunity cost when customer margins, shortage consequences, or disposal risks differ. (8)
The practical risk is that successive exceptions become another layer of artificial prices. A planner raises a penalty until a desired result appears; another planner changes a competing penalty later. The optimizer can then precisely minimize a configuration whose relationship to profit has become obscure. Evaluating such a deployment requires tracing important cost coefficients to business consequences and reviewing the decisions they produce, including losses that a service KPI omits.
Discrete constraints expose the scalability trade-off
SAP described its IBP supply formulation as a mixed-integer linear program in April 2015. Minimum lots and fixed charges required binary variables, and the article recommended limiting discrete decisions to an initial part of the horizon. SAP’s subsequently updated performance guidance also recommends reducing the horizon, aggregating time, separating loosely coupled subnetworks, and using product decomposition. It explicitly identifies shared resources and aggregated constraints as sources of difficulty. (15, 22)
These simplifications remove precisely the interactions that can determine economic value. A batch purchased today consumes cash and may leave obsolete stock months later. A capacity decision at one factory can change what another factory should produce. Shortening or separating the problem can make the calculation tractable while weakening its answer to those choices. Expanding the formulation over many uncertain futures would add another computational burden; mathematical representability alone would not establish a practical solution.
The current local-optimization documentation is particularly concrete. The method first relaxes discrete restrictions, then rounds and fixes subsets of decisions. Used as a starting solution, it is followed by the main optimizer. In standalone mode, a short runtime can leave some discrete requirements unsatisfied, and the documentation lists unsupported features including fixed capacity consumption. Those limitations belong to that mode; they should not be attributed to every IBP optimization run. (7)
SAP’s public cellphone-company benchmark provides actual MILP instances in MPS format. It makes a particular formulation reproducible and useful for comparing solvers. It does not test whether the modeled economic objective survives supplier failures, changing product economics, or missing actions. (32)
A documented shelf-life boundary
The time-series coupled workflow first distributes expiring stock with a shelf-life heuristic, then passes residual requirements to the supply optimizer. The optimizer does not receive remaining limited-life stock or the relevant minimum-shelf-life requirements. SAP explicitly warns that it can consequently plan production for demand that existing stock could have fulfilled. New production and external receipts produced by that optimizer are represented with unlimited shelf life in the combined output. (10)
This is a specific computational separation with an economic consequence: usable inventory and new production can compete for the same demand without being evaluated together. Displaying both results in common key figures does not repair that separation. For perishables, the buyer needs to examine the actual planning mode, the decisions omitted at the boundary, and whether resolving them requires recurring intervention. The finding concerns this documented time-series workflow, rather than all SAP warehouse or order-based shelf-life functionality.
Demand sensing and information timing
SAP’s demand-sensing process performs scheduled daily or weekly batches. It uses orders, deliveries, forecast snapshots, promotions, and optional external signals; the documented workflow includes gradient boosting, weekly adjustment, daily disaggregation, caps, and forecast-consumption rules. Planners can overwrite disaggregation profiles. During product phase-in and phase-out, some capabilities reduce to postprocessing rather than using the weekly learned pattern. (9)
The label adds no separate economic capability. Its useful content is the specified calculation. Validation must compare forecasts using the same information available at the same decision deadline. An order received after procurement was committed can improve a short-horizon forecast without improving the purchase. Likewise, dividing a weekly forecast into daily quantities requires evidence at the daily decision level; weekly accuracy cannot establish that promotional peaks or fresh-product waste have been handled well.
Technology history: durable engineering and repeated new beginnings
| Period | Public technical direction | What the record establishes |
|---|---|---|
| 2010–2015 | HANA and the real-time supply chain | SAP introduced HANA in 2010 and tied the 2013 SmartOps acquisition to real-time planning. Its 2015 optimizer article described a conventional MILP formulation. (13, 14, 15) |
| 2017 | Leonardo and CoPilot | Leonardo grouped machine learning, blockchain, IoT, and conversational applications. CoPilot’s shipped first version offered notes, screenshots, contextual chat, business-object recognition, and quick creation actions. (16, 18) |
| 2020 | Retrenchment in blockchain hosting | SAP announced retirement of its MultiChain and Quorum provisioning for new customers and renewals, moving away from hosting those open-source components. Existing contracts continued under their terms. (17) |
| 2019 documentation onward; January 2023 | Earlier assistants enter maintenance | The CoPilot help page places the product in maintenance and directs digital-assistant functionality to Conversational AI. Conversational AI itself entered maintenance in January 2023. (19, 20) |
| 2026 | Joule and autonomous supply chains | October announcements describe scenario analysis, root-cause suggestions, and logistics remedies, with general availability of new capabilities planned for Q4. November messaging still assigns scenario evaluation and important decisions to planners. (11, 12) |
HANA persisted as a technical foundation; its storage and execution mechanisms are documented. The 2013 real-time claim nevertheless mixed a database performance proposition with a much broader decision proposition. Faster access to planning data does not improve a cost model or represent uncertain futures. The current optimizer service also runs on separate compute infrastructure, so database speed must not be confused with complete optimization latency. (14, 23)
The assistant chronology is more troubling. SAP has repeatedly presented a new route toward intelligent enterprise work, while earlier assistant products entered maintenance. The 2017 release description did identify its initial task limits. What remains missing from that sequence is a sustained, measured account of how much planning work disappeared, which earlier promises were fulfilled, and what customers must rebuild between generations. Today’s language models cannot retroactively validate the earlier enterprise-intelligence narrative.
The blockchain retirement is similarly informative because it identifies the actual engineering perimeter: SAP had provisioned third-party ledger technology and later redirected customers toward other hosting arrangements. The record establishes a changed product commitment. It supplies no evidence that ledger hosting improved inventory or production economics. This history lowers confidence in another broad transformation claim until SAP demonstrates persistent delivery at the decision level.
Software materials and ownership cost
The following components have attributable roles in the reviewed planning architecture.
| Component | Documented role | Ownership consequence |
|---|---|---|
| HANA and SQLScript | Database and calculation environment; SAP’s IBP order-based planning vacancy names HANA SQLScript. (21) | Data processing, model activation, and database execution require specialized engineering. |
| ABAP, JavaScript, OData | The same development-team vacancy identifies these technologies for IBP Supply. (21) | Logic and interfaces span backend, user interface, and service boundaries. |
| SCM Optimization on SAP BTP Kubernetes | IBP preprocesses planning data, sends it to a hyperscaler compute cluster, and receives results. (23) | A planning run includes transfer, solver execution, and reintegration, beyond database or screen latency. |
| Excel add-in and web planning applications | Planners inspect and change key figures, profiles, and plans. (2, 9) | Client compatibility, templates, permissions, and manual edits remain part of the operating environment. |
| Integration services and APIs | Separate interfaces handle time-series planning data and purchasing documents; integration packaging changed in April 2026. (28, 29, 33) | Mapping, reconciliation, interface maintenance, and licensing must be included in TCO. |
HANA’s column-store administration documents an engineering trade-off behind the in-memory proposition. Writes accumulate in delta storage, which compresses less effectively and can retain old record versions; merges consolidate that state. The documentation covers memory pressure, long-running merges, and separate compression behavior after manual merges. These mechanisms require capacity and operational care. Their existence does not measure any particular IBP tenant’s cost, but it does invalidate treating fast in-memory access as a free architectural benefit. (24)
For new IBP licenses obtained after April 20, 2026, SAP’s feature documentation folds former S&OP and Control Tower capabilities into a mandatory foundation license. Existing Cloud Integration for data services connections can continue under earlier licenses; new subscribers are directed toward SAP Integration Suite, with a separate license. A buyer therefore needs the actual subscription generation and integration design to price an implementation. A generic diagram of an integrated SAP suite hides commercially relevant boundaries. (2, 33)
Configuration is an ongoing software responsibility
The model-configuration guide describes attributes, master data, planning levels, key figures, calculations, versions, and snapshots. It provides transport through software collections and distinguishes initial configuration upload from promotion to production. SAP explicitly warns against using the binary-upload route directly on production. This is a development lifecycle with artifacts and dependencies, even when much of the authoring happens in forms. (25)
A changed lead-time definition can affect demand propagation, forecast-error selection, inventory targets, and downstream supply. A new cost can interact with fair-share tiers and existing penalties. Maintaining the configuration consequently requires someone who understands both the business and the calculation graph, plus controlled promotion and regression work. Subscription and hosting charges omit this recurring labor, whether performed by the customer, SAP, or an implementation partner.
The decisive improvement test is a harmful recommendation. Can the team identify the missing interaction, change the problem rather than override the output, replay past decisions, and deploy a durable correction? SAP exposes substantial model configuration, but algorithm internals and the available decision structures remain constrained by its engines. The inventory FAQ explicitly withholds algorithm inspection. Repeatedly adjusting exposed parameters cannot resolve every missing action or interaction. This is the distinction developed in Holimization: optimization must remain revisable as the business reveals what the initial formulation missed. (3, 25)
Automation, security, and economic accountability
Faster planning still leaves planning work
SAP’s SLB case reports planning activities reduced from as much as three weeks to less than one week, and others from two weeks to less than a day. The same account reports over $1 billion in inventory savings over four years and a 37% reduction in inventory days over three years. These are attributed customer outcomes from a process, change-management, and software program. They establish a more substantive result than a product demonstration. (30)
The report also says teams moved from gathering data toward simulation and scenario planning. It does not provide remaining total staffing, partner and vendor effort, or return net of implementation and continuing maintenance. Reducing elapsed planning time and reallocating planners’ work do not establish the labor needed for an unattended decision process. That is the relevant comparison as agents make repetitive analysis and software changes cheaper.
The 2026 announcements retain this tension. The Logistics Issue Resolution Agent is described as reducing a multi-hour problem to a one-click decision; the Supply Chain Planning Assistant helps users identify causes and proposed corrective actions. The November description has an assistant coordinate demand, inventory, and capacity agents to construct scenarios, leaving the planner to evaluate them. These can reduce investigation time, but the documented workflow still concentrates human attention on individual decisions. The announcements do not quantify the total recurring workload or demonstrate economic selection across the full decision portfolio. (11, 12)
SAP also has existing scheduled jobs and data APIs. Agent productivity must be measured against that existing automation. A conversational request that launches an old batch or displays an exception should not receive the engineering credit of a new numerical engine. The more valuable improvement would make recurring corrections reusable and reduce the need for those exceptions in the first place.
Permissions have operational exceptions
SAP’s security guide exposes a concrete access-control matrix. In the documented version, copy and delete operations on whole planning versions do not apply permission filters; the copy operator’s write filtering requires an explicit setting. These operations need corresponding authorization boundaries because a user’s restricted planning view is not a universal restriction on what an authorized job can change. (26)
The order-and-stock permission model also states that multiple filters combine by union: additional assignments expand access. Change history records alterations to those filters. These are inspectable mechanisms with important administrative consequences. Least privilege depends on testing the effective combination of roles, filters, integrations, and jobs, including the effects of compromised accounts or erroneous automation. (27)
Certifications do not answer that question. The useful security evidence is the documented boundary and whether it contains damage after a mistake.
Results need a testable economic perimeter
The SLB case includes an increase toward 90% forecast accuracy in some business lines without defining the error metric, weighting, product/location granularity, or horizon. That percentage cannot substantiate detailed purchasing decisions. Aggregating across products or periods can cancel errors while shortages and excess stock remain at the operational level. The inventory and planning-time outcomes are separate claims; the accuracy percentage does not validate their causal attribution. (30)
STIHL’s account gives a useful deployment boundary: an initial rollout at two production sites, integration with manufacturing planning and scheduling and transportation management, and a stated plan to extend network planning to about 43 subsidiaries. It documents phased implementation and connecting applications, rather than a completed global optimization result. (31)
A testable economic proposition would define the baseline, decisions covered, evaluation period, recurring labor and software cost, and responsibility for correcting poor recommendations. The reviewed public cases do not supply that complete account. They support adoption and reported benefits, while leaving the customer to determine how much of the value can be attributed to IBP and whether it exceeds the continuing cost of the planning estate.
Supply chain score
The overall score is the arithmetic mean of the following 25 editorial assessments.
Supply chain depth: 5.0/10
| Criterion | Score |
|---|---|
| Economic framing | 6/10 |
| Decision end-state | 7/10 |
| Conceptual sharpness on supply chain | 6/10 |
| Freedom from obsolete doctrinal centerpieces | 3/10 |
| Robustness against KPI theater | 3/10 |
Average: 5.0/10.
Economic framing — 6/10. Profit maximization can distinguish commercially worthwhile demand from demand whose fulfillment costs too much. Service targets, delivery maximization, and artificial steering costs compete with that economic objective. The deployed configuration determines which interpretation governs decisions. (6, 8)
Decision end-state — 7/10. IBP computes procurement, production, distribution, and allocation plans, with purchasing-document interfaces and connections to execution systems. It reaches decisions with operational consequences. The inventory component’s targets and the scenario-review workflow leave important selection and execution responsibilities outside individual calculations. (1, 29, 31)
Conceptual sharpness on supply chain — 6/10. Multilevel bills of material, network inventory placement, finite resources, and uncertain replenishment show detailed domain knowledge. The separation between stocking targets and supply plans weakens the treatment of coupled economics across those capabilities. (1, 4, 5)
Freedom from obsolete doctrinal centerpieces — 3/10. Consensus planning, service targets, planner-reviewed scenarios, and policy-based distribution remain organizing principles. These mechanisms preserve a substantial manual planning role and can prioritize compliance with a plan over the economic value of the next decision. (1, 8, 12)
Robustness against KPI theater — 3/10. SAP publishes customer inventory outcomes, but the SLB accuracy claim lacks the metric and operational granularity needed to interpret it. Without that definition, a high percentage adds sales appeal without establishing better SKU-level decisions. (30)
Decision and optimization substance: 5.0/10
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 5/10 |
| Distinctive optimization or ML substance | 6/10 |
| Real-world constraint handling | 5/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 4/10 |
Average: 5.0/10.
Probabilistic modeling depth — 5/10. Inventory optimization explicitly accounts for demand and lead-time variability across multiple echelons. The reviewed process exports stocking targets, leaving joint probabilistic decision selection and calibration of relevant tail dependencies unestablished for the subsequent supply calculation. (4, 5)
Distinctive optimization or ML substance — 6/10. SAP documents numerical formulations, a multistage inventory engine, a specific demand-sensing pipeline, and public solver instances. These artifacts establish engineering substance. They provide less evidence of distinctive economic gains from the complete system than of functioning individual methods. (3, 9, 32)
Real-world constraint handling — 5/10. The supply formulation includes finite capacity, material flows, lot sizes, and fixed charges. Local optimization and the coupled shelf-life workflow expose material limitations: some discrete restrictions can remain unmet in standalone mode, while expiring stock can disappear from the next calculation. These omissions can change executable quantities and costs. (7, 10, 15)
Decision automation and labor productivity — 5/10. Scheduled numerical runs and reported reductions in planning time support useful automation. Current assistant descriptions retain human investigation, scenario evaluation, and remedy selection; total remaining customer, vendor, and partner labor is not measured. (9, 11, 12, 30)
Resilience under real operational complexity — 4/10. Configurable models allow changes to business logic, but SAP’s performance remedies can remove discrete choices, long horizons, and shared interactions. That pressure limits the ability to incorporate newly discovered economic relationships. Model transport alone does not establish replay and controlled improvement against actual operational losses. (22, 25)
Product and architecture integrity: 5.2/10
| Criterion | Score |
|---|---|
| Architectural coherence | 5/10 |
| System-boundary clarity | 7/10 |
| Security seriousness | 5/10 |
| Software parsimony and ownership cost | 3/10 |
| Compatibility with programmatic and agent-assisted operations | 6/10 |
Average: 5.2/10.
Architectural coherence — 5/10. IBP provides shared modeling and integration facilities, while inventory, supply optimization, and execution retain distinct responsibilities. The documented shelf-life handoff demonstrates that shared output tables can conceal a material break in the decision calculation. (4, 10, 25)
System-boundary clarity — 7/10. SAP documents where optimization runs, which data APIs apply to time-series or order-based planning, and which integration services require separate licensing. These boundaries are inspectable. The number of versions, modules, and subscription generations still complicates identifying the exact installed perimeter. (2, 23, 28, 29, 33)
Security seriousness — 5/10. The published permission matrix and filter-change history provide mechanisms that can be examined and tested. Whole-version operations and cumulative permissions require deliberate containment through other authorizations. The reviewed evidence leaves the damage boundary after a privileged account or integration is compromised insufficiently demonstrated. (26, 27)
Software parsimony and ownership cost — 3/10. The documented database, application, optimization-cluster, interface, and client layers create several maintenance responsibilities. Customer-specific calculation graphs, penalties, and transport processes add continuing specialist work. Public benefit claims do not expose a corresponding complete operating-cost account. (21, 23, 24, 25)
Compatibility with programmatic and agent-assisted operations — 6/10. APIs and scheduled jobs support execution without repeatedly navigating screens. Versioned configuration also supplies controlled artifacts. Programmatic access to data and existing jobs does not provide equivalent control over proprietary algorithms or demonstrate agents safely improving the numerical formulation. (25, 28, 29)
Technical transparency: 6.4/10
| Criterion | Score |
|---|---|
| Public technical documentation | 8/10 |
| Inspectability without vendor mediation | 6/10 |
| Portability and lock-in visibility | 5/10 |
| Implementation-method transparency | 7/10 |
| Evidence density behind technical claims | 6/10 |
Average: 6.4/10.
Public technical documentation — 8/10. SAP publishes extensive guides on inputs, algorithms, configuration, integration, permissions, and known computational limits. The explicit shelf-life warning and mode-specific optimization restrictions make the product assessable well beyond its sales presentation. (7, 10, 25, 26)
Inspectability without vendor mediation — 6/10. Public mathematical explanations and downloadable MILP instances enable outside examination. The inventory algorithm remains closed, and an example optimization instance does not expose the complete production decision engine. (3, 15, 32)
Portability and lock-in visibility — 5/10. Data export and import are documented, and software collections move configuration between SAP systems. These facilities expose what can be moved while leaving substantial dependency on SAP’s planning semantics, applications, and numerical operators. (25, 28, 29)
Implementation-method transparency — 7/10. The configuration guide describes model entities, dependencies, activation, and promotion. Performance guidance discusses the effects of business features on tractability. Customers can understand much of the implementation work, although its eventual effort and economic adequacy remain project-specific. (22, 25)
Evidence density behind technical claims — 6/10. Mechanism documentation and deployment descriptions support a large part of the established product. The latest autonomy narrative and reported accuracy percentages have much thinner validation at the level of decision quality, remaining labor, and net returns. (11, 12, 30, 31)
Vendor seriousness: 4.6/10
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 5/10 |
| Technology roadmap integrity | 4/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 3/10 |
| Defensibility in an agentic-software world | 6/10 |
Average: 4.6/10.
Technical seriousness of public communication — 5/10. Engineering documents name methods and limitations. Corporate messaging moves from those specific capabilities to broad autonomous-supply-chain claims without comparable evidence that the complete decision process has become autonomous. (10, 11, 12, 22)
Technology roadmap integrity — 4/10. HANA and numerical planning show sustained development. The blockchain-hosting retreat and successive assistant maintenance announcements show that prominent innovation narratives also produced changing product commitments. The current agent proposition needs measured continuity of delivered value across those generations. (14, 17, 18, 19, 20)
Conceptual sharpness — 5/10. SAP distinguishes costs, constraint types, and several numerical methods with technical precision. Its broader narrative blends visibility, collaboration, forecasting, optimization, and assistance, obscuring which computation actually selects the economically preferable action. (1, 6, 12)
Economic accountability — 3/10. Named cases report inventory and time benefits, but do not define a complete baseline, net TCO, economic failure criterion, or responsibility for remedying poor recommendations. Attribution across process change, integration, customer work, and software remains unresolved. (30, 31)
Defensibility in an agentic-software world — 6/10. Transactional integration, supply-chain data structures, and existing numerical engines supply more durable assets than a conversational interface. Their value depends on reducing the cost of operating and revising decision logic. Assistants that mainly accelerate scenario preparation leave much of the old planning workload intact. (12, 23, 25, 31)
Source dossier
External sources were reviewed on November 4, 2026. Documentation versions are stated where material; customer outcomes are attributed to their publisher.
[1] SAP Integrated Business Planning features
SAP. undated. Functional scope: forecasting, S&OP, supply planning, allocation, and visibility.
[2] Applications and Features of SAP Integrated Business Planning
SAP. 2605 documentation. Foundation licensing and integration changes for subscriptions obtained after April 20, 2026.
SAP. undated. Stochastic nonlinear inventory calculation, service constraints, outputs, and closed algorithm internals.
SAP. 2026 documentation. Multistage stock placement, demand and supply uncertainty, holding costs, and downstream target interfaces.
[5] Supply Variability Safety Stock Equals Zero
SAP. 2605 documentation. Production and transport lead-time variability inputs to the supply-variability safety-stock component.
[6] Time-Series-Based Supply Planning Optimizer
SAP. 2605 documentation. Time-series MILP, financial and delivery objectives, constraint hierarchy, and steering costs.
[7] Local Optimization for Discrete Problems
SAP. 2608 documentation. Start-solution and standalone modes, relaxed discrete requirements, and unsupported features.
[8] Fair Share for Demands and Inventory
SAP. 2026 documentation. Order-based fair-share cost construction and inventory-priority configuration.
SAP. 2605 documentation. Input signals, scheduled processing, weekly adjustments, daily disaggregation, and overrides.
[10] Step 2: Supply Planning Optimizer Run
SAP. 2026 documentation. Time-series shelf-life heuristic/optimizer handoff and the warning about unnecessary production.
[11] SAP Expands Joule Assistants and Agents to Advance Autonomous Supply Chain Management
SAP. 2026-10-08. October assistant announcements, examples, and planned Q4 2026 general availability.
[12] SAP Positioned as a Market Shaper in the Inaugural 2026 Gartner Emerging Market Quadrant
SAP. 2026-11. Planning-assistant workflow in which agents construct scenarios and planners evaluate outcomes.
SAP. 2013-02-22. SAP-authored acquisition announcement linking SmartOps and HANA to real-time supply-chain planning.
[14] SAP HANA: 10 erfolgreiche Jahre
SAP. 2020-03. HANA chronology from the 2010 introduction through Business Warehouse, Business Suite, and S/4HANA.
[15] IBP for Supply Optimizer: the mathematics behind
SAP. 2015-04-17. Original IBP MILP explanation and discretization-horizon recommendation.
[16] SAP Finds its Mona Lisa in Emerging Technologies
SAP. 2017-11-13. SAP-authored 2017 account of Leonardo technologies and positioning.
[17] Sunset of all MultiChain and Quorum services on the SAP Cloud Platform
SAP. 2020-08-19. SAP retirement of MultiChain and Quorum provisioning for new customers and renewals, with existing contracts preserved.
[18] SAP CoPilot 1705 now available to customers
SAP. 2017-05-10. The initial shipped CoPilot functions and proposed route toward a digital assistant.
SAP. 1905 documentation. CoPilot maintenance status and transfer of assistant functionality to Conversational AI.
SAP. 2023-01 lifecycle notice. Conversational AI maintenance status from January 2023.
[21] Developer for SAP Integrated Business Planning
SAP on LinkedIn. undated employer vacancy. SAP employer-authored vacancy for order-based IBP Supply development, naming the technologies used by that team.
[22] Time-Series-Based Supply Optimizer: notes on performance
SAP. 2018-06-08; subsequently updated. SAP optimizer performance guidance; the page has been updated since its June 2018 publication.
[23] Using SCM Optimization in Time-Series-Based Supply Planning
SAP. 2605 documentation. Documented preprocessing, hyperscaler compute cluster on SAP BTP Kubernetes, and return of planning results.
[24] Perform a Manual Delta Merge Operation
SAP. HANA platform documentation. HANA column-store delta storage, manual merging, memory considerations, and compression behavior.
[25] IBP Model Configuration Guide
SAP. 2511. Planning-model entities, calculation dependencies, software collections, and production-promotion guidance.
[26] Permission Filters in SAP IBP Applications
SAP. 2605 documentation. Application-by-application scope and exceptions of permission filters.
[27] Permission Filters for Orders and Stock
SAP. 2026 documentation. Order and stock permissions, cumulative access grants, and filter-change history.
[28] Integrating Data with External Systems
SAP. 2602 documentation. Time-series key-figure import/export through OData and its exclusion of order key figures.
[29] Integrating Purchasing Document Data with External Systems
SAP. 2026 documentation. Purchasing-document import/export for order-based planning.
[30] How SLB Leveraged SAP IBP to Drive Supply Chain Excellence
SAP. 2025-08-05. SAP account of SLB planning-time, inventory, and forecast-accuracy outcomes.
[31] STIHL Optimizes Sales and Production Planning
SAP. 2024-12. SAP account of STIHL initial deployment, application integration, and intended subsidiary expansion.
[32] SAP supply chain MILP benchmark instances
SAP on GitHub. 2023 repository. SAP-published MPS optimization instances for a fictional cellphone manufacturer.
[33] Data Integration Using SAP Cloud Integration for Data Services
SAP. 2026 documentation. Existing CI-DS integration and its unavailability for new IBP licenses after April 20, 2026.