Analytics und KI-Projekte skalieren
Raus aus der Sandbox
Foto: Elnur - shutterstock.com
Zum Einstieg ein Beispiel aus der Praxis: Eine europäische Bank will gezielt inaktive Kunden ansprechen und sie vor dem endgültigen Absprung bewahren. Konventionelle Methoden bleiben ergebnislos und die Kundenzahlen sinken. Die Lösung bringt ein Machine-Learning-Algorithmus. Er identifiziert Kunden, die mit hoher Wahrscheinlichkeit vor einem Wechsel zu einem Wettbewerber stehen und liefert Aufschluss über die Gründe, so dass reagiert werden kann. Das Ergebnis: Die Bank kann frühzeitig auf diese Kunden einwirken und reduziert so ihre Churn-Rate um 15 Prozent.
Solch eine Automatisierung datenbasierter Entscheidungen nimmt branchenübergreifend zu und gehört bald zum Alltag. Die meisten großen Organisationen haben bereits Projekte auf Basis künstlicher Intelligenz und Advanced AnalyticsAnalytics umgesetzt - immer mit dem Blick darauf, die eigene Organisation optimal auf die Anforderungen der datengetriebenen Zukunftswirtschaft auszurichten. Aber die Entwicklung von Anwendungsfällen ist nur ein erster Schritt, das Potenzial von künstlicher Intelligenz, komplexen Datenanalyse-Systemen etc. auszureizen. Im zweiten Schritt müssen die Projekte skaliert werden - und dafür ist es essenziell, eine technische Basis zu schaffen, die so eine Transformation möglich macht. Alles zu Analytics auf CIO.de
Raus aus der Sandbox, rein in die Produktion
Der Weg aus dem experimentellen Sandbox-Umfeld hin zu einem funktionierenden und in die Organisation fest eingebundenen Technology-Stack ist komplex. Basis, um diese Herausforderung zu bewältigen, ist eine von Anfang an strategisch ausgerichtete Datenarchitektur. Eine optimale Referenzarchitektur verteilt sich auf drei Säulen, die auf einem grundlegenden Data-Ingestion-Layer fußen:
Ein Data Warehouse, bei dem die Datenqualität und -konsistenz beim Einlesen sichergestellt wird (Stichwort: "schema on write"). Die Daten werden dabei im Data Warehouse vorsortiert und normalisiert, sodass sie für Nutzer einfacher zu verwenden sind.
Ein Data Lake, bei dem die extrahierten Daten erst bei Anfrage auf ihre Form geprüft und strukturiert werden ("schema on read"). Dies erlaubt, alle Daten in beliebiger Granularität zur Verfügung zu haben, wobei die nötige Übersetzungsarbeit dann aber immer individuell sichergestellt werden muss.
Real-Time Streaming (ebenfalls "schema on read"), wobei die Daten in Echtzeit analysiert werden können, was etwa beim industriellen Internet der Dinge enorm wichtig ist.
Das operative Modell der Organisation hat dabei einen großen Einfluss darauf, wie die Systeme genau eingesetzt werden. Wo es eher "wasserfallartige" Strukturen gibt, bei denen die IT die Planung übernimmt und die Fachseite nur noch begrenzte Anpassungsmöglichkeiten hat, bleibt das Data Warehouse oft im Zentrum. In agilen Umfeldern, in denen IT-Experten und andere Fachleute gemeinsam Probleme lösen, ist die Vollumfänglichkeit der Daten deutlich wichtiger und Data Lakes rücken in den Vordergrund.
Referenzarchitektur als Basis für Entwicklung
Organisationen, die sich an der obigen Referenzarchitektur orientieren, entwickeln sich besser: Zunächst ermöglicht Data-Warehouse-Offloading erhebliche Kosteneinsparungen bei Ressourcen und Lizenzen. Diese Kosteneffizienz stellt sich auch ein, wenn sich Organisationen von firmeneigener, aber ineffizienter Technologie verabschieden und stattdessen moderne Open-Source-Lösungen ins Spiel kommen. Neue Hadoop-Lösungen ermöglichen zuvor unmögliche Digitalprojekte und dank Streaming-Technologie wird eine deutlich kürzere Time-to-Market sichergestellt.
Dennoch: Eine solche digitale Transformation ist selbst für erfahrene Organisationen oftmals eine Herausforderung. Ein Reibungspunkt ist dabei, die Balance zwischen einem unternehmensweit einheitlichen Datenmodell auf der einen und völliger Flexibilität auf der anderen Seite zu finden.
Ein einheitliches - kanonisches - Datenmodell garantiert, dass überall innerhalb der Organisation Daten-Attribute nur einmal vergeben werden. Sollen sie geändert werden, ist dies entsprechend kompliziert. Das frisst Zeit und ist in einem agilen Kontext kaum umsetzbar. Ein Laissez-Fair-Approach, in dem jeder seine eigenen Datenstandards entwickeln kann, ist aber auch keine Lösung. Irgendwann müssen Daten doch zusammengeführt werden und das wäre durch unregulierte Standards erschwert.
Ein goldener Mittelweg dafür ist das sogenannte "Domain-driven Design". Dabei wird der fachliche Kontext der Daten und der beteiligten Stakeholder in den Fokus gerückt. Sprich: Es wird ein Kompromiss zwischen Agilität und Struktur geschaffen - so agil wie möglich und so strukturiert wie gerade nötig. Wie genau so etwas aussieht, muss immer individuell ausgearbeitet werden und hängt von der Unternehmensstrategie ab.
Skalierung sicherstellen
Ist erst einmal mit einer strategisch ausgerichteten Architektur eine feste Basis gelegt, können Digital-Projekte auch optimal skaliert werden. Ziel ist im ersten Schritt, eine sogenannte "Minimum Viable Architecture" aufzubauen. Also eine Architektur, die gerade so groß wie nötig ist, und die parallel zu den wachsenden Funktionalitäten ausgebaut wird.
Dies wird im Optimalfall mit einem innovativen Leuchtturmprojekt gekoppelt. So ein Projekt gibt klare, fachliche Anforderungen vor und präsentiert damit einen festen Kontext, in dem die nötigen Schritte vorangetrieben und wichtige Pain Points sichtbar gemacht werden können.
Schließlich ist es essenziell, diesen Prozess fachlich mit einer effektiven Data Governance zu begleiten. Es muss klar sein, wie Daten gekennzeichnet werden und welche Informationen wie verwendet werden dürfen, ohne gegen Gesetze und Regulierungen zu verstoßen. Dabei sollten auch die Menschen, die mit den Daten arbeiten, entsprechend aus- und weitergebildet werden, um Fehlerquellen - etwa beim Einpflegen von Daten - zu vermeiden