Kennzahlen-Dashboards mit Excel erstellenProfessionelle Dashboard-Projekte – so gehen Sie vor

Der Ablauf: Ein gutes Dashboard beginnt nicht in Excel

Viele Dashboard-Projekte starten mit einer Excel-Datei. Daten werden importiert, erste Pivot-Tabellen angelegt, Diagramme ausprobiert und Farben festgelegt. Nach kurzer Zeit sieht das Ergebnis bereits nach einem Dashboard aus.

Offen ist zu diesem Zeitpunkt oft das Entscheidende:

• wofür das Dashboard gebraucht wird,
• woher die Daten kommen und
• wer sich später um Aktualisierung und Änderungen kümmert.

Ein professionelles Dashboard-Projekt beginnt deshalb nicht mit einem Diagramm, sondern mit dem fachlichen Auftrag. Erst wenn Ziel, Nutzer und Informationsbedarf geklärt sind, folgen Kennzahlen, Daten, Architektur und Gestaltung.

Das Erstellen eines Dashboards ist ein Prozess – von der ersten Idee bis zum laufenden Betrieb. Die einzelnen Schritte, die im Folgenden erläutert werden (siehe folgende Abbildung), können Sie direkt auf Ihre Dashboard-Projekte übertragen.

Auftrag und Ziel klären

„Wir brauchen ein Vertriebsdashboard“ klingt nach einem Auftrag, ist aber zunächst nur ein Wunsch. Für die Umsetzung muss daraus eine konkrete Aufgabenstellung werden.

• Wer nutzt das Dashboard?
• Wie oft wird es gebraucht?
• Welche Entscheidungen soll es unterstützen?

Eine brauchbare Aufgabenstellung könnte lauten: Die Vertriebsleitung soll monatlich erkennen, ob Umsatz und Deckungsbeitrag im Plan liegen, welche Regionen wesentlich abweichen und welche Kunden oder Produkte diese Entwicklung erklären.

Damit stehen Nutzer, Zweck, Rhythmus und Analyseebenen fest. Zusammen mit Auftraggeber, Datenquelle, Nutzungsumgebung und Verantwortlichkeit gehören diese Angaben in einen kurzen Projektsteckbrief (siehe folgende Tabelle).

Halten Sie diesen Steckbrief auf einem eigenen Blatt der Projektmappe fest. Er ist später eine einfache Referenz, wenn neue Wünsche hinzukommen.

Anforderungen fachlich formulieren

Aus dem Projektziel und der Aufgabenstellung wird nun ein Anforderungskatalog. Eine Rückfrage hilft dabei immer wieder:

„Welche Entscheidung wollen Sie mit dieser Information treffen?“

Aus dem Wunsch „Wir hätten gerne eine Karte mit unseren Regionen“ kann so die fachliche Anforderung werden: „Wir möchten schnell erkennen, welche Regionen ihre Umsatzziele verfehlen.“

Ob dafür eine Karte, ein Balkendiagramm oder eine Tabelle am besten geeignet ist, bleibt erst einmal offen. Das entscheidet sich erst beim Entwurf des Dashboards.

Außerdem werden im Anforderungskatalog festgehalten:

• Filter
• Betrachtungszeiträume
• Vergleichswerte
• Detailebene

Teilen Sie die Anforderungen in Muss, Soll und Kann ein. So bleibt klar, was in die erste Version gehört, und das Projekt wächst während der Umsetzung nicht unkontrolliert weiter.

Kennzahlen eindeutig definieren

Spätestens bei den Kennzahlen zeigt sich, wie unterschiedlich scheinbar eindeutige Begriffe verstanden werden können. „Umsatz“ kann fakturierten Umsatz, Auftragseingang oder Umsatz nach Retouren meinen. Auch die Frage nach Netto- oder Bruttowerten sowie internen Umsätzen muss geklärt sein.

Jede zentrale Kennzahl erhält deshalb einen KPI-Steckbrief wie das folgende Beispiel:

Die Zeile „Bewertung“ legt fest, ab wann eine Abweichung als „wesentlich“ gilt. Genau diese Schwelle muss mit dem Auftrag geklärt werden. Fehlt sie, entscheidet später das Augenmaß, welche Region im Dashboard hervorgehoben wird.

