Ohne Business-Intent scheitert jedes Datenprodukt: Wie aus Lego-Steinen Trusted Data Products werden

Worum es in dieser Folge geht

Ales Zeman ist seit über 25 Jahren bei Quest und seit mehr als 30 Jahren im IT-Umfeld. Sein Uni-Abschluss vor 30 Jahren war ausgerechnet in künstlicher Intelligenz — die er selbst trocken einordnet: „Ich bin alt, die künstliche Intelligenz auch. Das Einzige, was wir damals nicht hatten, war die Rechenleistung." In dieser Folge hole ich mir bewusst die Vendor-Seite an den Tisch, die wir im Podcast bisher kaum beleuchtet haben — und teste ihren Kernsatz auf Herz und Nieren: Ohne Business-Intent funktioniert kein Datenprodukt.

Mich interessiert dabei vor allem der betriebswirtschaftliche Praxistest: Ich denke in Mehrwert, in Umsatz und Kosten, in Time-to-Market. Also frage ich Ales Schritt für Schritt durch: Was ist ein Datenprodukt überhaupt? Wie baut man es auf? Und ab wann lohnt sich das so, dass ich es einem CFO verargumentieren kann?

Die Storyline

Ohne Business-Intent kein Datenprodukt

Der Ausgangspunkt ist ein Satz, den Ales in einem Interview gesagt hatte und den ich ihm gleich zu Beginn vorhalte: Ohne Business-Intent funktionieren keine Datenprodukte. Seine Begründung ist unromantisch: Wer den Geschäftszweck nicht vorher bestimmt, dessen Projekte scheitern — sie bekommen keine Unterstützung, keine Ergebnisse, keinen ROI.

Wichtig ist ihm die Abgrenzung: Manche Dinge sind wirklich nur Werkzeug — du willst Produktivität steigern, also setzt du ein Werkzeug ein. Ein Datenprodukt dagegen ist eine End-to-End-Plattform und vor allem ein Prozess. Man installiert keine Lösung, man verändert die Kultur drumherum und braucht die Unterstützung der höheren Stellen. Genau das kenne ich aus eigener Budgetverantwortung — und ich gebe im Gespräch offen zu, dass mich die Vendor-Frage „Welches Problem habt ihr eigentlich?" früher regelmäßig geschmerzt hat, weil sie einen zwingt, erst über die eigenen Probleme nachzudenken, statt ein glänzendes neues Tool zu kaufen.

Die Lego-Analogie: Ziel, Steine, Anleitung, Marktplatz

Auf meine Bitte, ein Datenprodukt erst einmal zu definieren, greift Ales zu seiner Lieblingsanalogie — dem Lego-Baukasten. Die erste Frage ist immer: Was will ich erreichen? Bei Lego ist das ein Modell des Eiffelturms, im Unternehmen der Business-Intent. Dann brauche ich die Bausteine — das sind alle Daten, die irgendwo in der Firma liegen. Die Steine haben Farben und Formen: das sind die Metadaten, der Kontext. Woher kommen die Daten, was bedeuten sie, wie sehen sie aus? Dazu kommt das Anleitungsheft — das Datenmodell, das beschreibt, wie die Teile zusammenhängen.

Und wenn das Produkt fertig ist, muss man es vermarkten: auf einem Marktplatz, wie ein Webshop mit Preisschild. Dort werden Datenprodukte veröffentlicht, sind vergleichbar, haben Beschreibungen — und können sogar geliked werden. Die vier Bestandteile fasst Ales so zusammen: Daten, Modell, Kontext (Metadaten) und Vermarktung. Das typische interne Datenprodukt heißt fast immer Kunde 360 — die Sicht darauf, was Kunden kaufen und wie sie sich verhalten, verknüpft mit Transaktions- und Produktionsdaten. Und dass wir längst selbstverständlich Datenprodukte nutzen, zeigt er am Alltag: Google oder Apple Maps und die Verkehrslage sind nichts anderes.

