7. Oktober 2025/
Wir müssen erst die Datenbasis korrekt aufbauen. Danach können wir das Reporting optimieren Steffen Weiler – 07.10.2025 Hast du den...
Steffen Weiler – 07.10.2025
Hast du den folgenden Satz auch schon einmal gehört?
„Wir müssen erst die Datenbasis korrekt aufbauen. Erst dann können wir das Reporting optimieren.“
Das klingt erstmal total logisch. Jeder IT-Berater, jeder Datenbank-Admin, jeder Projektleiter wird dir das bestätigen.
Natürlich muss erst die Datenbasis stimmen.
Aber warum diese Denkweise gleichzeitig auch ein echter Projektkiller sein kann, das möchte ich dir heute einmal erklären.
Die klassische Herangehensweise „erst Daten, dann Reports“ führt zu fundamentalen Problemen, die viele BI-Projekte zum Stillstand bringen.
Das Data Warehouse wird monatelang entwickelt, die Entwicklung zieht sich träge hin und die Controller arbeiten weiter mit ihren manuellen Excel-Lösungen.
Kein Ende in Sicht, wann auf die neue Reporting-Umgebung umgestellt werden kann.
Die Fachbereiche können mit den bisherigen IT-Lösungen nichts anfangen.
Die KPIs, die sie brauchen, sind nicht abgebildet, die Strukturen passen nicht zu ihren Denkmodellen.
Diese sequenzielle Denkweise „erst Daten, dann Reports“ führt zu einem fundamentalen Problem, das ich das Henne-Ei-Dilemma nenne.
Die IT-Seite sagt: „Wir brauchen erst fachlichen Kontext, bevor wir die Datenstrukturen aufbauen können. Sagt uns, was ihr wollt, dann liefern wir die Daten.“
Die Fachseite antwortet: „Wir müssen erst mal die Daten sehen, bevor wir wissen, was überhaupt möglich ist. Zeigt uns doch erst mal die Daten und dann sagen wir euch, was wir brauchen.“
Beide Seiten warten aufeinander. Das Projekt steht still.
Das BI-Warteschleifen-Syndrom führt dazu, dass die jeweiligen Anforderungen von den unterschiedlichen Seiten vor sich hin tröpfeln.
Ehe du dich versiehst, ist wieder ein Monat vorbei, ohne dass sich wirklich etwas getan hat.
Die IT baut monatelang an einer theoretisch perfekten Datenstruktur, ohne zu wissen, ob sie später überhaupt gebraucht wird.
Die Fachbereiche werden ungeduldig, verlieren das Interesse und bauen sich ihre eigenen Schattenlösungen auf.
________________________
Ein typisches Beispiel: Die IT baut sechs Monate lang ein perfektes Financial Data Warehouse – mit Kostenstellen, allen Konten, allen historischen Daten, super historisiert, technisch sehr ausgereift.
Wenn das Dashboard dann endlich gebaut wird, stellt sich heraus: Der Controller braucht gar keine detaillierte Kostenstellen-Auswertung.
Er will nur drei einfache KPIs auf Executive Level und die wichtigsten Kostenstellen auf einen Blick sehen.
Das ganze komplexe Data Warehouse Projekt war völlig überdimensioniert.
________________________
Wenn du sagst „erst müssen die Daten perfekt sein“, dann kannst du ziemlich lange warten, weil Daten einfach nie perfekt sind.
IT-Teams arbeiten monatelang an der idealen Datenarchitektur.
Jede Tabelle ist normalisiert, jede Beziehung optimiert, jede Datenqualitätsregel implementiert.
Währenddessen sitzt der Fachbereich da und kann nichts machen.
Das Pareto-Prinzip gilt auch hier bei den Daten: 80% des Nutzens kommen aus 20% der Datenqualität.
Häufig verschwenden wir 80% der Zeit damit, die letzten 20% zu perfektionieren.
________________________
Du denkst fälschlicherweise, Datenqualität und Datenstruktur wären unabhängig vom Verwendungszweck definierbar.
Das ist ein Riesendenkfehler.
Gute Daten gibt es nicht abstrakt. Es gibt nur Daten, die für einen spezifischen Zweck geeignet sind oder nicht.
Ohne zu wissen, was am Ende damit gemacht werden soll, kannst du keine wirklich sinnvolle Datenarchitektur aufbauen.
Jede Analyse, die wir im BI fahren, ist am Ende für eine Entscheidung gedacht.
Gegebenenfalls fällt diese Entscheidung so aus, dass die Daten in der Zukunft gar nicht mehr erhoben werden müssen.
War es dann den Aufwand wert, direkt ein so großes Fass daraus zu machen?
Ein Unternehmen wollte ein Sales-Dashboard.
Die IT arbeitete mehrere Monate daran, alle Kundendaten zu bereinigen, Duplikate zu eliminieren, Adressdaten zu standardisieren. Super wichtige Arbeit, aber nicht für das Dashboard.
Das Dashboard brauchte eigentlich nur Umsatzzahlen nach Region und Produktgruppe.
Diese Daten waren schon nach zwei Wochen verfügbar und völlig ausreichend.
Aber weil man dachte, man baut ein sauberes Datenmodell mit korrekten Strukturen, dauerte das Projekt ein halbes Jahr länger.
Die Realität ist: Du wirst nie alle Datenprobleme lösen, bevor du nicht anfängst.
Es ist viel effektiver, mit unvollkommenen Daten zu starten und iterativ zu verbessern.
Der Reporting-First-Approach funktioniert genau umgekehrt:
Schritt 1: Fang mit dem gewünschten Ergebnis an – nicht mit den Daten, sondern mit dem, was am Ende rauskommen soll.
Schritt 2: Baue einen schnellen Prototyp – nicht zu lange in der Theorie bleiben, sondern schnell mit Prototypen starten.
Und sei es mit den Daten, die heute verfügbar sind, auch wenn sie nicht perfekt sind.
Hauptsache, du hast etwas zum Anfassen und Experimentieren.
Schritt 3: Lass die User damit arbeiten – die Stakeholder, die am Ende mit dem Bericht arbeiten sollen, werden dir schon sagen
Schritt 4: Iteriere immer wieder – verbessere den Report und die Datenqualität gezielt für den konkreten Anwendungsfall, nicht abstrakt.
Statt monatelang MIS-Daten zu bereinigen, wird in zwei Wochen der erste Prototyp gebaut – mit Excel-Exporten aus dem operativen System, mit manuellen Datenbereinigungen, nicht perfekt, aber funktional.
Der Produktionsleiter kann das sofort bewerten: „Das brauche ich, aber automatisiert. Hier fehlt noch etwas zur Schichtplanung, diese KPI ist überflüssig.“
Nach vier Wochen gibt es ein 80% perfektes Dashboard, nach acht Wochen sind die Datenflüsse automatisiert.
Warum funktioniert das besser?
Wichtiger Disclaimer: Das bedeutet nicht, dass Datenqualität unwichtig ist.
Es bedeutet nur, dass du sie gezielt und bedarfsgerecht angehst – nicht präventiv und abstrakt.
Quick Win #1: Das 48-Stunden-Dashboard
Setze dir als Ziel, innerhalb von 48 Stunden nach Projektstart ein erstes Dashboard zu haben.
Auch wenn es nur drei KPIs sind und die Daten aus Excel kommen – Hauptsache es ist visuell und die User können damit interagieren.
Das zwingt dich dazu, dich auf das Wesentliche zu konzentrieren und gibt dem Projekt sofort Momentum.
Quick Win #2: Die Prioritätenliste
Erstelle gemeinsam mit deinen Usern eine Liste: Was sind die drei wichtigsten Entscheidungen, die mit dem Dashboard getroffen werden sollen?
Alles andere ist erstmal zweitrangig.
Diese drei Entscheidungen definieren, welche Daten du brauchst – nicht mehr und nicht weniger.
Quick Win #3: Die Muss-Kann-Wird-Matrix
Teile deine Features in drei Kategorien:
Konzentriere dich in der ersten Version nur auf die Muss-Kriterien.
Nutze die 80-20-Regel konsequent: 80% des Nutzens kommen aus 20% der Features.
Identifiziere diese 20% und baue zuerst die.
Das bedeutet nicht, dass du schlampig arbeiten solltest, sondern dass du iterativ und nutzerorientiert vorgehst – statt theoretisch und perfektionistisch.
Warum „erst Datenbasis, dann Reporting“ problematisch ist
Die bessere Alternative – Der Reporting-First-Approach: Fang mit dem gewünschten Ergebnis an, baue schnelle Prototypen, lass die User damit arbeiten und iteriere basierend auf echtem Feedback.
________________________
BI-Projekte scheitern selten wirklich nur an der Technik, sondern vor allem an fehlender Nutzerakzeptanz.
Es ist vollkommen egal, ob du vier Wochen oder vier Jahre für die Datenintegration brauchst – am Ende kommt der entscheidende Moment:
Daran scheitern viele Reports. Und das ist schade, weil dann auch egal ist, wie viel Zeit reingeflossen ist.
Wenn du dafür sorgen willst, dass die Stakeholder die Reports lieben und wirklich als Asset ansehen, dann fokussiere dich auf den Nutzen, nicht auf die perfekte Technik.
Dieser Artikel basiert auf über zehn Jahren Erfahrung in Business Intelligence und Data Analytics. Für weitere BI-Insights und praktische Tipps folge mir auf LinkedIn oder höre den Daten zu Taten Podcast auf Spotify.
Im Podcast findest du die besten Experten rund um das Thema Power BI und Datenanalysen.
👉 Hier kommst du zur Folge:
Folge 13 – Wir müssen erst die Datenbasis korrekt aufbauen. Danach können wir das Reporting optimieren
Wir müssen erst die Datenbasis korrekt aufbauen. Danach können wir das Reporting optimieren Steffen Weiler – 07.10.2025 Hast du den...
Abo-Modell oder Time & Material: Was ist wirklich besser aus Kundensicht? Steffen Weiler – 23.09.2025 Bei der Auswahl eines Business...
Die besten Power BI Keyboard Shortcuts, die jeder Power BI Analyst kennen muss Steffen Weiler – 24.09.2025 Als Power BI...
Das solltest du in 2025 unbedingt können, um als Data Analyst Erfolg zu haben Steffen Weiler – 11.09.2025 Der Data...
Die 5 größten versteckten Kostentreiber fehlender BI-Struktur Steffen Weiler – 29.08.2025 Stell dir vor: Dienstag, 16:30 Uhr.Dein Chef kommt ins...
Ist jetzt noch der richtige Zeitpunkt, um sich im Power BI Bereich selbstständig zu machen? Steffen Weiler – 22.08.2025 „Steffen,...
