News
FRONTIER NEWS / WHAT IS CHANGING NOW

IBM’s SAP Offensive: Stop Paying to Preserve Complexity

IBM’s October 7 launch packages cloud ERP modernization for growing businesses. Its strategic bargain is fewer bespoke processes in exchange for faster delivery, a cleaner architecture, and savings CIOs must make contractual, but investigate thoroughly for the tradeoffs.

FRONTIER RESEARCH / PORTABLE EDITIONS

Take the argument with you.

Read the publication-ready report. Generated from the canonical News article.

Frontier editorial art for IBM Launches Ready for SAP: Standardize the Business, Then Demand the Savings

What changed

IBM announced IBM Ready for SAP Solutions on October 7, 2026, targeting midsize and fast-growing businesses with cloud ERP modernization and preparation for AI. Availability is initially limited by country and industry. This is a consulting and implementation offering, not a new computing platform.1

The announcement details are well corroborated by independent reporting which will have high visibility in the SAP community and are likely to spur discussion there.2

IBM’s product description supplies the commercial substance: predefined industry scope, Cognitus’ SAP Cloud ERP methodology, fit-to-standard implementation, and IBM Consulting Advantage for AI-assisted delivery. IBM presents these as ways to make project scope, timing, and price more predictable. It also distinguishes AI used to deliver the implementation from SAP Business AI and Joule used in subsequent operations.3

The launch cites Volumetric Building Companies’ three-month transformation and a reported 50% reduction in purchasing, manufacturing, and inventory cycle times. It also cites Second Nature Brands’ integration of Voortman Bakery onto a common SAP platform. These are vendor-published customer examples, not a representative benchmark.1

“But scaling AI requires a connected and modern enterprise foundation,” said Dr. Tom Janoshalmi, global managing partner at IBM Consulting. SAP’s Santina Franchi, identified with Corporate Segment and GROW, emphasized “rich data semantics, end-to-end business processes, industry expertise, and strong governance.”1

Those are promising operating results, but the commercial question remains open. IBM has not published pricing.1 A faster project only earns its keep if the economics hold up over the life of the system.

Frontier’s reading is that IBM is trying to make ERP transformation a more repeatable service. The wager is straightforward: reduce the number of unique decisions in each implementation and both execution risk and delivery effort can fall. Whether customers capture that value depends on how much variation they can retire—and what their contracts say happens to the savings.

Why it matters

Standardization changes who carries the complexity

A packaged implementation changes the starting question from “How do we reproduce our current business?” to “Which departures from the standard are valuable enough to fund?” That is an operating-model decision masquerading as a software selection. A local approval ritual may have a passionate owner and no economic justification. A distinctive manufacturing constraint may be the business. Treating both as configuration requests is how a standardized offer becomes a bespoke program with a more cheerful opening slide.

SAP’s published clean-core guidance describes decoupled extensions on Business Technology Platform and on-stack extensions using ABAP Cloud. Its highest compliance level uses released, stable interfaces; the guidance distinguishes these from riskier modifications.4 For this buying decision, the implication is an explicit boundary: routine processes belong in the standard, genuine differentiation needs a supported extension, and neither should depend on undocumented access to underlying tables. The exact options must be checked against the contracted ERP edition and scope.

The architectural prize is less coupling between the transaction core and the things a company needs to change frequently. That could reduce the number of dependencies an upgrade or acquisition must disturb. It does not eliminate integration work. An acquired factory can share a chart of accounts while still using a different production system, item taxonomy, or supplier identity. Common software is only useful if those differences have accountable owners and tested mappings.

Faster delivery is not automatically cheaper ownership

Frontier is hearing increasing skepticism about cloud ERP from its CIO community, particularly over vendor lock-in and ongoing subscription costs. Faster implementation does not resolve those concerns. Buyers still face the longer-term questions of renewal exposure, dependence on the vendor’s ecosystem, and the practical cost of leaving.

IBM says Consulting Advantage supports design, migration, testing, documentation, and training.3 Frontier’s economic inference is that reusable methods and AI assistance can lower supplier effort, but the distribution of that benefit is negotiable. A provider can turn productivity into a lower fee, more validation, a shorter schedule, or a higher margin. An AI-enabled delivery label promises none of those allocations by itself.

The right denominator is the cost of achieving a stable business outcome. Implementation fees sit alongside internal staff time, data remediation, integration, extensions, subscriptions, training, parallel operations, and support after cutover. Faster delivery creates value when it removes duplicate operating costs or brings benefits forward. It can destroy value when unresolved data and control problems simply arrive in production sooner. A fixed scope is useful precisely because its exclusions can be inspected; treating it as a guarantee of total cost defeats the point.