Governance als Service statt Bürokratie

Hier kommt mein liebster Perspektivwechsel der Folge. Der klassische Weg, Kundendaten zu beschreiben — „Sag mal, welche Daten hast du da drin, wie sehen die aus?" — hat schnell den Charakter einer Bürokratisierung. Der smarte Move ist, es über das Produkt zu spielen: Du bist derjenige, der diese Kundendaten als Service für andere bereitstellt. Aus Regulierung wird eine Leistung, die andere Abteilungen konsumieren — und untereinander sogar „Verträge" schließen. Das finden Menschen auf einer psychologischen Ebene viel attraktiver, und dann bringt es sogar Spaß.

Der Startpunkt ist für Ales trotzdem unromantisch: die Datenmodellierung, ein konzeptuelles und logisches Modell. Denn die Kernfrage „Was ist ein Kunde?" beantwortet jede Abteilung anders. Ohne gemeinsames Konzept lässt sich kein abteilungsübergreifendes Datenprodukt bauen — alle bleiben in ihren Silos. Governance darf man dabei nicht überspringen: Datenkatalog, wissen wo die Daten liegen, sensible Daten klassifizieren. In regulierten Branchen ist dieses Fundament oft schon da und lässt sich mitbenutzen.

Der 400.000-Euro-Beweis: der Versicherungs-Case

Damit es konkret wird, erzählt Ales von einer Versicherung, die seit Jahren Datenprodukte baut — noch ohne Automatisierung. Das Ziel: bei einem gemeldeten Vorfall erkennen, ob es Betrug ist. Dafür müssen Daten aus Kontakthistorie, Sentiment aus Call-Center-Anrufen und die eigenen Policies zusammengeführt werden. Allein die Abstimmung zwischen Fachabteilung, Datenabteilung und Analysten — welche Daten braucht man überhaupt? — dauerte sechs Monate. Das Ergebnis: 350 zusammengebaute Excel-Sheets.

Danach kamen noch einmal rund zwei Monate obendrauf: Governance-Leute mussten prüfen, ob alle Policies abgedeckt sind, wo die sensiblen Daten liegen und wer sie nutzen darf; Data Stewards mussten die Datenqualität sicherstellen und bereinigen. Die Teams: fünf bis zehn Leute aus verschiedenen Abteilungen. Die Kosten für dieses eine Datenprodukt: rund 400.000 Euro. Und beim nächsten Vorfall oder Zweck beginnt man wieder bei null.

Wie KI Monate auf Tage schrumpft

Das war das Vorher-Bild. Der Hebel ist eine End-to-End-Plattform plus KI. Voraussetzung bleibt: Ich muss wissen, wo meine Daten liegen — und da sind viele deutsche Firmen erschreckend weit am Anfang. Wo noch kein Datenkatalog existiert, zieht man per Reverse-Engineering die bestehenden Datenbanken, baut aus den physischen Modellen ein logisches, geht zum Konzept über und startet mit Datenqualität. Die KI schlägt Regeln vor (ein Geburtsdatum liegt zwischen 1950 und heute), findet fehlende Business-Terms, schlägt Definitionen vor, appliziert Policies auf sensible Daten — der Mensch bestätigt nur noch.

Entscheidend ist Ales' Klarstellung, was diese KI ist — und was nicht: kein ChatGPT. Wer ein Datenmodell einfach an ein allgemeines Sprachmodell übergibt, bekommt jedes Mal ein anderes Ergebnis, weil es halluziniert. Stattdessen wird ein LLM erstens auf dem eigenen Datenkatalog trainiert (es kennt die real vorhandenen Daten) und zweitens auf Standardmodellen, die Quest über 30 Jahre pro Industrie gesammelt hat. Mit klaren Guardrails wird das Modell gezwungen, sich nichts auszudenken, sondern nur Bestehendes zu nutzen. So schrumpft die Definitionsphase von Monaten auf Tage.

Trust Score: Vertrauen in neun Kriterien

