Eine Datenplattform ist kein Data Lake mit Dashboard

Ein Analyst von der Seite an einem langen Schreibtisch mit drei Monitoren voller abstrakter blau-grauer Tabellen und Verbindungslinien, dahinter gedruckte Schemadiagramme an einer Pinnwand, Licht am späten Nachmittag

Der Projektauftrag war klar: alle Daten des Unternehmens an einen Ort bringen. Aus dem ERP, dem CRM, dem Lagersystem und einem Dutzend Tabellen wurden Pipelines in einen Cloud-Data-Lake gebaut, jede Nacht geladen. Obendrauf kam ein BI-Tool. Die Präsentation zum Start zeigte alle Quellen, die in einen Speicher münden.

Ein halbes Jahr später zeigen drei Dashboards drei verschiedene Umsatzzahlen, und die Analysten verbringen den größten Teil ihrer Woche damit, zu erklären, warum. Die operativen Teams exportieren weiterhin in Tabellen, weil der Lake einen Tag hinterherhinkt und ohnehin nichts ändern kann. Die Daten sind an einem Ort. Sonst nichts.

Das Projekt hat Speicherung und Transport gelöst, die nie das Schwierige waren. Schwierig sind Bedeutung (was jedes Feld tatsächlich ist), Verantwortung (wer dafür geradesteht, dass es stimmt), eine Aktualität, die zur Entscheidung passt, und ein Weg zurück an den Ort, an dem die Arbeit geschieht. Ein Data Lake ist ein Ort. Eine Datenplattform ist eine Vereinbarung über alle vier.

Wo der Lake mit Dashboard scheitert

Kopien ohne Bedeutung. Tabellen kommen mit Spaltennamen an, die für den Entwickler des Quellsystems Sinn ergaben. Niemand weiter unten weiß, welcher der sieben Statuswerte „versandt“ bedeutet – also rät jeder Analyst, und jeder rät anders.

Kein Verantwortlicher für irgendeine Tatsache. Ist eine Zahl falsch, trifft es das Datenteam. Der Fehler liegt fast immer im Quellprozess, und die Menschen, die ihn beheben könnten, erfahren nie davon, weil der Lake nicht weiß, wer sie sind.

Ein Tempo für alles. Ein nächtlicher Batch bedient eine Bestandsentscheidung, die stündlich fällt. Oder, in der teuren Variante, alles wird in Echtzeit gestreamt, um einen Bericht zu speisen, den man einmal im Monat liest. Die Aktualität bestimmt die Pipeline, nicht die Entscheidung.

Fluss in eine Richtung. Daten fließen aus den operativen Systemen in die Analyse. Erkenntnisse fließen als Folie aus der Analyse. Gehandelt wird wieder im Quellsystem, von Hand. Der Weg von der Erkenntnis zur Aktion führt über Menschen, die Dinge abtippen.

Definitionen in der Berichtsschicht. Jedes Dashboard berechnet den Umsatz mit seiner eigenen Formel, und die Definitionen driften mit jeder Korrektur weiter auseinander. Wie man das stoppt, behandelt der Beitrag eine Definition von Umsatz.

Was eine Datenplattform ist

Ein Modell des Unternehmens, auf das jede Quelle abgebildet wird. Der Auftrag im ERP und der Deal im CRM sind mit denselben Objekten verknüpft, samt ihren Beziehungen, in einer Beschreibung des Geschäfts: einer Ontologie. Neue Quellen werden auf das Modell abgebildet, statt daneben abgeladen zu werden.

Ein Verantwortlicher für jedes Objekt und jede Quelle, namentlich, mit einer schriftlichen Definition dessen, was „korrekt“ bedeutet. Stimmt etwas nicht, geht es an diese Person, mit Belegen.

Aktualität, die die Entscheidung bestimmt. Fragen Sie für jede Nutzung, welcher Entscheidung diese Daten dienen und wie alt sie sein dürfen, wenn die Entscheidung fällt. Manches braucht Minuten, das meiste einen Tag, einiges einen Monat.

Datenherkunft. Jede Zahl lässt sich zu ihren Quellen und den unterwegs angewandten Transformationen zurückverfolgen – auch von jemandem, der die Pipeline nicht gebaut hat.

Ein Weg zurück. Die Plattform kann eine Entscheidung an den Ort liefern, an dem sie umgesetzt wird – als vorgeschlagene Nachbestellung, als markierte Rechnung oder als Aufgabe mit Verantwortlichem –, über eine Freigabe statt über ein Diagramm und eine E-Mail.

Der letzte Punkt ist der Grund, warum Hurukan keine separate analytische Kopie des Geschäfts führt. Seine Datenebene ist als Konnektoren in ein Datenmodell angelegt, mit Importen, Synchronisation, Dokumenten und E-Rechnungen an den Datensätzen, zu denen sie gehören. Betrieb und Analyse lesen dasselbe Modell, sodass eine Erkenntnis zu einem Vorschlag auf genau dem Datensatz werden kann, aus dem sie stammt. Das System ist im Aufbau; was hier beschrieben wird, ist das Design.

Ein Test, den Sie heute machen können

Nehmen Sie die Zahl, über die in Ihrer Managementrunde am meisten gestritten wird. Verfolgen Sie sie auf dem Papier zurück:

  • Aus welchem System, welcher Tabelle und welchem Feld sie stammt.
  • Welche Filter angewandt wurden und wer sie festgelegt hat.
  • Wer namentlich dafür verantwortlich ist, dass diese Zahl stimmt.
  • Wie alt sie in dem Moment war, als sie gezeigt wurde.

Dann stellen Sie die zweite Hälfte der Frage. Wenn diese Zahl ein Problem zeigt, was passiert dann? Zählen Sie, wie oft die Information abgetippt, weitergeleitet oder neu erklärt wird, bevor sich im Geschäft tatsächlich etwas ändert.

Braucht die Rückverfolgung mehr als eine Person, oder läuft die Aktion über E-Mail und Gedächtnis, haben Sie einen Lake mit Dashboard. Das übliche Symptom sind Berichte, die niemand öffnet – darum geht es in das Dashboard, das niemand öffnet. Die Hurukan-Übersicht zeigt, wo die Datenebene zwischen den übrigen Ebenen liegt.