This is the second post on kanban calculation (if possible, please read the **first post on kanban calculation **first). There are two possible approaches. First, you can **calculate the number of kanbans **using a kanban formula (due to its length, split into a first post and this second post). Alternatively, you can **estimate the number of kanbans **and adjust the system as it is running (as shown in a third post).

## Kanban Calculation – Part 2

Overall, there are five factors that determine the number of kanbans in a system. The first four are rational and are shown in the picture below. The fifth one is not very rational, but it is still needed for the system to work smoothly. These five factors, in the order we will cover them below, are:

**Regular Time of Customer**: How many parts does the customer need in a certain period?**Regular Time of Replenishment System**: How long does it take to replenish a product in your production or supply system?**Fluctuations of Replenishment System**: If there are problems in the replenishment system, what problems do we want to cover?**Fluctuations of Customer**: If the customer orders more quantity, or the same overall quantity but less frequently, which fluctuations do we want to cover?**Safety Margin**: Do we want to add additional kanbans so personnel feels more comfortable with the system?

Out of these five factors, the first two were covered already in my previous post How Many Kanbans? – The Kanban Formula, Part 1.

### 3. Fluctuations of Replenishment System

The system delivering the new products naturally will have hiccups. Not everything will go according to plan, and sometimes there will be delays. Average delays and losses have already been included when calculating the lead time. When calculating how fast the parts were leaving the system, we used the long-term average performance of the system. Hence we already included long-term average losses.

What we did not include were short-term problems. For example, assume your system has technical problems and is down for two hours. You would need to have enough kanbans in the system to cover these two hours until the system can catch up again. Similarly, if you want to cover breakdowns up to four hours’ duration, you would need four more hours in kanbans.

Unfortunately, no matter which time you cover, you can easily imagine a problem that would be longer than the covered time, however unlikely. Here **you have to decide what you want to cover and at what point you decide to take the bullet and run out of stock** rather than keep insane amounts of stock available all the time. This decision should be based on previous experience with the reliability of your system, and the amount of problems your company has if the customer misses his parts. Keep in mind that so far we have always used conservative estimates for other factors, hence your total covered time is likely to be higher than the time you add here.

### 4. Fluctuations of Customer

The fluctuation of the customer is similar. Here we have two factors to consider. First of all, not all customers have their parts delivered one by one. It is more common for a customer to have **multiple parts shipped at the same time** or even only once per week or once per month.

However, the system as calculated above so far only ensures that you have one kanban worth of parts in your system at any given time. If your customer wants five kanbans worth of parts in one shipment, you need to add four more kanbans. Please keep in mind that a kanban may represent more than one part.

For example, you estimate that your customer usually has shipments of 200 parts at one time. Yet you have only one kanban in the system representing 20 parts. Hence you need to add 9 additional kanbans to cover the bulk shipments.

Secondly, **your customer may or may not order as many parts as estimated by the customer takt**

*.*If he orders less, you do not run out of parts. If he orders more, you may need additional kanbans. The key here the replenishment time. If your customer orders more, your system will produce more but be delayed by the replenishment time. Hence you need to cover any additional demand during the replenishment time to give your system time to catch up.

Therefore, you need to estimate what a possible **additional peak demand within a replenishment time** could be. This demand has to be covered by adding additional kanbans. For example, if you estimate that besides the average 100 parts ordered during the replenishment time, your customer may order 100 more, then you would need 5 additional kanbans if each kanban represents 20 parts.

### Calculating the Total Number of Kanban

Now we have everything together – except for the safety factor – to estimate the number of kanban. We have a number of times that we can sum up:

- Lead time (material flow) from 2.1 in my previous post
- Waiting time of kanbans in the supermarket (as part of the replenishment time) from 2.2 in my previous post
- Duration of breakdowns and other problems in our system we want to cover from 3. above.

We also have a number of kanbans that we can sum up:

- Lot size formation from 2.2 in my previous post
- Waiting for other lots from 2.2 in my previous post
- Customer batching orders from 4. above
- Additional peak customer demand from 4. above.

Summing up the time, we now have to convert the time into the number of kanbans. For this, we need the customer *takt* (from 1. above). Dividing the total time by the customer *takt* represents the number of parts that we need to cover. Dividing this further by the number of parts per kanban gives us the number of kanbans.

