Why McKinsey's $3-to-$1 AI rule is wrong for order automation

No, and the reason is worth understanding. McKinsey's July 2026 report on the future of B2B sales says companies may need to spend $3 on change management for every $1 spent deploying AI, and that most invert the ratio. That ratio is a real observation about a real problem, but it describes an era of software that is ending. Classic enterprise systems shipped a process and required the organization to conform to it. Change management was the bill for that mismatch. Software that reads and adapts to the process you already run does not send the same bill.

Key takeaways

• McKinsey's $3-to-$1 ratio describes enterprise-wide gen AI tool rollouts, which are deployed the way classic software was: buy a general capability and ask people to change how they work.
• Change management was the cost of the gap between the vendor's process and yours. Panorama Consulting's 2026 ERP report found more than a quarter of organizations exceeded budget, commonly after finding that mismatch late.
• When software is configured to your process, the direction of adaptation reverses and most of that cost leaves the budget.
• Two costs survive: capturing the rules that live in people's heads, and deciding what the recovered hours are for.

The ratio rings true to anyone who has been through an ERP go-live. You did not buy software so much as adopt someone else's idea of how your business should work, and then spent two years persuading your own people to work that way. The consultants were not padding the invoice. That really was the job.

The question is whether that cost is a law of technology adoption or an artifact of a particular kind of technology. We think it is the second, and the difference matters for anyone being quoted an AI project on ERP-sized assumptions.

Where does the $3-to-$1 rule come from?

McKinsey draws on its earlier work on scaling generative AI from pilot to production and its January 2025 research on AI in the workplace. Note the hedge in the original: companies "may need" to spend at that ratio. It is a planning heuristic from consulting experience, not a measured benchmark.

More important is what was being deployed in the projects behind it. The report makes it clear that most companies have focused on rolling out enterprise-wide generative AI tools whose "economic impact is often diffuse." A company-wide assistant is deployed exactly as classic software was: buy a general capability, hand everyone a license, and ask them to change how they work to get value from it. Of course that needs $3 of change management. The burden of adaptation is still on the humans.

Why did classic enterprise software need so much change management?

Because it encoded one process, and you had two ways to deal with the gap between that process and yours. You could customize the software, which was expensive and broke at every upgrade, or you could conform, which meant redesigning roles, rewriting procedures, and retraining everyone. "Best practice" was frequently a polite term for the process the vendor could support.

The pattern still shows up in the data. Panorama Consulting's 2026 ERP report found that more than a quarter of organizations exceeded their project budgets, and that the common cause is discovering a technology mismatch late and buying additional technology or custom development to close it. That is the mismatch tax, arriving on schedule.

On an order desk, it looked like this. Your team had a rule that one large customer's split shipments get confirmed by phone before release, because that customer once refused a delivery over it. The new system had nowhere to put that rule. So it became a sticky note, then a workaround, then an error, and eventually a training module about why the workaround was not allowed.

What changes when the software adapts to you?

The direction of adaptation reverses, and most of the cost goes with it. An AI system that reads unstructured documents does not need your customers to send orders differently. A system configured with your business rules does not need your desk to adopt someone else's. The odd rule about split shipments stops being a problem to eliminate and becomes a rule to encode. Six differences follow from that one reversal.

• Classic: The organization adapted to the software. AI: The software is configured to the organization.
• Classic: Customers had to change too, through new portals, new formats, or new ordering rules. AI: Customers keep sending orders exactly as they send them today.
• Classic: The desk learned new screens, new steps, and a new workflow. AI: Most of the job disappears rather than changes, and what remains is exception review.
• Classic: The effort went into reengineering the process to fit the system. AI: The effort goes into interviewing the desk to capture the rules it already follows.
• Classic: An odd rule became a workaround, an expensive customization, or a quiet casualty. AI: That same rule gets configured once, and the system enforces it every time.
• Classic: Implementations ran in quarters, often years. AI: Weeks, scoped one order type at a time.

Look at what leaves the budget when adaptation runs the other way. No customer-facing change, so no migration campaign and no accounts quietly churning during the transition. No new primary interface for the desk, because the work arrives as exceptions to review rather than screens to master. No process reengineering phase, because the process is the input rather than the output. What remains is configuration, and configuration is paid once.

Where McKinsey is still right

Two things survive the argument, and they are worth stating plainly because the sloppy version of this claim is that AI implementations are effortless. They are not. The rules that make an order correct live in people's heads, and getting them out is real work. It is interview work rather than organizational change, and it is measured in weeks rather than years, but nobody should sell it as free.

There is one change no configuration can absorb: what people do with the hours they get back. If leadership does not answer that question out loud before go-live, the order desk will assume the answer is headcount, and adoption will stall for reasons unrelated to the software. That is genuine change management. It is cheap, it is quick, and skipping it is how a $50,000 project fails.

What should this actually cost you in time?

Scope it the way the argument implies. If the software is adapting to you, there is no reason to boil the ocean, and no reason to wait quarters for a first result.

1. Pick one order type or one customer segment, end to end, from intake to a posted sales order.
2. Capture the rules your desk already follows, including the odd ones, and configure them rather than reforming them.
3. Keep a person on exceptions from day one, and let the exception rate tell you what to configure next.
4. Say out loud what the recovered hours are for before anyone asks.

Our own experience matches the argument. Customers who scope it this way see the gains within weeks, at a cost that looks nothing like an enterprise rollout, because nothing about their process or their customers had to change before the system could start working. The savings show up while the project is still running, not a year after it ends.

That is a weeks-long project running alongside your existing ERP, not a replacement program. It is also why the implementation question we keep coming back to is about the team doing the configuring, not the size of the change management budget.

What to do next

We build order automation for manufacturers and distributors, which means we spend our implementations asking your team what they already do rather than telling them what to do instead. If your customers are getting inconsistent answers about their orders, bring three of your messiest purchase orders and book a demo.