Replenishment (Just in Time-Delivery)

Bild: Flickr / Lyza Danger - CC BY-SA 2.0

Für viele Kanban-Anwender in der IT oder anderen Bereichen der Wissensarbeit ist es in Vergessenheit geraten, aber dieses Framework hat ursprünglich einen sehr handfesten Hintergrund. In den ersten Jahrzehnten seiner Existenz wurden nicht Kreativarbeit oder Dienstleistungen damit gesteuert sondern Fabrikarbeit. Ein besonderer Aspekt war dabei die Organisation von Materialnachschub über so genannte Replenishments. Da es die in der Wissensarbeit auch gibt lohnt ein näherer Blick.

Die Grundidee der Kanban-Replenishments ist die Lieferung möglichst genau zum benötigten Zeitpunkt, also weder zu früh noch zu spät. Da das durch zentrale Steuerung kaum machbar wäre (alleine das dafür nötige Detail-Reporting wäre immens) erfolgt die Koordination dezentral. Wann immer der Vorat eines Werkstoffs eine Mindestmenge unterschreitet wird eine gemeinsam mit diesem Werkstoff aufbewahrte Kanban-Karte entnommen und an denjenigen weitergegeben der für die Bestellung zuständig ist. Da die Mindestmenge auf Verbrauch und Lieferzeit abgestimmt ist erfolgt die Lieferung kurz bevor der Vorrat erschöpft ist.

Der Vorteil dieser so genannten Just in Time Delivery: die Lagerhaltung wird deutlich verringert. Statt vorsichthalber grössere Mengen vorhalten zu müssen ist möglich, dass nur relativ kleine Vorräte angelegt werden. Die mit Lagerhaltungen verbundenen Nachteile (Totes Kapital, benötigte und instandzuhaltende Räumlichkeiten, Veraltung und Beschädigung der Waren, etc.) werden so minimiert. Die im Vergleich zu Europa und Amerika zeitweise erheblich billigere Produktion in Japan ist so zu erklären. Soviel zur Hardware. Aber ist das auch in der Wissensarbeit umsetzbar?

Es ist umsetzbar, wenn auch mit anderen Objekten. Werkstoffe werden in den IT- und Dienstleistungsbrachen praktisch nie zugeliefert, dafür kommt aber etwas anderes in ununterbrochener Regelmässigkeit nach: Anforderungen. Auch bei denen treten negative Effekte auf wenn sie in zu grosser Zahl gleichzeitig eintreffen - sie brauchen länger bis zur Umsetzung, veralten, ihr Kontext ändert sich, Schnittstellen ändern sich, und so weiter. Auch hier kann eine Just in Time Delivery daher Mehrwert stiften.

Natürlich ändert das die Art wie Anforderungen geschrieben werden müssen. Statt möglichst alles zu Beginn auszuspezifizieren muss jetzt mit den Detail-Beschreibungen so lange wie möglich gewartet werden, damit diese Arbeit nicht zu früh fertig wird. Das hat Auswirkungen auf die Organisation: statt einer vorgelagerten Phase ist das Erheben der Anforderungen jetzt ein parallel zur Umsetzung verlaufender Prozess. Und damit trotz allem zielgerichtet gearbeitet wird braucht es Dinge die leider nur wenige Unternehmen haben: eine Produktvision und fachliche Zwischen- bzw. Sprintziele.

Viele Organisationen scheuen diese Umstellung und gehen den scheinbar leichten Weg - vor dem Kanban-System befindet sich ein Backlog mit möglichst vielen, möglichst früh geschriebenen, möglichst detaillierten Anforderungen. Den dafür Verantwortlichen sei ein Besuch in der nächsten nach Kanban arbeitenden Fabrik empfohlen, um dort zu erfahren wie diese Arbeitsweise eigentlich gedacht ist.