Im thinkBI Podcast geht es diesmal um Datenaufbereitung. Das klingt zunächst nach einem technischen Zwischenschritt. Ein paar Transformationen, ein paar Bereinigungen, dann kann das Reporting beginnen. Genau dieses Bild ist zu klein.
Denn Datenaufbereitung entscheidet nicht nur darüber, wie Daten aussehen. Sie entscheidet auch darüber, wo Last entsteht, wie oft Quellsysteme berührt werden, wie stabil Verarbeitung abläuft und ob BI auf einem Werkzeug oder auf einer tragfähigen Architektur aufsetzt.
Die Irritation beginnt an einer Stelle, die viele Teams gut kennen. Fachbereiche oder BI-Verantwortliche wollen Daten schneller sehen. Nicht immer geht es um echte Echtzeit. Häufig geht es um den Wunsch, einen Ladeprozess kurzfristig anzustoßen, weil gerade noch etwas umgebucht wurde oder eine Excel-Datei aktualisiert worden ist. Das wirkt pragmatisch. Es erhöht aber auch die Komplexität. Sobald viele Beteiligte Prozesse nach Bedarf auslösen, greifen Zahnräder ineinander, die nicht mehr sauber orchestriert sind.
Schon an diesem Punkt wird sichtbar: Datenaufbereitung ist nicht nur eine Frage einzelner Transformationsschritte. Sie ist eine Frage von Ablauf, Verantwortung und Architektur.
Mächtige BI-Tools lösen das Problem nicht allein
Gerade im Self-Service-BI ist die Versuchung groß, möglichst viel direkt im Werkzeug zu erledigen. Ein Tool wie Power BI bringt Konnektoren, Transformationslogik und ein eigenes Speichermodell mit. Damit lässt sich erstaunlich viel umsetzen, oft auch sehr schnell.
Das ist ein echter Fortschritt. Kleine Teams können ohne große Vorinvestition Daten anbinden, bereinigen und für Analysen nutzbar machen. Für viele Organisationen ist genau das der richtige Einstieg.
Aber der sichtbare Komfort verdeckt leicht die strukturelle Grenze. Wenn Datenaufbereitung vollständig im BI-Werkzeug stattfindet, hängt die Verarbeitung eng an diesem einen System. Jede Aktualisierung durchläuft die Transformationslogik erneut. Schon während der Modellierung greifen Werkzeuge immer wieder auf die Quellen zu, um Zwischenergebnisse zu prüfen und anzuzeigen. Das erzeugt Last dort, wo sie oft am wenigsten erwünscht ist, in den Vorsystemen.
Das ist kein Detail der Bedienung. Das ist ein Architekturhinweis.
Datenaufbereitung braucht einen Ort, der nicht das Frontend ist
Sobald Datenmengen, Quellenvielfalt oder organisatorische Ansprüche wachsen, reicht es nicht mehr, Transformation nur als Funktion eines Analysewerkzeugs zu betrachten. Dann braucht Datenaufbereitung einen eigenen Ort.
Genau hier kommt die Datenplattform ins Spiel. Ihr Kernvorteil liegt nicht nur in mehr Technik. Ihr eigentlicher Wert liegt in der Entkopplung. Daten werden aus den Quellsystemen geladen, zwischengespeichert und dann innerhalb der Plattform weiterverarbeitet. Weitere Schritte laufen nicht mehr permanent gegen die operative Quelle, sondern gegen einen kontrollierten Zwischenbestand.
Damit verschiebt sich die Logik grundlegend. BI wird robuster, weil Quellsysteme geschont werden. Verarbeitung wird nachvollziehbarer, weil einzelne Schritte nicht mehr in einer Frontend-Logik versteckt sind. Und Transformation wird wiederverwendbarer, weil sie nicht an ein einzelnes Berichtswerkzeug gebunden bleibt.
Die entscheidende Frage lautet also nicht nur: Welche Transformation brauchen wir?
Die wichtigere Frage lautet: Wo soll diese Transformation eigentlich leben?
Bronze, Silver und Gold sind mehr als Schichten
Die Folge führt dafür die Medaillenarchitektur als einfaches Denkmodell ein. Im Bronze (Raw) Layer werden Daten zunächst so aufgenommen, wie sie aus den jeweiligen Quellen kommen. Das können Excel-Dateien, Exporte, SQL-Zugriffe oder andere Bereitstellungsformen sein. Entscheidend ist, dass zunächst ein belastbarer Rohbestand entsteht.
Darauf aufbauend entsteht der Silver Layer. Hier werden Daten bereinigt, vereinheitlicht, in Zeitverläufe überführt oder auf den letzten gültigen Stand gebracht. Die Plattform übernimmt also nicht nur technische Ablage, sondern fachlich relevante Vorbereitung.
Erst im Gold Layer werden daraus analytische Strukturen. Hier beginnt die eigentliche Modelllogik mit Dimensionen, Fakten und den Formen, die später für Reporting und Analyse benötigt werden.
Diese Schichtung ist keine formale Spielerei. Sie schafft Klarheit darüber, was Rohdaten sind, was vorbereitete Daten sind und was bereits analytisch modellierte Daten sind. Genau diese Klarheit fehlt oft, wenn alles in einem einzigen Werkzeug, in einem einzigen Modell und entlang vieler impliziter Transformationsschritte passiert.
Reife heißt nicht automatisch Plattform um jeden Preis
Trotzdem wäre es zu einfach, aus dieser Beobachtung sofort eine Pflicht zur großen Datenplattform abzuleiten. Die Folge argumentiert deutlich pragmatischer.
Nicht jede Organisation hat dieselbe Infrastruktur. Nicht jedes Team hat das nötige Know-how. Nicht jedes Berichtswesen ist so komplex, dass eine separate Plattform sofort wirtschaftlich oder organisatorisch sinnvoll wäre. Self-Service ist deshalb nicht der Fehler. Er ist oft der Anfang.
Der Fehler beginnt erst dann, wenn ein Werkzeug dauerhaft eine Rolle übernehmen soll, für die es architektonisch nicht gedacht ist. Wenn Ladeprozesse schwer steuerbar werden, wenn Quellen immer wieder neu belastet werden, wenn Transformationslogik unübersichtlich wächst und wenn das semantische Fundament zu stark an ein einzelnes Frontend gebunden bleibt, dann ist der Punkt erreicht, an dem Architektur nachziehen muss.
Gute BI entscheidet deshalb nicht ideologisch zwischen Self-Service und Plattform. Gute BI erkennt, wann der Reifegrad einer Organisation einen Wechsel der Verarbeitungsebene verlangt.
Vielleicht ist genau das die eigentliche Verdichtung dieser Folge: Datenaufbereitung ist keine vorbereitende Fleißarbeit vor dem Dashboard. Sie ist der Ort, an dem sich entscheidet, ob BI nur Daten verarbeitet oder ob sie beginnt, eine belastbare Informationsarchitektur aufzubauen.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
