Ein Wertstrom ist der Weg, den Wert von der ersten Idee bis in die Produktion zurücklegt. Er ist die Summe aller Schritte, Übergaben und Wartezeiten dazwischen. In diesem Video zeige ich ein einfaches Vorgehen in sieben Schritten: einen Wertstrom identifizieren, ehrlich messen, ein Zielbild entwerfen und dann Schritt für Schritt dorthin arbeiten. Die Zahlen im Beispiel sind bewusst vereinfacht, damit die Methode im Vordergrund steht und nicht ein einzelnes Ergebnis.
Schritt 1: Den Wertstrom identifizieren#
Der erste Schritt ist immer derselbe: einen Wertstrom auswählen und aufzeichnen. In meinem Beispiel nehme ich einen sehr klassischen, vereinfachten Ablauf. Er beginnt mit einer Idee, zum Beispiel einem neuen Feature. Danach wird die Spezifikation geschrieben, das Feature implementiert, manuell getestet und schliesslich manuell in die Produktion deployed.
Das ist kein kompliziertes Diagramm. Fünf Boxen hintereinander reichen. Entscheidend ist, dass man die Schritte explizit macht, denn verbessern kann man nur, was man sichtbar gemacht hat. Sobald der Wertstrom auf dem Papier steht, schauen alle auf dasselbe Bild und das Gespräch dreht sich plötzlich nicht mehr um Meinungen, sondern um Beobachtungen.
Schritt 2: Die Menschen im Wertstrom identifizieren#
Im nächsten Schritt schaut man, wer in jedem Schritt tatsächlich arbeitet. In meinem Beispiel hat das Business die Idee und schreibt auch die Business-Spezifikation. Die Entwickler implementieren das Feature. Ein Quality Engineer testet manuell. Und Operations deployt das Feature manuell in die Produktion.
Diese Übung klingt trivial, macht aber schnell deutlich, wie viele Übergaben im Spiel sind. Jede Übergabe zwischen diesen Gruppen ist eine potenzielle Quelle für Verzögerung, Rework und Missverständnisse. Wenn man buchstäblich sieht, wie viele Hände ein Feature zwischen Idee und Produktion berühren, versteht man schnell, warum alles so lange dauert, obwohl niemand wirklich langsam ist.
Schritt 3: Messen, was wirklich passiert#
Jetzt wird gemessen. Für jeden Schritt schaue ich auf drei Zahlen: Process Time, Lead Time und Percentage Complete and Accurate.
Process Time ist die Zeit, in der tatsächlich gearbeitet wird. Lead Time ist die Zeit vom Eintritt einer Aufgabe in einen Schritt bis zum Austritt, inklusive aller Wartezeiten dazwischen. Percentage Complete and Accurate sagt, wie oft die Arbeit, die weitergegeben wird, gut genug ist, oder wie oft sie zurückgeschickt und erneut gemacht werden muss.
Im Beispiel sehen die Zahlen so aus:
- Idee: Process Time 8 Stunden, Lead Time 8 Stunden, Percentage Complete and Accurate 75 Prozent.
- Spezifikation schreiben: Process Time 40 Stunden, Lead Time 80 Stunden, Percentage Complete and Accurate 50 Prozent.
- Implementierung: Process Time 40 Stunden, Lead Time 80 Stunden, Percentage Complete and Accurate 75 Prozent.
- Manuelles Testen: Process Time 16 Stunden, Lead Time 40 Stunden, Percentage Complete and Accurate 50 Prozent.
- Manuelles Deployment: Process Time 1 Stunde, Lead Time 8 Stunden, Percentage Complete and Accurate 80 Prozent.
Diese drei Zahlen pro Schritt reichen, um eine sehr ehrliche Diskussion über den Zustand des Systems zu führen. Und sie sind etwas, das man ohne teures Tooling wirklich erheben kann.
Schritt 4: Den Ist-Zustand analysieren#
Mit den Messungen auf dem Tisch wird zusammengezählt. Im Beispiel ergibt das eine Total Process Time von 105 Stunden und eine Total Lead Time von 216 Stunden. Die Rolling Percentage Complete and Accurate liegt bei nur 11 Prozent. Das heisst: Von 100 Ideen kommen nur 11 sauber durch diese Pipeline, ohne irgendwo nachgebessert zu werden. Die Activity Ratio, also Total Process Time geteilt durch Total Lead Time, liegt bei rund 48 Prozent.
In der Analyse schaue ich auch darauf, wo die Bottlenecks liegen, wo Übergaben lange Wartezeiten erzeugen und wo die Differenz zwischen Process Time und Lead Time am grössten ist. Genau in dieser Differenz sitzen die Ideen in Warteschlangen und werden gerade nicht bearbeitet. In den meisten Wertströmen steckt dort das grösste Verbesserungspotenzial.
Schritt 5: Den Ziel-Wertstrom entwerfen#
Sobald wir den Ist-Zustand verstehen, entwerfen wir die Zukunft. Der Ziel-Wertstrom nutzt dieselbe Struktur, aber die Schritte und Zahlen sehen anders aus.
- Idee durch das Business: Process Time 8 Stunden, Lead Time 8 Stunden, Percentage Complete and Accurate 100 Prozent.
- Statt Spezifikationen schreibt das Team User Stories: Process Time 8 Stunden, Lead Time 8 Stunden, Percentage Complete and Accurate 100 Prozent.
- Implementierung, wieder durch das Team: Process Time 20 Stunden, Lead Time 40 Stunden, Percentage Complete and Accurate 80 Prozent.
- Continuous Integration ersetzt das manuelle Testen. Der Build-Server baut und testet automatisch: Process Time 0,1 Stunden, Lead Time 0,1 Stunden, Percentage Complete and Accurate 100 Prozent.
- Continuous Deployment ersetzt das manuelle Deployment, zuerst in UAT und dann automatisch in die Produktion: Process Time 0,1 Stunden, Lead Time 0,1 Stunden, Percentage Complete and Accurate 100 Prozent.
Dass die Implementierung nur bei 80 Prozent Complete and Accurate liegt, ist kein Versehen. Die Continuous-Integration-Pipeline darf Implementierungen zurückweisen, wenn ein Test fehlschlägt. Genau dafür sind automatisierte Tests da. Das Rework passiert in Sekunden, nicht in Tagen.
Zusammengezählt ergibt das Zielbild eine Total Process Time von 36,2 Stunden, eine Total Lead Time von 56,2 Stunden, eine Rolling Percentage Complete and Accurate von 80 Prozent und eine Activity Ratio von rund 64 Prozent. Im Klartext: 80 Prozent der Ideen gehen direkt in die Produktion, und die Leute verbringen einen deutlich grösseren Teil ihrer Zeit mit echter Arbeit statt mit Warten.
Schritt 6: Massnahmen definieren#
Das Zielbild ist nicht der Plan. Der Plan ist die Liste konkreter Schritte, mit denen ich vom Ist-Zustand zum Zielbild komme. Ich lege beide Wertströme nebeneinander und identifiziere genau, was sich ändern muss: was automatisiert werden kann, welche Übergaben wegfallen, welche Rollen sich verschieben, welche architektonischen Anpassungen nötig sind, damit Continuous Integration und Continuous Deployment überhaupt funktionieren.
Diese Massnahmen priorisiere ich und packe sie in ein Backlog. Das ist wichtig: Einen Wertstrom zu verbessern ist kein Big-Bang-Projekt. Es ist eine Folge kleiner, priorisierter Änderungen, die zusammen mit den Menschen im Wertstrom umgesetzt werden.
Schritt 7: Die Übung wiederholen#
Der letzte Schritt ist der wichtigste, und er wird in den meisten Organisationen vergessen. Value Stream Mapping ist keine einmalige Übung. Es ist etwas, das wiederholt wird. Ich würde es typischerweise alle drei Monate machen und anschauen, wie sich der Wertstrom in Richtung Zielbild bewegt hat.
Die Realität vor Ort verändert sich. Neues Tooling kommt dazu. Das Team lernt. Bottlenecks verschieben sich. Ohne regelmässige Reviews driftet der Wertstrom in alte Muster zurück, und der Aufwand, den man früher investiert hat, verpufft leise. Wer die Übung wiederholt, macht aus Verbesserung eine Gewohnheit statt eines Ereignisses.
Wichtigste Erkenntnisse#
Den Wertstrom zuerst sichtbar machen. Die Schritte von der Idee bis zur Produktion aufzeichnen und die Menschen in jedem Schritt benennen. Verbessern kann man nur, was man explizit gemacht hat.
Process Time, Lead Time und Percentage Complete and Accurate messen. Diese drei Zahlen sind einfach, ehrlich und reichen aus, um die echten Probleme sichtbar zu machen.
Auf die Differenz zwischen Process Time und Lead Time achten. Dort sitzt die Arbeit in Warteschlangen. Die meisten Verkürzungen der Lead Time entstehen durch das Entfernen von Wartezeit, nicht durch schnelleres Arbeiten.
Ein Zielbild entwerfen und konsequent darauf hinarbeiten. Manuelles Testen durch Continuous Integration ersetzen, manuelles Deployment durch Continuous Deployment, Spezifikationen durch User Stories aus dem Team.
Ein priorisiertes Backlog an Massnahmen führen. Ist und Ziel vergleichen, nötige Massnahmen ableiten, priorisieren und wie jede andere Arbeit umsetzen.
Alle drei Monate wiederholen. Continuous Improvement ist das eigentliche Ergebnis dieser Übung. Eine einzelne Analyse verändert wenig, ein Rhythmus verändert die Organisation.