Toen Mr Taiichi Ohno, architect van het Toyota Production System, stelde dat we niet langer grote hoeveelheden voorraden moesten produceren en die maar moesten zien te verkopen (push), maar ons bewust moesten zijn van de marktvraag (pull), betekende dat een grote omslag in ons denken. Inmiddels zijn push en pull twee van de meest gebruikte termen in SCM. Op zich nog niets aan de hand. Wat mij echter verontrust is dat iedereen een andere uitleg geeft van push en pull. De ogenschijnlijke logische woorden van Mr Ohno zijn klaarblijkelijk niet eenduidig.
Een paar voorbeelden van uiteenlopende scholen:
Pull is kanban en push is MRP?
Pull werd al snel geassocieerd met haar eerste verschijningsvorm, kanban. Tegelijkertijd, werd push bijna synoniem met MRP. Kanban of pull production werd zelfs zo sterk het kenmerk van TPS, dat velen meenden dat ze synoniem waren, ondanks dat kanban slechts een middel was en geen doel.
Pull is make-to-order en push is make-to-stock?
De oorspronkelijke woorden van Mr Ohno zijn later meer dan eens vrij vertaald:
- Pull in simplest terms means that no one upstream should produce a good or service until the customer downstream asks for it, … (Womack & Jones, 2007)
- Pull production is the opposite of push. It means products are made only when the customer has requested or pulled it, and not before (The Boeing Company, 2002)
Logisch dat push en pull inmiddels ruimhartig worden gebruikt als synoniemen voor respectievelijk make-to-stock en make-to-order. Ons klantorderontkoppelpunt staat in het Engels zelfs bekend als push/pull point. Volgens deze definities zou een ‘make-to-order MRP-systeem’ overigens een ideaal pull systeem zijn. De vraag echter is of Mr Ohno dit ook zo heeft bedoeld.
Pull is observe & respond en push is plan & execute?
Volgens een andere school (Toshiki Naruse (2003) en De Toni, Caputo en Vinelli (1988)) is het onderscheid tussen push en pull gebaseerd op wat de verwerving van parts of de productiestart initieert. Push als deze wordt geinitieerd door planning (plan & execute); pull als deze plaatsvindt als reactie op de actuele situatie (observe&respond).
Pull limits the amount of work in process; push not?
Hop en Spearman (2003) definiëren een pull productiesysteem als een systeem dat expliciet de hoeveelheid work in process (WIP) beperkt; dit in tegenstelling tot een push productiesysteem. Het goede nieuws is dat volgens hun definitie pull op verschillende wijzen kan worden geïmplementeerd. Kanban is een manier om WIP te beperken, maar er zijn er meer, waaronder CONWIP, POLCA, maar ook MRP met een WIP-beperking.
Onbesliste strijd
Pull gedefinieerd als ‘klantvraag volgend’ is gevoelsmatig superieur aan push. Ik verdenk de pleitbezorgers van Lean dan ook wel eens slim gebruik te hebben gemaakt van deze emotie door consequent kanban te afficheren als het ‘verstandige pull’ en MRP als ‘domme push’. Mijns inziens nauwelijks terecht. MRP kan namelijk met evenveel liefde worden beschreven als ‘klantvraag volgend’ en dus als pull. Uitgangspunt van MRP is immers dat je pas produceert als er een op basis van onafhankelijke vraag berekende behoefte is.
Bovendien is het de vraag of het wel zo verstandig is de klantvraag te volgen. Uitzonderingen daargelaten is de klantvraag immers variabel; soms wat meer, dan weer wat minder. En wil je deze variabiliteit één op één volgen dan trekt dat zeer mogelijk een grote wissel op je capaciteit, materiaalbeschikbaarheid en doorlooptijd. Zeker als de klant je vraagt snel te leveren. Tel uit je winst.
Je hoeft Mr Ohno natuurlijk niet te vertellen dat het beter is de vraag niet één op één te volgen, maar de vraagvariabiliteit te levelen met voorraad en/of levertijd. Bij drukte put je uit capaciteitsvoorraad, en als het rustig is vul je de capaciteitsvoorraad weer aan. Klinkt behoorlijk push. Toch?
Tot slot staat buiten kijf dat observe & respond in principe de voorkeur geniet boven plan & schedule en systemen die WIP controleren veel betrouwbaarder en beheersbaarder zijn dan systemen die throughput controleren. Maar waarom zou je een systeem gebaseerd op observe & respond of een die WIP beperkt, een pull systeem moeten noemen? Mij een raadsel.
Stop de verwarring
Bent u er nog? In mijn ogen zaaien de termen push en pull slechts verwarring. Mogelijk met opzet veroorzaakt door Mr Ohno die ons naar verluidt op het verkeerde been probeerde te zetten door een schijnbaar logische maar halve waarheid te schetsen over het geheim van zijn succes.
Ik stel dan ook voor de termen push en pull niet langer te gebruiken, anders dan voor de Engelse vertaling van duwen en trekken. Zeg gewoon wat u bedoelt: kanban of MRP, voorraad- of ordergestuurd, observe & respond of plan & schedule, zelfs forward of backward scheduling.
Tot slot raad ik u aan u nog eens te verdiepen in het belang van beheersing van uw WIP. Want daar, zo wist Mr Ohno al veel langer, schuilt het werkelijke geheim van beheersing van uw supply chain. Of u dat beter kunt doen met Kanban, CONWIP, POLCA of een andere variant, is afhankelijk van uw situatie. En daar is geen woord push of pull bij.
