| The 4th Quadrant: Where Backflushing Works
In this article I will describe the manufacturing environments that are best suited for the use of Backflush inventory transactions. Many companies have decided to use the backflush transaction as a cornerstone of their implementation design. When a backflush transaction is performed, the quantity of the part being made is scanned or entered into the system. Then the component parts are automatically inferred and consumed using information from the bill of materials (BOM). This second step of consuming the component parts is done without any data entry or scanning, so it results in a tremendous reduction in the number of transactions entered. Inventory transactions divert precious man-hours and are also a source of errors when entered incorrectly or late. Therefore reducing transactions through backflushing is a very good idea, if transactions can truly be reduced using this method without losing inventory accuracy. Without accurate and timely inventory levels, internal production plans and external purchase orders cannot be scheduled effectively, leading to inventory shortages and excess inventory. Inventory shortages cause disruptions to the manufacturing schedule, forcing additional setups, forced substitutions, overtime, premium freight charges, missed shipments and lost capacity. Excess inventory increases obsolescence, and consumes precious cash flow and shelf space. Both excess inventory and shortages can indirectly lead to poor quality. A plant cannot cycle-count its way to accurate inventories. Cycle counting is not timely enough to be of benefit. And cycle counts are more likely to introduce errors than to correct them. When a part is manufactured, received, consumed, or scrapped, the count of that part in the system must reliably change quickly to reflect the new reality. In central Stores it is also desirable for the location identifier to be updated when parts are moved. The ERP inventory transaction design describes how all inventory transactions are captured, preferably in a highly predictable, transparent, and automated way. The design must ensure that all occurrences of scrap, non-standard usage, and substitution in the real world are quickly and reliably reflected in the system. - - - When thinking through an ERP implementation, it is best to start with a design of inventory transactions and technologies that meet the goal of accurate and timely inventory levels. Then this design is tested to ensure it also delivers other objectives, e.g.: customer-labeling requirements, and capturing and presenting quality and efficiency data. As changes in the inventory transaction design are made to meet secondary goals, the altered design is carefully re-evaluated for its retention of inventory accuracy and timeliness objectives. Another design objective may be to implement multiple manufacturing facilities with the same implementation design. This should also be carefully verified to make sure that inventory accuracy will not suffer at a plant whose processes differ from the other plants. Planned vs. Unplanned Transactions: Planned inventory transactions are those entries that occur at fixed-points in the manufacturing cycle, e.g. every time parts are moved into or out of stores to or from the manufacturing floor, or every time a full container of parts is automatically scanned as it comes out the end of a manufacturing cell. These transactions are designed to be self-correcting; an error is automatically made right at the next stage. An unplanned inventory transaction is detected and reported on an exception basis, often without the aid of technology. These transactions are part of the ERP software package, but have not been implemented in a rigorous enough manner so the transactions are captured routinely. These transactions are not self-correcting. Responsibility for capturing them is often given to personnel not equipped with proper training or part number lookup/transaction entry tools, or whose motivation is to ignore the need for the transaction entirely. These transactions are often missed, reported with an incorrect part number or quantity, or are entered into the system in an untimely manner, often the next day. For any implementation design to work, unplanned inventory transactions must be eliminated and replaced creatively with planned transactions because even a very low percentage of misreported transactions will take inventory accuracy quickly to an unacceptable level. - - - A plant must have two traits to implement backflushing without unplanned inventory transactions. Both traits must be met to realize the savings in transactions while maintaining inventory accuracy. Only those facilities with both traits should consider using backflushing. For the rest, there are alternatives to deliver inventory accuracy without enslaving the plant in a transaction quagmire.
When parts are made, one backbflush transaction is used to report the produced part. No reporting is done on component parts. This one transaction serves to both increase the quantity on-hand of the produced part, and relieve the inventory of all the component parts. Component part numbers and quantities-per are taken from the standard bill of material (BOM). This represents a huge savings over the traditional method of a) issuing component parts one at a time, usually to a discrete work order, b) receiving the finished parts into inventory, and c) returning any unused components, one at a time, back into inventory. Note: with backflushing, the components are not consumed until after the produced part is reported complete. Also note that only the STANDARD BOM used. Any scrap, material usage variance (using more or less than specified in the BOM) or substitution must be reported separately. These are typically implemented as unplanned transactions. Backflushing therefore only works when both of the following conditions are met: A) Low variation in component usage from the standard bill of material as evidenced typically by:
B) Short manufacturing lead times, i.e.:
Facilities with both of the above traits may with confidence elect to implement backflushing to report production quantities and relieve component materials. These facilities are those found only in the 4th quadrant, below.
Without low part I/O variation through low scrap, non-standard usage, and substitution, system inventory levels become unreliable. The exception transactions just cannot come through quickly or accurately enough to tame the beast. Loss of trust in the system occurs. Without short manufacturing lead times, components get moved into production but don’t get relieved right away from the ERP inventory. This leads to confusion. Evident discrepancies between physical and system inventory counts cause frustration and lack of trust in the system. In the 4th quadrant, backflushing requires fewer resources than the alternatives. In the other three quadrants, backflushing becomes expensive as the transaction savings evaporate due to unplanned inventory transactions, and/or lack of inventory visibility due to long lead times. The resulting inaccurate inventory levels often lead directly to a dependence on cycle-counts. Cycle counting is an expensive process that often introduces as many errors as it corrects. If the nature of a manufacturing process is such that component usage variation is natural and unavoidable, and/or production lead times are long, an ERP implementation design that entails a different methodology than backflushing is required. Following are two examples of possible alternatives to backflushing. Alternate Methodology I: Dual issues and returns against discrete work orders. Components are counted when issued to a work order from Stores when the work order is opened. Produced parts and leftover components are counted when returned to stores when the work order is closed. In conjunction with a tightly controlled material Stores with discrete storage locations, this can deliver very high inventory accuracy without the need for additional transactions to report scrap, material substitution, and non-standard usage separately. This obviously requires more transactions than backflushing. But these can be automated in a variety of ways, especially since most transactions take place in a limited area (Stores) and not throughout the plant. Accountability for component usage and operator time/efficiency at the work-order level by operator/shift/cell is greatly increased in this method over backflushing. Work orders also deliver higher lot-control quality measurement potential, substitution management (through a modified work-order BOM) and higher part and customer container bar-coding accuracy. For these reasons even a manufacturing plant in the 4th quadrant may choose this methodology over backflushing for its increased accountability and accuracy. Alternate Methodolgy II: Simple issues and returns from Stores. Components are counted and issued to the floor without reference to a work order. Leftover components and produced parts are returned to Stores. Accountability for component usage by operator, shift, and cell, etc., is lost, but inventory accuracy, especially within Stores, is achieved. Note: This may be a good first-phase implementation. The cost savings obtained through accurate inventory levels can be used to invest in a more sophisticated methodology such as I, above. Or it may be possible to obtain secondary measures such as operator accountability or scrap using other means, keeping the ERP/Inventory system simple, transparent, and accurate. Self-Correcting: In both of the above, parts are counted dually in Stores, i.e.: when put away into a discrete location, and again when issued out of that location in Stores. This also occurs when the parts are counted twice at receipt, first in Receiving, then when put into a discrete location in Stores. Ideally an automated counting procedure such as weight-counting is used for increased accuracy, reduced handling and to produce an automated barcode label for each internal container. Therefore both of the above alternatives to backflushing have the potential to be fully self-correcting. On the other hand, backflushing by its very definition can never be self-correcting and should only be used when corrections are rarely needed. Scrap: An objection can be made with both of the above alternatives that scrap is not reported with a reason code, or broken out separately from other forms of non-standard usage. But how accurate is scrap reporting in an environment without inventory accuracy? Better to settle for inventory accuracy and worry about scrap later as a separate issue. Option: implement a separate scrap analysis protocol unrelated to inventory transactions. Scrapped parts are segregated for subsequent inspection, quality data recording and possible rework. In both alternates above scrapped parts are already removed from inventory at the end of the manufacturing cycle (presumably by returning fewer components to Stores). Therefore an inventory transaction is only needed when parts are deemed acceptable upon inspection, or after a rework operation is performed. Lean: Without 100% visual inventory systems, Lean requires extremely high inventory accuracy. If visual inventory systems cannot be implemented due to space limitations, then an inventory transaction design as discussed above is essential to maintain very high levels of inventory accuracy. If visual systems are used however, perpetual inventories should often be be turned off. Why pretend to maintain perpetual inventories when they are not necessary? With perpetual inventories turned off, MRP demand levels are true gross requirements. This is very useful as data to be transmitted to suppliers or used internally for long-term planning. Kan-ban signals are used for short term requirements. Long term planning based on exploded demand is not possible with inaccurate perpetual inventories. So it is better to turn off the perpetual inventories and use the MRP demand as gross-requirements, assuming accurate BOMs and customer/independent demand levels. Please feel free to contact me if you have any questions.
Joseph Drouillard |
|
|