Procurement Lessons from the Zimmer Biomet SAP S/4HANA dispute

Gartner’s 2024 survey found that, on average, only 48% of digital initiatives meet or exceed their business-outcome targets. That finding is more useful than the familiar slogan that digital transformation projects simply “fail”. Most programs do not collapse completely. They underdeliver against the benefits used to justify the investment.

Large ERP programs rarely miss those benefits in a single dramatic moment. They gradually decompose through hundreds of decisions that appear reasonable on their own: another change order, revised date, SteerCo assurance that the remaining defects are manageable, top-up payment needed to keep the program moving.

We selected the Zimmer Biomet SAP S/4HANA program because it is recent, commercially significant, and unusually well documented through company disclosures, litigation, and subsequent analysis. More importantly, it demonstrates standard failure causes rather than a technical accident: an immature baseline, repeated scope change, unstable delivery resources, weak links between payment and operational readiness, pressure to go live, and dependency on the incumbent during remediation and exit.

The same case also exposes the prerequisites for success. A defensible business case, mature scope, accountable client ownership, stable supplier capability, evidence-based acceptance, independent go-live assurance, and a usable exit route must be there before the program becomes operationally irreversible. These are not administrative controls around the transformation. They are part of the transformation design.

That is why the dispute between Zimmer Biomet and Deloitte deserves attention from IT and technology procurement leaders. The core question is not whether SAP S/4HANA is a good product, or whether either party will eventually win the court case. The procurement question is practical: when did the customer lose their program control, and how should the contract have safeguarded the parties?

Procurement creates the greatest value before delivery becomes urgent. Once the program is late, operationally disruptive, and integrator-dependent, most contractual provisions become reactive channels for documenting problems rather than preventing them.

What is established and what is still disputed

Zimmer Biomet is a global medical technology company with over 8 billion USD in annual revenue in 2025. Reuters reported that management expected the ERP problems to reduce annual revenue by roughly one percentage point and that the company lowered its 2024 outlook. That was still before the legal dispute.

On 4 September 2025, Zimmer Biomet filed a complaint against its IT integrator, Deloitte, and sought at least $172 million. They alleged fraud, breach of contract, negligent misrepresentation, and deceptive trade practices. According to the complaint, Deloitte overstated its capabilities, staffed the work inadequately, over-customized the solution, generated repeated change orders, and supported a go-live that produced serious operational disruption.

Deloitte disputes the customer's position and states that it served the client diligently, delivered a modern system, obtained approvals during the program, and invoiced in line with the agreed contractual structure.

At the time of writing, we could not verify a final judgment or settlement. Therefore, the allegations or defense arguments should not be presented as findings of fact.

The commercial story behind the technical story

Public reporting and analysis of the court filings describe an ambitious program aiming to:

• consolidate multiple legacy systems,

• implement SAP S/4HANA across core finance and supply-chain processes,

• create substantial long-term benefits.

  
  

The initial work order was reportedly worth about $69 million. The complaint describes 51 change orders adding approximately $23 million, repeated movement of the planned go-live, and further remediation expenditure. Those numbers attract attention, but the underlying reasons matter more than the totals.

Seven Procurement Lessons

This is not only a contract-management problem. It begins with sourcing strategy and continues through the entire commercial lifecycle. We tried to identify seven procurement lessons based on the public information.

1. A trusted supplier is not a substitute for a market test

Long relationships can reduce transaction costs and accelerate mobilization, but they can also weaken competition. Even when an incumbent is the logical choice, the buyer should test the delivery model, price, resources, assumptions, and implementation risk against credible alternatives.

It looks like long-standing relationships between parties predetermined Deloitte to deliver the transformation program.

2. The business case is there to survive the contract

A transformation business case may promise hundreds of millions in benefits, but procurement, finance, or PMO should trace every material benefit delivered (not just promised).

3. Change control begins with scope maturity

Fifty-one change orders may indicate adverse selection, inadequate or missing discovery, genuine business change, weak project team decisions — or a combination thereof.

Whichever the reason, change orders aren't made to patch holes in a poorly-defined scope. The number and magnitude of those should've alerted both the project team and a budget controller, if there was one.

4. Pay for deliverables, not elapsed time

Milestones should correspond to material deliverables that reduce project risks. Retention and holdbacks are not punishment; they preserve leverage until the buyer receives the result it contracted for.

5. Contract for the delivery team, not merely the supplier brand

The branded proposal does not deliver the program. Named experts in the project team do. Contracts should define key personnel, minimum experience, location and time commitments, continuity expectations, approval rights for replacements, knowledge-transfer obligations, and consequences for unapproved substitutions.

Offshore delivery is not inherently a problem. Uncontrolled turnover and shared yet weak accountability are.

6. Go-live is a business decision supported by independent evidence

An integrator has a natural interest in reaching go-live, while the client has to manage the operational consequences. The go/no-go decision should therefore sit with the customer and be based on independent assurance across process, data, controls, integrations, performance, security, support capacity and business continuity.

7. Negotiate the exit while the relationship is healthy

The contract should specify transition periods, service continuity, access to environments and documentation, knowledge and IPR transfer, cooperation with a replacement provider, treatment of disputed invoices, license and tool rights, data return, and rates for additional assistance. A supplier should not gain new leverage simply because the customer is too engaged to consider alternatives.

What not to conclude from the case

It would be easy to turn this story into a warning never to use a large systems integrator, never to customize SAP, or never to go live before every defect is closed. None of those conclusions is useful.

Large integrators can mobilize global expertise and absorb complex delivery risk. Customization can be justified where it protects a genuine competitive or regulatory requirement. Every go-live carries the punch list of open issues.

The commercial question is whether the deviations were understood, priced, governed, and consciously accepted — and whether the customer retained a safe alternative when the evidence changed.

Nor should customers pretend they can transfer all transformation risk to the supplier. ERP delivery depends on client data, process ownership, timely decisions, testing, change adoption, and operational readiness. A good contract makes those responsibilities visible and reciprocal.

The procurement decision test

The Zimmer Biomet dispute will be debated as an SAP case, a Deloitte case, and an ERP-governance case. For procurement, it must be above all a lessons-learned case.

A strong technology contract should make the right behavior easier before a crisis: disclose delivery risk, retain the right people, surface the real cost of change, prove delivery before payment, and support an orderly transition if confidence collapses. If the commercial model does not do those things, procurement has bought activity rather than an outcome.

The final test is simple: at each critical decision, could the customer say “not yet”, “not good enough” or “we will move to another provider” without creating a larger operational threat to itself? If the answer is no, the program may still have governance, but the customer no longer has control.