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.
