Every engagement starts the same way. Someone senior, usually smart and usually under real pressure, asks me where AI goes in their business. It is a perfectly reasonable question. It is also the wrong one, and I understand entirely why it gets asked, because it is the question the board asked them first.

The trouble is what it smuggles in. It assumes the thing you have is the thing you should have, and that all it needs is a faster engine bolted to the front. Most of the time that is not true. The longer a business has existed, the less true it tends to be.

The absurdity, when you look straight at it

Think about what where can we add AI actually takes for granted. That the process is correct. That every step in it has earned its place. That the only thing wrong with it is the speed at which it runs.

None of that is usually the case, because processes do not really get designed. They accrete. Somebody added an approval in 2019 because a thing went badly wrong and nobody wanted it to happen twice. Somebody added a second review because a client got upset on a Friday. Somebody built a spreadsheet to bridge two systems that were both supposed to be replaced within the year, and that spreadsheet is now load bearing. None of it ever came out again, because removing things is nobody's job. Adding things looks like progress. Removing them never does.

Then we turn up with AI and make the whole thing run four times faster. Congratulations. You have automated the 2019 approval, and now it happens before lunch.

What we actually do

At Rhapsody we call it the input to output assessment. It works because it is deliberately blunt. Write down what goes in. Write down what has to come out, and be genuinely specific about that second one, because a campaign is not an output. The actual artefacts are. The actual formats. The actual standard they have to hit before somebody signs them off.

Then map everything sitting between those two points. Every system, every person, every handover, every approval, and, most revealingly, every wait. The waits are usually where the truth is.

Then ask the only question that really matters. If I had this input, and I needed that output, and I was starting today with what exists now, how would I actually do it?

You will almost never describe the thing you currently have. That gap is the opportunity. Not the automation. The gap.

In practice people find two things. A handful of steps that exist purely to compensate for a system somebody is about to replace anyway, and a couple more that exist because of a person who left in 2022. Those do not need automating. They need deleting, and that is free.

Why the middle gets fat

Eli Goldratt wrote about this in 1990, long before any of us had this particular problem to worry about. His observation was that organisations build rules to cope with a constraint, the constraint eventually disappears, and the rule quietly stays exactly where it is. He called them policy constraints, and his line on it is better than mine. Their original reasons have since long gone, but the old policies still remain with us.

That is most of what is sitting in the middle of your process right now. Fossils. Constraints that stopped existing years ago, still faithfully maintained by people who were not there when they were set.

The number everyone uses for this, which does not actually say it

I want to be straight about something here, because I have been guilty of it myself more than once. The statistic everybody reaches for is that ninety five percent of AI pilots fail. It comes from MIT's NANDA report, it is absolutely everywhere, and it is almost always deployed to argue precisely what I am arguing in this piece.

So I went and read it. It does not say that. Its actual diagnosis is a learning gap in the tools themselves... systems that do not remember, do not adapt and do not survive contact with edge cases. Its advice to buyers is to start at the edges of existing workflows and customise heavily from there, which is a recommendation to add carefully. It is not a recommendation to delete first, and using it that way is sloppy.

The number that genuinely does support this argument is much quieter and almost nobody quotes it. McKinsey tested twenty five organisational attributes against whether a company saw any real profit impact from generative AI, and the single biggest factor was whether they had redesigned their workflows. Only twenty one percent of the companies already using it had fundamentally redesigned any of them.

Four in five are bolting it onto a process nobody ever questioned. That is the finding, and it is a far better one than the stat we have all been passing around.

The bit I was missing

Musk has a five step algorithm he talks about, and step two is to try very hard to delete the part or the process. Fine. I believed that already. I had been saying a version of it for years.

What I did not have is what comes immediately after it. If you are not adding at least ten percent of what you deleted back in, you did not delete enough in the first place.

That is a falsification test, and my version of this simply did not have one. It means the exercise has a correct failure rate built into it. If every single cut you make survives contact with reality, you were being too careful, and the honest conclusion is that you should have gone further. You are supposed to overshoot and then walk some of it back. I have started using it in rooms and it changes them, because it gives people explicit permission to cut something they are not certain about.

Where this is wrong

There is a real counter argument here and I would much rather make it myself than have it made at me.

Sometimes you genuinely do not know enough to redesign anything. You have never seen what the technology does in your specific context, your team has no intuition for it yet, and auditing a process you do not properly understand is theatre with a whiteboard. In that situation the right move really is to bolt something on, ship it, watch what happens and build the intuition. Then come back and do this exercise properly, with evidence.

The failure mode is stopping at step one. The pilot works, everybody is pleased with themselves, and the redesign never happens at all, because the thing technically functions and nobody wants to reopen it.

So

Before you optimise a process, ask whether it should exist at all. Before you add another step, make that step justify itself out loud. If a process cannot survive being looked at properly then it does not belong, and no amount of intelligence layered on top of it is going to fix that. It will just make it faster.

The best systems scale because they are simple enough to understand and disciplined enough to execute, and that was true long before any of this arrived. What has actually changed is that the cost of finding out has collapsed, and with it the last decent excuse for not looking.

Anyway. That's where I'm sitting on this.

Si