Data Readiness | Blane Canada

Question 1

Is our data ready for AI?

Accepted Answer

Probably not, and that is normal. Most enterprise data was built for humans, not machines. It is fragmented and unstructured, it assumes a person will fill in gaps with judgment, and it captures only what human teams needed. An AI system has none of that judgment.

There is no AI strategy without a data strategy. That is not a slogan. It is the most reliable predictor of whether an initiative produces anything.

The diagnostic test is simple. Data designed for a human reader assumes the reader will supply context, resolve ambiguity, and know which version is current. Data designed for a machine cannot assume any of that. When you hand fragmented, inconsistent, human-oriented information to an AI system and it produces poor results, the model is not the problem.

The analogy I keep coming back to is deploying self-driving cars on roads with no lane markers, no signs, and no stoplights. The technology is remarkable. The environment was never built for it.

One correction to how this question usually gets asked. Data readiness is not a single company-wide score. It is specific to the use case in front of you. An opportunity can look attractive until you examine the information underneath it and find it spread across systems, maintained by hand, or reachable only through a workaround two people know about. That does not necessarily kill the idea, but it does mean data preparation is now part of the investment, and it frequently means a different opportunity with cleaner information should be the first project. This is why prioritization belongs after discovery rather than before it.

If your AI initiatives are not delivering, start by addressing your data before you evaluate another tool.

Question 2

What are the signs that our data is not ready?

Accepted Answer

Five signs show up repeatedly. Employees hunt for the right version of files. Different departments define the same thing differently. People build workarounds outside official systems. Reports need manual cleanup every week. And business knowledge lives scattered across PDFs, emails, and shared drives.

The first sign is spreadsheet archaeology. If your employees routinely spend part of their day hunting for the right version of a file, an AI system will run into exactly the same wall, because it has no way to know which version is authoritative either. What these systems need is structured, trusted, accessible information, and the fix starts with establishing one source of truth for the data that actually drives decisions.

The second sign is inconsistent definitions across departments. Sales describes a metric one way, finance another, and operations tracks something slightly different again. A person reconciles those differences instinctively in a meeting. A system cannot, and it will produce confident answers built on whichever definition it happened to find. Standardizing terminology and assigning clear ownership for each definition is unglamorous work that pays for itself the first time a report holds up under scrutiny.

The third sign is workarounds living outside your official systems. Shadow spreadsheets, personal notes, private AI prompts, and disconnected trackers accumulate when the sanctioned system is too hard to use or too hard to trust. Each one holds real business knowledge that no AI system will ever see, and each one leaves with the person who built it.

The fourth and fifth signs are related. If someone has to fix the numbers before every meeting, that is a data problem wearing a reporting problem's clothes, and automating the report will simply automate the error. And if your business knowledge lives in a scattered mix of PDFs, emails, Word documents, and shared drives full of folders named FINAL_v2_REAL, the knowledge exists but nothing can retrieve it reliably.

Two things make this harder to catch than an ordinary data problem. The first is that a capable model does not fail loudly on weak information. It produces a confident answer built on whichever version it happened to find, so the problem becomes less visible rather than more. The second is that conflicting definitions are a governance question rather than a technical one. No system can settle an organizational disagreement about which number is correct. Someone has to decide which source is authoritative, who may update it, and what happens when an inconsistency surfaces. Data governance is part of AI governance, and it is usually the part nobody assigned.

Real progress here usually starts with boring work: cleanup, governance, structure, and ownership rather than demonstrations. That is exactly why it gets skipped, and exactly where the return actually comes from.

Question 3

Do we have to clean up all our data before we start?

Accepted Answer

No. You have to clean the data that the first project touches. Fix it a bit at a time, workflow by workflow. Waiting for enterprise-wide data perfection is how companies spend two years preparing and never start.

We worked with a client who was overwhelmed by years of inconsistent, duplicate, and incomplete business information. Before we touched AI, we spent nearly two weeks cleaning and organizing the foundation. Their reaction afterward said everything: "I can finally breathe again."

