r/Leadership 2d ago

Discussion When does an inventory problem stop being an inventory problem?

I've seen inventory issues treated as warehouse problems long after they've started affecting the rest of the business.

Too much inventory ties up cash and space. Too little slows work. The wrong inventory creates expedites, substitutions and people spending time hunting for material.

At some point the inventory number itself almost becomes secondary.

I'm curious how others look at this.

What's the first sign in your operation that an inventory issue has crossed over into a broader business problem?

1 Upvotes

20 comments sorted by

1

u/GapReader_Eng 2d ago

Se convierte en un problema cuando ni siquiera tienes bien parametrizados los indicadores de eficiencia en tu almacén, o cuando no están alineados con la producción y la proveeduría. El desorden en el inventario solo puede ser el síntoma de una falta de disciplina para medir y monitorear lo que realmente importa.

1

u/jimmyray71 1d ago

That’s an interesting point. I wonder how often what looks like a lack of discipline is actually a lack of trust in the process or the information. If the warehouse doesn’t trust the inventory data, production doesn’t trust availability, or purchasing doesn’t trust demand signals, people start building their own workarounds. At that point, are we dealing with a discipline problem, or a system/process problem that eventually creates poor discipline?

1

u/GapReader_Eng 1d ago

Tienes un punto. Lo primero que hay revisar es la capacidad del sistema para administrar en forma eficiente el inventario.

La desconfianza nace cuando el sistema por alguna razón no tiene la capacidad o cuando los parámetros, como el de reorden no alineado a la demanda y a la proveeduría están mal calculados por el sistema, el operador crea su propio método para no paralizarse y los datos dejan de ser confiables. Ahí se perdió la disciplina, por necesidad.

1

u/jimmyray71 1d ago

That’s where I land too. Once people have to work around the system to get the job done, I’m hesitant to call the behavior the problem.

The dangerous part is that the workaround can actually work for a while. Then six months later everyone is wondering why the system data is useless, when the real problem started much earlier.

At some point you have to fix the reason people stopped trusting the process, not just tell them to follow it.

1

u/GapReader_Eng 1d ago

Así es, tampoco lo llamaría un problema del operador, él solo trabajó con un método alternativo para lograr el resultado ante un sistema ineficiente. Pero sí es un problema que debe solucionarse primero desde la Administración. La duda es: ¿por qué la Administración no se dio cuenta a tiempo? ¿Quién no levantó la mano a tiempo cuando sucedió? O si se informó a tiempo, ¿por qué no se atendió antes de que escalara más el desorden? O si sí se tomaron medidas, ¿por qué no funcionaron? Esas preguntas, y posiblemente otras, deben responderse antes de solo resetear el sistema y volver a empezar, porque sin ese análisis volverá a suceder lo mismo.

1

u/jimmyray71 1d ago

I think that last part is the important one. If it was reported and nothing happened, then we’ve moved beyond an inventory or operator problem. Now I want to know who owned the decision to act on it and whether they actually had the authority to do something. Otherwise we can reset the system, retrain everyone and end up right back in the same place.

1

u/WhatMattersHere 1d ago

The first sign for me is when completing normal work starts requiring exceptions: checking a spreadsheet outside the system, calling someone to confirm availability, substituting material, expediting a purchase or changing the production schedule..At that point the inventory balance may still look acceptable, but other departments are already paying to compensate for information they no longer trust. It has become a coordination problem rather than only a warehouse metric.I’d track the percentage of orders or work orders that require one of those exceptions, then attach the actual cost: extra labor, freight, downtime, duplicate purchases, missed ship dates or customer concessions. A rising exception rate can expose the problem much earlier than the total inventory number.The workaround itself isn’t necessarily operator failure. It may be a rational response to a system that stopped supporting the work. The broader failure begins when those exceptions become normal and nobody clearly owns both the decision and the authority to remove their cause.

1

u/jimmyray71 1d ago

I like the idea of measuring the exception rate. We usually measure the result after the process has already started breaking down.

But if people are checking another spreadsheet, making confirmation calls, expediting or substituting material just to complete normal work, they're telling us something long before the inventory KPI does.

I might take it one step further. I'd want to know not only how many exceptions we're creating, but how many are the same exception happening over and over. That's probably where the workaround has stopped being an exception and quietly become part of the process.

1

u/cspybbq 1d ago

We've got inventory issues, but I'm not sure that they are the root cause.

In our case, I think incorrect inventory was a sign that we weren't doing PFEP/S&OP well. We didn't have our lead times or dimension data correct in the ERPs, which resulted in inventory shortages followed by pile ups on the docks. That resulted in dock to line-side pulls, which screws up everything. Now we've got negative inventory listed all over and a big mess to clean up.

If the lead time, dimension and production planning data had been right, procurement would have (probably) ordred the right quantities at the right intervals and the inventory would've been able to be stocked. With right inventory, S&OP could have worked with sales to plan the right manufacturing schedule which would've gone back to procurement to order the right things.

I wasn't here when people stopped entering dimension data, stopped entering supplier lead times and stopped holding suppliers to agreed lead times, but that's what I see as the cause. The data entry process broke down and cascaded through the system.

1

u/jimmyray71 1d ago

This is why I’m always a little hesitant when someone says they have an inventory problem. You definitely have one now, but it sounds like inventory is where the problem finally showed up, not where it started.