Independent buyer evidence makes that economic test harder to dismiss. DSAG’s 2026 Investment Report surveyed 198 representatives, one per user company, between December 2025 and January 2026. It reports that cost-effectiveness influenced SAP investment decisions at 79%, while licensing and contract design registered 70%. The sample is weighted toward the German-speaking market, so these are buyer concerns, not global adoption estimates.5 The package enters a market asking for a defensible business case, not another destination slide.

AI readiness needs an acceptance test

IBM’s offering tightly links its clean core and trusted data to future agent-based processes.3 Our architectural inference is narrower: standardization can make automation easier to govern, but an agent still needs a reliable business identity, permission to perform a specific action, current data, and an escalation path. A system that agrees on what an invoice means has solved a different problem from a system authorized to pay it.

This changes the significance of go-live. A useful acceptance test follows an actual transaction across its boundaries: who requested it, which data supported it, who approved it, what the system committed, and how a mistake is reversed. If that chain cannot be reconstructed, an AI-ready label is premature. The scarce asset is operational clarity. More polished demonstrations do not substitute for it.

Frontier take

IBM is selling a bargain: give up avoidable process variation and buy a faster route to a coherent business. That can be a good trade, provided implementation savings are not overwhelmed by recurring costs and reduced freedom to change providers. The danger is that the customer standardizes its operations while the supplier keeps the productivity dividend. Frontier’s judgment is that CIOs should evaluate this offering as a transfer of complexity and delivery risk, with architecture and commercial terms judged together.

The strategic opportunity extends beyond a first implementation. A repeatable foundation could shorten the work needed to absorb the next acquisition or launch the next business unit. But repeatability is an asset only if the customer can actually reuse it: configuration decisions, integration definitions, data mappings, and operating knowledge must survive the departure of the original project team. Otherwise, the enterprise owns the subscription while renting its ability to change.

The timing adds negotiating pressure. SAP’s published maintenance policy retains mainstream support for covered Business Suite 7 core applications through 2027, with optional extended maintenance through 2030 at a two-percentage-point premium on the maintenance basis.6 That is an economic planning boundary for affected customers, not proof that every midsize business needs this package or that every existing SAP landscape fits it.

In a separate October 7 clarification, SAP CTO Philipp Herzig warned that expiring third-party database and Java support arrangements constrain options beyond 2030. SAP also states that conversions from affected third-party database landscapes must happen before those agreements end; later transitions would be greenfield.7 For those estates, delay can change the migration route as well as the support bill. That makes a dependency-specific decision more valuable than a generic deadline campaign.

This launch will deserve strategic credit if it makes successful modernization more reproducible and transfers measurable value to customers. Evidence to watch includes realized costs against the original scope, exception volumes after cutover, and the effort required for a second rollout. A smaller implementation bill is welcome. An organization that can change without commissioning another archaeological expedition is the larger prize.

Three moves for CIOs

  1. — Price the exceptions before choosing the package Commission a short, capped discovery using one representative business unit. Require a priced register separating standard processes, supported extensions, and unresolved gaps, with named business owners for each exception.

    • Decision trigger: Proceed only when every critical process has an accepted implementation path and total exceptions remain within the CFO-approved contingency; otherwise re-scope or compare another delivery model.
    • Why now: The strongest bargaining moment is before scope becomes a contractual assumption. This converts standardization from a sales promise into a decision the business can own.
  2. — Contract for the productivity dividend Obtain comparable proposals for the same accepted scope. Require itemized change rates, customer staffing assumptions, recurring charges, renewal terms, exit provisions, and reusable deliverables; connect payment milestones to reconciled data and working processes.

    • Decision trigger: If AI-assisted delivery does not improve price, schedule, or tested quality against the comparison, negotiate again rather than paying a premium for the supplier’s tooling.
    • Why now: Fixed-scope packaging makes exclusions and value allocation testable before signature. After selection, dependency on the implementation team weakens the customer’s ability to recover those benefits.
  3. — Make one governed transaction the AI-readiness gate Select one consequential workflow, such as a purchase-order change, and require evidence of permissions, data lineage, approval limits, audit history, exception handling, and reversal across ERP and connected systems.

    • Decision trigger: Keep AI in advisory mode if any approval boundary or recovery path fails; expand execution authority only after business and control owners accept the evidence.
    • Why now: The implementation is when identities, mappings, and responsibilities are being established. Fixing them then creates a reusable foundation; discovering the gaps after automation scales makes every downstream workflow a remediation project.

Sources