SAC Stories & Dashboards
Stand 2026-09-03
Stories = entscheidungsgetriebene Verwendungsschicht. Erfahrene Dreiakt-Struktur: Headline-KPI · Treiber · Handlung. ≤ 7 Widgets pro Seite (47 Widgets = 47 AM-Abfragen). Optimized Design nutzen (modern + mobil); Classic nur für Altbestand bis zur Migration. Mobile-first, sonst stirbt das Liefergut binnen 3 Monaten. Jede Story hat einen dokumentierten Zweck: „beantwortet Frage Q für Persona P bei Entscheidung D".
Was Sie lernen
- Die Kernkonzepte von SAC Stories & Dashboards verstehen
- SAC in einem typischen SAP-Analytics-Projekt anwenden
- Die 3-5 häufigsten Fehler erkennen und wissen, wie man sie vermeidet
- Diese Fähigkeit in der eigenen Personal Brand und im TJM-/Honorargespräch positionieren
Modulüberblick
SAP-Analytics-Cloud-Stories = die Verwendungsoberfläche, auf der governte Datasphere-Daten zu Geschäftsentscheidungen werden. Ein erfahrener Berater gestaltet Stories rund um die Entscheidung, die der Nutzer trifft, nicht rund um die Daten, die das Team hat. Anfängerfehler: 47 Diagramme auf einer Seite. Erfahrenes Handwerk: 3-7 Diagramme pro Seite, jedes beantwortet eine Frage, mit klarem narrativem Bogen.
Die Drei-Akt-Struktur, der jede erfahrene Story folgt:
- Headline-KPI (1-2 Widgets) — die Kennzahl, die in dieser Periode zählt.
- Treiber (3-5 Widgets) — was die Headline nach oben oder unten treibt.
- Handlung (1-2 Widgets) — was der Nutzer als Nächstes tun sollte.
Story-Typen und wann welcher einzusetzen ist.
- Optimized Design Experience — modern, mobilfreundlich, empfohlen für Neubauten.
- Classic Design Experience — Altbestand, nur für bestehende Stories bis zum Migrationsfenster.
- Analytic Application — wenn Scripting + individuelle Interaktivität benötigt werden (M023).
Performance-Realität. Die Story-Performance wird dominiert von (a) den Abfragekosten des zugrunde liegenden Analytic Model und (b) der Widget-Anzahl + dem Datenvolumen pro Widget. Eine Story mit 47 Widgets fragt das Analytic Model 47-mal ab. Erfahrenes Muster: ≤ 7 Widgets pro Seite, Hierarchie- und Filterverknüpfung, um die Widget-Kardinalität zu begrenzen, serverseitige Aggregation, die ins DSP-Analytic-Model verlagert wird.
Voraussetzungen
- Zunächst die Kernkonzepte durchgehen: C018, C019, C021
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein Industriekonzern, das Finance-Team wünscht eine Story „monatliche Geschäftsübersicht“. 4-Wochen-Build.
- Das Anti-Pattern erkennen und vermeiden: 47 Widgets auf einer Seite — Performance-Einbruch + kognitive Überlastung.
- Die zentrale Entscheidung des Moduls anwenden: Story-Typ — für Neubauten Optimized Design wählen; Analytic Application, wenn individuelles Scripting nötig ist, nicht Classic Design für neue Builds.
- Die Beherrschung mit dem KPI verfolgen: Widget-Anzahl pro Seite (Ziel: ≤ 7; Warnsignal: > 12 = Neugestaltung).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.