Why Your New Supply Chain Tool Is Underperforming — and It Has Nothing to Do with the Technology

You bought the platform. You did the implementation. You paid for the training. Six months later, half the team is still running reports in Excel, the alerts the system generates are being ignored, and the vendor is suggesting you need a more advanced license tier.

The vendor is wrong. The problem isn’t the technology.

In food and beverage supply chains, the most common reason digital tools underperform isn’t a software failure — it’s an organizational one. The tool was deployed into a structure that wasn’t designed to use it. And until that structure changes, no license upgrade or additional feature will close the gap.

This pattern is more widespread than most leaders want to admit. Research consistently shows that 70% of digital transformation initiatives fail to reach their goals — not because the tools don’t work, but because the organizations around them don’t change. In food and beverage specifically, demand planning sits in one function, production scheduling in another, quality and traceability in a third — each optimizing for its own KPIs, often at the expense of the whole. When a new digital tool is dropped into that structure, it doesn’t fix the fragmentation. It computerizes it.

After three decades leading supply chain and digital strategy at The Coca-Cola Company, I’ve seen this pattern repeat more times than I can count. Here are the five organizational failures I see most often — and what actually fixes them.

Failure 1: Decision rights were never defined

A new traceability system, quality alert platform, or demand planning tool generates real-time signals. Someone needs to act on those signals — within a defined timeframe, with a defined escalation path, accountable to a defined outcome.

In most deployments, this was never agreed. The system fires an alert. Everyone can see it. Nobody owns it. The team defaults to waiting for a manager to decide, which defeats the purpose of real-time visibility entirely.

What actually fixes it: Before the tool goes live, map every signal it generates to an explicit owner. Not a team — a person. Define what action they take, within what timeframe, and who they escalate to if the signal exceeds their authority. This decision rights mapping takes a day. Skipping it costs months of underperformance.

Failure 2: The workflow around the tool was never redesigned

The most common pattern I see: a new system is deployed, training is delivered, and then everyone goes back to doing their job the same way they always did — but now they also log into a new system to pull the same reports they were already producing in spreadsheets.

The tool becomes an additional step rather than a better way to work. Adoption is technically high (everyone logs in) but value is essentially zero (nobody changed what they do based on the data).

What actually fixes it: Map the current-state workflow before deployment. Identify which steps the tool eliminates, which it changes, and which new steps it introduces. Every function that touches the tool needs a redesigned workflow — not just access to a login. This is process work, not IT work, and it almost never appears in a vendor’s scope of work.

Failure 3: KPIs still reward the old behavior

Supply chain, quality, and production functions are measured on individual metrics — cost per unit, throughput rate, defect percentage, on-time delivery. A new integrated planning or quality tool is designed to optimize system-level outcomes that often require individual functions to accept short-term cost in exchange for system-level gain.

When the performance review still measures the old KPIs, rational people make the rational choice: they optimize for the metric they’re measured on and work around the tool when it conflicts.

What actually fixes it: Align the performance measures with the tool’s intended outcomes before go-live. If the tool is designed to reduce total supply chain cost, someone’s KPI needs to reflect total supply chain cost — not just their function’s slice of it. This requires a conversation between functions and their leadership, which is uncomfortable, which is why it almost never happens.

Failure 4: The org structure doesn’t support the data flows the tool requires

Many supply chain digital tools — demand planning platforms, digital twins, integrated quality systems — are designed around cross-functional data flows. They only generate value when quality data, production data, supplier data, and commercial data are connected.

But most food companies are structured functionally, with walls between those data sets. The tool needs a supply chain director who has visibility and authority across quality, production, and procurement. Often, no such role exists. The data flows the tool requires run across reporting lines that don’t connect.

What actually fixes it: Before purchasing any tool, ask: what org structure does this tool assume? What cross-functional authority does someone need to act on the data it generates? If the answer requires authority that nobody currently has, you either need to create the role or accept that the tool will underdeliver. This is an organizational design question — and it belongs in the evaluation phase, not the post-implementation review.

Failure 5: Change management was treated as a training day

Companies budget carefully for software licenses and implementation services. They often add a training day and call it change management. But training on the software is not the same as changing how the organization makes decisions, resolves cross-functional conflicts, or defines accountability.

The real change — who loses authority when decisions get faster, which team now owns a signal they didn’t previously see, how disputes between functions get resolved when the system generates conflicting priorities — is rarely addressed. Within twelve months, the tool is used selectively, inconsistently, or not at all.

What actually fixes it: Treat change management as organizational redesign. Map the power shifts the tool creates. Name the accountability gaps. Design the conflict resolution mechanisms. Build the behavioral expectations into how performance is managed — not just how the system is used. This is harder than a training day. It’s also the only thing that actually works.

The six questions to ask before your next deployment

If you’re planning a digital tool deployment — or trying to understand why a current one isn’t delivering — these are the questions that determine whether it works:

1. What specific decisions need to improve, and how fast?
2. Who owns each signal the tool generates — by name, with a defined response window?
3. What workflows change, and for which functions?
4. What org structure does this tool assume — and do we have it?
5. What KPIs need to change to reward the new behavior?
6. What capability does the team need to use the tool as designed?

If those questions aren’t answered before go-live, the technology is almost irrelevant. If they are, almost any reasonable platform will deliver.

What this looks like in practice

The most effective digital deployments I’ve been part of spent as much time on the first four questions as on the technology selection itself. The vendor conversation came after the organizational design conversation — not before. The result was a tool deployed into a structure that was ready for it, with decision rights mapped, workflows redesigned, and performance measures aligned.

That’s not a technology project. It’s an operational transformation that happens to involve technology. The distinction matters.

How Stelytics can help

If your supply chain digital transformation is stalling — or you’re about to start one and want to avoid the most common failure modes — a focused digital readiness assessment is the right starting point.

In two to three days, we work through the six questions with your leadership team, map the organizational gaps that will undermine your deployment, and build the pre-conditions that make the technology investment actually deliver.

Cristian works directly with your team — no junior consultants, no 80-slide strategy decks. Just senior, hands-on work that gets your organization ready before the technology lands.