Warum technisch herausragende Datenteams trotzdem scheitern

• Der Wert von Datenteams entsteht nicht durch die Menge an Pipelines, Schemata oder Dashboards, sondern durch veränderte Entscheidungen in der Organisation; zwischen Daten und Handeln braucht es eine interpretierende Ebene: die Perspektive (Perspective)
• Data-Perspective-Action ist ein Betriebsmodell, das verlässliche Daten aufbaut, sie im geschäftlichen Kontext interpretiert und daraus kontinuierlich konkrete Handlungen vorschlägt
• In der 2026 AI & Data Leadership Executive Benchmark Survey nannten 93 % der Daten- und KI-Führungskräfte Kultur und Change Management als zentrale Hürde für die Einführung; nur 7 % verwiesen auf Technologie
• Mit wöchentlichen One-Pagern, einem System zentraler Kennzahlen, Co-Design mit Stakeholdern und der Regel, jeder Analyse Handlungsempfehlungen beizufügen, lässt sich Perspektive zur Gewohnheit machen und mit realen Entscheidungen verknüpfen
• Je stärker KI Pipelines, erste Analysen und Dashboards erzeugt, desto mehr werden Domänenwissen und Vertrauen zum Unterscheidungsmerkmal; Datenteams müssen daher über korrekte Ergebnisse hinaus eine gemeinsame Realität schaffen

---

Warum Data-Perspective-Action nötig ist

• Der Wert einer Organisation entsteht nicht aus Datenartefakten, sondern aus Entscheidungen; zwischen Roh-Output und tatsächlichem Handeln braucht es die interpretierende Ebene der Perspektive
• Auch technisch kompetente Teams mit korrekten Daten können für die Entscheidungsfindung der Organisation irrelevant werden, wenn sie nur Output optimieren, etwa das Bearbeiten von Anfragen, das Schließen von Tickets oder das Ausliefern von Dashboards
• Selbst gut konzipierte Datensysteme können in der Priorität abrutschen, Budget verlieren oder durch Umstrukturierungen verschwinden, wenn die Verbindung zu Arbeit und Entscheidungen nicht zur Gewohnheit gemacht wird
• Data-Perspective-Action ist ein Framework, das den Weg von Daten über eine meinungsstarke Interpretation hin zu konkreten Entscheidungen bewusst und wiederholt durchläuft

Ausgangspunkt des Frameworks

• Das monatliche Reporting einer Werbeagentur dauerte vier Wochen und war bei der Übergabe bereits veraltet; nachdem der Workflow auf etwa einen Tag automatisiert wurde, konnte die verbleibende Zeit für ein Prognosemodell genutzt werden
• Das Modell war nicht komplex, zeigte aber die erwarteten Ergebnisse bei Budgetverschiebungen zwischen Kanälen, sodass Kunden erwartete Renditen vorab sehen und Kanalwechsel sowie Experimente durchführen konnten
• Aus dieser Erfahrung entstand die Abfolge von Daten, Interpretation und konkreter Entscheidung; später wurde dasselbe Modell in mehreren Organisationen angewandt

Schritt 1: Vertrauenswürdige Data

• Die Data-Ebene umfasst Infrastruktur, Zuverlässigkeit, Konsistenz, Informationsflüsse, Pipelines, Schemata, Modelle und Dashboards; ein Großteil der täglichen Arbeit von Data Engineers und Analytics Engineers fällt in diesen Bereich
• Aus nicht vertrauenswürdigen Daten lässt sich keine Perspektive entwickeln; bleibt die Arbeit jedoch bei Anfrage annehmen → bearbeiten → Ticket schließen stehen, wird die Last, korrekte Daten zu interpretieren, auf unvorbereitete Stakeholder verlagert
• Ein Team baute 200 Dashboards mit ausgefeilten Pipelines und Schemata sowie geprüfter Aktualisierungslogik, doch vor tatsächlichen Entscheidungen wurden nur 10 davon geöffnet
  • Die übrigen 190 entstanden, ohne dass Datenteam und Stakeholder gemeinsam festgelegt hatten, für welche Entscheidung sie gedacht waren
  • Die unnötigen Dashboards wurden stillgelegt, doch die eigentliche Ursache war das Fehlen einer gemeinsamen Definition des Arbeitszwecks
