Konzeptkarte

SAP Analytics Cloud (SAC)

Stand 10. Oktober 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP Analytics Cloud (SAC)?

Was es ist und warum es wichtig ist

SAP Analytics Cloud ist die einheitliche Oberfläche von SAP für Business Intelligence, Planung und Predictive Analytics und die Konsumschicht, die auf nahezu jedem Datasphere- oder BDC-Deployment aufsitzt. Business-Nutzer kommen direkt mit SAC in Berührung; hier landen auch, wenig glamourös, die meisten Tickets nach dem Motto „warum ist das Dashboard langsam“, weil sich an der Grenze zwischen SAC und seiner Datenquelle die architektonischen Entscheidungen zu Push-down und Concurrency tatsächlich auswirken. Dieses Grenzverständnis, nicht nur das Bauen von Stories, unterscheidet einen erfahrenen SAC-Architekten von jemandem, der nur Felder auf eine Fläche ziehen kann.

Wie es funktioniert: drei Verbindungsmodi

SAC-Stories lassen sich auf drei unterschiedlichen Verbindungsmodi aufbauen, und diese Wahl ist der mit Abstand größte Performance- und Kostenhebel in jedem Deployment. Die Live-Verbindung fragt bei jedem Rendern Datasphere oder HANA Cloud direkt ab – jedes Diagramm ist eine oder mehrere föderierte SQL-Abfragen, die an die Quell-Engine durchgereicht werden. Das liefert Echtzeit-Aktualität zum Preis der Latenz, typischerweise 100–500 ms im Median, und eine praktische Concurrency-Obergrenze von rund 200 gleichzeitigen Ad-hoc-Nutzern pro Analytic Model, bevor sich die Tail-Latenz zu verschlechtern beginnt. Die Import-Verbindung zieht Daten stattdessen zeitplangesteuert in den eigenen In-Memory-Cache von SAC; Stories fragen dann diesen Cache ab statt die Quelle, was die mediane Latenz unter 100 ms bringt und die Concurrency-Obergrenze auf Tausende Nutzer pro Modell anhebt. Der Preis ist Veralterung – die Daten sind nur so aktuell wie die letzte Aktualisierung, typischerweise alle ein bis vierundzwanzig Stunden – sowie eine begrenzte Cache-Größe, standardmäßig rund 5 GB pro Modell, wenngleich erhöhbar. Hybrid-Verbindungen mischen beides: live für die volatile Datenscheibe, Import für die stabile historische Scheibe, auf Story-Ebene zusammengeführt.

Wann welchen Modus einsetzen – die Kompromisse

Die Entscheidung lautet selten „welcher ist besser“ und fast immer „welchen Kompromiss toleriert diese Zielgruppe“. Ein Finanzcontroller, der eine operative Echtzeitzahl prüft, legt mehr Wert auf Aktualität als auf reine Geschwindigkeit, also ist die Live-Verbindung die richtige Wahl, unter Inkaufnahme der Latenz und der niedrigeren Concurrency-Obergrenze. Ein Executive-Dashboard, das von zweitausend Personen einmal wöchentlich angesehen wird, legt weit mehr Wert auf sofortige Ladezeit als auf sekundengenaue Aktualität – die Import-Verbindung ist die naheliegende Wahl, und das Veralterungsfenster bleibt für dieses Publikum unsichtbar. Sobald ein Deployment etwa zweihundert gleichzeitige Nutzer überschreitet und zugleich ein gewisses Maß an Aktualität benötigt, wird Hybrid für die meisten Enterprise-Rollouts zum Standardmuster: die sich schnell ändernden Zahlen live halten, die historische Basis cachen. Das Anti-Pattern ist, standardmäßig die Live-Verbindung zu wählen, weil sie sich „richtiger anfühlt“ – bei einem Dashboard mit breitem Publikum kann genau diese eine Entscheidung die vollständige Grundursache einer concurrency-bedingten Verlangsamung sein, die später fälschlich als Datasphere-Performance-Problem diagnostiziert wird.

SAC gegen Power BI gegen Tableau ist ein Vergleich, der in fast jeder BI-Frontend-Shortlist wiederkehrt, aber der eigentlich relevante Kompromiss liegt nicht in der Visualisierungsqualität – SAC ist das einzige der drei Tools mit einer nativen, schreibfähigen Planungs-Engine in derselben Tool- und Lizenzfamilie. SAC rein für BI zu wählen, wenn die Organisation keine SAP-zentrierte semantische Schicht zum Konsumieren hat, ist ein schwächeres Argument, als es gezielt zu wählen, weil bereits Datasphere Analytic Models existieren und Planung auf der Roadmap steht.

Das Paarungsmuster SAC-Datasphere

