Trusted Data Products: Business-Intent, Datenmodellierung und Trust Score – mit Ales Zeman, Quest (Folge 333)

Warum dauert der Aufbau eines einzigen Datenprodukts sechs Monate –
und warum fängt man beim nächsten Anwendungsfall wieder von null
an? Und wie misst man eigentlich, ob man den eigenen Daten trauen
kann? Ales Zeman arbeitet seit über 25 Jahren bei Quest und ist
seit über 30 Jahren im IT-Umfeld unterwegs. Seinen Uni-Abschluss
hat er vor 30 Jahren in künstlicher Intelligenz gemacht – seine
Diplomarbeit war ein Expertensystem, das man mit einem Prompt
ansprechen konnte. Was damals fehlte, sagt er, war die
Rechenleistung. In dieser Folge bringt er die Vendor-Seite in den
Podcast: das Thema Trusted Data Products. Der Ausgangspunkt ist ein
Satz, den Jonas Rashedi vorab bei ihm gefunden hat – ohne Business
Intent funktionieren keine Datenprodukte. Ales Zeman bestätigt das
und begründet es nüchtern: Wenn der Geschäftszweck nicht vorher
bestimmt ist, bekommen die Projekte keine Unterstützung, keine
Ergebnisse und keinen ROI. Was ein Datenprodukt überhaupt ist,
erklärt er an einem Lego-Baukasten. Erst das Ziel, also das Modell,
das gebaut werden soll. Dann die Bausteine, das sind die Daten, die
irgendwo in der Firma liegen. Die Farben und Formen der Steine sind
die Metadaten, der Kontext. Das Heft in der Schachtel ist die
Bauanleitung, also das Datenmodell. Und am Ende landet das fertige
Produkt in einem Marketplace, wo es beschrieben, verglichen und
sogar geliked werden kann. Wie aufwendig das in der Praxis ist,
zeigt ein Fall aus einer Versicherung. Ziel war, bei einem
gemeldeten Vorfall zu erkennen, ob es sich um Betrug handelt.
Allein die Abstimmung zwischen Fachabteilung, Datenabteilung und
Analysten darüber, welche Daten dafür gebraucht werden, hat sechs
Monate gedauert. Das Ergebnis waren 350 Excel-Sheets, aus denen ein
Datenprodukt gebaut wurde. Danach kamen noch einmal zwei Monate für
Governance, sensible Daten und Datenqualität dazu, plus einige
Wochen bis zur Bereitstellung. Beteiligt waren Teams von fünf bis
zehn Leuten aus verschiedenen Abteilungen. Und beim nächsten
Vorfall fing man wieder von null an. Genau dagegen richtet sich der
Ansatz einer automatisierten Data Product Factory. Die Reihenfolge
bleibt aber dieselbe, und keinen Schritt darf man überspringen:
erst Datenmodellierung, dann Datenkatalog, dann Datenqualität, dann
Governance, dann Bereitstellung auf einem Marktplatz. Wer keinen
Katalog hat, kann bestehende Datenbanken per Reverse Engineering
ziehen und daraus die Modelle aufbauen. Vertrauenswürdigkeit wird
gemessen, nicht behauptet. Der Trust Score setzt sich aus neun
gewichtbaren Kriterien zusammen. Datenqualität kann mit 40 Prozent
gewichtet werden, Governance mit 20 Prozent, dazu kommen Lineage,
Modellierung, Likes, Nutzungshäufigkeit und Aktualität. Gefragt,
woran es bei Kunden am häufigsten hakt, nennt Ales Zeman drei
Punkte: Datenqualität wird nicht gemessen, Datenmodelle fehlen oder
liegen nur als Excel-Sheet oder Visio vor, und SLAs zur Aktualität
sind gar nicht erst definiert. Beim Modellieren mit KI zieht er
eine klare Grenze. Ein LLM, das auf den eigenen Datenkatalog und
auf Standardmodelle pro Industrie trainiert ist, baut das
Datenmodell – nicht ChatGPT, das jedes Mal ein anderes Modell
zurückgibt und halluzinieren kann. Außerdem im Gespräch: warum
Kunde 360 das häufigste Datenprodukt in Unternehmen ist, warum
Fraud Detection und Customer Churn die typischen KI-Use-Cases
darüber sind, wie man eine solche Plattform vor einem CFO
begründet, was für und was gegen zentrale Datenhaltung spricht, und
warum Cloud und Cloud-Datenplattformen zwei bis drei Jahre später
in Deutschland angekommen sind als in Nordamerika. Beim AI-Hype
widerspricht er offen. Er würde das nicht Hype nennen, sondern eine
Verschiebung, vergleichbar mit dem Internet oder dem Smartphone.
Privat steuert er sein Zuhause über rund 80 Sensoren. Kurz vor der
Aufnahme meldete sein Hub, dass das Schwimmbecken den
Internetzugriff verloren hat. Sein Filmtitel fürs eigene Data-Game:
Abkürzungen zahlen sich bei KI nicht aus.