Data Enablement macht AI endlich skalierbar

Obwohl viele Unternehmen stark in AI investieren, bleibt der Schritt vom erfolgreichen Pilotprojekt zum skalierbaren Erfolgsfaktor schwierig. Data Enablement schafft die Voraussetzung dafür, AI über einzelne Initiativen hinaus im Unternehmen zu verankern. Mit verlässlichen Daten, klaren Verantwortlichkeiten und technischen Grundlagen, auf denen Anwendungen aufbauen können. 

AI-Technologie entwickelt sich rasant. Viele Probleme dahinter sind erstaunlich alt. Wer schon Data-Warehouse-, Big-Data- oder Data-Science-Initiativen begleitet hat, erkennt beim Scheitern heutiger AI-Vorhaben bekannte Muster wieder. Eine Plattform ist schwer zu nutzen, also wird eine neue eingeführt. Verantwortlichkeiten sind unklar, also entsteht ein weiteres Governance-Gremium. Die Adoption bleibt niedrig, also folgt das nächste Trainingsprogramm. Jede dieser Maßnahmen kann sinnvoll sein. Schwierig wird es, wenn sie nur einzelne Symptome adressieren. Data Enablement setzt genau dort an. 

Unser Kollege Boyan Angelov, Principal Data and AI Strategist bei Exxeta, hat  gemeinsam mit David Castro-Gavino im Buch Enabling Data (Facet Publishing, 2026) ein Modell entwickelt, das die organisatorischen Voraussetzungen für erfolgreiche Daten- und AI-Initiativen zusammenführt. Die zentrale Frage: Was muss ein Unternehmen aufbauen, damit der zehnte AI Use Case nicht wieder bei null beginnt? 

Was Data Enablement ermöglicht 

Viele Unternehmen haben längst bewiesen, dass AI in einzelnen Anwendungsfällen funktionieren kann und einen echten Mehrwert leistet. Das eigentliche Problem beginnt danach. Ein Pilot wird auf einer eigens dafür zusammengestellten Infrastruktur umgesetzt. Daten werden für diesen einen Anwendungsfall extrahiert, Kennzahlen im Projektteam definiert und die Zugriffsrechte individuell geklärt. Beim nächsten Use Case beginnt ein anderes Team wieder mit denselben Fragen. So entstehen viele erfolgreiche Einzelprojekte, ohne dass daraus eine skalierbare Fähigkeit wird. 

Ein konkretes Beispiel zeigt, wie sich das anfühlt: Bei HelloFresh kamen drei Teams auf drei verschiedene Churn-Raten. Ein Analyst hatte die Kennzahl für sein Team von Grund auf neu aufgebaut – ohne zu wissen, dass zwei andere Teams dasselbe gerade ebenfalls taten. Das ist keine Ausnahme, das ist das Standardmuster in Unternehmen ohne Data Enablement. 

Dieses Muster lässt sich als Pilotitis beschreiben: Die Zahl der Proofs of Concept steigt, aber nur wenige schaffen dauerhaft den Weg in den produktiven Betrieb. Ein AI-Forecasting-Pilot kann im Labor einwandfrei funktionieren und trotzdem nicht skalieren, wenn niemand vorab geklärt hat, wie er ans ERP angebunden wird, wer ihn betreibt und wie das Retraining gesteuert wird. Die Engineers müssen ihn dann für die Produktion neu bauen. Ein Pilot ohne geplanten Weg zur Skalierung ist nur Theater. 

Ein grundlegendes Problem beginnt bereits bei der Entstehung der Daten. Auf der einen Seite stehen die Datenproduzenten: Menschen und Systeme, die Daten überhaupt erst erzeugen. Die Kolleg:in im Vertrieb, die ein CRM-Feld füllt. Die Maschine, die Telemetrie sendet. Das Billing-System, das eine Zeile schreibt. Für diese Akteure sind Daten häufig ein Nebenprodukt ihrer eigentlichen Aufgabe. 

