The Bee Hive

System complexity, an inherent element of most modern production and inventory control systems, creates a plethora of direct and indirect costs. To attack complexity, the manager must attack its effects and then identify and address root causes.

Complexity shows up in excess inventory, increased lead times, and falling quality levels (yields). Lets be clear, though, about one thing. There is nothing wrong with complexity if that's what the customer - especially the critical customer - wants and is willing to pay for. But complexity is wrong if it results from our attempts to satisfy customer demand at all costs or from our tendency to view and attack problems in isolation without drawing on past solutions.

Complexity and Inventory

Inventory is a major lightning rod for any firm today. We look for excess inventory, monitor inventory levels, and experience the periodic push to reduce current inventory levels. In my previous articles, I have shown that inventory provides a number of functions (e.g. safety, decoupling, anticipatory, transit, lot sizing, and seasonal). Reducing inventory means identifying the functions served by inventory and then eliminating the need for those functions. This approach, however, is insufficient when dealing with inventory as a result of complexity. We often find that the functions fulfilled are quite valid, yet we simply have too much inventory.

To attack inventory resulting from complexity, we must identify and eliminate redundant and near-duplicate inventory. Our goal is simple - to preserve our ability to meet the functions provided by inventory, but to do so at lower levels.

Identifying and Eliminating Redundancy

By redundant inventory, we mean items that are identical in every way but the part number. I have seen numerous examples of redundant inventory. In one firm, the same item was given three different SKU number depending on the vendor from whom the item was purchased. Small orders were placed with each vendor rather than placing one large order with a single vendor. And why three SKU numbers? There has been a recent consolidation in purchasing. The purchasing functions, which had been decentralized at the various plants, were now centralized. Each purchasing group had bought its items from different vendors. When the purchsing function was centralized, the existing SKU numbers were simply thrown into the same database, thereby reducing any potential benefits resulting from centralization. In another case, the design process resulted in engineering essentially reinventing the same parts with different part numbers because the people involved were unaware the part had been previously designed.

In one statistic that I recall, up to 20 percent of part numbers in a typical manufacturing firm are duplicates and up to 50 percent are near-duplicates. These are strong indicators of complexity. 

There are various tactics for attacking redundancy (duplicate part numbers). We could develop and implement a part coding system that is incorporated into the part/item master and then simply look for those parts that have different part numbers but are identical in function. We could talk to people who work with inventory and ask them if they know of any substitutes, either identical or near-identical. We could pick a major category of inventory and take a sample of 100 part numbers and look for redundancies. Our goal is to identify the scope of the redundancy. It is our experience that opportunities for redundancy are the greatest after a consolidation activity (e.g. centralization of purchasing), the introduction of a large number of new products, phasing in or out numerous products, or a change in supplier.