9Self-Service und Governance im Data-Science-Umfeld: der emanzipierte Anwender

Uwe Haneke · Michael Zimmer

»Data! Data! Data!« he cried impatiently.

»I can’t make bricks without clay!«

Sherlock Holmes in »A Scandal in Bohemia«

Self-Service ist schon seit vielen Jahren ein großes Versprechen im Bereich der Business Intelligence (BI) sowie von Data & Analytics. Einige Nutzer sehen darin Chancen und Möglichkeiten, um selbstständig, agil und unabhängig Datenanalysen durchführen und Berichte eigenständig gestalten zu können [Zimmer & Beierschoder 2018]. Andere wiederum, vornehmlich Unternehmensbereiche wie die IT, befürchten einen Wildwuchs, der das aufgebaute Berichtswesen kompromittieren kann und damit kontraproduktiv wirkt. Der vorliegende Beitrag stellt die Möglichkeiten und Anforderungen an Self-Service-Angebote im Kontext von Data Science dar, präsentiert ein Konzept für eine differenzierte Data & Analytics Governance und gibt Anstöße für mögliche Weiterentwicklungen.

9.1Einleitung

Hinsichtlich der Frage, wie viel Self-Service-Angebote den verschiedenen Fachabteilungen gemacht werden sollen und wie viel Autonomie im Bereich der Datenakquise, der Datenaufbereitung und der Datenverarbeitung man diesen zugestehen möchte, scheiden sich seit Langem die Geister. Während die Fachabteilungen immer mehr Möglichkeiten für ein eigenständiges Handeln einfordern, steht die IT diesen Forderungen häufig zögerlich gegenüber. Diese konträre Fachbereichs- und IT-Sicht spiegelt auch die Extreme zum Umgang mit BI-Agilität1 wider. Hier handelt es sich auf der einen Seite um das Zugestehen vollständiger Freiheit in dezentralen Einheiten und auf der anderen Seite um einen von der IT getriebenen autoritären und zentralen Ansatz [Trahasch & Zimmer 2015, S. 157 ff.].

Betrachtet man die Historie von Data & Analytics-Infrastrukturen, so wird sichtbar, dass bereits zu Beginn sogenannter Data-Warehouse(DWH)-basierter-Architekturen viele Anwendungen zur Managementunterstützung im Fachbereich angesiedelt waren und hohe Freiheitsgrade der Anwender ermöglichten. Problem dieser Insellösungen war, dass Daten und Funktionen redundant vorgehalten wurden und es keinen Single Point of Truth gab. Aus diesem Wildwuchs an Insellösungen erfolgten eine von der IT getriebene Zentralisierung und die Etablierung von unternehmensweiten DWH-Architekturen [Kemper et al. 2006, S. 15 f.].

Mit zunehmender Reife dieser zentralen und autoritären Anwendungen sowie steigender Erfahrung der Anwender wurden aber auch im DWH-Umfeld neue Anforderungen an kürzere Bereitstellungszyklen, Freiheiten zur Datenanalyse und Freiheiten zur Aufbereitung der Daten im Fachbereich formuliert. Lösungsansatz der IT war hier meist die Einführung von Sandboxes, in denen Fachbereiche je nach Ausrichtung Reporting, Analyse oder sogar Datenaufbereitung im Self-Service durchführen konnten (vgl. [Trahasch & Zimmer 2015, S. 99 f.]).

Vor diesem Hintergrund ist Self-Service im Data & Analytics-Bereich nichts Neues, sondern vielmehr ein über Jahre etablierter Ansatz. Selbst die Arbeitsweisen der Data Science wurden in einzelnen Unternehmensbereichen wie beispielsweise im Investmentbanking2 und im Aktuars-Bereich der Versicherung3 bereits vor mehr als zehn Jahren durch Self-Service unterstützt.

Zwei Entwicklungen tragen derzeit sicherlich dazu bei, dass Self-Service-Anwendungen im BI sowie im Umfeld von Data & Analytics stark nachgefragt werden und im Fokus stehen. Zum einen ist hier der Aspekt der Anwender selbst zu sehen. Diese verfügen in der Breite heute über deutlich bessere IT-Kompetenzen als noch vor 10–15 Jahren. Die Nutzer haben mittlerweile häufig Erfahrungen mit grafischen Benutzungsoberflächen, im Umgang mit Datenbanken und oftmals sogar im Bereich der Programmierung selbst. Daraus resultiert ein neues Selbstverständnis und Selbstbewusstsein der Nutzer, verbunden mit der Forderung nach mehr Selbstständigkeit und eigenem Handlungsspielraum. Man könnte hier von einer Generation von Nutzen sprechen, die sich zumindest teilweise von der Abhängigkeit der IT emanzipieren möchte, um zeitnäher und agiler reagieren und handeln zu können.4

