CONWIP und Puffer

CONWIP-Limits sind einfach, halten aber auch Überraschungen für uns bereit. Ein Leser schrieb mir neulich eine Frage: Sein Limit erzeugte eine Art "Schwingung im System", weil er einen Puffer mit integriert hatte. Als Konsequenz wurden die Stakeholder unzufrieden, weil die Mitarbeiter trotz offensichtlicher Kapazität nicht arbeiteten.

 

Neulich schrieb mir jemand: „CONWIP gut und schön, es ist erst einmal hilfreich – es nimmt ein wenig den Druck.“

Direkt danach fragte er aber nach diesem nicht untypischen Verhalten: „Aber was ist eigentlich, wenn sich die Tickets bis zum CONWIP-Limit in einem Puffer ‚Warten auf Freischaltung‘ sammeln? Dann läuft die Bearbeitung leer, obwohl Kapazität da ist.“

Ein CONWIP, ein konstantes Work-in-Progress, ist ein überspannendes Limit. Dabei werden mehrere Aktivitäten oder Wartezustände gemeinsam limitiert. Wichtig ist nur, dass nicht mehr Arbeit im System ist. Ihr Zustand ist dabei nicht relevant.

 

Der Fragende beschreibt nun eine Situation, in der ein Wartepuffer in einem solchen CONWIP integriert wurde. Das ist kein größeres Problem, wenn der Puffer nicht am Ende der Limitierung steht oder die Wartezeit relativ gering ist. Im gegebenen Fall steht der Puffer aber direkt vor einer nicht sofort verfügbaren Ressource: Der Freischaltung auf ein Live-System. Diese Ressourcen heißen auf Englisch non instant availability Resources: NIA-Ressourcen. 

Der Puffer wurde geschaffen, um diese NIA-Ressource vor Unterlastung zu schützen. Sonst begrenzt sie eventuell den Durchsatz des Systems künstlich.

 

Leerlauf und künstliche Engpässe

Kritisch ist die Integration des Puffers in das CONWIP, weil sich die fertig gestellte aber noch nicht freigeschaltete Arbeit in diesem Puffer sammelt. Das CONWIP ist erschöpft und es kann keine neue Arbeit ins Arbeitssystem gezogen werden. Die Mitarbeiter laufen leer, obwohl sie Kapazität haben und die NIA-Ressource eventuell sogar noch mehr schaffen könnte. Das ist wirtschaftlich unrentabel.

Stakeholder sehen das und fragen nach, ob denn das Arbeitssystem nicht noch weitere Tickets akzeptieren kann. Das ist berechtigt, so lange die gepufferte Ressource noch nicht an ihrer Kapazitätsgrenze angekommen ist. Es ist ja offensichtlich noch Kapazität vorhanden!

Es ist übrigens keine Lösung, jetzt pauschal das CONWIP zu erhöhen. Der Effekt ist im Regelfall, dass dann zu viele Dinge parallel bearbeitet werden. Und das Gesetz von Little gilt eben auch für Teilsysteme: Die Durchlaufzeiten der Bearbeitung werden steigen.

Die Lösung dieses Problems muss stattdessen auf zwei Ebenen geschehen: den WIP-Limits und dem Gesamtfluss.

 

Aufteilung des Limits

Das systemüberspannende CONWIP wird aufgeteilt in mindestens zwei einzelne WIP-Limits: Für die Aktivitäten und eins für den Puffer. Das Aktivitäten-Limit wird typischerweise entsprechend den Mitarbeitern, Abhängigkeiten und Risiken gewählt. Der Wartepuffer wird so groß wie nötig, so klein wie möglich gewählt. Er muss die Menge Arbeit aufnehmen können, die die NIA-Ressource in einem Arbeitszyklus abarbeiten kann. So wird sie zumindest nicht zu einem künstlichen Engpass.

Als Konsequenz kann das Arbeitssystem neue Tickets akzeptieren, so lange die Kapazitäten der NIA-Ressource oder der Mitarbeiter im Aktivitätsteil des Systems nicht erschöpft sind. Erst wenn eines von beiden erreicht ist, erfolgt kein Signal mehr, dass weitere Arbeit akzeptiert werden kann. Das WIP-Limit im vorderen Teil schützt die Aktivitäten vor Überlastung, im Puffer schützt es die NIA-Ressource. Durch die Aufspaltung wird die Eingangsrate besser, also glatter an die Kapazitätsgrenzen der einzelnen Teile angepasst. Der Flow wird direkt verbessert.

 

Reflexion über den Flow

Die zweite Ebene betrifft den Gesamtfluss. Wir reflektieren über den Flow und die damit verbundenen Kosten. Lange Durchlaufzeiten bedeuten fast immer höhere Risiken bezüglich eines Abbruchs des Tickets, Abhängigkeiten untereinander, Integration und Kompatibilität untereinander. Also müssen wir uns ansehen, was es kostet, die NIA-Ressource zu verändern. Wir könnten beispielsweise die Frequenz der Freischaltung erhöhen: Verdoppeln, vervierfachen oder komplett zu kontinuierlicher Lieferung wechseln. Dann kann das WIP im Puffer vorher gesenkt oder komplett eliminiert werden.

Wir könnten aber auch durch verschiedene Risikoprofile den Engpass umgehen. Vielleicht benötigen nicht alle Tickets eine explizite Freischaltung? Es lohnt sich, die Arbeit genauer anzusehen.

 

Wirtschaftlich agieren

Wir können durch eine sinnvolle Selektion vor dem Commitment-Punkt den Wert steigern, den die Bearbeitung der Tickets schafft. Wir können weitere wirtschaftliche Verbesserung erreichen, wenn wir uns auch über die Kosten Gedanken machen. In diesem Fall sind es die Transaktionskosten pro Freischaltung und Verzögerungskosten der einzelnen Tickets – entgangener Wert. Um häufiger freizuschalten, müssen die Kosten pro Freischaltung gesenkt werden. Dann können wir häufiger freischalten, besseren Flow der Arbeit erzielen und bekommen weniger Wartezeiten. Insgesamt sollten dann die Verzögerungskosten der einzelnen Tickets sinken. Wertgenerierung durch Kostensenkung – wer hätte das gedacht? Um fair zu bleiben: Um die Kosten pro Transaktion senken zu können, sind häufig massive Investitionen notwendig. Die müssen wir im Auge behalten.