Set up kanban loops by associating items with supplying sources and destination supermarkets using Kanban Master Maintenance (17.1.4). See Define Loops in Kanban Master Maintenance.

Depending on the way cards are used to signal inventory movement between the source and destination or authorize production, loops can be set up to use either one or two cards.

In lean manufacturing, a supermarket is a controlled inventory location used to schedule production at an upstream process. Supermarkets can absorb variations in demand, compensate for differences in processing time among production operations, and allow a single work cell or operation to supply multiple downstream processes with different, variable rates of demand.

A supermarket can serve both as the destination for completed kanban items from one loop and as the source of supply for another loop.

These two kinds of supermarkets provide flexibility in the way you use kanban loops. For example, you can receive raw material from a supplier directly into stock by defining the destination as an inventory supermarket. You can then set up kanban loops between this inventory supermarket and point-of-use WIP supermarkets on the shop floor—using pull signals to replenish the WIP supermarkets. In a similar scenario that lets you track the inventory in the point-of-use supermarkets as part of the on-hand balance, define them as inventory supermarkets.

Typically, supermarkets are placed at points in the overall workflow when continuous flow is interrupted. For example, they can be placed:

Define supermarkets in Supermarket Maintenance (17.1.2), and associate them with kanban loops in Kanban Master Maintenance (17.1.4). See Setting Up Kanban Supermarkets.

Use the Supermarket Item Detail frame in Kanban Master Maintenance to define characteristics of how an item is stored at a supermarket for a specific kanban loop. For example, you can specify the maximum quantity that should be stored at the supermarket, the average demand, safety stock data, and buffer tolerances that can be used to evaluate historical and projected performance. See Supermarket Information.

In lean manufacturing, a process is a group of activities before and after which flow stops and inventory accumulates. In Kanban, you can define a process as the source of a kanban loop—with inventory accumulating at the loop destination, which is a supermarket.

Use Kanban Process Maintenance (17.1.3) to define the processes that supply kanban loops. Based on the relationship between the process and the kanban loops it supplies, that program lets you define each process as one of the following:

See Define Processes.

In a lean manufacturing environment, the pacemaker is the process that responds most directly to final demand. Often, this is near the end of the production cycle. For example, the pacemaker might be the final assembly process that supplies a finished-goods supermarket from which customer orders are filled.

You typically schedule production based on the pacemaker process. For example, you can use Preliminary Level Schedule Report (17.14.2) with Pacemakers Only set to Yes to determine the number of units that each shift on the pacemaker process needs to produce to meet demand. Level Mix Workbench (17.14.1) only creates level schedules for pacemaker processes.

First-in, first-out (FIFO) lanes are a way of managing inventory between processes when a supermarket buffer is not necessary, but continuous flow is not practical. For example, a FIFO lane might be used in front of a large batch operation where dissimilar parts go through a process such as welding, plating, anodizing, stamping, painting, and so on.

The first process receives the signal to produce from the supermarket (or from a FIFO lane from a previous process) and moves material to the subsequent process. The item produced at the second process is run in the order that it is received. Completed material moves to the supermarket or to another FIFO lane.

Based on how closely the flow of kanban material is controlled, cards can be recorded using Kanban Ship (17.6.4) as the material moves through a series of FIFO lanes. The system tracks the material by assigning the cards an in-process status. When the last FIFO process is completed, the system changes the status to shipped to indicate that the kanban has moved to the supermarket. See FIFO Process Data.

In Kanban Master Maintenance, you can specify one or a series of FIFO processes that perform work on a kanban item between the time it leaves the primary supplying process and when it reaches the destination supermarket.

The system can calculate various values related to kanbans for use either by other system functions or for analyzing the best way to set up kanban loops. In most cases, you have the option of entering these values manually, although they may be subject to automatic update.

This section describes the main kinds of calculations used by Kanban.

