Warum die meisten Dashboards nicht an der Technik scheitern – sondern vorher

Ein neues Dashboard in Power BI oder Tableau wird ausgerollt. Die Farben stimmen, die Filter funktionieren, die Ladezeiten sind gut. Und trotzdem: Drei Monate später öffnet es kaum noch jemand. Kein Bug, kein Performance-Problem, keine falsche Tool-Wahl – und trotzdem ein gescheitertes Projekt.

Bei per Vibe Coding selbst zusammengebauten Dashboards ist das Risiko sogar noch größer: Weil KI-Tools inzwischen fast jede Idee technisch umsetzen können, wird oft gebaut, nur weil es geht – nicht, weil vorher geklärt wurde, ob es auch hilfreich oder richtig wäre, genau das umzusetzen.

Das ist kein Einzelfall. In der Praxis zeigt sich immer wieder derselbe Grund: Nicht die Technik war das Problem, sondern dass vor dem ersten Klick in Tableau, Power BI oder einem anderen Tool nie richtig geklärt wurde, was das Dashboard eigentlich zeigen und welche Frage es beantworten soll.

Technik ist selten der Engpass

Moderne BI-Tools können heute fast alles: komplexe Datenmodelle, Echtzeit-Updates, interaktive Visualisierungen, mobile Ansichten. Wenn ein Dashboard nicht funktioniert, liegt es so gut wie nie daran, dass die Technik es nicht hergegeben hätte.

Das eigentliche Risiko entsteht viel früher – nämlich dann, wenn ein Projekt direkt mit dem Bauen beginnt, ohne vorher zu klären:

• Wer soll dieses Dashboard überhaupt nutzen, und welche Fragen oder Probleme hat genau diese Zielgruppe, die das Dashboard lösen soll?
• Welche Entscheidung soll damit getroffen werden?
• Was bedeutet „Erfolg“ für genau diese eine Ansicht?

Fehlen diese Antworten, entsteht meist ein Dashboard, das technisch einwandfrei ist – aber niemandem hilft, schneller oder sicherer eine Entscheidung zu treffen. Und genau das ist der Moment, in dem Nutzer:innen zurück zu Excel wechseln oder das Dashboard schlicht ignorieren.

Die eigentliche Frage: Welches Problem soll gelöst werden?

Ein Dashboard ist kein Selbstzweck. Es ist ein Werkzeug, um eine konkrete Frage schneller und zuverlässiger zu beantworten als vorher. Diese Frage zu kennen, ist die eigentliche Vorarbeit – und genau hier setzt Requirements Engineering bzw. Business Analysis an.

Statt „Wir brauchen ein Vertriebsdashboard“ lautet die eigentlich entscheidende Frage: Welche drei Entscheidungen soll die Vertriebsleitung damit jede Woche treffen können – und welche Daten braucht sie dafür wirklich?

Diese Klärung kostet am Anfang Zeit. Sie spart aber genau die Zeit, die sonst in Nacharbeiten, Change Requests und ein zweites, drittes Redesign fließt, weil im ersten Anlauf etwas gebaut wurde, das an der eigentlichen Fragestellung vorbeigeht.

Ein Beispiel aus der Praxis

Ein Unternehmen möchte ein Dashboard, um den Vertrieb zu steuern. Der Auftrag lautet knapp: „Ein Sales-Dashboard mit Umsatz, Pipeline und Forecast.“ Ohne weitere Rückfragen wird gebaut – technisch sauber, mit ansprechenden Diagrammen, klar strukturiert.

Nach dem Rollout zeigt sich: Die Vertriebsleiter:innen schauen sich das Dashboard einmal an und öffnen es danach kaum wieder. Der Grund stellt sich erst im Nachgespräch heraus: Sie treffen ihre wichtigste wöchentliche Entscheidung – welche Kund:innen priorisiert bearbeitet werden – auf Basis von Veränderungen in der Pipeline, nicht auf Basis von Endständen. Das Dashboard zeigte zwar korrekte Zahlen, aber nicht die Zahlen, auf denen die eigentliche Entscheidung beruhte.

