8Von einer BI-Landschaft zum Data & Analytics-Ökosystem
Michael Zimmer · Benjamin Diemann · Andreas Holzhammer
Data Science und künstliche Intelligenz (KI) gewinnen in Unternehmen stark an Bedeutung. Der Schwerpunkt liegt hier meist auf der Identifikation relevanter Anwendungsfälle und der Durchführung von ersten Proof of Values. Die zugrunde liegende Datenbasis wird in diesen frühen Phasen meist noch nicht betrachtet. Dies ist insofern kritisch, als dass Data Science und KI nur mit einer geeigneten Datenarchitektur erfolgreich durchgeführt werden können. So müssen zum Beispiel einerseits die richtigen Daten für die Analyse vorliegen, andererseits benötigen die Unternehmen Freigaben zur Nutzung der Daten durch die Kunden oder Konzepte zur Durchführung einer Data Science auf Basis anonymisierter Daten.
Im vorliegenden Beitrag werden Komponenten analytischer Ökosysteme vorgestellt und eine Referenzarchitektur eingeführt. Außerdem wird auch auf Agilität und Industrialisierung von Data Science eingegangen.
8.1Einleitung
In den letzten Jahren haben sich innerhalb der Datenarchitekturen von Unternehmen aufgrund neuer Technologien und Methoden grundlegende Paradigmenwechsel ergeben. In der Vergangenheit hatten Datenarchitekturen unter dem Schlagwort Data Warehouse (DWH)1 ihren Fokus häufig auf der Konsolidierung unternehmensweiter Daten. Für das Reporting wurden Daten täglich bis quartalsweise aufbereitet und aggregiert vorgehalten. Operatives Reporting auf Basis von Rohdaten war mithilfe eines Operational Data Store2 zwar möglich, in der Praxis aber nicht weit verbreitet. Durch die Etablierung von Big-Data-Technologien – bei denen eine Vielzahl an unterschiedlichen strukturierten und unstrukturierten Datenquellen (Variety) angebunden sind und große Datenmengen (Volume) schnell verarbeitet werden (Velocity) – hat sich das Verhalten von Unternehmen grundlegend verändert. Lag bei DWHs wegen hoher Speicherkosten der Fokus auf der Ablage und Verarbeitung einer relativ geringen Anzahl relevanter Daten, so können Unternehmen durch Big-Data-Technologien ihre Rohdaten zu geringen Kosten in einem Data Lake auf Vorrat ablegen. Dadurch können produzierende Unternehmen ihre operativen Produktionsdaten ganzheitlich erfassen und mit den dispositiven Systemen abgleichen (vgl. [Zarinac 2016, S. 131 ff.]). Banken, Versicherungen oder Telekommunikationsanbieter können wiederum eine 360-Grad-Kundensicht erstellen und Social-Media-Informationen oder Informationen aus den eigenen Telefonnetzen zusätzlich auswerten (vgl. [Neuhaus & Zimmer 2016]). Durch diese neuen Datenquellen ergeben sich für Unternehmen natürlich auch neue Anwendungsfälle. So können produzierende Unternehmen ihre Produktionsketten in Echtzeit in besserer Qualität steuern als bisher. Versicherungen können detaillierte Produkte für ihre Kunden anbieten und Telekommunikationsanbieter steuern auf Basis dieser Daten beispielsweise ihr Vertriebsnetz (vgl. [Zimmer 2015, S. 132 ff.]). Gemein haben all diese Fälle, dass sie neben einer fundierten Datenbasis in guter Qualität auch analytische Verfahren und Data Science benötigen, um neue Anwendungsfälle zu ermöglichen. Nur mit geeigneten Datenarchitekturen als Grundlage können Unternehmen zukünftig Data Science3 und KI-basierte Anwendungsfälle abbilden. Wie sieht eine solche Datenarchitektur aber aus?
8.2Komponenten analytischer Ökosysteme
Im Gegensatz zu rein DWH-basierten Architekturen sind moderne analytische Ökosysteme nicht mehr nach einer sequenziell zu durchlaufenden Struktur (Staging, DWH, Data Mart) strukturiert, sondern ermöglichen Absprünge zwischen den Ebenen. So ist es in hybriden Architekturen üblich, speziell ausgebildeten Analysts oder Data Scientists bereits die Rohdaten im Data Lake für Analysen zur Verfügung zu stellen. Dies ist beispielsweise erforderlich, um Modelle auf der Grundlage von großen Datenmengen zu entwerfen oder die Agilität der Datenarchitektur durch das Schema-on-Read-Prinzip zu erhöhen (vgl. [Zarinac 2016]). So ist nur durch eine übergreifende Zusammenführung von Daten in einem Layer, z.B. aus dem Data Lake, dem DWH oder den operativen Systemen, ein Data Scientist in der Lage, die an ihn gestellten Fragestellungen zeitnah zu beantworten. Absprünge in andere Layer, die im DWH-Umfeld als Bypässe bezeichnet wurden, sind mittlerweile bewusste Entscheidungen für mehr Agilität und entsprechen einer durch die Data & Analytics Governance geförderten Regel (vgl. [Trahasch & Zimmer 2018; Zimmer 2015]).
Generell lassen sich Operational Systems, Data-Management-Plattformen, Event Stream Processing, Batch Processing, Data Lake, DWH, Analytics Lab, ein Output Service Layer sowie Komponenten zum Informationszugriff unterscheiden [Haneke et al. 2018, S. 20] (vgl. Abb. 8–1).
Bei Operational Systems handelt es sich um klassische operative Systeme wie SAP R3 in der Produktion oder Versicherungssysteme wie Guidewire. Neuere Generationen dieser Systeme ermöglichen zunehmend auch dispositive Auswertungen. So bietet SAP S4/HANA die Kombination von dispositiven und operativen Daten in einer Plattform.
Bei sogenannten Data-Management-Plattformen handelt es sich um keine Extraktions-Transformations-Laden(ETL)-Werkzeuge, sondern um integrierte Lösungen zur Zusammenführung von operativen Datenquellen wie z.B. Web oder Sensordaten. Hier können mithilfe vorgefertigter Datenmodelle externe Daten schnell und einfach ohne komplexe ETL-Prozesse angebunden werden.
Abb. 8–1Analytisches Ökosystem, ein Ordnungsrahmen [Haneke et al. 2016, S. 20]
Batch Processing beschreibt die zyklische Verarbeitung von Daten, Event Stream Processing hingegen die eventgesteuerte Verarbeitung von Daten in Echtzeit.
Das DWH als ehemaliger Kern der dispositiven Hub-and-Spoke-Datenarchitektur stellt auch heute noch einen Single Point of Truth für harmonisierte und qualitätsgeprüfte Daten dar. Allerdings ist anzumerken, dass moderne Hub-and Spoke-Architekturen auch Big-Data-Technologien einsetzen.
Im Gegensatz zum DWH liegen die Daten im Data Lake4 eher in Rohform vor. Vorteile eines Lake sind die schnelle Verfügbarkeit von Daten sowie die großen Datenmengen. In Bezug auf Hub-and-Spoke ist anzumerken, dass dieser Ansatz auch ohne ein DWH mithilfe von Big-Data-Technologien abgebildet werden kann.
Durch ein Analytics Lab werden die Data Scientists dazu befähigt, eigenständig Analysen durchzuführen, Empfehlungen (sogenannte Recommender) zu entwickeln und letztlich analytische Modelle auf den unterschiedlichen Datenquellen zu erstellen. In den letzten Jahren hat sich gezeigt, dass auch hier Methoden der Softwareentwicklung mit zentralen Repositories, modularem Aufbau und Objektorientierung zielführend sind. Gerade für eine spätere Industrialisierung sind diese Methoden essenziell. So haben viele Unternehmen in der Vergangenheit manuell entwickelte Data-Science-Lösungen produktiv gesetzt und können diese mittlerweile nicht mehr warten.
Bei einem Output Service Layer (OSL) handelt es sich um eine Zwischenschicht. Sie ermöglicht als Service Bus einen zentral gesteuerten Aufruf der analytischen Kernsysteme. Eine solche Middleware kann dabei helfen, eine Vielzahl unterschiedlicher Touchpoints für Echtzeitentscheidungen standardisiert anzubinden und dabei nicht mit jedem System eigene Serviceverträge abschließen zu müssen.
Der Informationszugriff für Endanwender erfolgt durch Enterprise Applications, z.B. Vertriebssysteme, Reporting und Dashboards, z.B. klassische Managementreports, Visual Analytics und Storytelling, beispielsweise grafisch aufbereitete Berichte und visuell geführte Dramaturgien, Robotics, dazu gehören Chatbots, die im Rahmen der Prozessautomatisierung eigenständig auf Daten zugreifen, sowie Cognitive und Data Science.
8.3Vom Reporting zur industrialisierten Data Science
Stand bei DWH-basierten Architekturen die zyklische Bereitstellung von Reports an eine Vielzahl unterschiedlicher Adressaten (z.B. Management, Außendienst oder Vertrieb) im Fokus, so ist in heutigen Data & Analytics-Architekturen auch die Bereitstellung von Echtzeitentscheidungen über verschiedene Kanäle (wie Webpage, Mobile App oder Interfaces in Fahrzeugen) und die Anbindung neuer und innovativer Analytics-Werkzeuge im Fokus. Bei der Betrachtung des analytischen Ökosystems lassen sich generell drei Arten von analytischen Anwendungen mit zum Teil grundlegend unterschiedlichen Eigenschaften unterscheiden:
- Beim klassischen Reporting werden auf Grundlage spezifisch aufbereiteter
- Daten vorhersehbare und zyklische Informationsbedarfe durch Standardreports und Dashboards abgebildet. Die Entwicklung ist hierbei meist zentral in der IT gebündelt. Im Einsatz sind hier Standardwerkzeuge, die teilweise auch Self-Service Reporting auf bestehenden Daten ermöglichen (vgl. [Zimmer 2015; Trahasch & Zimmer 2015]).
- Bei Ad-hoc-Data-Science werden die im analytischen Ökosystem enthaltenen Daten für die Ad-hoc-Erstellung analytischer Anwendungen genutzt. Hierbei werden meist innovative und nur zum Teil standardisierte Werkzeuge eingesetzt. Essenziell ist hier die eigenständige Zusammenführung der Daten im Analytic Lab.
- Bei industrialisierter Data Science werden die Ad-hoc-Anwendungen übernommen und in eine professionelle und wartbare Lösung überführt. Ziel ist hier eine agile Data Science in Anlehnung an die Definition von BI-Agilität durch Zimmer (vgl. [Zimmer 2015; Trahasch & Zimmer 2015]).
In Tabelle 8–1 sind die Eigenschaften von klassischem Reporting, Ad-hoc-Data-Science und industrialisierter Data Science dargestellt.
Tab. 8–1Unterscheidung zwischen klassischem Reporting, Ad-hoc-Data-Science und industrialisierter Data Science (in Anlehnung an [Diemann 2017])
Vergleicht man diese Arbeitsweisen mit den Eigenschaften der Architekturansätze zur Förderung von BI-Agilität nach Zimmer, so wird sichtbar, dass die Arbeitsweise von Ad-hoc-Data-Science mit der einer unüberwachten Sandbox übereinstimmt.5 Beide haben gemeinsam, dass auf Basis einer Art Spielweise neue Anwendungsfälle einmalig erprobt werden und der Fachbereich in die Lage versetzt wird, eigenständig zu arbeiten. Standardisierung, Wiederverwendung und Übergabe an einen professionellen Betrieb sind allerdings nicht im Fokus.
Bei industrialisierter Data Science ist wiederum eine Tendenz zu einem serviceorientierten Ansatz mit werkzeuggestützten Sandboxes erkennbar. Bei diesem Ansatz werden »standardisierte Services […] mit beaufsichtigten und […] betreuten Sandboxes kombiniert« [Trahasch & Zimmer 2015, S. 108]. Dadurch werden hohe Freiheitsgrade unterstützt und gleichzeitig ein industrialisierter und standardisierter Betrieb mit einfacher Wartung ermöglicht. Dieses Vorgehen ist auch konform mit Verfahren wie Self-Service-Data-Preparation. Die Gemeinsamkeiten zwischen agiler BI und Agilität im Zuge von Data Science ist nicht verwunderlich. Dies gilt insbesondere, da die den Architekturansätzen nach Zimmer zugrunde liegenden Fallstudien auch die Arbeitsweise von Versicherungsaktuaren abbilden. Die Arbeitsweise dieser Berufsgruppe kann mit der eines Data Scientists gleichgesetzt werden (vgl. [Wiebusch & Zimmer 2017]).
Sieht man den Weg von klassischem Reporting über Ad-hoc-Data-Science zu industrialisierter Data Science als Evolutionspfad, so lassen sich auch hier Gemeinsamkeiten zu den Architekturansätzen aufzeigen. Im Unternehmenskontext lässt sich dieser Pfad dadurch erklären, dass Unternehmen zuerst Erfahrungen mit Big Data und Data Science sammeln müssen, bevor sie sich im Anschluss mit der Industrialisierung beschäftigen. Durch die zunehmende Verbreitung von Data Science in unterschiedlichen Unternehmensbereichen gewinnt die Wartung und Weiterentwicklung der modellbasierten analytischen Lösungen vermehrt an Bedeutung. Für industrialisierte Data Science wird allerdings eine neue Art der Data Science benötigt. Ist bei Ad-hoc-Data-Science künstlerisches und exploratives Schaffen und die Nutzung der besten Methoden gefordert, so ist im Zuge einer effizienten und effektiven Data Science zunehmend die Wiederverwendung und kostengünstige Weiterentwicklung notwendig. Dies widerspricht aber häufig dem Ansatz eines freigeistigen Künstlers. Vielmehr sind hier Themen wie Modularisierung, DevOps oder die zentrale Ablage der Modelle und zusätzliche Entscheidungsregeln in Repositories von großer Bedeutung (vgl. [Wiebusch & Zimmer 2017]).
Vor dem Hintergrund der starken Verbreitung von Data Science in Unternehmen und der daraus resultierenden steigenden Relevanz von – durch analytische Modelle unterstützten – Anwendungsfällen gewinnt auch eine kosteneffiziente Wartung und Weiterentwicklung im Sinne einer industrialisierten Data Science an Bedeutung. Um zu verdeutlichen, welche Anwendungen eine industrialisierte Data Science erfordern, lassen sich die Dimensionen der Modell- und Datenaufbereitungskomplexität heranziehen und stark vereinfacht die folgenden vier Szenarien ableiten:
- Stabile und sich kaum verändernde Daten und Modelle (vgl. 1 in Abb. 8–2)
- Sich regelmäßig verändernde Modelle und stabile Daten (vgl. 2 in Abb. 8–2)
- Sich regelmäßig verändernde Daten und stabile Modelle (vgl. 3 in Abb. 8–2)
- Stark volatile Modelle und Daten (vgl. 4 in Abb. 8–2)
Abb. 8–2Komplexität von Modell und Datenaufbereitung [Haneke et al. 2018, S. 23]
Ist bei einfachen Modellen mit geringen Datenänderungen noch eine Entwicklung mit manuellen Prozessen und daraus resultierenden großen manuellen Aufwänden ausreichend, so ist bei sich häufig ändernden modellgestützten Anwendungen eine industrialisierte Data Science erforderlich. Hier sind die bereits erwähnten zentralen Repositories und eine möglichst automatische Verarbeitung essenziell. Im DWH-Bereich haben sich in ähnlichen Anwendungsfällen unternehmensspezifische Frameworks etabliert, bei denen durch Modularisierung, Versionierung und Parametrisierung eine einfache Wartung von ETL-Prozessen und automatische Deployments ermöglicht wurden (vgl. [Zimmer 2015]). Die gleichen Prinzipien, die im DWH-Umfeld verwendet wurden, lassen sich auch auf Deployments von analytischen Modellen übertragen. Durch die steigende Komplexität und steigende Änderungshäufigkeit von Modellen sowie der zugrunde liegenden Datenquellen wird auch im Bereich der Data Science eine Modularisierung und Parametrisierung erforderlich. Die häufig händisch programmierten Modelle sind oft nicht auf regelmäßige Anpassung ausgelegt und erfordern in der Wartung sowie Weiterentwicklung hohe manuelle Aufwände.6 So sind unter anderem oft wichtige Abfragen oder Steuerungsparameter fest im Modell codiert und nicht in Repositories wie etwa Lookup-Tabellen abgelegt. Gerade bei der Erweiterung eines Modells ist es aber ein entscheidender Unterschied, ob der Sourcecode händisch angepasst werden muss oder ob nur eine Lookup-Tabelle für ein oder mehrere Modelle zentral gepflegt und versioniert werden kann. Neben Frameworks bieten hier auch professionelle Analytics-Werkzeuge mit Modellrepositories und definierten Deployment-Verfahren Lösungsansätze. Bei diesen kommt die notwendige Funktionalität bereits Out-of-the-Box und muss nur noch an die Bedürfnisse des Unternehmens angepasst werden.7 So können im Modellrepository abgelegte Modelle mit einem revisionssicheren Prozess produktiv gesetzt und automatisiert überwacht und erneut trainiert werden.
8.4Data Science und Agilität
Beim Betrachten der Anforderungen an Data & Analytics-Ökosysteme wird sichtbar, dass Agilität im Sinne von Zimmer und Trahasch8 vermehrt als Wettbewerbsvorteil im Data-Science-Bereich an Bedeutung gewinnt. Gerade in Unternehmen mit digitalen Kundentouchpoints spielen von Data Scientists entworfene Modelle und Regeln im Verkaufsprozess eine entscheidende Rolle. So kann beispielsweise durch personalisierte Services die Customer Experience verbessert und Upselling betrieben werden (vgl. [Kiani-Kreß 2017]). Um diese kundenzentrierten Anwendungsfälle aber langfristig im Unternehmen zu etablieren und weiterzuentwickeln, sind Architekturen mit hoher Agilität erforderlich. Hier sind zentral und professionell betriebene Infrastrukturen mit revisionssicheren und kurzen Deployment-Zyklen zielführend (vgl. [Beierschoder & Zimmer 2016; Trahasch & Zimmer 2015; Zimmer 2015]).
8.5Entwicklungs-, Test- und Produktionsumgebungen für Data Science
Im vorherigen Abschnitt wurde stark vereinfacht ein Einblick in Data & Analytics-Ökosysteme gegeben. Hierbei wurde vernachlässigt, dass ein solches Ökosystem nicht nur eine Umgebung beinhaltet, sondern Entwicklung, Test und Produktion subsumiert. Nachfolgend wird anhand eines einfachen Beispiels aufgezeigt, welche Herausforderungen bei der Produktivsetzung analytischer Modelle bestehen.
Abb. 8–3Data-Science-Entwicklung und Produktivsetzung
Kern von Abbildung 8–3 ist ein vereinfachter Data-Science-Prozess, der von der Feature-Entwicklung über das Training eines Modells und die Produktivsetzung bis hin zur Auslieferung der Scores an die Verbraucher reicht. Auf den ersten Blick erscheint dieser Prozess recht einfach. Ergänzt man hier aber die Entwicklungs-, Test- und Produktionsumgebungen, die aufgrund von Datenschutzanforderungen oder Normen von Unternehmen gefordert werden, so wird das Gesamtbild komplizierter.9
In der Regel werden auf einer Entwicklungsumgebung neue Anwendungen, wie ein DWH zur Datenhaltung oder Reports zur Entscheidungsunterstützung, umgesetzt (vgl. hierzu auch Abb. 8–4). Hier sind meist keine produktiven Daten im Einsatz. Es wird vielmehr mit synthetischen oder anonymisierten Daten entwickelt. Nur auf gesonderte Freigabe können produktive Daten in Ausnahmefällen zugespielt werden.
An Acceptance- und Produktionsumgebungen sind in der Regel produktive Daten angebunden. Hier können Anwender des Unternehmens Daten testen oder die Anwendungen produktiv nutzen. Eine Entwicklung ist auf diesen Umgebungen nicht vorgesehen.
Wie wirken sich solche Umgebungen aber auf Data Science aus? Data Science erfordert durch die explorative Arbeitsweise (vgl. Kap. 5 und 9) eine möglichst große Menge an Maschinen- oder Kundendaten, um geeignete Scores und Entscheidungen zu ermöglichen. Die in einer Entwicklungsumgebung vorgehaltenen Daten reichen häufig nicht aus und die produktiven Daten dürfen hier nicht verwendet werden. Um dieses Problem zu lösen, haben Unternehmen zwei Ansätze etabliert. Beim ersten Ansatz handelt es sich um die vollständige Anonymisierung der produktiven Daten zum Einsatz innerhalb der Entwicklung. Beim zweiten Ansatz erfolgt in Anlehnung an Self-Service Reporting (vgl. [Zimmer 2015]) die Nutzung von produktiven Daten. Beide Ansätze haben aber erhebliche Problemfelder. In einigen Anwendungsfällen sind beispielsweise anonymisierte Daten nicht mehr ausreichend, um ein Modell für den produktiven Einsatz zu trainieren. Der Zugriff auf produktive Daten ist häufig aber durch Datenschutzverordnungen nicht erlaubt.
Entwicklung – Modelle/PreProd |
Produktion |
|||
|
|
|
Abb. 8–4Pragmatischer Ansatz zum Umgang mit Umgebungen aus der Praxis
Wie lösen Unternehmen dieses Spannungsfeld? In der Praxis verbreiten sich derzeit Ansätze, in denen die Entwicklung der notwendigen Datengrundlagen von der Entwicklung der analytischen Modelle getrennt wird (vgl. Abb. 8–4). So werden in einer Datenentwicklungsumgebung von Data Engineers häufig analytische Tabellen auf Basis künstlicher Daten erstellt. Hierdurch wird sichergestellt, dass gesetzliche Rahmenbedingungen bei der Entwicklung von Datenarchitekturen eingehalten werden. In einer Modellentwicklungsumgebung werden hingegen auf Basis von Echtdaten analytische Modelle entwickelt und trainiert. Data Scientists können hier explorativ arbeiten und neue Modelle erstellen. Es ist allerdings anzumerken, dass in diesem Umfeld komplexe Berechtigungsstrukturen auf Daten- und Werkzeugebene erforderlich sind. Nur so können Datenschutzanforderungen erfüllt werden.
Um den Data Scientists hohe Freiheitsgrade bei der Modellentwicklung zu ermöglichen, ist es auch zielführend, Deployment-Verfahren von Modellen auf bereits existierenden Daten in Produktion zu ermöglichen. Solche Self-Service-Deployments erfordern aber innerhalb der IT häufig Überzeugungsarbeit. Dies gilt insbesondere, da Deployment als eine Kernaufgabe der IT verstanden wird. Hier ist mit der IT zu klären, dass die Data Scientists nur neue Versionen von Modellen eigenständig in Produktion bringen können und keine Änderungen an der Funktionalität durchführen. Der Fachbereich deployt hier auch keine neuen Programme, sondern ergänzt bestehende. Dadurch wird das Ergebnis respektive die Güte eines Modells besser, die Funktionalität verändert sich dadurch aber nicht. Sind Änderungen an den Daten oder neue Datenquellen notwendig, ist auch in diesem Fall eine Entwicklung mit der IT erforderlich.
8.6Vom Spielplatz für Innovation zur Serienfertigung
Nachdem im vorherigen Abschnitt erklärt wurde, wie das Zusammenspiel zwischen Entwicklung, Test und Produktion für Daten und analytische Modelle erfolgen kann, wird nun die Implementierung einer Serienentwicklung von KI-Anwendungen vorgestellt. Mit dieser können neue Use Cases flexibel und agil entwickelt, standardisiert in Produktion übergeben und regelmäßig im Betrieb weiterentwickelt werden. Hierfür haben sich Ansätze etabliert, die die Agilität eines »Spielplatzes für Innovation« mit den Eigenschaften einer Serienfertigung kombinieren. Mithilfe dieser Ansätze wird versucht, Automatisierung, kontinuierliche Verbesserung, Sicherstellung der Governance und Wartbarkeit zu ermöglichen. In Abbildung 8–5 sind die Eigenschaften vom Spielplatz bis zur Serienfertigung kurz dargestellt.
Abb. 8–5Vom Spielplatz zur Serienfertigung
Generell besteht eine Serienfertigung aus Entwicklung, Continuous Integration, Datenhaltung und Produktion (vgl. Abb. 8–6). In der Entwicklung erfolgen eine erste Datenvorbereitung und Modellierung sowie die Umsetzung erster Entscheidungslogiken, um einen Use Case zu verproben (#1). Um sicherzustellen, dass nicht jede Anwendung neue Datenstrukturen und analytische Modelle erzeugt, ist eine enge Verknüpfung mit der Datenhaltung (#2) erforderlich. Wurde der Use Case erfolgreich verprobt, können das zugehörige Modell10 und die Datengrundlage mithilfe von Continuous Integration in die Produktion übertragen werden (#3). Wichtig ist hierbei, dass die zugrunde liegenden Strukturen in Entwicklung und Produktion für Datenvorbereitung, Modellierung und Entscheidungslogik identisch sind und keine manuellen Anpassungen erfordern (#4). Durch einen solchen Ansatz wird die schnelle Zusammenführung von Daten aus unterschiedlichen Quellen, das Erstellen, Trainieren und flexible Verändern in der Entwicklung gefördert und gleichzeitig nicht wartbare Leuchttürme auf Insellösungen durch Standards verhindert. Hierzu sind aber klare Regelstrukturen zu definieren und durch geeignete Architekturkomponenten zu ergänzen.
Abb. 8–6Serienfertigung
Konkret bedeutet dies, dass Daten in Entwicklung im Self-Service aus unterschiedlichen Quellen zusammengeführt werden, um modellbasierte Auswertungen zu ermöglichen. Hierbei ist es wichtig, die Datenaufbereitung an zentraler Stelle zu beschreiben, um diese auch innerhalb der Produktion auf dieser Basis mit standardisierten Werkzeugen schnell und einfach umzusetzen bzw. direkt in produktive Prozesse einzubinden.
Dasselbe Prinzip gilt auch für die Modellentwicklung. Hier werden analytische Modelle erstellt und trainiert. Sind die Ergebnisse wie gewünscht, werden die Modelle in einem zentralen Modellkatalog abgelegt. Wichtig ist hier, dass zwischen Modell und benötigten Daten eine eindeutige Beziehung (inkl. Historie) vorhanden ist, um Rollbacks, Weiterentwicklung und Fehlerbehebungen zu ermöglichen. Neben Daten und Modell sind auch noch Entscheidungsregeln, sogenannte Business Rules, von Relevanz. Diese werden wie die Modelle ebenfalls in einem zentralen Repository abgelegt und können als Vorbedingung unterschiedlicher Modelle angewendet werden. Derzeit zeigt sich, dass viele Unternehmen zwar Data-Science-Anwendungen in Produktion haben, diese aber nicht für eine Weiterentwicklung ausgelegt sind und tendenziell eher Laboranwendungen entsprechen. Eine Serienfertigung ist für viele Unternehmen meist noch Zukunftsmusik.
Wie sieht eine Entwicklung in einem solchen Umfeld aus? Um dies zu veranschaulichen, wird nachfolgend der Prozess anhand eines einfachen Beispiels vorgestellt.
8.7Anwendungsbeispiel
Im gesättigten Schadenversicherungsmarkt (z.B. Kraftfahrtversicherung) verfolgen Versicherungen das Ziel, trotz eines hohen Preisdrucks zu auskömmlichen Preisen Verträge abzuschließen. Wie in anderen Branchen auch erfordert die Gewinnung eines Neukunden einen initialen Invest. Um hier langfristig erfolgreich zu sein und Kunden gegebenenfalls auch in eine Gewinnzone zu entwickeln, ist es erforderlich, die Expertise von Versicherungsmathematikern (Aktuaren) und Data Scientists mit Machine-Learning-Expertise zusammenzubringen. Nur durch die Kombination von branchenspezifischem Wissen mit technischer Expertise können Anwendungen erfolgreich umgesetzt werden und Themen wie Kundenwert, Beitragsoptimierung oder Schadenrisiken adressiert werden.11
Abb. 8–7Exemplarisches Beispiel
Konkret werden zur Berechnung eines risikogerechten Versicherungstarifs zunächst die erfassten Daten zu bestehenden Verträgen und zu den eingetretenen Schäden benötigt. Ebenfalls sind Kontextdaten zum Beschreiben individueller Risiken erforderlich. Dazu zählen beispielsweise für die Kraftfahrtversicherung zentral verfügbare Statistiken des Gesamtverbandes der Deutschen Versicherungswirtschaft, soziodemografische Daten und weitere die Risiken beschreibende Daten. Hier handelt es sich unter anderem um die Leistung oder das Gewicht eines zu versichernden Fahrzeugs (vgl. Abb. 8–7, hellgrau).
In der Regel wird aus diesen Daten mit bewährten erklärbaren Modellierungstechniken (Generalized Linear Models oder Generalized Additive Models) ein risikogerechter Tarif entwickelt. In Marktsegmenten mit wenigen Verträgen ist ein solcher Tarif aufgrund der geringen Grundgesamtheit sehr ungenau, was letztlich im schlimmsten Fall zu einem für den Versicherer zu niedrigen Preis führen kann. In gut berechenbaren, aber hart umkämpften Marktsegmenten kann es hingegen vorkommen, dass auskömmliches Geschäft verloren geht, weil die Konkurrenz um wenige Euro billiger anbietet.
Daher gehen Versicherer dazu über, die Tarifstrukturen der Konkurrenz anhand einiger Beobachtungen vorherzusagen (Reverse Engineering). Die Tarifstrukturen sind komplex, die Menge der verwendeten Prädiktoren ist jeweils unbekannt. Mit Machine-Learning-Algorithmen wie Gradient Boosting kann das Reverse Engineering jedoch mit zufriedenstellender Genauigkeit gelingen (vgl. Abb. 8–7, dunkelgrau)
Zusammen mit den Erfahrungsdaten über abgegebene Angebote und erfolgte Abschlüsse (Quotierungsdaten) kann für jedes Risiko und jeden möglichen Angebotspreis eine Abschlusswahrscheinlichkeit bestimmt werden.
Der individuell optimale Angebotspreis ist jener, der den Erwartungsnutzen optimiert – das ist das Produkt aus Abschlusswahrscheinlichkeit, erzielter Marge und daraus abgeleitetem Deckungsbeitrag (Angebotspreis minus Risikoprämie). Eine Darstellung findet sich in Abbildung 8–8.
Abb. 8–8Zusammenhang zwischen Preis und Abschluss
Der tatsächlich angebotene Preis entsteht aber erst nach Anwendung einer fachlich und strategisch bedingten Entscheidungslogik. So kommen Preisuntergrenzen zur Anwendung, vertrieblich vorgegebene Rabatte oder etwa die fachlich anreizkompatible Vorgabe, dass ein Vertrag immer günstiger werden soll, je länger kein Schaden bezahlt wurde.
Schon die Verkettung mehrerer Datenquellen, mehrerer statistischer Modelle und einer komplexen Entscheidungslogik gebieten, das Testen, die Produktivsetzung und die Aktualisierung der Modelle im Sinne der Abbildung 8–2 weitgehend zu automatisieren.12
Die Vielzahl der Versicherer, die im Jahreswechselgeschäft nahezu täglich ihre Preise ändern, sowie die sich stetig verändernden Schadenaufwände sowie regulatorische Vorgaben führen schließlich dazu, dass dynamisches Pricing ohne umfassende Industrialisierung der Data Science nicht möglich ist.
In Verbindung mit einem engmaschigen Monitoring kann es gelingen, nachhaltig profitable Preise zu erzielen und die Abschlusszahlen in Richtung einer optimalen Auslastung des Betriebs zu steuern.
Das hier beschriebene Beispiel lässt sich auch auf das in Abbildung 8–6 vorgestellte Vorgehen zur Serienfertigung übertragen. Konkret bedeutet dies für den Data Scientist, dass er mit den Fachexperten in der Entwicklung die notwendigen Daten integriert, fachlich modelliert und aufbereitet. Um die Anwendung in Zukunft erfolgreich in Produktion zu bringen, ist es bereits hier erforderlich, den Datenschutz mit einzubeziehen und Freigaben zur Nutzung zu erhalten. Zusätzlich sind IT-Richtlinien zur Dokumentation und Übergabe erforderlich (vgl. Kapitel 9). Nur dadurch können die Prozesse zur Datenintegration an eine standardisierte Produktion übergeben werden. Im Anschluss erfolgt in einem iterativen Prozess die Modellentwicklung und das Training, um die bereits beschriebenen Herausforderungen zufriedenstellend zu lösen. Ergeben sich neue notwendige Datenquellen, kann es sein, dass das Datenmodell und die benötigten Daten weiter ergänzt oder verändert werden müssen. Ist das Modell erfolgreich entwickelt und trainiert, wird die zentrale Datenhaltung angepasst, das analytische Modell dokumentiert und eine Verknüpfung zwischen Datenmodell und analytischem Modell in einem zentralen Repository abgelegt. Dies ist erforderlich, um einen Audit-Trail zu ermöglichen und das analytische Modell zukünftig warten und weiterentwickeln zu können.
Sind alle Vorgaben zur Übergabe eingehalten, kann das Modell und die zugrunde liegende Datenbasis in eine produktive Umgebung integriert werden. Das analytische Modell wird in regelmäßigen Zyklen in Produktion überprüft. Sollte es nicht mehr die gewünschten Ergebnisse liefern, wird der Entwicklungszyklus angestoßen. Hierfür kann die aktuelle Version des Modells, die Datengrundlage und die Verknüpfung in die Entwicklung geladen werden. Nach erfolgreichem Retraining oder Anpassung des Modells werden die Repositories gepflegt und die neue Version wird in Produktion übertragen. Durch Versions-IDs im Datenmodell kann sichergestellt werden, dass eine Nachvollziehbarkeit der Entscheidung für jeden Kunden gegeben ist.
8.8Fazit
Unternehmen stehen heute vor der Herausforderung, klassische Datenarchitekturen mit analytischen Methoden und Arbeitsweisen zusammenzuführen. Gab es in der Vergangenheit meist speziell erstellte analytische Data Marts als Teilmenge der DWH-Daten (vgl. [Zimmer 2015]), so ist heute die zentrale Bereitstellung aller Daten einer Data & Analytics-Architektur gefordert. Dies führt dazu, dass Data Science nicht rein methodisch betrachtet werden kann, sondern eine Integration in die Data- und Analytics Governance erfordert. So sind sowohl ganzheitliche Datenarchitekturen als auch geeignete Ablauf- und Aufbauorganisationen (siehe Kap. 9) zu definieren. Im Bereich der Architektur sind hier Bereitstellung der benötigten Daten, Datenschutz, aber auch Modellentwicklung sowie Industrialisierung wichtige Themen. Auf den ersten Blick neigen Data & Analytics-Entscheider dazu, hier neue Lösungen aufzubauen. Legt man aber bestehende Best Practices aus der Softwareentwicklung und der Business Intelligence zugrunde, so sind aktuelle Herausforderungen gut lösbar. Die grundlegenden Prinzipien verändern sich nicht vollständig, sie erweitern sich vielmehr nur durch eine größere Datenmenge und neue Werkzeuge des Zugriffs. Wichtig ist hier ein wie in Abbildung 8–5 und Abbildung 8–6 dargestelltes ganzheitliches Vorgehen. Die im Bereich der BI-Agilität vorgestellten Maßnahmen lassen sich auch auf Data Science adaptieren und helfen auch hier, wandlungsfähige Unternehmen im Wettbewerb zu fördern (vgl. [Zimmer 2015; Trahasch & Zimmer 2015]). Dies gilt insbesondere, da Daten und daraus abgeleitete Entscheidungen heute einen kritischen Erfolgsfaktor für Unternehmen darstellen.