Type III: Capability Inversion — The Haribo Story
This is Episode 10 of The Coherence Effect. If you're new here, start with Episode 01.
EVERYDAY ANALOGY Signing up for a marathon before you can run a 5K isn’t inspiring — it’s a setup for injury and withdrawal. The race is real. The training foundation isn’t there yet. You can’t build the base and run the race at the same time and expect either to go well. Organizations do this with every major system implementation that assumes capabilities the organization hasn’t built yet.
In October 2018, Haribo — the German confectionery company that has been making gummy bears since 1920 — began converting sixteen candy factories across ten countries to SAP S/4HANA. Some of those factories were running systems from the 1980s. The need to modernize was real. The strategic case for consolidation was legitimate. The intent was sound.
Within weeks of go-live, the company couldn’t track raw materials or inventory across its own manufacturing network. Shelves went bare at supermarkets across Germany. Sales of the Gold Bear — Haribo’s signature product and the reason most people have ever heard of the company — dropped 25 percent in 2018.
The post-mortem produced a familiar list of causes: poor testing methodology, insufficient executive engagement, inadequate planning, processes incompatible with the software. All of it true. None of it the actual diagnosis.
Here is what the post-mortem missed.
Haribo had been operating sixteen factories in ten countries, each running separate regional systems, some decades old, managing more than 1,500 product variants across a complex multi-country manufacturing and distribution network. That is not a simple operating environment. It carries high operational complexity, heterogeneous process legacy, and significant data integrity risk across every facility simultaneously.
SAP S/4HANA is a capable platform. It was never built as an out-of-the-box fit for Haribo’s specific operational complexity. The assessment that should have happened before vendor selection wasn’t a question of whether SAP was good software. It was a question of whether the build-buy-partner model Haribo was about to commit to — a single platform, simultaneous multi-country deployment, on a compressed timeline — was matched to the actual risk and complexity of what they were delivering.
It wasn’t. The platform was chosen because it was the industry standard, and Haribo was among the first companies in Germany to roll out the full S/4HANA feature set at once. The capability model was selected on the basis of technology reputation and competitive positioning — not on a rigorous assessment of whether that model could deliver in this specific environment against this specific risk profile.
This is what I call Type III coherence failure — Capability Inversion. The organization treats delivery capability as a function of technology selection rather than as a co-equal dimension with its own structural requirements. The assumption is that if you choose the right platform, capability follows. It doesn’t. Capability asks whether your build-buy-partner model is matched to your actual operational complexity and your actual risk tolerance. When that question is never asked — when capability is subordinated to the strategy layer’s preference for a particular solution — you cannot execute your way out of the mismatch. More discipline, better testing, stronger governance: none of it addresses a model that was wrong before the first line of configuration was written.
The diagnostic signature of Type III failure is subtle and consistent.
The organization experiences delivery failures it can’t explain through performance metrics. Vendors are underperforming, but the data doesn’t show why. Technology investments aren’t returning expected value, but the gap can’t be located in any specific failure of execution. The same problems recur in different forms across different vendor relationships or platform implementations, and each recurrence gets treated as a new execution problem rather than as evidence of a structural mismatch in the capability model.
The corrective response is always more rigor — better contracts, tighter SLAs, stronger governance, more comprehensive testing. These interventions aren’t wrong. They’re applied to the wrong problem. When the capability model is mismatched to the operational environment, execution discipline can’t close the gap. You need a different model, not a better-run version of the wrong one.
Haribo’s problem wasn’t that their testing was inadequate, though it was. Their problem was that they had selected a deployment model — simultaneous multi-country go-live with a platform still proving its own implementation maturity — that was structurally misaligned with the complexity of their manufacturing environment. No amount of testing would have resolved that mismatch. The right corrective would have been a different sequencing of the deployment: a pilot in a single facility, an honest assessment of whether the S/4HANA implementation ecosystem in 2018 had the maturity to handle what Haribo was asking of it. Those are capability model questions, not execution questions.
Industry post-mortems of the Haribo failure converged on a similar root cause: Haribo’s international manufacturing and supply chain expansion had outpaced what its SAP transformation was actually built to support. That’s a model mismatch diagnosis. The transformation was never matched to the future-state operating model. The platform was selected before the operating model was defined.
I have spent thirty years working with organizations on exactly this failure mode — often in circumstances where the vendor relationship had already been signed and the model mismatch was only becoming visible through delivery underperformance. The conversation in those circumstances is always the same: the client wants to know how to fix the vendor. Better governance. Tighter accountability. Escalation protocols.
The honest answer is that you cannot govern your way out of a model mismatch. The vendor is underdelivering because they’re being asked to deliver something the engagement model was never designed to support. The conversation that should have happened before contract execution — what does our operational complexity actually require, and is this model capable of meeting that requirement — is now a much more expensive conversation to have.
The organizations that avoid this failure mode do one thing differently. They treat the capability assessment as a separate, prior step from vendor selection. Before any platform is named, before any vendor is invited to present, they ask: what are we actually trying to deliver, what does our operational environment require, and what build-buy-partner model is matched to that requirement given our actual risk tolerance? Only after that question is answered does vendor selection begin.
That sequence feels slow. It is significantly faster than the alternative.
The question for you: think about the last significant vendor relationship or technology investment your organization made. Was the capability model — the build-buy-partner decision — assessed independently of the platform selection? Did someone, before any vendor was in the room, map your operational complexity against the delivery model options and ask whether there was a match? Or did the platform selection happen first, driven by industry reputation or competitive benchmarking, with the assumption that capability would follow from the right choice of technology?
If the answer is the second — if the model was never independently assessed — the question isn’t whether you have a capability problem. The question is when it becomes visible enough to name.
The Coherence Effect — Series Guide
Phase One — Human Foundation
01 · You Already Know This. You Just Haven’t Named It Yet.
02 · The Piano Man
03 · The Porch
04 · No Deck Required
05 · Why I Built This
Phase Two — The Framework
06 · Your Diagnosis Is Probably Wrong
07 · Your Organization Isn’t Broken. It’s Incoherent.
Phase Three — The Case Studies
08 · Type I: Intent Subordination — The Boeing Story
09 · Type II: Dimension Collapse — The Peloton Story
10 · Type III: Capability Inversion — The Haribo Story
11 · Types VI & VIII: The $42M That Was Never Missing
12 · Type IV: We Don’t Do That
13 · Type V: Authority Diffusion
14 · Type VII: Structural Theater
Phase Four — Series Close
15 · What Comes After the Diagnosis
The OCI Diagnostic identifies which of the three structural dimensions is being treated as less than co-equal in your organization — and what that subordination is costing you per quarter. Start the conversation here.
The full research: https://doi.org/10.5281/zenodo.19456590
Kent Hallmann is the founder of PrecisionPath Consulting — the diagnostic instrument for the Coherence Problem. Thirty-five years diagnosing organizational friction at Deloitte, KPMG, Wipro, and SAP. Fixed fee. Defined scope. Senior practitioner on every engagement — no handoffs, no substitutes.
Next episode: Type III — Capability Inversion. An analogy about signing up for something before you’re ready for it. And a case study about what happens when a ninety-eight-year-old company runs a technology implementation that the technology itself wasn’t ready for either.Where is your organization carrying a Capability Inversion right now?