As I wrote earlier the magic of pull is based on the WIP regulation. In order to have optimal production we should set the correct WIP level. If it’s too close to critical WIP, throughput will suffer. If it’s too big, cycle time increases.

If we want to change our existing line into pull production the easiest way would be to set WIP level as it is right now. We won’t launch new jobs until some previous job is finished and the line is controlled as an single CONWIP line.

After this we will wait until the line stabilizes and then observe if there will transform queues somewhere. Especially in front of the assumed bottleneck stations. Observation must be done from longer time period and WIP levels should not be changed daily.

If there is constant queue in front of the bottleneck station, then decreasing the WIP won’t make any impact on line. It will only decrease the cycle time.

Then we will continue to observe the line especially if we make any more changes into the line. Example speeding up the bottleneck station could make it to starve if WIP levels are not changed accordingly.

WIP level exception

No rules without exceptions! Let’s think that there is an machine breakdown after the bottleneck station. Then we will end up in the situation where queue will transform in front of the broken machine and all production cards will end so that all the machines before the broken station will stop including the bottleneck station.

If there is significant speed difference between the bottleneck station and broken machine it could be reasonable to launch new jobs without the production card so that the bottleneck station won’t starve. Broken machine can catch up the queue and our throughput won’t suffer.

In case of machine breakdowns the bottleneck station can be fed by launching jobs without the production card

In case of machine breakdowns the bottleneck station can be fed by launching jobs without the production card

There is also another way to maximize the use of the bottleneck station.

We can pull production from the bottleneck and then push it from there.

Production is pulled from the bottleneck and then pushed from then onwards

Production is pulled from the bottleneck and then pushed from then onwards

Multiloop CONWIP

To gain better control we can split our line into smaller parts instead of one common WIP level. Then our line is kind of somewhere in the middle of the kanban and CONWIP lines where WIP is regulated in multiple places.

One regulation can cover only one workstation and the smaller the loops are the more closer of kanban behavior it will be.

Comparison of different pull methods

Comparison of different pull methods

Even after the line has been splitted in multiple loops we have another problem to solve.

Where production cards should be removed from the job? When it leaves the buffer or before it’s going to buffer?

If in all loops we move cards when jobs are taken from the buffer into the next loop our line would behave quite similar than normal CONWIP line.

If we take new job into the loop everytime one job is finished, before it goes to the buffer, then there would be an possibility to overfill the buffer in case of breakdowns in the next loop.

Pulling from the end of the line, before the buffer, is something that could be used in bottleneck loop. Then we would have quite similar behavior than the example above where jobs were launched without production card.

Different pulling points and bottleneck loop

Different pulling points and bottleneck loop

This picture represents that kind of line where production card is moved when job is taken from the buffer. Buffer is kind of one part of the loop and WIP is regulated including the buffer.

But bottleneck loop pulls its jobs before the buffer, every time another job is finished. This allows it to work fully utilized. Buffer after the bottleneck loop is not part of any loop, so it can be overfilled if there is breakdown in the loops after it. So the loops after the bottleneck doesn’t limit the throughput of the bottleneck loop.

Shared resources

From logistic point of view it would be easiest if every product/routing would have its own machines. But it’s not always doable if there is one expensive machine that is needed for multiple products.

Easiest way to use shared resource is to split line before and after the shared resource into CONWIP loops. Shared resource will take the jobs from the buffer based on their queue time. (FIFO)

If lines produce very different products and shared resource needs setups it could be necessarily to determine more conditions, like minimum amount of each product family before the setup. Then FIFO doesn’t always happen but it could be necessarily so that the shared resource won’t become the bottleneck due to setup times and low utilization.

CONWIP-loops in case of shared resource

CONWIP-loops in case of shared resource

Shared resource complicates production predictions and line behavior modelling. But it can be computed quite well if we know the production distribution for different products and the process time in shared resource.

Let’s take an example from the picture above. If process time for product A is 1 hour and for product B 2 hours and A product is done 60 % and B product 40 % of the summarized production. Time that is used to manufacture product A is 1 x 0,6 / ( 1 x 0,6 + 2 x 0,4 ) = 0,4286.

So 42,86 % of the time the shared resource will produce A product. This can be used in calculations same way like availability. When machine does one product it is unavailable for other products.

Average process time for each job is inverse, so process time for A product is 1/0,4286 = 2,33 hours and for B product 2/0,5714 = 3,5 hours.

Now we can compute predictions for each line like the shared resource would be for that line only. We just take in consideration the availability for that specific product.

This is easy if the product distribution is constant 60/40 %. But if it varies a lot our modelling would be more complicated. Then we can assume that the shared resource behaves like an high variation machine.

Controlling the throughput

Because pull production is based on WIP regulation it is possible to make products ahead of scheduled. Of course with that prevision that there is enough jobs in release list.

From the variation point of view it is also good practice to do next weeks jobs if we have good flow and our bottleneck station is faster than average. But it is not practical to do jobs that are not due for months.

This leads us into conclusion that every job should have an earliest start date on release list.

Correspondingly during the bad times we should be prepared to do overtime. Extra hours or days. We should compare our throughput and schedule and see if we are behind and consider if extra Saturday or extra hours are necessarily.

But we must be careful with overtime so that we won’t end up in treadmill.


Written by Jesse Uitto

Sales Director @

Leave a Reply

Your email address will not be published. Required fields are marked *