Genau hier stand doubleSlash: an der Schwelle zu einem unübersichtlichen Datenchaos, das unsere Effizienz bedrohte. Doch anstatt in der Datenflut unterzugehen, haben wir uns entschlossen, das Ruder herumzureißen. Mit einer Mischung aus Data Mesh Prinzipien, rigorosem Datenmanagement und einer gehörigen Portion Innovationsgeist starteten wir eine grundlegende Transformation. Erfahren Sie, wie wir unser Unternehmensreporting von einem schwerfälligen Relikt in eine dynamische, fehlerresistente Datenautobahn verwandelt haben, die nicht nur die Fehlersuche minimiert, sondern auch datengetriebene Entscheidungen verlässlicher macht.
Unser Erfolg über die Jahre spiegelt sich darin wider, dass immer mehr Fragestellungen, die wir als Use Cases bezeichnen, hinzugekommen sind. In diesem Zusammenhang wurden neue Datenquellen integriert sowie Daten aufbereitet und visualisiert. Die dadurch entstandene Datenarchitektur kann als „historisch gewachsen“ bezeichnet werden und ließ mit der Zeit Übersichtlichkeit vermissen. Zwischenergebnisse der Datenaufbereitung wurden für andere Use Cases genutzt, aufeinander aufgebaut und mit ähnlicher Logik sowie identischen Daten parallel entwickelt. Das hatte zur Folge, dass wir immer mehr mit Fehlern zu tun hatten, die wir zwar in einer Aufbereitungsstrecke korrigierten, jedoch ähnliche Fehler in anderen Transformationen übersahen. Dies führte zu Inkonsistenzen und vor allem dazu, dass viel Zeit für die Fehlersuche und Korrektur aufgewendet wurde, anstatt neue Analysen zu erstellen.
Zudem wurde sehr heterogen vorgegangen. Gelegentlich wurden „alle“ Daten aus einem Quellsystem mitgenommen und im großen Umfang weiterverarbeitet. An anderen Stellen hingegen nutzten wir konsequent nur die tatsächlich benötigten Daten aus dem Quellsystem.
Kurz gesagt, es war Zeit für das große Aufräumen.
Angesichts unseres Wissens über Data Mesh und anderer Konzepte sowie unserer Erfahrungen aus verschiedenen Kundenprojekten mussten wir für unseren eigenen Datenhub „nur noch“ die Umsetzung starten. Wie bei unseren Kunden auch verursacht die Veränderung Schmerzen. Dies liegt vor allem daran, dass historisch gewachsene Systeme ihre Tücken aufweisen und wir sowohl neue Use Cases liefern als auch bestehende weiterhin betreiben müssen. Das sollten wir alles erfahren. Zu jeder Zeit waren wir uns jedoch sicher: Änderungen sind notwendig, denn ohne diese würden die Aufwände für Fehlersuche und -korrektur stetig steigen und die Verlässlichkeit abnehmen.
Vorgehen nach fachlicher Zugehörigkeit
Zuerst gliederten wir unsere Use Cases und KPIs nach Fachdomänen und setzten Termine mit den zuständigen Stakeholdern an. Im Bereich Finanzen, der Domäne unseres Unternehmensreportings mit der größten Tragweite und den meisten Use Cases, sind zudem die wichtigsten Quellsysteme angesiedelt.
Gemeinsam mit den Fachbereichsexperten/innen ordneten wir die KPIs aus den Use Cases in eine fachliche Hierarchie ein und identifizierten Abhängigkeiten. Außerdem bestimmten wir, welche KPIs aus fachlicher Perspektive aus bestimmten Daten oder Eingangs-KPIs entwickelt werden müssen, da die „Wahrheit“ oft in spezifischen Quellsystemen verankert ist.
Hier zeigte sich beispielsweise, dass wir nicht die eine Wahrheit über Mitarbeitende, deren Wochenarbeitszeit, Beschäftigungsverhältnis und Teamzugehörigkeit hatten. Deshalb war der erste und nachhaltig wichtige Schritt der Aufbau einer solchen Tabelle, die in verschiedene Use Cases und Datenprodukte integriert werden sollte.. Obwohl der Aufwand zunächst hoch war, wurde der Nutzen bald offensichtlich, insbesondere bei der vereinfachten Fehlersuche in finanziellen Use Cases, die sich auf das Beschäftigungsverhältnis oder die Teamzugehörigkeit der Mitarbeitenden stützen.
Hierarchische Einordnung
Insbesondere die hierarchische Betrachtung der KPIs erlaubte uns in der Folge, die fachliche Datenarchitektur zu entwerfen. Das grundlegende Konzept war die Data Factory (https://www.doubleslash.de/leistungen/data-factory/ ) zusammen mit der Idee der Datenprodukte (https://staging.blog.doubleslash.de/usability-von-datenprodukten-tipps-und-best-practices-aus-dem-projektalltag).
Basierend auf den gewonnenen Erkenntnissen aus bisherigen Datenaufbereitungen arbeiteten wir in weiteren Meetings mit Fachbereichsexperten/innen daran, die Use Cases und Datenprodukte so zu gestalten, dass sie alle relevanten Fragen abdecken und die Aufbereitungen logisch aufeinander aufbauen. Einige bestehende Aufbereitungsstrecken wurden gründlich überarbeitet und nahezu neu aufgebaut. Andere ließen sich mit wenig Aufwand übernehmen oder in mehrere, fachlich getrennte, aufeinanderfolgende Datenprodukte segmentieren.
Ein Use case ist dabei immer eine Aufbereitung, die ein Output produziert, der entweder visualisiert oder dem Anforderer bzw. der Anforderin als Datei bereitgestellt wird.
Im Gegensatz dazu sind Datenprodukte fachlich abgegrenzte Datenaufbereitungen, die, anders als Use Cases, nicht direkt an den Anforderer/die Anforderin geliefert, sondern in weitere Use Cases oder andere Datenprodukte integriert werden. Als Input für Datenprodukte und Use Cases dienen Base Tables, die bereinigte und aufbereitete Daten aus den Quellsystemen beinhalten. Diese Base Tables werden historisiert, sodass unabhängig von den Quellsystemen die KPIs zu einem Tag x wieder errechnet werden können. Da die Base Tables üblicherweise homogen hinsichtlich der Quellsysteme sind, fungieren sie auch als fachlich formulierter Datenbedarf für die Quellsysteme.
Lifecycle eines Use Cases
Immer dann, wenn Daten aus einem Use Case später in einem anderen Use Case ähnlich benötigt werden, sollte aus der ursprünglichen Aufbereitung ein allgemeineres Datenprodukt entwickelt werden, das anschließend in beiden Use Cases nach Bedarf gefiltert und weiterverarbeitet wird. So verhindern wir eine erneute parallele Aufbereitung. Insbesondere bei der erstmaligen Aufbereitung der Daten „neuer“ Quellsysteme kommt diese Weiterentwicklung vor.
Erfahrungen
Für unseren Datenhub wurde sehr viel Kapazität in den Umbau der fachlichen Datenarchitektur investiert. Als Ergebnis können wir festhalten:
- Die Datenbedarfe in Richtung Quellsysteme sind nun fachlich klarer. Dementsprechend lassen sich die notwendigen Anpassungen bei einem potenziellen Austausch von Quellsystemen klarer benennen.
- Bei der Konsolidierung der Datenstrecken ist es wichtig, sich immer wieder an die konsequente Einhaltung der vorher aufgestellten Regeln zu erinnern. Dies war bei uns beispielsweise die Vermeidung paralleler Aufbereitung ähnlicher Datenprodukte oder Use Cases. Und trotzdem ist es am Ende kaum möglich, zu 100% konsequent zu handeln.
- Die Strukturierung der verschiedenen Aufbereitungen erfolgte nun mit einem deutlich stärkeren fachlichen Fokus. Bei neuen Use Cases können wir direkt mit den Stakeholdern die Nutzung der verschiedenen Datenprodukte besprechen. Spricht der Finanzverantwortliche von „Aufwand nach Kostenart“, wissen wir nun sofort, welches Datenprodukt gemeint ist und zur Beantwortung der Fragestellung herangezogen werden muss.
- Die klare Zuordnung der Verantwortlichkeiten ermöglicht eine bessere Einbindung des fachlichen Wissens der Daten-Owner und der zugehörigen Prozesse. Die von uns erstellte Dokumentation zu den Base Tables, Datenprodukten und Use Cases verbessert die Transparenz der Aufbereitungen erheblich und ermöglicht eine schnelle Klärung von Fragen. Die historisierten Base Tables helfen in verschiedenen Situationen dabei, den Datenstand einer KPI am Tag X erneut errechnen zu können
Unsere Einschätzung
Trotz der hohen Aufwände und gelegentlichen Herausforderungen durch komplexe fachliche Logiken sind wir mit der neuen Datenarchitektur sehr zufrieden. Wir können uns jedoch in der konsequenteren Handhabung des Stammdatenmanagements weiter verbessern. Wir müssen die Stammdaten (z.B. Personal, Kunden, Konten) konsequenter aus den Quellsystemen beziehen, die als verlässliche Quelle für die fachlichen Ansprechpartner/innen gelten. Weiterhin streben wir Verbesserungen in der Datenqualität an, indem wir beispielsweise Pflegefehler bereits beim Import aus den Quellsystemen erkennen und korrigieren lassen. Des Weiteren planen wir, das Testing der Datenstrecken zu verbessern, um Fehler in der Aufbereitung effektiver zu adressieren. Um die Transparenz der aufeinander aufbauenden Base Tables, Datenprodukte und Use Cases zu erhöhen, entwickeln wir eine automatisierte Data Lineage. Dies soll uns ermöglichen, den Weg spezifischer Daten durch unseren Datenhub präziser zu verfolgen, Fehler zu minimieren und den Fachbereichen fundierte datenbasierte Entscheidungen zu ermöglichen.
