“Are we AI-ready?” is by now a question that comes up in many boardrooms, usually as if there were a certificate somewhere you could apply for. There is not. AI-ready is an operational capability made up of six parts, and you can check for yourself where you stand. This article walks through them, with a test per capability that you can run within a week.
Kees Pronk
CEO
AI-ready means the information in your company is set up so an AI layer can reliably get answers out of it: connected, unambiguous, meaningful, protected, delivered on time and actively maintained. It is not a piece of technology you buy and not a certificate you earn.
The reason this distinction matters: a capability is built up in steps and you can stop at any point without the work being wasted. A technology choice is a purchase that only has value once the whole thing is in place.
There is a misconception that costs a lot of money: that AI and business intelligence are two separate tracks with their own budgets and their own vendors.
BI-ready means information is consistent and decision-ready. AI-ready is that, plus three things: knowledge that is governed, access in natural language, and automation with a boundary around it.
The six capabilities below apply to both. That makes the decision simpler than it is often presented. You do not have to believe in AI to start on this work, because you need the first half anyway to know what is happening in your business. Anyone who makes their reporting reliable is laying exactly the foundation an AI layer will later run on.
Connecting sources — reporting: reports that are no longer filled in by hand. AI: a model that sees the whole picture instead of a part.
Recording definitions — reporting: one number the board steers on. AI: answers that do not vary with how the question is phrased.
Semantic layer — reporting: reporting you can extend yourself. AI: questions in plain language that hit the right field.
Row-level access — reporting: customer portals without per-customer manual work. AI: an assistant that gives each user the right answer.
Delivery — reporting: signals instead of monthly reports. AI: actions instead of advice.
Stewardship — reporting: numbers that still hold up a year from now. AI: an AI you dare to let take part in decisions.
The systems that together contain the answer come together automatically and repeatably.
The trap is in the word “connected”. In practice that often means: someone exports it every Monday. That is not a connection. An export is a snapshot, it keeps no lineage, it does not complain when the source changes, and it hangs on a person with a calendar reminder.
A real connection pulls data without anyone thinking about it, remembers where every number comes from, checks that what arrives looks the way it should, and raises a signal when it does not.
Minimum requirement: every source that participates in a decision arrives automatically, with recorded lineage.
Test: ask which manual steps sit between a source system and the report the board sees. Count them. Then ask what happens if the person doing them is away for two weeks.
A concept means the same thing everywhere, and there is someone who can be named as the one who decides that.
This is the least technical and the most decisive capability. Ask three departments how many customers you have and you get three numbers, all defensible within their own logic. As long as people talk to each other, the conversation corrects that difference. As soon as a system or an assistant provides the answer, that correction disappears.
What usually goes wrong here is the solution, not the problem. A data dictionary is written into a document, everyone gets an email, and after three months it is out of date. Not from laziness, but because the document is not attached to anything. What does work: recording the definition in the place where reporting picks it up, so a change in the definition becomes visible in the report.
That comes with one thing that has nothing to do with technology. One person per concept who is allowed to decide what it means. Not a committee. One name.
Minimum requirement: for the ten concepts the business is steered on, it is recorded what they mean and who decides that.
Test: ask three people the same question about a core number. Count the different answers. Then ask who is allowed to decide which answer is the right one.
It is recorded what a field means and how it relates to the rest, in a place a system can read.
The difference with capability 2 is worth getting sharp. Definitions are about the concepts people talk about, like revenue and margin. Semantics is about the data itself: what a column means, which values it can take, and what those values mean.
Take a status column with the values 1, 2, 3 and 7. A model cannot know what those mean, so it guesses, and a language model guesses with a confident sentence. That such a value stands for something like “cancelled, but the contract runs to the end of the year” is usually known only to the person who once entered the code.
In most companies that knowledge sits with two or three people. They are the semantic layer, and they are documented nowhere. That works fine until they change jobs, or until you build a system that has to answer without them.
Minimum requirement: for the fields that participate in steering information it is recorded what they mean, including the meaning of codes and statuses.
Test: pick a random code column from your most important system and ask three people what the values mean. Check whether the answer is written down anywhere.
Who is allowed to see which answer is fixed at the level of the data and not at the level of the screen.
With dashboards, access is a screen question and that is manageable. With an assistant, that changes. It does not read one report but the underlying data, and formulates a new answer. That lets it combine things that never sat together on any screen.
A concrete example. An account manager asks which customers in his region have margin under pressure. Reasonable question. To answer it, the assistant looks in the margin data, and that table contains all customers. If the boundary lives in the screen he normally uses instead of in the data, that boundary is no longer there. He does not even have to ask for it.
The solution is called row-level security, access at row level. Every user only sees the rows that belong to them, regardless of the route through which they request it. Everything that runs on the data inherits the same rule: the dashboard, the portal, the export and the assistant.
This is the only capability where we do not propose an interim solution. Bolting it on afterwards means there was a period during which everyone could pull everything, and what was pulled in that period you cannot take back.
Minimum requirement: the access rule lives in the data layer and is inherited by every application that runs on it.
Test: ask what happens if someone asks the same question through another route. Through an export, for example, or through a new report someone builds themselves.
Insight arrives at the moment and the place where the decision is made.
Information has a shelf life that is shorter than most reporting cycles. A deviation you spot on day two is a phone call. The same deviation on day forty, in the monthly report, is a credit note. Same information, different value, thirty-eight days apart.
Companies mostly invest in the quality of the report and rarely in the speed, and that is understandable: quality is visible and speed is not. No one leaves a meeting thinking that the report was fine but arrived too late to act on.
Delivery also raises the question whether a dashboard is even the right format. A dashboard asks for someone who looks at it, and that is a habit that fades after three months. If the action is predictable, if you can write down in advance what should happen when a threshold is crossed, then that does not belong on a screen but in a message to the person who can do something about it.
Minimum requirement: for every recurring decision it is known how much time sits between a fact occurring and someone knowing about it.
Test: measure the lead time of one signal for one month. Compare that with the frequency at which it is acted on.
There are checks that notice when a source has changed, and there is someone who gets an alert about it.
Software that breaks you notice: you get an error. Data flows rarely break like that, they drift. A vendor renames a field, your connection keeps running, and that one column now arrives empty. In the report, a category that goes empty looks like a category in which nothing happened.
On a dashboard that is annoying, because eventually you see the kink. With an assistant there is no chart. There is only an answer in a sentence, and that sentence sounds just as confident in March as it does in December.
Stewardship also includes a test environment. The moment reporting takes part in decisions, a change in a definition is no longer a technical tweak but a change that will show up tomorrow in what the board sees. At Runderkamp four DTAP environments were set up for exactly that reason: development, test, acceptance and production.
Minimum requirement: there are checks on volume, throughput and ratios, with a recipient who receives the alert.
Test: ask when a source was last changed, how long it took before someone noticed, and how it was discovered.
At Runderkamp, active in food retail and catering, these capabilities came together around a concrete problem. A PLU, the code that identifies a product, meant something slightly different in different contexts. The same held for product names, packaging units and pricing agreements.
What happened: over 1,400 products and PLUs were standardized, around 170 suppliers were connected centrally, and around 600 current pricing records are maintained in one place with one meaning. Around that sit four DTAP environments.
The work was not in the technology of connecting. It was in the decision on what a PLU means from now on, and in holding to that decision when the first exception showed up. These are solution patterns, not guaranteed outcomes.
Take these six with you to your first conversation with a vendor, whichever vendor that is. If the conversation is only about the model or the tool and not about these six, then the conversation is about a demo.
1. Connected sources — do the systems that together hold the answer come together automatically?
2. Quality and definitions — does a concept mean the same thing everywhere, and who decides that?
3. Semantic context — is it recorded what a field means, not just what sits in it?
4. Security and access — does the access boundary live in the data or on the screen?
5. Delivery — does insight arrive at the moment the decision is made?
6. Stewardship — who notices when a source changes, and how long after?
These six capabilities describe what is needed. They say nothing about how much is needed, and that varies a lot by company.
If you work with one system that holds almost everything, capability 1 is largely already in place and your gain sits elsewhere. If you share nothing outside your own organization, capability 4 is considerably simpler. If you make monthly rather than daily decisions, capability 5 is less urgent.
What cannot be argued away is capability 2. A company that cannot appoint an owner per definition will not keep a solution alive after delivery. That is not a technical problem and it cannot be solved by a better vendor.
The nice thing about these six is that you can walk through them yourself, without a quote and without a project. The tests together cost a week and produce a more honest picture than any outside inventory.
What you do after that is another matter. Starting without that picture is a gamble, and postponing without that picture is a gamble too.
Author
CEO
Boards often ask for a better dashboard, while the real split is signalling versus reporting. One shows what happened; the other acts when it counts.
Kees Pronk
CEO
A portal that works at three clients often stalls at thirty. How row-level security and a multi-tenant setup replace manual rights work.
Kees Pronk
CEO
One shared report, each user only sees the rows they are entitled to. How boards share data with staff, partners and customers without losing control.
Kees Pronk
CEO
