Visualisierung und Dashboard-Design für Lieferfähigkeit

Die Daten sind da. Ein Team hat geklärt, für wen und warum es misst. Es hat verstanden, aus welchen Dimensionen sich Lieferfähigkeit zusammensetzt.

Es erfasst Cycle Time, Throughput und Work in Progress, und es weiß inzwischen, wie verlässlich seine Lieferversprechen wirklich sind. Was noch fehlt, ist der Schritt, an dem sich entscheidet, ob aus all dem ein Nutzen wird. Die Zahlen müssen sichtbar werden, und zwar so, dass jemand auf ihrer Grundlage handelt.

In der Praxis sieht dieser Schritt oft gleich aus. Jemand baut ein Dashboard. Es zeigt eine durchschnittliche Cycle Time von zwölf Tagen, eine Throughput-Kurve der letzten Wochen, vielleicht eine Ampel, die auf Grün steht. Es wirkt professionell, es hängt auf einem Monitor im Flur oder liegt als Reiter im Projektwerkzeug bereit. Und dann passiert nichts. Niemand trifft eine andere Entscheidung als zuvor, und nach einigen Wochen schaut kaum noch jemand hin.

Das ist kein Datenproblem. Es ist ein Darstellungsproblem.

Warum gute Daten an der Darstellung scheitern

Ein Dashboard scheitert selten daran, dass die Zahlen falsch sind. Es scheitert daran, dass die Darstellung die falsche Frage beantwortet, oder gar keine.

Der häufigste Fehler beginnt beim Mittelwert. Eine durchschnittliche Cycle Time von zwölf Tagen klingt nach einer Aussage, ist aber eine Verschleierung. Zwei Teams mit identischem Durchschnitt können völlig unterschiedlich arbeiten. Beim einen liegen fast alle Vorgänge dicht beieinander, sodass eine Zusage über zwölf Tage verlässlich hält. Beim anderen schwankt die Bearbeitungszeit zwischen zwei und vierzig Tagen, und dieselbe Zusage ist kaum mehr als ein Münzwurf. Auf dem Dashboard sehen beide Teams identisch aus, obwohl ihre Planbarkeit kaum unterschiedlicher sein könnte. Wie sehr Durchschnittswerte in die Irre führen, wurde in „Vom Durchschnitt zur belastbaren Prognose“ ausführlich behandelt. In der Visualisierung kehrt dasselbe Problem in grafischer Form zurück.

Ein Diagramm, das niemanden zu einer Entscheidung führt, ist nur Dekoration.

Der zweite Fehler ist subtiler. Eine Darstellung kann fachlich korrekt und trotzdem für ihr Publikum nutzlos sein. Ein Diagramm, das den aktuellen Arbeitsfluss eines Teams im Detail zeigt, ist für dieses Team Gold wert. Vor die Geschäftsführung projiziert, die wissen möchte, ob sich die Lieferfähigkeit über das Quartal verbessert hat, erzeugt dasselbe Diagramm hauptsächlich Ratlosigkeit. Umgekehrt sagt eine hoch aggregierte Quartalskurve einem Team, das am Morgen entscheiden muss, woran es arbeitet, überhaupt nichts.

Visualisierung ist also keine Dekoration, die man nachträglich über fertige Metriken legt. Sie ist der Ort, an dem Metriken zu Entscheidungen werden. Oder eben nicht. Dieselben Daten, unterschiedlich dargestellt, führen zu unterschiedlichem Handeln. Oder zu keinem.

Welche Darstellung für welche Frage

Aus dem Auftakt dieser Serie, „Kennzahlen für Lieferfähigkeit – Wozu und für wen messen wir überhaupt?“, ist bekannt, dass verschiedene Stakeholder verschiedene Fragen mit verschiedenen Zeithorizonten stellen. Genau daran muss sich die Darstellung ausrichten, nicht an dem, was technisch möglich oder optisch beeindruckend ist.

