SAC in the SAP data landscape

Dan, Contoso Motor Co.'s finance process owner, has used Fiori analytical apps in SAP S/4HANA since go-live. Now the CFO wants one place for margin dashboards, the 2027 sales and margin plan, and board slides. Noor, the data and analytics lead, proposes SAP Analytics Cloud (SAC). Dan's questions are the ones every S/4HANA practitioner asks: what does SAC do that our Fiori apps don't, where does its data come from, and how will we know its numbers are right?

SAC is SAP's cloud service for business intelligence, enterprise planning and augmented analytics in one tool. Users build stories (dashboards and reports), planning models for budgets and forecasts, and use features such as smart insights and search to insight. Since 2025 SAP packages SAC as part of SAP Business Data Cloud, alongside SAP Datasphere, but it is still a service of its own with its own models and data storage (course sap-dap-101).

Where SAC fits

What changes for an S/4HANA practitioner

• Modeling is explicit. In Fiori you consume a query someone built; in SAC you (or your BI team) design models with dimensions, measures and hierarchies.
• Data may be a copy. Imported models hold data in SAC, refreshed by schedule; live models query the source each time.
• Security has two homes. Live models use the source system's authorizations; imported models need SAC's own data access controls.
• Planning writes data. Planning models store plan values in SAC (or in Datasphere with seamless planning), not in SAP S/4HANA.
• Releases are SAP's. SAC is updated by SAP on a regular release cycle; your stories must be regression-tested against it.

Licenses, releases and roles

SAC distinguishes users who only consume and build business intelligence content from users who plan, and planning users need planning rights; under Business Data Cloud, capacity is also expressed in capacity units. Check what Contoso’s contract covers before designing who plans where. SAP updates SAC on its own release cycle, so a story that works today must be regression-tested after each update, the same way Contoso tests its Public Edition-style cloud services. Inside SAC, roles control who can create models, build stories, run data actions or only view. Noor’s team defines three role groups: model builders (her team), story builders (key users such as Maria for O2C and a finance analyst for Dan) and viewers (managers and the CFO). Separating modeling from story building keeps definitions in one place while letting the business build the views it needs.

Contoso’s first SAC scope is deliberately small: one margin dashboard for the CFO (live on an S/4HANA query for actuals), one planning model for the 2027 sales and margin plan of CMC-ALT-100 and related products, and an Excel workbook for controllers built with the add-in. Everything else stays in embedded analytics until there is a reason to move it. A small scope lets Priya build a reusable test approach (lesson 6) on three objects before the BI team scales out, and it gives Dan a concrete comparison: the same September margin in the Fiori app, in the SAC story and in his old spreadsheet, reconciled line by line.