Eine kurze Anforderungsanalyse zu Beginn – wenige gezielte Gespräche mit den tatsächlichen Nutzer:innen – hätte diesen Punkt aufgedeckt, bevor auch nur eine einzige Visualisierung gebaut wurde.

Requirements Engineering als Fundament: Was das konkret bedeutet

Requirements Engineering für Dashboards muss kein aufwendiger, formaler Prozess sein. Im Kern geht es darum, vor der Entwicklung ein paar zentrale Fragen sauber zu beantworten:

• Wer nutzt das Dashboard konkret, und in welcher Situation?
• Welche Entscheidung oder Handlung soll dadurch unterstützt werden?
• Wie oft wird hineingeschaut – täglich, wöchentlich, nur im Monatsabschluss?
• Woran würde man festmachen, dass das Dashboard tatsächlich hilft?
• Was passiert aktuell ohne das Dashboard – welcher Workaround wird ersetzt?

Ein paar bewährte Methoden helfen dabei, diese Fragen strukturiert zu klären, ohne das Projekt zu verlangsamen:

• Stakeholder-Interviews: kurze, gezielte Gespräche mit den späteren Nutzer:innen statt nur mit dem Auftraggeber.
• 5-Why-Technik: Bei jeder gewünschten Kennzahl einmal mehr nachfragen, warum sie gebraucht wird – oft liegt die eigentliche Anforderung eine Ebene tiefer.
• User Stories für Dashboards: „Als [Rolle] möchte ich [Information], um [Entscheidung/Handlung] treffen zu können“ – eine einfache, aber wirksame Struktur, um Anforderungen konkret statt vage zu formulieren.
• Low-Fidelity-Prototyping: Ein grobes Layout auf Papier oder als Skizze mit den Nutzer:innen durchsprechen, bevor die erste Kennzahl in ein Tool gebaut wird.

Keine dieser Methoden erfordert Wochen an Vorlaufzeit. Meist reichen wenige, gut vorbereitete Gespräche, um die Richtung eines Projekts spürbar zu verändern.

Warum das gerade jetzt wichtiger wird

Mit KI-gestützten Tools lassen sich Dashboards inzwischen deutlich schneller umsetzen als noch vor einigen Jahren. Das klingt zunächst nach einem Vorteil – birgt aber ein Risiko: Wenn die zugrunde liegende Frage nicht klar ist, wird mit KI-Unterstützung nicht mehr Klarheit geschaffen, sondern lediglich schneller das Falsche gebaut. Die Geschwindigkeit der Umsetzung verändert nichts an der Notwendigkeit, vorher zu wissen, welches Problem eigentlich gelöst werden soll – im Gegenteil, sie macht eine solide Anforderungsklärung noch wertvoller.

Fazit

Ein Dashboard-Projekt beginnt nicht mit dem ersten Diagramm, sondern mit der Klärung, welche Frage beantwortet werden soll. Wer diesen Schritt überspringt, riskiert ein technisch tadelloses Dashboard, das trotzdem niemand nutzt. Wer ihn ernst nimmt, spart sich Nacharbeiten, Frust und teure Redesigns – und bekommt ein Werkzeug, das tatsächlich zu besseren Entscheidungen führt.

Wie sich der Erfolg eines gut konzipierten Dashboards anschließend auch in Euro ausdrücken lässt, haben wir im Beitrag zum ROI von Dashboards beschrieben.

Genau an diesem Punkt setzen wir bei M2 Data an: Bevor wir ein Dashboard in Tableau oder Power BI umsetzen, klären wir gemeinsam mit euch, welche Entscheidungen es unterstützen soll und welche Fragen es beantworten muss. In einem kompakten Requirements-Workshop – dem ersten Schritt in unserem Prozess – bringen wir genau diese Punkte auf den Tisch, bevor die erste Kennzahl gebaut wird. Meldet euch gerne, wenn ihr ein Dashboard-Projekt plant und sicherstellen wollt, dass es von Anfang an die richtigen Fragen beantwortet.