Im thinkBI Podcast geht es im Dashboard Creation Cycle einen Schritt weiter, weg von der reinen Modellbeschreibung, hin zur Frage, woher die Daten für ein Modell überhaupt kommen. Das klingt zunächst nach einer technischen Vorfrage. In der Praxis ist es aber eine der wichtigsten Architekturentscheidungen überhaupt. Denn bevor ein Report sauber gebaut werden kann, muss klar sein, welche Daten wirklich belastbar sind.
Die sichtbare Oberfläche ist selten die ganze Wahrheit
Wer in einem ERP-System auf ein Feld schaut, sieht oft nur das Ergebnis einer längeren Kette. Die Oberfläche zeigt einen Wert an, aber nicht immer seine eigentliche Herkunft. Manche Systeme bieten Hilfefunktionen oder technische Hinweise, die einen ersten Blick auf die Quelle erlauben. Trotzdem bleibt oft nur eine halbe Wahrheit sichtbar. Gerade bei Strukturen, Views oder zur Laufzeit berechneten Feldern wird schnell deutlich, dass Anzeige und Datengrundlage nicht dasselbe sind.
Das ist ein wichtiger Unterschied. Eine Oberfläche kann nützlich sein, weil sie Orientierung gibt. Sie kann aber auch täuschen, wenn sie als Beweis für die eigentliche Quelle gelesen wird. Ein Flow Field in Dynamics oder Business Central ist dafür ein gutes Beispiel. Die Oberfläche greift auf eine Struktur zu, die selbst nicht die Daten hält, sondern sie erst über Logik zusammenzieht. Wer das nicht erkennt, verwechselt Darstellung mit Herkunft.
Genau deshalb beginnt Datenidentifikation nicht mit dem Tool, das später reporten soll. Sie beginnt mit dem Blick auf die fachliche und technische Wirklichkeit hinter der Anzeige. Nicht jedes sichtbare Feld ist eine Quelle. Nicht jede Tabelle ist der Ort, an dem die Wahrheit liegt.
Quelle, Plattform, Frontend: drei Ebenen, drei Aufgaben
Der Gedankengang ordnet die Datenwelt nicht als linearen Weg von A nach B, sondern als System unterschiedlicher Ebenen. Manchmal liegen die Daten bereits in einer Datenplattform oder einem DWH. Dann muss nicht mehr das Vorsystem selbst angezapft werden, sondern die Frage lautet: Welche Source innerhalb dieser Plattform ist fachlich die richtige?
In anderen Fällen reicht das nicht aus. Dann muss man in das Vorsystem zurückgehen und dort die wirkliche Datengrundlage identifizieren. Erst danach kann entschieden werden, ob die Daten direkt an ein BI-Werkzeug geliefert werden oder ob sie zunächst in eine Plattform geladen werden, dort bereinigt, strukturiert und als analytische Schicht bereitgestellt werden.
Diese Unterscheidung ist wichtig, weil sie die Verantwortung sauber verteilt. Das Vorsystem ist nicht automatisch die beste Analysequelle. Die Datenplattform ist nicht automatisch nur ein technischer Umweg. Und das Frontend ist nicht automatisch der Ort, an dem die Datenverantwortung endet. Jede Ebene hat ihren Zweck.
Gerade bei kleineren Unternehmen kann es plausibel sein, direkt mit einem Werkzeug wie Power BI an die Quellsysteme zu gehen. Das ist zunächst nicht falsch. Aber mit wachsender Reife verschiebt sich die Frage. Dann reicht der direkte Zugriff nicht mehr aus, weil Daten aufbereitet, entkoppelt und über eine verlässliche Schicht bereitgestellt werden müssen. BI wird damit weniger zu einer einzelnen Anwendung und mehr zu einer Architektur aus Datenaufnahme, Zwischenschicht und Analysezugriff.
Wenn die Herkunft unklar bleibt, wird die Planung fragil
Die eigentliche Herausforderung liegt nicht nur in der Technik, sondern in der Identifikation der echten Datengrundlage. Das ist besonders dann schwierig, wenn Systeme gekapselt sind oder wenn sich die Quelle nicht direkt aus der Oberfläche ablesen lässt. Wer nur den sichtbaren Wert kennt, aber nicht die Struktur dahinter, plant auf unsicherem Boden.
Deshalb braucht Datenidentifikation technisches Verständnis. Oft braucht man jemanden, der ein System nicht nur bedienen, sondern auch wirklich lesen kann. Denn in vielen Fällen liegt die entscheidende Information nicht auf der Maske, sondern in der Struktur dahinter. Erst dann wird sichtbar, ob eine Anzeige direkt aus einem Vorsystem kommt, ob sie über eine View erzeugt wurde oder ob sie erst in einer Datenplattform fachlich sinnvoll zusammengeführt wird.
Dieser Gedanke ist zentral: BI beginnt nicht mit Visualisierung, sondern mit Herkunftsklarheit. Wenn die Datengrundlage nicht sauber identifiziert ist, werden spätere Modelle fragil. Dann sieht der Bericht korrekt aus, aber seine semantische Stabilität bleibt unklar.
Data Virtualization ist kein Ersatz für die Frage nach der Quelle
Ein anderer Weg ist Data Virtualization. Wenn Ladeprozesse aus Vorsystemen oder Datenplattformen zu langsam sind, kann eine virtuelle Schicht die Daten über einen zentralen SQL-Endpunkt bereitstellen. Das kann sinnvoll sein, weil es Zugriffe vereinfacht und Daten flexibel verfügbar macht.
Aber auch hier gilt: Die technische Lösung ersetzt nicht die strukturelle Frage. Data Virtualization ist eine Form der Bereitstellung, nicht automatisch eine Antwort auf die Frage nach der besten Quelle. Sie kann eine sinnvolle Architekturkomponente sein, solange klar bleibt, welche Daten sie nur durchreicht, welche sie aufbereitet und welche Verantwortung sie übernimmt.
Damit verschiebt sich der Blick weg von der reinen Toolfrage. Die eigentliche Entscheidung lautet nicht: Welches Werkzeug ist moderner? Sondern: Wo liegt die belastbare Datengrundlage, und in welcher Schicht wird sie für die Analyse sinnvoll zugänglich gemacht?
Datenidentifikation ist eine Architekturfrage
Am Ende ist Datenidentifikation ein Entscheidungsprozess über Wahrheit, Zugriff und Verantwortung. Wer Daten für BI verwendet, muss wissen, woher sie kommen, wie sie entstehen und welche Schicht welche Aufgabe erfüllt. Das gilt für klassische Datenbanken ebenso wie für Web-Services, Dateien oder gekapselte Vorsysteme.
Der Gedankengang macht damit eine Grundlogik sichtbar, die später für jede weitere Modellierungsfrage wichtig bleibt: Ein BI-Modell ist nur so gut wie seine Herkunftsklärung. Wer die Quelle nicht versteht, kann weder die Ladeprozesse noch die Modellstruktur noch die spätere Auswertung sauber begründen.
Deshalb ist dieser Stoff ein guter Einstieg in den operativen Teil des Dashboard Creation Cycle. Er verschiebt den Fokus vom „Was wollen wir anzeigen?“ zum „Welche Daten dürfen überhaupt Grundlage sein?“. Und genau dort beginnt belastbare BI.
🎧 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/