Zum anderen erhalten Self-Service-Angebote und -Szenarien aber mit der zunehmenden Nutzung von Data Science aktuell einen neuen Schub. Im Mittelpunkt steht hierbei der Teilprozess der Datenaufbereitung (Data Preparation). Ist es bei Reporting-Lösungen ausreichend, zentral eine Datenhaltung bereitzustellen, aus der sich viele Anwender mit ihren Self-Service-Reports bedienen, erfordern Ad-hoc-Data-Science-Anfragen flexible und individuell erstellbare Datengrundlagen. Hier stellt die Datenbeschaffung nach wie vor einen wichtigen, vielfach noch immer unterschätzten Schritt im Rahmen der Data Science dar. Sind die Daten in geeigneter Granularität und Qualität vorhanden, können Data Scientists ihre Modelle anwenden und Nutzen für das Unternehmen stiften.

Neben der Frage der einzusetzenden Werkzeuge stehen auch organisatorische Fragen im Raum. Vor diesem Hintergrund wird in diesem Kapitel Self-Service im Kontext von Data & Analytics definiert, Data Preparation und ETL abgegrenzt sowie kurz in Themen der Data & Analytics Governance eingeführt.

9.2Self-Service-Angebote für Data & Analytics

Prinzipiell versteht man unter Self-Service im Bereich der Data & Analytics den Ansatz, anwendergesteuerte Datenanalysen und Berichterstellungen in Fachabteilungen weitgehend unabhängig von der IT durch eigenständigen Zugriff auf die vorhandene Informationsbasis durchführen zu lassen. Die Voraussetzungen für den Zugriff auf die Daten und das Erstellen der entsprechenden Schnittstellen liegen dabei im Verantwortungsbereich der IT. Über entsprechende Werkzeuge und Rechte ist es dem Anwender nun möglich, selbstständig Berichte und Auswertungen zu erstellen oder zu modifizieren, ohne dass die IT eingeschaltet werden muss. Dies entlastet nicht nur direkt die IT, sondern führt darüber hinaus zu einer deutlichen Verbesserung der Agilität (vgl. [Trahasch & Zimmer 2015, S. 99 ff.]).

In Anlehnung an [Haneke et al. 2018] lassen sich drei Anwendungsklassen für Self-Service unterscheiden (vgl. Tab. 8–1, S. 148). Hierbei handelt es sich um:

Wie bereits erwähnt haben sich in diesem Umfeld Sandbox-Ansätze innerhalb der Unternehmen etabliert. Sind bei klassischem Reporting eher unüberwachte Sandboxes6 im Einsatz, so werden bei Ad-hoc-Analysen und industrialisierter Data Science eher überwachte Sandboxes eingesetzt.7

Diese Einschätzung wird auch von BARC, dem Business Application Research Center, geteilt. So ist Self-Service-BI für BARC nicht nur einer der wichtigsten Trends im Bereich von Data & Analytics, sondern gehört in vielen Unternehmen bereits heute zur Realität. BARC geht davon aus, dass es sich bei 80% der Anwender um Standardnutzer handelt, die nur einen geringen Funktionalitätsumfang benötigen und sich auf der gesicherten Basis eines Single Point of Truth bewegen (vgl. Abb. 9–1). Im Vordergrund stehen hier das einfache Modifizieren von vorhandenen Berichten oder Dashboards und das selbstständige Durchführen von einfachen Auswertungen.8 Bereits auf diese Weise lassen sich signifikante Entlastungen der IT und eine deutliche Verbesserung der Agilität realisieren.

image

Abb. 9–1Self-Service-Nutzer nach Anwendergruppen (in Anlehnung an [Förth & Tischler 2018])

Bei der zweiten Gruppe – den Power-Usern – ist es hingegen erforderlich, eigenständig Analysen durchzuführen, Daten anzureichern und gegebenenfalls sogar Marts oder zentrale Datenhaltungen in Zusammenarbeit mit der IT zu erweitern.

Die Data Scientists als dritte Gruppe stellen zwar nur einen Bruchteil der Unternehmensanwender dar, erfordern aber die höchsten Freiheitsgrade beispielsweise in Bezug auf Datenaufbereitung oder den Einsatz von neuen und innovativen Werkzeugen. Aus Unternehmenssicht erfordert diese Anwendergruppe eigene Governance-Strukturen, um eine möglichst hohe Agilität zu ermöglichen. Neben klassischen Governance-Maßnahmen in Bezug auf Organisation und Architektur ist es für Unternehmen essenziell, die technologische und Methodenkompetenz ihrer Data Scientists und Power-User zu fördern. Hier sind neben der regelmäßigen Evaluation neuer Werkzeuge auch die Förderung fachlichen Know-hows sowie die Schulung im Bereich allgemeiner Programmierrichtlinien und Datenstrukturen von Relevanz (vgl. [Meier & Zimmer 2018]).