Alle Steckbriefe zusammen bilden den KPI‑Katalog. Er sorgt dafür, dass dieselbe Kennzahl überall gleich berechnet wird, und ist die erste Anlaufstelle, wenn sich eine Definition ändert.

Datenquellen und Datenqualität prüfen

Erst jetzt geht es um die Daten. Bevor die erste Abfrage in Power Query entsteht, sollte klar sein, welche Quellen es gibt und wie verlässlich sie sind:

• Welche Quellen werden benötigt und wer stellt sie bereit?
• Wann und wie oft liefern sie neue Daten?
• Bleibt die Struktur der Dateien oder Tabellen stabil?
• Gibt es eindeutige Schlüssel für Kunden, Produkte oder Kostenstellen?
• Sind Zeiträume vollständig?
• Gibt es fehlende oder doppelte Datensätze?

Ein typischer Stolperstein sind Bezeichnungen. Steht ein Kunde in verschiedenen Quellen einmal als „Müller GmbH“, einmal als „Müller GmbH & Co. KG“ und an anderer Stelle als „Kunde 4711“, sollte die Verknüpfung nicht über den Namen erfolgen. Eine stabile Kunden-ID ist dafür die bessere Grundlage.

Solche Probleme fallen sonst erst auf, wenn das Dashboard wie fertig aussieht. Dann nützt die schönste Oberfläche wenig, weil sich die Daten nicht zuverlässig zusammenführen lassen.

Die technische Architektur festlegen

Sind Anforderungen, Kennzahlen und Quellen geklärt, folgt ein Konzept für den technischen Aufbau. Für viele Excel-Dashboards bewährt sich eine Verarbeitungskette, die Daten, Berechnung und Darstellung sauber voneinander trennt.

Nicht jedes Projekt braucht alle Ebenen. Wichtig ist, dass Rohdaten, manuelle Eingaben, Berechnungen und Darstellung nicht unkontrolliert vermischt werden.

Die Blätter README und Parameter gehören zu keiner Stufe der Kette, sondern begleiten sie: Das eine dokumentiert die Lösung, das andere nimmt Einstellungen wie Dateipfade auf.

Eingabebereiche lassen sich zusätzlich per Blattschutz vor versehentlichem Überschreiben bewahren. Einen Zugriffsschutz ersetzt das nicht: Der Schutz auf Blattebene ist kein Sicherheitsfeature, er verhindert nur das Ändern gesperrter Zellen. Vertrauliche Daten schützen Sie mit einer Dateiverschlüsselung per Kennwort oder mit Information Rights Management (IRM).

In diese Phase gehört auch die Aktualisierung:

• Wo liegen die Quelldateien?
• Ändern sich Dateinamen oder Pfade?
• Welche Schritte sollen beim Aktualisieren automatisch laufen?

Eng damit verbunden ist die Frage, mit welcher Excel-Version und an welchem Ort das Dashboard genutzt wird. In Excel für das Web lassen sich Abfragen auf lokale Dateien nicht aktualisieren, und Abfragen, die in das Datenmodell laden, werden dort derzeit ebenfalls nicht aktualisiert.

In Excel für Mac steht das Datenmodell gar nicht zur Verfügung. Wer im Browser oder am Mac arbeitet, bestimmt also mit, welche Werkzeuge infrage kommen.

Das Dashboard entwerfen, bevor es gebaut wird

Bevor Zeit in die Formatierung von Diagrammen fließt, entsteht ein Wireframe – eine einfache Skizze des späteren Dashboards. Sie zeigt, welche Information wo steht.

Farben und Schriftarten spielen dabei noch keine Rolle. Geprüft werden Informationshierarchie und Bedienung:

• Stehen die wichtigsten Aussagen oben?
• Ist die Leserichtung nachvollziehbar?
• Sind die Filter dort, wo man sie erwartet?
• Was kann weg?

Beachten Sie: Passen Kopf- und Analysebereich nicht auf eine Bildschirmseite, sollten Sie Inhalte streichen oder in den Detailbereich verschieben.

Solche Änderungen sind im Wireframe in wenigen Minuten erledigt. Im fertig formatierten Dashboard kosten sie deutlich mehr Zeit.

Mit einem Prototyp früh Rückmeldung holen

Aus dem Wireframe entsteht ein erster funktionsfähiger Prototyp. Dafür reicht oft ein kleiner, aber realistischer Datenbestand. Der Prototyp muss noch nicht gut aussehen; er soll zeigen, ob das Konzept trägt.