Auf der anderen Seite stehen die Datenkonsumenten: Menschen und Produkte, die aus Daten ableiten, was passiert ist, was passieren wird und was zu tun ist. Die Analystin, das Board-Deck, das Forecasting-Tool im Vertriebsmeeting. Und immer häufiger AI-Agenten, die Daten automatisiert interpretieren, Entscheidungen vorbereiten und Aktionen auslösen. 

Das Problem: Beide Seiten kennen die Anforderungen der jeweils anderen Seite kaum. Ein CRM-Feld kann für den Vertrieb optional erscheinen. Monate später soll aber genau diese Information ein Prognosemodell speisen. Erst dann fällt auf, dass ein großer Teil der Einträge fehlt oder uneinheitlich gepflegt wurde. Das Ziel von Data Enablement ist, die organisatorischen und technischen Voraussetzungen so aufzubauen, dass Daten zuverlässig für Analytics & AI genutzt werden können. 

Drei Fehler, an denen Data Enablement regelmäßig scheitert 

Drei Muster tauchen immer wieder auf: isolierte Einzelmaßnahmen, behandelte Symptome und ein Nordstern, den niemand beschreiben kann. 

1. Isolierte Einzelmaßnahmen 

Hier ein Datenkatalog, dort eine Qualitätsinitiative, anderswo ein Governance-Board. Jede Maßnahme lässt sich für sich begründen. Ihre Wirkung bleibt jedoch begrenzt, wenn die Abhängigkeit dazwischen fehlt. Ein technisch guter Datenkatalog bringt beispielsweise wenig, wenn Verantwortlichkeiten unklar sind oder die Fachbereiche keinen Grund haben, ihn im Alltag zu nutzen. Ein starkes AI-Team wiederum kann nur begrenzt skalieren, wenn für jeden neuen Use Case zunächst eigene Datenpipelines und Zugriffsprozesse gebaut werden müssen. 

Was beim Data-Mesh-Ansatz passierte, illustriert das gut: Teams bekamen Autonomie und Werkzeuge, aber keine gemeinsamen Definitionen und keine Leitplanken. Das Ergebnis war Chaos statt Empowerment. US-Teams begannen, eigene Schatten-Pipelines zu bauen. Der Punkt: Werden die vier Säulen getrennt behandelt, entsteht Reibung. Data Enablement ist die Verbindungsebene, die sie zusammenhält. 

2. Symptome behandeln statt Ursachen 

Viele vermeintlich technischen Probleme haben organisatorische Ursachen. Wer verantwortet ein bestimmtes Datenfeld? Welche Definition von Umsatz gilt unternehmensweit? Wer entscheidet über Zugriffsrechte? Sind diese Fragen ungeklärt, entstehen Probleme später auf der technischen Ebene. Der Reflex heißt dann: mehr Technologie, mehr Prozesse. Die Ursache verschwindet nicht. Sie liegt danach nur tiefer und wird teurer, sie zu beheben. 

3.  Das Zielbild bleibt abstrakt 

Wenn ein Führungsteam »AI-first« ausruft, können die wenigsten im Raum beschreiben, was das an einem Dienstagmorgen konkret bedeutet. Was folgt, ist ein Cargo-Kult. Die Organisation baut die sichtbaren Artefakte datengetriebener Unternehmen nach und lässt das Betriebsmodell darunter weg. Dasselbe Muster hat schon die Big-Data-Welle geprägt und danach die Data-Science-Welle. Neu ist allein die Geschwindigkeit, mit der diese Lücke heute aufklafft. 

Vier Voraussetzungen für skalierbare AI 

Das Data and AI Enabling Model ordnet Abhängigkeiten entlang von vier Bereichen: Menschen, Technologie, Governance und Daten. Dabei geht es nicht darum, überall den maximalen Reifegrad zu erreichen. Entscheidend ist die Frage: Welcher Bereich begrenzt unsere Data- und AI-Initiativen aktuell am stärksten? 