Every-part-every interval (EPEI) is an important concept in lean manufacturing. It indicates the time interval over which you can run every regular part produced in a process based on current demand. Knowing the EPEI helps determine the manufacturing lot size and supermarket quantities for each part produced in a particular manufacturing process, as well as the number of kanban cards in the replenishment loop. For example, if you have sufficient time to produce all the items more than once each day, you can consider using smaller lot sizes—leading to improved agility.

You can prevent the system from including rarely or irregularly produced items in process EPEI calculations by setting EPEI Auto to No for the item detail in Kanban Process Maintenance. In that case, the EPEI value is for reference only. Additionally, you can specify minimum EPEI values for both a process and an individual item—for example, if you do not want to set up a process more than once during a given period. If the system-calculated value is less than the minimum, the system uses the specified minimum instead. See Define Processes.

While Kanban Process Maintenance includes several options for displaying EPEI, it often is expressed in days. For example, when you are using days as the display option, an EPEI of 0.5 means that, allowing for changeover times, the process can produce all of its items twice each day.

The reciprocal of the number of intervals provides the EPEI for the process:

Average demand is the average total quantity of a kanban item required during each day over a specified historical or future period. Individual item average demand is required to determine supermarket size and kanban sizes for kanban loops, as well as for mix analysis and level scheduling activities. Average demand for all the items produced by a kanban process is needed to calculate takt time, pitch time, and EPEI.

The system can calculate average demand based on actual historical demand, projected future demand, or a combination of both. Since this calculation is actually being done for a kanban loop or loops and any given item may have multiple kanban loops, the system must include some additional logic to determine how much of each item’s total demand is being satisfied by a specific loop. This is done using the Demand Percent field in the Kanban Master record.

Use Demand Calculation Template Maintenance (17.1.6) to set up definitions of demand patterns, and associate a demand template with loop records in Kanban Master Maintenance. The system bases its calculation on that template when you run Average Demand Calculation. See Calculate Average Demand and Safety Stock.

When the template specifies only historical days, the system searches for inventory usage in the inventory history for kanban items within the specified site range and number of historical days. In this search, the system looks for issue and backflush transactions, including ISS-UNP, ISS-SO, ISS-FAS, ISS-WO, and similar transaction records that were recorded during the specified range. The specified range covers the period starting at the current day minus the specified number of historical days through the current day minus one. (Note that the current day is not included in the historical horizon, since issue transactions are still being processed for the current day.) Transactions by item are aggregated for the specified number of days, then the average quantity issued per day is calculated by multiplying the aggregated usage by the Demand Percent.

When the template includes only future days, the average daily demand for a component is derived directly from the average daily demand of each of its parent items, plus any additional independent demand (unconsumed forecast and customer orders) during the specified horizon. In this calculation, the system processes the items in the selection working from the highest bill of material level to the lowest (that is, from top to bottom). It also includes additional logic, using the Demand Percent, to calculate how much of the average demand will be sourced through the loop in question.

For each kanban loop and associated item being processed, the system computes the average daily demand using the following logic:

Notice that this calculation does not use exploded MRP demands and does not require MRP to be run. Note that although the template says “Using MRP Demand” when the Future Demand Source is “Explode,” the actual logic does not use all the MRP detail requirements to compute the average demand. Only forecast and customer demand are read from the database for use in the calculation.

Some companies want to base component demands on a leveled MPS. This can be accomplished by setting the average demand for the finished goods items (MPS items) manually. The average demand for these items would be set to the leveled MPS quantity, and these items would be excluded from the selection for the average demand calculation. Since the logic in the system uses the parent item average daily demand in the calculation, this has the effect of creating component demands based on the leveled MPS.

When the template specifies both historical and future days, the system performs the same calculations individually. It then combines the total historical demand with the total future demand, and divides this by the total number of days to get the average daily demand.

