Most AI planning starts with a list of use cases.
Which tasks take too long? Where could a team use an assistant? What could we automate?
Those are reasonable questions, but I think they come too early. Before deciding what AI should do, you need a clear picture of what the business already knows and whether that information can be used reliably.
An AI system may be perfectly capable of performing a task and still produce little value. The information it needs could be scattered across several systems, duplicated, out of date, locked away, or inconsistent. In some cases, the business itself hasn’t decided which source is right.
That’s why I’d start with data capability mapping. The point isn’t to create an exhaustive inventory of every field and database. It’s to understand what the company could do if the right information were connected, and what needs to be fixed before that becomes possible.
A list of systems won’t tell you what the business knows
Most companies can name the software they use.
Customer records are in the CRM. Support tickets are in another platform. The accounting system holds transactions. Project work is tracked somewhere else. Important decisions are buried in email or Slack. And there’s often a spreadsheet that everyone trusts more than the official dashboard, which is usually worth investigating.
A system inventory tells you where information might be. It doesn’t tell you whether that information is current, accessible, understood, or safe to act on.
To figure that out, I want to know what each system is supposed to own, who maintains it, and what other work depends on it. I also want to know where people go when two systems disagree. The answer may be a documented rule, but it may also be one experienced employee who knows which number is probably right.
That employee is doing more than looking something up. They’re holding part of the company’s operating logic in their head.
A useful data capability map makes that logic visible. It shows what the company can understand and do when information is connected, not just which tools it has purchased.
Look at data, access, understanding, and action
I use four layers to make the map practical: data, access, understanding, and action.
Data is what the company knows. That may include customer details, contracts, transactions, support conversations, product activity, project status, employee knowledge, or years of operational history.
Access is where that information lives and how it can be retrieved. A company may have exactly the information it needs, but it sits in a closed system, an inconsistent spreadsheet, or a document that only one person knows exists.
Understanding is what becomes visible when several sources are considered together. Product activity tells you one part of a customer’s story. Support history tells you another. Contract terms and recent conversations add context. Together, those sources may help the business understand account health, renewal risk, expansion opportunities, or recurring product problems.
Action is what can safely happen next. Can a system update a record, create a task, send an alert, or draft a response? Does someone need to approve the decision? Is there a reliable place to record the result?
These layers matter because companies often jump from “we have the data” to “we can automate the decision.” There may still be several gaps between those two statements.
The requested output is rarely the whole opportunity
Suppose an account manager asks for an AI tool that writes a weekly account summary.
That sounds useful. It could save time. But I’d want to see how the account manager creates that summary today.
They may check the CRM, review recent customer conversations, look at product activity, search for open support issues, confirm contract details, and decide which information is current enough to trust. Writing the summary might be the shortest part of the process.
The harder work is reconstructing the customer context behind it.
Once that becomes visible, the opportunity changes. If the underlying information can be connected reliably, the company may be able to build a broader customer intelligence capability. The same foundation could support meeting preparation, account health reviews, renewal planning, support escalation, forecasting, and executive briefings.
The weekly summary is one output. The reusable capability is a trustworthy view of the customer.
This distinction matters because several teams may request different automations that depend on the same information. If each request becomes a separate project, the company can end up building the same integrations repeatedly, applying different logic to the same records, and producing outputs that disappear as soon as the immediate task is finished.
A capability map helps you see the shared foundation before you build the individual tools.
Missing information is part of the answer
The mapping process will also reveal places where automation should wait.
Two systems may disagree about contract value. Customer status may be updated inconsistently. An important exception may exist only in someone’s memory. A system may be able to read the information needed for a decision but have no safe way to record what happened afterward.
Those findings aren’t failures. They’re useful design information.
An AI system can’t reliably apply a rule that the business has never made explicit. It shouldn’t be expected to guess which source is authoritative. Connecting more systems won’t help if nobody trusts the information being connected.
Sometimes the best first project is cleaning up a field, assigning ownership, connecting two systems, or documenting how a decision is actually made. That work may sound less exciting than launching an AI agent, but it creates the conditions for automation people can rely on.
It may also reveal that AI isn’t needed for part of the problem. If the task follows a stable rule and the information is structured, a query or a straightforward automation may be the better choice. The purpose of the map is to clarify the work, not to justify a particular tool.
Keep the exercise close to the work
Data capability mapping doesn’t need to become a six-month governance program.
I’d start where the business already feels pressure. Choose a few important workflows and follow the information through them. What does someone need to know to complete the work? Where does that information come from? Which source should be trusted? What do they compare or reconcile? What action follows, and where is that action recorded?
Talk to the people doing the work. They know which report is stale, which field is routinely ignored, and which customer requires special handling that never made it into the documentation. They can also tell you why the process developed that way, which is often the difference between fixing the workflow and automating a workaround.
The map should make three things easier to see:
- capabilities the business already has
- capabilities that are one or two connections away
- gaps that need to be resolved before automation makes sense
If the result is a beautiful diagram that nobody uses to make a decision, you’ve created another information-maintenance problem.
Build the foundation once
The real value of data capability mapping isn’t the map. It’s the change in how the company chooses automation work.
Instead of collecting a separate AI wish list from every team, you can look for places where people repeatedly reconstruct context that already exists somewhere in the business. You can identify information that supports several workflows, clarify who owns it, and decide whether the company is ready to act on it safely.
That produces a more useful plan. Some opportunities will be ready now. Some will need a small amount of cleanup or connection. Others will turn out to depend on decisions the business hasn’t made yet.
Once you can see those differences, AI planning becomes much more concrete. You’re no longer looking for somewhere to put a new tool. You’re deciding which business capabilities are worth building and whether the information underneath them is strong enough to support the work.