How do you know whether your organisation is ready for AI?

Being ready for AI sounds like a state you reach. As though there is a moment when you are through it and allowed to start. It does not work that way, and that assumption is exactly why companies spend years waiting for a starting signal that never comes.

Readiness breaks down into four things that can independently hold or not hold. You can have excellent data and still be unable to start. You can have messy data and be running a working application next month. What decides the outcome is which of the four is your binding constraint.

All four are below, each with a test you can run today.

Why this question nearly always gets answered wrong

Search for it and you get checklists from parties selling software. Those checklists cover infrastructure, data volume, integrations. Not because those are the most important questions, but because those are the questions their product answers.

The question an owner or director is asking is a different one. It is not whether it is technically possible, because technically almost anything is. It is whether it will land in this company, with these people, alongside the actual work. That is an organisational question, and a product checklist has no answer to it.

Stacks of paper files. Data readiness is not about volume, it is about whether the same word means the same thing everywhere.

Four kinds of ready

The last row is the most important and appears in virtually no checklist.

One: data

The reflex is to think in volume. Do we have enough data. That is almost never the problem, because most companies this size have years of orders, hours, quotes and tickets lying around.

The problem is meaning. In a company with any history, the word customer means something different in the ERP than in the CRM. Sales counts an order at signature, finance at delivery. Neither is wrong, they were defined for different purposes, and nobody ever reconciled them.

In daily work you notice none of this, because people carry the translation in their heads. Point a model at that data and there is no head to carry it in, and out comes a confident number averaging two definitions.

The test: ask three people from three departments what an order is and when it counts. Three answers means that is your first piece of work. This is not a multi-year programme, incidentally: a semantic layer records that meaning on top of your existing systems without migrating anything.

Two: people

Every application worth anything needs hours from the people who know the work best. Those are by definition your busiest people, and their time appears in no budget because nobody invoices for it.

This is not about technical knowledge. It is about the person who knows which customer always gets an exception, why that one supplier is handled differently, and which rule in the handbook has been wrong for three years. That knowledge is written down nowhere and is exactly what makes an application usable rather than demonstrable.

The test: can you name a person right now, plus a day of the week on which they have four hours free? If not, that is your binding constraint, and no supplier solves it for you.

Three: processes

This is the question of whether it pays, and it is simpler to calculate than people think: hours of manual work per year, times the loaded hourly rate, times the share you actually remove.

The worked example on our site takes a process of 1,200 hours a year and lands at roughly EUR 68,000 saved, with payback under three months. That same sum immediately shows where it does not add up. A process of two hundred hours a year almost never pays back, however impressive the demo.

The goal, moreover, is rarely to replace people. It is to get more out of the people you already have by taking the repetitive work off their plate. That changes the arithmetic: you are not counting redundancies, you are counting capacity freed up for work that does generate revenue.

The test: name a process consuming more than five hundred hours a year whose output can be checked. If you have none, AI is not your priority yet, and that is a perfectly legitimate conclusion.

Someone at work in a production environment. The people who know the exceptions are the ones a project cannot do without.

Four: decision-making

This is where it most often breaks down in practice, and the only one that never appears in a checklist.

Suppose it works. The system proposes scheduling that order differently, pricing that quote differently, routing that ticket differently. Who is then allowed to decide that this is how it works from now on? And what happens when the system gets it wrong once?

Without an answer to those two questions you get the pattern we see most often: technically everything works, everyone is enthusiastic, and nothing changes. The suggestion gets overruled by a human every time just to be safe, and after three months someone switches it off.

The workable answer is usually human on the loop: the system acts and a named person supervises and can intervene. Not approving every action in advance, because then that person becomes the bottleneck and stops reading within two weeks.

The test: name the person allowed to decide this is how it works now, and the person allowed to stop it. If that is zero people or five, you have work here.

The order in which you tackle them

The four are not equal, and that saves months. They have an order that follows from what goes wrong when you reverse it.

Start with decision-making. Not because it is the most fun, but because it is the cheapest and determines everything after it. An hour-long conversation recording who may decide and who may stop it costs you nothing and prevents the most common ending of an AI trajectory.

Then processes. Without a process of sufficient volume, the rest is an academic exercise. This step is arithmetic rather than research: you probably already have the hours somewhere in a time registration or planning system.

Then people. Now that you know which process it is, you also know who knows it. That is usually one or two names, and names are concrete enough to free up time for.

Data last. That feels wrong, because data looks like the foundation. But you do not need your data in order in general, you only need the terms within this one process to be unambiguous. That is a fraction of the work, and only after the first three steps do you know which fraction.

Anyone starting in reverse order, which is what most companies do, begins a data project with no end date and never gets to the other three.

Three signals that you are better off waiting

Not every company should start now, and establishing that honestly is worth more than a trajectory that stalls halfway.

The first signal is a reorganisation or system migration already under way. If the ERP is being replaced next quarter, the meaning of your data changes and the process changes. Everything you build now you will build again.

The second is that nobody on the management team can answer why you are starting. Cost saving is an answer, growth without extra headcount is an answer, competitors are doing it is not. Without your own answer the priority evaporates at the first disappointing quarter.

The third is an earlier attempt that quietly died and was never discussed. If there are people in the company who think this will be another one of those, that is a real problem technology does not solve. Name what went wrong last time first.

Where you stand relative to everyone else

Figures help you judge whether you are behind or simply careful.

The bottom two rows are the interesting ones. Between wanting to and having a plan sits a gap of more than fifty percentage points. Which means the competition in your sector is probably searching just as hard as you are, and whoever has a concrete plan first gains an advantage that is not about technology.

That AI users apply it to logistics in only 4 percent of cases is a second signal. Attention goes to marketing and sales, where it is visible. The money is more often in the dull processes nobody posts about.

What ready does not mean

Ready does not mean everything is in order. That is true of no company, including the ones that look ready in interviews.

Ready means: there is one process we know costs enough hours, the data underneath it can be repaired without replacing a system, there is someone who knows the work and gets time, and there is someone allowed to decide this is how it works now.

Four things. No more. Anyone waiting until all four dimensions hold across the whole organisation waits forever.

The reverse is also true and gets said less often. A company scoring excellently on all four dimensions but with no process consuming enough hours is not ready for AI. It is ready for something else.

The test in five questions

Go through them honestly, in ten minutes.

1. What is an order, and do three departments give the same answer?
2. Which process costs more than five hundred hours a year?
3. Who knows the exceptions in that process, and does that person have time?
4. Who is allowed to decide it works differently from now on?
5. What will show us in six months that it worked?

They are deliberately in this order. Questions one and two you can check yourself, questions three and four require a conversation, and question five forces you to imagine now what the conversation looks like in six months.

Answer three or more and you can start. Answer one and you now also know exactly where to start, which is worth more than a general recommendation to get going.

Where to begin

If you want to move through this quickly: the AI Photo is a free twelve-question self-scan taking ten minutes that runs along exactly these dimensions. No obligation, but an honest read on where you stand.

If you want a substantiated plan after that, the AI Readiness Scan delivers the opportunities ranked in ten working days, costed on your own figures, with a roadmap you can take into the boardroom.