Der Weg von der Anforderung zum Dashboard

Es gibt einen Verlauf, den fast jeder kennt, der schon einmal an einem Dashboard gearbeitet hat. Die Fachabteilung äußert einen Bedarf. Die Erstellerseite nimmt ihn auf und beginnt zu bauen. Nach einigen Wochen wird das Ergebnis präsentiert, und die erwartete Begeisterung bleibt aus. Stattdessen: „Das ist nicht das, was wir gemeint haben."

Auf beiden Seiten entsteht Frust. Die einen sagen, die verstehen uns nicht. Die anderen sagen, die wissen nicht, was sie wollen.

Interessanterweise haben beide recht. Der Fehler liegt nicht bei den Personen, sondern in der Abwesenheit eines gemeinsamen Vorgehens. Genau dafür habe ich den Dashboard Requirement Process entwickelt — kurz DRP. Er beschreibt in sieben Schritten, wie aus einer diffusen Anforderung ein Dashboard wird, das genutzt wird.

Der Prozess ist kein theoretisches Modell. Er ist aus einer Vielzahl von Projekten entstanden und dort mehrfach erprobt worden.

Die sieben Schritte im Überblick

1. Motivation — Warum wollen wir das so machen?

Der erste Schritt hat nichts mit dem Dashboard zu tun, und genau deshalb wird er meistens übersprungen. Es geht darum, den Anfordernden das Warum nahezubringen: Warum will sich das Unternehmen stärker mit Daten auseinandersetzen? Was genau soll sich durch ein Dashboard verbessern? Welche Entscheidungen sollen schneller, klarer oder besser getroffen werden?

Diese Motivation muss kommuniziert werden — und zwar nicht nur in einer Folie, sondern in der Organisation. Ein kurzes Video eignet sich dafür oft besser als ein Workshop, weil die Anfordernden selbst entscheiden können, wann sie es anschauen.

Wichtig ist die Tonlage: Der Prozess wird als Hilfsmittel vorgestellt, nicht als träger Ablauf, der die Kreativität ausbremst.

2. Konzept — Die Spielregeln

Im zweiten Schritt werden die Anfordernden in den bestehenden Rahmen eingeführt: Standards, Framework, Visualisierungen. Welche Farben, welche Diagrammarten, welche Dashboard-Typen stehen zur Verfügung?

Das klingt nach Einschränkung, ist aber das Gegenteil. Wer aus einem Vorgegebenen auswählen kann, tut sich deutlich leichter, als wer aus dem Nichts erfinden soll. One-Pager, die man als Spielregeln lesen kann, leisten hier mehr als jedes Handbuch.

Warum Standards keine Einschränkung sind, lässt sich mit einem Vergleich klarmachen: Die Mehrzahl der Autofahrenden hält sich an die Straßenverkehrsordnung. Das schränkt niemanden wirklich ein — es sorgt dafür, dass alle unbeschadet ankommen, weil jeder weiß, was zu erwarten ist. Mit einem Dashboard-Standard verhält es sich genauso.

3. Anforderungsaufnahme — Was braucht ihr?

Erst jetzt geht es um den konkreten Bedarf. Gute Anforderungen entstehen nicht durch Wünsche, sondern durch kluge Fragen.

Ein Fragebogen im Vorfeld leistet zwei Dinge: Er zwingt die Anfordernden, sich mit der eigenen Anforderung zu befassen, statt sie im Termin spontan zu erfinden. Und er gibt der Erstellerseite Material, um zu erkennen, welche Art von Dashboard hier gebraucht wird.

Typische Fragen: Welche Fragen soll das Dashboard beantworten? Welche Entscheidungen soll es unterstützen? Wie oft wird es genutzt und von wem? Wird es strategisch, operativ oder analytisch genutzt?

Hier entscheidet sich, ob das spätere Dashboard Klarheit schafft oder nur Daten schön anzeigt. Wer in diesem Schritt nur Features sammelt, verpasst das Ziel.

4. Prototyping — Wie schaut ihr auf diese Fragestellung?

Prototyping ist kein Vorgriff auf die Umsetzung. Es ist Teil des Verstehens.

Es geht nicht um pixelgenaue Entwürfe, sondern um Dialogfähigkeit: mit Stift, Whiteboard oder PowerPoint gemeinsam skizzieren, was zuerst sichtbar sein soll, wie sich eine Kennzahl zusammensetzt, welche Strukturen interessant sind, ob ein Zeitverlauf relevant ist. Dabei wird gemalt, gestrichen, verworfen und neu gedacht.

Das ist der erste Moment, in dem Fachlichkeit und Visualisierung sich wirklich begegnen. Und es ist der Schritt, der sich in der Projekterfahrung immer wieder als der entscheidende herausgestellt hat.

