Data readiness: the check most transformation programs skip.

Automation and AI initiatives get judged on the model or the workflow, but they run on whatever data feeds them. A capable system built on inconsistent, duplicated, or unowned data will produce unreliable output regardless of how well it is configured. Data readiness is a precondition, not a parallel workstream.

Existence is not the same as usability

Most organisations already hold the data a new system needs, but scattered across systems that were never designed to agree with each other. The relevant question is not whether the data exists, but whether it is consistent, current, accessible to the system that needs it, and traceable to a source someone is accountable for.

Ownership decides whether quality holds

Data quality degrades wherever no one is responsible for it. Before a transformation or automation program starts, someone needs to own each critical data source: who corrects it when it's wrong, who is notified when it changes, and who decides what "correct" means for that field.

Audits belong before architecture decisions

A short data audit, mapping what exists, where it lives, what's missing, and who owns it, should come before system selection, not after. It surfaces the gaps that would otherwise appear mid-project as unplanned rework: fields that mean different things in different systems, records with no single source of truth, or data that is accurate but not accessible to the tool that needs it.

The goal is a decision system, not a clean pipeline

The end goal is not clean data for its own sake. It's data structured well enough to support the decisions, workflows, or AI outputs the business actually needs. Readiness work should be scoped against those specific use cases, not treated as a general cleanup exercise with no defined finish line.