Author: Ahmed Hussain
The broken process has two qualities that make it look like the right place to begin. It is visible and it is urgent.
When a process breaks repeatedly, the organisation knows about it. The escalation calls are logged. The workarounds are documented. The cost of failure is felt in the business every week. The pressure to fix it is real, and the appetite to try something new is high.
AI is new. The broken process has a problem. The combination feels productive.
What the logic misses is everything underneath the visibility. A broken process is broken for a reason. Usually several reasons that compound each other. The inputs are inconsistent because the upstream data was never properly structured. The exception rate is high because the rules were written for a version of the process that no longer reflects how the work actually arrives. The people who run it have developed workarounds that are undocumented, not because they are hiding something, but because the workarounds evolved faster than anyone thought to write them down.
Deploying AI into this environment does not fix the process. It automates the workarounds. It scales the inconsistency. It moves faster through steps that were already producing the wrong output.
The result is an AI system that runs confidently and produces errors at a rate the organisation cannot keep up with. The fix is always the same: pause the deployment, map the process properly, clean the data, redefine the rules. Everything that should have been done before the AI was built.
The right starting point for an AI deployment is the best-running process in the organisation.
This is counterintuitive. The best-running process does not feel urgent. It is not generating complaints. Nobody is escalating about it. The business is not losing visible money on it. The case for intervention is harder to make in a leadership meeting.
But the best-running process has qualities that make it the right foundation for an AI deployment.
The inputs are consistent. The same type of data arrives in the same format, with the same structure, reliably enough that a system can be trained on it and deployed with confidence that what it trained on reflects what it will see in production.
The outputs are defined. The team that runs the process can articulate what a good output looks like. Not in general terms. In specific terms. This output met the standard. That one did not. This is why.
The edge cases are known. Because the process runs well and the team understands it, the exceptions that occur are documented or at least discussable. When asked what happens when an unusual input arrives, the team can answer. That answer is what makes it possible to specify an AI system that handles the normal cases and routes the exceptions correctly.
The people who run it can explain it. This is perhaps the most important quality. A process that is well understood by the people running it can be specified precisely enough to build an AI system around. A process that runs on institutional memory and undocumented judgment cannot.
The business case for starting with the best process is not just structural. It is economic.
A process that already runs well is handling volume at a rate limited by the human capacity available to run it. The senior analyst who produces the weekly reconciliation report takes four hours. The customer success manager who qualifies new inbound enquiries handles twelve per day. The procurement team that reviews supplier submissions processes forty per week.
In each case, the ceiling on throughput is human time. The work is well-defined. The quality is consistent. The constraint is capacity.
An AI system deployed on this process does not change the definition of good output. It does not need to fix a broken methodology. It runs the same well-defined process, faster, at higher volume, with the human judgment reserved for the cases that genuinely require it. The senior analyst reviews the exceptions the system flagged, not the full report. The customer success manager handles the qualified enquiries the system escalated, not the full inbound queue. The procurement team reviews the supplier submissions the system could not score, not all forty.
The throughput gain is real, measurable, and immediate. And because the process was already working, the risk of the AI system producing confidently wrong outputs is significantly lower than it would be in a broken process.
This is not an argument that broken processes should not be fixed. It is an argument about sequence.
A broken process needs to be fixed before AI is deployed into it. The fixing work is a process design problem, not an AI problem. It involves mapping what the process actually is, not what the documentation says it is. It involves cleaning the data that feeds it. It involves defining the rules that the workarounds are approximating. It involves agreeing on what a good output looks like and how to measure whether the process is producing it.
This work is unglamorous. It does not generate excitement in a leadership meeting. It is harder to fund than an AI project because it does not come with a demo. But it is the prerequisite for any AI deployment that is going to operate in production rather than in a perpetual pilot phase.
The organisations that deploy AI successfully do not have better models than the ones that fail. They have better sequence.
They define the workflow before they select the model. They clean the data before they build the pipeline. They specify the edge cases before they go live. And they start on a process where the foundation is solid enough to build on.
Starting on the best process is not a conservative choice. It is the fastest path to a working system in production. The organisation that starts there builds confidence, builds a track record, and builds the operational discipline that makes the next deployment easier.
The organisation that starts on the broken process builds a very expensive proof of concept, discovers the process needed to be fixed first, and starts again.
The broken process will get its turn. After the foundation is laid.
