0 0 Votes
Artikel-Rating

Heute geht’s in unserer kleinen Blogserie über Kanban um Praktik Nummer 3: “Miss und steuere den Fluss!” Wie man mit Kanban den Workflow messen und steuern kann, darüber wurden ganze Bücher gefüllt. Hier möchte ich Dir einen ersten Einstieg ins Thema geben und Dir ein paar Grundkonzepte vorstellen.

Den Kanban Workflow messen

Wenn Du Kanban nutzen möchtest, musst Du messen, wie lange Arbeit (also Aufgaben, Tickets etc.) benötigt, bis sie fertig ist. Dazu gibt es verschiedene Metriken und Möglichkeiten. Die beiden wichtigsten Messgrößen, um mit Kanban den Arbeitsfluss zu messen, sind Lead Time und Cycle Time.

Wir essen eine Pizza

Da wir große Fans des Pizza-Spiels sind, um die Mechanismen von Kanban zu verdeutlichen, hilft dieses Beispiel gut weiter, um auch Lead und Cycle Time zu verstehen. Stell Dir einfach vor, Du wärst Pizzabäcker und in Deiner Pizzeria befinden sich viele Gäste, die Du mit Essen versorgen möchtest. Natürlich möchtest Du das möglichst schnell tun, denn keiner Deiner Gäste wartet gerne lange auf sein Essen. Damit wären wir schon bei unserer ersten Messgröße:

Lead Time

Die sogenannte Lead Time ist die Zeit, die benötigt wird, um eine Aufgabe seit ihrem Bekanntwerden fertig zu stellen. In unserem Pizzeria-Beispiel ist Lead Time die Zeit von der Bestellung des Kunden bis zu dem Zeitpunkt, an dem er seine (hoffentlich heiße) Pizza vor sich auf dem Tisch hat.

Cycle Time

Die Cycle Time hingegen ist die Zeit, die wir vom Beginn bis zur Fertigstellung einer Aufgabe benötigen. Denn nur weil uns eine Aufgabe bekannt ist und wir wissen, dass wir sie erledigen müssen, heißt das ja nicht, dass wir auch direkt damit anfangen.

So gesehen tickt die Uhr der Lead Time sofort nach Bekanntwerden einer Aufgabe, während die Cycle-Time-Uhr noch stillsteht und erst dann startet, wenn wir mit dem ersten Arbeitsschritt beginnen.

Außerdem läuft die Messung der Cycle Time von Beginn bis zum Ende einer Aufgabe permanent weiter. Also auch dann, wenn wir die Aufgabe begonnen haben, sie aber zwischendurch unterbrechen, weil wir andere Dinge bzw. Aufgaben erledigen. Die Cycle Time ist also nicht die reine Bearbeitungszeit einer Aufgabe.

Wenn ein Kunde in unserer Pizzeria eine Bestellung aufgibt, beginnt die Lead Time zu laufen. Die Cycle Time wird erst ab dem Zeitpunkt gemessen, an dem wir mit der Zubereitung der Pizza beginnen. Sie läuft allerdings auch weiter, wenn wir das Backen dieser Pizza unterbrechen, weil wir beispielsweise eine Rotweinlieferung am Lieferanteneingang unserer Pizzeria entgegennehmen.

Das Cumulative Flow Diagram

Eng mit Kanban verbunden ist das sogenannte Cumulative Flow Diagram (oder kurz CFD). Das Cumulative Flow Diagram visualisiert, wie viele Aufgaben oder Tickets sich an einem bestimmten Tag in welchem Bearbeitungsstand befinden. Mit ein wenig Übung lassen sich Lead und Cycle Time leicht aus dem CFD ablesen.

Mit Kanban den Fluss messen - Lead Time & Cycle Time

In dem hier zu sehenden CFD kannst Du erkennen, dass es am 04.01.2020 insgesamt 20 Tickets gab. Erst am 14.01. sind insgesamt 20 Tickets geschlossen (orangene Linie). Das lässt zwar keine Rückschlüsse darauf zu, wie die exakte Lead Time für ein einzelnes Ticket ist, aber das betreffende Team weiß, dass es von dem Zeitpunkt, an dem eine neue Aufgabe bekannt wird, im Durchschnitt gute 10 Tage benötigt, bist diese fertig ist. Dadurch, dass dann später weniger neue Tickets hinzukommen, verringert sich die Lead Time. Den Stand vom 12.01.2020 erreicht das gleiche Team bereits am 16.01.2020. (Lead Time = 4 Tage)

Auch die durchschnittliche Cycle Time wird im CFD leicht sichtbar. Nur ziehen wir die horizontale Linie nicht von offen bis fertig, sondern von in Arbeit bis fertig (blaue Linie). Die Arbeit, die am 18.01. auf dem Tisch des Teams liegt, ist am 21.01. abgeschlossen. Die Cycle Time des Teams beträgt für diesen Zeitraum also 3 Tage. Du kannst außerdem sehen, dass dieses Team in diesem Zeitraum sehr viele Tickets gleichzeitig bearbeitet hat, denn der orangene Bereich auf dem Cumulative Flow Diagram wird immer breiter. Ein gutes Zeichen dafür, dass das WIP-Limit überschritten wurde.

Wenig später hat das Team sich darauf konzentriert, diese Aufgaben abzuarbeiten und keine neuen Aufgaben zu beginnen. Im Ergebnis hat sich die Cycle Time dadurch dramatisch verkürzt. Am 24.01.2020 beträgt die Cycle Time nur noch 1 Tag statt wie zuvor 3 Tage.

