Mein Ansatz

Daten sind kein Projekt. Entscheidungen schon.

Die meisten Unternehmen, die ich sehe, haben keinen Datenmangel – sie haben ein Zugriffsproblem. Analytics gehört dorthin, wo entschieden wird: in den Prozess. Diese Seite beschreibt, wie ich Vorhaben einordne, bevor über Werkzeuge geredet wird.

SEO-Title
Data & Analytics – drei Ebenen, ein Zielbild | Stephan Jacobs
Meta-Desc.
Wie ich Analytics-Vorhaben einordne: Strategie, Plattform, Prozess. Über Zielbilder, Health-Checks und die Frage, wo man sinnvoll anfängt.
Keywords
SAP Analytics · Datenstrategie · Analytics Architektur · SAP Data und Analytics
URL
/themen/data-und-analytics/

Ausgangslage

Was mir immer wieder begegnet

Nutzung

Analytics steht neben der Landschaft

Dashboards existieren, aber niemand nutzt sie im Tagesgeschäft – weil sie außerhalb des Prozesses leben.

Architektur

Das BW läuft aus

Der Wartungshorizont ist gesetzt, die Zielarchitektur nicht. Und jede Woche Warten macht die Entscheidung teurer.

Kalkulation

Migration wirkt unkalkulierbar

Jede Schätzung hängt an Entscheidungen, die noch keiner getroffen hat. Also wird sie verschoben.

Geschwindigkeit

Zahlen kommen zu spät

Bis der Report steht, ist die Entscheidung längst gefallen – meistens aus dem Bauch.

KI

KI bleibt Folie

Use Cases werden diskutiert, aber die Datenbasis trägt sie nicht. Der Pilot scheitert nicht am Modell.

Organisation

Der Fachbereich wartet auf die IT

Für jede neue Sicht ein Ticket. Das skaliert nicht – und endet in Excel.

Einordnung

Drei Ebenen, ein Zielbild

Fast jede Analytics-Frage lässt sich einer dieser drei Ebenen zuordnen. Sie bauen aufeinander auf, aber man muss nicht oben anfangen: Die meisten Vorhaben starten dort, wo der Druck am größten ist. Wichtig ist nur, dass die anderen beiden Ebenen dabei nicht verbaut werden.

Standortbestimmung

Wie ich eine Analytics-Landschaft bewerte

Bevor über Zielarchitekturen gesprochen wird, hilft ein nüchterner Blick auf das, was heute läuft. Sechs Felder, die ich mir dabei ansehe – die Reihenfolge ist Absicht, denn die späteren Fragen ergeben ohne die früheren wenig Sinn.

Feld 1

Landschaft & Architektur

Welche Systeme sind im Einsatz, wie hängen sie zusammen, wo liegen Redundanzen?

Feld 2

Reporting-Bestand

Was existiert, was wird tatsächlich genutzt, was ließe sich ersatzlos abschalten?

Feld 3

Datenqualität & Semantik

Gibt es eine gemeinsame Definition der Kennzahlen – oder drei?

Feld 4

Betrieb & Kosten

Was kostet die heutige Landschaft an Lizenz, Betrieb und Pflege wirklich?

Feld 5

AI-Readiness

Trägt die Datenbasis die Use Cases, über die gerade gesprochen wird?

Feld 6

Organisation & Skills

Wer kann heute selbst auswerten – und wer wartet auf ein Ticket?

Analytics ist für mich nicht die Frage, wie wir noch einen Bericht bauen – sondern wie wir aus Daten bessere Entscheidungen machen.

Deshalb steht am Anfang eines Vorhabens für mich nie die Werkzeugfrage. Sondern die, welche Entscheidung heute schlechter getroffen wird, als sie müsste – und was ihr dafür fehlt.

Vorgehen

Wie ich Vorhaben aufsetze

  1. 01

    Orientierung

    Bestandsaufnahme statt Produktvergleich. Erst wenn klar ist, was heute läuft, lohnt sich die Diskussion über das Ziel.

  2. 02

    Bewertung

    Optionen im Vergleich, mit Prototyp statt Foliensatz. Auch wenn ein Nicht-SAP-Weg der bessere wäre.

  3. 03

    Entscheidung

    Zielbild, Roadmap, Aufwandsrahmen. Ab hier ist klar, was wann Geld kostet.

  4. 04

    Umsetzung

    In Inkrementen, jedes mit einem Ergebnis, das der Fachbereich tatsächlich nutzt.

  5. 05

    Weiterentwicklung

    Enablement statt Abhängigkeit. Der Erfolg zeigt sich daran, wie viel ohne mich weitergeht.

Warum keine AufwandsangabenBelastbare Schätzungen entstehen erst, wenn die Komponenten feststehen. Alles davor ist eine Hausnummer – und Hausnummern sind der Grund, warum Analytics-Budgets regelmäßig reißen.

Haltung

Woran ich Entscheidungen festmache

  • Prozess vor Werkzeug. Kennzahlen entstehen entlang von Prozessen, nicht daneben. Das ist der Unterschied zwischen einem Dashboard und einer Steuerung.
  • Bestand ehrlich bewerten. Ein gewachsenes BW ist kein Fehler, den man korrigiert – aber auch keine Architektur, die man ungeprüft fortschreibt.
  • Weniger migrieren als man denkt. In fast jeder Bestandsaufnahme ist der größte Hebel das, was ersatzlos entfallen kann.
  • Fachbereiche befähigen. Jede Anforderung, für die ein Ticket nötig ist, ist eine Anforderung, die nicht gestellt wird.
  • Über Grenzen hinweg denken. Operatives und strategisches Reporting sind zwei Ebenen desselben Zielbilds – wer nur eine baut, merkt es beim ersten Konzernbericht.

Weiterlesen

Die beiden anderen Ebenen im Detail

Plattform

SAP Business Data Cloud

Architektur, Datenprodukte und die beiden häufigsten Wege dorthin: aus dem BW und aus BusinessObjects. Dazu Planung und die Frage, was die Umbenennung von BTP zur Business AI Platform bedeutet.

Zur Business Data Cloud →

Prozess

S/4HANA Embedded Analytics

Operatives Reporting im Prozess – im laufenden S/4HANA-Projekt und danach, wenn sich zeigt, dass die Berichte aus dem ECC doch nicht gepasst haben.

Zu Embedded Analytics →