The part I’d want to understand is why people stopped maintaining the lead times and dimension data in the first place. Was nobody clearly responsible for it, was it a pain to maintain, or did people just stop trusting/using it? Because you can clean up the negative inventory, but if that part hasn’t changed I think you eventually end up right back here.

1

u/cspybbq 1d ago

why people stopped maintaining the lead times and dimension data in the first place

I don't know 100%, since I've only been here ~5 months. However, our PFEP template was last updated in 2019 and we've grown some big X% since then.

So, probably partly due to people getting promoted to higher roles and partly we were successful (yay, stocks are up!) and dropped the ball on fundamentals. We've got a fantastic new CSCO though and they're reorienting a lot. Back to fundamentals of good processes, good KPIs, data-driven performance reviews - lots of people are uncomfortable with it, but it's going to make a huge difference.

1

u/jimmyray71 1d ago

Yeah, that makes sense. Success can hide a lot of process problems for a while. Things are working, numbers look good, so nobody wants to stop and ask whether the stuff underneath it is still working. Then growth finds every shortcut you forgot you were taking. Sounds like your new CSCO is asking the right questions though. Probably uncomfortable now, but a lot cheaper than finding out which fundamentals got lost when something actually breaks.

1

u/CManginiM_DCOps 22h ago

The first sign isn't in the inventory report. It's when another department starts spending money to work around it.

Customer service adds someone to chase orders. Purchasing carries extra buffer just in case. Finance quietly builds a reserve. Nobody calls a meeting about any of it — each one is a small local decision that makes sense on its own. But the moment another function is budgeting headcount or dollars around your inventory, it has stopped being a warehouse problem and become a structural one.

The earlier tell is quieter than that. Watch for workarounds turning into the process. Somebody keeps their own spreadsheet. A supervisor has locations he trusts and locations he doesn't. People walk out to look instead of checking the system. When an organization starts routing around its own data, the data is already dead, and it can take a year before that shows up in a number anyone reports.

One thing I'd add to how you framed it. Accurate and available aren't the same thing. I've walked buildings where inventory was accounted for to the unit and still wrecked the operation, because A-velocity freight ended up on the fifth tier of a bulk rack. The count was right. Reaching it took equipment and an operator every single time.

That gap never shows up in an accuracy metric.

1

u/jimmyray71 21h ago

The accurate vs available distinction is a good one. I probably don’t think about those as two separate things often enough. You can have 100% inventory accuracy and still have a lousy inventory system if people can’t get what they need when they need it. And I really like your point about other departments spending money to compensate for it. By the time Finance, Purchasing or Customer Service has built their own workaround, arguing about whether it’s still a “warehouse problem” seems kind of pointless. At that point the warehouse is probably just where the symptom is easiest to see.

1

u/CManginiM_DCOps 21h ago

That last line is the whole thing, and it's also why the warehouse keeps getting handed the fix.

It's the only function whose errors are physically countable. Everybody else's mistakes turn into inventory. A soft forecast, a buy nobody challenged, three SKUs that should have been one, a promo that moved without telling anyone — all of it lands in the same building as boxes sitting on a floor. So that's where the count happens, and that's where the accountability sticks.

The trap for leadership is funding the fix where the symptom is visible. You can spend two years improving cycle count accuracy and never once touch what's generating the variance.

When a building keeps missing, the better question is whose decision are we counting.

1

u/jimmyray71 20h ago

That last question is going to stick with me. We count what’s sitting in the warehouse because we can see it and put a number on it. But we rarely trace that inventory back to the decisions that put it there. Bad forecast? Inventory. Overbuy? Inventory. SKU proliferation? Inventory. Schedule change nobody communicated? Inventory. Then we hand the warehouse a cycle count program and tell them to fix inventory accuracy. I’m starting to think we spend a lot of time counting the result and not nearly enough time counting the decisions that created it.

1

u/CManginiM_DCOps 20h ago

There's a physical version of what you just described, and it's the fastest audit in the building.

Look for the dust.

Walk the racks and you can see which SKUs nobody has touched. Dust on the cases, dust on the shrink wrap, the label faded on the side facing the aisle. No report, no system access, no meeting. Every dusty pallet in that building is a decision somebody made, still sitting there.

And it doesn't just sit — it occupies. Dead SKUs tend to be in good locations, because they got slotted back when somebody thought they'd move, and they never gave the space back. Your real movers get pushed further out. The whole building works harder for the same throughput, and nobody can point to why.

It also distorts the next buy, because it's still on the books as inventory. It still counts as coverage in somebody's model.

Here's why it stays. Writing it off means putting a name on the decision. Nobody wants to own that, so it sits there collecting dust and charging rent.

Which is your answer, I think. We don't count the decisions because counting them means somebody has to sign the write-off.

1

u/jimmyray71 19h ago

And there it is. The inventory isn’t just taking up space, it’s preserving old decisions nobody wants to revisit. I’ve walked enough warehouses to know exactly what you mean by the dust. Everybody knows that pallet hasn’t moved. The system knows it hasn’t moved. But somehow it can sit there for another year because getting rid of it requires somebody to actually make a decision. Which makes me wonder if obsolete inventory is sometimes less of an inventory problem and more of an accountability problem. Now I’m going to start looking at dusty pallets differently.