Die Geschäftsführung denkt in Quartalen und Trends. Ihre Frage ist, ob sich die Lieferfähigkeit in eine gute Richtung bewegt und ob Zusagen tragfähig sind. Dafür eignen sich aggregierte Verläufe mit klarer Trendlinie, nicht die Momentaufnahme eines einzelnen Arbeitsflusses.

Wer auf CTO- oder Bereichsleitungsebene steuert, sucht systemische Muster und Interventionspunkte. Hier sind Vergleiche über die Zeit sinnvoll und, mit Vorsicht, auch über Teams hinweg. Vorsicht deshalb, weil der direkte Vergleich zweier Teams schnell zu falschen Schlüssen und Fehlanreizen führt. Wichtig ist die Möglichkeit, von der Übersicht in die Details zu wechseln.

Im Produktumfeld dreht sich fast alles um Planbarkeit. Wann ist etwas fertig, und wie sicher ist diese Aussage? Darauf antwortet am besten eine Darstellung, die Streuung und Wahrscheinlichkeit zeigt, statt einer einzelnen Zahl.

Das Team schließlich arbeitet im Hier und Jetzt. Es braucht eine Sicht auf den aktuellen Fluss, auf liegengebliebene Vorgänge und auf den Bestand an angefangener Arbeit, idealerweise tagesaktuell.

Dieselbe Cycle Time taucht damit auf mehreren Sichten auf, aber in jeweils anderer Form. Für das Team als tagesaktueller Punkt in der Verteilung, für das Produktumfeld als Perzentil hinter einer Zusage, für die Leitung als Quartalstrend. Es ist dieselbe Messung, übersetzt in die jeweilige Frage. Eine einzige Darstellung, die all das gleichzeitig leisten soll, leistet am Ende nichts davon richtig.

Vier Darstellungen, die zum Handeln führen

Für die Steuerung von Lieferfähigkeit haben sich einige Darstellungen bewährt, die auf den in „Cycle Time, Throughput und Work-in-Progress“ eingeführten Metriken aufbauen. Jede beantwortet eine eigene Frage, jede löst im Idealfall eine konkrete Handlung aus, und jede verschweigt etwas. Das ist kein Mangel, sondern der Grund, warum man sie kombiniert.

Das Work-in-Progress-Diagramm zeigt den Bestand an angefangener, noch nicht abgeschlossener Arbeit über die Zeit. Ergänzt um eine Linie für das vereinbarte WIP-Limit wird daraus die unmittelbarste Steuerungsdarstellung überhaupt. Steigt der Bestand über das Limit, ist die Handlung klar: keine neue Arbeit beginnen, sondern Angefangenes abschließen. Der Zusammenhang zwischen hohem Bestand und langer Bearbeitungszeit ist kein Bauchgefühl, sondern folgt aus Little’s Law, und warum eine hohe Auslastung gerade nicht zu mehr Durchsatz führt, wurde in „Der Mythos der 100%-Auslastung“ beschrieben. Der blinde Fleck dieser Darstellung ist die Verteilung. Sie zeigt, wie viel Arbeit im System steckt, aber nicht, wie lange einzelne Vorgänge brauchen.

Der Scatterplot trägt jeden abgeschlossenen Vorgang an seinem Fertigstellungsdatum gegen seine Cycle Time ab. Ergänzt um Perzentillinien wird daraus ein präzises Bild der Streuung. Auf einen Blick wird erkennbar, wie lange Vorgänge tatsächlich brauchen, wo Ausreißer liegen und ob sich das Bild zuletzt verändert hat. Daniel Vacanti hat diese Darstellung in Actionable Agile Metrics for Predictability als ein zentrales Werkzeug für Vorhersagbarkeit beschrieben, weil sie zeigt, was ein Mittelwert verbirgt. Aus den Perzentilen lässt sich eine belastbare Zusage ableiten, etwa dass 85 Prozent der Vorgänge in höchstens fünfzehn Tagen abgeschlossen sind, und genau diese Zahl wird zur Handlung, sobald sie in eine Terminzusage einfließt. Punkte, die sich zu Gruppen ballen, eine Lücke, in der über Wochen nichts fertig wurde, oder ein Pulk auffällig langsamer Vorgänge sind weniger fertige Antworten als Anlässe für die richtige Frage. Der blinde Fleck des Scatterplot ist die laufende Arbeit. Er kennt nur Abgeschlossenes und sagt nichts über das, was gerade im System steckt.

