Primer on Lean Manufacturing Using Microsoft Dynamics AX Featured Author - Dr.

Scott Hamilton - August 27, 2007 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 items 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 items 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 kanbans 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 nonreplenishing kanbans (for material required by a sales order), as displayed in figure 2. The user can prepare information about an items kanban policies, and (when appropriate) flag it as active so that kanban tickets can be created.

Item Origin 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 kanbanReplenishment 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 kanbanReplenishment 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 kanbanManufactured 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-andgo 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 cells 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-asfinished 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 kanbanA 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 kanbanVariable 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.
o

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 kanbanTemporary 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 kanbanA 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 kanbanThe 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:
o o o

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.

The pull-to-order policy can apply to a purchased, transfer, or manufactured kanban. 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. Part II: A Primer on Lean Manufacturing Using Microsoft Dynamics AX: Case Studies A lean manufacturing environment employs kanbans for coordinating and executing material replenishment. The definition of kanban policies governs the creation and behavior of kanban tickets, as described in part one of this series (please see A Primer on Lean Manufacturing Using Microsoft Dynamics). Case studies provide one approach for understanding how kanbans support variations in lean practices, including the case where a work cell has demands stemming from kanbans and production orders.

For more background, please see excerpts from the book Managing Your Supply Chain Using Microsoft Dynamics AX (Hamilton, 2007): Microsoft Dynamics AX 4.0 for Distribution Environments and Microsoft Dynamics AX 4.0 for Manufacturing Environments. Case Study #1: Pull-to-order Environment This first case study illustrates usage of various types of kanban tickets described in the previous part of this series. In this case, the replenishment policies for the end item reflect a pull-to-order (PTO) manufactured kanban, whereas replenishing kanbans are used for the components. 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. The case study involves a two-level product structure to build the end item, identified as Product #1 in figure 1. The left side of figure 1 depicts the product structure in terms of the bill of material (BOM) and routing. A final assembly cell produces Product #1 to sales order demand, and completed items are placed in a shipment staging area for subsequent shipment. Production of Product #1 requires Subassembly #1, Part #1A, and other purchased components. These purchased components are stocked next to the final assembly cell, with receipts direct to the location. An inventory location on the factory floor is commonly called a floor stock location or a supermarket location. The right side of figure 1 depicts the factory layout in terms of cells and inventory locations.

Subassembly #1 is produced to stock in the subassembly cell, using Part #1B and other purchased components. These purchased components are first received in a stockroom, and then transferred to the floor stock location next to the subassembly

cell. Completions of Subassembly #1 are placed in the final assembly floor stock location. Purchased kanbans provide the basis for replenishing purchased material stocked in the stockroom and the final assembly floor stock inventory locations. A purchased kanban acts as a signal to the vendor, and the kanban receipt transaction updates the items inventory balance. Transfer kanbans replenish the floor stock inventory for the subassembly cell with material transferred from the stockroom. A transfer kanban acts as a signal to the stockroom, and the kanban receipt transaction transfers inventory between the two locations. The left side of figure 2 depicts these kanban signals and the associated kanban receipts.

