Kaum eine Kanban-Einführung vergeht, ohne dass irgendwann Littles Gesetz erwähnt und als (meist die) Erklärung für die Sinnhaftigkeit von WIP-Limits herangezogen wird. Theoretisch mag dieser Ansatz richtig sein, praktisch erscheint er mir sehr wenig zielführend.
Die wenigsten Informatiker (und noch weniger Betriebswirtschaftler) werden das Thema „Warteschlangentheorie“ im Studium genossen haben – und mit einer hübschen Formel am Flipchart lässt sich auch nur beeindrucken, wenn sich der Trainer beim Erklären der beteiligten Variablen und Rahmenbedingungen nicht hoffnungslos verhaspelt. Klar wird oft nur: Auch das Studium des Trainers ist schon lange her – und die tolle Formel vielleicht doch gar nicht so einleuchtend.
Genau genommen scheint mir das Gegenteil der Fall zu sein: Littles Theorem1 ist für die meisten Menschen hochgradig kontraintuitiv; die oft nicht ganz sattelfesten Erklärungsversuche enden erstaunlich häufig sogar in der m. E. sehr schädlichen Erwartungshaltung, eine geringere Durchlaufzeit bedeute zwingend einen höheren Durchsatz. Dabei halte ich eine funktionierende Erklärung für wirklich wichtig, verstößt die Einführung von WIP-Limits doch gegen die Instinkte vieler Menschen (m. E. vor allem gegen die Instinkte der meisten Führungskräfte).
Dennoch: Viel zu häufig dürfte die Erklärung mit Little’s Law beginnen – und dann auch gleich enden, so, als wäre damit per se bereits etwas Wichtiges gesagt, tiefe Einsicht erzeugt. Nichts davon ist m. E. der Fall – und wichtige Vorteile von WIP-Limits werden zudem durch die zwar natürlich nicht unrichtige, aber in meinen Augen unvollständige und vor allem nur allzu häufig unverstandene Erklärung unterschlagen.
Wie es vielleicht besser geht: Hilfreiche Metaphern statt Formeln
Ich erkläre die Wirkung von WIP-Limits am liebsten mit einem Fluss – nicht etwa mit dem Arbeitsfluss, sondern tatsächlich mit einem physischen Fluss in der Landschaft (vgl. hier): An den Stromschnellen fließt das Wasser schneller; aber mehr, als durch den Engpass passt, passt eben auch nicht hindurch – es sei denn, ich erweitere den Fluss an genau dieser Stelle2. Gerade an der Engstelle fließt es zudem sehr gleichmäßig, die Wirbel sind davor und vor allem dahinter. Übertragen auf den Arbeitsfluss: Die Durchlaufzeit und ihre Varianz3 sinkt, aber der Durchsatz steigt nur, wenn ich auch mehr Menschen daran arbeiten lasse.
Orientiert sich das WIP-Limit an der tatsächlichen Kapazität, ist es also gar kein „künstlicher Engpass“ (als das WIP-Limits oft angesehen werden), sondern nur eine Explizierung des Faktischen4 – und es gilt vor allem, den vorhandenen Engpass optimal auszulasten5. Wird das Faktische des Engpasses mit der Metapher des Flusses nicht deutlich genug, hilft mir ergänzend oft die Metapher vom Flughafen6: Es sollten im Mittel ebenso viele Flugzeuge abfliegen wie landen – ebenso viel Arbeiten fertig werden wie neue Arbeit in das System gespeist wird –, andernfalls stapeln sich die Flugzeuge auf dem Rollfeld:
Wichtig neben diesen Erklärungen erscheint mir aber vor allem, die weiteren Vorteile von WIP-Limits nicht zu unterschlagen (wie es mit der Formel am Flipchart – der Reduktion auf das Thema „Warteschlange“ – schnell passiert):
- Mehr WIP bedeutet mehr Kontextwechsel und damit mehr Overhead. Hier hilft mir in der IT oft das Bild der CPU. Jeder, der sich ein wenig mit hardwarenaher Programmierung beschäftigt hat, wird bestätigen können: Context Switches erzeugen einen hohen Overhead, der gesamte Zustand der CPU muss gesichert werden, bevor sich die CPU (ja nur zeitweilig) anderer Arbeit widmen kann – und das Verhältnis von Threads zu CPU-Kernen will wohl ausbalanciert sein. Erstaunlicherweise kommt kaum jemand auf die Idee, dass das mit Menschen kaum anders ist: mentale, soziale oder faktische Rüstzeiten sind ein enormer Effizienzkiller und verursachen zudem schlichtweg Stress7.
- Die Fehlerrate steigt mit der Anzahl der gleichzeitigen Aufgaben, Multitasking verursacht Fehler und Stress8. Dieser Sachverhalt ist wohlerforscht; ich neige praktisch aber dazu, an dieser Stelle einfach nur auf das Thema „Smartphone am Steuer“ als Beispiel zu verweisen9.
- Limitiert man explizit die Menge der Arbeit im (sowieso faktischen) Engpass, werden strukturelle oder sich wiederholende Probleme im Arbeitsfluss viel offensichtlicher als im Falle eines einfach nur „verstopften“ Engpasses – schon allein, weil man weniger Arbeitseinheiten untersuchen muss, um die Probleme zu identifizieren. Liegt in der Stromschnelle – um auf den Fluss zurückzukommen – etwas quer und staut sich das Wasser, ist dies sofort offenkundig. Staut sich die Arbeit aber einfach nur scheinbar verteilt im gesamten System, verstellt dieser Stau meist die Sicht auf die wahren Probleme der Abarbeitung.
- Die Wahrscheinlichkeit, eine Kultur des „Die-Dinge-auch-fertig-Machens“ zu erzeugen, steigt deutlich. In vielen Organisationen ist es erstaunlich üblich, die Dinge im „95% fertig“-Zustand zu belassen – und dann Unfertiges gleichzeitig womöglich als Beweis für die eigene Überlastung oder wahlweise der eigenen Wichtigkeit demonstrativ vor sich herzutragen. WIP-Limits können das verhindern, können sogar dazu führen, dass „fertig geworden sein“ wieder gefeiert wird!
- Oft gehört ist die Behauptung, WIP-Limits würden geradezu automatisch ein Pull-System erzeugen, seien womöglich gar eine notwendige Voraussetzung dafür. Ich halte beides für Unsinn: Ersteres wäre nur richtig, wenn das Limit zum „Pull“ zwingen würde – es begrenzt ihn aber nur. Wäre letzteres richtig, gäbe es nicht so viele Menschen, die sich aus eigenem Antrieb den Schreibtisch bis zum Anschlag mit Arbeit füllen – auch das ist irgendwie ein Pull-System, aber eben ohne WIP-Limits und damit oftmals weitgehend unkontrolliert. Was aber (gerade angesichts dieses Beispiels) offenkundig richtig ist: WIP-Limits ermöglichen – in Verbindung mit weiteren Prozessregeln bspw. für den eigentlichen „Pull“ –, ein Pull-System zu steuern, nicht nur i. S. eines oft doch recht kybernetischen „visuellen Managements“ am Kanban-Board, sondern insbesondere aufgrund der vorgenannten Aspekte eben auch i. S. wertschätzender (Menschen‑)Führung.
All das steckt nicht in L = λW – und ist doch so wichtig und in vielen Fällen sogar viel wirksamer als die bloße Betrachtung und Modifikation des Wartesystems. Es mit einigen wenigen prägnanten Metaphern zu illustrieren, erscheint mir deutlich wirksamer als die nackte Theorie – und ergänzt man seine Erläuterungen auch noch durch praktisches (und haptisches) Erleben – im Zweifel in Form eines Simulations-„Spiels“10 –, gewinnt diese Wirksamkeit womöglich auch an Nachhaltigkeit.
Fußnoten:
- ↑ Bei genauerer Betrachtung handelt es sich nicht um ein Gesetz, sondern um ein Theorem und damit um eine Tautologie. Vgl. Little, J. D. C.; Graves, S. C.: Little’s Law. In: Chhajed, Dilip (Hrsg.); Lowe, Timothy J. (Hrsg.): Building Intuition. Insights from Basic Operations Management Models and Principles. Springer Science & Business Media (2008). S. 85.
- ↑ An dieser Stelle erscheint mir manchmal ein kurzer Exkurs zu Eliyahu M. Goldratts Theory of Constaints (TOC) empfehlenswert.
- ↑ Auch etwas, dessen tieferer Sinn sich nicht jedem auf Anhieb erschließt – hier von „Qualität“ zu sprechen, hat sich als hilfreich erwiesen.
- ↑ Vgl. bspw. <https://www.leanability.com/de/blog-de/2017/10/wip-limits-muessen-sterben/> (03.08.2020) nebst der Diskussion zu diesem Beitrag.
- ↑ Wie man einen Engpass trotz Wartezeiten optimal auslastet, erkläre ich gern mit der Metapher von der Zahnarztpraxis; vgl. hier.
- ↑ Vgl. LEANability, a. a. O.
- ↑ Schön zusammengefasst bspw. unter <https://www.apa.org/research/action/multitask>, archiviert am 30.07.2020 unter <https://web.archive.org/web/20200730015607/https://www.apa.org/research/action/multitask>.
- ↑ Vgl. Baethge, A.; Rigotti, T.: Arbeitsunterbrechungen und Multitasking. Ein umfassender Überblick zu Theorien und Empirie unter besonderer Berücksichtigung von Altersdifferenzen
1. Auflage. Dortmund: Bundesanstalt für Arbeitsschutz und Arbeitsmedizin 2010. Dankenswerterweise online verfügbar unter <https://www.baua.de/DE/Angebote/Publikationen/Berichte/F2220.html> (03.08.2020). - ↑ Vgl. <https://www.besmart-mobil.de/unfallursache-nr-1-smartphone-am-steuer/> (03.09.2020).
- ↑ Bspw. Featureban, vgl. hier.
Die Fehlerrate sinkt mit der Anzahl der gleichzeitigen Aufgaben, Multitasking verursacht Fehler und Stress8.
Muss es nicht heißen die Fehlerrate steigt mit der Anzahl der gleichzeitigen Aufgaben? Je mehr ich gleichzeitig tue, desto mehr Stress, desto mehr Fehler?
In der Tat! Vielen Dank!