Seite 2: Die Symptome einer Big Data-Dysfunktion

Inhaltsverzeichnis

Unternehmen, die Probleme mit der Datenqualität und der datengestützten Wertschöpfung haben, zeichnen sich in der Regel durch eine Reihe gemeinsamer Fehlerfaktoren aus: Zum einen kann ein missglückter Start vorliegen und die ins Auge gefassten Anwendungsfälle für Daten kommen nie in Gang. Möglich ist auch, dass es der Organisation nicht gelingt, mit den Bedürfnissen einer immer größer werdenden Anzahl von Datenkonsumierenden Schritt zu halten. Genauso kann es Probleme beim Skalieren von Quellen geben: Da der Umfang der Daten – und vor allem auch ihre Diversität – innerhalb wie außerhalb des Unternehmens rasant zunimmt, lassen sich die Quellen nicht so schnell integrieren wie sie sich vermehren. Schließlich erweist sich die Wertschöpfung aus den Daten schwierig bis unmöglich, wenn sich Datenproduzierende und Datenkonsumierende nicht abstimmen.

Laut einer Studie von NewVantage Partners tun sich die meisten Unternehmen in Sachen Big Data weiterhin schwer. Der Umfrage zufolge geben nur 24 Prozent der befragten Firmen an, ihr Versuch, eine datengestützte Organisation zu bilden, sei tatsächlich von Erfolg gekrönt gewesen. Ein ähnlich geringer Anteil an Unternehmen bejaht die Aussage, erfolgreich eine Datenkultur in ihrer Organisation etabliert zu haben. Doch der Grund für das flächendeckende Scheitern ist keineswegs technologischer Natur: Über 90 Prozent der Befragten bezeichnen vielmehr Menschen und Prozesse als Ursache dafür, dass die datengestützte Transformation ihrer Organisation nicht gelingen will.

Warum bestehende Architekturen einer Transformation im Wege stehen

Die Schwierigkeiten, auf die Unternehmen bei der Implementierung von Data Warehouses und Data Lakes stoßen, haben ähnliche Ursachen, treten aber an unterschiedlichen Stellen auf.

Der Zweck eines Data Warehouse ist es, einen strukturierten Datenspeicher mit integrierter Rechenleistung bereitzustellen, der alle Anforderungen eines Unternehmens erfüllen soll. Doch je größer ein Unternehmen ist, desto unrealistischer ist die Erfüllung dieses Anspruchs. Abgesehen vielleicht von einfachsten Domänen sind in der Regel mehrere voneinander abgegrenzte Kontexte und die entsprechenden Datenmodelle nötig. Gleichzeitig erschwert der beträchtliche Overhead von Data-Warehouse-Technologien eine effiziente Anpassung an diese Kontexte. Selbst im günstigsten Fall, in dem eine Beschränkung auf ein einziges Datenmodell möglich wäre, leidet häufig die Datenqualität, da eine zentralisierte Qualitätskontrolle nicht mit den dezentral auftretenden Änderungen im Unternehmen Schritt halten kann.

Oft enthalten verschiedene Systeme innerhalb der IT-Organisation die gleichen Daten. Für ein zentrales Data-Team ist es deshalb im Zweifelsfall schwierig festzustellen, welche die beste Datenquelle für eine Analyse ist. Hinzu kommt: Die Analyseszenarien können hinsichtlich der erforderlichen Datenqualität variieren. Beim Data-Warehouse- wie beim Data-Lake-Modell ist die Datenqualität maßgeblich von Handlungen beeinflusst, die stattfinden, lange bevor Nutzerinnen und Nutzer ins Spiel kommen. Die Personen, die für die Datenerzeugung verantwortlich sind, gehören anderen Organisationseinheiten an als die Verwender derselben Daten.

Ein gigantisches Silo – und ein unüberwindlicher Engpass

Data Warehouses wie auch Data Lakes bilden häufig eine Art riesiges Silo, das Petabytes an Daten enthält. Natürlich sollen solche Architekturen den Zugriff auf alle Daten des Unternehmens ermöglichen. Aber anders als bei anderen Silos besteht das Problem hier nicht darin, dass Daten aufgrund technischer Beschränkungen unzugänglich wären; die Herausforderung ist vielmehr eine organisatorische. Die Teams, die diese monolithischen Daten-Repositories betreiben, müssen mit hochgradig spezialisierten Data Engineers besetzt werden.

Allerdings sind qualifizierte Data Engineers schwierig zu finden, und ihre Vergütung ist entsprechend hoch. Daher stellt die Rekrutierung der richtigen Personen für das Erstellen und den Betrieb eines Data Lake eine enorme Hürde dar. Doch selbst wenn ein Unternehmen in der Lage ist, genügend Fachkräfte für Aufbau und Betrieb seines Data Lake zu finden, enden die Probleme damit nicht. Denn diese Data-Fachleute müssen Daten von Personen und Teams aus dem gesamten Unternehmen beziehen. Letztere haben jedoch wenig Anreiz, sicherzustellen, dass sie nur korrekte, vertrauenswürdige und aussagekräftige Daten weitergeben.

Sind die Daten einmal erfasst, hat das Data-Engineering-Team die wenig beneidenswerte Aufgabe, sie für den Rest des Unternehmens nutzbar zu machen. Und zwar ohne jegliches Fachwissen zur jeweiligen Domäne und ohne Unterstützung durch eine immer größer werdende Anzahl von Datenkonsumierenden.

Ein Paradigmenwechsel, der nicht auf Technologie beschränkt ist

Um in der beschriebenen Situation Abhilfe zu schaffen, müssen Entscheiderinnen und Entscheider sich von den derzeitigen technologieorientierten Denkmustern lösen. Andernfalls bliebe die inhärente Trennung zwischen Datenproduzierenden und -konsumierenden ebenso bestehen wie das gigantische Silo, der Personalengpass und die damit einhergehenden Fehlermöglichkeiten.

Anstatt Daten weiterhin als Nebenprodukt anderer geschäftlicher Funktionen zu betrachten, ist es Zeit anzuerkennen, dass Daten schon lange ein eigenständiges Produkt sind. Dieser neue Blickwinkel ist nötig, damit Entscheiderinnen und Entscheider sich von monolithischen Systemen und linearen Pipelines lösen können. Spezifische Teams verantworten nunmehr die Daten. Ein solches Verständnis vermittelt nicht nur, wie die unterstützende Architektur, sondern auch die Organisation selbst zu strukturieren sind.

Die meisten Data Scientists verbringen mindestens 80 Prozent ihrer Zeit mit dem Erfassen und Extrahieren von Daten. Doch was wäre, wenn geschäftliche Aktivitäten von Grund auf datenorientiert gestaltet wären? Und wenn dieselben Data Scientists während des gesamten Lebenszyklus der Daten voll involviert wären?