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!**