Overview of Kanban Planning
Kanban is a pull replenishment system whose aims are zero stockouts, shorter lead times, and reduced inventory with minimal manual supervision. Instead of waiting for an MRP plan to release materials down the supply chain, with kanban each operation pulls the materials it needs from its source when it needs them, signaling with a replenishment signal or a kanban that it needs to do so.
The term kanban refers to a visual replenishment signal such as a card or an empty bin for an item. In a kanban system, each work center has several bins, each containing a certain number of the same item. When a bin becomes empty, the work center starts the process of replenishing the empty bin by sending the replenishment signal, or a kanban. Meanwhile, the work center can continue using the other (stocked) bins.
An item that is pulled through the kanban system, rather than pushed by the planner, is called a kanban-released item, or simply kanban item. Your planning system can have kanban items as well as items released by the planner.
A kanban system is most effective in flow shops--manufacturing organizations with well-defined material flows. Because the demand for customer-order items may be discontinuous even in a shop where the material demand is steady, you might want to only designate certain items as kanban items.
The kanban location for a kanban item is the designated location where that item is stored (and where replenishment is delivered).
Sometimes, the kanban location is part of regular inventory. Often, however, kanban implementations use sub-inventory locations for kanban items, so that each work center has a small stock of the parts it needs. In these implementations, the sub-inventory location is the kanban location.
For every kanban item, there is a pull sequence --a series of kanban locations that models the actual replenishment network on the shop floor or through external suppliers, specifying the sequence to follow to obtain the kanban item.
In defining a pull sequence for a kanban item in Oracle Inventory, you specify the supplier and supplier site for a kanban item at a specific location. You also specify what you want the kanban calculation program to calculate, the lead time for obtaining the kanban item, the allocation percentage, and order modifiers that you want to affect the calculation program.
Kanban size refers to the number of items in each kanban. Because a kanban is only replenished when it's empty, the kanban size should be a multiple of the lot size. For example, if you would normally order an item in lots of 20, you should not make the kanban size less than 20 because the supplier would not be able to fulfill such an order.
Kanban cards are the replenishment signals. Each kanban bin has one kanban card, so the number of kanban cards is the same as the number of kanbans for each item. Thus, if a work center must have 100 of the same kanban item at any given time, and the kanban size is 20, there must be five kanbans for the item--five kanban cards.
The kanban plan indicates the number of kanbans and the size of each kanban required to satisfy the demand for all items that are either kanban released or have components that have kanban released items on the bill.
One of the most important tasks of a kanban planning system is determining the optimal number of kanban cards. The kanban planning software takes care of this calculation provided you enter correct values for kanban size, average daily demand for the kanban item, and the lead time to replenish one kanban.
We provide a package that you can use to customize the calculation. See the Oracle Manufacturing, Distribution, Sales and Service Open Interfaces Manual.
By default, the standard calculation is:
(C - 1) * S = D * L
- C is the number of kanban cards
- D is the average daily demand
If you think through the kanban process, you will see why this formula works best when the demand for the kanban item is steady.
- L is the lead time (in days) to replenish one kanban
In addition to this basic formula, when the calculation program calculates kanban size, it takes into account the values for the following order modifiers (specified in the pull sequence), in the following order:
For example, suppose you've specified the Minimum Order Quantity for a particular item to be 50. You want the formula to calculate the kanban size (S), so you enter values for S, D, and L. Even though--strictly based on the values you enter for C, D, and L--the formula should yield 40, the actual kanban size will be 50 because of your order modifier--assuming the Lot Multiplier is a factor of 50.
Note: The program uses order modifiers only when calculating the kanban size. If you specify the kanban size and want the program to calculate the number of kanban cards, the program does not use order modifiers.
How the Program Determines Average Daily Demand
Before the kanban calculation program can calculate the kanban size or the number of kanban cards, it needs values for the other variables. It gets the values of L and C or S from the pull sequence you define in Oracle Inventory. But where does the program get the value of D, the average daily demand?
The program calculates the average daily demand by following these steps:
- It identifies all the kanban items that you want to include in your kanban calculation, using the parameters you enter when you launch a kanban calculation.
- It finds location information for each kanban item.
- For each kanban item, it identifies every BOM in which the item appears so that it can explode the demand from the assemblies down to the kanban item.
- Using the MDS, MPS, or forecast you specify in the Kanban Names window, it identifies all the demand entries for each kanban item for which the demand is independent. For example, suppose that from the forecast you specified in Kanban Names, the program finds independent demand for 600 of kanban item A.
- It uses the Allocation Percentage specified in the pull sequence for each kanban item to determine how to distribute demand for the item among its different locations. For example, if the allocation percentage for item A at location L1 is 20%, then the program places demand of 120 (that is, 20% of 600) at location L1.
- Using the MDS, MPS, or forecast you specify in the Kanban Names window, it calculates demand for each kanban item for which demand is dependent on the demand for other items. It does so by using the following information:
- Quantity per Assembly. For example, if there are 2 of kanban item R per one assembly of item K, and the demand for K is 10, then the demand for R is 20.
- Component Yield. The program divides the demand for the child item by that item's component yield to determine the actual demand for the child item. For example, if the component yield for item R is 50%, the new demand for R is 40 (because 20 divided by 50% is 40).
- Reverse Cumulative Yield. The program further divides the demand for the child item by the Reverse Cumulative Yield (specified in the operation sequence of the flow routing for the parent item) to determine the actual demand for the child item. For example, if the reverse cumulative yield for K is 10%, the new demand for R is 400 (because 40 divided by 10% is 400).
- Net Planning Percentage. The program then multiplies the demand for the child item by the Net Planning Percentage (specified in the operation sequence of the flow routing for the parent item) to determine the actual demand for the child item. For example, if the net planning percentage for K is 80%, the new demand for R is 320 (because 400 multiplied by 80% is 320).
- Finally, the program sums up the demand entries that fall within the kanban planning horizon for each kanban item at each location and divides the demand for each item at each location by the number of work days. For example, if the number of work days on the planning horizon is 20, then the average daily demand for item A at location L1 is 6 (because the total demand for item A at location L1 for the planning horizon is 120). The program prorates the demand from periodic forecasts for those days between the Demand window specified for the calculation program.