KANBAN

19
Kanban Replenishments – An Overview An Oracle White Paper June 2003

description

Kanban process oracle

Transcript of KANBAN

Page 1: KANBAN

Kanban Replenishments – An Overview An Oracle White Paper June 2003

Page 2: KANBAN

Kanban Replenishment – An Overview

Objective:............................................................................................................ 3 Introduction: ...................................................................................................... 3 Business Needs .................................................................................................. 3 Kanban Supply Status....................................................................................... 4 Kanban Source Types....................................................................................... 5

a) Production: ................................................................................................ 5 b) Intra Org:................................................................................................... 5 c) Inter Org: ................................................................................................... 6 d) Supplier...................................................................................................... 6

Setup Required:.................................................................................................. 7 Kanban Planned Items - Setup ................................................................... 7 Kanban Card Definition .............................................................................. 7 Kanban Pull Sequences - Setup .................................................................. 8

Kanban Card Sizing .......................................................................................... 9 Calculation Formula ................................................................................... 10 How the Program Determines Average Daily Demand ....................... 11 Kanban Card Printing ................................................................................ 13

Technical Overview: ....................................................................................... 14 Tables used: ................................................................................................. 14 Packages used: ............................................................................................. 14

References: ....................................................................................................... 18 About the Author: ........................................................................................... 18

White Paper Title Page 2

Page 3: KANBAN

Kanban Replenishment – An Overview

OBJECTIVE: The objective of this paper is to understand as to what a KANBAN Replenishment system means and how is it handled in the Inventory module of Oracle Applications. The scope of the usage of KANBAN system in this paper is restricted for the purposes of Replenishment.

INTRODUCTION: Kanban in Japanese means “sign” or “signal”. This system is used in where the items have a relatively stable demand and medium to high production volume.

Kanban Cards are used in a Pull based System. A pull based system is one where inventory items for a particular part or assembly area are replenished as soon as they are needed. When the items are needed, Kanban cards in Oracle Inventory change their Supply Status to Empty, and Inventory generates the Kanban replenishment request automatically.

Oracle Inventory allows you to define Kanban planned items and replenishment chains based on sourcing information to support your continuous flow manufacturing systems. You can define Kanban planned items, and create a Kanban Pull Sequence for each Kanban item. You can specify different replenishment sources for your Kanban locations. Kanban Cards are used to replenish your Kanban items by triggering replenishment requests based on sourcing information. You can print Kanban cards for a replenishment plan or a pull sequence.

BUSINESS NEEDS With Oracle Inventory you can:

White Paper Title Page 3

Page 4: KANBAN

· Minimize stockouts

· Achieve shorter lead times

· Reduce inventory with minimal manual supervision

KANBAN SUPPLY STATUS Kanban cards are generated with default Card Status of Active. When you define a card manually, you can initially give it either Active or Hold status. If the Supply Status is Full, you can temporarily pull a card out of the replenishment chain by changing the Card Status to Hold. You can terminate use of a Kanban card by changing the Card Status to Canceled, but you cannot reverse this change. Only Canceled cards can be deleted.

All the Kanban Supply Status codes can be set manually only. Kanban is a manual control system. However a Kanban API can be used to update the Supply status of the Kanban Cards.

The Various valid statuses of Kanban Cards are: 1. New The Kanban has just been created and is not yet part of the replenishment chain.

2. Empty The Kanban is empty and a replenishment signal has been generated.

3. Full The Kanban has been replenished.

4. Wait The Kanban is waiting until the minimum order quantity has been met by the aggregation of cards.

5. In-Process for the Supplier source type, the purchase order has been approved. For the Inter-organization source type, the internal requisition has been approved.

6. In-transit You have received an advanced shipment notice indicating that All Kanban cards are generated with a Supply Status of New. You can change this status to Empty to trigger a Kanban replenishment signal. During initial setup, you can switch the status to Full if you are starting out with a full bin. When you are defining a card manually, you can create it with a status of Empty, Full or New.

White Paper Title Page 4

Page 5: KANBAN

