AI readiness is often framed as a checklist. Do you have data? Do you have use cases? Do you have executive sponsorship? Do you have guardrails? Do you have the right tools?
Those questions are not useless, but they are not enough. They make readiness sound like a general organisational condition, when the more useful question is much more specific: which parts of the business are actually suitable for AI, which are not ready yet, and which should be fixed, simplified or retired before AI is introduced at all?
For a growing business, that distinction matters. AI is now easy to talk about and increasingly easy to experiment with. It is much harder to turn it into controlled business value. The reason is rarely the model itself. The constraint usually sits in the operating reality around it: process variation, unclear ownership, fragmented data, duplicated applications, brittle integrations and controls that were never designed for automated or semi-automated decision-making.
AI does not remove those constraints. It exposes them.
Most businesses are not blocked by AI
Many businesses do not have an AI problem. They have an operating model problem that AI makes harder to ignore.
A process that is inconsistent across teams will not become coherent because a model is added to it. A data set that cannot be trusted for reporting is unlikely to become trustworthy because it is used in an AI workflow. An application estate with overlapping roles will not become easier to govern because another layer of automation sits above it. A weak control environment will not become safe because the AI tool has a policy document attached to it.
The failure mode is not always dramatic. In many cases, AI produces useful local results while the wider business remains unchanged. Teams gain productivity in pockets. A few workflows improve. Some documents are produced faster. A chatbot or assistant works in a narrow context. But the underlying operating model still carries the same confusion, duplication and manual reconciliation as before.
That is not strategic advantage. It is productivity on top of unresolved complexity.
The practical question for leaders is therefore not whether AI could be used somewhere. It almost certainly could. The better question is whether the business understands where AI should be used, where it should be constrained, where the foundations need fixing first, and where AI would simply make a fragile process move faster.
Readiness is contextual
A business is not simply ready or not ready for AI. Different parts of the business will sit in different states of readiness.
One process may be stable, well understood and supported by clean data, making it a reasonable candidate for automation or AI assistance. Another may be valuable but too variable, requiring process design before any intelligent workflow is introduced. Another may be duplicated across teams and better suited to rationalisation before technology is added. Another may be low value, poorly controlled and ready to retire rather than modernise.
This is why generic AI readiness assessments can become shallow. They often produce a broad view of capability but do not translate that view into treatment decisions. A score may tell the business that it has data weaknesses, governance gaps or use-case opportunities. It may not tell the leadership team what to do with a specific process, application, workload or capability next.
That is where readiness needs to become disposition.
Disposition is the missing decision layer
A disposition view asks what should happen to a process, application, workload or capability based on evidence.
Some things should be retained because they are working well enough and changing them would create unnecessary disruption. Some should be retired because their value no longer justifies the complexity they create. Some should be rationalised because duplication is creating cost and confusion. Some should be stabilised because they matter, but the current foundations are too weak to build on confidently.
Other areas may be suitable for automation, where the work is repeatable and the rules are clear. Some may be suitable for AI assistance, where human judgement remains central but the model can reduce cognitive load or improve speed. Fewer areas will be ready for deeper AI enablement, where AI becomes embedded in operational flow and therefore requires stronger data, integration, monitoring and control maturity.
In some cases, the right answer is replacement or rebuild. That should not be the default, but it should remain an option where the existing process or application cannot support the business direction safely or economically.
The value of this approach is that it prevents AI readiness from becoming a vague positive ambition. It forces the business to connect ambition to treatment, treatment to evidence, and evidence to sequencing.
AI-readiness decisions need structural evidence
Useful disposition decisions cannot be made from a technology inventory alone.
The business needs to understand the capability being supported, the process flow around it, the data it depends on, the applications involved, the integration points that connect it, the automation already in place, and the controls that would be required if AI were added.
These are not separate checklists. They are connected diagnostic lenses.
If the process is unstable, AI may create faster inconsistency. If the data is weak, AI may generate outputs that look confident but cannot be trusted. If application boundaries are unclear, AI may increase dependency on an already confused estate. If integrations are brittle, AI-enabled workflows may fail in ways that are harder to diagnose. If controls are reactive, automated or AI-assisted decisions may scale risk before anyone sees the pattern.
This is why AI readiness belongs inside a broader operating-model diagnosis. The question is not whether a tool can be deployed. It is whether the surrounding business reality can support the use case safely, repeatedly and economically.
The wrong sequence creates expensive noise
AI initiatives can create noise when they are started before the business understands the operating constraints beneath them.
A leadership team may fund pilots across several functions because the appetite is high, but without a clear view of which use cases are structurally viable. Teams may build prompt libraries or agent workflows before data ownership and control points are defined. Automation may be introduced into a process that should have been simplified first. A vendor solution may be selected because it demonstrates impressive capability, while the business has not yet tested whether its own foundations can support adoption.
The result is often a collection of experiments rather than a coherent path to advantage.
That does not mean businesses should wait until everything is perfect. Perfection is not the standard. The standard is enough clarity to know where to act, where to constrain, and where to defer.
The useful AI question is not “where can we use AI?” It is “what treatment does this part of the business deserve next?”
A practical AI-readiness question set
A better AI-readiness conversation starts with the business object being assessed. That may be a process, application, workload, decision flow, reporting activity, operational capability or customer interaction.
For each candidate, the business should ask whether the process is stable enough to automate or assist, whether the data is reliable enough to inform decisions, whether the application landscape is clear enough to avoid duplication, whether integration points are predictable enough to support workflow, and whether controls are strong enough to scale the change safely.
It should also ask whether the use case is worth pursuing at all. Some work is too low value. Some activity is compensating for a broken process and should be removed rather than enhanced. Some applications are better retired than integrated again. Some workflows need stabilisation before AI is even relevant.
This turns AI readiness into a set of treatment decisions rather than a general enthusiasm score.
Where ITZAMNA fits
ITZAMNA is useful here because it treats AI readiness as part of a broader diagnostic and sequencing problem.
The first move is to diagnose the operating reality. That means identifying the symptoms, collecting evidence, mapping where friction sits across capabilities, processes, data, applications, integrations, automation and controls, and testing whether the AI opportunity is being constrained by deeper structural issues.
The next move is to shape a disposition view. For each relevant process, application or capability, the business can decide whether to retain, retire, rationalise, stabilise, automate, AI-assist, AI-enable, replace or rebuild. That decision should include rationale, confidence, risk, dependency and sequencing implications.
Only then does the business have a credible basis for action. It can choose a small, safe AI-assisted workflow. It can stabilise data before scaling a use case. It can retire duplication before adding another tool. It can decide that a process is not ready yet and that forcing AI into it would create more cost than value.
This is not anti-AI. It is pro-value.
AI advantage starts with better judgement
The businesses that benefit most from AI will not simply be the ones that move fastest. They will be the ones that understand where AI can safely strengthen the operating model and where it would amplify fragility.
That requires better judgement before tooling. It requires evidence before enthusiasm. It requires a practical view of what to fix first, what to simplify, what to retire, what to automate, and what is mature enough to AI-enable.
AI readiness is not a checklist. It is a decision about treatment and sequence.
Get that decision right, and AI becomes part of a more coherent operating model. Get it wrong, and it becomes another expensive layer on top of the same unresolved complexity.