Erst an einer konkreten Lösung merken Anwender häufig, was ihnen fehlt. Aus „Wir brauchen eine Analyse nach Region“ wird beispielsweise „Wir müssen von der Region bis zum einzelnen Kunden heruntergehen können.“

Solche Rückmeldungen sollen vor der endgültigen Umsetzung kommen, nicht danach. Halten Sie nach der Abstimmung fest, welche Anforderungen in die freigegebene Version einfließen. Gegen diesen Stand wird später getestet.

Die freigegebene Lösung umsetzen

Erst mit diesem Schritt werden Datenaufbereitung, Berechnungen und Darstellung vollständig aufgebaut. Welche Werkzeuge dabei zum Einsatz kommen, hängt von Datenmenge und Anforderungen ab:

• Excel-Tabellen für strukturierte Daten
• Power Query für Import und Transformation
• Datenmodell beziehungsweise Power Pivot für relationale oder umfangreichere Datenbestände
• Pivot-Tabellen für flexible Auswertungen
• Diagramme, Pivot-Charts, Slicer und Zeitachsen
• Formeln und bedingte Formatierung für ergänzende Berechnungen und Hervorhebungen

Nicht jedes Dashboard braucht Power Pivot, und nicht jede Kennzahl eine aufwendige Formel. Eine einfache, nachvollziehbare Lösung ist im Betrieb oft mehr wert als eine raffinierte Konstruktion, die später niemand mehr ändern kann.

Kommt das Datenmodell zum Einsatz, legen Sie die Kennzahlen aus dem KPI-Katalog als explizite Measures an.

• Implizite Measures, die Excel beim Ziehen eines Feldes in den Wertebereich erzeugt, gelten nur für die jeweilige Pivot-Tabelle.
• Explizite Measures stehen dagegen in jeder Pivot-Tabelle und jedem Pivot-Chart der Arbeitsmappe zur Verfügung.

So wird jede Kennzahl genau einmal berechnet – und zwar so, wie es im Steckbrief steht.

Fachlich und technisch testen

Ein Dashboard ist nicht fertig, sobald die sichtbaren Zahlen plausibel wirken. Der Test muss sowohl die fachlichen Ergebnisse als auch das Verhalten der Arbeitsmappe abdecken. Nutzen Sie dafür die folgende Übersicht.

Am meisten verrät der Aktualisierungstest mit Daten, die bei der Entwicklung noch nicht vorlagen. Erst dann zeigt sich, ob Abfragen, Bereiche und Berechnungen wirklich dynamisch aufgebaut sind.

Performance und Robustheit prüfen

Mit wachsender Datenmenge kann eine fachlich korrekte Arbeitsmappe im Alltag trotzdem unbrauchbar werden. Lange Ladezeiten, träge Filter oder langsame Neuberechnungen sind ein Anlass, die Struktur noch einmal zu prüfen.

Typische Ansatzpunkte sind:

• überflüssige Spalten und Zeilen in Power Query,
• zu große Formelbereiche,
• volatile Funktionen,
• redundante Pivot Caches,
• zu viele bedingte Formatierungen oder
• ein unnötig komplexes Datenmodell.

Stellschrauben dafür sind: BEREICH.VERSCHIEBEN lässt sich oft durch INDEX ersetzen, INDIREKT durch WAHL. Mit Strg + Ende sehen Sie außerdem, ob der benutzte Bereich eines Blatts weit über die tatsächlichen Daten hinausgewachsen ist.

Optimierung ist dabei kein Selbstzweck. Entscheidend ist, dass Aktualisierung, Filter und Bedienung im vorgesehenen Einsatz zuverlässig und schnell genug funktionieren.

Abnahme und Übergabe vorbereiten

Nach erfolgreichem Test folgt die fachliche Abnahme. Der Fachbereich bestätigt, dass

• Kennzahlen und Vergleichswerte stimmen,
• Filter wie vereinbart arbeiten und
• die freigegebenen Anforderungen umgesetzt sind.

Mit der Abnahme entsteht eine Version, auf die sich alle Beteiligten beziehen können. Das zahlt sich aus, sobald die ersten Änderungswünsche kommen.

