The readiness question is not whether the data exists
Most organisations can answer 'do we have data on customers, orders and prices' within a minute, and the answer is yes. The question that determines whether an AI project will work is different: can this data be identified, interpreted and acted upon by something that has no memory of how the business used to work, under a permission model somebody has written down, with every consequential step traceable afterwards.
That question is answerable, and answering it takes a small team two or three weeks rather than a data transformation programme. The value of a structured readiness assessment is that it produces a defensible decision — proceed, narrow, or stop — rather than a percentage that everyone interprets differently. A readiness exercise that ends without a recommendation has been wasted.
Seven dimensions, each with a hard question
The dimensions below are ordered roughly as they constrain each other. Availability comes first because nothing else matters without it, and ownership comes early because it is the dimension most often scored optimistically.
| Dimension | The hard question | A failure looks like |
|---|---|---|
| Availability | Can this data be read reliably during operating hours? | Extracts that depend on a person remembering to run them. |
| Quality | Are identifiers, amounts and statuses reliable enough to act on? | Duplicate entities and undefined status values in active use. |
| Ownership | Is there a named person answerable for whether it is right? | Every field is critical and no field has an owner. |
| Integration | Can changes to a source be detected rather than discovered? | Silent divergence between two reports of the same thing. |
| Access control | Can entitlement be resolved per record at run time? | One service identity with reach to everything. |
| Auditability | Can a decision be reconstructed with its inputs and rules? | No record of which version of a rule produced an outcome. |
| Operations | Who is responsible when a source changes or breaks? | The alerting goes to the team that built it, not the owner. |
Scoring honestly rather than comfortably
For each dimension, three states are enough: ready, partially ready with a named workaround, and not ready. Anything more granular invites a total that has no meaning. The discipline that makes the exercise worthwhile is that the person who answers each question must not be the person who will benefit from a positive answer — so the data engineer reports on integration, the business owner on definitions and authorisation, and the compliance or risk function on auditability.
Two rules keep it honest. First, 'partially ready' must name the workaround and who carries it; a partial without an owner is a no. Second, the assessor must record what would change the answer, which converts the assessment into the first item of a remediation plan rather than a verdict. The related question of what an agent can actually be allowed to do is covered in what an AI agent should be allowed to do inside an enterprise.
The checklist
This is the sequence to run. It is ordered so that each step produces the input to the next, and so that the first fortnight produces something usable even if the assessment is never finished.
- Name the specific decision the project is meant to support, and the person who owns that decision.
- List the entities involved and the fields required to make the decision, not the tables that happen to contain them.
- Confirm that each required field has a definition, a version and a named business owner, and record the ones that do not.
- Establish the baseline for the process the decision sits in: volume, correction rate and cycle time, measured over a stated period.
- Measure the duplicate rate on the key entity and decide the matching rule before any deduplication is run.
- Verify that each source change is detectable, and that somebody is notified when it happens.
- Confirm that entitlement can be resolved per record at run time, and document the policy for any entity where it cannot.
- Name the human approval point before the first consequential action, and state the reversibility of each action the system will take.
- Record, for every 'no' and every 'partial', what would change it and who owns that work.
- Write the recommendation — proceed, narrow the scope, or stop — with the evidence attached and a review date on it.
Steps three, five and seven are where most assessments fail, and they fail for organisational rather than technical reasons: an owner cannot be named because nobody has held that responsibility before, a matching rule does not exist because the duplicates have been tolerated, and entitlement cannot be resolved because the policy was never written. These are findings to be reported to the executive as such, not defects for the project team to absorb.
Interpreting the result without a score
The output is a decision with conditions, and there are only three defensible shapes. Proceed, when the decision-critical fields are available, owned and reliable, and the access model exists for the entities involved. Narrow, when the project can be scoped to a segment or an entity type where the answers are ready — a single region, a single product line, a single customer type — which is usually the prudent move and frequently the whole project. Stop, when the data required is owned by nobody and the definition work has no sponsor; in that case the useful deliverable is the assessment itself, which will be needed again by whoever retries.
Note what does not appear in the result: a readiness score presented to a board. Aggregating seven heterogeneous dimensions into one number invents a precision that does not exist and makes a defensible conditional recommendation look like an unjustified refusal. The conditions and their owners travel well through an organisation; a number does not.
What to do with the result
An assessment is only worth running if it is connected to what happens next. Treat the recorded conditions as the first backlog of the semantic work, with the named owners as the accountable parties, and schedule the review date before the project starts rather than after it stalls. Where the honest conclusion is that the definitions must be written before anything is built, the mechanism for doing that is described in from fragmented enterprise data to a shared business context, and the engineering that follows it is set out in how we approach enterprise data engineering.