sales order line item for the end item (Product #1) requires realistic delivery promises to help align demands with available capacity. Delivery promises can be based on the planning calculation logic within Dynamics AX. In this case, the delivery promises for a manufactured item with PTO kanban policies can also be based on available capacity of the associated final assembly cell. A shipment schedule coordinates shipping activities. A manufactured pull-to-order kanban is generated automatically for the end item (Product #1). The PTO kanban can be directly linked to the sales order (where the quantity and due date match the sales order), or the PTO kanban can represent the sum of sales order demands for the same item and date, depending on policies associated with the production schedule for the final assembly cell. This PTO kanban acts as a signal to the final assembly cell, and displays on the cells production schedule. In this case study, the kanban completion transaction updates the end items inventory balance (in the shipment staging area location), and auto-deducts the component inventory (in the final assembly floor stock location).

A manufactured kanban for Subassembly #1 replenishes the floor stock inventory for the final assembly cell. In this case study, the kanban completion transaction updates the subassemblys inventory balance (in the final assembly floor stock location) and auto-deducts the component inventory (in the subassembly floor stock location). The work cells production schedule provides a second coordinating tool for manufactured kanbans. The policies associated with the production schedule affect scheduling logic. For example, the production schedule of manufactured kanbans can be adjusted to reflect interspersed production of various items, such as producing some of each item throughout the day rather than producing the entire kanban quantity for one item before producing the next kanban. This concept is termed heijunka scheduling. The shipping schedule displays sales order line items that need to be shipped, along with information about the item, quantity, ship date, kanban status, and the associated production schedule. This information supports close coordination between shipping and production, since shipping has visibility of completed and in-process production. Case Study #2: Multilevel PTO Environment The second case study illustrates usage of PTO kanbans for the final assembly cell and the associated feeder cell or cells. This case study uses the same two-level product structure shown in figure 1, and the only difference in figure 2 would be the use of a manufactured PTO kanban for the subassembly cell. The relationship between a cell and its feeder cells (termed an assembly structure) must be predefined in order to support multilevel PTO environments. The assembly structure typically reflects portions of the multilevel BOM where the manufactured component employs PTO kanbans for coordination. Case Study #3: Kanbans for a Stocked End Item The third study illustrates usage of replenishing kanbans for the end item, with inventory stocked in a finished goods location. However, PTO kanbans are used to transfer inventory from the finished goods location to the shipment staging area for subsequent sales order shipment. The transfer PTO kanbans act as the basis for picking the stocked end item. The unique characteristics of this case study are shown in figure 3 and described below.

A sales order provides the starting point, where the sales order line item identifies the shipment staging area as the ship-from location. The kanban replenishment policies for this end item and staging location reflect a PTO transfer kanban so that it is replenished from the finished goods location. The use of a template minimizes the effort to define these replenishment policies for every end item. If there is insufficient finished goods inventory, a manufactured PTO kanban can be automatically generated so that the final assembly cell produces the item. The shipping schedule displays the status of these PTO kanbans, thereby supporting closer coordination of shipping, finished goods inventory, and production. Supporting Lean and Traditional Manufacturing Practices The lean manufacturing application provides new constructs that supplement the Microsoft Dynamics AX functionality so that a single system can support lean and traditional manufacturing practices. Item replenishment can be based on kanban policies or the item coverage policies employed by AX planning calculations (such as period lot sizing logic). For example, some firms have introduced lean into a specific product line, while other product lines employ production orders. Another example involves the introduction of lean for final assembly, while subassembly operations employ production orders. Other examples include

A work cell produces items stemming from kanban and production order demands, typically during the transition period from traditional to lean. The production schedule for this work cell can incorporate kanban tickets and planned production orders, and can support reporting of kanban completions and production order completions.

It is possible to employ both sets of replenishment policies for the same items so that kanban policies coordinate actual replenishment while delivery promises, projected material, and capacity requirements can be based on planning calculations. Projected requirements based on planning calculations can be used to calculate the kanban quantity and number of kanbans for an item.

The lean functionality significantly simplifies the complexity of transaction reporting in comparison to traditional approaches. A typical purchase order receipt in Dynamics AX, for example, requires creating the purchase order, identifying the purchase order during receipt, recording a receipt quantity within delivery tolerances, and determining what to do when the received quantity does not match the ordered quantity. With kanban tickets, the receipt transaction only requires the identification of the kanban ticket and quantity. The simplification is even more apparent when comparing transaction complexity between production orders and manufactured kanbans. Concluding Remarks This primer on lean manufacturing for Microsoft Dynamics AX explained how to handle some of the variations in lean practices. It covered the definition of kanban policies that govern the creation and behavior of kanban tickets. Kanbans and their replenishment policies act as alternatives to the use of planning calculations and item coverage policies, and to the use of planned orders and action messages for coordination and execution purposes. Several case studies highlighted the variations in lean practices and the use of kanbans. Kanbans and production schedules represent new constructs that supplement the Dynamics AX functionality so that a single system can support lean and traditional manufacturing practices. The new constructs also simplify transaction reporting and system usage, thereby contributing to the elimination of waste. This concludes the two-part series on Lean Manufacturing Using Microsoft Dynamics AX. 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.