Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Business Data Cloud intelligent applications, and what they replace

As of 2026-08-14

The intelligent applications tier of SAP Business Data Cloud sits above the governed data and the semantic model: packaged applications and agents that consume data products rather than being built on raw tables. Two are commercially available and named — Cloud ERP Intelligence for the COO and People Intelligence for the CHRO — and behind them sits a broader library of pre-built analytics applications from SAP and partners, targeting a specific industry, role or process. The proposition is not a better dashboard: the executive deliverable is the product, and the platform is the prerequisite.

What actually ships

Cloud ERP Intelligence stitches three existing data products together — finance, supply chain and manufacturing — and puts Joule on top to turn the joined data into narrative rather than a dashboard the executive interprets unaided. People Intelligence follows the identical pattern for the CHRO, joining headcount, compensation and performance products and surfacing findings such as an attrition concentration in one function and geography.

Alongside them sits the wider packaged library: applications built from data products, analytic models, stories and agent grounding configurations, in five shapes — industry-specific, function-specific, process-specific, pre-configured agent applications, and partner-published verticals.

The structural claim is the same in both cases. A custom project starts from a blank canvas; a packaged application starts substantially complete, and the delivery work is activation, source mapping and tailoring rather than construction.

The activation window and its prerequisite

SAP quotes four to six weeks to activate one of the executive applications on a standard estate. The qualifier does all the work: the window assumes the underlying source data is already replicated into the platform as governed data products.

That replication is the actual project, especially on a brownfield estate with years of custom fields and inconsistent master data that must be reconciled first. Selling the window as though the clock starts at kick-off produces a steering-committee expectation the programme cannot meet and that nobody will remember qualifying.

The rest is genuinely mechanical: provisioning the application's products, models and stories into the tenant, mapping expected source columns onto the customer's actual columns — which is the bulk of the remediation — applying customer-specific dimensions and branding, and validating against reports the business already trusts.

The five tailoring patterns

Almost all tailoring falls into five shapes, and naming them upfront is what keeps a fixed-scope activation fixed.

Source-column mapping, where the application expects standard fields and the customer has renamed or extended them — this is where the hours go. Currency-conversion adjustment, where delivered currencies do not match the reporting currency. Industry-vertical extension, where a delivered application needs a customer-specific dimension. Custom measures, where the customer's signature indicators are not in the delivered set. And agent prompt tuning, so answers use the customer's own terminology and product names.

Anything outside those five is a build, and pricing it as a tailoring line is how a fixed-fee activation becomes a dispute.

Packaged application or custom build

The requirement maps to a standard domain and a delivered measure set. Take the packaged application: it reaches a named executive fast, at low build cost, and SAP maintains the logic as the underlying products evolve.

The pain point is bespoke — a margin analysis across a product line the delivered products do not model, a proprietary allocation, an industry definition SAP has not shipped. Build it; the packaged application will not stretch.

A highly proprietary process, a regulatory requirement the library has not caught up with, or heavy non-SAP ingestion. Custom, sometimes with the packaged application as scaffolding rather than the deliverable.

A first funded proof that the platform delivers. Packaged first, custom second — and never pitch a packaged application on visualisation quality. Its differentiator is the pre-built cross-product join and the narrative layer, so comparing it on charts invites an unfavourable comparison with tools the customer already owns.

Assistance is not autonomy, and drift is the real risk

Alongside the packaged applications sit assistance surfaces embedded where analysts already work: drafted commentary on stories and models, natural-language catalogue search, chart summaries written for an executive brief, auto-drafted product descriptions and glossary entries, and measures proposed from a natural-language prompt. Those are productivity assistance — a human still does the task. The autonomy step is an agent completing a multi-step job against an explicit goal with a measurable definition of done, a permission-scoped tool catalogue and an append-only trace. Presenting the two as one maturity level is the failure that surfaces publicly.

The second risk outlives the project. Data products drift as source systems change, and an application built on stale products degrades into confident, wrong narratives — worse than no application, because a sentence carries more authority than a bar chart and invites less interrogation.

What we cannot assert

SAP's own material uses more than one label for this tier, so we describe what ships rather than asserting a naming hierarchy. We publish no count of available packaged applications either: the library grows between releases, and a number stated on a date reads as true long after it stops being.

Frequently asked

Which intelligent applications are available today?

Cloud ERP Intelligence, joining the finance, supply chain and manufacturing data products for the COO, and People Intelligence, joining headcount, compensation and performance for the CHRO. Both put a Joule narrative over the joined products, and both assume those products are already provisioned in the tenant.

How long does activation take?

SAP quotes four to six weeks for a standard estate, measured from a point where the underlying source data is already replicated into the platform as governed data products. On a brownfield estate, that replication and reconciliation work sits in front of the window and is usually the longer half.

When is a custom build the right answer?

When the business logic diverges from the delivered model — a proprietary allocation, an industry measure SAP has not shipped, a question spanning sources the packaged products do not cover — or when the process itself is highly proprietary. The packaged application is fixed in scope by design.

Are these applications the same as Joule agents?

No. The packaged applications and the embedded assistance surfaces are productivity tooling: a human does the task faster. An agent completes a multi-step job against a measurable definition of done, using a permission-scoped tool catalogue and leaving an append-only audit trace — a different maturity level with a different governance obligation.

What this page is built on

Read next