In dieser Folge möchte ich mit dir über eine Denkgewohnheit sprechen, die wir in Business Intelligence selten hinterfragen. Wir behandeln Dashboards wie Projekte. Es gibt eine Anforderung. Es gibt eine Umsetzung. Es gibt eine Übergabe. Und irgendwann gilt das Ganze als „fertig“.
Aber genau hier liegt aus meiner Sicht ein Denkfehler. Ein Dashboard ist kein Projekt. Es ist ein Zyklus.
Vor einiger Zeit habe ich für mich den sogenannten Dashboard Creation Cycle formuliert. Kein offizielles Framework. Kein Lehrbuchmodell. Sondern ein strukturiertes Denkmodell, das beschreibt, wie Dashboards tatsächlich entstehen – wenn man es bewusst angeht.
Die folgende Darstellung zeigt diesen Zyklus:
Was du hier siehst, ist kein linearer Ablauf. Es ist ein Kreislauf – mit zwei zentralen Spannungsfeldern:
Planung vs. Umsetzung
Fachabteilung vs. IT
Business Intelligence bewegt sich genau zwischen diesen beiden Achsen.
Die Anforderung – Fachlichkeit zuerst
Der Zyklus beginnt typischerweise im Fachbereich. Es gibt eine Fragestellung. Ein Steuerungsbedürfnis. Einen Wunsch nach Transparenz.
Hier geht es noch nicht um Tools. Hier geht es um Verstehen.
Welche Entscheidung soll unterstützt werden?
Welche Kennzahlen sind relevant?
Was bedeutet „Erfolg“ in diesem Kontext?
Wenn diese Phase übersprungen oder oberflächlich behandelt wird, ist alles Weitere nur noch Kosmetik.
Dashboard Prototyping – Denken vor Technik
Der nächste Schritt ist aus meiner Sicht entscheidend, das Prototyping. Und bewusst nicht im Tool. Ich spreche hier gerne von Paper Prototyping. Werkzeugunabhängig. Frei von technischen Restriktionen.
Wie soll das Dashboard aussehen?
Wie bewegt sich der Nutzer darin?
Welche Navigation ergibt Sinn?
Solange wir noch im Konzept sind, sollten wir uns nicht durch technische Limitationen einschränken lassen.
Datenmodell-Konzept – die strukturelle Grundlage
Spätestens hier wird es technischer. Ausgehend vom Prototyp leiten wir ab:
Welche Dimensionen brauchen wir?
Welche Fakten?
Welche Beziehungen?
Datum, Kunde, Produkt, Kostenstelle, Projekt, usw. Hier entsteht die Struktur. Und hier liegt ein zentraler Punkt, den ich immer wieder betone:
Self-Service beginnt nicht im Bericht.
Self-Service beginnt im Datenmodell.
Ein sauber designtes Modell ist die Voraussetzung dafür, dass Fachbereiche eigenständig arbeiten können.
Datenidentifikation und Datenaufbereitung
Nun müssen wir konkret werden. Wo liegen die Daten? ERP-Systeme, CRM-Systeme, Dateien, Datenbanken, APIs, usw. Die Daten gehören fachlich dem Business, technisch sind sie aber häufig in der IT verortet.
Wir identifizieren die Quellen.
Wir definieren Ladeprozesse.
Wir automatisieren die Aktualisierung.
Ein Dashboard ohne reproduzierbaren Datenfluss ist kein Produkt, es ist ein Experiment.
Datenmodell-Erstellung und Dashboard-Umsetzung
Jetzt setzen wir das konzipierte Modell technisch um.
Wir transformieren Daten.
Wir definieren Berechnungen.
Wir setzen Beziehungen.
Erst danach entsteht das Dashboard im Werkzeug, auf Basis des zuvor geplanten Prototyps. Wenn Visualisierungen technisch nicht umsetzbar sind, stehen wir vor einer Entscheidung:
Erweitern wir das Tool?
Oder passen wir das Konzept an?
Auch das ist Teil eines bewussten Prozesses.
Nutzung und der eigentliche Anfang
Der spannendste Teil ist nicht die Fertigstellung. Es ist die Nutzung.
Das Dashboard wird bereitgestellt.
Die Daten werden regelmäßig aktualisiert.
Der Fachbereich arbeitet damit.
Und fast immer entstehen daraus neue Anforderungen.
Neue Fragen.
Neue Perspektiven.
Neue Erweiterungen.
Und genau hier schließt sich der Kreis.
Wir starten wieder bei der Anforderung.
Wir durchlaufen Prototyping.
Wir passen das Modell an.
Wir erweitern das Produkt.
Weg vom Projektdenken
Wenn wir ehrlich sind, dann ist ein Dashboard nie „fertig“. Es reift. Es entwickelt sich weiter. Es passt sich an. Genau deshalb ist es kein Projekt, sondern ein Zyklus.
Und vielleicht ist das der eigentliche Perspektivwechsel. Statt Dashboards auszuliefern, entwickeln wir Datenprodukte.
Iterativ. Strukturiert. Im Zusammenspiel von Fachbereich und IT.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Wie arbeitet ihr heute? Habt ihr einen klar definierten Prozess?
Oder entsteht vieles implizit, in den Köpfen einzelner Personen?
Vielleicht ist es an der Zeit, euren eigenen Dashboard Creation Cycle einmal explizit zu formulieren. Ich bin gespannt auf deine Gedanken dazu.
thinkBI Essentials
Kernaussagen
- Ein Dashboard ist kein einmaliges Umsetzungsprojekt, sondern ein fortlaufender Zyklus aus Anforderung, Modellierung, Umsetzung und Nutzung.
- Gute BI beginnt nicht mit dem Werkzeug, sondern mit der fachlichen Frage und einem bewusst gedachten Prototyp.
- Self-Service entsteht nicht erst im Bericht, sondern auf der Grundlage eines tragfähigen Datenmodells.
- Der eigentliche Wert eines Dashboards zeigt sich erst im Betrieb, wenn Nutzung neue Fragen erzeugt und das Datenprodukt gezielt weiterentwickelt wird.
Begriffe aus diesem Beitrag
Dashboard Creation Cycle
Der Dashboard Creation Cycle ist ein Denkmodell für die wiederkehrenden Phasen der Dashboard-Entwicklung. Er macht sichtbar, dass Anforderungen, Datenmodell, technische Umsetzung und Nutzung nicht linear nacheinander enden, sondern sich fortlaufend gegenseitig beeinflussen.
Paper Prototyping
Paper Prototyping beschreibt die konzeptionelle Gestaltung eines Dashboards vor der technischen Umsetzung. Im BI-Kontext hilft es, Navigation, Informationslogik und Visualisierungsstruktur zu klären, bevor Toolgrenzen das Denken verengen.
Datenmodell
Ein Datenmodell organisiert Fakten, Dimensionen und Beziehungen so, dass fachliche Fragen sauber beantwortbar werden. Für Business Intelligence ist es die strukturelle Voraussetzung dafür, dass Berichte belastbar und Self-Service überhaupt sinnvoll möglich werden.
Datenprodukt
Ein Datenprodukt ist mehr als ein einzelner Bericht oder ein technisches Artefakt. Es verbindet fachlichen Nutzen, stabile Datenversorgung und kontinuierliche Weiterentwicklung zu einem dauerhaft nutzbaren Bestandteil der Entscheidungsunterstützung.
Weiterdenken
- An welcher Stelle behandeln wir Dashboards heute noch wie abgeschlossene Lieferobjekte statt wie entwickelbare Datenprodukte?
- Wo fehlen in unserem Prozess die saubere Verbindung zwischen Fachfrage, Prototyp und Datenmodell?
- Verwandtes Thema: Self-Service beginnt im Datenmodell
- Verwandtes Thema: Datenprodukte zwischen Fachbereich und IT
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/
