Follow up op artikel over onjuiste wachttijdberekeningen in de VSM

Enige tijd geleden publiceerde collega Thom Luijben (consultant & Master Black Belt) het artikel ‘Veel gezien: onjuiste wachttijdberekeningen in de VSM‘ over de verkeerde wachttijdberekening zoals hij die vaak in VSM’s tegen komt. Dit artikel werd ook in de Symbol nieuwsbrief geplaats. Op beide plaatsingen ontvingen we waardevolle reacties. In onderstaand artikel reflecteert Thom hierop. 

Allereerst mijn dank aan degenen die hebben gereageerd want dat helpt in de kennisverdieping van ons vakgebied. De kern van mijn artikel ging er over dat de wachttijd in een push-proces vaak verkeerd wordt berekend door de voorraad te vermenigvuldigen met de cyclustijd van het komende werkstation. Maar om tot een goede totale doorlooptijd te komen moet er met de cyclustijd van de bottleneck worden gerekend.

 

Van toepassing bij een volledig first-in-first-out (FIFO)

De meest voorkomende reactie was dat dit klopte maar wel als er volledig first-in-first-out (FIFO) wordt gewerkt. En dat dit in de praktijk bij de geïllustreerde lange wachttijden niet zal gebeuren. Deze reactie klopt helemaal. Ik had geen FIFO vermeld maar ging er impliciet vanuit. En wat je in de praktijk vaak ziet bij lange wachttijden is de roep om voorrang. Voorrang geven kan natuurlijk maar de directe consequentie is dat de niet-voorrang hebbende een langere doorlooptijd krijgen. De wet van Little is ook hier onverbiddelijk: De gemiddelde wachttijd verandert niet, dus bij versnellen hoort ook vertragen. Eigenlijk is prioritering een vorm van overprocessing en dus verspilling. Beter om energie in verbeteren te steken. Een andere suggestie was er om in plaats van FIFO af te handelen een afhandelingsvolgorde aan te houden die kijkt naar welke aanvraag er het eerste af moet zijn gehandeld. Waardevolle suggestie.

 

Cyclustijd versus takttijd

Een tweede reactie was dat er beter gerekend kan worden met de takttijd dan met de cyclustijd van de bottleneck in de situatie dat de takttijd hoger is dan de cyclustijd van de bottleneck. De door mij beschreven situatie was inderdaad dat het proces niet kan leveren wat de klant vraagt omdat de cyclustijd van het proces (bepaalt door de bottleneck) boven de takttijd ligt. Dan de situatie dat de cyclustijd van het proces ligt onder de takttijd. Moet er dan met de takttijd worden gerekend? Dit kan mijn inziens verschillend werken voor productie- c.q. dienstenprocessen. In een puur push-proces, zoals het is benoemd en met de push-pijlen is aangegeven, kan er in een productiesituatie meer worden gemaakt dan de klant vraagt. Er zal dan ophoping aan de achterkant van het proces plaatsvinden want de klant kan die hoeveelheden niet afnemen. Dit is bij productie-processen zeer wel mogelijk. En dan neemt de doorlooptijd toe. Er moet dan dus wel met de cyclustijd van het proces worden gerekend. In dienstenprocessen is het vaak anders. Dit omdat dan de klant vaak ook gelijk de belangrijkste leverancier is. Zoals in mijn voorbeeld waar er niet meer aanvragen kunnen worden behandeld dan er worden ingediend. In dat geval kan de gemiddelde indientijd van een aanvraag beter als takttijd worden genomen (takttijd=werktijd van dienstverlener op een dag gedeeld door aantal aanvragen op die dag). En dan reken je wel met de takttijd.

 

Push-proces

Een derde reactie was dat in de praktijk de wachttijden dynamisch kunnen zijn als het proces niet wordt aangestuurd. Dat is inderdaad een typisch kenmerk van een push-proces waar het onderhanden werk voortdurend kan veranderen. Pull of conwip (constant work in process: pas er weer één in als er één uit het proces komt) zijn dan de klassieke aansturingsmechanismen.

 

Flowshopproces of jobshopproces

De laatste reactie die ik wil benoemen is dat ik een flowshopproces beschrijf voor dit aanvraagproces maar dat dit geen adequate beschrijving zou zijn. Het kan beter als een jobshopproces worden gezien. Ik ben geen expert in jobshopprocessen maar deze reactie prikkelt om daar dan in te duiken. Inderdaad, evenementen zijn zo verschillend van elkaar dat elke aanvraag een ander beroep doet op de verschillende werkstations dat de praktijk hiervan zich meer gedraagt als een jobshopproces. Een jobshopproces kenmerkt zich door een grote variëteit aan producten/diensten in kleine volumes met onvoorspelbare vraag. Hierdoor kan de bottleneck gedurende de tijd kan veranderen. Goed punt dus.

 

Meer weten?

Wil je meer weten over Value Stream Mapping of over onze andere dienstverlening? Neem dan contact met ons op, via onderstaand formulier of bel ons via 053 – 20 30 240.






    Share This