Horizontal laufen vier Säulen. Ob du in sie investiert hast oder nicht: Jedes Daten- oder AI-Vorhaben läuft durch alle vier. Die schwächste Säule bestimmt, wie hoch du darüber bauen kannst. Ein exzellentes Modell auf ungeprüften Daten erzeugt vor allem Risiko. Eine perfekte Architektur, die im Fachbereich niemand bedienen kann, bleibt eine Kostenstelle mit guter Dokumentation. 

Dass es funktioniert, wenn Enabling-Investitionen und Use-Case-Initiativen zusammengedacht werden, zeigen Zahlen aus einem Metadatenprogramm, das Boyan Angelov und David Castro-Gavino im Buch dokumentieren: Nach einem Quartal sank die Onboarding-Zeit für neue Datenprodukte um 42 Prozent, wiederkehrende Kennzahlen-Anfragen gingen um 35 Prozent zurück und die Nutzung des Datenkatalogs stieg um 64 Prozent. Diese Zahlen zeigen keinen abstrakten Infrastrukturgewinn. Sie zeigen, was passiert, wenn Teams aufhören, dieselbe Arbeit immer wieder neu zu erledigen. 

Das Modell betrachtet Data Enablement zusätzlich in drei Phasen: Strategie, Taktik und Portfoliomanagement. 

Strategie klärt das Warum und das Was: die Verbindung zu Geschäftszielen, die Auswahl der Säulen, messbare Ziele und ein ehrlich dokumentierter Ausgangszustand. In der Praxis bedeutet das 30 Tage Diagnosearbeit: Die Data-Führungskraft interviewt fünf bis sieben Schlüsselpersonen, begleitet sie bei der Arbeit und kombiniert drei Arten von Evidenz – was Menschen als Schmerzpunkte benennen, Nutzungsdaten und vorhandene Dokumente. Das Ergebnis ist eine Friction Map über alle vier Säulen. Typische Erkenntnisse: mehrere Definitionen derselben KPI, veraltete Glossareinträge, Lineage, die nur in Köpfen existiert, und Analysten, die immer wieder dieselben Fragen stellen. Die wichtigste Disziplin in dieser Phase: nicht zu früh handeln. Keine Tool-Käufe, keine Zielarchitektur, bevor die Diagnose abgeschlossen ist. 

Die Taktik-Phase widmet sich ganz der Frage: Welche Voraussetzung müssen wir schaffen? Hier entstehen ein cross-funktionales Betriebsmodell, die tragenden Werkzeuge (Qualitätsprogramm, Datenkatalog) und die Arbeit an Training und Change Management. Diese Elemente schneiden mit Absicht quer durch alle Säulen, denn das Zusammenspiel ist wichtig. Ein Datenqualitätsprogramm gehört nicht allein in die Datensäule. Es berührt Menschen, Technologie und Governance gleichzeitig. Sonst wirkt es nicht. 

Portfoliomanagement überspringen die meisten. Der Grund liegt im Wesen von Pilotitis selbst: Führungskräfte wollen schnelle Erfolge, Anbieter wollen Referenzfälle, und Teams wollen neue Technologie – ohne die Verantwortung für den Betrieb. Was hilft, ist die Kopplung: Jede AI-Initiative bekommt eine Enabling-Investition dazu. Wirkung wird in echten Reviews nachgehalten und mit einer klaren Baseline gemessen, nicht mit der Menge des Gelieferten. 

Mit einer Domäne starten, nicht dem ganzen Konzern 

Der häufigste Fehler bei großen Frameworks ist der Versuch, sie sofort unternehmensweit auszurollen. Der beste Start für Data Enablement ist eine klar abgegrenzte Organisationseinheit oder Business-Domäne, die ihre Daten, ihre Use Cases und ihr Budget selbst verantwortet. 

Wie wählt man diese Domäne aus? Ein formales Bewertungsschema gibt es nicht. Sinnvoller ist es, in zwei bis drei Domänen mit der höchsten wahrnehmbaren Reibung zu starten und vorab die Zusage eines Domain-Champions zu sichern, der das Vorhaben aktiv trägt. Was nicht funktioniert: erst alle Daten in Ordnung bringen zu wollen, bevor mit Use Cases begonnen wird. 