• Wer auf der Data-Ebene bleibt, hält zwar Backlog und Arbeitslast aufrecht, vergrößert aber den Abstand zu realen Entscheidungen, wodurch die Priorität des Teams leicht sinkt

Schritt 2: Perspective

• Perspective ist die Ebene, die ein Team, das Informationen liefert, in ein Team verwandelt, das die Organisation beeinflusst; entscheidend ist Domänenwissen, um zu beurteilen, ob die verfolgten Metriken zu einer konkreten Entscheidung passen
• In der 2026 AI & Data Leadership Executive Benchmark Survey wählten 93 % der leitenden Daten- und KI-Führungskräfte Kultur und Change Management als wichtigste Einführungshürde; Technologie nannten nur 7 %
  • Abstand zwischen Kultur/Change Management und Technologie: {b:93,7}
  • Es war die größte Lücke in 15 jährlichen Erhebungen; über den gesamten Untersuchungszeitraum hinweg traten Kultur und Change Management wiederholt stärker als Hürde hervor als Technologie
  • Selbst wenn Organisationen in Infrastruktur und Talente investieren, bleiben die Ergebnisse begrenzt, wenn Fähigkeiten zur Interpretation und Umsetzung von Veränderungen fehlen
• Da KI per Prompt Pipelines, erste Analysen und Dashboards erstellen kann, verschiebt sich der Engpass vom Bauen hin zu Vertrauen
  • Je größer die Output-Menge wird, desto wichtiger werden Guardrails wie Datenqualität, Governance und eine klare Definition von Wahrheit
  • Netflix’ Mick Dreeling geht davon aus, dass die Verantwortung dafür, korrekte Antworten sicherzustellen und die Messlatte kontinuierlich anzuheben, in einer Umgebung, in der Stakeholder Agenten direkt befragen, wahrscheinlich beim Data-Engineering-Team liegt
  • Meta’s Shridhar Iyer bewertet Domänenexpertise als geistiges Eigentum, das nicht verschwindet, auch wenn Agenten allgemeines Wissen aufnehmen
• Fachleute, die Perspective systematisch entwickeln, gewinnen mit fortschreitenden KI-Tools an Wert; Arbeit, die nur auf der Data-Ebene bleibt, lässt sich dagegen leichter automatisieren

• Die Falle der Objektivität

  • Datenprofis können das Liefern von Interpretationen als Eingriff in fremde Zuständigkeiten empfinden und in Passivität verfallen, indem sie Analysen keinen Kontext hinzufügen
  • Stakeholder müssen dann unter Zeitdruck und konkurrierenden Prioritäten halb verstandene Dashboards selbst interpretieren oder sich auf ihr Bauchgefühl verlassen
  • Daten sprechen nicht für sich; wenn Datenteams sie nicht sorgfältig anhand von Kontext und Expertise interpretieren, tut es jemand anderes

• Das Problem, nach der Übergabe nicht weiterzuschauen

  • Auch wenn Pipelines laufen, Dashboards geöffnet werden und Tests bestehen, können Stakeholder CSVs herunterladen, in Excel Spalten und Formeln hinzufügen und Analysen bei Bedarf neu erstellen
  • Ein solches System funktioniert technisch, wird in der Praxis aber umgangen
  • Fragt man fünf Stakeholder nach den Entscheidungen, die sie aktuell treffen, und den unsicheren Punkten, lassen sich Probleme finden, die innerhalb von ein bis zwei Tagen lösbar sind
  • Das Vertrauen, das durch proaktives Lösen kleiner Probleme entsteht, schafft die Grundlage dafür, dass das Datenteam nicht erst nach der Entscheidung, sondern schon in Meetings vor der Entscheidung dabei ist

