Skip to content
Shenzhen · The Greater Bay Area · Earth

An AI Readiness Assessment Should Produce a Process Register, Not a Maturity Score

I have handed over maturity scores, and they were the cheapest document to produce and the least useful. What actually changes a spending decision is a ranked register of processes with their owners, their decision rules, and what each one costs every month it stays manual.

7 min read1,523 words
AI StrategyEnterpriseNot yet translated.

What should you be buying when you buy a readiness assessment?

A readiness assessment that ends in a maturity score has not answered the question you paid for. The only output worth the invoice is a ranked list of processes, each with a named owner, a written decision rule, and a monthly cost of staying manual.

I have produced the other kind of document. The deck is pleasant, the radar chart is legible, and the score — 3.1 out of 5, data foundations weak, governance emerging — survives exactly one steering committee. Then nothing happens. Nobody's name is attached to a number, the number has no unit, and you cannot hold a 3.1 up against a vendor's quote. The score answers a question about the room that filled in the questionnaire, not about the work the company does.

An AI readiness assessment earns its cost only if it ends in a ranked list of processes with named owners, written decision rules, and a monthly cost of staying manual; a maturity score contains none of those and cannot be compared to an invoice.

There is a simple test for whether an assessment was real. Could the recommendations section have been written before the interviews happened? In most maturity-score engagements, it could. The recommendations are the standard set — clean your data, define an AI policy, appoint an owner — and they would read the same for a logistics firm in Shenzhen and a hospital group in Manchester. That is not a finding. It is a genre.

What should a readiness assessment actually hand over?

Four artifacts, all of them yours to keep in an editable file:

A ranked process register. Ten to fifteen processes, ordered by what each one costs the business every month it continues as it is. Order is the product. An unordered list of forty candidates is a research dump, not a decision.

A decision rule per process, in the owner's own words. What triggers the process, what thresholds move it, who approves an exception, and what happens when the inputs are incomplete. Under 200 words, written by the person who does the work, not by the consultant. If the owner cannot write it, that gap is the finding.

A human boundary. Which steps stay with a person regardless of how well the model performs, and which role signs off when the system is wrong. A register with no boundary column produces automation that nobody will let near a customer.

The monthly cost of the status quo. In hours and in money, per process, computed from observed work rather than declared work.

OutputUnitWho uses itThe decision it supports
Maturity scoreNone — a dimensionless numberSteering committeeNone directly; usually a decision already taken
Ranked process registerMoney per month, per processProcess owners and the CFOWhich single process gets funded first
Written decision rulesWords, one rule per processWhoever builds the systemWhat the system must encode, and what it must never decide
Replay agreement ratePercentHead of operationsWhether the rule is knowable yet, or still tacit

How do you compute the cost of staying manual?

Sample, do not survey. Ask an operations lead how long a process takes and you will get a number that reflects how the process is supposed to run. Take twenty completed cases from last month — actual records, not recollections — and time or reconstruct each one. Use the median, then multiply. The median matters because the mean is dominated by the two horror cases that everyone remembers and nobody can fix by buying software.

For the rate, take the loaded annual cost of the role — salary plus employer contributions, benefits, and the software seat that exists only for this task — and divide by productive hours, not by 2,080. Time in meetings, training, and leave is real.

Here is the arithmetic on one process, with an illustrative loaded rate of $42 per hour so the shape is visible:

  • 2,400 invoice exceptions per month
  • 6.5 minutes median handling time per exception
  • 2,400 × 6.5 ÷ 60 = 260 hours per month
  • 260 × $42 = about $10,900 per month, or roughly $131,000 per year

The rate is invented; the hours are not. The hours come out of your own systems, and they are the part you should not accept on trust from anyone. If a vendor's proposal is $60,000 to build and $1,400 a month to run, the payback on that row is about six months, and you can now check that claim instead of being told about it.

Multiply the result by the number of rows. A register where the top five processes total 500 hours a month is a different conversation from one where they total 40, and you want to know which you have before you approve a discovery phase.

How do you know a decision rule is real?

Rules that exist on paper and rules that exist in behaviour diverge, and the divergence predicts whether a build will succeed.

The cheapest test I know: for twenty completed cases, ask the process owner to state the outcome before you show them the record. Compare. If the owner's prediction matches what actually happened in fewer than about four cases out of five, the process is being adjudicated by tacit judgment that has never been written down, and any system you build will encode a rule that is not the one being used. That is not a reason to abandon the process. It is a reason to spend three weeks making the rule explicit first, because that work is cheap and reversible, and encoding the wrong rule is neither.

Two names on the same row is another signal. If a process needs two owners to be described honestly, the boundary is wrong — split it into two rows, and the ranking will usually tell you that one half is worth automating and the other is not.

Which process should go first?

The one with the highest monthly cost of staying manual among the rows whose decision rule is already legible. Not the most complained-about process, not the most strategic-sounding, and not the one an executive saw at a conference. I have watched the loudest process in a company get automated first twice, and both times the build succeeded and the business case did not, because the volume was in a quieter process two rows down. The mechanics of that failure are worth reading in detail if you are about to sequence your own portfolio: the failure pattern where the loudest process gets automated first.

One property of the register deserves attention. If you compute cost with per-role loaded rates instead of a single blended rate, the ranking can change, because an hour of a legal reviewer is not priced like an hour of an AP clerk. That reordering is information, not noise. It tells you which process carries expensive attention rather than large volume, and expensive attention is usually where automation pays most per hour saved.

How should you buy a two-week version of this?

Put constraints in the proposal, because constraints are what stop the engagement from expanding into a score.

Ask forRefuse to pay for
A fixed number of processes, agreed in advance and cappedAn open-ended discovery phase with a phase-two decision
Interviews with the people who do the work, not only their managersWorkshops where nobody has done the process in two years
A spreadsheet you own, one row per process, one owner per rowA slide deck with a radar chart and an appendix of definitions
Observed handling times from sampled recordsSelf-reported time estimates collected in a survey
An explicit written "not ready" verdict for rows that deserve itA readiness percentage that implies everything is partly ready

The honest sizing rule: the assessment should cost less than one month of the cheapest process on the final register. If it costs more, cut the number of processes rather than the depth per process.

And the honest verdict has to be allowed. For some rows, the correct output is that the process is not ready because its rule does not exist yet, or because the volume is too low to justify fixed build and maintenance costs. A readiness exercise that never returns "not yet" is not assessing readiness; it is preparing a purchase.

What is the next concrete action?

Pick the process you complain about most in your own head, pull twenty completed cases from last month, and time them by hand this week. That single number costs you a few hours and it will either survive contact with the register or expose that the process you were about to fund is the wrong one. Then find the named owner and ask them to write the decision rule in 200 words; if they cannot, you have located your actual readiness gap, and it is cheaper to close by writing than by buying. A maturity score would have told you that you are a 3.1 and left you exactly where you started.

Keep reading

More in AI Strategy

Ready to build a system?[ Book a Call ]