u/jimmyray71

I’ve spent most of my career in supply chain, procurement and warehouses, and I don’t think I’ve ever walked into an operation that didn’t have at least one person who knew things the system didn’t.

They know which supplier will actually help when you’re in trouble. Which inventory number is probably wrong. Why we stock something differently. What happened the last three times receiving didn’t match the PO.

Some of that obviously needs to be documented. But I’m not convinced we can document all of it. A lot of it came from years of seeing problems, making decisions and remembering what worked.

The other side is pretty obvious too. If that person takes two weeks off and everything falls apart, we have a problem.

I’m curious how other supply chain people handle this. What knowledge do you insist gets documented, and what have you found just doesn’t transfer very well until somebody has lived through it?

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?

We spend a lot of time talking about better dashboards, alerts, forecasting and automation.

But I’m starting to think there’s a more basic question.

What happens after the system tells you something is wrong?

A late shipment gets flagged.

Inventory falls below the threshold.

A PO doesn’t match.

A truck is going to miss its window.

Everyone can see the exception.

But who owns it?

More importantly, what are they actually authorized to do about it without asking someone else?

I’ve seen technology improve visibility without improving the decision process behind it. The result is a better dashboard showing the same problem sitting there longer than it should.

Maybe the implementation order should be:

Process → Ownership → Decision Rights → Technology

Otherwise we may just be automating the waiting.

Curious how others handle this. When an exception appears in your system, is ownership already defined, or does the team figure it out when it happens?

I’ve seen plenty of contingency plans that looked great on paper.

Then something actually went wrong.

Everyone knew what the plan said, but nobody was quite sure who had the authority to make the decision.

Do we switch suppliers?

Expedite the material?

Move inventory from somewhere else?

Call the customer?

Spend the extra money?

And while everyone is figuring out who owns the decision, the problem keeps getting bigger.

It makes me wonder if a contingency plan without clearly defined decision authority is really a contingency plan at all.

When something goes wrong in your organization, is it clear who owns the immediate decision?

And maybe the harder question:

Does your culture reward someone for solving the problem, or punish them afterward for making the decision?

I've been thinking about how companies define a “backup supplier.”

Sometimes it means another supplier has been qualified and entered into the system.

But when was the last time they actually quoted the material?

Have you placed an order with them recently?

Do you know their current lead time and available capacity?

And if your primary supplier went down tomorrow, who actually has the authority to move the business?

I'm curious how others handle this.

Do you periodically place orders with backup suppliers to keep the relationship and process active, or is qualification enough until they're needed?

I've been thinking about how companies define a “backup supplier.”

Having another vendor's name in the system doesn't necessarily mean you can actually switch to them.

When was the last time they quoted the material?

Have you placed an order with them recently?

Do you know their actual lead time and available capacity?

If your primary supplier told you Monday morning they couldn't ship for 30 days, how long would it really take you to move?

And maybe the bigger question: who in your organization has the authority to make that decision?

I'm curious how others handle this.

Do you actively test critical backup suppliers with occasional orders, or is qualification enough until you actually need them?

I've been thinking about how companies define a “backup supplier.”

Having another vendor's name in the system doesn't necessarily mean you can actually switch to them.

When was the last time they quoted the material?

Have you placed an order with them recently?

Do you know their actual lead time and available capacity?

If your primary supplier told you Monday morning they couldn't ship for 30 days, how long would it really take you to move?

And maybe the bigger question: who in your organization has the authority to make that decision?

I'm curious how others handle this.

Do you actively test critical backup suppliers with occasional orders, or is qualification enough until you actually need them?

​

I've spent a lot of my career around supply chain, procurement, inventory and operations, and I've become increasingly skeptical of complexity for complexity's sake.

I've seen simple spreadsheets solve very expensive problems.

I've also seen companies invest in systems that provided significantly more data without necessarily helping people make better decisions.

I'm not anti-technology. Quite the opposite.

But I think there's a point where the question needs to change from:

"What can this system do?"

to:

"What decision will we make differently because of it?"

If a more sophisticated forecasting model improves accuracy, great.

If a WMS improves inventory control, great.

If AI identifies something people couldn't reasonably find themselves, great.

But if the operation doesn't have clean data, clear processes and someone who owns the decision, adding more technology may just give you a more sophisticated version of the same problem.

I'm curious where other supply chain people draw the line.

When has a simple solution worked better than the more sophisticated one at your company?

​

I've always thought procurement gets into trouble when we look at purchase price by itself.

A supplier offers 10% off for a larger order. Sounds good.

But now you've increased inventory, used warehouse space, tied up cash and taken on the risk that demand changes before you use it.

I've seen the same thing with lower-cost products. The unit price looks better, but increased usage, quality problems or additional handling can wipe out the savings pretty quickly.

For me, the question isn't:

"Did we get a better price?"

It's:

"Did we actually lower the total cost to the business?"

Curious how other procurement and supply chain people evaluate these decisions.

What costs do you think companies most often leave out of the equation?

I’ve been thinking about this after years of working in supply chain and operations.

When a process isn’t working, the conversation often turns pretty quickly to the system.

