Is your company ready for AI? Ask one workflow at a time.

The maturity assessment arrives as a radar chart. The company scores in the middle on every axis, and the recommendation is to “strengthen data foundations” before doing anything else. Nobody disagrees, and nothing starts.

Ask the question one workflow at a time instead. A workflow is ready when its data is reachable, it has a named owner, you can measure how it runs, its errors can be tolerated and caught, and the people involved have time to take part. Asked that way, the answer turns into a decision.

Why do company-wide maturity scores mislead?

They average across workflows that have little in common. Finance may be ready while field service isn’t, and a middling score describes neither. They measure inputs, such as strategies, platforms and licenses, rather than the conditions a specific workflow needs, and their advice is generic enough to delay everything.

Readiness is not a property of a company. It belongs to a workflow.

They also produce two opposite errors:

• False alarms. “Our data isn’t clean enough” stops a project that needs only two approved sources, such as the policy library and the order system, not the whole data estate.
• False confidence. Licenses bought, a data lake or an AI policy feel like readiness. None of them means a workflow has an owner or that its documents are current.

What does ready mean for a single workflow?

Five conditions, all specific to the work: reachable data, a named owner, a baseline you can measure, an error you can tolerate and catch, and people with time, meaning experts to write reference answers and users to try the pilot. The eighteen questions below test each one. Answer yes or no; “sort of” counts as no.

Which data questions come first?

1. Can you name every source the workflow needs? Systems, document libraries, mailboxes. “All our data” is not an answer.
2. Do those sources live in approved systems? Not in personal folders, chat threads or someone’s head.
3. Can the team get read access quickly, with the permissions people already have? Access that takes months to grant is a project of its own.
4. Is the information current, and does someone maintain it? An assistant built on an outdated library gives outdated answers with confidence, so clean up the documents first.
5. Can you pull a few hundred real past cases to test against? Without them there is no evaluation set and no way to prove quality.

Which people and process questions matter?

People

6. Is there a named owner who can decide and will still be there after launch? Without one, nobody defines good or runs the system.
7. Can the experts give time to write and check reference answers? Their hours are usually the scarcest input.
8. Do the people who do the work agree the problem is worth solving? If not, they won’t use the result.
9. Is it agreed what the time saved is for? Otherwise it disappears into other work.

Process

10. Can the process be described on one page, the same way by everyone who does it? If not, fix the process first.
11. Will it stay stable while you build? A workflow being redesigned, or whose core system is being replaced, is a moving target.
12. Can you measure volume, time per case and error rate now, or within two weeks? That baseline is what every later claim depends on.

Which risk, security and IT questions matter?

Risk and security

13. Do you know what a wrong answer costs, and which errors are unacceptable at any rate? This decides how much review the design needs.
14. Can a person review or reverse the output before it matters? If not, the tolerance for error may be too tight for AI.
15. Has the data been classified, including whether personal or special-category data is involved? Your data protection officer decides what that means for the project.
16. Is it agreed where the data may be processed: a provider’s cloud, your own cloud or your own servers?

IT

17. Can IT connect to the systems involved, read-only first, with a test environment?
18. Is there an approved way to use models, with provider terms reviewed, an acceptable use policy and someone to run and monitor the system after launch?

Count the yeses, but read the noes first. A no on questions 1–3, 6 or 13 blocks the workflow whatever the total: without reachable data, an owner or a known cost of error, a pilot has nothing to stand on.

What should you do when the answer is not yet?

Treat “not yet” as a finding, not a verdict. The noes name the first project:

• No data access: open access or consolidate the sources, the kind of work data and AI foundations covers.
• A process nobody describes the same way: fix the process, or the form, before anything else.
• No owner: name one, or drop the workflow. A workflow nobody owns is not waiting for technology.

An illustrative example: three candidate workflows at a manufacturer, run through the checklist.

• Supplier invoice matching is ready. Invoices and purchase orders sit in the ERP with read access agreed, the accounts payable lead owns it, and system timestamps give a baseline. It goes to discovery.
• Sales contract review needs data access first. Signed contracts live in personal drives and email threads, so its first project is moving them into the document system with basic metadata.
• An employee policy assistant has no owner. HR and IT each assume the other owns it, so it is parked until someone accepts.

Ready workflows then go into the prioritization matrix with the rest of the list.

One meeting, three workflows

Before the meeting, each candidate’s owner, or would-be owner, answers the eighteen questions with evidence. In the meeting, spend about twenty minutes per workflow: read the noes first, agree the blocker and write the next action with a name beside it. Leave with three decisions: one workflow to discovery, one to fix first, one parked or dropped.

To make the same check on measured evidence, the readiness review in a Discovery Sprint covers one or two workflows in about two weeks; the ways in compares it with the other formats.