KANBAN SOURCE TYPES The Kanban Source types identifies the type of replenishment that is required to fulfill a material requirement planning that is generated by a Kanban.3

There are 4 different types of Source Types:

Production

Intra Org

Inter Org

Supplier

a) Production: When the Kanban Pull Sequence Source Type is set to Production, after the Kanban card is set to “Empty”, Kanban replenishment would launch a WIP Job for "make" item. Records are inserted in the table WIP_JOB_SCHEDULE_INTERFACE. This works for the Date Effective items only.

On Selecting the Source type as “Production”, while defining the Source type, enter the flow or discrete line that supplies to this location.

b) Intra Org: When the Kanban Pull Sequence Source Type is set to Intra Org, i.e. The item is to be transferred from a Subinventory within the Organization, the Kanban replenishment would result in a Replenishment Move Order generation, which would authorize the movement of the material within an Organization.

Value of REFERENCE_ID in MTL_TXN_REQUEST_LINES gives the KANBAN_CARD_ID in MTL_KANBAN_CARDS.

When the Source type is Intra Org, while defining the Source type, choose the Source Inventory and the locator from where you want to replenish.

White Paper Title Page 5

Page 6: KANBAN

c) Inter Org: When the Kanban Pull Sequence Source Type is set to Inter Org, i.e. The item is to be transferred from a different Organization, depending on the set up in shipping network for the Organization, with shipment type of 'In transit' or ‘Direct’, the Kanban replenishment would result in a Internal Requisition generated.

When the Source type is Inter Org, while defining the Source type, choose the Organization from where you want to replenish.

The Requisition Import generates an internal requisition for the item with a status of Approved. (If encumbrance/budgetary control is on, Purchasing sets the status to Pre-Approved.)

Once Purchasing approves the standard purchase order, blanket release, or internal requisition, Inventory automatically receives a status for the Kanban card of In Process.

In Purchasing, Kanban replenishment requests look like any other purchasing document, and you receive them like you do any other shipment. As soon as you receive the item for delivery through the Receipts or Receiving Transactions windows in Purchasing, Inventory automatically receives a status for the Kanban request of Full, indicating that the inventory supply has been replenished.

d) Supplier When the Kanban Pull Sequence Source Type is set to Supplier, i.e. The item is to be brought from a Supplier, when query and select a Kanban card and then Replenish it, a row is inserted in to the PO_REQUISITIONS_INTERFACE_ALL. And then Purchasing creates a blanket release (if a blanket agreement exists) or a standard purchase order (if a valid quotation exists) for the item.

This record is then converted in to a pre-Approved Requistion by running the Req-import process.

White Paper Title Page 6

Page 7: KANBAN

When the Source type is Supplier, while defining the Source type, choose the Supplier code and the site you wish to procure the material from.

SETUP REQUIRED: Kanban Planned Items - Setup You can specify an item to be a Kanban planned item by setting the Release Time Fence attribute in the MPS/MRP Planning Attribute Group to Kanban Item. Only Kanban planned items can be used in defining a pull sequence.

Kanban Card Definition You can create Kanban cards for an item, subinventory and locator. Oracle Inventory allows you to generate Kanban cards automatically or manually. A

White Paper Title Page 7

Page 8: KANBAN

Kanban number uniquely identifies each Kanban card. The Kanban numbers are automatically generated for those cards that are generated from a Kanban pull sequence. For manually defined cards, both replenishable and non-replenishable, you can enter an unused Kanban number or let the system create the number. Replenishable cards are used for Kanbans that cycle through the system from full to empty, remaining active until they are withdrawn. Non-replenishable Kanban cards are one-time signals that are primarily used to manage sudden spikes in demand. Non–replenishable cards do not have to be associated with a pull sequence.

Kanban Pull Sequences - Setup For every Kanban planned item, you must define a pull sequence, which is a series of Kanban locations that model the replenishment network on the shop floor. A Kanban location can be a subinventory or an inventory locator. The replenishment source for a Kanban location can be another Kanban location, a production line, another organization or an outside supplier. You have the option to use locators even if the locator control is turned off at the organization, subinventory and item levels.