• Perspektive mit wöchentlichen One-Pagern trainieren

  • Jede Woche wird eine Seite in drei Teilen erstellt
    • In einem Absatz zusammenfassen, welche Fakten die Daten zeigen
    • In einem Absatz mit eigener Einschätzung interpretieren, was das für das aktuelle Geschäft bedeutet
    • In 1–2 konkreten Bulletpoints vorschlagen, was als Nächstes zu tun ist
  • Teilt man dies drei Monate lang in einem Zyklus mit einer Führungskraft, einem Kollegen oder einer Business-Ansprechperson und holt jeweils ein Feedback ein, verändert sich die Intuition dafür, welche Daten Entscheider wichtig finden
  • Mit dem Handlungsvorschlag beginnt die wichtigste Arbeit; auch wenn es unangenehm ist, muss man üben, eine eigene Meinung zu bilden

• Makro- und Mikrokennzahlen

  • Makrokennzahlen sind wenige zentrale Zahlen, die beantworten, ob das Unternehmen gesund ist; Mikrokennzahlen sind Eingangsgrößen, die Bewegungen der Makrokennzahlen erklären
  • Apple’s Monisha Kanoth sieht eine robuste, im gesamten Business abgestimmte North-Star-Metrik als Grundlage für Vertrauen
  • Für eine Marketingleiterin, die Daten aus Dutzenden Quellen erhielt, wurde das Reporting-System auf drei Makrokennzahlen und fünf Mikrosignale umgebaut
  • Innerhalb eines Quartals kam sie aus dem Zustand heraus, nicht zu wissen, welchen Zahlen sie vertrauen sollte, und konnte in Board-Gesprächen präzise benennen, was Wachstum antreibt und was nicht
  • Als die wichtigen Kennzahlen festgelegt und ihre Integrität priorisiert wurden, verbesserten sich auch die Fragen und die Qualität der Antworten des Datenteams

• Mit Stakeholdern gemeinsam designen

  • Version 0.8 veröffentlichen bedeutet, Ergebnisse vor der Fertigstellung zu zeigen und Stakeholder in die letzten 20 % des Aufbaus einzubeziehen
  • Gemeinsame Erstellung erzeugt Ownership am Ergebnis; Ownership verwandelt Artefakte in tatsächliche Handlungszusagen
  • Ein Stakeholder schrieb 100 wirklich wichtige Fragen auf, und die meisten Fragen der folgenden Jahre lagen innerhalb dieser Liste
  • Diese Liste diente als Build-Roadmap und als Werkzeug zur Kontrolle des Scopes
  • Bei neuen Anfragen ging es nicht darum, ob sie abgelehnt werden, sondern darum, ob sie wichtiger sind als die bereits gemeinsam vereinbarten Punkte

• Narrative statt Links als Ergebnis liefern

  • Wer nur SQL-Abfragen, Spreadsheets oder Dashboard-Links teilt, verlagert die schwierigste Interpretationsarbeit auf die Nutzer
  • Schon ein kurzes Narrativ zwingt dazu, auszuwählen, was wichtig ist, Verantwortung für eine bestimmte Interpretation zu übernehmen und ein Ergebnis zu schaffen, das Feedback, Widerspruch und Korrekturen ermöglicht
  • Generative KI kann zum Glätten von Formulierungen genutzt werden, sollte aber nicht das Denken selbst übernehmen
  • Schreiben ist ein Denkprozess, und KI kann keine eigene Perspektive stellvertretend entwickeln
  • Wer das von KI erstellte Narrativ weitergibt, ohne sich direkt am Denken zu beteiligen, überspringt die Perspective-Ebene, die sich über Zeit aufbaut

Schritt 3: Action

• Die Lücke zwischen einer Empfehlung und einer tatsächlichen Organisationsentscheidung ist groß; Datenteams unterschätzen oft die nötige Arbeit für diesen Übergang und ihre eigene Verantwortung dafür
• Die Lücke zwischen Analyse und Entscheidungsmeeting muss durch klare Empfehlungen, Quantifizierung der Opportunity und kontinuierliche Unterstützung geschlossen werden
• Beteiligt sich das Datenteam nicht an diesem Bereich, füllen Interpretationen, Interessen und Zeitpläne der Stakeholder die Lücke, und das Team gibt die Führung im wichtigsten Teil der Arbeit ab

