Enterprise AI Adoption Hobbled by 1998 ERP Rollout Playbook

The argument: AI is being run like an ERP install

The usual explanation for why corporate AI is stalling points at the technology: weak models, messy data, old systems. A new argument from inside the management-research world points somewhere else. It says the trouble is the project template companies use to roll AI out.

Vibhas Ratanjee, who studies leadership and culture at Gallup, says many enterprise AI programs are built on a change-management method that took shape in 1998. That method was made for software that took about three years to install and then ran for roughly fifteen. AI, by contrast, changes meaningfully about every six weeks.1 He describes the typical AI program document as one most people in large companies would recognize: phases, workstreams with named owners, a center of excellence, a training curriculum, a communications plan, a rising adoption curve and a go-live date somewhere in the middle. With a different title, he argues, the same document could describe an ERP rollout from 2011.1

This piece takes that argument seriously. It is the most useful way to read the gap between what companies spend on AI and what they get back. But it is not the only explanation, and the evidence points to more than one cause.

How the ERP playbook was built

Ratanjee traces the method's history. Gartner analyst Lee Wylie named the ERP category in an April 1990 research note. SAP shipped R/3 in 1992. The ERP wave peaked late in that decade as companies replaced old systems ahead of Y2K.1 By 1998 the playbook was settled: blueprint, phase gates, configuration, training push, go-live, and a benefits review about eighteen months later.1

Every step depended on one assumption: the system would not change. Phase gates work only if the target stays put between them. Training works only if the tool people learn in March is the same tool they use in November. A benefits review needs a stable thing to measure.1 Ratanjee argues that pointing this method at a technology that keeps changing is a difference in speed of roughly two orders of magnitude, not a difference in style.1

He also connects the playbook to older ideas in change management. Kurt Lewin's 1940s model has three steps: unfreeze, change, refreeze. It ends by locking new behavior in place. In Ratanjee's account, the ERP method and classic change management grew up together. One installs a system that stays still, and the other fixes people's behavior around it.1

The most interesting part of his argument concerns a well-known 1998 critique. That year, Thomas Davenport wrote in Harvard Business Review that enterprise systems forced their own process logic onto the business. For years, the standard complaint about ERP was that it froze companies in place.1 Ratanjee says AI flips this. The software no longer freezes. The plan does, and it goes stale month by month while the technology keeps moving. Organizations end up stuck with an outdated picture of the tool rather than an outdated process.1

Training goes up, job expectations stay the same

Ratanjee backs the argument with Gallup data. In a survey of 102 chief HR officers at global Fortune 500 companies:1

• 62% are setting up centers of excellence or internal AI champions.
• 78% encourage peer learning and experimentation.
• 57% train managers on AI.
• Only 26% have written AI skills into job expectations or performance goals.
• Just 8% tie AI adoption to performance incentives.

Almost all of these leaders (99%) call AI important to strategy. Yet half say they have low confidence in their managers' ability to guide employees on using it.1 Ratanjee reads this as an accurate assessment of how little the organization itself has changed, not a judgment on the managers. A manager finishes training and goes back to a job description written before the tools existed, goals set the previous October and approval chains that still need three signatures.1 In his words: new capability, old machinery.

He illustrates this with a regional operations manager who has 18 direct reports. Her team started using AI tools as soon as they arrived. Months later, the official program reaches her unit and trains her on things she has been working out alone, using material written early in the program.1

The ROI numbers fit the argument

The argument lands at a time when doubts about AI returns are widespread. The most-cited figure comes from MIT's Project NANDA: 95% of generative AI pilots showed no measurable profit-and-loss impact.2 Commentators often use that figure to say the problem is structural, not a shortage of tools, and that most organizations ended up with faster individuals inside unchanged organizations.2 That is close to Ratanjee's point in different words.

Other surveys point the same way:

• BCG and KPMG (over 2,100 executives): only 5% to 8% of enterprises report measurable AI returns at scale, even with average AI budgets of $186 million.4
• IBM (2,000 CEOs): only 25% of AI initiatives delivered the expected ROI, and only 16% scaled across the enterprise.8
• McKinsey: organizations seeing big returns were twice as likely to have redesigned their workflows from end to end before choosing models.7
• RAND (practitioner interviews): leadership-related causes, not technical failures, accounted for 84% of the failure reasons cited.10

These studies measure different things, but they lead to the same conclusion: AI pays off when the work itself is redesigned, not when the tool is added on top of how work is already done.

The headline number deserves some caution. Critics, including Marketing AI Institute's Paul Roetzer, note that MIT's 95% figure uses a narrow, six-month, P&L-only definition of success that leaves out efficiency and productivity gains.8 Several analyses treat it as a rough direction rather than a precise rate.11 The fair summary is that a large share of AI spending is underperforming expectations. The exact share depends on how value is defined.

The competing explanation: old systems and messy data

There is a second explanation for the stall, and it comes mostly from vendors and integrators. It says the real problem is technical.

One modernization firm, citing Deloitte, says nearly 60% of AI leaders name legacy integration as one of their biggest barriers to deploying AI agents.12 Their reasoning is that agents need real-time information, while old systems run on overnight batch jobs, flat files and rigid workflows.12 A 2026 benchmark of 1,050 IT leaders found that 86% think AI agents can add more complexity than value when integration is missing. About half of today's agents still run in isolation.16 One integration vendor puts the share of enterprises naming legacy integration as their single biggest obstacle to ROI at 46%.13

This account and Ratanjee's are not really in conflict. Both describe AI being bolted onto structures built for an earlier era. One talks about processes and incentives, the other about databases and APIs. Still, they lead to different spending decisions. Vendors tend to recommend wrapping old systems in AI agents or replacing them.1218 Ratanjee recommends changing how programs are planned, funded and reviewed.1

A warning attributed to McKinsey suggests technology alone will not solve the problem. Adding agents on top of a "good enough" legacy system risks hitting the same limit robotic process automation hit: quick wins at the edges while the core problems stay in place.21 McKinsey's high performers redesign workflows rather than inserting AI into existing ones.10 BCG similarly says agents cannot simply be bolted onto legacy processes.10 On this point, the technical and organizational camps agree.

Why companies keep using the old playbook

Ratanjee gives three reasons the method persists:1

1. Habit. Technology rollout is the corporate routine people have practiced most.
2. Funding. Budget committees approve proposals with fixed milestones and benefits curves. They send back proposals that ask for ongoing funding and regular reassessment.
3. Career risk. In most performance systems, revising an approved plan looks the same as having gotten it wrong.

His proposed fixes match those three causes:1

• Remove the go-live date and see which parts of the program still make sense without it.
• Fund a regular review cycle instead of a fixed benefits curve, and require each proposal to state what would prove it wrong.
• Put the date for revisiting the plan on the calendar before it is approved, and name who is protected when it happens.

The funding point may matter most for ROI. Surveys show companies mostly track operational measures such as productivity (39%) and time savings (36%). Strategic measures like revenue growth come in at 26%.3 If a program is judged on milestones met rather than on how the business changes, it can look successful and still never reach the P&L.

Where this leaves enterprise AI

This analysis takes the view that Ratanjee has identified a cause that comes before many of the technical ones. A company that keeps updating its plans, funding and incentives can work through integration debt piece by piece. A company stuck on a fixed blueprint will still underperform after its systems are modernized, because its methods are still built for a target that stays still. The data does not prove this, but it is consistent with it: the gap between leaders and laggards keeps showing up in workflow redesign and leadership behavior, not in which model a company picked.710

The uncomfortable conclusion for managers is that the playbook that made them good at enterprise technology may now be getting in their way. The 1998 method worked because the software it installed stayed still. AI does not, and so far most organizations have not adjusted their methods to match.1