Follow up on article about incorrect wait time calculations in the VSM

First, my thanks to those who responded because it helps in the deepening of knowledge in our field. The gist of my article was about how waiting time in a push process is often miscalculated by multiplying the inventory by the cycle time of the upcoming workstation. But to arrive at a good overall lead time, the cycle time of the bottleneck must be taken into account.

Applicable with a full first-in-first-out (FIFO)

The most common response was that this was true but only if full first-in-first-out (FIFO) is used. And that in practice with the illustrated long wait times this will not happen. This response is absolutely correct. I had not mentioned FIFO but implicitly assumed it. And what you often see in practice with long wait times is the call for priority. Prioritizing is possible, of course, but the immediate consequence is that the non-prioritized get a longer lead time. Little’s law is also implacable here: The average waiting time does not change, so with accelerating comes slowing down. Actually, prioritization is a form of overprocessing and therefore wasteful. Better to put energy into improving. Another suggestion was that instead of FIFO handling, there should be a handling order that looks at which request should have been handled first. Valuable suggestion.

Cycle time versus branch time

A second response was that it is better to calculate with the branch time than with the cycle time of the bottleneck in the situation where the branch time is higher than the cycle time of the bottleneck. Indeed, the situation I described was that the process cannot deliver what the customer requests because the cycle time of the process (determined by the bottleneck) is above the branch time. Then the situation that the cycle time of the process is below the branch time. So should branch time be used? In my opinion, this can work differently for manufacturing or service processes. In a pure push process, as it is named and indicated with the push arrows, more can be made in a production situation than the customer requests. There will then be accumulation at the back end of the process because the customer cannot take those quantities. This is very possible in manufacturing processes. And then the lead time increases. Thus, the cycle time of the process must then be taken into account. In service processes, it is often different. This is because then the customer is often the main supplier at the same time. As in my example where no more applications can be processed than are submitted. In that case, it is better to take the average submission time of an application as the branch time (branch time=working time of service provider on a day divided by number of applications on that day). And then you do count with the branch time.

Push process

A third response was that in practice, wait times can be dynamic if the process is not driven. This is indeed a typical feature of a push process where the work in progress can constantly change. Pull or conwip (constant work in process: pass one back in when one comes out of the process) are then the classic control mechanisms.

Flow shopping process or job shopping process

The last response I want to name is that I am describing a flow shop process for this application process but it would not be an adequate description. It is better thought of as a job shopping process. I am no expert on job shopping processes but this response excites me to dive into that then. Indeed, events are so different from each other that each request makes different calls on the different workstations that the practice of this behaves more like a job shopping process. A job shop process is characterized by a wide variety of products/services in small volumes with unpredictable demand. As a result, the bottleneck may change over time. Good point, then.

Want to know more?

Want to learn more about Value Stream Mapping or our other services? Then contact us, using the form below or call us at 053 – 20 30 240.