Die zwei simplen Weisheiten daraus sind:

  • Wenn Du die Lead Time (=Wartezeit für Deine Kunden) reduzieren willst, nimm nicht mehr Aufträge an, als Dein Kanban Workflow aktuell bewältigen kann.

  • Willst Du die Cycle Time Deines Kanban Workflows verringern, begrenze die Menge paralleler Arbeit durch ein WIP-Limit.

Mit Kanban den Workflow steuern

Nur zu messen, wie lange eine Aufgabe braucht, hilft natürlich nicht weiter. Aus den gemessenen Zeiten musst Du auch Rückschlüsse ziehen, was Du an Deinem Kanban Workflow verändern solltest, um die Zeiten zu verkürzen. Da Du vorher nicht immer genau absehen kannst, was genau passieren wird, musst Du experimentieren. Das heißt, Du misst etwa Lead und Cycle Time von bestimmten Tickets (oder Teams), führst eine Veränderung durch und misst die gleichen Werte erneut. Das erlaubt Dir dann Rückschlüsse. Wenn die Zeiten sich verbessern, behältst Du die Veränderung bei. Haben sie sich verschlechtert, machst Du sie wieder rückgängig oder führst weitere Anpassungen durch.

Ein beliebtes Modell, um den Fluss in Kanban zu steuern, ist die Engpasstheorie. (Zur Engpasstheorie gibt es eine Vielzahl von Business Büchern, Lehrgängen und Methoden, die darauf aufbauen. Ich möchte hier mit zwei Punkten nur einen kleinen Einblick geben, was Du generell mit der Engpasstheorie tun kannst.)

Die Engpasstheorie und Dein Kanban Workflow

Im besten Fall fließt die Arbeit in Form von Aufgaben oder Tickets von links nach rechts durch Deinen Arbeitsprozess – wie hier rechts zu sehen über beispielsweise vier verschiedene Stationen.

Das ist natürlich in den seltensten Fällen der Fall, denn an irgendeiner Stelle in diesem Fluss wird es eine Station geben, die nicht so schnell arbeiten kann, wie alle anderen Stationen. Dadurch entsteht der erwähnte Engpass in Deinem Kanban Workflow. Mit dem Ergebnis, dass sich vor dem Engpass die Arbeit staut und dahinter Leerlauf entsteht.

Den Engpass kannst Du durch eine gute Visualisierung sichtbar machen und auch nur dann, wenn Du Deinen Workflow so abgebildet hast, wie er gerade ist und nicht, wie Du ihn (irgendwann später) gerne hättest!

Der Engpass ist (meistens) nicht da, wo die Kollegen am lautesten schreien

Wenn wir einmal annehmen, dass Station 3 unser Engpass ist, dann wird sich die Arbeit nicht an dieser Stelle des Prozesses ansammeln, sondern an Station 1 und Station 2! Mit dem Ergebnis, dass die Kollegen, die dort arbeiten, darüber klagen werden, extrem viel zu tun zu haben. (Und eben nicht die Kollegen an Station 3.)

Du bist also gut beraten, Dir nachgelagerte Prozesse anzuschauen, wenn bestimmte Kollegen im Unternehmen über zu viel Arbeit klagen.

Wirklich sichtbar wird Dein Engpass natürlich nur dann, wenn Du Euren aktuellen Kanban Workflow auf einem Board abgebildet hast, Lead und Cycle Time misst und ein WIP-Limit anwendest. Ansonsten ist die Suche nach dem Engpass so effizient wie das Lesen im Kaffeesatz.

Arbeite nicht am Engpass, sondern sorge dafür, dass er ausgelastet ist

Einen der besten Tipps, den ich Dir geben kann: Beginne nicht als erstes damit, Deinen Engpass zu erweitern, damit irgendwie noch mehr Arbeit durch Deinen Kanban Workflow passt, sondern sorge zuerst dafür, dass Dein Engpass immer gut ausgelastet ist.

Ironischerweise führt die Erweiterung eines Engpasses dazu, dass ein neuer Engpass an einer anderen Stelle auftreten wird.

Wenn in einem Projekt ein bestimmtes Team den Engpass darstellt – zum Beispiel weil nur dieses Team die Arbeit erledigen kann – dann ist der häufigste Reflex, dort mehr Kollegen einzusetzen. Zum einen kann das gefährlich sein, da die Teamgröße gerade in agil arbeitenden Teams ein sensibler Faktor ist. (Mehr dazu kannst Du in meinem Artikel über die optimale Teamgröße erfahren.) Zum anderen führt das wie gesagt dazu, dass der Engpass an einer anderen Stelle auftritt. Die Engpasstheorie sagt nämlich auch, dass es immer einen Engpass im Workflow gibt. Schlimmstenfalls löst Du einen Engpass auf und kannst danach nicht herausfinden, an welche Stelle er sich nun verschoben hat.

Viel sinnvoller ist es hingegen, zunächst dafür zu sorgen, dass der erkannte Engpass immer gut ausgelastet ist und nicht mit anderen Dingen belästigt wird. Wenn also etwa ein Projektteam als Engpass erkannt wurde, dann solltest Du vor allem darauf achten, dass die Mitglieder dieses Teams nichts anderes machen, als an den Aufgaben des Projektes zu arbeiten. Das ist in der Regel nämlich ein extrem häufiger Fehler. Kollegen oder Teams, die noch nicht als Engpass erkannt wurden, werden mit Meetings, Workshops oder Kundenterminen zusätzlich belastet, wodurch ihre ohnehin schon knappe Zeit weiter eingeschränkt wird.