Most AI projects that stall do not stall on the model. They stall on the question of which number is the right number. This article explains why that is, why AI makes that weakness more visible than reporting ever did, and in which sequence you actually build it up.
Kees Pronk
CEO
A data foundation is the whole of connections, definitions, meaning, access rules and stewardship that makes information from separate systems usable for decisions. It is not a product and not a server. It is a capability you build up and maintain, just like bookkeeping.
That comparison with bookkeeping is more useful than it seems. Bookkeeping is not exciting either, the work also sits in agreements and discipline, and you also only notice it is missing the moment you have to answer a question you need a hard answer to.
Almost every company we speak to already has the information. It just sits spread across systems that were never designed to work together, and that were each bought for good reasons.
An ERP that knows the customers and the invoices. A service desk that knows the tickets. A planning package that knows the hours. Measurement software or an industry-specific package that captures the actual work. And around that, a collection of spreadsheets in which people have filled the gaps between those systems.
That is not sloppiness. It is the normal result of fifteen years of sensible individual purchases. For years, spreadsheets were the best available solution for exactly that problem, and in some places they still are.
What sits under a failed AI pilot almost always falls into four categories.
“We already have everything connected” in practice often means: someone exports it every Monday. An export is a snapshot without lineage. If the source renames a column, the export just keeps running with an empty column and no one gets an alert. And if that person is on holiday, there is no data that week.
Ask three departments how many customers you have and you get three numbers. Sales counts accounts, finance counts debtors with revenue this year, service counts active contracts. All three are correct. All three measure something different. As long as people talk to each other, the conversation corrects that difference. Software does not talk back.
In almost every database you find columns with codes whose meaning has never been written down. A status column with the values 1, 2, 3 and 7, where that last value was entered once for a specific case and is now only known to one or two people in administration. They are the semantic layer of that company, and they are documented nowhere.
As long as people reach data through reports, you can manage access per report. That works right up until a second route is added: an export, a portal, or an assistant that reads the underlying data itself.
This is the point the article turns on, and it is rarely made.
A dashboard shows a number in context. You see the chart next to it, you see the previous period, you see that the line has an odd kink. If something is off, it stands out and you pick up the phone. The format itself invites doubt.
A language model gives you a sentence. Fluent, complete, confident. There is no margin of error attached, no source, and above all no note that the question could be interpreted in three ways and that the model picked one.
It increases the speed and the scale at which the consequences of that weakness spread.
That is not because the technology is bad. It is because a language model is built to always answer. Ask it about your revenue with your ten largest customers and it gives a number, even if three systems use three revenue definitions. You do not get a warning that the question was ambiguous. You get an answer.
So the risk is not that AI does not work. The risk is that it works convincingly on a foundation that does not deserve it.
There is a sequence in this work and it cannot be reversed. Each step leans on the previous one.
Automation amplifies what is already there. Automate a process in which one concept has three meanings, and you produce those three meanings faster and at greater scale. That is why step two cannot be skipped, however tempting that is because it is the least technical and most political step.
The practical translation of that sequence is shorter than people expect, and that is by design.
The temptation is to make steps three and four as broad as possible and only then deliver something. We have tried that. The result was an architecture the builders were rightly proud of and that the business had nothing to do with for six months. In those six months the urgency evaporated and the question “what was this for again” was slowly asked in earnest.
Start with one thin, valuable flow from source to outcome. Make the architecture underneath reusable, but do not build the whole future platform before the first business result has been proven.
CentreBlock delivers impact analytics to several customers at once. Every customer wants to see their own numbers, no one may see anyone else’s, and comparisons across periods have to be meaningful.
What was built: over a million visitor records flow in structured, eleven KPIs have been standardized so every customer is measured by the same yardstick, and seven comparable reporting periods have been set up so a change really is a change and not a difference in method. On top of that runs the patented Impact Score.
The outcome that mattered: the reporting lead time went from days to minutes.
What belongs alongside that: this worked because the question was sharp. CentreBlock knew exactly which outcome it needed, and that made the choice of which sources did and did not participate easy. These are solution patterns, not guaranteed outcomes.
Data foundation: The whole of connections, definitions, meaning, access and stewardship that makes information usable for decisions.
Connector: Software that pulls data from a source system automatically, including validation and lineage.
Semantic layer: The place where it is recorded what a field means and how it relates to other fields.
Row-level security: Access at row level: every user only sees the data that belongs to them, regardless of the route through which they request it.
DTAP: Development, test, acceptance and production: four separate environments in which a change is built, tested, approved and only then rolled out.
The question we start every engagement with is not about technology, and the answer rarely comes from the IT side.
Which recurring decision, manual action, reporting process or service to your customers would improve most if the underlying information were connected, reliable and securely available to the right people?
Try that question on someone in your company who is not responsible for it. Usually that person knows the answer exactly, and has just never been asked.
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