Pull sequences cannot be used with model/unit effective number controlled item since the Model/unit effective items are for project manufacturing environment and pull sequences are for flow manufacturing kind of environment. Pull sequences are not supposed to be used by items that are model/unit effective number controlled (project manufacturing). Both functionalities are for different kind of industry segments.

The following snapshot gives an example of a Pull Sequence for item KB15138:

Supplier Kanban

Supplier: Advanced Network Site: SANTA CLARA

Org: M1

SubInv. Stores Locator: 1.1.1..

Inter org Kanban

Org: M1 SubInv. RIP

White Paper Title Page 8

Page 9: KANBAN

Note:

The subinventory and locator on the first pull sequence in your replenishment chain must equal the subinventory and locator on either the material control region of all bills of material using this Kanban location or the WIP supply location on the Organization Item Master. If these values do not match exactly, Kanban planning for the item will fail.

KANBAN CARD SIZING Kanban Size is calculated when the line is designed, since the line is designed for maximum rate, the Kanban size is also calculated accordingly. The Kanban Size reflects the minimum amount of Inventory that is required to support the designed daily rate of Production.

White Paper Title Page 9

Page 10: KANBAN

You can choose what you want the program to calculate: Kanban size or Kanban cards. The product of Kanban size and number of Kanban cards (or containers) will satisfy the demand at capacity for the planning horizon.

Kanban size refers to the number of items in each Kanban container. Each Kanban container has one Kanban card, so the number of Kanban cards is the same as the number of Kanban for each item.

In the planning process, there are Order modifiers defined for each pull sequences:

Minimum Order Quantity – This is defaulted from the item setup.

Lead-time – This lead-time is the time required to replenish one Kanban from its source.

Lot Multiplier – Use this if you want to have lots in fixed Multiples.

Allocation Percentage – This represents the distribution of an item’s demand across multiple locations.

Safety Stock – The number of days of safety stock you want to maintain.

If you specify the Kanban Size, the program will not consider the above Order Modifiers to calculate the number of cards.

Calculation Formula 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.

Oracle provides 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 * A * (L + SSD)

where:

White Paper Title Page 10

Page 11: KANBAN

C is the number of Kanban cards

S is the Kanban size

D is the average daily demand

A is the allocation percent

L is the lead time (in days) to replenish one Kanban

SSD is the Safety Stock Days

If you think through the Kanban process, you will see why this formula works best when the demand for the Kanban item is steady.

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:

Minimum Order Quantity

Lot Multiplier

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 C and L. Even though--strictly based on the values you enter for C and L--the formula should yield 40, the actual Kanban size will be 50 because of the Minimum Order Quantity. If a Lot Multiplier of 15 is specified, the Kanban size is rounded to 60 in order to meet both the Minimum Order Quantity and Lot Multiplier order modifiers.

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. 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.

White Paper Title Page 11

Page 12: KANBAN

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, Actual Production, 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, Actual Production, 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 workdays. For example, if the number of workdays 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

White Paper Title Page 12

Page 13: KANBAN

forecasts for those days between the Demand window specified for the calculation program.

In the following example, the Kanban Size is defined for the item KB15138.

Kanban Card Printing You can print Kanban cards for a replenishment plan or a replenishment chain when you generate the cards. You can also print cards individually if the card information is complete. You can print duplicate cards only if the original is lost or voided.

In a Kanban System, every container has a Kanban that displays the item number, Item description, usage point, supply point, size of the Kanban (or pull quantity) and the sequence number of the card.

White Paper Title Page 13

Page 14: KANBAN

TECHNICAL OVERVIEW:

Tables used: MTL_KANBAN_CARDS:

MTL_KANBAN_CARDS is the definition table for Kanban cards. The associated attributes describe which pull sequence this card belongs to, the Kanban size, supply status, and card status MTL_KANBAN_CARD_ACTIVITY:

MTL_KANBAN_CARD_ACTIVITY is a history table of the activity performed on a Kanban card. The associated attributes describe which Kanban card this activity belongs to, and what document replenished it.

MTL_KANBAN_PULL_SEQUENCES:

MTL_KANBAN_PULL_SEQUENCES is the definition table for pull sequences. The associated attributes describe which item, subinventory, and locator this pull sequence belongs to, the source type, number of Kanban, Kanban size, replenishment lead time, and other planning attributes.

Packages used: Following are some important packages used in the Kanban system. INVVKBNB.pls – creates PACKAGE BODY INV_Kanban_PVT

This package body consists of the following important procedures

Get_Pull_Sequence_Tokens:

This procedure gets the names required to build the message for a pull sequence

Delete_Pull_Sequence: This procedure deletes all pull sequences for a given plan.

White Paper Title Page 14

Page 15: KANBAN

Validate_Pull_Sequence: This procedure verifies whether all required fields are present.

Insert_Pull_Sequence: This procedure inserts record in MTL_KANBAN_PULL_SEQUENCES with data from the record.

Update_Pull_Sequence: This procedure Updates the record in MTL_KANBAN_PULL_SEQUENCES with data from the record.

Update_Pull_Sequence_Tbl: This procedure Updates the records in

MTL_KANBAN_PULL_SEQUENCES with data from the table of pull sequences id's passed to it. It generates and prints Kanban cards as well.

Update_Card_Supply_Status: This procedure updates the supply status for a Kanban card id record. If the supply status is In Process the document details are also captured.

Update_Card_Supply_Status: This procedure updates the supply status for a Kanban card id record.

Valid_Production_Kanban_Card: This function will check the validity of a production Kanban Card.

Delete_Kanban_Cards: This procedure deletes Kanban cards for a pull sequence.

Create_Kanban_Cards: This procedure generates Kanban cards for a pull sequence.

Create_Move_Order: This procedure would create a transfer order for Kanban card with source type Intra Org.

Launch_MLP: This program will launch the WIP Mass load program to upload the data from WIP_JOB_SCHEDULE_INTERFACE table.

Create_Wip_Discrete: This procedure would create a WIP Discrete Job for a Kanban card.

White Paper Title Page 15

Page 16: KANBAN

Create_Rep_Schedule: This procedure would create a WIP Repetitive

Schedule.

Create_Flow_Schedule: This procedure would create a WIP Flow schedule.

Create_Wip_Job: This procedure will decide about the creation of a WIP replenish mode.

Create Replenishment: This procedure would create kick off the replenishment cycle for the Kanban cards.

Check_And_Create_Replenishment: This procedure will check whether it is ok to start replenishment cycle for a card.

INVKBCGS.pls creates the package INVKBCGN that consists of the following procedures

Procedure to Create_Kanban_Cards

procedure card_check_and_create

INVKBCGB.pls

This Stored package is a Concurrent program, primarily for Generating Kanban cards and launching the card printing report.

It has got following subprograms:

1. Create_Kanban_cards procedure calls functions for generation of Kanban cards, based on the parameters passed to it.

2. Resolve_Pullseq_All_Null function is called when no parameters are passed.

White Paper Title Page 16

Page 17: KANBAN

3. Resolve_Pullseq_With_Pull is called when pull_sequence_id is passed as parameter.

4. Resolve_pullseq_with_loc is called when locator flexfield is passed as parameter.

5. Resolve_pullseq_no_loc is called when locator flexfield is not passed but other parameters are passed.

6. Card_check_and_create checks for the existence of valid cards and calls APIs for generating cards.

7. Print_kanban_report - launches Kanban card printing report.

8. Print_error - To print error messages to log file.

9. Kb_get_conc_segments - To find out locator name when locator id is passed.

White Paper Title Page 17

Page 18: KANBAN

REFERENCES: 1. Release 11.5 Oracle Inventory User's Guide

2. Oracle E- Business Suite, Manufacturing & Supply Chain Management, by Bastin Gerald, et al.

ABOUT THE AUTHOR: Uday P. Maydeo, CPIM, is a Senior Support Analyst at Oracle’s India Support Center, Bangalore, India.

White Paper Title Page 18

Page 19: KANBAN

Kanban Replenishments – An Overview June 2003 Author: Uday P. Maydeo Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Copyright © 2003, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.