Das Thema dieser Folge habe ich in der letzten Folge schon angekündigt: Push- und Pull-Systeme.
Die Namen von Push-Systemen und Pull-Systemen sind sich sehr ähnlich. Das ist manchmal verwirrend. Ich muss manchmal selbst darüber nachdenken, welches ich nun meine und mich auch manchmal korrigieren. Also schön konzentriert bleiben!
Keine Lust auf Lesen? Dann höre dir doch den Podcast an:
Die Beiden haben auch noch gewisse Konnotationen, über die wir mal kurz sprechen sollten.
Push wird im Allgemeinen als das böse Konzept, Pull als das gute Konzept angesehen. Auch wenn ich großer Anhänger von Pull-Systemen bin, ist das völliger Quatsch.
Push hat häufig den Klang eines direktiven Managers, der vielleicht sogar im Micromanagement-Stil seinen Mitarbeitenden Aufgaben hineindrückt – obwohl sie gar nicht mehr bearbeiten können.
Oder mit Push wird der sprichwörtliche Wurf über den Zaun verknüpft und dabei ist uns dann egal, wie der Empfänger damit umgehen kann.
Oder, und das finde ich persönlich ziemlichen Quatsch, Push ist etwas, wo der Mitarbeitende sich nicht die Aufgabe aussuchen darf, während er oder sie das bei Pull angeblich tun dürfte.
Im Englischen gibt es eine schöne Redewendung für das, was jetzt kommt: "I have to pop your bubble", denn auch Pull bedeutet keinen Freifahrtschein für ein Cherrypicking.
Pull hat trotzdem insgesamt einen sehr positiven Beiklang: Selbst- statt Fremdstimmung und so weiter. Dass sich das erst einmal nur auf die Kapazität begrenzt, sehen wir uns gleich an.
Jetzt haben wir uns die reininterpretierten Charakteristika angeschaut, sehen wir uns doch mal an, wie die beiden Systeme wirklich funktionieren.
Wir fangen mit dem Push-System an. In einem Push-System erstellen wir eine Vorplanung. Wir ermitteln Kapazitäten aller Stationen in unserem Wertstrom und schätzen für alle Aufträge ab, wie viel Aufwand sie für die einzelnen Stationen bedeuten. Wir müssen also vorher wissen, welche Aufträge wir bearbeiten wollen und müssen sie verstanden und geschätzt haben. Eigentlich bräuchten wir auch noch die Bearbeitungszeit, aber dazu kommen wir gleich noch mal.
Gehen wir erst einmal von einer idealen Welt aus. Wir haben also Aufwände und Kapazitäten. Die legen wir übereinander und überlegen uns einen sinnvollen Ablaufplan für die Aufgaben.
Ein Problem ist jetzt, dass wir Störungen, unvorhergesehene Abhängigkeiten und Schwankungen nicht so richtig mit einplanen können. Wäre schön, wenn wir schon vorher wüssten, was schiefgehen wird, dann könnten wir das ja sofort angehen. Gewisse Risiken können wir adressieren, aber wir können halt nicht alles vorhersehen. Wir planen also zeitliche Puffer ein.
Wenn eine Aufgabe beendet wurde und der richtige Zeitpunkt gekommen ist, wird sie zur nächsten Station gegeben zur Bearbeitung. Laut Plan sollte die zu diesem Zeitpunkt ja die Kapazität haben, um die Aufgabe zu bearbeiten.
Ich habe eben gesagt, dass wir eigentlich auch die Bearbeitungszeit und nicht nur den Aufwand brauchen. Menschen, die nur mit dem Aufwand planen, sind in meinen Augen schon echt draufgängerisch.
Denn die Bearbeitungszeit ist auch maßgeblich davon abhängig, wie viele Dinge parallel bearbeitet werden! Falls du mal ein anschauliches Beispiel dafür haben möchtest: Miss mal die Zeit, die du für's Zähneputzen benötigst.
Einmal wenn du es fokussiert putzt und einmal, während du dabei vielleicht den Spiegel im Bad putzt. Der konkurrierende Zugriff auf die geteilten Ressource Hand und Hirn verlängert die Bearbeitungszeiten von beiden Aufgaben. Bei etwa gleichem Aufwand!
Gut. Jetzt haben wir das Push-System mit seinen Abschätzungen und der Vorausplanung. Sehen wir uns nun das Pull-System an.
In einem Pull-System werden Aufgaben nur dann ins System und von einer Station zur nächsten bewegt, wenn diese Kapazität signalisieren – mit einem sogenannten Pull-Signal. Ich habe in einer früheren Folge schon den Friseur erwähnt, der nach Beendigung des ersten Auftrag dem nächsten Kunden zuruft, dass er dran ist – so einfach ist ein Pull-System! Bei mehreren Stationen sieht das dann so aus, dass sich die Aufgaben durch den Wertstrom bewegen. In die entgegengesetzte Richtung fließen die Pull-Signale. Dadurch werden Ausgang und Eingang gekoppelt und wir bekommen eine Aussage, wann Kapazität für einen weiteren Auftrag da ist.
Um mit Schwankungen umgehen zu können, können wir auch hier Puffer verwenden: Wir messen dann an den einzelnen Stationen und im gesamten System, wie viele Aufträge maximal und minimal durchgeschleust werden können und richten dann Puffer ein, um diese Maxima abdecken zu können.
Das Schöne am Pull-System ist: Wir müssen gar nicht so viel vorausplanen! Wir können uns die Reihenfolge überlegen, in der Aufträge in das System kommen sollen und dann bei einem Pull-Signal den nächsten Auftrag reingeben.
Darüberhinaus sollten wir ein paar Messungen durchführen - Durchsatz und Durchlaufzeiten nämlich. Dann rechnen wir einfach damit, dass sich das System so verhält, wie es das bis jetzt getan hat. Damit können wir dann Vorhersagen darüber treffen, wann etwas fertig sein wird.
Das Pull-System reagiert auch nicht so anfällig auf Störungen. Naja, eigentlich reagiert es genau wie ein Push-System, insofern, als dass die Störungen natürlich genauso auftreten und zu den gleichen Verzögerungen führen wie in einem Push-System. Aber wir müssen bei Pull nicht unsere gesamte Planung über den Haufen werfen und neu erstellen.
Das, ist so, weil in einem Pull-System die systeminhärenten Verzögerungen in den Messdaten mitgeführt werden. Wir haben also einen etwas vollständigeren Blick auf das System, als wenn wir nur mit Kapazität und Aufwand vorausplanen!
Jetzt, wo wir die beiden Systeme kennen: Wo ist denn nun welches angemessen? Ich würde ja in den meisten Fällen ein Pull-System empfehlen, weil es uns einfach bessere Informationen liefert und billiger zu betreiben ist. Aber in einer Umgebung mit sehr geringen Störungen könnte man vielleicht auch ein Push-System verwenden.
Pull-Systeme sind überaus hilfreich, wenn wir gewisse Schwankungen haben, die einem statistisch vorhersagbaren Verhalten unterliegen. Wir können ihr Eintreten zwar nicht ganz genau vorhersagen. Wir akzeptieren sie aber erst einmal, haben sie in unseren Messungen über die Systemgeschwindigkeit und können sie dann nach und nach adressieren und gegebenenfalls sogar ausräumen.
Wir haben ein paar Voraussetzungen. Die gelten aber sowohl für Push- als auch für Pull-Systeme.
Da ist zum einen ein einigermaßen stabiles System zu nennen.
Wenn wir ein wild mutierendes Arbeitssystem haben, können wir da zwar auch mit einem Pull-System aktives Management mit wenig Aufwand betreiben.
Die Messdaten werden uns normalerweise recht wenig sagen – außer, dass wir auf einem wildem Ochsen reiten!
Wenn du am Rand stehst und den Ochsen und dein Können abschätzt und dann versuchst genau vorherzusagen, wie lange du dich auf dem Ochsen hältst, dann hast du ein Äquivalent zur Push-Planung in diesem Fall.
Eine zweite Voraussetzung, hauptsächlich für Pull, ist ein grundlegendes Wissen über Statistik. Da scheuen viele Menschen etwas zurück, aber wenn man die Grundlagen mal drin hat, kann man gute, verlässliche Aussagen über Laufzeiten und so weiter treffen!
Die für mich wichtigste Konsequenz von Pull-System ist, dass wir in den meisten Fällen der Realität der Kapazitäten ins Auge blicken, statt sie uns über getunte Schätzungen schönzurechnen. Das Wunschdenken weicht also der Realität. Das honorieren die Kunden, denn wir werden vorhersagbarer!
Kommentar schreiben
Julie (Montag, 11 Mai 2020 20:23)
Hallo Florian,
ich verstehe folgendes aus dem Podcast nicht:
"Aber wir müssen bei Pull nicht unsere gesamte Planung über den Haufen werfen und neu erstellen. Das, ist so, weil in einem Pull-System die systeminhärenten Verzögerungen in den Messdaten mitgeführt werden." und
"Aber in einer Umgebung mit sehr geringen Störungen könnte man vielleicht auch ein Push-System verwenden."
Deine Erklärung scheint zu sagen, dass wir die Verzögerung durch (zyklische) Störungen bereits alle mit einrechnen und deshalb nicht neu planen müssen (oder zumindest nur am Schrittmacher Prozess), wenn mal was schief geht. Aber die Planungsabteilung in einem Push-System kennt im besten Fall ja auch die typischen Störungen bzw. die Verzögerungen in den einzelnen Prozessen und plant diese bereits ein (zwar nur als Durchschnittswert aus der Vergangenheit, aber im Pull sind es auch nur Vergangenheitswerte). Also dürfte ein Pull nicht besser bei störungsanfälligen Prozessen sein, als Push. Im Gegenteil, Push hat dann wenigstens die Puffer. Ja die sind teuer und groß, ok. Aber allein auf das Risiko bei Störungen bezogen (die vielleicht schneller entdeckt werden, ja. Und die mit mehr Druck gelöst werden müssen, ja) nicht vor vornherein/per se besser...
Oder habe ich da einen Denkfehler?
Ich würde mich über einen Austausch dazu freuen :-) Viele Grüße, Julie (KVP-Team in Berlin)