Eckerson und andere weisen jedoch auch auf die Gefahren hin, die mit Self-Service-BI verbunden sind. Nach einer anfänglichen Euphorie führe Self-Service-BI in fast allen ihm bekannten Fällen zu einem »[…] environment in which no one trusts the data that anyone else produces« [Eckerson 2016], da alle Geschäftsbereiche letztlich ihre eigenen »spreadmarts« aufbauten und nur diesen vertrauten. Nur eine kooperative Zusammenarbeit von Business und IT könne eine geeignete Umgebung sicherstellen, in der die Anforderungen aller Beteiligten berücksichtigt werden.9

9.3Data Governance und Self-Service

Wie in der Herleitung dargestellt, handelt es sich bei der Data Governance um keinen Selbstzweck, sondern vielmehr um einen für die strategische Nutzung der Daten im Unternehmen kritischen Erfolgsfaktor. Hier gibt es unterschiedliche Ausprägungen, Ambitionsniveaus und Sichten auf Freiheitsgrade einzelner Nutzergruppen. Generell hat eine solche Governance nach [Gluchowksi 2020) folgende Aufgaben:
image

Abb. 9–2Data-Governance-Rahmen

In Abbildung 9–2 ist ein agiles Vorgehen beschrieben, mit dem ein Data-Governance-Rahmenwerk eingeführt werden kann (vgl. [Zimmer 2020]). Nach einer initialen Phase, in der die grundlegenden Anforderungen diskutiert, erhoben und verprobt werden, erfolgt eine inkrementelle Umsetzung der Governance-Bestandteile. Wichtig ist hier, dass nicht alle Themen auf einmal umgesetzt werden müssen, sondern nach Bedarf sukzessive erweitert werden können. So kann beispielsweise mit dem Aufbau einer sukzessive zu erweiternden Rumpfaufbauorganisation begonnen werden, anstatt alle notwendigen Rollen vorab durchzuexerzieren. In Abbildung 9-2 ist dieser Prozess als Zyklus dargestellt. Sobald die für die konkrete Fragestellung notwendigen Artefakte vorhanden sind, kann die Lebensphase mit Change Management und Operationalisierung beginnen. Wichtig ist, dass die Artefakte einem kontinuierlichen Wandel unterzogen sind und auch eine Verbesserungsschleife vorgesehen ist.

Setzt man die Governance in Bezug zu den unterschiedlichen Anwendern aus Fachbereichen, der IT oder auch externen Anwendergruppen, so wird sichtbar, dass hier unterschiedliche Ausgestaltungen einer Governance erforderlich sind. Generell kann auf Basis einer ersten Version der Governance ein Bausteinkasten an erlaubten Modulen definiert werden. Diese bilden wieder die Grundlage für eine zentrale Umgebung. So haben etwa unregelmäßig wiederkehrende Anfragen über die Kundengüte andere zu erfüllende Rahmenbedingungen als die Entwicklung eines sich selbst optimierenden Recommenders, der täglich von 100.000 Anwendern auf einer Webseite genutzt wird. Um sicherzustellen, dass die Governance die relevanten Anforderungen abbildet, ist eine zentrale Steuerung mit klaren Verantwortlichkeiten sowie eine Ergänzung und Verbesserung der Governance-Artefakte erforderlich (vgl. Abb. 9–3).

Bei dem hier beschriebenen Vorgehen handelt es sich um eine allgemeine Übersicht. Jeder Governance-Bestandteil kann bzw. muss vom Unternehmen durchdacht werden. So sind beispielsweise strategischer Werkzeugkasten und Datenarchitektur hier nur ein Unterpunkt, resultieren de facto heute aber in komplexen, die Aufbau- und Ablauforganisation unterstützenden Cloud-basierten Lösungen. Beispiele hierfür sind in Kapitel 8 dargestellt.

image

Abb. 9–3Lebenszyklus einer Data & Analytics-Strategie

Generell lässt sich Self-Service durch eine Vielzahl an Maßnahmen fördern. So können im Zuge der Aufbauorganisation zum Beispiel ein erfahrener und technisch versierter Data-Science-Experte als Teil des Fachbereichs und ein zentrales Data Science Competence Center als Multiplikator und Mittler fungieren. Ebenso können geeignete Prozesse unterschiedliche Geschwindigkeiten oder auch Compliance-Level fördern (vgl. [Zimmer 2020, S. 114 f., Tab. 8–1]).

9.4Self-Service-Datenaufbereitung und Data Science

Wie bereits diskutiert, gehören Analytics und Data Science zu den wichtigsten Treibern, die zu einer verstärkten Nachfrage nach Self-Service-Angeboten im Bereich der Informationssysteme geführt haben. Die nachgefragten Self-Service-Funktionalitäten betreffen in diesem Fall jedoch weniger das Berichtswesen als vielmehr den Zugang zu zusätzlichen Daten, die die Anwender ohne direkte Unterstützung der IT nutzen und aufbereiten möchten (vgl. auch Tab. 8–1, S. 148).

