Der CDO der Howden Group darüber, warum das Datenprodukt-Modell bei schnellem Akquisitionstempo scheitert – und wie eine agentenbereite Datenschicht stattdessen aussieht
von Aly McGue
Das traditionelle Daten-Playbook für Unternehmen setzt ein bestimmtes Tempo voraus. Sie entwerfen eine Strategie, bauen die Plattform auf, binden Datenquellen methodisch an und stellen Produkte für jeden wichtigen Anwendungsfall bereit. Der Plan ist das Artefakt, und das Artefakt ist auf Langlebigkeit ausgelegt.
Dieses Playbook wird nun auf eine Weise auf die Probe gestellt, für die es nicht entwickelt wurde. Unternehmen, die durch Übernahmen wachsen, agentenbasierte Workflows aufbauen und neue Datenquellen in rasantem Tempo integrieren, stellen fest, dass Strategien aus einer langsameren Ära zu Hindernissen für das eigene Geschäft werden. Die Architektur, Taxonomie und das Betriebsmodell, die bei einem bestimmten Tempo funktionierten, wirken dem nächsten Tempo aktiv entgegen.
Barry Panayi ist Group Chief Data Officer bei Howden, einem globalen Versicherungsmakler, Underwriter und Rückversicherer, der in über 50 Ländern mit 25.000 Mitarbeitenden tätig ist. Vor fünf Jahren hatte das Unternehmen noch 10.000 Beschäftigte. Im letzten Jahr hat es mehr als ein Unternehmen pro Woche übernommen. Howden betreibt seine Enterprise-Datenplattform auf Databricks und konsolidiert über 100 Datenquellen in einer einheitlichen Architektur, die von der regulatorischen Berichterstattung bis hin zu Conversational Analytics über Databricks Genie alles unterstützt.
In diesem Blog erörtert Barry, warum traditionelle Designentscheidungen für die zukünftige Nutzung von AI nicht mehr funktionieren. Das Produktmodell wird schwerfällig. Der Abstimmungszyklus wird teuer. Der Dashboard-Backlog wird zum Engpass. Im Folgenden legt Barry dar, was man stattdessen aufbauen sollte.
Aly McGue: Sie haben erwähnt, dass das Modell „Ein Produkt pro Anwendungsfall“ ab einem bestimmten Punkt an seine Grenzen stößt. Was meinen Sie damit und was tritt an seine Stelle?
Barry Panayi: Ich habe die Erfahrung gemacht, dass dieses Modell schwerfällig wird. Wenn Sie sich Ihre Datenebene als eine Reihe offener, verwalteter Services vorstellen, lässt sie sich viel flexibler an alle kommenden AI-Anforderungen anpassen.
Wir werden Daten für Agenten bereitstellen, die sie im gesamten Unternehmen verteilen, und das erfordert eine andere Design-Mentalität. Sie können nicht jeden Anwendungsfall im Voraus definieren, wenn die Konsumenten nicht mehr nur Dashboards und Analysten sind. Agenten werden Daten auf eine Weise kombinieren, die Sie nicht vorhergesehen haben. Ein Service-Layer setzt genau das voraus. Ein Produktkatalog tut das nicht.
Deshalb rate ich auch dazu, die Verantwortlichen für Prozess- und Agenten-Workflows in Ihrem Unternehmen frühzeitig einzubinden. Nicht erst, wenn die Plattform bereits steht.
Aly: Howden hat im letzten Jahr mehr als ein Unternehmen pro Woche übernommen. Was macht dieses Tempo mit einer Datenorganisation und was musste sich architektonisch ändern?
Barry: Als ich anfing, hatten wir etwa 80 Datenquellen angebunden, und die Datenintegration nach einer Übernahme dauerte rund sechs Monate. Bei unserem Akquisitionstempo bedeutete dies, dass die Leute Silos bildeten oder Daten von woanders herholten, weil sie sofort Ergebnisse brauchten. Die Akzeptanz in unseren Geschäftsbereichen war gering, weil wir schlichtweg nicht die nötige Abdeckung hatten.
Es war nicht nur eine technische Modernisierung. Es ging darum, die Kosten für Fragmentierung, langsame Integration und Doppelarbeit zu eliminieren. Architektonisch sind wir in eine andere Richtung gegangen. Beim vorherigen Setup wurden das Data-Mastering und die Qualitätsprüfungen weiter nachgelagert durchgeführt, also näher am Reporting-Layer. Wir mussten dies so nah wie möglich an der Datenaufnahme (Ingestion) ansetzen, damit die Daten schneller nutzbar werden. Dieser Wechsel verändert den gesamten Zeitplan.
Eine der größten Stärken von Howden ist die Zusammenarbeit zwischen verschiedenen Geschäftsbereichen. Und der Treibstoff dafür sind die Daten. Sie müssen wissen, was Ihre Kollegen haben, das Ihnen helfen könnte, und wie Sie ihnen helfen können. Es gab so viele Geschäftsmöglichkeiten, die wir allein dadurch erschließen konnten, dass wir Daten sichtbar machten – noch nicht einmal vollständig integriert und aufbereitet, einfach nur sichtbar.
Aly: Wenn man so viele Quellen hat, kann dieselbe Kennzahl in mehreren korrekten Versionen existieren. Wie haben Sie verhindert, dass Ihr Team seine Zeit mit dem manuellen Datenabgleich verbringt?
Barry: Wir hatten teilweise bis zu vier Versionen desselben Datenpunkts, und alle waren in ihrem eigenen Kontext korrekt. Es gab kein gemeinsames Datenmodell oder eine einheitliche Taxonomie, sodass mein Team viel Arbeit darauf verwenden musste, herauszufinden, welche Version für eine bestimmte Antwort die richtige war.
Die Führungskräfte bekamen immer, was sie brauchten. Wir haben dafür gesorgt, dass die Zahlen stimmten. Aber der manuelle Abgleich kostete Zeit und Ressourcen, die wir für wertvollere Aufgaben hätten nutzen können. Seitdem haben wir parallel zur Plattform ein Standard-Datenmodell entwickelt, das Accord-Datenmodell. Dieses kodifiziert die Logik, sodass der Abgleich integriert ist, anstatt darauf angewiesen zu sein, dass Mitarbeitende Fehler jedes Mal manuell abfangen.
Das ist der entscheidende Punkt. Wenn Ihre Taxonomie nicht kodifiziert ist, wird Ihr Team zur Abgleichsmaschine. Das ist eine Steuer, die Sie in jedem Berichtszyklus zahlen, und sie skaliert mit dem Unternehmen in genau die falsche Richtung.
Aly: Viele Unternehmen haben ein Portfolio von AI-Pilotprojekten, die nie skaliert werden. Was hat sich bei Howden geändert?
Barry: Wie bei vielen Organisationen ging es in unserer Anfangsphase vor allem um die Erkundung, was bedeutete, dass wir individuelle Anwendungsfälle von Grund auf neu entwickelten. Das war eine notwendige Phase, um zu sehen, was möglich ist. Aber um wirklich zu skalieren, mussten wir davon wegkommen, für jeden Geschäftsbereich alles neu zu bauen. Dank der Art und Weise, wie wir die Databricks-Plattform nutzen, verfügen wir heute über standardisierte Pipelines, gemeinsam genutzten Code und wiederverwendbare Daten-Assets. Wir können bereichsübergreifende Analysen durchführen, indem wir Kunden-, Risiko- und Marktdaten miteinander kombinieren – und das einmalig aufbauen, anstatt es für jeden Bereich neu zu entwickeln.
Wir haben mittlerweile eine gruppenweite AI-Anwendungsfall-Pipeline. Wir arbeiten immer noch daran, Modelle in die Produktion zu überführen, damit sie als konsistente Services genutzt werden können – das ist eine Lücke, die ich offen eingestehe. Aber der Übergang von isolierten Experimenten zu einer skalierbaren Funktion ist real. Ohne diese einheitliche Sichtweise könnten wir nichts davon tun.
Aly: In einer Branche, die sich nicht im Transaktionstempo des Einzelhandels bewegt: Wo verändern schnellere Daten tatsächlich das Ergebnis?
Barry: Worauf es enorm ankommt, ist die Reduzierung dessen, was ich als „Insight-Lag“ bezeichne – die Spanne zwischen dem Zeitpunkt, an dem Daten irgendwo im Unternehmen entstehen, und dem Zeitpunkt, an dem sie tatsächlich genutzt werden können.
Unser Geschäft besteht hauptsächlich aus der Vermittlung (Broking). Das bedeutet, dass wir Maklern die aktuellsten Erkenntnisse liefern müssen, bevor sie sich mit einem Kunden zusammensetzen. Unser Reporting war früher langsam und Batch-gesteuert. Die Daten waren nicht falsch, aber bis man sie zu Gesicht bekam, waren sie veraltet. Das führt nicht zu einem Vertrauensproblem, sondern zu einem Nützlichkeitsproblem. Man arbeitet quasi mit dem Blick in den Rückspiegel.
Wenn heute ein Makler zum Kunden geht, kann er sagen: „Das ist es, was wir derzeit in unserem gesamten Bestand sehen, das ist das Benchmarking, das ist unsere interne Einschätzung.“ Unsere Daten sind unser IP. Es gibt nicht viele Unternehmen, die wie wir die gesamte Wertschöpfungskette im Versicherungswesen abdecken. Ich wäre verrückt, wenn ich nicht dafür sorgen würde, dass wir diese Erkenntnisse schnell bereitstellen – und mit der Fragmentierung, die wir zuvor hatten, wäre das absolut unmöglich gewesen.
Aly: Was war der Auslöser für die Einführung von Genie und was hat sich bei der Suche nach Antworten geändert?
Barry: Die Frage, die mir gestellt wurde – möglicherweise sogar schon in meinem Vorstellungsgespräch –, lautete: Warum können wir nicht einfach mit unseren Daten chatten? Die Logik war simpel. Die Menschen chatten über ChatGPT mit dem gesamten Internet. Warum also können sie nicht den Daten ihres eigenen Unternehmens eine Frage stellen und eine schnelle Antwort erhalten?
Das hat zwei Seiten. Die eine ist die reine Geschwindigkeit. Jemand hat eine Frage, die Antwort besteht aus ein paar Zahlen oder einem schnellen Diagramm, und Genie erledigt das. Die andere Seite ist das, was dadurch freigesetzt wird. Ohne dieses Tool fragt jemand nach den zehn wichtigsten Kunden basierend auf einer bestimmten Kennzahl. Ein Analyst nimmt das auf, klärt die Frage, schreibt eine Abfrage und baut ein Dashboard, das unweigerlich aufwendiger wird als nötig. Dieser Zyklus ist langsam. In unserem US-Einzelhandelsgeschäft, das bei meinem Einstieg ein Greenfield-Projekt war, haben wir die Zielarchitektur vom ersten Tag an aufgebaut. Dort wird Genie von Anfang an genutzt, was wahrscheinlich Hunderte von Stunden für den Bau von Dashboards eingespart hat, die nach der ersten Nutzung ohnehin in Vergessenheit geraten wären.
Mein Kollege hat ein Konzept, das er „Howden Intelligence Layer“ nennt: eine dünne Schicht, die Ihre Frage an den richtigen Service weiterleitet. Einige Fragen gehen an ein allgemeines Modell für Recherchen oder E-Mails. Andere sind Genie-Fragen, weil die Antwort in unseren verwalteten Daten liegt. Dem Nutzer sollte es völlig egal sein, woher sie kommt.
Aly: Wenn Sie einer Führungskraft auf C-Level, die ihre Daten- und AI-Initiativen skalieren möchte, einen einzigen Rat geben könnten, welcher wäre das?
Barry: Erst langsam, um dann schnell zu sein. Nicht zu langsam, aber entwerfen Sie es von Anfang an richtig. Lassen Sie sich von Ihrem Plattformpartner beim Entwurf der Architektur helfen, denn ich habe zu viele Architekten erlebt, die Altlasten aus früheren Projekten mitbringen.
Binden Sie die Verantwortlichen für Prozess- und Agenten-Workflows in Ihrem Unternehmen frühzeitig ein. Wir werden Daten für Agenten bereitstellen, die sie im gesamten Unternehmen verteilen, und das erfordert eine andere Design-Mentalität. Und fangen Sie an, in Datenservices zu denken, nicht nur in Datenprodukten.
Bei Barrys Argument geht es nicht um Howden. Es geht um die Designentscheidungen, vor denen die meisten Unternehmen stehen. Das Produktmodell, das in die Ära der Dashboards passte, ist nicht das Modell, das in eine agentenbasierte Ära passt. Die nachgelagerte Abstimmungsarbeit wird zu einer dauerhaften Belastung, wenn die Taxonomie nicht bereits vorgelagert kodifiziert wird. Die Aktualitätsmetrik, auf die die meisten Teams optimieren, ist nicht die Metrik, die für das Unternehmen wirklich zählt – es ist die Erkenntnisverzögerung.
Das Tempo, mit dem Howden Akquisitionen tätigt, macht diese Kompromisse schneller sichtbar als anderswo. Aber diese Kompromisse betreffen nicht nur Howden. Sie kommen auf jedes Unternehmen zu, das Daten für AI-Agenten bereitstellen möchte. F ührungskräfte, die ihre Systeme schon jetzt auf dieses Nutzungsmuster auslegen, müssen sie später nicht neu konzipieren.
Planen Sie für das Tempo, das Sie anstreben, nicht für das Tempo, in dem Sie sich heute befinden.
Um zu erfahren, wie mehr als 25 Branchenexperten den Weg für eine erfolgreiche AI-Bereitstellung ebnen, lesen Sie den Bericht "Making AI Deliver" von Economist Enterprise, der mit Unterstützung von Databricks erstellt wurde.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.