Weil im Titel „Trusted" steht, will ich wissen: Wie misst man Vertrauenswürdigkeit? Ales' Antwort ist ein Trust Score aus mehreren gewichteten Kriterien. Datenqualität lässt sich über Regeln messen und wiegt bei ihm rund 40 Prozent. Governance — sind Glossar, Policies und sensible Daten klassifiziert? — kommt auf rund 20 Prozent. Dazu Lineage (Herkunft und Transformation der Daten, nachweisbar), das Vorhandensein von Modellen, die Aktualität (SLA/Freshness) und — mit kleiner oder sogar null Gewichtung — die Likes: Wurde ein Produkt schon genutzt, gab es Feedback?

Als Zahlen-Mensch frage ich nach den drei Kriterien, die bei den meisten Kunden am schlechtesten sind. Ales' Antwort: Erstens wird Datenqualität oft gar nicht gemessen (nicht, dass sie schlecht wäre). Zweitens fehlt die Datenmodellierung — oder sie existiert nur als Excel-Sheet oder Visio, was sich zwischen Fachabteilungen kaum austauschen lässt. Und drittens werden SLAs zur Aktualität schlicht vergessen.

Nicht nur für Konzerne — und warum Deutschland spät dran ist

Sind Datenprodukte nur etwas für große Versicherungen? Nein. Der Treiber im Mittelstand sind KI-Anwendungen — und KI braucht gute, vertrauenswürdige Daten. Der Weg dorthin führt über Datenprodukte. Der Haken: Viele Mittelständler haben noch nicht einmal einen Datenkatalog. Dann kann die automatisierte Data Product Factory noch nicht ansetzen, und man muss einen Schritt zurückgehen — von „automatisiert" zu erst einmal „verwaltet". Rund 80 Prozent der Daten sind in vielen Firmen unbekannt: wo sie liegen, woher sie kommen, wer zuständig ist.

Spannend wird der Vergleich, als ich meine drei Siemens-Energy-Folgen zum Thema Data Mesh einbringe — dort ist man klein und hands-on gestartet und über Jahre gereift. Quests Ansatz ist eine integrierte Plattform. Ales bleibt fair: zentral oder dezentral muss jede Firma selbst entscheiden; bei großen Konzernen mit vielen Akquisitionen ist zentrale Datenhaltung oft gar nicht agil genug. Entscheidend ist aber, dass zumindest das logische Modell abteilungsübergreifend gleich ist — und die Plattform bleibt bewusst unabhängig (Snowflake, Databricks, Microsoft Fabric). Dass Deutschland beim Thema Cloud-first zwei bis drei Jahre hinter Nordamerika liegt, zieht sich als roter Faden durch. Und den Begriff Hype weist er zurück:

Warum mich das besonders umtreibt

Ich bin mit einer klaren Skepsis in dieses Gespräch gegangen: Wenn die Vendor-Seite kommt, rechne ich mit Marketing. Was hängen geblieben ist, ist stattdessen die Ehrlichkeit der Zahlen — gerade der Versicherungs-Case, bei dem ich als CFO sofort abgewinkt hätte. Genau das ist der Punkt: Nicht die Plattform entscheidet, sondern ob vorne ein echter Business-Intent steht und hinten Wiederverwendbarkeit herauskommt. Ohne das ist jedes Datenprodukt ein 400.000-Euro-Einzelstück.

Bei den Ersparnis-Zahlen bleibe ich der Kaufmann, der nachrechnet — „über 50 Prozent" ist eine Vendor-Annahme, kein Naturgesetz. Aber zwei Dinge nehme ich ernst mit: die Erkenntnis, dass die meisten Organisationen den Schritt zurück (erst wissen, wo die Daten liegen) überspringen, weil sie dem KI-Hype hinterherrennen — und Ales' Buchtitel-Satz, der das ganze Gespräch zusammenfasst: Abkürzungen zahlen sich bei KI nicht aus.

Jetzt reinhören