Excel Partners
Insights

Research

Your data is readier than you think

Teams postpone AI for a warehouse rebuild they do not need. What actually has to be true before an agent can do useful work, and what can wait.

The most common reason a useful AI project does not start is a sentence that sounds responsible. Our data is not ready. It is sometimes true. More often it is a warehouse migration wearing the costume of a prerequisite, and it postpones work that would have succeeded on the data you already have.

What actually has to be true

For a system to do useful work against your data, a short list of things need to hold. The data has to be reachable by a program rather than only by a person. Records need to be identifiable, so the same customer is the same customer across two systems. Permissions need to be expressible, so the system can be told what it is not allowed to see. And someone needs to know what the fields mean.

That is close to the whole list. Notice what is not on it: a single warehouse, a completed migration, consistent historical backfill, or a governance programme that has finished.

What can wait

Historical cleanliness is the big one. Teams routinely block on the idea that five years of messy records must be fixed first. For most use cases the system is working with the last ninety days, and the state of a record from four years ago is irrelevant to whether it can draft a reply today.

Full consolidation can wait too. Reading from three systems through three well-defined interfaces is unglamorous and it works. The consolidation project is worth doing for other reasons. It is not a precondition for this.

The thing that is genuinely blocking, and gets ignored

Semantics. Not whether the data is clean, but whether anyone can say what a field means. We have seen a status column with eleven values, four of which are no longer used, two of which mean the same thing for historical reasons, and one which means something different depending on which team wrote the record.

No amount of infrastructure fixes that, and no model will guess it correctly. The work is an afternoon with the person who has been there longest, writing down what each value actually means. It is the least fashionable task on any data roadmap and it unblocks more than the migration does.

A test you can run this week

Pick one real task. Take fifty recent cases. Can a person, given only what the system would be given, do the task correctly? If yes, your data is ready for that task. If no, note exactly what they had to go and look up, because that is your actual gap, and it is almost always narrower than the migration you were about to fund.

  • If they needed a different system, you need an integration, not a warehouse.
  • If they needed to ask a colleague, you have a semantics problem, not a data problem.
  • If they could not do it at all, the task is wrong, not the data.

Readiness is per task, not a property of the organisation. Asking whether the data is ready in general produces a general answer, which is always no. Asking whether it is ready for one specific job usually produces a yes, and that is enough to start.