»The key to success is getting the right data and find the right attributes« stellen Kelleher und Tierney für Data Science fest und identifizieren diesen Schritt im Analyseprozess als erfolgskritisch [Kelleher & Tierney 2018].

Im unternehmerischen Alltag versucht der Data Scientist, auf der Basis der ihm vom Data Engineer zur Verfügung gestellten Daten neue Erkenntnisse für komplexe betriebliche Fragestellungen zu finden. Theoretisch soll der Data Engineer den Bereich der Data Science entlasten, damit dieser sich auf sein Kerngeschäft konzentrieren kann:

»Data engineering makes data scientists more productive. They allow data scientists to focus on what they do best – performing analysis. Without data engineering, data scientists spend the majority of their time preparing data for analysis.«10

Der Data Scientist wählt die notwendigen Daten aus, reichert sie an, verknüpft sie und testet sein Modell. Die Analyse der Ergebnisse führt nicht nur zu internen Anpassungen seines Modells, beispielsweise in Form einer neuen Gewichtung der Parameter, sondern auch zu strukturellen Änderungen. So sollen neue, bisher noch nicht enthaltene Daten, z.B. in Form weiterer Attribute, genutzt werden. Auch neue Datenquellen möchte der Data Scientist möglicherweise hinzuziehen. Die Datenquellen und ihre Struktur sind dem Data Scientist bekannt. Doch muss er seine neuen Anforderungen zunächst für den Data Engineer formulieren und kommunizieren. Dieser sorgt dann für die Bereitstellung der Daten aus der neuen Datenquelle. Schnell wird klar, dass sich die gut gemeinte Rolle des Data Engineer durchaus auch als Bremse für Data Science und Analytics erweisen kann.

Eine mögliche Lösung stellen Werkzeuge für eine sogenannte Self-Service-Datenaufbereitung dar. Durch solche Werkzeuge und eine geeignete Architektur wird dem Data Scientist der eigenständige Zugriff auf neue oder bereits verknüpfte Datenquellen für Ad-hoc-Themen ermöglicht. Ohne Zweifel sollte ein Data Scientist nicht nur über die notwendige Data Literacy verfügen, sondern auch über das technische Know-how im Umgang mit den angesprochenen Werkzeugen.11

Sollten sich die auf diesem Weg neu angeeigneten Daten im Modell als nützlich und sinnvoll erweisen, ist die Datenquelle auch offiziell anzubinden. Erst jetzt erfolgt die Formulierung der Anforderungen, die der Data Engineer anschließend sauber umsetzt. Hier spielen auch die Fähigkeit und der Wille des Data Scientist, nachhaltige und wartbare Datengrundlagen aufzubauen und nicht nur provisorische Lösungen zu erstellen, eine entscheidende Rolle. Nur wenn die Wartung und der Betrieb der zugrunde liegenden Datenbasen und der darauf aufsetzenden analytischen Modelle gewährleistet ist, kann Data Science dauerhaft im Unternehmen erfolgreich sein und zu der gewünschten Wertschöpfung führen.

Gemäß BARC versteht man unter »Data Preparation (Datenaufbereitung) […] den Prozess zur Aufbereitung und Bereitstellung von Daten für Data Discovery und fortgeschrittene Analysen (Advanced Analytics)« [Grosser & Tischler 2017]. Data Preparation ist dabei ein iterativer Prozess, der sowohl strukturierte Datenquellen als auch polystrukturierte Rohdaten nutzt, um auf diese Weise ein umfassenderes Bild der Realität zu erzeugen. Das so entstehende neue Data-Set kann dann, etwa mit Methoden der Data Science, genutzt und analysiert werden. Eine Umfrage von BARC zeigt dementsprechend auch Data Scientists und Datenanalysten als eine der größten Nutzergruppen von Data Preparation.

Aufgrund des hohen Drucks, den Data Science an dieser Stelle ausüben konnte, hat sich der Einsatz solcher Self-Service-Data-Preparation-Werkzeuge beschleunigt, sodass von einem wichtigen Schritt bei der Emanzipation des Anwenders gesprochen werden kann (vgl. [Haneke 2017]).

Gerade im Bereich der explorativen Analytik kann Self-Service Data Preparation daher ein Werkzeug sein, das dem Anwender ein höheres Maß an Flexibilität und Autonomie bietet und so am Ende auch zu einer höheren Produktivität führen kann. Data-driven Enterprises benötigen dabei immer mehr Self-Service-Funktionalitäten. Und dies nicht nur für den reinen Auswertungsbereich, sondern verstärkt auch für die Datenakquise:

»As more organizations focus on data-driven decision making, that has prompted a growing demand for data access.« [Swanson 2016, S. 3]

