How to Run an AI Readiness Assessment in Two Weeks

Every enterprise AI programme begins with some version of the same question: are we ready? It is a fair question, and the usual answer is a quarter-long study that ends in a maturity spider chart and a slide titled 'recommended next steps'. Six months later the chart is stale and nothing has shipped.

A readiness assessment is worth doing — but only if it is scoped as a decision-making exercise rather than a diagnostic one. Done properly it takes about two weeks, and it ends with three things: the two or three use cases you should build first, the constraints that have to be fixed alongside them, and the baseline numbers that will later tell you whether it worked.

What readiness actually measures

Readiness is not a judgement about how sophisticated your technology is. It is a judgement about whether your organization can get an AI system into production and keep it there. Programmes rarely fail because the model was not good enough; they fail because nobody could get access to the data, because the process had no owner willing to change how the work runs, or because no one agreed in advance what result would justify scaling. Those are the things an assessment should be looking for.

Five dimensions worth scoring

• Adoption — is AI absent, running as isolated experiments, live in a few production use cases, or embedded in core workflows? This calibrates how ambitious the first project should be.
• Data — scattered across systems and spreadsheets, centralized but inconsistent, a governed warehouse with named owners, or genuinely AI-ready with pipelines, catalogs and quality SLAs.
• Process automation — mostly manual, scripts and macros in pockets, RPA or workflow tools on several processes, or orchestrated automation with monitoring. Processes that are already instrumented are the cheapest ones to hand to AI.
• Governance — no policy, informal guidelines, defined controls for some use cases, or an enterprise-wide responsible-AI framework. Governance is what lets you say yes faster, not slower.
• Measurement — not measured, anecdotal, per-project ROI reviews, or continuous value tracking against baselines.

Score each from 1 to 4 for a total out of 20. The headline number matters less than the shape: an organization scoring 4 on data and 1 on governance has a completely different next move from one with those scores reversed. The first needs a policy and risk tiers written before it scales what it is already capable of building; the second needs a data foundation before any of its governance work has something to govern. These are the five dimensions behind the free AI maturity self-assessment on our homepage — five questions, two minutes, and a band with the moves that fit it.

A two-week schedule

• Days 1–3: interviews with process owners in the functions carrying the most manual volume — finance operations, customer service, legal, supply chain. Ask where work backs up and what people redo, not where they would like to use AI.
• Days 4–5: a data walk-through with the people who actually maintain the systems. Where do the records live, who owns them, how would a system read them, and how good are they on a bad day rather than in the demo extract?
• Days 6–8: score the five dimensions from evidence — a document you were shown, a queue length you were given, a policy that exists — rather than from self-report. Self-reported maturity is consistently one band optimistic.
• Days 9–10: build and size the use-case shortlist, then run the readout with the sponsor and the process owners in the same room.

Two weeks is not a shortcut; it is a constraint that keeps the exercise honest. Anything that cannot be established in ten working days is usually something you will learn faster by building the first use case than by studying it further.

Score the use cases, not just the organization

The organizational score sets ambition. The actual deliverable is a ranked shortlist, and each candidate should survive four questions.

• Is the outcome objectively checkable? The invoice posted, the ticket resolved, the clause flagged and accepted by a reviewer. If success is a matter of opinion, you will never be able to widen autonomy safely.
• Does the data already exist and is it reachable today, without a new integration programme sitting in front of it?
• Is there an escalation path — a human queue that already absorbs exceptions and can absorb the AI's?
• Is there a named process owner who will change how the work runs, not just a technology sponsor who will fund a pilot?

The fourth question is the one that disqualifies most candidates, and it is the one most assessments skip. A use case with an enthusiastic CIO and no operational owner produces a pilot that works and an operation that never changes. When two candidates score similarly, take the one whose owner is in the room.

What 'not ready' usually means

In practice, a low score almost never means do not start. It means start somewhere specific and fix the rest in parallel. Data scattered across the estate is not a blocker if one well-governed source exists for the one process you care about — that is where you begin. No AI usage policy is not a reason to delay a document-extraction use case with a human reviewer on every output; it is a reason to write a one-page policy and a risk-tier list alongside the build, which is a fortnight of work rather than a committee.

The genuine blockers are narrower than most steering committees assume: no owner willing to change the process, an outcome nobody can measure even manually, or a regulated decision whose output you cannot explain to the person it affects. Everything else is a sequencing problem.

What the readout should contain

• A score per dimension with the evidence behind it, so the number can be argued with rather than believed.
• Two or three use cases ranked by value against effort, each with a baseline already measured — current cycle time, current cost per transaction, current error rate.
• The fixes that run in parallel with the build: policy, data access, integration work, and who owns each.
• A first ninety days with an explicit decision point — what result at day 90 means expand, and what result means stop.

What assessments typically surface

The value of the exercise is usually in what it corrects. For a global building-materials manufacturer, the assumption going in was that invoice extraction was the constraint. The assessment showed extraction was largely solved by modern models; the real cost sat in purchase-order matching rules and tax variation across twelve country entities. Scoping the programme around validation and a feedback loop rather than around OCR is what carried it to 78% touchless processing.

For an enterprise SaaS company with 150,000 internal documents, the presenting request was a chat assistant. The finding was that documents were findable but not trustworthy — several versions of the same answer, no way to tell which was current. The requirement that mattered was permissions and cited sources on every response, not conversation quality. Both of those corrections cost two weeks to discover and would have cost two quarters to discover by building.

A readiness assessment is not a gate you pass. It is the cheapest available way to avoid building the wrong first thing — and the fastest way to give a sponsor a shortlist they can actually fund. If you want a starting read before committing anyone's calendar to it, the five-question self-assessment on our homepage takes two minutes and scores the same five dimensions.