Genau diese Lücke schließt das Aging-Work-in-Progress-Diagramm. Es zeigt für jeden offenen Vorgang, wie lange er bereits in Bearbeitung ist, gemessen an denselben Perzentilen wie der Scatterplot. So wird sichtbar, welche Vorgänge gerade dabei sind, die übliche Bearbeitungszeit zu überschreiten, solange noch eingegriffen werden kann. Während der Scatterplot rückblickend erklärt, was gewesen ist, richtet diese Darstellung den Blick nach vorn auf das, was zu entgleisen droht, und sie übersetzt sich direkt in die Frage, welcher Vorgang heute Aufmerksamkeit braucht. Ihr blinder Fleck ist der lange Verlauf. Sie ist eine Momentaufnahme und ersetzt keine Trendbetrachtung.

Für die Frage nach konkreten Terminen reicht keine dieser Darstellungen allein. Hier kommt die Monte-Carlo-Prognose ins Spiel, wie sie in „Forecasting in der Softwareentwicklung“ beschrieben wurde. Sie übersetzt die historische Streuung in eine Aussage über die Zukunft und zeigt, mit welcher Wahrscheinlichkeit ein Vorhaben bis zu einem bestimmten Datum fertig ist. Visuell wird daraus kein einzelnes Datum, sondern ein Bereich von Ergebnissen mit zugeordneten Wahrscheinlichkeiten. Ein einzelnes Datum suggeriert eine Sicherheit, die niemand hat, und es lädt dazu ein, beim ersten Verzug das Vertrauen zu verlieren. Ein Bereich mit Wahrscheinlichkeiten macht das Risiko dagegen explizit und erlaubt eine bewusste Entscheidung darüber, wie viel Sicherheit eine Zusage tragen soll.

Wer tiefer einsteigen will, findet im Cumulative Flow Diagram eine reichhaltigere, aber auch anspruchsvollere Darstellung, die Bestand, Durchsatz und Bearbeitungszeit in einem Bild vereint. Es lohnt sich für die analytische Vertiefung, verlangt aber Übung im Lesen und eignet sich deshalb schlechter für ein Dashboard, das auf einen Blick zum Handeln führen soll.

Angebot und Nachfrage im Blick

Eine Frage entgeht allen vier Darstellungen, die im vorhergehenden Abschnitt behandelt wurden: Wächst der Berg an Arbeit schneller, als er abgebaut wird?

Ein Created-vs-Resolved-Diagramm, das neu hinzukommende Vorgänge den abgeschlossenen über die Zeit gegenüberstellt, macht diese Schere sichtbar. Solange beide Linien parallel laufen, bleibt der Bestand stabil. Driften sie auseinander, wächst der Rückstand, und keine Verbesserung der Bearbeitungsgeschwindigkeit wird das auf Dauer auffangen.

Für die Leitungsebene ist das oft die ehrlichste Darstellung überhaupt, weil sie ein strukturelles Problem zeigt, das in den Darstellungen einzelner Teams untergeht. Sie verlagert die Aufmerksamkeit von der Frage, wie schnell gearbeitet wird, auf die Frage, ob überhaupt mehr zugesagt wird, als zu schaffen ist. Was geschieht, wenn diese Schere lange ignoriert wird, zeigt sich in den Beständen, die in „Feature-Friedhof und Zombie-Projekte“ beschrieben sind.

Vom einzelnen Diagramm zum Dashboard