Darüber hinaus hat Data Science mittlerweile auch das Data Warehouse mit seinem konsolidierten, bereinigten und stabilen Datenbestand als Datenquelle entdeckt. Einige Autoren, wie etwa Kelleher und Tierney, empfehlen die Nutzung des Data Warehouse explizit als wichtigste Datenquelle für Data Science. Data Science sollte unbedingt auf die qualitativ hochwertige Datenbasis zurückgreifen, die durch langjährige Erfahrungen und durch die damit zusammenhängenden ETL-Prozesse abgestimmt ist. Vielen Data Scientists ist der Mehrwert einer solchen Nutzung für ihre Analysen oftmals nicht bewusst, sodass unnötige Mehrfachbearbeitungen zu beobachten sind.12

Das Bild der Data Science wird in der Regel bestimmt von einem Data Scientist, der Modelle entwickelt, in denen er Daten verarbeitet, um auf diese Weise dem Unternehmen zu neuen Erkenntnissen zu verhelfen. Dabei stehen zumeist die Modelle und die daraus abgeleiteten Erkenntnisse im Vordergrund. Analysiert man jedoch, womit Data Scientists die meiste Zeit verbringen, so stellt man fest, dass die Datenbeschaffung hier den Löwenanteil belegt. »Eighty percent of the effort in a typical analytics project is finding and preparing the data« [Loubser 2018]. Diese und weitere Untersuchungen der letzten Jahre stützen diese Sichtweise (vgl. [Loubser 2018; CrowdFlower 2016]). Durch die hohe technische Kompetenz der Nutzer in den Bereichen Analytics und Data Science könne den Anwendern mehr Selbstständigkeit beim Auffinden und Vorbereiten der Daten zugebilligt werden. Damit wird Self-Service Data Preparation zu einem zusätzlichen unterstützenden Werkzeug, das von einer geeigneten Governance-Strategie mit entsprechenden Maßnahmen wie überwachten Sandboxes flankiert werden muss.

9.5Self-Service-Datenaufbereitung vs. ETL

Das Schaffen eines integrierten Datenpools, auf dessen Basis Analysen durchgeführt und Berichte generiert werden, stellt in der Business Intelligence ein altbekanntes Problem dar. Das Frontend kann noch so schön, die Usability noch so gut, das System noch so performant sein: Wenn die Datenbasis unvollständig oder inkonsistent ist, werden die Nutzer das angebotene Werkzeug nicht verwenden. Viele Unternehmen, die diesen Teilprozess in ihrer Projektplanung vernachlässigt haben (in der Zeitplanung oder auch im Projektbudget), mussten hier im wahrsten Sinne des Wortes Lehrgeld zahlen. Über die Bedeutung der Datenintegration und ETL im Data-Warehouse-Prozess wurde gerade im Zuge der zunehmenden Etablierung von BI in den Unternehmen viel publiziert.13

image

Abb. 9–4Abgrenzung ETL & Data Preparation

Unabhängig von der Technologie (DWH vs. Big Data vs. Hybrid) muss die zentrale Datenhaltung im Sinne einer Hub-and-Spoke-Architektur als Single Point of Truth [Zimmer 2019] nicht nur die richtigen Daten in der gewünschten Granularität beinhalten, sondern auch die Qualität der dort zu findenden Daten gewährleisten. Dabei hat sich immer wieder gezeigt, dass der Aufbau einer zentralen Datenhaltung wie ein DWH oder ein Data Lake über die Rückkopplung mit den Fachbereichen auch zu einer Verbesserung der Datenqualität in den Quellsystemen führt. Neue Rollen, wie etwa die der Data Stewards, sollten sicherstellen, dass eine ausreichende Datenqualität in der verwendeten Datenbasis gewährleistet werden kann.

ETL mit seinen Schritten Extraktion, Transformation und Laden stellt einen von der IT gesteuerten Teilprozess im Rahmen der zentralen Datenbereitstellung dar und wird sowohl bei klassischen DWH-Anwendungen als auch im Big-Data-Bereich eingesetzt. In diesem Teilprozess werden verschiedene Datenquellen – zumeist OLTP-Systeme – über Konnektoren angeschlossen, im Rahmen der Transformation bereinigt und homogenisiert und anschließend in die zentrale Datenhaltung geladen. War dies in der Vergangenheit für Big Data noch verpönt, so haben sich im Zuge hybrider Datenarchitekturen für Batch-Verarbeitungen ähnliche Schichtenkonzepte wie beim DWH etabliert und altbewährte Methoden durchgesetzt.

