New functionality within Microsoft Dynamics AX incorporates lean manufacturing constructs, thereby providing a single system that supports lean and traditional manufacturing practices. This primer focuses on constructs that support basic variations in lean practices and briefly touches on more complex variations.
The lean manufacturing application supplements the existing version of Microsoft Dynamics AX 4.0, which has been described in the book Managing Your Supply Chain Using Microsoft Dynamics AX (Hamilton, 2007) and in the following excerpts: Microsoft Dynamics AX 4.0 for Distribution Environments and Microsoft Dynamics AX 4.0 for Manufacturing Environments. The description of lean manufacturing functionality uses system-specific terminology for functions, window titles, and field labels as much as possible. However, alternative phrasing or synonyms are sometimes used to clarify meaning and ensure understanding. It is assumed the reader has some familiarity with the lean philosophy and such terminology as kanbans.
Kanbans support coordination and execution in lean environments, and provide a logical starting point for further explanation. Containers provide the simplest conceptualization of a kanban, where each container has an identifier, and an empty container signals the need to replenish material for a specific item and quantity.
Kanban Policies and Kanban Tickets
Kanban policies and kanban tickets differentiate two key contexts for kanbans. Kanban policies govern creation and behavior of kanban tickets. A kanban ticket for an empty container signals the need to replenish an item, and reporting the receipt of a kanban ticket updates the item's inventory balance. The status of a kanban ticket indicates whether the container is empty or not.
Kanban policies are defined for an item and a specified inventory location. A subset of these policies concerns replenishment and the creation of kanban tickets. They represent an alternative approach to item coverage policies within Dynamics AX, and are not employed in planning calculations. Another subset of these policies concerns the behavior of kanban tickets. For example, the impact of reporting completions of a manufacturing kanban ticket can vary in pull-to-order (PTO) environments, since the ticket can be directly linked to a sales order. That is, the completion can update the item's inventory balance and optionally update the activities associated with picking, shipping, or invoicing the sales order. PTO represents a special case of make-to-order (MTO) manufacturing environments, with kanban tickets providing linkage to sales orders and acting as the primary coordination tool.
Kanban tickets are commonly called kanbans, and each kanban is uniquely identified by a kanban ticket ID. Other synonyms for the identifier include kanban order number, replenishment order number, or container ID. The system-assigned kanban ticket ID consists of a prefix and counter. The basic information for a kanban ticket includes the kanban ticket ID, the item number and description, the quantity and unit of measure, the required date, and the “to location” for placing the received material. Basic information also includes the vendor for a purchased kanban and the work cell for a manufactured kanban, as shown in the two examples displayed in figure 1. Component information may also be displayed on the ticket for a manufactured kanban. A kanban ticket can be printed or displayed electronically.
The kanban quantity and the number of kanbans represent basic replenishment policies for creating kanban tickets for stocked material. For example, a fixed number of kanbans, such as three, would result in three kanban ticket IDs after creating the kanbans, each for the specified kanban quantity. A newly created kanban ticket represents an empty container that requires replenishment. The following sections further describe the kanban policies regarding replenishment.
Overview of Kanban Replenishment Policies
A kanban's replenishment policies are defined for an item and a specified inventory location. A basic framework for replenishment policies consists of the item origin and the differences between replenishing kanbans (for stocked material) and non-replenishing kanbans (for material required by a sales order), as displayed in figure 2. The user can prepare information about an item's kanban policies, and (when appropriate) flag it as “active” so that kanban tickets can be created.
The item origin can be purchased, transferred, or manufactured. The item origin determines the nature of information for kanban policies and the nature of kanban ticket transactions.
- Purchased kanban—Replenishment policies specify a vendor and a blanket purchase order. The blanket purchase order must be previously defined for the item and location. Once a purchased kanban ticket has been created (with a status of “pending”), it communicates the need for replenishment and must be confirmed with the vendor (status of “supplier confirmed”) prior to recording receipt. Confirmation can be via a vendor portal or screen. After recording a material receipt for the purchased kanban ticket (status of received), Dynamics AX creates a new purchase order that reflects a release against the blanket purchase order, and performs a receipt for the specified quantity. Once a container associated with the kanban ticket has been emptied, the status changes back to “pending.”
In addition to the individual kanban tickets, coordination tools include a kanban purchasing screen that displays purchased kanbans requiring further action. Filtering helps focus attention on a specified vendor, required date, or status such as “pending” or “supplier confirmed.” The screen supports printing of the kanban ticket, changing of the kanban status (for example, to a status of “supplier confirmed”), and recording of the kanban receipt.
- Transfer kanban—Replenishment policies specify the “transfer-from” location and the type of transfer journal for recording transfers. Once a transfer kanban ticket has been created (with a status of “pending”), it communicates the need for replenishment and can be reported as received. After recording a material receipt for the transfer kanban ticket (status of “received”), Dynamics AX creates a transaction for the specified quantity in the transfer journal, and posts the journal. Once a container associated with the kanban ticket has been emptied, the status changes back to “pending.”
In addition to the individual kanban tickets, coordination tools include a kanban transfer screen that displays transfer kanbans requiring further action. Filtering helps focus attention on a specified required date, or the source or destination location. The screen graphically displays whether available inventory exists at the source location (via a green hand or red hand icon), and supports the printing of kanban tickets and the recording of kanban ticket receipts.
- Manufactured kanban—Manufactured kanbans apply to items produced internally as well as to items with a subcontracted operation as described below. In both cases, replenishment policies specify the work cell that produces the item. A work cell (also termed a cell) represents a new construct different from the work centers defined in Dynamics AX, and it has an assigned calendar of working hours.
Once a manufactured kanban ticket has been created (with a status of “internal order”), it communicates the need for replenishment. After recording completion of the manufactured kanban ticket (status of “received”), Dynamics AX creates a production order and a report-as-finished transaction for the specified quantity. This approach builds on Dynamics AX functionality without the additional complexity associated with production order transactions, while facilitating existing reporting functions. Once a container associated with the kanban ticket has been emptied, the status changes back to “internal order.”
In addition to the individual kanban tickets, coordination tools include a kanban manufacturing screen that displays manufactured kanbans requiring further action. Filtering helps focus attention on a specified work cell or required date. The screen graphically displays whether available inventory exists for components (via a green hand or red hand icon) and supports the printing of kanban tickets and the recording of kanban completions. The user can also assign the kanban ticket to a different work cell. A kanban stop-and-go board provides a second coordination tool, since it graphically displays the kanbans waiting to be produced at a specified work cell. A graphic comparison between calculated and prescribed takt time provides a third tool, since it indicates how well the cell is doing.
A work cell can have an associated production schedule, which provides an additional coordination tool. It displays the items, quantities, and required dates of manufactured kanbans being produced at the cell, and supports the recording of kanban completions. Production schedules represent a new construct, and each one is uniquely identified by a production schedule identifier. A production schedule defines the items covered by the schedule, and policies that determine scheduling logic, display characteristics, the behavior of manufactured kanbans, and so forth.
For example, one policy determines whether a PTO kanban is directly linked to the sales order (where the quantity and due date match the sales order), or it represents the sum of sales order demands for the same item and date. Other policies determine how scheduling logic handles the cell's drumbeat, where the drumbeat reflects the available capacity expressed in the number of equivalent units that can be produced per day. Each item assigned to the schedule may consume a different amount of capacity, which is expressed as a ratio of equivalent units. A ratio of two, for example, means that production of the item will consume twice as many drumbeats. The drumbeat ratio concept represents an alternative approach to using routing operations for indicating required capacity. Further explanation of production schedule policies merits a separate article, and falls outside the scope of this primer.
Manufactured Kanbans and Subcontracted Manufacturing
Manufactured kanbans also apply to an item with a process step performed by a subcontractor, where material is supplied to the vendor. Using kanbans for subcontracted manufacturing requires supplemental information in the policies for the manufactured kanban. These policies include the vendor, the inventory location associated with the vendor, the item that represents the outside operation and its cost (termed a payment item), and the blanket purchase order for this item. An additional policy indicates whether the subcontracted manufacturing represents the only step in the manufacturing process (the simplest case), or an intermediate or final step in a multistep manufacturing process. In the simplest case, a kit of components is sent to the vendor, and the completed parent item is received via the manufacturing kanban completion.
Once a manufactured kanban ticket has been created (with a status of “internal order”), it communicates the need for replenishment. The components must be sent to the vendor (a status of “sent to contractor”), and then the receipt of the manufactured kanban ticket can be reported (status of “received”). Upon receipt, Dynamics AX creates a production order, the pick list transactions for components, and a report-as-finished transaction for the specified quantity. It then deletes the production order. The primary coordination tool (termed the subcontracting kanban screen) displays manufactured kanban tickets after components have been sent to the vendor, with filtering based on the supplier. The screen supports the printing of kanban tickets and the recording of kanban receipts.
Replenishing versus Non-replenishing Kanbans
A replenishing kanban refers to stocked material, whereas a non-replenishing kanban refers to material required to satisfy a sales order. In either case, an empty kanban signals the need for replenishment. With replenishing kanbans, an empty kanban may stem from material usage transactions, such as shipments or auto-deduction. An alternative approach is to manually report the kanban as empty. With replenishing kanbans, the number of kanbans for an item can be fixed or variable.
- Fixed kanban—A fixed number of kanbans represents the simplest replenishment policy, and also reflects a stable demand pattern. Fixed kanbans reflect a variation of min-max replenishment logic. The kanban quantity reflects an order multiple, with separate orders for the fixed number of kanban tickets. The quantity for a single kanban, or a user-specified number of kanbans, can act as the minimum quantity triggering replenishment.
- Variable kanban—Variable kanban approaches can be used to handle changing or seasonal demand patterns. Dynamics AX supports several variable kanban approaches, as illustrated by the following examples.
- Demand-sensitive kanban (dynamic kanban)—A kanban flagged as having a dynamic replenishment policy allows the system to automatically update the number of kanbans to reflect the sales order backlog. The forward analysis calculations consider sales orders with delivery dates in a specified time period, and can either suggest changes or automatically update the number of kanbans. The number of kanbans will be increased or decreased to align with the sales order demand.
- Temporary kanban—Temporary kanbans provide one approach for handling periods of higher demand. They can be defined when kanban replenishment policies already exist for a specified item and location. The supplemental replenishment policies include a kanban quantity, the number of kanbans, and a date range of effectivity, which provide the basis for creation of the temporary kanbans. A temporary kanban does not require action until the starting date within the effectivity range.
- Phased target kanban—A phased target kanban provides one approach for handling inventory build-up in anticipation of seasonal demand. The replenishment policies for a phased target kanban consist of a kanban quantity, a total target quantity, and a detailed breakout of target dates and target quantities (or percentages) to achieve the total. For example, a total target quantity of 1,000 may have a detailed breakout of 100 on January 1, 200 on February 1, 300 on March 1, and 400 on April 1. These replenishment policies provide the basis for creating kanbans with required dates that correspond to the detailed breakout.
- PTO kanban—The PTO kanban policy indicates that kanban tickets are only created for sales order line items. The kanban ticket is termed a “PTO kanban,” and the statuses consist of “PTO created” and “PTO completed.” Dynamics AX designates the sales order linkage in several ways:
The pull-to-order policy can apply to a purchased, transfer, or manufactured kanban.
- The prefix for the kanban ticket ID consists of the sales order number and line number.
- The sales order line item identifies the status of the kanban ticket.
- Changes to the sales order quantity and shipment date automatically update the kanban ticket information.
This is the first of a two-part series on Lean Manufacturing Using Microsoft Dynamics AX. The next part will present three case studies to illustrate the use of kanbans.
About the Author
Dr. Scott Hamilton has consulted with more than a thousand companies worldwide and has conducted several hundred executive seminars on supply chain management (SCM) and enterprise resource planning (ERP) issues. He also helped design three influential ERP software packages. His books include Maximizing Your ERP System and the APICS CIRM textbook on information systems for manufacturing, and previous books on Microsoft Dynamics AX and Dynamics NAV. Hamilton can be reached at ScottHamiltonPhD@aol.com or at 612-963-1163.
For more information and to start your own custom solution comparison, please visit