Dashboard entwickeln: intern oder für Kunden?

Das Wichtigste in Kürze

• Ein Dashboard bündelt ausgewählte Kennzahlen oder Vorgänge so, dass Nutzerinnen und Nutzer den aktuellen Stand schneller erfassen können.
• Für interne Teams stehen oft Steuerung und Zusammenarbeit im Vordergrund. Ein Dashboard für Kunden muss zusätzlich verständlich sein und Zugriffe sauber trennen.
• Die wichtigste Vorarbeit ist nicht die Gestaltung, sondern die Klärung von Fragen, Datenquellen und Verantwortlichkeiten.
• Ein Pilot mit wenigen, klar definierten Ansichten zeigt, ob das Dashboard im Arbeitsalltag hilft.
• Veraltete oder widersprüchliche Daten werden durch eine ansprechende Oberfläche nicht verlässlicher.

Worum es geht

Ein Dashboard ist eine digitale Oberfläche, die wichtige Informationen an einem Ort zusammenfasst. Das können Kennzahlen, Statusmeldungen, Aufgaben oder einzelne Vorgänge sein. Nutzerinnen und Nutzer sollen damit eine konkrete Frage beantworten können, ohne dafür mehrere Tabellen, Systeme oder E-Mails durchsuchen zu müssen.

Ein internes Dashboard richtet sich etwa an die Geschäftsführung, eine Abteilung oder ein Projektteam. Es kann offene Aufgaben, Auftragsstände oder Bearbeitungszeiten zeigen. Ein Dashboard für Kunden stellt dagegen Informationen bereit, die Kundinnen und Kunden selbst einsehen dürfen, zum Beispiel den Status eines Auftrags oder den Stand einer Anfrage.

Die technische Umsetzung kann von einer einfachen, intern genutzten Web-Oberfläche bis zu einem kundenspezifischen Portal reichen. Was passt, hängt davon ab, wie häufig die Informationen gebraucht werden, aus welchen Systemen sie kommen und welche Aktionen die Nutzer damit ausführen sollen. Ein Dashboard ist nicht automatisch ein Ersatz für die zugrunde liegenden Systeme oder für persönliche Abstimmungen.

Typische Ausgangslage

Stellen Sie sich ein mittelständisches Unternehmen vor, dessen Leitung Aufträge, offene Fälle und Durchlaufzeiten aus drei Tabellen vergleicht. Die Tabellen werden von verschiedenen Personen gepflegt und nicht immer gleichzeitig aktualisiert. Vor einer Besprechung muss jemand die Stände abgleichen und Unklarheiten klären. Das kostet Zeit und erschwert den Vergleich.

Ein internes Dashboard könnte die relevanten Informationen an einer Stelle anzeigen und kenntlich machen, wann sie zuletzt aktualisiert wurden. Ein Kunden-Dashboard könnte in einem anderen Beispielszenario ausgewählte Auftragsstände bereitstellen, damit Kunden nicht für jede Statusfrage anrufen müssen. In beiden Fällen muss zuerst geklärt werden, ob die Informationen verlässlich vorliegen und wer sie sehen darf.

So gehen Sie vor

1. Fragen und Nutzer festlegen. Notieren Sie, wer das Dashboard verwenden soll und welche Entscheidungen damit leichter fallen sollen. „Wir wollen mehr Überblick“ ist zu ungenau. Hilfreicher ist eine Frage wie: „Welche Aufträge benötigen heute eine Rückmeldung?“

2. Informationsbedarf begrenzen. Wählen Sie zunächst nur Angaben aus, die zur Beantwortung dieser Fragen nötig sind. Zu viele Kennzahlen und Ansichten machen die Oberfläche schwerer verständlich. Prüfen Sie auch, ob eine Information wirklich in einem Dashboard gebraucht wird oder besser im bestehenden Fachsystem bleibt.

3. Datenquellen und Qualität prüfen. Erfassen Sie, wo die Informationen entstehen, wer sie pflegt und wie sie zusammengeführt werden können. Stimmen Bezeichnungen und Statuswerte überein? Gibt es doppelte Einträge oder fehlende Aktualisierungen? Solche Fragen sollten vor der Gestaltung geklärt werden.

4. Zugriff und Aktualisierung definieren. Legen Sie fest, welche Personen welche Daten sehen dürfen und wie oft Aktualisierungen nötig sind. Bei einem Kunden-Dashboard braucht jeder Kunde eine passende, voneinander getrennte Ansicht. Interne Informationen dürfen nicht durch eine fehlerhafte Zuordnung nach außen gelangen.

5. Einen Pilot umsetzen und testen. Beginnen Sie mit einer Nutzergruppe und einem überschaubaren Prozess. Testen Sie mit typischen Aufgaben: Finden die Personen den relevanten Stand? Verstehen sie die Kennzahlen? Entspricht die Anzeige den Daten in der Quelle? Sammeln Sie Rückmeldungen, bevor Sie den Umfang erweitern.

6. Betrieb und Verantwortung festlegen. Bestimmen Sie, wer Datenquellen, Zugriffsrechte und fachliche Definitionen pflegt. Dokumentieren Sie, was eine Kennzahl bedeutet und was bei Fehlern oder Ausfällen passiert. Ein Dashboard braucht Betreuung, auch wenn die Oberfläche einmal fertiggestellt ist.

Entscheidungskriterien und typische Fehler

Vor einer Entwicklung helfen diese Fragen:

• Müssen dieselben Informationen regelmäßig aus mehreren Quellen zusammengesucht werden?
• Führt die bessere Übersicht zu einer konkreten Entscheidung oder Handlung?
• Sind die wichtigsten Daten vorhanden und ausreichend verlässlich?
• Wer ist für Aktualität, Definitionen und Berechtigungen verantwortlich?
• Soll die Oberfläche nur informieren oder auch Eingaben und Aktionen ermöglichen?
• Welche Informationen dürfen Kunden sehen, und wie wird der Zugriff getrennt?

Ein häufiger Fehler ist, mit der Auswahl von Diagrammen oder Farben zu beginnen. Damit wird die Oberfläche gestaltet, bevor klar ist, welche Entscheidung sie unterstützen soll. Ebenso problematisch ist es, möglichst viele Daten aufzunehmen. Mehr Anzeige bedeutet nicht automatisch mehr Orientierung.

Auch uneinheitliche Definitionen führen zu Missverständnissen. Wenn zwei Teams „offen“ unterschiedlich verwenden, kann ein gemeinsamer Wert im Dashboard einen falschen Eindruck vermitteln. Legen Sie deshalb Begriffe und Berechnungsweisen fest und machen Sie bei Bedarf sichtbar, wann Daten zuletzt aktualisiert wurden.

Bei Kunden-Dashboards kommt eine weitere Abwägung hinzu: Eine gute Selbstbedienung kann wiederkehrende Statusanfragen reduzieren, darf aber keine Erwartungen an Echtzeit-Informationen wecken, die Ihre Systeme nicht erfüllen. Kommunizieren Sie, welche Angaben gezeigt werden und wie aktuell diese üblicherweise sind.

Grenzen und Risiken

Ein Dashboard kann keine schlechte Datenpflege ausgleichen. Fehlen Einträge oder werden Vorgänge unterschiedlich dokumentiert, zeigt die Oberfläche diese Probleme höchstens schneller. Manchmal ist es sinnvoller, zunächst den Erfassungsprozess zu vereinheitlichen, statt direkt eine neue Anwendung zu bauen.

Auch der technische Aufwand kann wachsen. Neue Datenquellen, zusätzliche Nutzergruppen und individuelle Auswertungen erhöhen Anforderungen an Wartung, Berechtigungen und Tests. Prüfen Sie deshalb, ob vorhandene Systeme bereits geeignete Übersichten bieten und ob ein eigenständiges Web-Tool tatsächlich einen Vorteil bringt.

Bei personenbezogenen oder vertraulichen Informationen müssen Zweck, Zugriff und Aufbewahrung sorgfältig geprüft werden. Datenschutzrechtliche Anforderungen hängen vom konkreten Vorhaben ab und sollten im Einzelfall fachkundig bewertet werden. Das gilt besonders, wenn externe Nutzer Zugriff auf ein Kundenportal erhalten.

Woran Sie den Nutzen erkennen

Vereinbaren Sie vor dem Pilot einfache Prüfkriterien. Beobachten Sie zum Beispiel, ob die beteiligten Personen die vereinbarten Informationen ohne manuelles Zusammenführen finden und ob sie die dargestellten Werte gleich verstehen. Prüfen Sie außerdem, wie oft Daten fehlen, Rückfragen entstehen oder Zugriffsprobleme auftreten.

Vergleichen Sie den Ablauf vor und nach dem Pilot anhand derselben Tätigkeiten. Dabei geht es nicht um eine pauschale Einsparungszusage, sondern um nachvollziehbare Beobachtungen: Welche Arbeitsschritte entfallen, welche bleiben nötig und wo entstehen neue Pflegeaufgaben? Wenn die Oberfläche regelmäßig genutzt wird und Entscheidungen erleichtert, kann der nächste Ausbauschritt sinnvoll sein.

Häufige Fragen

Was ist der Unterschied zwischen einem Dashboard und einem Bericht?

Ein Bericht hält Informationen häufig für einen bestimmten Zeitpunkt oder eine Auswertung fest. Ein Dashboard ist meist für wiederkehrende Nutzung gedacht und bündelt ausgewählte Werte oder Statusinformationen. Die Abgrenzung hängt davon ab, wie häufig Daten aktualisiert werden und welche Interaktion vorgesehen ist.

Brauchen wir für ein Dashboard eine neue Datenbank?

Nicht zwingend. Zunächst sollte geprüft werden, welche Datenquellen bereits vorhanden sind und wie sie angebunden werden können. Eine zusätzliche Datenbank kann in bestimmten Fällen sinnvoll sein, bringt aber auch Verantwortung für Aktualisierung und Pflege mit sich.

Wie aktuell müssen die angezeigten Daten sein?

Das richtet sich nach der Entscheidung, die das Dashboard unterstützen soll. Für manche Übersichten reicht eine regelmäßige Aktualisierung, während andere Abläufe einen häufigeren Abgleich benötigen. Legen Sie die Anforderung fest und zeigen Sie Nutzenden transparent, auf welchem Stand die Daten sind.

Wann ist ein Kunden-Dashboard sinnvoll?

Es kann passen, wenn Kunden wiederholt nach ähnlichen Informationen fragen und diese verlässlich sowie klar abgegrenzt bereitgestellt werden können. Prüfen Sie, ob der Nutzen für Kunden den Aufwand für Zugriffsverwaltung, Betreuung und verständliche Erläuterungen rechtfertigt.

Was ist ein guter erster Schritt?

Wählen Sie einen Prozess, bei dem mehrere Personen regelmäßig Informationen aus verschiedenen Quellen zusammenführen. Formulieren Sie eine konkrete Frage, die das Dashboard beantworten soll, und prüfen Sie Datenqualität sowie Zugriffsbedarf. Daraus lässt sich ein begrenzter Pilotumfang ableiten.