Die kanonische Tier-1-Architektur verwendet Datasphere Analytic Models als governte semantische Schicht und SAC-Stories rein als Darstellungsoberfläche. Jedes Analytic Model trägt die Geschäftslogik, die überall konsistent bleiben muss – Währungsumrechnung, eingeschränkte Kennzahlen, Hierarchiesemantik, durch Data Access Controls geschützte Zeilen –, und SAC-Stories greifen einfach auf das zurück, was das Modell bereitstellt. Die architektonische Regel, die erfahrene Teams ausnahmslos durchsetzen: Eine SAC-Story niemals direkt auf eine rohe Datasphere-SQL-View richten; immer zuerst in ein Analytic Model verpacken. Der Grund ist keine stilistische Vorliebe, sondern Konsistenz. Wenn fünf verschiedene Stories jeweils unabhängig voneinander die Währungsumrechnung oder einen Filter für eingeschränkte Kennzahlen neu implementieren, werden sie irgendwann voneinander abweichen, und niemand wird erklären können, warum zwei „identische“ Zahlen auf zwei Dashboards nicht übereinstimmen.

Fallstricke und Anti-Patterns

Über das Roh-View-Anti-Pattern hinaus sind Story-Wildwuchs und stille Veralterung die beiden wiederkehrenden Fehlerbilder. Story-Wildwuchs entsteht, wenn jeder Analyst eine persönliche Story baut, statt eine governte zu konsumieren, sodass dieselbe Kennzahl im Mandanten auf fünf leicht unterschiedliche Arten berechnet wird – ein Governance-Versagen, das als Self-Service-Enablement getarnt ist. Stille Veralterung entsteht, wenn der Aktualisierungsplan einer Import-Verbindung unbemerkt bricht, ein fehlgeschlagener Job oder eine abgelaufene Zugangsberechtigung, und niemand es bemerkt, bis ein Business-Nutzer meldet, dass „die Zahlen falsch aussehen“; die Behebung besteht darin, den Aktualisierungsjob selbst als überwachte, alarmierende Infrastruktur zu behandeln statt als Fire-and-Forget-Zeitplan. Ein dritter Fallstrick ist die Unterdimensionierung für Concurrency: Teams dimensionieren ein Analytic Model für die zehn Nutzer des Pilotprojekts und überdenken die Verbindungsmodus-Entscheidung nie, wenn der Rollout auf Hunderte skaliert – genau der Punkt, an dem die Obergrenze der Live-Verbindung von rund 200 Nutzern von einer Fußnote zu einem Vorfall wird.

Joules „just ask“-Schicht in SAC, und ihre neue betriebliche Voraussetzung

Joules Fähigkeit zu analytischen Einblicken in SAP Analytics Cloud wird durch eine „just ask“-Funktion angetrieben, die unterstützte SAC-Modelle sowie jedes SAP-Datasphere-Analytic-Model indexiert, das Teil einer BDC-Formation ist — das heißt, die natürlichsprachige Frage, die ein Business-Anwender in Joule eintippt, wird beantwortet, indem dieselbe gesteuerte semantische Schicht gelesen wird, auf der diese Karte empfiehlt, jede SAC-Story aufzubauen, nicht eine separate, KI-spezifische Kopie der Daten (help.sap.com; community.sap.com, 2026). Das ist der konkrete Grund, warum die architektonische Regel im Textkörper dieser Karte — eine rohe Datasphere-View niemals direkt an SAC exponieren, sondern immer zuerst in ein Analytic Model verpacken — nun neben BI-Konsum-Einsätzen auch KI-Konsum-Einsätze trägt: Eine auf einer rohen View aufgebaute Story ist für Joules „just ask“-Indexierung genauso unsichtbar oder inkonsistent wie für eine zweite, von einem Menschen gebaute Story.

Das betriebliche Detail, das gegenüber jedem Kunden zu erwähnen ist, der diese Integration betreibt oder plant: Das Release Joule 2506 führte eine bahnbrechende Voraussetzung ein, die SAP Build Work Zone verlangt, um Nutzer und Rollen von SAC nach Work Zone zu provisionieren und zu synchronisieren, damit die Integration der konversationellen Analytik weiterhin funktioniert (SAP Community, 2026). Das ist genau die Art von Abhängigkeit, vor der die Falle „Early-Adopter-Funktionen als GA verkauft“ dieser Karte (siehe C024) warnt — ein Scoping-Gespräch, das „Joule in SAC“ bepreist hat, ohne zu prüfen, ob der Kunde bereits Work Zone betreibt oder ob dessen Bereitstellung im Umfang liegt, wird die Lücke erst nach dem Go-live statt während der Kalkulation entdecken. Das Vorhandensein von Work Zone oder die Kosten für dessen Ergänzung vor einem Festpreisangebot für ein Joule-in-SAC-Engagement bestätigen.