For example, assume we calculated a total time of 4:04 hours, or 14,640 seconds. Dividing this by our customer *takt* of 28 seconds per part gives us 522.86 parts. Further dividing this by 20 parts per kanban gives us 26.14 kanbans needed to cover the different times. Don’t round this number yet.

Next we add the different number of kanbans from above to the kanbans needed to cover the time. For example, assume we had another 20 kanbans from lot size, customer batching, etc. Our total would now be 46.14 kanbans. (Still don’t round this number yet.)

### 5. Safety Margin

The last thing to add would be the **safety margin**. Technically, this is usually not needed. The kanban calculations above – for all their uncertainty – are usually quite conservative, and you may get away with even fewer kanbans. However, in many plants, shop floor personnel or lower management have negative experiences with upper management cutting margins too thin, hurting plant performance and therefore creating problems, especially for the people on the shop floor. Plus, your problems may be bigger than you think they are.

The safety factor is a way of giving additional safety to people who worry if the numbers match or if there will be a mess on the shop floor afterwards. Hence we simply add either more kanbans or a percentage to the kanbans calculated so far, until the people involved (possibly including yourself) feel more comfortable. Strictly speaking it is not necessary, but **the few extra kanbans are usually worth the peace on the shop floor**.

At this point we can also round the number of kanbans. As our previous calculation was far from precise, we do not necessarily need to round up. If our total stands at 61.2 kanbans, I would be happy to also round down. For 61.9, I would probably round up. Usually I include the rounding as part of the safety margin discussion or decide based on gut feeling about the conservative numbers used so far.

And that’s it. There you have it. You have estimated the number of kanbans needed for a kanban loop. Just keep in mind that this is only a **very rough estimate**. In the next and last post of this short series, I will present alternative methods to determine the number of kanbans, including comments on how to maintain and update the number of kanbans in the system. Now go out and **improve your industry!**

Chris,

If we have ABC 3 processes when we assemly one product X,A is the botttleneck process,we use the total avaiable amount of time of 3 process OR only avaiable time of the bottleneck process when we calculate the takt ?thanks

Tim

Hi Tim, my post How to determine Takt Times may help you on how to determine takt times.

Dear Mr Roser,

I have been reading your posts for 2 years and find them very helpful. Thank you so much for the great efforts:-)

Just one question:

The calculation shows that the total numbers of Kanban cards in the system. But how can I estimate the space needed for the supermarket? Since it is a running loop, I guess we cannot plan the supermarket based on the total number of the cards.

Your answer is appreciated.

Best regards,

Hi Ray Lee, ideally the supermarket should fit all the kanban (i.e. the parts represented by kanban). Normally the supermarket is only 50% full in a good system, but especially if you have many different products some of them may be at 100% in the supermarket, and having a too small supermarket would be a constant hassle.

Hello, upon reading your post I had some doubts I hope you will be able to clarify. When you talk about the replenishement time, it is the time in takes a kanban to tranverse the production system, with all the elements you explained and its possible fluctuations. If we set the number of kanban cards to cover the demand during the replenisment period imagine this example: we have a demand of 10 units/hour, a replenishment time of 1 hour and we ignore safety margin considerations. According to calculations with a container size of 2, we would need 5 kanban cards. So if 1 kanban takes an hour to complete a cycle, it means that on the second cycle we would only have 1 kanban available of stock, and a demand of 5 to cover every hour. What am I missing?

Hi TS. the replenishment time is the time from the card leaving the supermarket, until the same card comes back with a part into the supermarket. For Make to Stock this must include fluctuations, the question is how much.

Your calculation is correct, you have a replenishment time of 1 hour multiplied with a frequency of 10 per hour (or divide by a takt of 1/10th hour), which gives you 10 pieces in the loop. Having two parts per kanban (box), you need five kanban, and would have to produce 5 kanban (10 parts) per hour.

The fun starts if you include fluctuations. What if your system is down for 2 hours –> add 10 more cards if you want to cover it. What if the customer sometimes orders 5 parts at once (with the same average of 10/hour) –> add 4 parts/2 kanban. This quickly becomes a very messy calculation/estimation on what fluctuations you want to cover and when you decide that you rather take a stock-out.

Thank you very much for your answer. I was missing the assumption that prior to this we assume that capacity meets demand. In this case in the same hour we can process 5 kanban simultaneously.