Ein Wunsch ist noch keine Anforderung

Es gibt einen Satz, mit dem viele Dashboard-Projekte beginnen, und er klingt vorbildlich kundenorientiert: „Sagt uns einfach, was ihr sehen wollt."

Das Ergebnis ist vorhersehbar. Man bekommt eine Liste. Sie ist lang, sie ist heterogen, und sie enthält alles, was in den letzten Jahren einmal jemandem gefehlt hat. Danach folgt der zweite vorhersehbare Satz, diesmal von der Erstellerseite: „Die können nicht sagen, was sie sehen wollen, die wollen immer alles."

Beide Seiten haben recht. Und beide sitzen in derselben Falle.

Warum die offene Frage nicht funktioniert

Wer in einen Anforderungsworkshop mit einem weißen Blatt Papier geht und fragt, was man gern hätte, verlangt von den Teilnehmenden etwas, das sie in dieser Situation gar nicht leisten können.

Sie haben keine Orientierung darüber, was ein Dashboard überhaupt ist und was es leisten kann. Sie haben kein Zielbild, an dem sie ihre Wünsche relativieren könnten. Sie kennen die Spielregeln nicht — welche Darstellungsformen es gibt, was zusammen funktioniert, wo Grenzen liegen. Also nennen sie das, was sie kennen: ihre bestehenden Berichte, ihre Excel-Tabellen, ihre Detailsichten. Und sie nennen alles, weil Weglassen ohne Kriterium riskant wirkt.

Die Liste, die dabei entsteht, ist keine Anforderung. Sie ist eine Sammlung von Wünschen — und zwischen beidem liegt ein entscheidender Unterschied.

Wunsch, Analysebedarf, Führungsinformation

Ein Wunsch ist die Äußerung eines Interesses. Eine Anforderung ist die Beschreibung eines Bedarfs, der an eine Aufgabe gebunden ist. Der Weg vom einen zum anderen führt über eine Unterscheidung, die in der Praxis fast nie explizit gemacht wird.

Nice to have. Interessant, aber ohne Konsequenz. Man würde es sich anschauen, wenn es da ist, und nichts anders machen. Das ist kein schlechter Wunsch — er gehört nur nicht auf eine Steuerungsübersicht.

Analysebedarf. Relevant, aber anlassbezogen. Diese Information braucht man, wenn etwas auffällig ist, um der Ursache nachzugehen. Sie gehört in eine analytische Sicht, nicht in den Überblick, und sie muss nicht ständig sichtbar sein.

Führungsinformation. Steuerungsrelevant und wiederkehrend. Diese Information beeinflusst regelmäßig Prioritäten, Entscheidungen oder Maßnahmen. Sie gehört an die prominenteste Stelle.

Viele Dinge sind interessant, aber nicht steuerungsrelevant. Gute Dashboardarbeit unterscheidet zwischen diesen drei Kategorien, bevor gebaut wird. Wer die Unterscheidung überspringt, baut ein Artefakt, in dem alles gleich wichtig aussieht — und damit nichts.

Die Fragen, die aus Wünschen Anforderungen machen

Der Übergang gelingt nicht durch Nachbohren im Sinne von „Braucht ihr das wirklich?". Diese Frage erzeugt Rechtfertigungsdruck und damit trotzige Wunschlisten.

Er gelingt durch Fragen, die den Wunsch an eine Situation binden:

• 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?
• Welche Vergleichswerte braucht es, damit ein Wert einzuordnen ist?
• Wobei genau soll es helfen?

Hinter der Aussage „Ich muss die Umsätze sehen" steckt fast immer deutlich mehr. Die eigentliche Arbeit besteht darin, herauszuarbeiten, wonach die Umsätze angeschaut werden sollen — nach Regionen, Produkten, Kunden, Kanälen — und vor allem, was aus der Antwort folgen soll.

Ein Fragebogen im Vorfeld leistet dabei zwei Dinge gleichzeitig. Er zwingt die Anfordernden dazu, sich mit der eigenen Anforderung zu befassen, statt sie im Termin spontan zu erfinden. Und er gibt der Erstellerseite genug Material, um zu erkennen, welche Art von Dashboard hier überhaupt gebraucht wird. Sind die Antworten unpräzise, hilft ein moderiertes Format, das die Anforderung aus der Draufsicht betrachtet, statt sich sofort in Einzelkennzahlen zu verlieren.

Was vorher passieren muss

Es gibt eine Vorbedingung, die häufig übersehen wird: Bevor man Anforderungen aufnimmt, brauchen alle Beteiligten ein gemeinsames Verständnis davon, worüber sie eigentlich sprechen.

Das heißt konkret zweierlei. Erstens muss klar sein, warum überhaupt standardisiert und visualisiert wird — nicht als Zwang, sondern als Nutzen. Zweitens muss es einen Rahmen geben: welche Darstellungsformen, welche Farben, welche Dashboard-Arten zur Verfügung stehen. Nicht als Einschränkung der Kreativität, sondern als Orientierung. Aus etwas Vorgegebenem auszuwählen ist deutlich einfacher, als aus dem Nichts zu erfinden.

Wer diese beiden Schritte überspringt und direkt mit der Anforderungsaufnahme startet, kann davon ausgehen, dass dieser Schritt schiefgeht. Nicht weil die Beteiligten unfähig wären, sondern weil ihnen die Grundlage fehlt, auf der sie sinnvoll auswählen könnten.

Der Punkt

Die Aufgabe in der Anforderungsaufnahme besteht nicht darin, Wünsche einzusammeln und möglichst viele davon umzusetzen. Sie besteht darin, Wünsche zu sortieren, zu ordnen und zu hinterfragen.

Das Dashboard, das alles zeigt, gibt es nicht. Es gibt nur Dashboards, die sich auf eine Fragestellung konzentrieren — und solche, die es versucht haben und an allen Fronten mittelmäßig geblieben sind.

Wer diese Auswahl nicht trifft, hat sie nicht vermieden. Er hat sie nur an die Nutzerin delegiert, die jetzt selbst herausfinden darf, was wichtig ist.

Reflexionsfrage: Wann wurde in eurem letzten Reporting-Projekt zuletzt eine Anforderung abgelehnt, weil nicht klar war, welche Entscheidung sie unterstützen soll?

Quellen und weiterführende Hinweise

• Der vollständige Dashboard Requirement Process mit allen sieben Schritten — von der Motivation über Anforderungsaufnahme und Prototyping bis zur Übergabe — ist im TDWI-E-Book *Self-Service Analytics* beschrieben: zum E-Book

Aus meiner eigenen Arbeit

• Mini-Guide: 100 Fragen über Dashboards — Kapitel 2 behandelt die Frage, wie viel auf ein Dashboard muss und wer eigentlich entscheidet, was daraufkommt.
• Steuerungs-Check — acht Fragen dazu, ob eure Dashboards Entscheidungen tragen oder nur informieren.

Wenn bei euch die nächste Anforderungsrunde ansteht und ihr sie nicht mit einem weißen Blatt beginnen wollt: Beim Reporting-Check schauen wir gemeinsam auf das, was schon da ist, und darauf, welche Steuerungsfragen dahinterstehen.