Ist das Vorgehen in einer Domäne erprobt, kann es auf weitere Bereiche übertragen und dort angepasst werden. Das reduziert Komplexität und verhindert, dass ein großes Transformationsprogramm jahrelang Grundlagen definiert, bevor der erste messbare Nutzen entsteht. 

Was passiert, wenn eine Domäne scheitert? Das lässt sich mit der richtigen Vorbereitung entschärfen. Jeden Piloten als Experiment mit Hypothese und klaren Kennzahlen aufzusetzen bedeutet, dass ein Scheitern Erkenntnis liefert und keine Blamage ist. Go/No-Go-Entscheidungspunkte geben dem Prozess Struktur. Die Durststrecke, in der Probleme sichtbar werden, ist keine Niederlage. Sie ist Klarheit darüber, wo das Unternehmen wirklich steht. 

Vier Fragen für dein nächstes Steering Meeting 

Wer wissen möchte, wie gut die Voraussetzungen für skalierbare AI Use Cases bereits sind, sollte diese vier Fragen stellen: 

1. Was hat unser letzte KI-Use-Case hinterlassen, das der nächste wiederverwenden kann? 

Lautet die Antwort »nichts«, kostet der zwanzigste Use Case so viel wie der erste. Ein klares Signal, dass das Unternehmen einzelne Projekte baut, aber noch keine skalierbare AI-Fähigkeit. 

2. Welche der vier Säulen begrenzt uns aktuell am stärksten? 

Menschen, Technologie, Governance oder Daten? Gefragt ist die Säule, die aktuell den Nutzen aller anderen begrenzt. Das ist selten die absolut schwächste. Die Investition folgt dieser Antwort, nicht dem Organigramm. 

3. Wer verantwortet die Definitionen der Daten, die unsere Modelle verwenden? 

Fehlt die Verantwortung, können AI-Systeme Ergebnisse produzieren, die plausibel wirken und trotzdem auf falschen oder widersprüchlichen Grundlagen beruhen. 

4. Was ist unsere Baseline? 

Wer nicht sagen kann, wie es vor dem Start aussah, wird nie belegen können, was sich verändert hat. Die nächste Budgetrunde verliert er an jemanden, der es kann. 

Keine dieser Fragen braucht eine neue Plattform, eine Reorganisation oder ein externes Programm. Sie schaffen vor allem Klarheit darüber, wo das Unternehmen heute steht. 

Data Enablement schafft die Grundlage für skalierbare AI 

Ein Eisberg zeigt über der Wasserlinie nur einen kleinen Teil seiner Masse. Der weitaus größere Teil liegt verborgen darunter und trägt trotzdem das ganze Gewicht. Bei AI-Initiativen ist es nicht anders: Was als Pilot, Dashboard oder Chatbot sichtbar wird, ist immer nur die Spitze. Ob sie trägt, entscheidet sich in dem, was darunter liegt. 

Wettbewerbsvorteile, für die frühere Generationen Jahre brauchten, schmelzen heute innerhalb weniger Quartale ab. Die Unternehmen, die dabei vorne bleiben, gewinnen nicht, weil sie die meisten Piloten vorzuweisen haben. Sie gewinnen, weil sie die unspektakuläre Arbeit unter der Wasserlinie erledigt haben, während andere noch Ankündigungen geschrieben haben. 

Genau das ist Data Enablement: kein zusätzliches Programm neben der AI-Strategie, sondern ihre Voraussetzung. Am ersten Piloten scheitert selten jemand. Am zehnten schon, wenn er genauso viel kostet wie der erste. Die Frage ist also nicht, ob dein Unternehmen AI kann. Die Frage ist, ob der nächste Use Case leichter wird als der letzte. Wenn die Antwort »nein« lautet, weißt du jetzt, wo du anfangen solltest.