Ein Dashboard ist keine Sammlung aller verfügbaren Diagramme, sondern eine bewusste Auswahl für ein bestimmtes Publikum und dessen wiederkehrende Frage. Die Komposition folgt derselben Logik wie die Auswahl des einzelnen Bildes.

Eine Team-Sicht verbindet sinnvoll ein Work-in-Progress-Diagramm für den aktuellen Bestand, einen Scatterplot für die Verteilung der jüngsten Bearbeitungszeiten und ein Aging-Diagramm für die Vorgänge, die gerade zu lange dauern. Diese drei zusammen beantworten die Frage, woran heute zu arbeiten ist und wo etwas zu klemmen droht.

Eine Sicht für die Leitungsebene sieht völlig anders aus. Sie zeigt vielleicht nur zwei Dinge: einen Trend der Lieferfähigkeit über mehrere Quartale und eine knappe Aussage zur Vorhersagbarkeit der nächsten größeren Zusage. Alles Weitere lenkt ab.

Die Anordnung der Elemente ist dabei kein gestalterisches Detail, sondern folgt der Reihenfolge, in der der Betrachter denkt. Was zuerst gelesen werden soll, steht oben links. Was nur bei Bedarf interessiert, tritt zurück oder verbirgt sich hinter einem Klick.

Eine weitere Unterscheidung betrifft die Form der Auslieferung. Ein Bild, das in einer Quartalspräsentation gezeigt wird, darf eine bewusst gewählte Momentaufnahme sein, sauber aufbereitet und kommentiert. Ein Dashboard dagegen lebt von Aktualität. Es zieht seine Daten fortlaufend aus der Quelle und ist nur so viel wert, wie es dem aktuellen Stand entspricht. Wer beide Formen verwechselt, baut entweder eine Präsentation, die ständig veraltet, oder ein Dashboard, das niemand aktuell hält.

Dashboards neigen mit der Zeit zum Wuchern. Jede neue Frage führt zu einem weiteren Diagramm, bis die ursprüngliche Klarheit unter der Fülle verschwindet. Ein gutes Dashboard wird deshalb nicht nur ergänzt, sondern regelmäßig auch zurückgeschnitten. Was über Monate niemand mehr betrachtet hat, kann weg.

Dashboards, die genutzt werden

Damit aus den richtigen Diagrammen ein Dashboard wird, das überlebt, lohnt der Blick auf die immer gleichen Fehler. Stephen Few hat in seiner Arbeit zum Dashboard-Design eine ganze Reihe davon zusammengetragen, und die meisten lassen sich auf wenige Muster eindampfen.

Das erste ist Überfrachtung. Wenn ein Bildschirm alles zeigen will, zeigt er nichts deutlich. Das zweite ist fehlender Kontext. Eine Zahl ohne Zielwert, ohne Vergleich und ohne Trend ist nicht interpretierbar, weil niemand weiß, ob zwölf Tage gut oder schlecht sind. Das dritte ist falsche Präzision, etwa eine Cycle Time auf zwei Nachkommastellen, die eine Genauigkeit vortäuscht, die die Daten gar nicht hergeben. Das vierte ist schmückendes Beiwerk, das von der Aussage ablenkt. Edward Tufte prägte dafür in The Visual Display of Quantitative Information den Begriff der Data-Ink-Ratio. Je größer der Anteil einer Darstellung ist, der tatsächlich Information trägt, und je kleiner der Anteil bloßer Verzierung, desto klarer die Aussage.

Zwei weitere Muster betreffen die Ehrlichkeit der Darstellung. Der geschönte Zeitausschnitt wählt den dargestellten Zeitraum so, dass die Kurve günstig aussieht, und erzeugt eine Aussage, die mit der nächsten Woche zusammenbricht. Eng verwandt ist die manipulierte Achse. Eine Werteachse, die nicht bei null beginnt, lässt kleine Unterschiede dramatisch wirken, und uneinheitliche Maßstäbe zwischen zwei nebeneinanderliegenden Diagrammen verleiten zu Vergleichen, die gar nicht zulässig sind. Wer mehrere Darstellungen nebeneinanderstellt, sollte ihre Skalen bewusst angleichen.

Besondere Vorsicht gilt der beliebten Ampel. Eine Farbe ist erst dann eine Information, wenn vorher vereinbart wurde, was Grün, Gelb und Rot bedeuten und welche Handlung jede Farbe auslöst. Ohne diese Vereinbarung ist die Ampel nur ein beruhigendes oder beunruhigendes Signal ohne Konsequenz, und sie verleitet dazu, eine komplexe Lage auf eine einzige Farbe zu reduzieren. Ein Schwellenwert, auf den sich niemand geeinigt hat, richtet mehr Schaden an als gar keiner.

Der eigentliche Grund, warum Dashboards zu Friedhöfen werden, liegt allerdings tiefer. Sie werden für die gebaut, die sie bauen, nicht für die, die sie lesen sollen. Ihnen fehlen eine klare Frage, ein Verantwortlicher und ein Anlass, zu dem sie betrachtet werden. Genutzt wird ein Dashboard, wenn es an eine wiederkehrende Entscheidung oder ein regelmäßiges Gespräch gekoppelt ist, wenn jede Ansicht eine einzige Frage beantwortet, wenn die Zahlen mit Zielwert, Trend oder Vergleich versehen sind und wenn der Zugang ohne Hürde funktioniert. Dazu gehört, dass eine Person für die Darstellung verantwortlich ist und es einen festen Anlass gibt, zu dem darauf geschaut wird. Ein Diagramm, das in einem solchen Termin tatsächlich besprochen wird, überlebt. Eines, das nur existiert, verschwindet.

Wie diese Darstellungen technisch entstehen, ist zweitrangig, solange das Ergebnis lesbar bleibt. Manche Teams bauen ihre Diagramme von Hand in einer Tabellenkalkulation, was flexibel, aber fehleranfällig und mühsam zu pflegen ist. Andere nutzen allgemeine Business-Intelligence-Werkzeuge, die viel können, dafür aber Einrichtung und Wartung verlangen. Wieder andere greifen zu spezialisierten Werkzeugen, die Flow-Metriken direkt aus dem vorhandenen Arbeitsverwaltungssystem ziehen. Für Teams, die ihre Vorgänge in Jira verwalten, fallen etwa die Delivery Gadgets in diese Kategorie, die mehrere der hier beschriebenen Darstellungen als fertige Bausteine bereitstellen. Entscheidend ist nicht das Werkzeug, sondern ob die entstehende Darstellung die richtige Frage für das richtige Publikum beantwortet.

Fazit

Ein Dashboard ist nie das Ziel. Das Ziel ist die Entscheidung, die es ermöglicht. Die Daten wurden erhoben, ihre Verlässlichkeit wurde geprüft, und nun werden sie lesbar gemacht. Visualisierung ist die Brücke zwischen Messung und Handeln, und über diese Brücke kommt nur, was auf die Frage des jeweiligen Betrachters zugeschnitten ist.

Drei Einsichten tragen das. Die Darstellung folgt der Frage des Publikums, nicht dem technisch Möglichen, denn dieselbe Cycle Time wird für Team, Produkt und Leitung jeweils anders übersetzt. Jede Darstellung beantwortet genau eine Frage und sollte eine konkrete Handlung auslösen, weshalb Bestand, Verteilung, alternde Arbeit und Prognose getrennte Bilder verdienen. Und ein Dashboard lebt nur, wenn es an eine Entscheidung, einen Verantwortlichen und einen festen Anlass gekoppelt ist, statt als beeindruckende, aber folgenlose Anhäufung von Diagrammen zu existieren.

Damit ist das Handwerkszeug beisammen. Welche Muster in der Kombination dieser Darstellungen auf welche systemischen Probleme hindeuten und wie sich daraus konkrete Steuerungsentscheidungen ableiten lassen, ist ein Thema für sich.

Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.