Power BI · Blog

Wir müssen erst die Datenbasis korrekt aufbauen. Danach können wir das Reporting optimieren

· 8 Min Lesezeit · Steffen Weiler
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 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.

Das Problem der sequenziellen Denkweise 

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.
Was passiert, wenn beide Seiten aufeinander warten? - Das Henne-Ei-Dilemma

Problem Nr. 1: Das Henne-Ei-Dilemma

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.

 ________________________

Das Controlling-Dashboard Dilemma

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.

 ________________________

Problem Nr. 2: Die Perfektionismus-Falle

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.

 ________________________

Der fundamentale Denkfehler

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?
Was braucht ein Sales-Dashboard wirklich?

Sales-Dashboard Beispiel

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. ________________________

Die bessere Lösung: Der Reporting-First-Approach

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.
  • Welche Entscheidungen sollen getroffen werden?
  • Welche KPIs sind wirklich relevant?
  • Wie soll das Dashboard am Ende aussehen?
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
  • was fehlt
  • was überflüssig ist
  • was anders sein soll
Schritt 4: Iteriere immer wieder – verbessere den Report und die Datenqualität gezielt für den konkreten Anwendungsfall, nicht abstrakt.
Ein schnelleres Produktreporting kann der bessere Weg sein

Produktionsreporting in 8 Wochen statt 6 Monaten

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?
  • Erstens: Du bekommst sofortiges Feedback und siehst, welche Daten wirklich gebraucht werden.
  • Zweitens: Die User bleiben motiviert, sie sehen von Anfang an Fortschritte.
  • Drittens: Du optimierst nur dort, wo es wirklich notwendig ist – kein Overengineering.
  • Viertens: Das Projekt wird viel schneller. Statt einem Jahr Vorbereitung hast du schon nach einem Monat die ersten Ergebnisse.
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.
Mit diesen Quick Wins wird dein Projekt erfolgreich

Drei konkrete Quick Wins für dein nächstes Projekt

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:
  • Muss-Kriterien: Ohne diese funktioniert das Dashboard nicht
  • Kann-Kriterien: Wäre schön, aber nicht kritisch
  • Wird-Kriterien: Kommt später, wenn Zeit und Budget da sind
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.

Zusammenfassung:

Warum "erst Datenbasis, dann Reporting" problematisch ist
  • Problem 1 – Das Henne-Ei-Dilemma: Beide Seiten warten aufeinander, das Projekt steht still.
  • Problem 2 – Die Perfektionismus-Falle: Du wartest ewig auf perfekte Daten, die es nie geben wird.
  • Problem 3 – Over-Engineering: Du baust komplexe Lösungen für Probleme, die gar nicht existieren.
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.

 ________________________

Der entscheidende Punkt zum Schluss

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:
  • Arbeiten die Personen mit den Daten?
  • Nutzen sie das Dashboard?
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

Du möchtest prüfen, wie fortschrittlich dein Unternehmen im Bereich Datenanalyse ist?

Jetzt BI-Score berechnen & Optimierungspotenziale entdecken! Vorheriger Beitrag
  • All Posts
  • Allgemein
Load More End of Content.