SAP Data & Analytics explained

SAP Data & Analytics is the SAP area that turns process data into reporting, planning and forecasting: warehousing in BW and SAP Datasphere, embedded analytics on CDS views inside S/4HANA, and dashboards in SAP Analytics Cloud (SAC). It is also called Analytics or BI, and it sits between the data platform and the business meaning of the figures.

Why does an analytics build spend so long on reconciliation?

Because a report is only accepted once it ties back to the source, and the difference is rarely in the dashboard: a key date, a currency translation, a filter, a delta that was never initialised. Every phase closes some version of that gap, and the phase of the project decides which one.

Discovery and design — KPI workshops where "revenue" turns out to have several definitions, source-to-target mapping, and the warehouse-versus-live call.
Build — extraction, model layers, transformation logic, then the query and the story on top.
Test — the figures are walked against the source one by one, until every difference is explained rather than adjusted away.
Cutover — initial and history loads inside a window, delta initialisation, the first period-end out of the new model.
Run and AMS — a process chain failed overnight and the management meeting is in the morning; load monitoring, tuning, new report requests.

Warehouse, live, or somewhere between

Where a figure gets calculated decides the rest.

Data warehousing (BW, BW/4HANA): InfoObjects, ADSOs and CompositeProviders, transformations and process chains — governed data with history the source system no longer keeps.
SAP Datasphere: The same job in the cloud: spaces, views, replication and data flows, task chains and analytic models, with CDS views onboarded rather than re-modelled.
Embedded analytics: Analytical CDS views and queries reading the transactional tables directly, surfaced as Fiori apps and KPI tiles — reporting with no extraction step.
Front end and planning (SAC): Stories, models and Analytics Designer; Analysis for Office in Excel; planning with versions, data actions and allocations.
Acquisition and semantics: Extractors and delta queues out of ECC, SLT replication, non-SAP sources, the definition behind each KPI, and the analysis authorizations deciding who sees which company code.

Who gets hired to model numbers

From BI or data engineering — SQL and dimensional modelling transfer directly; what is missing is the SAP data model and the process behind it (switching in from another background).
From a functional area — controlling or logistics consultants who already own the meaning of the figures.
From the key-user side — the person maintaining the spreadsheet a department depends on (the key-user route).
From development — ABAP developers who write CDS views and drift into the analytical half.

A model you built and reconciled to the source, a planning model that survived real users, a BW estate you carried onto the current stack: the walk-through of one of those decides the hire, not the tool list (what interviews test).

Which domain you pair analytics with

Analytics alone is a toolset; a domain makes it a specialism. Three pairings carry their own argument. CO is the classic partner because margin is assembled there, so a profitability question ends up in the controlling model whatever tool draws the chart. MDG pairs because a report aggregates across master data: duplicate customers and missing hierarchy nodes surface as wrong totals. And authorizations pairs because a reporting layer inherits the source system's access model and can quietly widen it: a warehouse copy carries no restriction the modeller did not rebuild (which combinations work).

Where the cloud stack moves the work

Three shifts show up in the day job. Extractor and delta-queue building shrinks, because models arrive onboarded from S/4HANA rather than re-derived from tables. The layering call arrives earlier and gets sharper: what is held with history in Datasphere, what is read live through embedded analytics. And the KPI definition moves out of the front-end story into the shared model, versioned and transported like any other object (the wider career effect).