Safety stock is a type of buffer inventory that guards against running out of stock during the time it takes to replenish a supermarket’s regular inventory. For example, it is useful when actual usage exceeds forecasted demand. However, because a key lean manufacturing principle is to reduce inventory to the lowest practical level, accurate safety stock calculations are required to avoid excessive buffer inventories.

See Supermarket Information.

When you choose a method other than Manual, the system calculates safety stock based on the safety stock template specified in Kanban Master Maintenance. Set up templates in Demand Calc Template Maintenance (17.1.6) and associate a template with each kanban loop in Kanban Master Maintenance. You can then update safety stock using Safety Stock Calculation. Additionally, the system automatically updates safety stock based on related modifications and calculations in one of the kanban workbenches or Historical Buffer Evaluation.

With this method, you can enter a quantity of items that you want to maintain as safety stock. Alternatively, enter the number of days of average demand required. The system calculates the safety stock level by multiplying this number of days by the calculated average demand.

With this method, the system calculates a standard deviation of average demand over the number of days in the planning horizon, which is the total number of historical and future days specified in Demand Calculation Template Maintenance. It then multiplies this demand by a service factor associated with the specified service level.

The service level is the percentage of time that inventory for this item will typically not run out before the replenishment time has been reached. For example, 50.00 means that 50% of the time, you will run out of this item before there is time to restock. Higher numbers mean that the supermarket maintains more inventory for the item in the form of safety stock.

With the peak method, the system calculates the average demand for each n‑day period within the planning horizon defined in Demand Calculation Template Maintenance, where n is the value specified in Peak Average Days. Safety stock is based on the highest average demand during an n‑day period

The size of a kanban does not have to be the same as the order quantity. To provide the agility to respond quickly to demand changes, the order quantity is typically set to a multiple of the kanban replenishment card quantity.

When you define kanban loops using Kanban Master Maintenance, you can set up accumulators to combine quantities from multiple kanbans—automatically authorizing production based on a cumulative quantity, an amount of time expired, or a schedule. See Card Tracking Information.

In a manual environment, this would be the equivalent of accumulating cards in a slot and defining a rule to prohibit production until the specified number of empty cards is returned, until a certain amount of time has expired, or only on specified days of the week—assuming that the order quantity has been met.

Run Accumulator Monitor (17.6.6) to automatically authorize cards based on time and schedule parameters. See Monitor Accumulator Quantities.

Controlling the card’s active status lets a planner temporarily increase a kanban’s supermarket buffer and at the same time define when that buffer can be reduced again.

Use Kanban Card Maintenance (17.3.1) or Kanban Multi-Card Maintenance (17.3.2) to define one or more limited-use cards for a kanban loop. Additionally, if you use the Increase Cards in Loop function of Kanban Card Management (17.3.16), you can specify limited-use parameters for the new cards. See Managing Kanban Cards.

While a limited-use card is active, the system automatically updates the working buffer size for the loop to account for the additional kanban quantity. See Working Buffer.

Kanban transactions convert visual replenishment signals to electronic signals. Kanban transactions track the movement of components into the production process and the movement of final products out of the production process. In a more controlled environment, transactions can also track material at a finer level; for example, as items pass along FIFO lanes between process operations.

When materials or components are required in the production process, they are pulled from raw material inventory or received directly from an external supplier. At the end of the production process, final products are transferred to finished goods inventory where they are available for shipment.

Depending on the life cycle of the kanban and how you choose to control the workflow within your plant, kanban transactions can be processed in several modes. The system creates a kanban history record each time you record a card. The card is assigned a status, shown in Kanban Status, based on where in the cycle the transaction is recorded. See Record Kanban Transactions.

Kanban Transactions summarizes the available transactions and where in the cycle they are used.

When items are consumed and corresponding kanban cards are recorded using Kanban Consume/Post, you can send a replenishment order in the form of a dispatch list to replace what was used. When items are produced as part of a FIFO process, you also can generate dispatch lists for cards recorded using Kanban Ship to authorize production by a subsequent FIFO process. You also can produce a report on cards that have already been included on a dispatch list. See Generate Dispatch Lists.

