Kostenloses Werkzeug
Nimm einen kürzlich abgeschlossenen Vorgang — einen Antrag, eine Änderung, eine Freigabe. Zähl die Tage von der Auslösung bis zum gelieferten Ergebnis. Schätz dann die Stunden echter Arbeit darin. Diese Seite stellt die beiden Zahlen nebeneinander.
Der ganze Zeitraum, Warten eingeschlossen: vom Moment der Anforderung bis zum Eintreffen des Ergebnisses.
Nur die Zeit, in der wirklich daran gearbeitet wird. Trag Stunden ein: 45 Minuten am Antrag sind 0,75, nicht 45.
Lean unterscheidet drei Arten von Zeit: wertschöpfende Arbeit, notwendige nicht wertschöpfende Arbeit (etwa eine gesetzlich verlangte Prüfung) und Verschwendung. Für diesen Rechner zählen die ersten beiden — jede Minute, in der der Vorgang aktiv bearbeitet wird, einschließlich Prüfungen und Freigaben, solange sie tatsächlich stattfinden. Nicht mitzählen: die Zeit, in der der Vorgang liegt — Postfächer, Ticket-Warteschlangen, Sammelläufe, Warten auf einen Termin oder ein Release-Fenster.
Mehrere Personen gleichzeitig. Zähl die verstrichene Bearbeitungszeit einmal, nicht die Summe pro Kopf. Eine Stunde Besprechung mit vier Personen ist hier eine Stunde, nicht vier. Personenstunden blähen die Arbeitsseite auf und können die Durchlaufzeit sogar übersteigen.
Wenn Maschinen arbeiten. Wird der Vorgang tatsächlich verändert — eine Pipeline baut ihn, ein Nachtlauf verarbeitet ihn — ist das Bearbeitungszeit und kein Warten, auch wenn niemand ihn anfasst. Zeit, in der er nur in einer Warteschlange liegt, ist Warten, ob mit Maschine oder ohne. So oder so: einmal entscheiden und bei jedem Vorgang gleich handhaben, sonst sind deine Zahlen untereinander nicht vergleichbar.
Es zu lösen, ist Gegenstand des Kurses. In DevOps & IT Service Management nehmen wir dasselbe Sechs-Wochen-Beispiel wieder auf und gestalten es Schritt für Schritt um. Oder du bringst deinen eigenen Wertstrom mit, dann verbessern wir den gemeinsam.
Zum Kurs →Nichts von dem, was du oben eingetragen hast, wird irgendwohin gesendet — der Link öffnet lediglich die Kursseite.
Flow Efficiency setzt die Zeit echter Arbeit ins Verhältnis zur gesamten Durchlaufzeit: Arbeitszeit geteilt durch Durchlaufzeit, mal hundert. Braucht ein Vorgang zwanzig Tage und stecken darin sechzehn Stunden Arbeit, sind das bei einem Achtstundentag zwei Arbeitstage — also zehn Prozent.
Die Zahl ist deshalb interessant, weil sie die übliche Blickrichtung umdreht. Wer Durchlaufzeit senken will, beschleunigt meist die Arbeit. Bei zehn Prozent Flow Efficiency liegen aber neunzig Prozent der Zeit im Warten — dort ist der Hebel, und dort schaut selten jemand hin.
Arbeitszeit geteilt durch Durchlaufzeit, in Prozent. Die Durchlaufzeit läuft ab dem Zeitpunkt, an dem die Anforderung existierte, nicht ab dem Beginn der Bearbeitung — sonst misst man das Warten aus der Rechnung heraus.
Darauf gibt es keine belastbare Antwort. Die viel zitierte Regel „5 bis 15 Prozent sind typisch“ ist Erfahrungswissen aus Vorträgen von David J. Anderson, nicht das Ergebnis einer Studie. Die einzige größere veröffentlichte Messung — 63 Teams bei ASOS — fand 9 bis 68 Prozent. Der brauchbare Vergleich ist der eigene Prozess zu einem früheren Zeitpunkt.
Nicht zwangsläufig. Ein niedriger Wert heißt, dass viel Zeit im Warten liegt — das kann an Abhängigkeiten, Freigaben oder Priorisierung liegen und ist manchmal bewusst so gewählt. Die Zahl bewertet nichts, sie zeigt, wo überhaupt zu suchen wäre.
Weil der Zähler kleiner wird — bei gleicher Durchlaufzeit sinkt die Flow Efficiency, wenn die Arbeit schneller geht. Genau das ist der Punkt: Wer die Zahl als Zielwert benutzt, optimiert am Ende in die falsche Richtung. Sie ist eine Diagnose, keine Kennzahl fürs Berichtswesen.
Als Argument. Die Aussage „wir brauchen mehr Leute“ und die Aussage „neunzig Prozent der Zeit warten wir auf eine Freigabe“ führen zu völlig verschiedenen Maßnahmen — und nur die zweite lässt sich mit einer gemessenen Zahl belegen.