Unter Data Preparation14 versteht man dahingegen das Sammeln, Bereinigen, Aufbereiten und Bereitstellen von Daten mit dem Ziel der Analyse. Dies scheint auf den ersten Blick nicht sehr weit vom klassischen ETL entfernt zu sein, unterscheidet sich jedoch in wichtigen Punkten. Zheng sieht dabei drei wichtige Aspekte [Zheng 2017]:

  1. Nutzer
    Während im Falle von ETL in der Regel die IT als zentraler Endnutzer zu sehen ist, wendet sich Data Preparation an eine andere Anwendergruppe. Hier stehen Anwender im Vordergrund, die die Datenbasis bereits gut kennen und aufgrund ihres Know-hows in der Lage sind, diese in vielfältiger Art und Weise zu nutzen oder aufzubereiten. Hierunter fallen nicht nur Data Scientists, sondern auch Business Analysts oder sogenannte Power-User.
  2. Daten
    Bei ETL handelt es sich zumeist um strukturierte Daten, die vornehmlich aus operativen Systemen ausgelesen und in das Data Warehouse überführt werden. Auf dieser – einheitlichen – Basis können im Anschluss die notwendigen Berichte generiert werden. Data Preparation dahingegen fokussiert in erster Linie auf Big Data. Die hier zu betrachtenden, großen Datenmengen sind vielfach unstrukturiert und liegen oft schemafrei vor.
  3. Use Case
    ETL-Prozesse dienen dazu, Daten aus heterogenen Quellen in eine einheitliche, homogene Datenbasis zu überführen, die als Single Point of Truth die Grundlage für das Unternehmensberichtswesen bildet. Die unter Punkt 1 genannten Nutzer von Data-Preparation-Werkzeugen arbeiten explorativ. Dabei nutzen sie neue Datenquellen, von denen noch nicht klar ist, ob sie langfristig tatsächlich dauerhaft genutzt werden sollen. Die zugrunde liegenden Analytics-Prozesse müssen agil sein, da die verantwortlichen Teams immer wieder neue Möglichkeiten austesten und gegebenenfalls wieder verwerfen.

Bei ETL handelt es sich also um einen zentral gesteuerten Prozess der Datenbereitstellung mit dem klaren Ziel, regelmäßige und wiederkehrende Datenlieferungen automatisiert, standardisiert und mit möglichst hoher Qualität und Ausfallsicherheit bereitzustellen. Demgegenüber steht Self-Service-Datenaufbereitung für nicht regelmäßig durchgeführte analytische Fragestellungen (vgl. Abb. 9–4). Legt man die in Tabelle 8–1 (S. 148) eingeführte Struktur von klassischem Reporting über Ad-hoc-Data-Science und industrialisierter Data Science zugrunde, so wird sichtbar, dass ETL-Prozesse sowohl für Reporting als auch für wiederkehrende und industrialisierte Data-Science-Anwendungsfälle erforderlich sind. Die Herausforderungen für Unternehmen bestehen derzeit darin, den Data Scientists und Analysten im Fachbereich hohe Freiheitsgrade zu ermöglichen und gleichzeitig eine Übergabe der hier erstellten Anwendungen und Analysen in einen Regelbetrieb mit gleichzeitigem Aufbau von ETL-Prozessen zu ermöglichen. Hier haben sich im Bereich der Data-Warehouse-Architekturen überwachte Sandbox-Ansätze etabliert. Diese lassen sich auch auf die Data-Science-Anwendungsfälle übertragen (vgl. [Haneke et al. 2018, S. 20 ff.; Trahasch & Zimmer 2015] sowie Kap. 8).

9.6Bimodale Data & Analytics: Segen oder Fluch?

Auf Basis einer differenzierten Governance lässt sich in den Unternehmen verstärkt eine IT der zwei Geschwindigkeiten beobachten, die unter dem Begriff der bimodalen IT diskutiert wird.15 Im Bereich von Data & Analytics ist dieses Konzept im Umfeld DWH-basierter Anwendungen bereits seit Jahren im Einsatz. So hat die zentrale Entwicklung eines DWH beispielsweise eine andere Geschwindigkeit als die dezentrale Entwicklung von Data Marts oder Reports im Fachbereich.16 Weitere Verbreitung findet dieses Konzept durch den zunehmenden Wunsch der Fachbereiche, Data Science möglichst flexibel zu unterstützen und durch Self-Service-Lösungen weniger abhängig von der zentralen und meist reglementierten Planung der IT zu sein.

»Die Zusammenarbeit zwischen Fachbereich und IT stellt eine zentrale Herausforderung dar. Insbesondere die Lösungsansätze der zentralen IT zur Erfüllung fachlicher Informationsbedürfnisse sind häufig […] nicht zufriedenstellend. So führen Kapazitätsengpässe innerhalb der IT sowie die Allokation eines Großteils der IT-Mitarbeiter für die Sicherstellung des Betriebs dazu, dass der Zeitraum zwischen Auftragserteilung seitens Fachbereich und Umsetzung durch die IT für die Fachbereiche häufig mehrere Monate dauert. Erschwerend kommt hinzu, dass viele Vorhaben aufgrund der Ressourcensituation ständig repriorisiert und schließlich nicht umgesetzt werden.«

[Meier & Zimmer 2018]