“We need a better ERP.”

“We need a WMS.”

“Our forecasting system isn’t good enough.”

Sometimes that’s absolutely true.

But I’ve also seen companies spend a lot of money improving the technology without answering some basic questions first:

Who owns the forecast?

Who owns inventory targets?

Who decides when supply and demand don’t match?

Who owns the exception?

And, probably most importantly, who actually has the authority to make the decision?

If those answers aren’t clear, I’m not convinced better software fixes much. Sometimes it just lets an unclear process run faster.

I’ve started looking at technology implementations differently because of this:

Process → Ownership → Decision rights → Technology

Not technology first.

For those of you who have been through ERP, WMS, MRP or planning-system implementations, I’m curious:

How much of the problem was actually the software, and how much was the organization around it?

After years in operations, I've found that many issues blamed on supply chain actually start somewhere else. Poor forecasting, unclear priorities, siloed communication, or inconsistent processes often create the downstream problems.

What's an example you've seen where fixing the root cause solved what everyone thought was a supply chain issue?

I’ve been thinking about the difference between measuring performance and actually managing it.

A metric can tell you where to look, but it cannot explain why the number moved. A lower productivity score could mean an employee is disengaged, but it could also mean the process changed, the work became more complex or the target was poorly designed.

The wrong metric can create the wrong behavior. People start protecting the number instead of serving the customer or improving the operation.

Personally, I would rather inherit a team with no metrics than one built around bad metrics. I can create useful measurements. Changing the habits and distrust caused by the wrong ones is much harder.

How do you determine whether a performance metric is actually helping your team?

I’ve been thinking about the difference between measuring performance and actually managing it.

A metric can tell you where to look, but it cannot explain why the number moved. A lower productivity score could mean an employee is disengaged, but it could also mean the process changed, the work became more complex or the target was poorly designed.

The wrong metric can create the wrong behavior. People start protecting the number instead of serving the customer or improving the operation.

Personally, I would rather inherit a team with no metrics than one built around bad metrics. I can create useful measurements. Changing the habits and distrust caused by the wrong ones is much harder.

How do you determine whether a performance metric is actually helping your team?

I've been thinking about leadership and something I've noticed over the years.

I don't necessarily trust leaders with perfect records.

I trust leaders who have made hard decisions, had something not work out, owned it, and learned from it.

Supply chain especially teaches this lesson because you are constantly making decisions with incomplete information.

You can have the best forecast, the best supplier, and the best plan, and something unexpected can still happen.

The question isn't: "Did you make a mistake?"

The better question is: "What did you learn, and what changed because of it?"

Some of the best leaders I've worked with weren't the ones who were always right.

They were the ones who could say: "I got that wrong. Here's what we're going to do differently."

Curious what others think:

What is a mistake or failure that ended up making you a better leader?

​

Currently mid-engagement on a warehouse/staging redesign for an electrical contractor who's also implementing ServiceTitan. Talked to a dozen ops folks in similar spots lately, and there's a pattern: everyone's optimizing dispatch software while their physical warehouse actively fights the new system.

Case in point — wire and cable racked with zero logic tied to job sequencing. Techs burning 20-30 min per morning just hunting for material before they even leave for the first call. That's not a software gap, that's a layout problem, and no amount of real-time job costing fixes it.

Curious if others have seen this — are you seeing software rollouts stall because the physical ops underneath weren't ready? What forced the fix (if anything)?

Walked into an operation recently where everyone on the floor knew the process was broken. Weeks of lost productivity. Shipments going sideways consistently.

Not one person had flagged it up the chain.

When I asked why, the answer was simple: the last person who raised a problem got blamed for it.

This comes up constantly in operations work. The systems get all the attention — WMS upgrades, layout redesigns, carrier audits. But the single biggest driver of sustained operational performance is whether your team actually feels safe surfacing problems early.

A few things I've seen work:

When bad news comes up, fix the problem first and ask how it happened second. Sequence matters.

Recognize the person who flagged it publicly, not just privately

Never let "how did this get so bad before anyone said something" go unexamined — that question usually reveals more than the problem itself

The operations that run well long-term aren't the ones with the best processes. They're the ones where people tell the truth fast.

Curious if others have run into this — what actually moved the needle for you on building that kind of culture?

Success isn't measured by how many fires you put out.

It's measured by the fires that never start.

When inventory is available, production runs smoothly, and customers receive their orders on time, most people never think about the work behind it.

That's okay.

Great supply chain leadership isn't about recognition. It's about creating resilient processes, building strong teams, and solving problems before they impact the business.

Looking back, I'm grateful for every challenge that pushed me to become a better leader.

What's the biggest lesson your career has taught you?

​

Success isn't measured by how many fires you put out.

It's measured by the fires that never start.

When inventory is available, production runs smoothly, and customers receive their orders on time, most people never think about the work behind it.

That's okay.

Great supply chain leadership isn't about recognition. It's about creating resilient processes, building strong teams, and solving problems before they impact the business.

Looking back, I'm grateful for every challenge that pushed me to become a better leader.

What's the biggest lesson your career has taught you?