• Die Regel: nicht nur Daten präsentieren

  • Jede Analyse muss eine empfohlene Handlung enthalten; Daten dürfen nicht allein präsentiert werden
  • Die Vorgabe, am Ende etwas empfehlen zu müssen, verändert den Arbeitsumfang von Anfang an
    • Man untersucht entlang einer konkreten Frage
    • Man instrumentiert Kennzahlen, die mit der Entscheidung zusammenhängen
    • Man berücksichtigt, welche Informationen Führungskräfte brauchen, um zu handeln
  • In einem Fall, in dem ein Modell eine Wachstumschance quantifizierte, aber keine Handlung des Leaderships auslöste, fehlten nicht Genauigkeit der Analyse, sondern Empfehlung und gemeinsamer Kontext
  • Wer von Data direkt zu Action springt, lässt Beziehungsaufbau, gemeinsame Erstellung und Vertrauensbildung aus; Empfehlungen können dann unausgeführt bleiben

• Opportunity-Größe und kontinuierliche Unterstützung

  • Wenn aus einer Analyse eine Hypothese entsteht, muss das Datenteam selbst quantifizieren, wie wertvoll die Opportunity ist und warum sie priorisiert werden sollte
  • Auch wenn Schätzungen falsch sein können, geben konkrete Zahlen Entscheidern etwas, dem sie widersprechen können; diskutierbare Schätzungen führen eher zu Entscheidungen als vage Richtungen
  • Eine einmalige Präsentation bedeutet nicht, dass etwas in die Roadmap aufgenommen wird; bis zur Action-Ebene kann es Monate dauern
  • Mit einer Learning Agenda sollten umgesetzte und nicht umgesetzte Empfehlungen verfolgt werden; für weiterhin wichtige Punkte sollten aktualisierte Zahlen geliefert und die Unterstützung fortgesetzt werden
  • Wer Folgearbeit einstellt, weil die erste Präsentation nicht angenommen wurde, gibt die Kernarbeit auf, die zur Entscheidung führt

Organisationsstruktur, die das Framework stützt

• Die ideale Grundeinheit ist ein Duo aus einem Analytics Engineer und einem Analysten, das einem bestimmten Geschäftsbereich zugeordnet ist
  • Der Analytics Engineer verantwortet die Robustheit des Systems
  • Der Analyst übernimmt Narrativ, Stakeholder-Beziehungen und Handlungsempfehlungen
• Engineers ohne Partner für Narrative bauen leicht für Vollständigkeit statt für Entscheidungen; Analysten ohne vertrauenswürdigen Systempartner haben Schwierigkeiten, überzeugende Belege zu schaffen
• Bestehende Organisationen müssen sich nicht sofort umstrukturieren; sie können die beiden Rollen für ein Quartal einem Geschäftsbereich zuordnen, das Modell validieren und dann ausweiten
• Wenn Infrastrukturarbeit wie in frühen Unternehmen den Großteil der Teamkapazität bindet, kann statt eines Duos Zeit für gemeinsame Perspektive geschützt werden
  • Wöchentliche Business Reviews durchführen
  • Monatliche Demos für Teams veranstalten, die man nicht direkt betreut
• Wichtiger als das Organigramm selbst ist die Gewohnheit, Perspective zu wiederholen

Operativer Rhythmus, der sich langfristig aufbaut

• Wird die Arbeit, Perspektiven zu entwickeln und Handlungen zu unterstützen, jede Woche wiederholt, kumuliert der Effekt über Monate und Jahre
• Je stärker man am Entscheidungsprozess teilnimmt, desto besser kann man unterscheiden, welche Pipelines keinen klaren Existenzgrund haben, welche Alerts eher Rauschen sind und welche Infrastrukturinvestitionen künftig tatsächlich nötig werden
• Die Rolle des Datenteams besteht darin, eine gemeinsame Realität aufzubauen, der die Mitglieder der Organisation in Bezug auf die aktuelle Lage und ihre Bedeutung gemeinsam vertrauen können
• Data-Perspective-Action ist ein Betriebsmodell, das immer wieder sichtbar macht, dass der Zweck technischer Arbeit bessere Entscheidungen sind; auch Pipelines und Schemata existieren für diese Entscheidungen