AI-enabling the old way is why your transformation stalls.
Adding a model to a process built around a constraint that no longer applies does not change the economics. The programmes that make it to production redraw the work first, then add intelligence to it.
They all fail the same way
Most AI programmes we are asked to rescue look identical from the outside. There is an impressive pilot that demos beautifully, an enthusiastic innovation team who can explain exactly why it matters, and a production date that has now moved three times.
The technology is rarely the problem. The models work, the vendors are competent, and the engineering is usually better than the organisation gives it credit for. What is wrong is upstream of all of that.
The programme was designed to prove that AI works rather than to change how the business runs. Those are different objectives, and only one of them survives a budget review in the second year.
The easy thing to fund
AI-enabling an existing process is much easier to fund than redesigning it. It needs no operational change, no difficult conversation with the person who owns the workflow, and no admission that the workflow was shaped by a constraint that has since disappeared.
So the pilot gets pointed at the process as it stands. It reads the same forms, follows the same approval chain and produces the same artefact slightly faster. Everyone can see it working, and nobody can see the number move.
Three things follow from that decision, and all three show up later as delivery problems rather than design problems.
The process was designed around its old constraint, so you have automated the workaround rather than removed the bottleneck.
Nobody with a P&L signed up for the outcome, and an innovation budget cannot force an operational change.
Governance was treated as a launch gate rather than a design input, so risk arrives at the end with legitimate objections and no time.
Redesign, then automate
The programmes that reach production start from the economics rather than from the capability. They ask which process, if it behaved completely differently, would change cost or revenue enough to justify the disruption of changing it.
That question does most of the work. It rules out the interesting-but-marginal use cases that consume the first year of most AI roadmaps, and it forces a conversation with whoever owns the number rather than whoever owns the innovation budget.
Once the process is redrawn, automation becomes straightforward, because you are automating something designed to be automated rather than something designed around a human bottleneck.
Start from the economics
Which process changes cost or revenue enough to justify the disruption.
Redesign, then automate
If the workflow only makes sense because of a constraint AI removes, change the workflow.
Give it an owner with a budget
The person accountable for the number, not for the innovation.
Bring risk in on day one
Constraints are cheaper as design inputs than as launch objections.
One question, asked early
There is a short test we apply before committing to any use case, and it costs nothing to run. Ask what breaks if this works. If a process genuinely changes, something downstream has to adapt: a team stops doing something, a handover disappears, a report becomes unnecessary.
When nobody can name what changes, the use case is decoration. It will pass its pilot, produce a pleasant slide, and quietly fail to justify its second year of funding. If the answer to what breaks if this works is nothing, you are automating something that did not matter.
The useful side effect of asking early is that it surfaces the operational conversation while it is still cheap. Finding out in week three that a team will need to work differently is a planning input. Finding out in month nine is a reason the programme stops.
Three things this quarter
None of this requires a transformation office or a new platform. It requires being honest about which processes matter and willing to change one of them.
If you want to make progress before the next planning cycle, three things are worth doing now.
Pick one process where you can name the number it affects.
Write down what the process would look like if the constraint vanished.
Get the risk conversation on the calendar before the build starts.
This is the sequence our AI Transformation engagements are built around: find the economics, redesign the work, then ship intelligence into it with governance already agreed.
Explore AI TransformationLeads our AI practice across India, Dubai and the US, with a focus on getting pilots into production. Spends most of his time on the operational conversations that decide whether a model ever ships.
See all articles by this author