That was not because we deployed a flashy tool. It was because the business finally had clarity. Cleaner data meant faster reporting, fewer mistakes, less frustration, and more confidence in decision-making. The AI work that followed was easier and cheaper because of it.

The practical path is narrow and sequential. Identify your most-used business knowledge. Centralize it. Remove duplicates and outdated files. Standardize naming and formatting. Define who owns and updates the information. Then build on that one clean foundation and repeat.

A simple place to start is with four honest questions. Do different teams use different versions of the same data? Are employees manually fixing spreadsheets every week? Can you quickly find accurate information when you need it? Do you trust your reports? If the answer to any of those is "not really," start there.

Question 4

Our AI tool cannot find the answers our people need. What is wrong?

Accepted Answer

Almost always the format, not the model. We worked with a client who wanted an AI-powered self-service help desk. Their information lived in PDFs, Word documents, old spreadsheets, and inconsistent formats scattered across the company. The AI was not the issue. The data was unreadable to it.

Before building anything for that client, we converted and standardized their information into a structure the system could actually use. The result was that employees could finally get fast, accurate answers without digging through folders or emailing HR for basic questions.

The lesson generalizes. AI is only as useful as the information it can access and understand. If your company knowledge is buried in disconnected files and inconsistent formats, an AI tool will struggle exactly the way your employees already do. What looks like a weak tool is usually a condition that was already costing you and was simply invisible, because people compensated for it with effort.

The practical starting point is narrow. Identify the knowledge people ask for most often. Centralize it. Remove duplicates and outdated versions. Standardize naming and formatting. Then decide who owns keeping it current, because an accurate knowledge base with no owner is a temporary condition.

Two specific failures cause most of this. If five versions of the same policy exist, the system has no way to know which is current, so it answers from whichever one it retrieves. And if different documents use different words for the same thing, retrieval degrades quietly rather than obviously. The technical capability is not in question. The organizational work is making the information orderly enough that the tool can use it without introducing confusion.

You may not need more AI. You may just need information the tool can actually read.

Question 5

Our data is clean. Why is that still not enough?

Accepted Answer

Clean data lacks intent. A system can know a customer's balance is $5,000 without knowing whether that customer is high value, whether the balance is overdue, or whether a support ticket is open on it. Structure tells the machine what the data is. Context tells it what the data means.

A great deal of money has been spent cleaning data over the past decade, and it was money well spent. It is also not sufficient for the kind of work companies now want AI systems to do.

The gap is meaning. Cleaning makes data consistent and accessible. It does not encode the relationships between pieces of information that a person would supply automatically. An experienced employee looking at that $5,000 balance instantly knows whether it matters, because they carry the surrounding context in their head. A system has to be told.

That is why the work is moving toward layers that sit on top of structured data and describe the relationships between data points. It is the connective tissue that explains how things relate to each other, and it is what turns retrieval into reasoning.

The practical implication for an executive is that your data investment does not end when the records are clean. Someone has to define what the records mean in a way a system can use. If your team is only moving rows and columns, you have completed the first half of the job.

Question 6

We collected a lot of information but nobody can use it. What now?

Accepted Answer

You have solved the collection problem and walked into a management problem. That is a normal and predictable sequence. The answer is a structure that holds the information over time, with defined ownership, rather than another round of collection.

I have lived this exact progression. Years ago we built an interview tool for a profession that had never gathered structured information from its clients. The response was immediate and consistent. Great information. Absolutely useful. Then came the question that changed everything: how do I organize and manage all of this?

We had solved the information problem and walked directly into a data management problem. Every interview produced structured intelligence. Multiply that across dozens of companies, several staff members, and multiple years of visits, and the volume becomes unmanageable without a system built to hold it. The software business that followed was born out of necessity rather than ambition.

The lesson carries directly into AI work today, and it is why our builds start with a warehouse rather than a report. A report is what you look at. The stored record underneath it is what compounds. One row per person per day, with the underlying detail preserved, is not a snapshot. It is an asset that gets more valuable every month and makes the next phase of work possible.

If you have collected information you cannot use, do not collect more. Build the structure that holds what you have.