"It's impressive" is not the same as "it pays for itself"

Most AI purchasing decisions happen backwards. Someone sees a capable demo, gets excited about what the tool can technically do, and the budget conversation starts from there — with the ROI case built after the fact to justify a decision that's already emotionally made. That's not a criticism of the people making the call; it's just how impressive technology tends to get bought, and it's exactly the pattern that made the automation wave and the ERP wave expensive for the companies that got it wrong.

The fix isn't skepticism for its own sake. It's asking the ROI question in the right order — before the contract, not as a retroactive justification for one already signed.

Three numbers, not one gut feeling

This is the same discipline behind real numbers, not a new one

This three-number framework isn't abstract — it's the same logic behind the For-Profit Education case study, where the fix wasn't a bigger media budget, it was modeling the actual lifetime value of each degree program and letting the acquisition cost follow the real number instead of a blended guess. That discipline supported 4x the media spend specifically because the value side of the equation was calculated honestly first, not assumed.

The same logic applies to an AI purchase. If you can't say with reasonable confidence what a tool is actually worth to a specific, sized use case, the responsible move isn't to buy it and hope the value shows up — it's to define the use case precisely enough that the number becomes calculable.

The phrase that started it

In 1990, management theorist Michael Hammer published an article in Harvard Business Review with a title that still holds up as advice today: "Don't Automate, Obliterate." His argument was simple and, at the time, genuinely radical — companies were spending enormous sums computerizing their existing processes, and getting almost nothing for it, because a computerized bad process is still a bad process. His answer wasn't better software. It was tearing the process down and rebuilding it from the actual business objective, not from whatever steps happened to already exist.

Three years later, Hammer and co-author James Champy expanded the idea into Reengineering the Corporation, and business process reengineering became one of the most influential — and most widely misapplied — management ideas of the decade. The misapplication is the part worth paying attention to, because it's the same misapplication happening again right now, three technology generations later.

Four waves, one recurring mistake

Why the mistake keeps recurring

Every one of these waves arrived with genuine, real capability behind it — ERP, RPA, and AI all deliver real value when applied correctly. That's actually part of why the mistake keeps happening: the technology is impressive enough on its own that it's easy to believe the impressiveness is the whole solution. It never has been. The technology is the second decision, not the first.

The first decision is always the same one Hammer described in 1990: understand what the process is actually supposed to accomplish, strip out what doesn't serve that, and only then decide where technology earns a place in what's left. That sequence doesn't change with the tool. It's the reason the same automation-era mistake we've written about before keeps showing up under a new name every decade — and it's the discipline behind every engagement on this site, well before AI made it a trending topic.

The deal is the easy part

Due diligence gets months of attention. Integration gets a plan on a slide and then whatever time is left over after the deal actually closes. That imbalance is the source of almost every post-acquisition problem — not bad diligence, not a bad target, just a structural underinvestment in the unglamorous work of making two organizations run as one.

The three engagements below span industrial refrigeration, automotive consulting, and fuel delivery — different industries, different buyers, different deal sizes. The pattern underneath all three was identical.

Three engagements, one pattern

The common thread

In each case, the instinct under pressure was to move fast on something visible — replace the system, roll out new software, consolidate everything at once. In each case, the actual fix was slower and less dramatic: understand what was really happening operationally first, then make the technology decision in service of that, not ahead of it.

That sequencing is what separates an integration that compounds problems from one that resolves them. A new system layered onto an unclear process just makes the unclear process run at a larger scale.

The real question isn't "can we afford a CTO." It's "do we need one for the next 40 hours a week, or the next 10?"

Most businesses that need executive-level judgment don't actually need it full-time. They need it consistently, accountably, and at the right level of seniority — but not five days a week, every week, indefinitely. A full-time hire at that level is a large fixed cost, a long hiring process, and a bet that the need will still be there in the same shape a year from now. Fractional leadership exists for the much more common situation: real, ongoing need for the judgment, without the full-time shape.

Below are the signs worth checking against, broken out by role, since "we need help" usually turns out to be a specific gap once you look closely.

By role: what the gap usually looks like

One caution before you hire anyone, fractional or full-time

A fractional executive fixes an accountability gap. It doesn't fix a process that was never going to work regardless of who's running it. Before bringing anyone in — fractional or full-time — it's worth being honest about which one you actually have. That's the same diagnostic question behind everything else on this site, and it applies just as much to hiring decisions as it does to technology ones.

The pitch always sounds the same

A decade ago, the pitch was automation. Robotic process automation, workflow software, "digital transformation" in the loosest sense of the term — the promise was that if you wired your existing process into a machine, the machine would run it faster, cheaper, and with fewer mistakes than the humans doing it by hand.

Today the pitch is AI. Different acronym, same promise: hand your process to something smarter than a human, and the process gets better. The tools changed. The pitch didn't.

What actually happened ten years ago is the part everyone conveniently forgets. Companies that automated a broken process didn't get a fixed process running faster. They got a broken process running faster — and running it at a scale and speed that made the underlying dysfunction much harder to catch, diagnose, and unwind, because now it was happening automatically instead of visibly, by hand, where at least someone noticed when it went wrong.

The mistake has a name, and it's older than either technology

This isn't a new observation. Business process reengineering, as a discipline, exists specifically because organizations kept making this mistake with every new wave of enterprise software going back to the 1990s. The core insight was never about the technology — it was about sequence. Fix the process, then apply the tool. Reverse that order, and the tool just becomes a faster way to do the wrong thing.

AI makes this failure mode worse, not better, for one specific reason: AI is genuinely more capable than the automation tools that came before it. A clunky RPA script that automates a bad process fails in ways that are usually obvious pretty quickly — it breaks, it errors out, someone notices. A capable AI system layered onto a bad process can paper over the dysfunction convincingly enough that nobody notices until the cost has already compounded. The better the tool, the more dangerous it is to point at the wrong problem.

That's not a line written for this article. It's the actual stated goal on a real client engagement, well before AI was part of anyone's vocabulary. The instinct to fix the process before touching the technology isn't new marketing positioning built around the AI moment — it's the same discipline applied to whatever the current hype cycle happens to be.

How to tell which problem you actually have

Most businesses considering an AI investment right now are really asking one of two very different questions, and conflating them is where the trouble starts:

• "Our process works, but it's slow or expensive — can AI speed it up?" This is a legitimate question, and often the answer is yes.
• "Our process is inconsistent, poorly owned, or nobody agrees on how it's supposed to work — can AI fix that?" This is the question that gets you in trouble, because the honest answer is no. AI applied here doesn't fix the inconsistency. It automates it, at scale, invisibly.

The uncomfortable part is that most organizations can't actually tell which question they're asking without looking closely — because a process that's been broken long enough starts to feel normal to the people running it. That's not a knock on anyone's judgment; it's just how organizational blind spots work. It usually takes someone outside the day-to-day to see the gap between "how we've always done it" and "how it actually needs to work."

If more than one of those gave you pause, that's not a reason to avoid AI forever — it's a reason to sequence the work correctly. Align on what the process should actually do, simplify it down to something consistent, and only then decide where AI or automation genuinely earns a place in it.

The businesses that get this right aren't slower to adopt AI. They're faster.

The instinct might be that all this diagnostic work up front is a delay — that the businesses racing straight to AI adoption are the ones getting ahead. In practice, it's usually the opposite. A business that fixes its process first ends up implementing AI faster and cheaper than one that's still discovering, mid-rollout, that the tool is just making an existing mess more efficient. The upfront discipline isn't the slow path. It's the one that doesn't require doing the work twice.