Im thinkBI Podcast schließt Folge 020 direkt an die Diskussion zur Datenidentifikation an. Diesmal geht es weniger um eine weitere Technikfrage als um eine notwendige Korrektur: Wie verhalten sich fachliche Anforderung, semantisches Modell und technische Systemrealität eigentlich zueinander?
Die zugespitzte Antwort lautet: Gute BI braucht einen Mittelweg. Weder reicht es, Fachlichkeit einfach als Idealbild zu behandeln, noch genügt es, sich an den vorhandenen technischen Strukturen festzuklammern. Beides führt in Sackgassen.
Wenn Self-Service die Anforderung verdrängt
In vielen Organisationen lässt sich ein bekanntes Muster beobachten. Erst wird gefordert, dass Fachbereiche mehr selbst machen sollen. Dann entstehen Self-Service-Strukturen, die Geschwindigkeit versprechen und die Last zwischen Anforderer und Umsetzer reduzieren sollen. Der Gedanke ist nicht falsch. Problematisch wird er dort, wo aus Befähigung Bastelarbeit wird.
Dann wird gebaut, ohne die zugrunde liegenden Prozesse wirklich zu verstehen. Anforderungen werden nicht sauber beschrieben, vorhandene Systeme nicht ernsthaft geprüft und Begriffe nicht geklärt. Die Organisation gewinnt scheinbar Tempo, verliert aber Orientierung. Was sichtbar wird, ist Aktivität. Was fehlt, ist saubere Erkenntnisarbeit.
Das ist kein Argument gegen Self-Service. Es ist ein Argument gegen ein falsches Verständnis von Self-Service. Fachbereiche dürfen nicht allein gelassen werden mit Werkzeugen, die operative Freiheit versprechen, aber keine gedankliche Führung mitliefern. Gute BI braucht deshalb beides: eigene Handlungsfähigkeit dort, wo sie sinnvoll ist, und zentrale Struktur dort, wo Begriffe, Modelle und wiederverwendbare Logiken sauber gehalten werden müssen.
Das semantische Modell ist nicht einfach das Vorsystem
Die Rückmeldung aus der Community trifft deshalb einen wichtigen Punkt: Das semantische Modell sollte nicht von der technischen Struktur des Vorsystems diktiert werden. Wenn BI nur nachbaut, was ein operatives System zufällig vorgibt, entsteht noch kein gutes analytisches Modell.
Der Weg im Dashboard Creation Cycle ist gerade deshalb sinnvoll aufgebaut. Zuerst kommt die Anforderung. Dann folgt ein Prototyp oder eine fachliche Sicht auf die spätere Nutzung. Danach wird ein semantisches Modell beschrieben, das die fachliche Logik trägt. Erst dann stellt sich verschärft die Frage, wo die Daten dafür tatsächlich herkommen.
Genau hier liegt aber die Spannung. Fachlichkeit beschreibt oft ein sinnvolles Zielbild. Das Vorsystem zeigt dagegen, wie Prozesse wirklich implementiert wurden. Beides ist nicht automatisch deckungsgleich. Wer nur auf die Fachlichkeit hört, läuft Gefahr, eine schöne Idealwelt zu modellieren, die technisch so gar nicht existiert. Wer nur auf die Technik schaut, übernimmt bestehende Systemgrenzen und verwechselt sie mit fachlicher Wahrheit.
BI braucht deshalb Übersetzungsarbeit. Fachlichkeit muss führen, weil sie erklärt, was für das Geschäft eigentlich relevant ist. Technik begrenzt, weil sie zeigt, welche Daten in welcher Form tatsächlich vorliegen, welche Nuancen ein System erzwingt und wo der Rohzustand der Daten beginnt.
Wofür bauen wir eigentlich eine Datenplattform?
An diesem Punkt wird auch die Rolle von Datenplattformen interessant. Viele Plattformen entstehen IT-getrieben. Datenquellen werden integriert, Schichten aufgebaut, Ladeprozesse definiert. Technisch kann das sehr sauber wirken. Trotzdem bleibt oft eine entscheidende Frage unterbelichtet: Für wen wird diese Struktur eigentlich gebaut?
Wenn das Ziel eine bessere analytische Nutzung im Business ist, dann reicht es nicht, Daten nur zentral abzulegen. Sie müssen so bereitgestellt werden, dass daraus verständliche, belastbare analytische Strukturen entstehen können. Eine Plattform, die lediglich technische Tabellen sammelt, erfüllt ihren Zweck nur zur Hälfte.
Gerade hier entsteht in Projekten häufig Reibung. Teams, die Plattformen verantworten, liefern Daten gern in einer Form aus, die für ihre technische Logik sinnvoll ist. BI-Teams oder Fachbereiche brauchen dieselben Daten aber in einer Form, die semantisch konsumierbar ist. Nicht als wilde Sammlung technischer Tabellen, sondern als geordnete Grundlage für Dimensionen, Fakten und analytische Beziehungen.
Das sind keine gegensätzlichen Welten. Es sind zwei Ebenen derselben Verantwortung. Die Plattform soll Daten verlässlich, nachvollziehbar und wartbar halten. Gleichzeitig muss sie anerkennen, dass ihr eigentlicher Zweck nicht in der technischen Selbstgenügsamkeit liegt, sondern in der Bereitstellung für fachlich sinnvolle Nutzung.
Schichten sind kein Selbstzweck
Die naheliegende Antwort darauf ist eine Schichtenarchitektur. Unten liegen rohe, vorsystemnahe Daten. Darüber können technische oder leicht bereinigte Langzeitschichten entstehen, in denen Historie, Anreicherung und Stabilisierung organisiert werden. Erst weiter oben entsteht dann die Ebene, die für ein semantisches Modell oder ein Sternschema wirklich konsumierbar ist.
Entscheidend ist aber nicht die Anzahl der Schichten. Entscheidend ist ihre Funktion. Eine Schicht ist nur dann sinnvoll, wenn klar ist, welche Verantwortung sie übernimmt. Rohe Nähe zur Quelle, technische Konsolidierung und fachliche Bereitstellung sind nicht dasselbe. Wer diese Ebenen vermischt, baut zwar Infrastruktur, aber noch keine belastbare Informationsarchitektur.
Damit verschiebt sich der Blick auf eine ruhigere, aber wichtigere These: Gute BI ist weder die direkte Herrschaft der Fachlichkeit noch die Herrschaft der Technik. Gute BI ist die Disziplin, beide Seiten so zusammenzuführen, dass ein fachlich korrektes und technisch tragfähiges System entsteht.
Das ist mehr als ein methodischer Hinweis. Es ist eine Klarstellung darüber, was Business Intelligence organisatorisch leisten muss. Nicht nur Daten sichtbar machen, sondern zwischen Wunschbild und Systemwirklichkeit vermitteln. Nicht nur Plattformen bauen, sondern Verantwortung für nutzbare Strukturen übernehmen. Nicht nur Self-Service erlauben, sondern Denken und Modellierung so führen, dass Freiheit nicht in Beliebigkeit kippt.
Vielleicht liegt genau darin die eigentliche Reife von BI: nicht in maximaler Zentralisierung und nicht in maximaler Dezentralisierung, sondern in der Fähigkeit, einen belastbaren Mittelweg zu gestalten.
🎧 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/
