In der letzten Folge haben wir über den Dashboard Creation Cycle gesprochen. Danach ist in den Kommentaren auf LinkedIn einiges passiert. Und genau dort möchte ich heute ansetzen.
Joachim hat beschrieben, wie er mit einer Nutzungsmatrix in Power BI arbeitet, um die tatsächliche Verwendung von Berichten messbar zu machen. Ein kontinuierlicher Verbesserungsprozess.
Harald hat angemerkt, dass die Anzahl der Dashboards in Projekten häufig wächst – die Qualität der Entscheidungen aber nicht zwingend mit. Seine Frage: Müssten wir nicht explizit festhalten, welche Entscheidungen wir mit einem Dashboard treffen wollen?
Und Claudine hat einen Punkt angesprochen, den ich selbst nur zu gut kenne, die Frage nach dem Owner eines Dashboards erzeugt oft fragende Blicke. Verantwortung wird gerne an die IT delegiert, obwohl die fachliche Verantwortung eigentlich in die Fachabteilung gehört.
All diese Punkte führen zurück zum Anfang des Cycles, den Anforderungen.
KPIs beginnen nicht im Bericht
Ich habe vor einiger Zeit einen Beitrag von Philipp von Loringhoven gesehen, der angelehnt an das Business Model Canvas, ein KPI-Canvas und später auch ein Report-Canvas entwickelt hat. Eine strukturierte Sammlung von Fragen, die uns zwingt, vor der Visualisierung zu denken.
Ein paar dieser Fragen:
- Wer nutzt diese KPI?
- Welche konkrete Frage beantwortet sie?
- Welche Limitationen hat diese Kennzahl?
- Welche Treiber beeinflussen sie – und welche Kennzahlen beeinflusst sie selbst?
- Was tun wir bei welchem Wert?
- Welchen Zielkorridor streben wir an?
- Wie berechnet sich die Kennzahl?
- Welche Datenquellen liegen zugrunde?
Das sind keine Formalismen. Das sind Klarstellungen.
Denn eine Kennzahl wird erst dann zur KPI, wenn sie mit Ziel, Kontext und Handlung verknüpft ist. Ansonsten bleibt sie ein isolierter Wert.
Von der Zahl zur Entscheidung
Besonders entscheidend finde ich die Frage: Was tun wir bei welchem Wert?
Wenn wir das nicht vorab definieren, beobachten wir Zahlen, aber wir steuern nicht.
Wir bauen Dashboards, aber wir verändern nichts.
Ein Dashboard sollte nicht aus „Lust an Visualisierung“ entstehen. Es sollte mit einer klaren Zielsetzung starten:
Was soll sich durch dieses Dashboard ändern?
Welche Entscheidung soll besser getroffen werden?
Woran messen wir, ob das funktioniert?
Und genau hier schließt sich der Kreis zu den Kommentaren:
- Nutzung messen ist gut.
- Ownership klären ist besser.
- Entscheidungsbezug definieren ist essenziell.
Verantwortung gehört in die Anforderung
Wenn wir bereits in der Anforderungsphase festhalten:
- Wer ist Owner?
- Welche Entscheidungen sollen getroffen werden?
- Wie messen wir den Nutzen?
- Welche Ziele verfolgen wir?
Dann haben wir später im Nutzungsschritt überhaupt erst eine Basis, um zu bewerten, ob unser Dashboard erfolgreich ist oder ob wir nachschärfen müssen.
Ansonsten entsteht genau das, was wir in vielen Projekten beobachten:
Wild wachsende Dashboard-Landschaften ohne klaren Zweck.
Canvas statt Chaos
Ich finde den Ansatz des KPI-Canvas und des Report-Canvas deshalb so wertvoll, weil er Struktur schafft, ohne überformalistisch zu sein. Man zwingt sich selbst, zentrale Fragen zumindest stichpunktartig zu beantworten. Man dokumentiert, wofür eine Kennzahl gedacht war. Man schafft Transparenz über Verantwortung.
Und vielleicht ist der nächste Schritt sogar, solche Grundfragen systematisch zu nutzen, etwa indem man sie als strukturierten Fragenkatalog einsetzt oder sogar durch einen Chatbot unterstützen lässt, der genau diese Punkte abfragt und schärft.
Die Werkzeuge sind da. Die Frage ist, nutzen wir sie?
Die Beiträge von Philipp von Loringhoven findest du hier:
Report-Canvas: https://www.linkedin.com/posts/philipploringhoven_neue-version-des-report-canvas-activity-7031530976593743872-qlZb/
🎧 Die komplette Folge findest du im thinkBI Podcast.
Mich interessiert: Wie lebt ihr Anforderungen in euren Projekten?
Gibt es bei euch klare Definitionen von Entscheidung, Zielwert und Ownership oder entstehen KPIs eher situativ?
Denn am Ende bleibt für mich ein Gedanke: Eine KPI ist nur dann wertvoll, wenn wir vorher wissen, wofür.
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/
