WIP-Limits helfen uns dabei, die Arbeit unter Kontrolle zu bekommen. Sie erfordern aber auch ein sehr diszipliniertes Vorgehen, damit hohe Geschwindigkeiten erzielt werden können. In diesem Post erkläre ich, was passiert, wenn die Limits angehoben werden, und gebe eine Empfehlung, was Du stattdessen tun solltest.
WIP revisited
Häufig beobachte ich, dass Teams die anfänglich selbstgesetzten WIP-Limits nach einiger Zeit hochsetzen. Auf meine Nachfrage höre ich gute Gründe: Verschiedene Tickets warten auf die Bereitstellung einer spezialisierten Ressource – ein Testsystem oder bestimmte Spezialisten zum Beispiel – und können nicht weiter bearbeitet werden und ruck-zuck ist das WIP-Limit erschöpft, denn blockierte Tickets zählen in das Limit. Wenn Arbeitseinheiten warten, bedeutet das, dass die zuständigen Bearbeiter nicht weiter daran arbeiten können. Auch die Bearbeiter sind blockiert. Natürlich könnten sie versuchen, Kollegen zu unterstützen, aber wenn das nicht möglich oder sinnvoll ist, sitzen sie bildlich gesprochen herum. Das kann nicht richtig sein und fühlt sich schlecht an: Unnütz herumsitzen kann nicht die Lösung sein!
Mit erhöhtem WIP-Limit können Teammitglieder weiterarbeiten und sind beruhigt.
Was aber ist die langfristige - meist noch nicht sichtbare - Auswirkung? Und warum ist sie problematisch?
Auswirkungen steigenden WIPs
Das Erste, was die Teams merken sollten, ist eine Erhöhung der durchschnittlichen Durchlaufzeit. Natürlich greift das Gesetz von Little eigentlich erst, wenn das System sich wieder stabilisiert hat, aber wenn man annimmt, dass zwei stabile Zustände existieren (vor und nach der Erhöhung des WIPs), zeichnet sich zumindest ein Trend ab: Die Durchlaufzeit steigt.
Darüber hinaus sinkt die Vorhersagbarkeit. Das klingt vielleicht erst einmal unintutiv, aber wenn mehr Dinge parallel in einem System bearbeitet werden, die in unterschiedliche Blockaden, Bearbeitungs- und Wartezeiten laufen können, ohne dass sich zeitnah darum gekümmert wird, so steigt die Streuung der Durchlaufzeiten. Fokus auf wenige Dinge ermöglicht es, sich dediziert um diese Dinge zu kümmern und Probleme im Fluss der Arbeit gezielt anzugehen.
Apropos Fokus: Werden Arbeitseinheiten thematisch miteinander gruppiert, steigt der Fokus in fachlichen und technischen Aspekten. Bearbeiten wir verschiedene Dinge, steigt auch die Wahrscheinlichkeit, dass sich diese Gruppierungen vermengen – es sind einfach viele Dinge parallel. Das bedeutet, dass einige Mitarbeiter an einem Themenblock arbeiten, während andere einen zweiten Block bearbeiten. Das wiederum bedeutet erhöhte Koordination bei der Integration, und das Risiko, dass man sich gegenseitig auf die Füsse tritt. Ist der Fokus enger, sinkt dieses Risiko!
Eine breite Streuung in längere Durchlaufzeiten bedeuten gegebenenfalls auch, dass die Erwartung, die die Kunden an den gegebenen Dienst haben, verletzt werden. Häufig spricht man von Service Level Agreements (wenn diese vertraglich festgelegt wurden) oder der Service Level Expectation (SLE, wenn es nur eine gewisse vereinbarte Erwartung gibt). Wird die SLE verletzt, sinkt das Vertrauen in den bereitgestellten Dienst und der Kunde ist häufig geneigt, "enger zu steuern". Gerade gegenüber Dienstleistern ausserhalb des eigenen Unternehmens sieht man das beschriebene Verhalten häufig, weil diese entweder keine Versprechungen machen oder diese konstant brechen.
Zusammengefasst bedeutet das Heraufsetzen von WIP-Limits in vielen Fällen, dass der Kundennutzen sinkt:
* Längere Durchlaufzeiten,
* geringere Verlässlichkeit und
* höhere Risiken bei der Integration.
Sind die alten Limits schlecht?
Ich stelle in den Momenten, in denen über eine Erhöhung der Limits nachgedacht wird, als erstes eine Frage: Was hindert Euch daran, das vorherige WIP-Limit zu respektieren? In vielen Fällen wurde das WIP-Limit ja gewählt, um genau die beschriebenen Effekte zu korrigieren. Natürlich sind Blockaden hinderlich und es ist wirtschaftlich nicht immer sinnvoll, wenn Mitarbeiter "herumsitzen", aber vor dem Hintergrund des Kundennutzens sind manche Effizienzfragen einfach nachrangig.
Es geht auch anders!
Ich empfehle den Betreibern des Kanban-Systems dann zwei Dinge. Erstens, über die Blockaden zu reflektieren, denn sie sollten nicht generell einfach hingenommen werden. Sind Mitarbeiter durch Blockaden unterlastet, sollten sie sich Gedanken darüber machen - und von ihren Führungskräften dabei unterstützt werden - welche wirtschaftlichen Auswirkungen die Blockaden haben: Was bedeutet es an Verzögerungskosten, dass die aktuelle Aufgabe liegenbleibt? Wie lange kann man es sich leisten, sie liegen zu lassen? Welche Investition ist notwendig, um die Aufgabe weiterzubringen und ggf. sogar die Blockadeursache nicht wieder auftreten zu lassen? Wie können wir Abhängigkeiten unterstützen oder beschleunigen oder sogar beheben? In vielen Fällen ist es so, dass man Probleme am richtigen Ort, wirtschaftlich begründet mit ihrem Kontext vortragen muss, um zu einer schnellen Lösung zu kommen.
Falls sich wenig oder gar nichts gegen die Blockaden und Abhängigkeiten tun lässt empfehle ich variable WIP-Limits. Ein Beispiel: Im Normalfall ist das Limit 5 Arbeitseinheiten in einer bestimmten Aktivität. Im Fall, dass viele Blockaden zueinanderkommen, darf die Menge paralleler Arbeit auf 7 steigen, aber nur kurzfristig. Es sollte schnell wieder auf 5 absacken. Kommt man in die Verlegenheit, auch die Beschränkung auf sieben überschreiten zu wollen, wird automatisch ein Kaizen-Event ausgelöst: Ein Krisenmeeting, um die aktuelle Situation zu analysieren und sofort Gegenmaßnahmen (möglichst auch durch eine Veränderung des Arbeitssystems und nicht nur eine Hochpriorisierung an anderer Stelle) zu treffen. Achtung: Die wirtschaftlichen Auswirkungen der Blockaden müssen klar sein. Ein "uns geht es damit nicht gut" reicht nicht, damit sich etwas bewegt!
Fazit
Diese beiden Vorgehensweisen helfen, weil gezielt über die entstandenen Probleme reflektiert wird, statt die Unzuverlässigkeit des Arbeitssystems hinzunehmen. Bei der einen wird direkt darüber reflektiert, die andere gibt uns die Chance, gewisse Schwankungen auszuhalten und nur in schlimmeren Fällen aktiv zu werden. Dieser Puffer geht natürlich auch zu Kosten der SLEs, der Vorhersagbarkeit und der Geschwindigkeit.
Die Reflexion über die aktuelle Situation ist anspruchsvoll: Man muss über Verzögerungskosten nachdenken, diese gegen andere Optionen abwägen. Man muss überlegen, wie das Kanban-System umgestaltet werden muss, damit ein neuer Zustand besser dargestellt wird oder neue Verhaltensregeln durch das System unterstützt werden können. Ich helfe Dir dabei gerne. Ruf mich doch einfach an.