5. Umsetzung — Das Dashboard entsteht

Jetzt kommt das Werkzeug ins Spiel. Der Unterschied zum üblichen Vorgehen: Die Umsetzung beginnt nicht mit einem leeren Blatt, sondern mit einem getesteten Prototyp. Die Struktur steht, die Kennzahlen sind abgestimmt, das Layout wurde gemeinsam gedacht.

Kein Ratespiel, keine Überraschungen, kein Wunschkonzert mehr.

Häufig sind die Person, die die Anforderung aufgenommen hat, und die Person, die baut, nicht dieselbe. Den Prototyp hinzuwerfen mit den Worten „Mach das genau so" funktioniert nicht. Werkzeuge haben unterschiedliche Eigenschaften, und wenn etwas nicht auf Anhieb geht, ist gemeinsames Suchen nach einer Lösung besser als tausend Workarounds für eine Kleinigkeit.

6. Review — Haben wir die Spielregeln eingehalten?

Ein Dashboard, das gebaut ist, ist noch lange nicht gut. Es muss überprüft, gespiegelt und hinterfragt werden — nicht aus Misstrauen, sondern aus Respekt vor der Wirkung.

Überlassen Sie das nicht der Fachabteilung, sondern machen Sie es selbst. Checklisten eignen sich hier gut, weil sie ein hohes Quality Gate darstellen, ohne dass jedes Mal neu diskutiert werden muss, worauf zu achten ist.

Review ist keine Kür. Es ist Teil der Verantwortung.

7. Übergabe — Weil Wirkung entscheidet

Der letzte Schritt wird am häufigsten unterschätzt. Ein gutes Dashboard verdient eine gute Einführung.

Wer Wirkung will, muss nicht zeigen, wie etwas funktioniert — sondern warum es wichtig ist. Ein Drilldown verblüfft niemanden mehr. Interessant ist, was man durch einfache Navigation entdecken kann und welche Fragen sich damit schneller beantworten lassen.

Die Übergabe ist zugleich ein wichtiger Teil des internen Marketings. Wer hier fünf Minuten zwischen Tür und Angel investiert, verschenkt die Arbeit von Wochen.

Was der Prozess leistet

Der DRP ist kein Bürokratieinstrument. Er löst drei Probleme gleichzeitig.

Er strukturiert die Aufnahme, sodass Anforderungen vergleichbar und vollständig werden. Er versetzt die Erstellenden in eine beratende Rolle, statt sie zu Bestellungsempfängern zu machen. Und er sorgt für einen einheitlichen Qualitätsstandard, weil nicht jedes Projekt neu erfindet, wie man vorgeht.

Der wichtigste Effekt ist aber ein anderer: Wenn im Prototyping nichts versprochen wurde, was später nicht gehalten werden kann, ist die Umsetzung wenig dramatisch. Und wenn die Anforderung an eine Entscheidungssituation gebunden wurde, gibt es am Ende jemanden, der das Dashboard tatsächlich braucht.

Was der Prozess voraussetzt

Zwei Dinge setze ich dabei voraus, und ich will sie offen benennen.

Erstens: Es existieren Standards zu Visualisierung, Notation und Dashboard-Framework. Ohne sie fehlt in Schritt 2 der Rahmen, auf den man sich beziehen könnte.

Zweitens: Es gibt eine angemessene Datenqualität und einen vorhandenen Datenhaushalt. Der DRP ist kein Verfahren, um fehlende Daten zu ersetzen.

Und noch etwas: Was sich hier so geradlinig liest, braucht in der Praxis Übung und Routine. Je öfter man den Prozess durchläuft, desto besser kennt man auch die Möglichkeiten im eigenen Werkzeug — und desto weniger Überraschungen gibt es.

Reflexionsfrage: An welcher Stelle dieser sieben Schritte steigt euer Vorgehen heute ein? Und was passiert bei euch mit den Schritten davor?

Quellen und weiterführende Hinweise

• Die ausführliche Beschreibung des Dashboard Requirement Process mit allen sieben Schritten und einem Schwerpunkt auf dem Prototyping ist im TDWI-E-Book *Self-Service Analytics* erschienen: zum E-Book

Aus meiner eigenen Arbeit

• Mini-Guide: 100 Fragen über Dashboards — die scheinbar naiven Fragen, die sich in jedem dieser sieben Schritte lohnen.
• Steuerungs-Check — acht Fragen dazu, ob eure Dashboards Entscheidungen tragen oder nur informieren.

Wenn ihr den Prozess bei euch etablieren wollt oder wissen möchtet, wo eure bestehenden Dashboards stehen: Beim Reporting-Check schauen wir gemeinsam drauf.