Zur Übergabe gehört eine kurze Dokumentation. Anwender brauchen Hinweise zu Aktualisierung, Filtern, Kennzahlen und zulässigen Eingaben. Für die technische Pflege kommen Datenquellen, Abfragen, Tabellenbeziehungen, Parameter und besondere Berechnungslogiken hinzu.

Am besten steht diese Dokumentation direkt in der Arbeitsmappe, auf dem README‑Blatt. Dort finden auch Version, Verantwortliche und das Änderungsprotokoll ihren Platz.

Den laufenden Betrieb organisieren

Nach der Übergabe beginnt der Alltag. Datenquellen ändern sich, neue Produkte kommen hinzu, Organisationsstrukturen werden angepasst, und manchmal ändert sich sogar die Definition einer Kennzahl. Deshalb braucht das Dashboard klare Zuständigkeiten.

Dazu gehört ein einfacher Änderungsprozess: Neue Kennzahlen oder Filter kommen erst nach Freigabe in die Datei, und jede Änderung wird im Änderungsprotokoll festgehalten. Zum Beispiel so:

So bleibt nachvollziehbar, welche Version im Einsatz ist und warum sich die Lösung verändert hat.

Wann Excel nicht mehr die passende Plattform ist

Zu einem professionellen Projekt gehört auch die Frage, ob Excel noch die richtige Plattform ist. Ein Wechsel sollte geprüft werden, wenn

• sehr große Datenmengen verarbeitet werden,
• viele Personen gleichzeitig mit derselben Lösung arbeiten,
• differenzierte Berechtigungen nötig sind oder
• eine zentral betriebene Reporting-Plattform mit weitgehend automatischer Aktualisierung gefordert ist.

Einige Grenzen sind technisch fest. Ein Arbeitsblatt fasst höchstens 1.048.576 Zeilen und 16.384 Spalten, eine Tabelle im Datenmodell dagegen bis zu 1.999.999.997 Zeilen. Dort wird eher der Arbeitsspeicher zum Engpass: In der 32-Bit-Version teilen sich Excel, Arbeitsmappen und Add-ins einen virtuellen Adressraum von 2 GB, die 64-Bit-Version kennt keine feste Grenze für die Dateigröße. In Excel für das Web gilt eine Gesamtdateigröße von höchstens 250 MB.

Unterhalb dieser Grenzen gibt es keine Dateigröße und keine Nutzerzahl, ab der Excel automatisch ungeeignet wäre. Ausschlaggebend sind die konkreten Anforderungen an Datenmenge, Zusammenarbeit, Sicherheit, Aktualisierung, Wartung und Governance.

Die sinnvollere Frage lautet daher nicht „Kann Excel das noch?“, sondern: „Ist Excel für diesen Anwendungsfall noch die wirtschaftlich und organisatorisch passende Lösung?“

Fällt die Entscheidung für Power BI, ist eine saubere Architektur ein großer Vorteil: Beim Import einer Excel-Arbeitsmappe in Power BI Desktop werden alle Power-Query-Abfragen übernommen, ebenso Beziehungen, berechnete Spalten, Measures und KPIs des Datenmodells. Hierarchien werden dabei derzeit nicht übernommen.

Projekt-Checkliste

Auftrag und Anforderungen

• Ziel, Nutzer und Auftraggeber definiert
• Zu unterstützende Entscheidungen benannt
• Muss-, Soll- und Kann-Anforderungen abgestimmt
• Aktualisierungsrhythmus geklärt
• Nutzungsumgebung (Excel-Version, Ablageort) geklärt

Kennzahlen und Daten

• KPIs mit Berechnung, Vergleichswerten und Bewertungsregel definiert
• Datenquellen und Schlüssel identifiziert
• Datenqualität geprüft

Konzept und Umsetzung

• Architektur festgelegt
• Wireframe erstellt
• Prototyp abgestimmt
• Datenaufbereitung und Berechnungen umgesetzt

Test und Freigabe

• Zahlen mit Referenzwerten abgeglichen
• Filter und Sonderfälle geprüft
• Aktualisierung mit neuen Daten getestet
• Performance im vorgesehenen Einsatz geprüft
• Fachliche Abnahme erfolgt

Übergabe und Betrieb

• README/Dokumentation vorhanden
• Verantwortlichkeiten festgelegt
• Version dokumentiert
• Änderungsprozess definiert