Planview Blog

Ihr Weg zu geschäftlicher Agilität

Enterprise Agile Planning

The Lead Time and Cycle Time Debate: When Does the Clock Start?

Veröffentlicht Von Tommy Norman

Vor kurzem habe ich mit einer Gruppe meiner Planview AgilePlace-Kollegen über Kanban gesprochen. Die uralte Debatte über die Definitionen von Durchlaufzeit und Zykluszeit kam auf, und wir rollten alle ein wenig mit den Augen. Die Lean-Gemeinschaft hat dieses Thema bereits eine Million Mal aufgewärmt, aber es scheint, dass wir immer noch keinen Konsens finden können. Das Thema kann für Kanban-Neulinge verwirrend sein und frustriert erfahrene Praktiker immer wieder. In diesem Beitrag erkläre ich, warum diese Definitionen häufig umstritten sind. Ich erkläre Ihnen auch, wie eine einfache Definition Ihnen helfen kann, das Beste aus diesen Lean-Kennzahlen herauszuholen.

Wann beginnt die Uhr?

Die Debatte um Vorlaufzeit und Zykluszeit dreht sich im Wesentlichen um Folgendes: Wann beginnt die Uhr zu laufen?

Kanban-Neulinge denken oft, dass sich die Vorlaufzeit auf die Zeit zwischen der Anforderung einer Arbeit und dem tatsächlichen Arbeitsbeginn bezieht.

Die allgemein akzeptierte Vorstellung ist, dass die Vorlaufzeit mit der Anfrage eines Kunden beginnt und mit der Lieferung des Wertes an diesen Kunden endet.

Aber was ist eine Anfrage? In der traditionellen schlanken Fertigung stellt eine Anfrage eine Kundenbestellung für ein physisches Produkt dar.

In der Wissensarbeit kann eine Anfrage viel immaterieller sein: Um ein Beispiel aus der Softwareentwicklung zu verwenden, könnte es sich um eine ungeprüfte Idee für eine Funktion handeln. Diese Idee muss möglicherweise einen Priorisierungsprozess durchlaufen, bevor sie überhaupt in das Backlog eines Teams aufgenommen wird. Dann stellt sich die Frage: Hat die Uhr zu ticken begonnen - als wir die Idee hatten oder als sie in den Auftragsbestand aufgenommen wurde?

An dieser Stelle kann die Definition von Vorlaufzeit und Zykluszeit schwierig werden. Die Begriffe werden oft synonym verwendet. Wenn dies geschieht, verlieren die dahinter stehenden Metriken ihre Bedeutung.

Aus diesem Grund haben einige Leute den Begriff Vorlaufzeit durch spezifischere Begriffe ersetzt: Kundenvorlaufzeit zum Beispiel oder Systemvorlaufzeit. Dadurch wird klar, was genau gemessen wird und für wen.

Anstatt sich mit diesen Unterschieden herumzuschlagen, sollten Sie mit den Grundlagen beginnen. Fragen Sie sich selbst: Welches Problem versuche ich mit diesen Metriken zu lösen?

Fragen Sie bei allen Metriken zuerst nach dem "Warum?"

Diese Frage habe ich meinen Kollegen während unseres Gesprächs gestellt. Einer von ihnen sagte: "Wir müssen die Zykluszeit kennen, damit wir wissen, wie schnell wir etwas produzieren können."

"Okay", sagte ich. "Warum?"

Das brachte mir einige verwirrte Blicke ein, aber ich fuhr fort: "Ganz gleich, wie Sie sie definieren, Durchlaufzeit und Zykluszeit sind Messgrößen. Wir verschwenden Zeit damit, darüber zu diskutieren, was genau sie messen.

Lassen Sie uns einen Schritt zurücktreten und uns fragen, warum wir diese Informationen überhaupt wissen wollen."

Die darauf folgende Diskussion war viel produktiver. Wir waren uns alle einig, dass wir diese Informationen wissen wollten, damit wir bessere Vorhersagen über unsere Arbeit machen konnten.

Ein Beispiel

Nehmen wir an, Sie erhalten vom Vertrieb eine Anfrage für eine neue Produktfunktion. Logischerweise lautet die erste Frage, die sich der Vertrieb stellt: "Wann kann ich mit der Fertigstellung dieser Funktion rechnen?"

Sie können davon ausgehen, dass das Feature etwa 10 Tage dauern wird. Aber sollten die Verkäufer damit rechnen, das Feature in 10 Tagen zu sehen? Nein.

Und warum? Denn ihre Anfrage wird zusammen mit allen anderen aktuellen Anfragen priorisiert.

Und warum? Ihre Anfrage wird zusammen mit allen anderen aktuellen Anfragen priorisiert. Wenn also unsere durchschnittliche Zeit von der Anfrage bis zur Lieferung (Vorlaufzeit) 10 Tage beträgt und sich vor dieser neuen Anfrage aus dem Vertrieb 4 Artikel in der Warteschlange befinden, würden wir prognostizieren, dass die Anfrage höchstwahrscheinlich in 50 Tagen geliefert wird. (10 Tage pro Feature, mal fünf.)

