Most AI readiness problems are not AI problems.
Before automating a process it helps to know whether the data is trustworthy, whether anyone agrees what the process is, and whether the systems involved can be reached at all. We assess that honestly and sequence the work.
The pilot failed, and the model was not the reason
Automation efforts stall for unglamorous reasons. The data exists but nobody trusts it. The process is documented but the documentation describes what should happen rather than what does. The system holding the records has no usable interface. Three teams each believe they own the exception handling.
None of that is visible in a demo, and all of it surfaces in week three of an implementation. Assessing it first is cheaper than discovering it, and it changes which processes you should attempt at all.
Working out what is genuinely ready, and what only looks it
The assessment covers four dimensions, because a process usually fails on whichever one nobody checked.
Data readiness. Whether the data automation would depend on is complete, current and trusted by the people who would have to rely on the output. Quality problems that humans quietly work around become failures when a machine hits them.
Process readiness. What the process actually does, as opposed to what the documentation says. Where the exceptions are, how often they occur, and who handles them. Exception volume is usually what decides whether automation is worth it.
Systems readiness. Whether the systems involved can be reached programmatically, what that access costs, and where a human is currently acting as the integration between two things that do not talk.
Organisational readiness. Whether the people affected have been involved, who owns the process afterwards, and what happens to the roles around it. Automation that surprises the team running the process tends not to survive contact with them.
Candidate selection. A shortlist of processes worth automating, scored on effort against benefit, with the ones we think you should leave alone marked as such and the reasoning given.
Measuring what it saved. Deciding upfront how you will know whether automation worked, and baselining before you change anything. Skipping this makes the second business case much harder to argue.
Assess broadly, then go deep on a shortlist
Assessing everything to the same depth wastes time. We survey widely, then concentrate on the candidates that look worth the effort.
Map what is already there
A broad pass across candidate processes with the people who run them, scoring each on the four readiness dimensions. Fast and deliberately shallow, to find where the depth is warranted.
Go deep on the shortlist
Detailed work on the processes that scored well: real volumes, real exception rates, real system constraints. This is where optimistic candidates usually get demoted, which is the point.
Sequence the work
A roadmap ordered by readiness and benefit rather than by enthusiasm, including the preparatory work that has to happen before certain processes become viable at all.
A roadmap built on evidence rather than optimism
- A readiness assessment across data, process, systems and people
- Process maps reflecting what happens rather than what is documented
- A scored shortlist of automation candidates with effort against benefit
- The processes we think you should not automate, and why
- Preparatory work identified for candidates that are not ready yet
- A baseline and measurement approach agreed before anything changes
Related: agentic frameworks, strategic advisory, the full consultancy practice.