70 Prozent aller Data-Transformationen scheitern. Das ist keine Studie, das ist meine Schätzung aus 15 Jahren in Daten-Führungsrollen und über 300 Gesprächen im Podcast. Und sie scheitern nicht an Technologie. Sie scheitern an einer Mischung aus unklaren Mandaten, zu großen Versprechen im ersten Quartal und einer Unterschätzung dessen, was Transformation eigentlich bedeutet: Verhaltensänderung.
Diese Seite ist der Versuch, dir zu geben, was ich selber gern gehabt hätte, als ich zum ersten Mal CDO wurde. Aus zwei Büchern bei Springer Gabler, aus meiner Zeit bei Douglas, Funke und FALKE, und aus 317 Podcast-Gesprächen destilliert. Du-Form, keine Beweihräucherung, und wenn ich keine Zahl habe, sage ich das.
Was ist eine datengetriebene Organisation?
Eine Arbeits-Definition: Eine Organisation, in der Entscheidungen strukturell mit Daten verprobt werden, nicht nur dokumentiert. Der Unterschied ist entscheidend. „Dashboard gucken" ist kein Beleg für Datengetriebenheit. Im Gegenteil — die meisten Organisationen mit den schönsten Dashboards sind genau die, in denen der Vorstand am Ende sowieso entscheidet, was er vorher schon wollte.
Was eine datengetriebene Organisation nicht ist: Kein BI-Team mit 40 Reports. Keine Cloud-Migration. Keine KI-Taskforce. Das sind Zutaten, nicht das Gericht.
Abgrenzung zu Digitalisierung: Digitalisierung ist der Weg vom Papier zum Bit. Datengetriebene Transformation ist der Weg vom Bauchgefühl zur verprobten Hypothese. Das ist nicht dasselbe. Digitalisierung kann lange gut laufen, ohne dass irgendjemand die produzierten Daten für Entscheidungen nutzt.
Mehr zum Reifegrad-Check im Data-Maturity-Modell und zum Zusammenspiel mit Datenkultur.
Wie werden Unternehmen datengetrieben?
Die kurze Antwort: über Wertschöpfung, nicht über Technologie. Die Grundlage, ein Unternehmen datengetrieben zu machen, ist Mehrwert zu schaffen — und Mehrwert kannst du erst schaffen, wenn du dein Business verstehst und weißt, welche Initiativen das Business wirklich verändern. Ich gehe im Podcast inzwischen so weit zu sagen: Wir sollten „weg von datengetrieben hin zu wertschöpfungsgetrieben" (Folge mit Tiankai F., Adidas).
Der Weg dahin läuft in der Praxis über vier Schritte:
- Business-Verständnis vor Dateninitiative. Welche Entscheidungen im Unternehmen haben Geldwert — und welche davon werden heute aus dem Bauch getroffen?
- Sichtbare Use Cases mit Preisschild. Bei Siemens Energy wurde ein manueller Beschaffungs-Prozess von 20 Stunden pro Woche auf zwei Minuten gebracht — „mit diesen Kennzahlen können wir ein gewisses Preisschild an unsere Use Cases bringen" (Folge mit Max J.). Solche Zahlen überzeugen mehr als jede Strategie-Folie.
- Die Bauchgefühl-Hürde ernst nehmen. Marc R. von sevDesk beschreibt das ehrlich: „umso seniorer die Leute werden, umso mehr wollen sie sich auf ihr Bauchgefühl verlassen" — selbst in einem Software-Unternehmen muss sein Team „immer wieder dafür sorgen, dass die Leute mehr mit Daten arbeiten" (Folge zur Data-DNA). Ohne Rückendeckung von oben gewinnt der HiPPO — das „Highest Paid Person's Opinion"-Problem beschreibt schon eine der frühesten Podcast-Folgen mit DHL (zur Folge).
- Nie „fertig" denken. „Wenn du denkst, du bist jetzt fertig — ich glaube, wir befinden uns in einer kontinuierlichen Transformation" (Folge mit Marc R., Pixum).
Das Reifegrad-Raster für die eigene Standortbestimmung liefert Data Maturity, die Kompetenz-Seite Data Literacy.
Woran scheitern datengetriebene Transformationen?
Nach über 320 Podcast-Gesprächen ist das Muster eindeutig: Datengetriebene Transformationen scheitern fast nie an der Technik — sie scheitern an Menschen, Mandat und fehlendem Geschäftszweck. Sebastian W. von ONE LOGIC bringt es auf den Punkt: „Es ist ja jetzt nicht so, dass ich jemals ein Data-Science-Projekt gesehen hätte, wo ich sage, das ist am Algorithmus gescheitert […] sondern es sind die Daten und natürlich auch Business Cases" (zur Folge).
Die fünf häufigsten Scheiter-Muster, jeweils mit echtem Fall:
1. Kein Buy-in — die Strategie verstaubt. „Man hat sich nicht das Mandat geholt, man hat sich nicht das Buy-in der Stakeholder geholt […] Dann verstaubt diese Datenstrategie halt eben nach zwölf Monaten irgendwo in einer Schublade oder auf Sharepoint" — so beschreibt es die Folge mit der Münchener Hypothekenbank; Caroline G. hat deshalb bewusst mit dem Buy-in angefangen, nicht mit dem Papier (zur Folge).
2. Die Fachabteilung wird übergangen. Bei Best Secret scheiterte ein technisch gutes Data-Science-Projekt, weil das Team nach eigener Aussage Oberlehrer gespielt hat: „die Fachabteilung war noch nicht bereit dazu und hat sich wahrscheinlich auch ein wenig von uns bedroht gefühlt. Und dann ist es im Endeffekt gescheitert, weil es nicht angenommen wurde" (zur Folge).
3. Nur Junioren im Projekt. Daniel H. von Zeotap warnt Kunden offen: „Leute, wenn ihr hier nur juniore Leute seid, ist das Projekt zum Scheitern verurteilt" — Senioren delegieren Datenprojekte gern an „die Kids", „aber die Kids können halt nicht entscheiden" (zur Folge).
4. Kein Geschäftszweck. Ales Zeman nach 25 Jahren Datenprodukt-Praxis: „Wenn man den Geschäftszweck nicht vorher bestimmt hat, dann scheitern die Projekte. Die kriegen keine Unterstützung, keine Ergebnisse, keinen ROI." Seine Gast-Einschätzung zur KI-Welle: über 90 Prozent der KI-Projekte kommen nicht zum Ergebnis (zur Folge).
5. Die Kultur blockiert — und der Frontalangriff verschärft es. Meine eigene Douglas-Lehre: „Da gab es den Satz, das Data Warehouse öffnet um 9 Uhr und schließt um 17 Uhr." Am Tisch war die Kultur nicht aufzubrechen — „die Meinungen waren zu hart". Funktioniert hat der Umweg: eine Cloud-Lösung „nebendran" stellen, mit neuen Use Cases Mehrwert zeigen und die alte Welt dann rückwärts aufbrechen (Folge mit Ursula Krause, Sky).
Dahinter liegt fast immer dasselbe Strukturproblem, das Prof. Florian Stahl (Universität Mannheim) beschreibt: „Das Problem ist häufig die Organisationsstruktur […] genau dort sind die Unternehmen häufig wie gelähmt." Und wer im KI-Fieber die Datenbasis überspringt, bekommt seine „brutale Erkenntnis" zwei Schritte später: „Wenn ich keine Daten habe, brauche ich auch über AI nicht reden" (zur Folge).
Warum Transformation jetzt — die drei Treiber
KI-Druck. Generative KI und Agenten-Systeme funktionieren nur auf einer sauberen Daten-Infrastruktur. Der vermeintliche KI-Hype ist in Wirklichkeit ein Daten-Hype mit Verzögerung. Firmen ohne Data Governance werden mit KI teuer scheitern — nicht weil die Modelle schlecht sind, sondern weil sie auf faulen Daten trainieren. Das merken die meisten erst, wenn es peinlich wird.
Wettbewerb. Der Spread zwischen datenreichen und datenreifen Unternehmen wird jedes Jahr größer. Datenreich sind viele — datenreif sind wenige. Wer mit 300 Datenquellen arbeitet, ohne einen Katalog zu haben, ist datenreich. Wer mit zehn Datenquellen dreimal pro Woche eine Entscheidung mit Geldwert ändert, ist datenreif.
Regulatorik. Der EU AI Act ist seit 2024 in Kraft, das volle Pflichtenheft wird 2026 bis 2027 scharf. Dazu DSGVO, Produkthaftungsrichtlinie, sektorale Regulierung (MaRisk, Medizinprodukte). Ohne Governance kannst du das nicht mehr compliant betreiben. Governance ist nicht mehr optional, nicht mal für Mittelständler.
Das Data Maturity Modell — wo steht deine Organisation?
Das Reifegrad-Modell, das ich nutze, orientiert sich am klassischen CMMI (Capability Maturity Model Integration aus der Software-Welt). Es ist kein magisches neues Framework, es ist eine ehrliche Adaption. Fünf Stufen — und ich bin ehrlich: Die meisten deutschen Mittelständler stehen auf Stufe 2, nicht auf Stufe 4, wie sie sich selbst einschätzen.
Stufe 1 — Initial. Ad hoc. Excel-Wüste. Wissen steckt in Köpfen. Wenn die Kollegin geht, geht das Wissen mit. Keine Governance, keine Plattform, keine Rollen. Das ist kein Vorwurf — viele sehr erfolgreiche Mittelständler sind hier.
Stufe 2 — Managed. Es gibt ein BI-Team, wiederkehrbare Reports, ein zentrales Dashboard-Tool. Datenqualität reagiert — wenn etwas falsch ist, wird es korrigiert. Sie agiert aber noch nicht — es gibt keine präventiven Quality-Checks. Dieser Reifegrad wird am häufigsten mit Stufe 4 verwechselt, weil die Dashboards hübsch aussehen.
Stufe 3 — Defined. Prozesse sind dokumentiert. Rollen sind benannt (Data Owner, Data Steward, Data Product Manager). Governance läuft — teuer, aber belastbar. Dieser Sprung von 2 auf 3 ist der mit Abstand teuerste, und hier bleiben die meisten hängen.
Stufe 4 — Quantitatively Managed. Du misst nicht nur dein Business mit Daten, sondern auch deine Datenarbeit selbst. Data Products haben SLAs. Datenqualität wird als Metrik geführt. Wer hier ist, hat Governance nicht nur als PowerPoint.
Stufe 5 — Optimizing. Kontinuierliche Verbesserung ist strukturell verankert. Federated Governance (in der Regel eine Form von Data Mesh). Datenkultur ist real, nicht Wunsch. Das erreichen sehr wenige — und wer es erreicht, darf es nicht für gesichert halten. Bei einem Führungswechsel fällt das schnell auf Stufe 3 zurück.
Vertiefung zum Reifegrad-Sprung im Data-Maturity-Cluster.
Die Rolle des CDO — wer treibt die Transformation?
Ein CDO macht fünf Dinge, nicht zwanzig. Wenn du eine Stellenanzeige mit zwanzig Aufgaben liest, wird daraus fast immer eine Frustrations-Rolle, keine Wirkungs-Rolle.
Erstens: Strategie, die im Vorstand überlebt. Nicht die schönste Strategie-Folie, sondern die, die drei Quartale nach Abnahme noch handlungsleitend ist.
Zweitens: Operating Model für Datenarbeit. Wer macht was, mit welchen Ressourcen, bis wann? Klingt banal, ist aber 80 Prozent der Arbeit.
Drittens: Governance, die nicht in Folien stehenbleibt. Der Unterschied zwischen Governance als Compliance-Reflex und Governance als Vertrauens-Infrastruktur.
Viertens: Data-Team-Aufbau. Die richtigen Rollen zur richtigen Zeit. Dazu später mehr.
Fünftens: Business Cases mit Geldwert. Nicht „Effizienzsteigerung", nicht „bessere Entscheidungen". Sondern benennbare Entscheidungen mit benennbarem Euro-Betrag.
Die klassische Verwechslung: CDO vs. CIO vs. CAIO vs. CDO (Chief Digital Officer, was ein ganz anderer Job ist). Im Cluster zur CDO-Rolle findest du die Matrix, die ich gerne in Vorständen herumreiche, wenn wieder einmal „wer ist für Daten zuständig?" nicht klar ist.
Brauchst du wirklich einen CDO, oder reicht ein Head of Data? Meine Faustregel: Wenn Daten in die Strategie gehören sollen, dann CDO mit C-Level-Mandat. Wenn es um saubere Reports geht, dann Head of Data unter dem CIO. Beides sind ehrliche Wege. Unehrlich wird es, wenn du einen CDO-Titel vergibst ohne C-Level-Mandat — das ist politisches Burnout-Vorprogramm.
Data-Team-Aufbau — die fünf Rollen, die du brauchst
Ich treffe jede Woche CDOs, die drei Data Analysts eingestellt haben und sich wundern, warum das Data-Team keine Wirkung zeigt. Drei Analysts machen schöne Dashboards. Sie bauen keine Daten-Organisation. Dafür brauchst du fünf Rollen, und zwar nicht fünf Köpfe gleichzeitig — aber fünf Rollen im Operating Model.
Data Engineer — das Fundament. Pipelines, Plattform, Data Contracts. Das Fehlbild: „Data Engineer schreibt Skripte für Reports." Das ist Analytics Engineer.
Analytics Engineer / Data Scientist — der Hebel. Transformations-Logik, Metriken-Kataloge, Experimente. Seit der Modern Data Stack sinnvoll getrennt.
Data Product Manager — der oft fehlende Link. Discovery, Roadmap, KPI-Ownership. Wird in deutschen Mittelständlern typischerweise zwei Jahre zu spät besetzt. Und das ist der teuerste Fehler, weil das Team ohne diese Rolle an Problemen vorbeibaut.
Data Translator — die teuerste Rolle, die keiner haben will. Hybrides Profil zwischen Fachbereich und Daten. Nicht Assistenz, nicht PowerPoint-Bauer — eine eigenständige Rolle.
Data Governance Lead — der unbeliebte Retter. Policies, Katalog, Access, Compliance-Übersetzung. Läuft in kleinen Teams mit — ab 20 Data-Mitarbeitern nicht mehr.
Der komplette Aufbau-Pfad mit Hire-vs.-Freelance-Empfehlung steht im Data-Team-Cluster.
Data Governance — ohne Regeln kein Vertrauen
Governance scheitert selten an Regeln. Sie scheitert an Bürokratie. Wenn dein Data-Katalog nach drei Monaten niemand mehr pflegt, hast du kein Regel-Problem, sondern ein Anreiz-Problem.
Das Framework, das ich nutze, hat vier Säulen: Quality, Security, Privacy, Access. Nicht zwanzig. Vier. Und jede Säule hat messbare Kennzahlen, nicht „wir achten darauf".
Zur zentralen Entscheidung gehört: zentral oder federiert? Zentral ist der Klassiker — ein Governance-Team hält die Regeln. Federiert ist das Data-Mesh-Modell — Domain-Owner halten die Regeln mit zentralen Leitplanken. Unternehmen unter 1.000 MA fahren fast immer besser mit zentral. Ab 1.000 MA und mehreren Domänen wird federiert interessant.
Vertiefung im Governance-Cluster und zum Mesh-Ansatz im Data-Mesh-Pillar.
Datenkultur entwickeln — der weichere, härtere Teil
Kultur ist die Sache, die alle in die Roadmap schreiben und dann zuletzt angehen. Und es funktioniert einfach nicht. Tools allein bauen keine Datenkultur. Keine KPI-Kaskade baut Datenkultur.
Drei Hebel, die in meiner Erfahrung funktionieren:
Führung. Was entscheidet der Chef, und wie? Wenn der Vorstand Meetings mit Hypothesen öffnet statt mit Meinung, hast du in sechs Monaten eine andere Organisation.
Ritual. Wie wird Datenarbeit sichtbar? Ein „Monthly Data Moment" — ein Team präsentiert in 20 Minuten eine Entscheidung und die Daten, die dahinterstehen. Keine Dashboards, sondern Entscheidungen.
Incentives. Was belohnst du? Wenn OKRs zur Pflicht eine Datenverknüpfung haben, wird das Verhalten folgen. Wenn nicht, bleibt Datenkultur Lyrik.
Ein häufiger Fehler: zu viel Data Literacy, zu wenig Kultur. Kompetenz ohne Haltung ist leer, Haltung ohne Kompetenz ist naiv. Beides braucht es — im Datenkultur-Cluster steht, wie du sie parallel aufbaust.
Datengetriebenes Change Management — Verhaltensänderung, nicht Kommunikation
Kotter kennst du. Acht Stufen, von der Dringlichkeit bis zur Verankerung. Das Framework ist gut — aber Data-Change ist nicht klassisches Change Management.
Wie ernst man das nehmen muss, sagt Prof. Florian Stahl Unternehmen ins Gesicht: „Schaut zuerst mal, dass ihr auch ein richtig gutes Change Management etabliert, weil ihr werdet als neues Unternehmen enden. Ihr könnt nicht denken, wir kaufen einfach Technologie ein und dann läuft das irgendwie" (zur Folge). Siemens Energy formuliert dieselbe Erkenntnis aus der Praxis: „Das betrifft unsere Daten, die Prozesse und die Menschen. Wenn sich dieser Mensch nicht transformiert, dann tun das die Daten nicht und auch die Prozesse nicht" (Folge mit Tim Kessler). Und die Merck-Data-Culture-Verantwortliche räumt mit dem Top-down-Mythos auf: „Es muss nicht top-down passieren […] Es muss auf allen Ebenen gleichzeitig passieren" (zur Folge).
Meine Budget-Faustregel dazu, seit Jahren im Podcast wiederholt: ein Euro in Technik, drei Euro in Kultur (Folge mit Zurich).
Daten können der Führung widersprechen. Das ist der große Unterschied zu klassischem Change. Wenn du Change von A nach B machst, liefern Daten Beweise, ob A oder B besser ist. Das ist politisch unangenehm. Ein Vorstand, der in zwei Quartalen nicht hören will, was die Zahlen sagen, kippt ein Data-Programm leiser, als du „Kotter Phase 5" sagen kannst.
Messbarkeit ist Waffe und Vorteil zugleich. Data-Change kannst du messen, klassischen Change oft nicht. Das macht dich angreifbar, weil deine Misserfolge quantifiziert sind. Gleichzeitig ist es dein Schutz, wenn du die Messung fair führst.
Echo-Chambers fallen schwerer. „Wir sind alle data-driven, oder?" ist die Fragerunde, in der 80 Prozent ja sagen und 70 Prozent lügen. Du brauchst Metriken jenseits von Self-Report-Surveys.
Die vier Kipppunkte, die ich immer wieder sehe: Monat 3 („Zahlen, die der Vorstand nicht glaubt"), Monat 6 („die Initiative wird leise"), Monat 9 („Schatten-IT entsteht"), Monat 14 („Führungswechsel stellt alles in Frage"). Details im Change-Management-Cluster.
Data Literacy — deine größte Skalierungs-Hürde
Data Literacy ist nicht SQL. Data Literacy ist die Fähigkeit, Daten zu lesen, zu hinterfragen und Entscheidungen darauf zu gründen. Das ist eine Denk-Kompetenz, keine Tool-Kompetenz. Das wird laufend verwechselt, und deshalb werden 90 Prozent aller Literacy-Programme faktisch Tableau- oder PowerBI-Schulungen.
Drei Levels, die ich in meinen DHBW-Vorlesungen und in Corporate-Programmen nutze:
Level 1 — Consumer. Liest Dashboards, hinterfragt Methodik, nutzt Daten für eigene Entscheidungen. Das Minimum für jede Mitarbeiter-Rolle mit Verantwortung.
Level 2 — Data Citizen / Analyst. Erstellt eigene Auswertungen mit Self-Service-Tools, prüft Datenqualität, versteht Metriken-Definitionen.
Level 3 — Producer. Gestaltet Data Products, definiert Metriken, arbeitet eng mit dem Data-Team. In einer gesunden Organisation haben ungefähr 5 Prozent der MA Level 3.
Das 12-Monats-Curriculum steht im Data-Literacy-Cluster.
Buy-in-Management — Vorstand, Mittelbau, Basis
Buy-in ist nicht einstufig. Du brauchst drei Ebenen gleichzeitig:
Vorstand / C-Level. ROI-Argumentation in Entscheidungen mit Geldwert, nicht in Effizienz-Phrasen. Sponsorship, der hält, wenn es politisch wird.
Mittelbau. Die schwierigste Ebene. Typische Bremse: Kompetenz-Angst, Kontrollverlust, Datenqualitäts-Skepsis (oft berechtigt). Lösung: einbinden, nicht umgehen.
Anwender. Passive Nicht-Nutzung ist der stille Tod jedes Data-Programms. Lösung: konkreter Nutzen pro Person, nicht „wir machen das Unternehmen besser".
Im Buy-in-Cluster findest du die zitatfähigen Sätze für jede Ebene — die Formulierungen, die ich aus Vorstandsterminen mitgebracht habe.
<BuchBox title="Das Datengetriebene Unternehmen" subtitle="Rashedi / Greiner / Geuer / Borlik · 2022 · Springer Gabler" description="Der Praxisleitfaden zur datengetriebenen Transformation. 5-Phasen-Prozess, Reifegradmodell, Operating Model." href="https://link.springer.com/book/10.1007/978-3-658-37003-2" />