Mir wurde neulich folgende Aussage vorgetragen und ich wurde nach meiner Meinung dazu gefragt.
Die Fragende hatte sich schon etwas mit der Kanban-Methode beschäftigt und sie hatte auch ein Kanban-Board mit WIP-Limits bei sich im Unternehmen hängen. So richtig kamen sie aber noch nicht mit den WIP-Limits zurecht, sie wurden immer als störend und wenig hilfreich empfunden.
Während der Einführung war ihnen von den beiden Trainern empfohlen worden, die Arbeit zuerst am Engpass zu limitieren. Sie fragte mich, was ich davon halte.
Warum wir limitieren
Rekapitulieren wir doch einmal kurz, weshalb wir die Menge paralleler Arbeit limitieren. Ich glaube, es war Dan Vacanti, der mal getwittert hat, dass er eigentlich lieber sagen würde, dass wir WIP optimieren statt die Menge zu limitieren. Ich stimme damit völlig überein.
Wieso also die Menge an Arbeit in den einzelnen Schritten optimieren?
- Wir wollen die Menge an Arbeit, die sich parallel in einem Bearbeitungs- oder Wartezustand befindet, an die Kapazität des Zustands anpassen. Nicht zu wenig, nicht zu viel – optimiert eben. Das bedeutet, die Menge an Arbeit sollte den Arbeitsschritt und die Menschen, die ihn erbringen, nicht überlasten. Sie sollten aber auch nicht in den Bore-Out getrieben werden. Das ist natürlich u.a. abhängig von der Anzahl der Menschen, die bearbeiten, den Abhängigkeiten, Wartezeiten und der Dauer der Bearbeitung.
- Wir möchten ein Warnsignal bekommen, falls Situationen auftreten, in denen mehr bearbeitet werden soll, als die Kapazität vorsieht. Ein solches Warnsignal kann beispielsweise ein Rückstau in den vorherigen Arbeitsschritt sein. Oder es ist ein einfaches "Rotfärben" der Spalte, wie die meisten elektronischen Werkzeuge das tun. Solche Situationen können dadurch ausgelöst werden, dass
- ein Problem mit einem bestimmten Auftrag auftritt, beispielsweise ein Qualitätsproblem
- eine unvorhergesehene Abhängigkeit auftritt, die uns zum Warten bringt
- ein externer Eingriff ins System auftritt, zum Beispiel jemand, der die Priorität des eigenen Auftrags hochsetzt und ihn durch das Arbeitssystem drücken will
- Wir möchten den Flow optimieren, so dass Arbeit leicht aus einem Schritt in einen nachfolgenden fließen kann. Durch die Limits wird das gesamte System gut getaktet ist und der Durchsatz der einzelnen Schritte mit passender Parallelisierung gut aufeinander abgestimmt.
Sehen wir uns doch mal diese Zeichnung an:
Bei Schritt D tritt ein Engpass auf. Wir haben hier einen Durchsatz von vier Aufträgen pro Tag, während B und C durchschnittlich 5 Aufträge pro Tag bearbeiten können. A ist die Eingangsspalte, also ein Puffer, damit das System nicht leerläuft. E und F sind jetzt erst mal nicht so relevant, sie schaffen aber 6 und 5 Aufträge pro Tag.
Am Engpass limitieren bedeutet Überlauf
Die Empfehlung war nun, zuerst am Engpass zu limitieren. Das ist erst einmal keine schlechte Empfehlung, denn B und C sorgen dafür, dass pro Tag ein Auftrag mehr bei D ankommt als dieser Arbeitsschritt bearbeiten kann.
Stell dir den Stress vor, der auftritt, wenn sich vor dir ein riesiger Berg auftürmt, den du nie abarbeiten können wirst. Deine Kollegen nehmen keine Rücksicht und du arbeitest am Engpass! Ein Auftrag pro Tag kommt durchschnittlich auf den Berg drauf. Wenn wir reine Arbeitstage rechnen, sind am Ende des Monats 20 Tickets, am Ende des Jahres schon ~210! Und da arbeitest du schon an der Kapazitätsgrenze.
Limitieren wir diesen Arbeitsschritt aber beispielsweise mal auf 6 Tickets parallel. Sechs, denn wir möchten auch die Schwankungen, die im Arbeitsablauf von D auftreten können abfedern können. Ein Ticket wird also nur dann zu D geschoben, wenn weniger als sechs Tickets in der Spalte sind. Wir haben D damit zuverlässig vor Überlastung geschützt – insofern war es eine gute Empfehlung.
B und C bearbeiten aber weiterhin durchschnittlich 5 Aufträge pro Tag. Der Berg wächst also trotzdem, aber woanders – nämlich wahrscheinlich in der Spalte des Arbeitsschrittes C. Unser System vor dem Engpass sammelt also weiterhin fleißig unfertige Aufträge. Die Aufträge warten darauf, dass sie in Schritt D bearbeitet werden. Diese Wartezeit zählt auf die Durchlaufzeit ein – die Zeit zwischen dem Annehmen des Auftrags und seiner Fertigstellung. Aus dieser Sicht ist die Limitierung des WIPs am Engpass also unnötiger Quatsch! Wir müssten vielmehr die Menge an Arbeit optimieren, die in das System geht.
Die Antwort: Gesamtsystem limitieren!
Das können wir dadurch bewerkstelligen, dass wir WIP-Limits vom Engpass aus nach vorne ziehen: Jede einzelne Spalte bekommt ein Limit. Damit bekommen wir gleich den Warnmechanismus, von dem ich weiter oben geschrieben habe. Win-Win! Wir bekommen also nun den Schutz des Engpasses vor Überlastung in den Griff wie auch die Überlastung des Gesamtsystems und die damit verbundene Verlängerung der Durchlaufzeit.
Ich habe vorhin gesagt, dass der durchschnittliche Durchsatz von E und F nicht so relevant ist. Das kommt daher, dass der Engpass ja bei D sitzt. Die Menge von Arbeit, die bei E und F ankommt ist also geringer als der mögliche Durchsatz – da müssen wir uns also keine Sorgen machen.
Allerdings sind wir in der Dienstleistung und insbesondere in der Wissensarbeit anfällig für Engpässe. Die können bei uns stärker wandern als das in der Produktion der Fall ist! Wenn also in diesem Moment ein Engpass bei D liegt, kann er vielleicht nächste Woche schon bei E liegen. Haben wir unser System hinter D nicht mehr limitiert, fluten wir den nächsten Engpass! Stattdessen wollen wir unser Pull-System mit den Limits also über den gesamten Arbeitsablauf ausstrecken: Bitte alles komplett limitieren! Damit schützen wir das Gesamtsystem vor Überlastung, vor Variabilität des Engpasses, installieren unser Warnsystem für aussergewöhnliche Situationen und können auch noch den gesamten Durchsatz in einen passenden Takt setzen. So much win!
Pull-Systeme FTW!
Wichtig ist für diesen Schutz eigentlich, dass wir ein Pull-System installieren: Ein System, in dem Aufträge nur dann weitergegeben werden, wenn signalisiert wurde, dass Kapazität verfügbar ist. Das ist das sogenannte Pull-Signal.
Es existieren zwar Pull-Systeme ohne WIP-Limitierung. Aber jedes Arbeitssystem, in dem der Menge an Arbeit eine obere Grenze gesetzt wurde, ist ein Pull-System. Ein Pull-System ohne diese Limits ist meiner Erfahrung nach schwer zu regeln und bricht irgendwann zusammen. Da ist es viel leichter, obere Limits zu setzen.
Ein WIP-limitiertes Arbeitssystem ist also Pull-System und das ist der Grund, warum vielen die WIP-Limitierung auch so schwer fällt. Die WIP-Limits schützen das System zuverlässigvor Überlastung. Aufträge, die die Kapazität überschreiten, werden also am Eingang abgewiesen oder müssen andere ersetzen. Schade Schokolade! Da tritt wieder der positive Effekt des Pull-Systems ein: Es weist uns auf eine ungewöhnliche Situation mit Handlungsbedarf hin. Wir müssen hier also eine Entscheidung treffen. Und die ist nicht immer leicht. Sie ist aber viel hilfreicher als nur den Engpass vor direkt wahrnehmbarer Überlastung zu schützen.
Was sind deine triftigsten Gründe, warum du noch kein limitiertes System hast? Oder welche Probleme treten typischerweise bei dir auf? Limitiert Ihr nur am Engpass oder darüber hinaus? Ich freue mich über deinen Kommentar!
Kommentar schreiben