Software Inventory and the “Finished Goods Warehouse” Dysfunction

As a strapping young lad, I worked for my Dad’s management consulting firm “on location”. I happened to work at a firm that made a very, very exciting product – metal drawer slides (booyah!). In its simplest form, this product has exactly 3 parts: 2 pieces of metal (bent, punched and painted) and 1 nylon wheel that gets pressed onto one end. This firm did not suffer from lack of customers or an oversaturated competitive landscape, but this firm was clearly struggling. So why were we there?

For starters, they did not really understand their entire business from end to end. They hadn’t given thought to an integrated supplier network. Partnership with the people that actually shipped their products, raw material suppliers, etc? – Uh, no.

I will write at length about the menagerie of issues they encountered in another post, but for now, let me describe ONE of the symptoms those issues caused – a massive finished goods warehouse. The warehouse housed actual finished products, buffer stocks of every product sku, and much more. It also housed huge quantities of production product runs that weren’t to spec, or were sent back from drawer manufacturers in large quantities because they “didn’t fit”. It also contained blems, discontinued product lines, and more buffers.

At first blush, I’d guess this seemed like a pretty good idea. How else would they ensure they had enough product on hand to ship to customers at a moment’s notice? Not only that, it took 2 full days to retool the machinery and powder coating bays to get ready for new product runs. So, while they had their most popular models running, they decided to build extra units to ensure they were being efficient, and didn’t have to retool the machines (and waste all that time). So, they did what many manufacturing firms did. They built a massive finished goods warehouse. When they ran out of space, they built it bigger. In my estimation, they’d run out of space 3 or 4 times before we got there.

Imagine their surprise (and mine) when the first thing I was asked to do was to take 5 friends from the shop floor and start “recycling” mass quantities of finished goods, old parts, blems, etc. It was a horrible job. It felt like I was on an episode of “Hoarders – Enterprise-style”. We gutted that warehouse over the next weeks and months, leaving one “relatively” tiny section in the back corner near shipping and receiving for storage.

Why would we do that?

Let’s start with how firms look at excess inventory and why they manage it the way they do. How firms view excess inventory often determines the practices they employ to manage it. Excess inventory, in many manufacturing firms, is viewed as:

• An Asset (because it is listed on the left side of the balance sheet)
• A Stock buffer – “insurance” for demand fluctuations
• Insurance for production problems (scrap, incorrect bills of material, shortages, on the floor engineering changes)
• Some also view it as efficient use of resources. After all, BIG BATCHES are more efficient, right?

So what’s the real impact of excess inventory? Many companies view costs as simply the cost of borrowing money to finance and build the excess inventory. The true costs are significantly higher and include the following:

• Holding costs (cost of capital, warehousing, lost items, theft, damage, insurance, physical inventory counting)
• Product Obsolescence – finished goods are at heightened risk of becoming obsolete or unneeded
• Opportunity costs (missed sales)
• Delayed shipments due to order fulfillment issues and growing complexity – sometimes requiring expeditors

When all costs are considered, most companies find that inventory costs are in the 25 percent to 35 percent per year range. Yikes. This warehouse became a dumping ground for an out-of-control process. It was simply waste, but no one understood it. They didn’t have an idea of its true cost, how to rectify it, or how to eliminate it.

So how does this relate to Software Development?

If you look closely, there are obvious parallels in the software development space. The most obvious is related to the “large batch efficiencies” firms think they get in specifying software in advance. This one is fairly obvious to most, as requirements and “intended solutions” age and become obsolete. This causes an entire raft of dysfunctions from the waste of refactoring old and outdated specs, to the worse problem of massive and onerous change control processes that tend to drag projects out for months or years (and sadly products are built that no one wants or needs). What a waste!

If we dig a little deeper, many organizations (like mine) have adopted Lean principles and are attempting to build “flow” and “pull” into our processes and teams. We construct Kanbans to visualize that flow. By in large, this simple visual approach allows us to “see” bottlenecks at every steps in our process. This is HUGE because we can now take action to remove the bottleneck and get prodcuts to flow.

Interestingly, it ALSO allows us to see where we build “buffer stocks” and “finished goods warehouses” in the value stream. These buffers are often NOT acted on as we rationalize away the dysfunctions as “necessary” to our big batch mentality. This is why it’s important to challenge the need and inspect why you have them.

My opinion: Sometimes software-centric “finished goods warehouses” ARE necessary, but mostly they are built to cover up an out of control process that no one understands, all under the guise of “big batch” efficiency.

What we are trying to teach now, and what teams need to start to challenge themselves to understand, is that a “buffer stock” or “finished goods warehouse” can create the very same dysfunctions in your development processes as bottlenecks. It hinders flow, hides issues, and can create massive waste.

So….you are seeing the bottlenecks. Can you find where you build “buffers” or “warehouses” and explain why you need them? Do your kanban boards display excess inventory anywhere – even if you made an active decision to put it there? Is it more important to have them in the process than building flow? Are you building those things into the process to avoid another issue?

Leave a Reply

Your email address will not be published.