Auf der prädiktiven Seite, die diese Karte bereits abdeckt (Smart Predict für Citizen-Data-Scientist-Workflows, Databricks für komplexes ML), trägt die breitere Business AI Platform nun auch SAPs tabellarische Foundation-Modelle — SAP-RPT-1.6 und RPT-1.6-large sind Stand September 2026 die aktuelle Generation auf generative AI hub, neben einem verwalteten Tabular-Orchestration-Workflow und einer RPT-Playground-API (bis zu 1.000 Anfragen/Stunde) zum Experimentieren. Sie liegen architektonisch zwischen der Einfachheit von Smart Predict und dem vollen ML-Engineering-Gewicht von Databricks: ein In-Context-Learning-Modell, das zur Inferenzzeit aus einer beschrifteten Tabelle vorhersagt, ohne Trainingsschritt — es lohnt sich, dies als dritte prädiktive Option in einem Scoping-Gespräch zu benennen, statt direkt auf das binäre Smart-Predict-oder-Databricks zurückzugreifen, das diese Karte derzeit rahmt — die richtige Wahl hängt davon ab, ob der prädiktive Bedarf des Kunden näher an „schnell, tabellarisch, ohne ML-Team“ (RPT), „gesteuert, wiederholbar, citizen-freundlich innerhalb von SAC“ (Smart Predict) oder „maßgeschneidert, großskalig, von einem ML-Team verantwortet“ (Databricks) liegt.

Was sich seit Ende September 2026 geändert hat

28. September 2026 — Excel-Add-in 2026.21 (SAP-Primärdokumentation). Währungsumrechnung lässt sich jetzt direkt in der Arbeitsmappe definieren und verwalten: Eine neue Aktion Add Currency Conversion an der Kennzahlen- oder Strukturdimension, verfügbar, wenn das zugrunde liegende SAC-Modell die Währungsumrechnung unterstützt, erzeugt ein berechnetes Element (Quellelement, Zielwährung, Kategorie, Datum), das wie jede andere Kennzahl nutzbar ist. Das stützt die Aussage der Karte: Die Umrechnungslogik gehört ins Modell, denn das Add-in liest sie jetzt von dort.
28. September 2026 — gleiche Version. Eine neue, optionale Einstellung Enable advanced data retrieval (incl. optimized retrieval) nutzt Daten-Clustering, um das Risiko von Serverlimit-Überschreitungen bei großen Arbeitsmappen zu senken. Sie ist standardmäßig nicht aktiviert, damit bestehende Arbeitsmappen unberührt bleiben.

Aktualisierung vom 10. Oktober 2026

8. Okt. 2026 - Upgrade-Pfad für SAC Planning (ERP Today, SAP-Primärquelle nicht gelesen). Nach SAP Connect können SAC-Planning-Kunden auf SAP Enterprise Planning wechseln; Group-Reporting-Kunden können den Financial Consolidation Assistant ergänzen oder umsteigen; BPC- und BFC-Migrationsservices sind ab Q1 2027 geplant, und EPM-Anwendungen sind mit der BDC-Kernkapazität gebündelt. Für einen SAC-Planning-Kunden ist das eine terminierte Option, kein Grund, jetzt die Plattform zu wechseln: das bestehende Planungsmodell stabil halten und die Q1-2027-Liefergegenstände in den Entscheidungskalender aufnehmen.
8. Okt. 2026 - Enablement. Die SAP Community meldet, dass die SAC-Video-Tutorials vollständig für Horizon aktualisiert wurden.
Was sich nicht geändert hat. Die geprüften Quellen enthalten keine Connect-spezifische SAC-Ankündigung; die obigen Hinweise zum Excel-Add-in und zu Datasphere gelten weiter.

Warum es zählt

Live-Verbindungen stoßen bei rund 200 gleichzeitigen Ad-hoc-Nutzern pro Analytic Model an ihre Grenze, bevor sich die Tail-Latenz verschlechtert – jenseits dieser Schwelle werden Import oder Hybrid notwendig.
Der Import-Modus tauscht Aktualität gegen Skalierung ein (Tausende Nutzer, unter 100 ms), lässt die Daten aber zwischen den Aktualisierungen veraltet, typischerweise 1–24 Stunden – falsch für echtzeitfähiges, governtes Reporting.
Wird der Analytic-Model-Wrapper übersprungen, bricht die Konsistenz von Währungsumrechnung, Einschränkungen und berechneten Kennzahlen, auf die SAC-Stories angewiesen sind.

Kernpunkte

Drei Modi: Live (Push-down, < 200 Nutzer, Echtzeit) · Import (Cache, Tausende Nutzer, veraltet) · Hybrid (beides).
Rohe Datasphere-Views immer in ein Analytic Model verpacken, bevor sie an SAC exponiert werden.
Planung ist das SAP-Alleinstellungsmerkmal – Write-back, Versionskontrolle, Audit, Top-down/Bottom-up-Abstimmung.
Predictive: Smart Predict für Citizen-Data-Scientists und einfache Fälle; Databricks für Data Scientists und komplexes ML.
DAC in Datasphere ist die Source of Truth für Zeilensicherheit – wirkt sich auf SAC, Joule, Delta und OData aus.
Concurrency-Obergrenze im Live-Modus: ~200 gleichzeitig; darüber Hybrid.
Joule liest SAC-Story-Metadaten und Datasphere Analytic Models für natürlichsprachige Fragen und Antworten mit Quellenangaben.
SAC wird getrennt von den Datasphere-CU abgerechnet (Modell pro benanntem Nutzer / pro gleichzeitigem Nutzer).

Quellen

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.