Das Little'sche Gesetz in 3D

Die häufig verwendete Beziehung zwischen durchschnittlicher Zykluszeit, durchschnittlicher Gesamtarbeit und Inputrate (oder Durchsatz) ist als Little's Law bekannt. Es wird oft verwendet, um zu argumentieren, dass es gut ist, an weniger Artikeln gleichzeitig zu arbeiten (als Team oder als Einzelperson) und so die durchschnittliche Zykluszeit zu senken. In diesem Blog werde ich die weniger bekannte Verallgemeinerung des Little'schen Gesetzes erörtern, die eine fast unbegrenzte Anzahl zusätzlicher Beziehungen ermöglicht. Die einzige Grenze ist Ihre Vorstellungskraft. Ich werde Beziehungen für die durchschnittlichen 'Gesamtbetriebskosten im System' und für die durchschnittliche 'Just-in-Time' aufzeigen.

Zunächst beschreibe ich einige eher einfache Verallgemeinerungen und im dritten Teil einige komplexere Variationen des Littleschen Gesetzes.

Variationen des Little'schen Gesetzes

Wie ich in den vorangegangenen Blogs(Anwendung von Little's Law in Agile Games und Warum Little's Law funktioniert...immer) gezeigt habe, besagt Little's Law tatsächlich, dass die Messung der Gesamtfläche von links nach rechts gleich der Addition von oben nach unten ist. Sobald wir dies erkannt haben, ist es einfach, einige einfache und bekannte Verallgemeinerungen zu erkennen. Ich werde sie hier kurz erwähnen, ohne zu sehr ins Detail zu gehen. Teilsystem Nehmen wir an, ein System besteht aus 1 oder mehreren Teilsystemen, z.B. in einem Kanban-System, das aus 3 Spalten besteht, können wir die entsprechenden Teilsysteme identifizieren:

1. erste Spalte (z.B. 'Neu') in 'rot',
2. zweite Spalte (z.B. 'Doing') in 'gelb',
3. dritte Spalte (z.B. 'Erledigt') in 'grün'

Siehe Abbildung rechts. Indem wir die Teilsysteme unterschiedlich einfärben, sehen wir sofort, dass das Little'sche Gesetz sowohl für das System als Ganzes als auch für jedes Teilsystem gilt ('roter' und 'gelber' Bereich). Hinweis: Berücksichtigen Sie für die durchschnittliche Eingaberate nur die Zeilen, die die entsprechende Farbe haben, d.h. für die Eingaberate der Spalte 'Erledigen' nur die Zeilen, die eine gelbe Farbe haben; in diesem Fall entspricht die durchschnittliche Eingaberate 8/3 Artikeln pro Runde (Eingabe in die Spalte 'Erledigen'). Das Gleiche gilt für die Spalte 'Neu'. Arbeitsaufgabe Typ Bisher bin ich davon ausgegangen, dass es nur 1 Typ von Arbeitsaufgaben gibt. In der Praxis haben Teams mit mehr als einer Art von Arbeitsaufgaben zu tun. Beispiele hierfür sind Class of Service Lanes, User Stories und Production Incidents. Indem wir die verschiedenen Workitem-Typen unterschiedlich einfärben, sehen wir, dass Little's Law auf jeden einzelnen Workitem-Typ anwendbar ist. Im Beispiel rechts haben wir User Stories ('gelb') und Production Incidents ('rot') eingefärbt. Auch hier gilt das Little'sche Gesetz sowohl für den roten als auch für den gelben Bereich separat. Wenn wir nachrechnen, sehen wir, dass für 'User Stories' (gelber Bereich):

