Deloitte's $175M SAP Failure
When ERP Fails, It’s Rarely “Just a Technology Problem”
Large ERP failures are far too routine. This is the case for various reasons, but pointing the finger at the software vendor isn’t always justified. ERP implementations are vastly complex; I’m not insinuating ERP implementations are easy to pull off. What I am interested in is that these failures seem to have a theme. Which is that as soon as responsibility is handed off, the project becomes difficult to manage.
According to public court filings, medical device manufacturer Zimmer Biomet filed a lawsuit in September 2025 seeking more than $170 million in damages related to a failed SAP S/4HANA implementation led by Deloitte. This is the pattern I’m talking about: ambitious transformation goals, a high-profile consulting partner, escalating costs, and a breakdown so severe that core operations were described as barely functional.
In this case, I won’t be dragging SAP S/4HANA through the mud. Although there is plenty of blame to go around. With that being said, SAP S/4HANA remains one of the most capable enterprise platforms on the market. These cases matter because they expose structural issues in how large transformations are governed. Even more importantly, they expose how accountability is allocated, and how risk accumulates until it becomes unavoidable.
What the Case Tells Us About How These Projects Break
Zimmer Biomet is an $8 billion global organization operating across more than 100 entities with a workforce exceeding 20,000 employees (about the seating capacity of Madison Square Garden). Like many companies at that scale, it was running a fragmented landscape of legacy ERP systems and turned to Deloitte to help define a unified path forward.
Following a ten-month assessment, Deloitte reportedly projected substantial net benefits from consolidating onto SAP S/4HANA. Based on that analysis, Zimmer Biomet entered into a $70 million licensing agreement with SAP and a master services agreement with Deloitte to support a phased rollout across North and Latin America.
Initial deployments were described as mixed. The more significant breakdown emerged in 2024 during implementations in Costa Rica, Brazil, Mexico, and Colombia, where the system allegedly failed to perform under real-world operating conditions. According to the lawsuit, defects in warehouse management disrupted the supply chain, restricted product flow, and triggered cascading impacts across revenue, customer fulfillment, and investor confidence.
The financial consequences outlined in the filings were severe. Zimmer Biomet has alleged more than $75 million in lost revenue, a $2 billion decline in market capitalization, and total payments to Deloitte exceeding $100 million. Remediation efforts reportedly included fifty-one change orders, pushing additional costs close to $94 million. At its lowest point, the organization described itself as barely operational.
By then, the issue was no longer the technology itself. The system had become the constraint.
Why Big Consulting Is So Difficult to Hold Accountable
What’s interesting to me isn’t necessarily the failure but what followed.
In November 2025, Deloitte filed a motion to dismiss, arguing that its work was governed by contracts that clearly defined scope, approvals, and deliverables. The defense wasn’t that problems did not occur, but that the work performed was contractually authorized, reviewed, and accepted at each stage of the project.
I feel it’s important to highlight that this is where many organizations underestimate their exposure.
Large consulting firms are designed to manage contractual risk, not outcome accountability. Invoices are tied to milestones. Milestones are tied to deliverables. Deliverables are approved within narrowly defined review windows. When issues surface later, the response defaults to documentation and sign-offs rather than the operational reality the system created.
That dynamic creates a persistent gap between what executives believe they are buying and what contracts are actually structured to enforce.
Assurances around minimal customization, preconfigured solutions, or top-tier staffing often live in conversations, proposals, and presentations rather than binding contractual language. When implementations unravel, those assumptions are difficult, and sometimes impossible, to hold accountable.
This does not mean organizations are without leverage. It does mean, however, accountability has to be designed intentionally.
The Hidden Cost of Go-Live Obsession
Another recurring theme in the allegations is the prioritization of a fixed go-live date over system readiness.
This is one of the most persistent and least challenged failure patterns in ERP implementations. Go-live dates are often treated as immovable commitments, even when testing exposes defects in core business processes. Once a date is set, it takes on a gravity of its own. Program optics, executive reporting, and contractual timelines begin to matter more than whether the system can actually support day-to-day operations.
In this case, the alleged defects in warehouse management and order-to-cash processes were not edge cases or isolated issues. They were foundational breakdowns in how the business moves product, recognizes revenue, and fulfills customer demand. Once the system went live, it reportedly constrained the supply chain instead of enabling it, turning what should have been a stabilizing platform into a source of disruption.
I’m going to say this loudly for the people in the back: a go-live date is not a business outcome! It is an internal milestone. When it takes precedence over quality, resilience, and process fit, it becomes a risk multiplier. The cost of delaying go-live is visible and uncomfortable. The cost of going live with a system that is not ready is often far greater, and it compounds long after the project is declared complete.
How to Change the Outcome
There are real, actionable lessons here for leaders responsible for overseeing large technology investments.
Contracts, first and foremost, must tie payment to business-level value, not simply task completion or time elapsed. A deliverable that technically exists but fails under real operating conditions should not be treated as acceptable or complete. If value cannot be realized in production, it has not been delivered.
Shared accountability must also be explicit. Risk cannot sit entirely with the client, while control sits with the integrator. Governance models need enforcement mechanisms, including clear remediation obligations when systems fail to perform as intended once live. Without that balance, accountability becomes theoretical rather than operational.
Customization should never be minimized rhetorically. ERP implementations are, by nature, exercises in aligning software to operational reality. Framing customization as trivial or avoidable sets false expectations and undermines informed decision-making long before the first line of code is written.
Finally, boards and executives need visibility into system readiness, not just project status. Defect trends, process stability, and operational impact should carry more weight than whether a timeline is being met. Progress reports that ignore these indicators provide comfort without control.
These changes do not eliminate risk. They surface it earlier, while it can still be addressed deliberately rather than absorbed reactively.
The Bigger Lesson
ERP failures at this scale are rarely the result of a single bad decision. They emerge from layered assumptions, misaligned incentives, and contracts that reward visible progress over actual performance.
Large consulting firms are not inherently the problem. The risk comes from treating accountability as implied rather than deliberately engineered into how the work is governed, contracted, and measured.
When governance is loose, documentation becomes the shield. When contracts are vague, outcomes become negotiable. And when leadership is disconnected from operational reality, warning signs surface only after the cost of ignoring them has already compounded.
This case is still unfolding, and the courts will ultimately determine how responsibility is allocated. Regardless of the legal outcome, the lesson is already clear.
Transformation does not fail quietly. It fails expensively.
If this raised questions, sparked disagreement, or reflected challenges you have seen firsthand, I would genuinely welcome the conversation.
These are the kinds of failures organizations only get one chance to learn from.