Five signs your data environment isn’t ready for AI and what to do about it

Most AI efforts stall for the same reason: leadership cannot trust the inputs. Teams talk about models, tools, and use cases, but day‑to‑day reality looks like this: a new question comes in; people pull three reports, reconcile in a spreadsheet, and ship a number everyone argues about anyway.

That is not a modeling problem. It is a data environment problem. Until the environment can produce reconcilable, repeatable answers, AI becomes a fast way to generate outputs no one will adopt.

Below are five signs we see repeatedly in mid‑market manufacturers and distributors. If you recognize two or more, the right move is foundation work before any AI program.

Sign 1: Core metrics mean different things to different teams

If revenue, margin, inventory turns, OTD, or scrap has multiple definitions, AI will not fix the disagreement. It will make the disagreement more expensive.

What it looks like:

• • Finance and operations reconcile margin every month.

• • Two dashboards show two answers.

• • The “final” number is whichever one wins the meeting.

What to do about it:

• • Choose one definition per metric and write it down.

• • Tie the definition to source fields and transformation logic.

• • Assign an owner who is accountable when definitions drift.

Sign 2: Business logic lives in spreadsheets and reports

In many environments, the most important logic is buried in an analyst’s Power BI model, an Excel macro, or a private SQL script. That logic is the business. It is not visible, auditable, or reusable.

What it looks like:

• • “That report is wrong unless you apply this filter.”

• • A spreadsheet has become the system of record.

• • People hesitate to change pipelines because they do not know what will break.

What to do about it:

• • Move logic upstream into the data layer.

• • Normalize calculations into shared models (cost, margin, allocation).

• • Treat “definitions and logic” as an asset, not a byproduct.

Sign 3: ERP data is being queried directly for analytics

ERPs are built for transactions. Analytics needs stable, curated structures. When teams query ERP tables directly for reporting and experimentation, they inherit timing issues, duplicated values, and transactional artifacts.

What it looks like:

• • Reports are slow and brittle.

• • The same entity exists multiple times with different keys.

• • A change in ERP configuration breaks reporting without warning.

What to do about it:

• • Create a curated analytical layer (even if small at first).

• • Separate transactional reality from analytical truth.

• • Add lineage so people know where numbers came from.

Sign 4: Data ownership is implicit

Ask who owns customer, product, pricing, and cost data. If the answer is a department name instead of a person, ownership is missing.

What it looks like:

• • Conflicts are “resolved” by whoever speaks loudest.

• • Changes happen without notification.

• • Quality issues are discovered by executives.

What to do about it:

• • Assign owners for critical domains.

• • Define what owners do: approve definitions, adjudicate conflicts, sign off on changes.

• • Build simple governance that protects trust without slowing delivery.

Sign 5: Every new question triggers reconciliation

Reconciliation is the tax you pay when the environment is not coherent.

What it looks like:

• • New CFO asks for a margin view the team spends two weeks reconciling.

• • A board question becomes a scramble.

• • Analysts stop taking requests because it is never “just one report.”

What to do about it:

• • Fix the root causes that create reconciliation (definitions, logic placement, ownership, lineage).

• • Prove trust with a small set of high‑value metrics.

• • Expand only after repeatability exists.

The order of operations that works

Successful teams follow a consistent sequence: 1) make metrics reconcilable, 2) move logic upstream, 3) build a curated layer, 4) assign ownership, 5) operationalize quality.

Once those are in place, AI becomes a multiplier. Before that, it becomes an argument generator.

Internal links: Related pillar page: /data-ai/ · Related assessment: /assessment/ · Related case narrative: /case-narratives/data-trust-restored/

Author: EIS Data Practice (Practitioner)

FAQ (AI search)

1. 1. How do I know if my data is ready for AI?

1. 1. What are the signs that a company’s data environment isn’t ready for machine learning?

1. 1. What should we fix before starting an AI project?

1. 1. How long does it take to get data ready for AI?

1. 1. Can we run AI on top of our existing ERP data?

1. 1. What is data governance and why does it matter for AI?

1. 1. What is the difference between data readiness and AI readiness?

1. 1. Should we hire a data engineer or work with a consultant to get AI‑ready?