The September 2025 lawsuit filed by Zimmer Biomet against their implementation partner seems like a case study in how ERP projects go wrong. A $172 million claim for a premature SAP S/4HANA go-live. Fifty-one change orders totaling $23 million beyond the original baseline.

This is not a new story. National Grid spent $585 million cleaning up a 2012 SAP implementation that went live before it was ready. Waste Management sued SAP for $500 million after being promised software that didn’t exist yet. The names and vendors change. The pattern holds.

Development and integrations are no longer the primary constraint because modern ERP platforms like Dynamics 365 Finance & Supply Chain Management have more functionality than ever before. You can fit the system to the business process in ways that would have required custom code a decade ago. That bottleneck has largely moved.

The three things that still cause implementations to drag or fail entirely are data, people, and scope.

Data migration and data quality. This one is consistently underestimated. When you’re talking about hundreds of thousands of products with bills of materials and routes, data is almost always worse than expected when you get into it. Cleansing, transforming, and validating that data to meet the requirements of the new system takes time. There is no shortcut. The data has to be right before go-live, or you are setting yourself up for failure.  In fact an implementation I’m close to, has recently postponed by a year just to get the data right.

Organizational readiness and change management. Many implementations default to a train-the-trainer approach. In theory, this scales. In practice, it puts enormous pressure on people who may not be skilled teachers, and who are already stretched by their day jobs, and who are being asked to train their peers on processes that are themselves still changing and learning. The critical work: understanding the current state process, defining the future state, identifying what is actually different, and standardizing before training anyone is frequently underfunded or rushed. When change management gets cut from the budget, it does not save money. It defers the cost to post go-live, where I find organizations taking months, maybe years, to become efficient in the new system.

Scope creep. Scope changes show up disguised as legitimate business requirements. Sometimes it is. Often, the right answer is to go live with the agreed scope and revisit once the dust settles. Organizations frequently cannot see what they actually need until the system is running. Trying to solve for everything upfront extends the project, adds cost, and introduces complexity that makes the go-live harder.

Given that framing, the right question is not how AI makes implementations faster. The right question is how AI reduces the risk of failure.

AI can help with data quality work: identifying inconsistencies, flagging records that will not pass validation, accelerating the cleansing process. That directly attacks one of the primary failure modes. AI can generate test scripts, accelerating coverage for standard scenarios. It can produce fit/gap documentation faster so the team spends less time on paperwork and more time on configuration decisions that actually matter.

AI should be used to help in assessing organizational readiness and assist in training employees- to reduce the risk of going live before the people are ready to adopt the process and software.

These are practical applications reducing risk. Some may also reduce time. But that is a secondary benefit, not the goal.

When AI takes over a task, you have to evaluate what the human who used to perform that task does instead. If that person redirects their time to higher-value work on the same project, that is a real gain. If they simply have fewer tasks and fill the gap with lower-priority work, the project timeline and cost may not change at all.  This is where I question companies claiming a 40% reduction in implementation timeline.

Some roles are required regardless. A full-time project manager is a full-time project manager. Automating some of their administrative tasks does not eliminate the need for the role. However, it might mean they spend more time on risk identification and stakeholder communication, both of which reduce risk. But it does not come off the invoice as direct savings.

Not all AI applications on ERP projects will reduce timeline or cost. Some will reduce risk without moving either number. That is still a good outcome. But it is a different claim than “we will deliver your implementation 20-40% faster,” and organizations evaluating partners who make that promise should push on the specifics.

What part of the project is faster? Which failure modes does that address? What happens to the hours AI frees up, and who carries that benefit?

Roughly 55-75% of ERP implementations miss their original objectives. That number has not moved much despite significant advances in technology, methodology, and tooling over the past two decades!  Let that sink in.

The failures are not primarily technical. They are organizational. Data quality, change management, and scope discipline are people problems wrapped inside a technology project. AI can help, however it is not the answer.  These are people projects, not technology projects.