Mithilfe einer bimodalen Data & Analytics Governance versuchen Unternehmen die zunehmende Nachfrage nach mehr Autonomie der Fachbereiche mit den Governance-Anforderungen seitens der IT in Einklang zu bringen. Das entsprechende Zusammenspiel ist in Abbildung 9–5 dargestellt.17

image

Abb. 9–5Bimodale BI

Auf der einen Seite existiert im Unternehmen nach wie vor eine IT-getriebene zentrale Data & Analytics. In diesem klassischen Ansatz werden die ETL-Prozesse, Datenhaltungen, Berichte und Auswertungen in erster Linie von der IT-Abteilung zur Verfügung gestellt. Die Fachbereiche können lediglich ihre Anforderungen formulieren und die Gestaltung der Berichte nur teilweise beeinflussen. Der IT obliegt zudem die Verantwortung für das Testen, die Verwaltung und das Auditing der Berichte. Damit ist die IT-Abteilung letztlich die führende Größe.

Ganz anders stellt sich die Lage dar, wenn wir auf der anderen Seite von fachgetriebenen Anwendungen sprechen. Die Neuentwicklung von Analysen und Reports wird hier vom Fachbereich vorangetrieben, der dabei die von der IT zur Verfügung gestellten Werkzeuge, Services und den Support nutzt.18 In Anlehnung an Gartner kann man hier auch von einem bimodalen IT-Konzept sprechen. Mode 1 repräsentiert dabei die klassische IT-driven BI, die unter den bewährten Rahmenbedingungen betrieben wird, während Mode 2 für die Business-driven BI steht. Hier werden Freiräume gegeben, die es dem Fachbereich ermöglichen, explorativ nach neuen Erkenntnissen und Innovationen zu suchen, wobei in der Regel iterativ vorgegangen wird. Die Agilität steht hierbei im Vordergrund. Der Fachbereich hat im Mode 2 die Möglichkeit, schnell und größtenteils unabhängig von der IT-Abteilung seine Anforderungen umzusetzen und eigene Hypothesen sehr zeitnah auf ihre Richtigkeit hin zu überprüfen. Gerade für Data Science und Analytics sind die hierdurch entstehenden Freiheitsgrade von besonderer Bedeutung.

Dabei sind beide Modes durchaus verzahnt. Ist der IT-getriebene Ansatz sozusagen ein Enabler für die im Mode 2 zu findenden fachgetriebenen Analysen, so können bzw. müssen die hier entwickelten Berichte oder auch Innovationen im Sinne neuer Ansätze, Datenaufbereitungen und Konnektoren durchaus ihren Weg in die Mode-1-Welt finden und diese für alle Anwender erweitern. In diesem Fall spricht man dann von der Operationalisierung oder auch Industrialisierung der Ergebnisse (vgl. [Van der Lans 2015; Haneke et al. 2018]). Die IT muss dabei die Anwender im Bereich Self-Service aktiv unterstützen. Dies kann durch das Bereitstellen der benötigten Services, durch Schulungen und Unterstützung beim Aufbau von Sandboxes oder auch durch den Betrieb von Data Labs geschehen.

9.7Entwicklungen im Self-Service-Bereich

Aus den oben genannten Gründen nimmt nicht nur die Nutzung von Self-Service-Angeboten bei analytischen Anwendungen in der Breite zu. Auch in der Tiefe gibt es verstärkt neue Werkzeuge, die es Nutzern ermöglichen sollen, selbstständig Analysen vorzunehmen, ohne gleich Data Scientist oder Data Engineer zu sein. Zwei dieser in letzter Zeit in den Fokus geratenen Tendenzen werden im Folgenden kurz erläutert.

9.7.1AutoML als Data-Scientist-Ersatz?

Vor dem Hintergrund eines eklatanten Fachkräftemangels auf dem Feld der Data Science haben sogenannte AutoML-Anwendungen die Hoffnung genährt, dass man zukünftig möglicherweise fast vollständig auf diese Rolle verzichten könnte. Werkzeuge wie etwa H2O, DataRobot, AutoKeras oder auch Google Cloud oder Microsoft Azure AutoML sollen es auch Nicht-Experten ermöglichen, Machine-Learning-Modelle und -Techniken zu nutzen. Nachdem in den vergangenen Jahren große Fortschritte auf diesem Gebiet erzielt werden konnten, stellten Chin et al. die ketzerische Frage: »The Death of Data Scientists – will AutoML replace them?« [Chin et al. 2020]. Die Autoren beantworten diese Frage – wie viele andere Autoren auch – mit einem klaren Nein.19 Das Versprechen, Maschine Learning über AutoML zu den Fachdomänen zu bringen und damit letztlich eine Art Self-Service-Anwendung bereitzustellen, konnte – so reizvoll es auch sein mag – bisher noch nicht eingelöst werden.