Optionally, you can use EDI eCommerce to export the dispatch list to the loop supplier in electronic data interchange (EDI) format. See EDI eCommerce.

Based on Kanban Control and Kanban Master Maintenance settings, you can control whether the system requires cards to be recorded in a specific sequence using the programs on the Kanban Transactions Menu. See Using Kanban Transactions.

Sequence enforcement functions assume the following expected transaction sequence for replenishment loops:

For move loops, the expected sequence is:

When enforcing sequences, the system uses this order of transaction events to determine the expected event, based on the current transaction being recorded. It then determines the actual transaction from card detail records. If the expected and actual transactions are not the same, the system uses the enforcement level associated with the expected transaction to determine whether to accept the transaction, display a warning message, or issue an error. The system checks for error-level enforcement settings first; if none are defined, it then checks for warning-level enforcement.

Enable sequence enforcement on the system level by setting Replenishment Sequence Enforcement or Move Sequence Enforcement to Yes in Kanban Control. You also use Kanban Control to set the enforcement level for each type of transaction. Depending on the value of Use Control Prog Tran Settings in Kanban Master Maintenance, the system either enforces sequences based on the Kanban Control settings or uses loop-specific values.

Sequence enforcement is controlled on three levels:

If you do not record transactions at certain steps in the kanban life cycle—for example, when your company does not record acknowledgements from suppliers—set the sequence enforcement level for that transaction event to None.

Based on the source type and control settings for the kanban loop defined in Kanban Master Maintenance, the system can automatically generate inventory and backflush transactions when the kanban is recorded in Kanban Fill/Receive.

Specific transactions depend on the source type:

Some programs that display inventory transaction history records, such as Transactions Detail Inquiry (3.21.1), include the card ID in the Remarks field for kanban transactions. You also can use the view programs on the Kanban Transactions Menu (17.6), which display both kanban and inventory transaction history.

If you do not record inventory transactions at the same time as kanban transactions—Impact Inventory is No in Kanban Master Maintenance—the inventory represented by full kanbans and the actual on-hand balance at inventory supermarket locations can be significantly different.

Based on related loop parameters, you can use Inventory Validation Report (17.6.13) to identify loops with potential problems that might require you to verify the card status or perform a cycle count. See Generating Reports.

Inventory transactions created when you process a kanban card using Kanban Fill/Receive also result in GL transactions.

Item movements for inventory kanbans:

Production receipts for process kanbans:

To provide consistency with standard cost-creation functionality, order quantities are based on item master values rather than those in the kanban loop record.

You can define inventory accounts for product line, site, and location combinations in Inventory Account Maintenance (1.2.13); for consignment accounts, use Purchasing Account Maintenance (1.2.5). Otherwise, the system uses the default accounts set up by product line in Product Line Maintenance (1.2.1).

When inventory transactions affect more than one site, costs may differ between the two sites. Cost variances are posted to the Transfer Variance account defined for the item product line and site in Inventory Account Maintenance, if available. Otherwise, the account defined for the site in Site Maintenance is used. The system automatically generates the appropriate balancing transactions in the GL for each site.

You can use the view programs on the Kanban Transactions Menu to review the GL transactions that were created with a card was recorded.

When the number of cards shown in Kanban Master Maintenance is not the same as the actual number of active cards, you can have the system bring the loop back into balance by adding or removing cards.

When you reconcile cards from one of the workbenches, use Move Card Sizing to specify how move cards in two-card loops are adjusted when replenishment cards are reconciled.

The programs also let you print any cards that were created or activated as part of reconciliation.

For customers who want to size externally and still use the auto reconcile features, the solution is to set the Maximum Buffer field for the loop so that it includes all the cards they have created.

You can use QAD’s advanced electronic data interchange (EDI) module, EDI eCommerce, to exchange kanban-related information with loop suppliers. You can: