Die Idee eines Kennzahlen-Dashboards klingt zunächst hervorragend.
Ein Bildschirm. Ein paar Diagramme. Ampeln in Rot, Gelb und Grün. Und auf einen Blick weiß man, wo das Unternehmen steht.
Zumindest theoretisch.
In der Praxis beobachte ich etwas anderes: Viele Kennzahlensysteme produzieren vor allem eines – Reibung.
Die Daten liegen in der Buchhaltung. Andere Zahlen im Projektmanagement. Persönliche Ziele im Kalender. Finanzdaten wieder in einem anderen System. Bevor man weiß, wo man wirklich steht, muss man exportieren, kopieren, aktualisieren und Dateien öffnen.
Und genau dann passiert etwas sehr Menschliches: Man schaut irgendwann nicht mehr hin.
Wir beginnen bei Kennzahlen häufig am falschen Ende
Die typische Frage lautet: Welche Daten haben wir?
Dann bauen wir daraus Reports.
Ich glaube inzwischen, dass die Reihenfolge genau umgekehrt sein muss.
Die erste Frage lautet:
Welche Entscheidung möchte ich treffen?
Oder noch einfacher:
Welche Frage soll mir dieses Dashboard beantworten?
Das klingt nach einem kleinen Unterschied. Tatsächlich verändert es das gesamte System.
Denn unterschiedliche Fragen benötigen unterschiedliche Kennzahlen. Wenn ich wissen möchte, ob wir unsere Jahresziele erreichen, brauche ich andere Informationen als bei der Frage, ob unsere Liquidität bis Jahresende ausreicht. Und wenn ich wissen möchte, ob ich persönlich jeden Tag an meiner Meisterschaft arbeite, brauche ich wieder ein anderes System.
Warum sollte also ein einziges Dashboard all diese Fragen gleichzeitig beantworten?
Ein Dashboard. Eine Frage.
Unsere derzeitige Hypothese lautet deshalb:
Ein gutes Dashboard beantwortet eine klar definierte Frage – und zwar möglichst innerhalb weniger Sekunden.
Nicht zwanzig Fragen. Nicht alles, was theoretisch interessant sein könnte. Eine Frage.
Zum Beispiel: Bin ich auf Kurs, meine Jahresziele zu erreichen?
Oder: Reicht unsere Liquidität bei der derzeitigen Entwicklung bis Jahresende?
Oder ganz persönlich: Habe ich heute die Dinge getan, die mich meiner Meisterschaft näherbringen?
Die Kennzahlen ergeben sich erst danach.
Das ist für mich ein fundamentaler Unterschied zwischen Reporting und Führung. Reporting zeigt, was man messen kann. Ein gutes Kennzahlensystem zeigt, was man wissen muss.
Mehr Information ist nicht automatisch besser
Die Forschung zu Information Overload ist hier ziemlich eindeutig in ihrer Grundrichtung. Eppler und Mengis haben bereits 2004 Forschung aus Organisationswissenschaft, Accounting, Marketing und Informationssystemen zusammengeführt: Wenn die Menge und Komplexität der Information unsere Verarbeitungskapazität übersteigen, leidet die Qualität der Informationsverarbeitung.
Eine neuere Dashboard-Studie von Ke, Liao, Li und Luo untersuchte 2023 mit Eye-Tracking fünf unterschiedliche Informationslasten. Das Ergebnis ist für die Praxis interessant: Die Informationslast eines Dashboards beeinflusst die kognitive Belastung – und Menschen unterscheiden sich darin, wie effizient sie komplexe Dashboards verarbeiten. In dieser konkreten Untersuchung waren Teilnehmer bei neun oder mehr Informationsmodulen überfordert. Das ist keine universelle Neun-Kacheln-Regel. Aber es ist ein guter Warnhinweis gegen die verbreitete Annahme, mehr Kennzahlen würden automatisch mehr Kontrolle erzeugen.
Auch Experimente zur Darstellung von Unsicherheit zeigen: Unter kognitiver Belastung kann die Fähigkeit leiden, aus grafisch dargestellten Informationen die optimale Handlung abzuleiten – selbst wenn einzelne Werte noch korrekt gelesen werden.
Das Problem ist also nicht nur ästhetisch. Ein überladenes Dashboard kann genau die Entscheidung erschweren, die es eigentlich erleichtern soll.
Mein einfachstes Dashboard hätte genau drei Kennzahlen
Ich experimentiere gerade mit einem sehr einfachen persönlichen System.
Die Inspiration dafür kommt unter anderem von Cameron Hanes und seinem Prinzip:
“Lift. Run. Shoot.”
Drei Aktivitäten. Konsequent ausgeführt.
Bei mir sind es derzeit drei andere Dinge:
Sport.
Am Artikel arbeiten.
An Gesetzestexten arbeiten.
Dahinter steckt keine komplizierte Mathematik. Die eigentliche Frage lautet:
Habe ich heute an den drei Bereichen gearbeitet, in denen ich besser werden möchte?
Drei von drei? Der Tag ist grün.
Zwei von drei? Noch nicht ganz.
Null oder eins? Dann brauche ich auch keine ausgefeilte Analyse. Die Information ist eindeutig.
Interessanterweise liegen diese Daten teilweise bereits vor. Ich trage entsprechende Aktivitäten beispielsweise in meinen Google Kalender ein.
Das Problem ist also nicht zwingend die Datenerhebung. Das Problem ist die letzte Meile: Wie wird aus vorhandenen Daten ein sichtbares Signal?
Der größte Feind eines Kennzahlensystems ist Reibung
Wenn ich jeden Freitag eine Stunde investieren muss, um meine Kennzahlen zusammenzusuchen, habe ich kein funktionierendes Kennzahlensystem.
Ich habe einen zusätzlichen administrativen Prozess.
Und solche Prozesse sterben irgendwann.
Ein Kennzahlensystem muss deshalb möglichst automatisch entstehen. Im Idealfall läuft es so:
Die Aktivität findet statt.
Das bestehende System erfasst sie.
Die Daten werden automatisch übernommen.
Eine einfache Regel interpretiert sie.
Das Dashboard zeigt das Ergebnis.
Mehr sollte der Nutzer davon möglichst nicht mitbekommen.
Die Oberfläche ist dabei beinahe der unwichtigste Teil.
Vier Ebenen – in der richtigen Reihenfolge
Früher hätte ich vermutlich zuerst Excel geöffnet. Oder Power BI. Oder irgendein Reporting-Tool.
Heute würde ich zunächst vier Ebenen trennen.
Erstens: die Frage.
Was möchte ich wissen?
Zweitens: die Datenquelle.
Wo entsteht die Information ohnehin schon? Kalender? Buchhaltung? Bank? Projektmanagement? CRM? Datenbank?
Drittens: die Logik.
Wann ist das Ergebnis gut, schlecht oder kritisch?
Erst dann kommt:
Viertens: die Visualisierung.
Das Dashboard ist lediglich das Fenster auf das System. Nicht das System selbst.
Und genau hier wird KI interessant
Noch vor wenigen Jahren hätte eine individuelle Lösung schnell ein kleines IT-Projekt bedeutet: Anforderungen schreiben, Entwickler suchen, Schnittstellen definieren, Budget freigeben, Monate warten.
Für ein Dashboard mit vielleicht drei entscheidenden Kennzahlen.
Das Verhältnis zwischen Problem und Lösung war teilweise absurd.
Heute verändert sich diese Gleichung.
Google bietet mit Data Studio, vormals Looker Studio, weiterhin ein kostenloses Werkzeug für anpassbare Reports und Dashboards. Metabase bietet eine kostenlose Open-Source-Version mit mehr als 20 Datenquellen, unbegrenzten Fragen und Dashboards sowie KI-Funktionen. Appsmith bietet eine kostenlose Community-Edition als Open-Source-Low-Code-Plattform für eigene interne Anwendungen.
Aber das ist noch nicht der interessante Teil.
Der interessante Teil ist KI als Übersetzer zwischen Führungsfrage und technischer Umsetzung.
Ich muss nicht mehr zuerst wissen, welche Datenbankabfrage, API oder Automatisierung ich brauche. Ich kann mit der Frage beginnen: Zeig mir jeden Morgen, ob ich gestern meine drei Mastery-Aktivitäten erfüllt habe. Die Daten stehen im Kalender.
Dann kann KI beim Entwurf der Datenlogik helfen, Schnittstellen erklären, Code erzeugen, Fehler suchen und die kleine Anwendung iterativ mit mir bauen.
Genau wie bei anderen Themen, über die ich hier schreibe, sehe ich KI dabei nicht als Ersatz für Denken. Im Gegenteil: Die Qualität des Systems hängt stärker denn je davon ab, ob ich die richtige Frage stellen kann.
KI kann die letzte Meile dramatisch verkürzen. Sie entscheidet aber nicht, welche Kennzahl für mein Unternehmen relevant ist. Sie weiß auch nicht automatisch, wann eine Kennzahl beginnt, das Verhalten zu verzerren.
Die gefährliche Seite von Kennzahlen
Denn es gibt noch ein zweites Problem: Sobald wir Kennzahlen sichtbar machen, verändern sie Verhalten.
Die bekannteste Warnung dazu ist Goodhart’s Law. Marilyn Strathern formulierte es 1997 so:
“When a measure becomes a target, it ceases to be a good measure.”
Das ist für mein Drei-Punkte-System genauso relevant wie für Unternehmens-KPIs.
Wenn ich beispielsweise „Artikelarbeit“ nur danach messe, ob ich irgendeine Aktivität eingetragen habe, kann ich die Kennzahl erfüllen, ohne einen guten Artikel zu schreiben.
Die Kennzahl ist ein Signal. Nicht die Realität.
Deshalb sollten wir Dashboards nicht mit Wahrheit verwechseln. Sie sind bewusst reduzierte Modelle der Realität, gebaut für eine bestimmte Entscheidung.
Klein beginnen
Die Versuchung ist natürlich sofort da.
Wenn wir schon Datenbanken anbinden können, dann nehmen wir noch die Bank dazu. Und die Buchhaltung. Und Projekte. Und Portfolio. Und Mitarbeiterzahlen.
Und irgendwann bauen wir das Cockpit der Enterprise.
Genau das würde ich nicht tun.
Ich würde mit einer einzigen Frage beginnen.
In meinem Fall vielleicht:
Habe ich heute meine drei Mastery-Aktivitäten gemacht?
Die Daten kommen aus dem Kalender. Eine kleine Logik erkennt die drei Aktivitäten. Das Dashboard zeigt drei Felder. Sind alle erfüllt, wird der Tag grün.
Fertig.
Wenn dieses System tatsächlich jeden Tag genutzt wird, kann die nächste Frage hinzukommen.
Nicht vorher.
Die eigentliche Kennzahl ist Nutzung
Das führt zu einer unangenehmen Erkenntnis.
Ein perfektes Dashboard, das niemand regelmäßig anschaut, ist wertlos.
Ein primitives Dashboard mit drei Zahlen, das jeden Morgen eine Entscheidung verändert, ist dagegen extrem wertvoll.
Vielleicht sollten wir Kennzahlensysteme deshalb nicht danach beurteilen, wie viele Daten sie darstellen können. Sondern danach, wie schnell sie eine relevante Frage beantworten.
Meine derzeitige Faustregel wäre:
Wenn ich länger als zehn Sekunden brauche, um zu erkennen, ob Handlungsbedarf besteht, ist das Dashboard wahrscheinlich noch nicht gut genug.
Das ist keine wissenschaftlich validierte Schwelle. Es ist eine Designregel, die ich gerade teste.
Und wenn ich die Daten dafür jedes Mal manuell zusammensuchen muss, haben wir vermutlich noch gar kein Dashboard.
Wir haben nur einen Report.
Auf einen Blick wissen, wo man steht
Genau das wäre für mich das Ziel.
Nicht maximale Information.
Sondern minimale Distanz zwischen Realität und Erkenntnis.
Die Zahlen entstehen ohnehin. Die Systeme existieren ohnehin. Und mit den heutigen KI-, Low-Code- und Open-Source-Werkzeugen wird es immer einfacher, die letzte Verbindung selbst zu bauen.
Vielleicht besteht die nächste Generation von Kennzahlensystemen deshalb gar nicht aus einem gigantischen Management-Cockpit.
Vielleicht besteht sie aus vielen kleinen, extrem fokussierten Instrumenten.
Jedes davon beantwortet genau eine Frage:
Bin ich auf Kurs?
Kann ich mir das leisten?
Müssen wir eingreifen?
Habe ich heute getan, was notwendig war?
Mehr Daten machen Entscheidungen nicht automatisch besser.
Die richtigen Signale zur richtigen Zeit schon.
Und vielleicht ist genau das die wichtigste Frage an jedes Dashboard:
Wie schnell erkenne ich, dass ich handeln muss?
Literatur und Quellen
Eppler, M. J. & Mengis, J. (2004). The Concept of Information Overload: A Review of Literature from Organization Science, Accounting, Marketing, MIS, and Related Disciplines. The Information Society, 20(5), 325–344. DOI
Ke, J., Liao, P., Li, J. & Luo, X. (2023). Effect of information load and cognitive style on cognitive load of visualized dashboards for construction-related activities. Automation in Construction, 154, 105029. DOI
Allen, P. M., Edwards, J. A., Snyder, F. J. & Makinson, K. A. (2014). The effect of cognitive load on decision making with graphically displayed uncertainty information. Risk Analysis, 34(8), 1495–1505. DOI
Strathern, M. (1997). ‘Improving ratings’: audit in the British University system. European Review, 5(3), 305–321.
Google Cloud (2026). Data Studio / Looker Studio product documentation. Dokumentation
Metabase (2026). Pricing and Open Source Edition. Produktinformation
Appsmith (2026). Pricing and Community Edition. Produktinformation
Cameron Hanes. Lift Run Shoot – Trainingsprinzip und veröffentlichte Trainingsvideos.
Hinweis zur Entstehung: Dieser Artikel entstand in Zusammenarbeit mit KI. Die KI wurde als Recherche-, Sparrings- und Redaktionspartner eingesetzt. Auswahl der Fragestellung, Argumentation, persönliche Erfahrungen und finale Bewertung liegen bei mir.