Dies bedeutet jedoch nicht, dass die Nutzung von AutoML im Bereich der Data Science keinen Sinn macht. Vielmehr zeigen Untersuchungen, dass AutoML zum heutigen Zeitpunkt durchaus in der Lage ist, die Arbeit eines Data Scientist zu unterstützen und seine Produktivität zu erhöhen. In jedem Fall lässt sich die time to production neuer Modelle deutlich verkürzen. Gerade für Anwendungsfälle, in denen es vor allem auf die Geschwindigkeit der Umsetzung ankommt, kann der Einsatz von AutoML-Werkzeugen sinnvoll sein. Insofern sollte man AutoML als eine Ergänzung des Werkzeugkastens rund um Machine Learning und Data Science sehen, mit der sich gerade zu Beginn eines Projektes Effizienzgewinne erzielen lassen.

9.7.2Augmented Analytics

Während AutoML ein spezielles Werkzeug darstellt, um durch die Automatisierung erster Schritte Effizienzgewinne zu erreichen und die Abhängigkeit der Anwender von Spezialisten – zumindest im Anfangsstadium – zu verringern, handelt es sich bei Augmented Analytics um einen breiteren Ansatz.

Gartner definiert Augmented Analytics wie folgt: »Augmented analytics uses machine learning to automate data preparation, insight discovery, data science, and machine learning model development and insight sharing for a broad range of business users, operational workers and citizen data scientists« [Gartner 2019].

Es wird deutlich, dass Augmented Analytics damit zu einer weiteren Entwicklungsstufe im Bereich der Self-Service-Angebote führt. Verschiedene Autoren sprechen bereits von einer dritten Generation der BI-Anwendungen oder auch von der »Demokratisierung« der Daten durch leichteren Zugang und KI-unterstützte Auswertungen (vgl. [Kobek 2020], [Ortiz 2020] oder [LaPlante 2019]). Stehen in der traditionellen Self-Service-BI noch das Entwickeln neuer Reports und Dashboards durch die Anwender im Vordergrund, sollen im Fall von Augmented Analytics durch die Nutzung von NLP benutzerfreundliche Schnittstellen den Zugriff auf die Daten ermöglichen und die Analyse der Daten (und damit das Generieren von neuen Erkenntnissen) auch für Nicht-KI-Experten durchführbar sein.20

Wie bereits im Fall von AutoML soll die Nutzung von Augmented Analytics nicht die Rolle des Data Scientist obsolet machen. Vielmehr sollen die neuen Werkzeuge die Data-Science-Teams entlasten und auf diese Weise zu einer effizienteren Nutzung der Ressourcen führen.

9.8Fazit

Die Nutzung von Self-Service-Werkzeugen wird gerade in und vermutlich auch durch Data Science und ihre Verbreitung im Unternehmensumfeld weiter zunehmen. Angesichts der starken Zunahme und Verbreitung von Self-Service-Analytics-Werkzeugen in den Unternehmen werden die hiermit geschaffenen Freiheitsgrade für die Anwender auf den unterschiedlichen Ebenen bereits zum Teil als das »new normal« bezeichnet. Entsprechende Funktionalitäten werden eingefordert, angenommen und erwartet. Sie werden damit zukünftig zum Standard in den Unternehmen werden, die mit Analytics, Data Science und Machine Learning arbeiten. Die sich auf diese Weise herausbildende Self-Service-Kultur wird dazu führen, dass sich innerhalb des Unternehmens noch mehr Anwenderinnen und Anwender vor dem Hintergrund ihrer jeweiligen Fachdomäne mit analytischen Fragestellungen beschäftigen können und werden.21

Damit einhergehen müssen aber auch entsprechende organisatorische Rahmenbedingungen sowie ein umfassendes Ausbildungs- und Onboarding-Konzept. Ohne diese werden die erzielten Ergebnisse nicht wie gewünscht zur Wertschöpfung beitragen. Das alleinige Bereitstellen von Zugriffsmöglichkeiten auf die Daten und Analysetools für die Anwender ist an dieser Stelle nicht zielführend, vermutlich sogar kontraproduktiv.

In Anbetracht dieser Entwicklung und der hier zu erwartenden Dynamik ist das Erarbeiten einer geeigneten Data & Analytics-Governance-Strategie für die Unternehmen von elementarer Bedeutung. Nur so kann verhindert werden, dass die gewährten Freiheiten für Fachbereiche zu kontraproduktiven Entwicklungen führen. Die Balance zwischen gesicherten und belastbaren Informationen und Strukturen einerseits und ausreichenden Freiräumen für das kreative Entwickeln neuer Analysen und Lösungsansätze andererseits muss gehalten werden. Ein Analytics Competence Center nach dem Vorbild der BICCs könnte dabei ein wichtiges Instrument sein. Der Ruf nach mehr Freiheit in den Fachbereichen ist nicht neu. Doch erstens ist er heute lauter denn je und zweitens lässt er sich mithilfe der neuen Werkzeuge immer leichter realisieren.