Hinweis: Bei dieser Art von Prognosen ist Vorsicht geboten, da die Verwendung eines Durchschnittswerts nicht immer den Grad der Schwankungen widerspiegelt, der bei der Arbeit mit Wissen üblich ist.

Wie wir Vorlauf- und Zykluszeiten definieren

Lead Time

Bei Planview AgilePlace definieren wir Vorlaufzeit als die Zeitspanne zwischen dem Zeitpunkt, an dem eine Anfrage gestellt wird, und dem Zeitpunkt, an dem sie an den Kunden geliefert wird. Oft qualifizieren wir den Begriff als "Kundenvorlaufzeit", um uns daran zu erinnern, dass diese Kennzahl aus der Perspektive des Kunden betrachtet wird.

Natürlich können wir nicht einfach mit jeder Arbeit beginnen, sobald die Anfrage gestellt wird. Das wäre unhaltbar, um nicht zu sagen unklug. Wenn eine Anfrage gestellt wird, verbringt sie normalerweise einige Zeit im Backlog, bevor sie bearbeitet wird. Um zu optimieren, wie wir arbeiten, müssen wir uns eine detailliertere Metrik ansehen. Deshalb ist es sinnvoll, sowohl die Vorlaufzeit, wie oben beschrieben, als auch die Zykluszeit zu messen.

Zykluszeit

Die Zykluszeit ist die Zeitspanne zwischen dem Beginn der Arbeit an einer Anfrage und der Auslieferung an den Endkunden. Die Zykluszeit misst alle aktiven (wertschöpfenden) Arbeitszeiten sowie die Wartezeiten zwischen den aktiven Arbeitszeiten. Es ist nützlich, die Zykluszeit zu messen, um ein Verständnis dafür zu bekommen, wie effizient Ihr System arbeitet. Daniel Vacanti hat gerade einen hervorragenden Beitrag auf veröffentlicht, in dem er erklärt, wie man die Zykluszeit berechnet.

Prozess-Zykluszeiten

Für noch mehr Details kann es hilfreich sein, auch die Zykluszeit der einzelnen Prozesse zu analysieren. Wenn Sie beispielsweise wissen möchten, wie effizient Ihr Team den Schritt "Design" durchläuft, würden Sie die Design-Zykluszeit messen. Für die Design-Zykluszeit würde die Uhr beginnen, wenn die Arbeit in die Design-Spur eintritt, und stoppen, wenn sie in die nächste Spur übergeht. Wenn Sie die Design-Zykluszeit für mehrere Workitems messen, erhalten Sie einen Überblick darüber, wie lange die Arbeit für den Design-Schritt benötigt.

Wenn Sie jeden einzelnen Schritt so weit wie möglich optimieren und Ihre Gesamtzykluszeit immer noch langsam ist, gibt es vielleicht eine einfache Erklärung: Übergaben. Bei den meisten Systemen liegt der Großteil der Verschwendung in den Wartezeiten zwischen den Schritten - nicht in den Schritten selbst. Die Messung individueller Zykluszeiten kann Ihnen helfen, langsame Übergaben und andere Hindernisse für den Arbeitsfluss zu erkennen.

Metriken klug einsetzen

Vorlaufzeit und Zykluszeit helfen uns bei der Vorhersage, wann die Artikel in unseren Rückständen fertiggestellt werden können. Dies hilft uns, effektiver mit unseren Stakeholdern zu kommunizieren.

Die Untersuchung der Prozesszykluszeiten kann uns helfen, Möglichkeiten zur Verbesserung des Flusses zu identifizieren. Die Verringerung unserer Zykluszeiten bedeutet einen besseren Arbeitsfluss, was bedeutet, dass wir unsere Kunden schneller beliefern können.

Wir müssen darauf achten, dass unsere Bemühungen, die Vorlauf- und Zykluszeit zu verkürzen, keine negativen Auswirkungen auf andere Bereiche des Unternehmens haben (Produktqualität, Kundenzufriedenheit usw.). Die Geschwindigkeit, mit der die Artikel unseren Prozess durchlaufen, ist nur ein Indikator dafür, wie gut wir liefern, und sollte in einem angemessenen Verhältnis zu anderen Schlüsselkennzahlen stehen. Erfahren Sie mehr über die Gefahren von Eitelkeitsmetriken in diesem Beitrag.

Wenn wir nicht mehr über Begriffe diskutieren, sondern uns fragen, warum diese Kennzahlen wichtig sind, können wir damit beginnen, sie in unseren Teams effektiv einzusetzen. Wenn wir das Gespräch vom "Was" auf das "Warum" verlagern können, können wir uns auf das konzentrieren, was wirklich wichtig ist: die Verbesserung der Wertschöpfung für unsere Kunden.

Verwandte Beiträge

Geschrieben von Tommy Norman

Tommy ist der Lean/Agile Coach bei LeanKit und sorgt dafür, dass wir die Werte und Prinzipien hinter unserem Produkt verkörpern. Er ist der Leiter der Agile Nashville User Group und der Music City Agile Konferenz und spricht häufig auf lokalen und nationalen Veranstaltungen. Tommy ist ein 9-facher Microsoft MVP. Seine Agile-Trainingsreihe war in den letzten zwei Jahren das meistverkaufte Agile-Video auf Safari Books Online. Kontaktieren Sie ihn unter @tommynorman.