• Durchschnittliche Anzahl im System (N) = (6+5+4)/3 = 5 User Stories,
• Durchschnittliche Eingabequote ((lambda) = 6/3 = 2 Benutzergeschichten pro Runde,
• Durchschnittliche Wartezeit (W) = (3+3+3+3+2+1)/6 = 15/6 = 5/2 Runden.

Wie erwartet ist die durchschnittliche Anzahl im System gleich der durchschnittlichen Eingangsrate mal der durchschnittlichen Wartezeit. Die gleiche Berechnung kann für die Produktionsereignisse durchgeführt werden, was ich dem Leser als Übung überlasse. Artikel beschleunigen Betrachten Sie schließlich die Artikel, die in eine "Expedite"-Spur gelangen und dort Zeit verbringen. In Kanban wird eine Expedite Lane für Artikel verwendet, die besondere Priorität benötigen. In der Regel werden solche Artikel so gehandhabt, dass (a) höchstens 1 solcher Artikel im System vorhanden sein kann, (b) das Team die Arbeit an allen anderen Artikeln einstellt, damit sie so schnell wie möglich fertiggestellt werden, (c) sie Vorrang vor allen anderen Artikeln haben und (d) sie eventuell gegen WiP-Grenzen verstoßen. Wenn wir alle Artikel blau einfärben, die Zeit in der Expedite-Spur verbringen, können wir das Little'sche Gesetz auch auf die Expedite-Spur anwenden. Ein Beispiel für die Einfärbung finden Sie in der Abbildung rechts. Die Berechnung überlasse ich dem Leser.

3D

Wir können das Little'sche Gesetz sogar noch weiter ausdehnen. Bis jetzt habe ich nur "flache" Flächen betrachtet. Die Erweiterung besteht darin, dass wir jeder Zelle eine bestimmte Höhe geben können. Siehe die Abbildung rechts. Eine Abwandlung des Little'schen Gesetzes folgt, sobald wir erkennen, dass die Messung des Volumens von links nach rechts dasselbe ist wie die Berechnung von oben nach unten. Anstatt Flächen zu messen, messen wir stattdessen Volumina. Der einzige Haken an der Sache ist, dass wir, um das Little'sche Gesetz niederzuschreiben, der 'horizontalen' Summe der Zahlen und der 'vertikalen' Summe der Zahlen eine sinnvolle Interpretation geben müssen. Im Falle einer Höhe von '1' sind dies einfach die 'Wartezeit' (W) bzw. die 'Anzahl der Gegenstände im System' (N). Eine detailliertere, präzisere und mathematische Formulierung finden Sie in der Arbeit von Little selbst: siehe Abschnitt 3.2 in [Lit11].

Einige Anwendungen des 3D-Little's Law

Wert Betrachten Sie als Aufwärmübung den (geschäftlichen) Wert eines Artikels als Höhe. Nennen Sie diesen Wert 'V'. Jedes Arbeitsobjekt hat seinen eigenen spezifischen Wert.

( overline{mathrm{Value}} = lambda overline{V W} ) Die Interpretation dieser Beziehung ist, dass der"durchschnittliche (geschäftliche) Wert der unvollendeten Arbeit im System zu jedem Zeitpunkt" gleich der durchschnittlichen Inputrate multipliziert mit dem"Durchschnitt des Produkts aus Zykluszeit und Wert" ist. Teams können versuchen, diesen Wert zu minimieren und gleichzeitig die Wertoutputrate zu maximieren. Operative Gesamtkosten Als nächstes Beispiel nehmen wir als Höhe für die Zellen eine Folge von Zahlen 1, 2, 3, .... Ein Beispiel finden Sie in den folgenden Abbildungen. Wie sind die Interpretationen in diesem Fall? Nehmen wir an, wir haben ein Workitem, das Betriebskosten von 1 pro Tag hat. Dann ergibt die Reihenfolge 1, 2, 3, ... die Gesamtkosten bis heute. Am Tag 3 betragen die Gesamtkosten 3 mal 1, was die dritte Zahl in der Folge ist. Die 'vertikale' Summe ist einfach die'Gesamtkosten der unerledigten Arbeit im System'. Für die Interpretation der 'horizontalen' Summe müssen wir die Zahlen addieren. Für ein Workitem, das sich seit 'n' Tagen im System befindet, beträgt die Summe (1+2+3+...+n), was (1/2 n (n+1)) entspricht. Für 3 Tage ergibt dies (1+2+3=1/2 3 4 = 6). Die Interpretation der 'horizontalen' Summe ist also (1/2 W (W+1)), wobei 'W' für die Wartezeit des Artikels steht. Zusammengenommen ergibt sich ein zusätzliches Little'sches Gesetz der Form: ( overline{mathrm{Cost}} = frac{1}{2} lambda C overline{W(W + 1)} ) wobei 'C' der operative Kostensatz eines Arbeitspostens und (lambda) der (durchschnittliche) Inputsatz ist. Wenn anstelle von Spielrunden die'Gesamtkosten im System' in einem Zeitintervall 'T' gemessen werden, ändert sich die Formel geringfügig in ( overline{mathrm{Cost}} = frac{1}{2} lambda C overline{Wleft(W + Tright)} ) Die Teams möchten dies möglicherweise minimieren, was zu einem interessanten Optimierungsproblem führt, da verschiedene Arten von Arbeitsposten unterschiedliche Betriebskostensätze haben. Wie sollte die Kapazität des Teams auf die einzelnen Arbeitsaufgaben verteilt werden? Dies ist ein Thema für einen anderen Blog. Just-in-Time Eine etwas seltsamere Beziehung ergibt sich, wenn die Artikel mit einer Frist versehen sind. Bezeichnen Sie das Datum und die Uhrzeit der Frist mit 'D'. Als Höhe wählen Sie die Anzahl der Zeiteinheiten vor oder nach der Frist, in der der Artikel fertiggestellt wird. Nennen Sie außerdem 'T' die Zeit, die das Team für die Arbeit an dem Artikel benötigt hat. Dann schließt das Team die Arbeit an diesem Objekt zum Zeitpunkt ( T + W ) ab, wobei 'W' die Zykluszeit des Objekts darstellt.

In der Abbildung links sehen Sie ein Workitem, das 2 Tage vor dem Abgabetermin fertig ist. Beachten Sie, dass die Höhe abnimmt, je näher der Termin rückt. Da das Workitem 2 Zeiteinheiten vor dem Abgabetermin fertiggestellt wurde, beträgt die Just-in-Time 2 zum Zeitpunkt der Fertigstellung.

Das Bild auf der linken Seite zeigt ein Workitem, das eine Zeiteinheit nach dem Abgabetermin liegt und eine zugehörige Just-in-Time von 1 hat.

( overline{mathrm{Just-in-Time}} = frac{1}{2} lambda overline{|T+W-D|(|T+W-D| + 1)} ) Dieses Beispiel klingt sehr exotisch und nicht sehr nützlich. Ein Team könnte sich überlegen, wann der beste Zeitpunkt für den Beginn der Arbeit an einem Artikel ist, um die oben genannte Variable zu minimieren.

Fazit

Aus unserem 'Herumspielen' mit der Größe von Flächen und Volumina und der Erkenntnis, dass eine unterschiedliche Zählweise (von links nach rechts und von oben nach unten) zum gleichen Ergebnis führen sollte, konnte ich eine Reihe neuer Beziehungen ableiten. In diesem Blog habe ich bekannte Variationen des Little'schen Gesetzes in Bezug auf Subsysteme und Workitem-Typen neu abgeleitet. Darüber hinaus habe ich neue Beziehungen für die"durchschnittlichen Gesamtbetriebskosten", den"durchschnittlichen Wert" und die"durchschnittliche Just-in-Time" abgeleitet. Zusammen mit dem bekannten Little's Law ergeben sich daraus interessante Optimierungsprobleme und möglicherweise praktische Leitlinien für Teams, die noch mehr Wert schaffen wollen. Ich bin gespannt auf die Variationen, die Sie sich einfallen lassen! Lassen Sie es mich wissen, indem Sie sie hier posten.

Referenzen

[Lit11] John D.C. Little,"Little's Law as Viewed on Its 50th Anniversary", 2011, Operations Research, Vol. 59 , No 3, pp. 536-549,

Little's Law aus Sicht des 50. Jahrestages