Your AI programme probably does not have a technology problem.
It has a master data problem.
The model may be sophisticated. The cloud platform may be modern. The ERP vendor may have promised embedded intelligence, autonomous workflows and predictive insight.
None of that matters if the same customer exists five times across Salesforce, SAP and a legacy billing system.
None of it matters if product hierarchies mean different things in different business units.
None of it matters if finance cannot reconcile cost centres across entities, countries and reporting structures.
AI does not repair business context. It amplifies whatever context you give it.
If your master data is inconsistent, AI will produce faster answers, faster forecasts and faster automation built on unreliable foundations.
That is the uncomfortable truth many enterprises are avoiding.
The AI execution gap starts with data
The standard transformation sequence looks attractive on a board presentation:
Strategy → Technology → AI deployment → Business value
The real sequence is more demanding:
Strategy → Business definitions → Master data → Technology → Execution → Adoption → Business outcome
That missing layer between strategy and technology is where many programmes fail.
A CIO approves an AI use case. The technology team builds a data pipeline. A vendor configures the model. The pilot produces inconsistent results. Users lose confidence. Finance challenges the numbers. Risk blocks production deployment.
The organisation then blames the AI technology.
Often, the technology did exactly what it was asked to do.
The real failure was that nobody had agreed what a customer, product, supplier, cost centre or active contract actually meant.
According to Deloitte’s 2026 analysis of ERP and AI readiness, Gartner expects only 30% of organisations to have the data quality required to fully leverage advanced AI capabilities by 2027.
That is not primarily a model problem. It is a governance and execution problem.
What broken master data looks like in practice
Master data is the relatively stable business information that sits underneath transactions and decisions.
Examples include:
- Customer and business partner records
- Products, materials and service definitions
- Suppliers and vendor records
- Chart of accounts and cost centres
- Legal entities and organisational structures
- Locations, assets and contracts
In a multi-vendor enterprise, these records rarely remain consistent.
A customer may be:
- “Acme Holdings Ltd” in Salesforce
- “ACME HOLDING” in SAP
- “AHL-00981” in a billing platform
- A different regional subsidiary in Oracle
The records may refer to the same commercial relationship. The systems do not know that without a governed matching rule.
Product data creates a similar problem. One business unit reports by product family. Another reports by SKU. A third reports by service category. The executive dashboard shows three different versions of gross margin because the hierarchy is not shared.
Finance data is no better. Cost centres change after reorganisations, but old mappings remain in data warehouses, planning tools and operational systems. AI can identify spending patterns, but it cannot decide whether two cost centres should be consolidated without an agreed business rule.
Why ERP modernisation exposes the problem
ERP modernisation does not create most master data problems.
It reveals them.
When an organisation consolidates SAP instances, moves from legacy Oracle environments, integrates Salesforce with finance or introduces Microsoft Dynamics, old inconsistencies become impossible to ignore.
The migration team must answer questions that were previously avoided:
- Which customer record is authoritative?
- Which product hierarchy should survive?
- Which cost centre structure reflects the operating model?
- Which fields are mandatory?
- Who approves changes?
- What happens when local requirements conflict with global standards?
- How should historical records be mapped?
These are business decisions. They cannot be delegated entirely to a technical migration team.
The financial consequences are real. Informatica reports, citing Panorama Consulting research, that 33% of ERP projects were over budget, with 35% of respondents identifying data issues as a cause of the overrun. The same source reports that 46% of respondents linked timeline overruns to data issues.
Poor master data is not an administrative inconvenience.
It is a programme risk.
The four controls every enterprise needs before scaling AI
1. Assign ownership by data domain
“Data is everyone’s responsibility” usually means nobody is accountable.
Assign a business owner for every critical domain.
For example:
- Customer: Chief Commercial Officer or customer operations leader
- Product: Chief Product Officer, supply chain leader or operations executive
- Finance: CFO or group financial controller
- Supplier: Procurement director
- Employee: CHRO
The owner is not responsible for correcting every record. The owner is accountable for the definition, quality threshold, approval rules and business consequences.
Technology teams should operate the controls. They should not invent the business meaning.
2. Define the golden record
A golden record is not simply the record found in the newest platform.
It is the trusted, governed representation of a business object.
For each domain, define:
- The authoritative identifier
- Required and optional attributes
- Matching and deduplication rules
- Survivorship rules when systems disagree
- Ownership of each critical field
- Permitted values and validation rules
- Audit and lineage requirements
- Update frequency and approval thresholds
Do not attempt to make every field perfect before delivering value. Define the minimum viable golden record for the business outcome you are targeting.
A predictive maintenance use case may need asset identity, location, maintenance history and operating condition.
It may not need every descriptive field in the enterprise catalogue.
3. Establish a stewardship model
Ownership sets accountability. Stewardship makes it operational.
A practical stewardship model includes:
- Domain stewards who monitor quality and resolve exceptions
- Data custodians who manage technical controls and integrations
- A central data governance function that manages standards and escalation
- A decision forum for cross-domain conflicts
- Service-level targets for resolving data issues
Track measurable indicators, not vague statements about “improving data quality”.
Useful metrics include:
- Duplicate rate
- Completeness of mandatory fields
- Invalid value rate
- Match confidence
- Unresolved exception volume
- Time to resolve a data issue
- Percentage of records with traceable lineage
- Number of manual reconciliations per reporting cycle
Set thresholds by use case. A customer segmentation model may tolerate a different error rate from regulatory reporting or automated credit decisions.
4. Gate AI deployment on data readiness
An AI pilot should not move to production because the model works in a controlled demonstration.
It should move because the underlying data is reliable enough for the business and risk context.
Before approval, test:
- Accuracy
- Completeness
- Consistency
- Uniqueness
- Validity
- Timeliness
- Lineage
- Access controls
- Human override procedures
The gate should be explicit. If the data fails the threshold, the use case pauses.
That is not bureaucracy. It is delivery discipline.
The correct sequence for ERP and AI modernisation
The order matters.
Phase 1: Start with the business decision
Do not begin with a platform or model.
Begin with the decision you want to improve.
Examples:
- Which customers are at risk of leaving?
- Which products are eroding margin?
- Which suppliers create disruption risk?
- Which cost centres are driving unplanned spend?
- Which cases should be prioritised for human review?
Define the decision, its owner, the required data and the measurable outcome.
Phase 2: Profile the critical data
Map where the relevant data exists across ERP, CRM, finance, workflow and operational platforms.
Then measure its condition.
Do not profile the entire estate at once. Start with the domains connected to the highest-value and highest-risk decisions.
Phase 3: Agree definitions and ownership
Create the golden-record definition. Assign domain owners. Resolve conflicts between global and local requirements.
This is where business and technology must work together.
Phase 4: Stabilise the ERP and integration foundation
Modernise or remediate the core systems based on the business operating model.
That may mean a full ERP transformation. It may mean targeted remediation, integration improvements or a phased consolidation.
The right answer depends on the business problem. Technology selection comes after that decision.
Panorama Consulting’s ERP and AI guidance makes the same essential point: ERP modernisation creates the governance, process consistency and system context that AI depends on.
Phase 5: Pilot AI against governed data
Choose a contained use case with a clear owner, controlled risk and measurable baseline.
Run it inside the operating process. Measure adoption, accuracy, cycle time, exception rates and financial impact.
Do not measure success by whether the demonstration impressed the steering committee.
Phase 6: Scale with continuous stewardship
Data quality decays.
Acquisitions happen. Products change. Organisations restructure. New vendors enter the ecosystem. Local teams create workarounds.
Master data management is therefore not a one-time cleansing project. It is an operating capability that must remain connected to ERP, CRM, finance, AI and change management.
The role of the execution layer
This is where the Execution Gap becomes visible.
Strategy defines the ambition.
Technology provides the platforms.
Execution connects business ownership, data rules, integration work, governance and delivery cadence.
Adoption determines whether teams use the new definitions and controls.
Business outcomes prove whether the investment worked.
A programme can have an excellent data strategy and still fail because nobody resolves exceptions. It can have a strong MDM platform and still fail because finance and operations disagree on ownership. It can have a clean migration and still fail because users recreate old spreadsheets outside the governed environment.
The missing capability is not always another tool.
It is often senior execution leadership that can make decisions stick across business units, vendors and platforms.
Questions CIOs and CFOs should ask now
Before approving another AI or ERP workstream, ask:
- Who owns the customer, product and finance domains?
- What is our agreed golden record for each critical object?
- What percentage of records are duplicates or incomplete?
- Which business definitions differ across SAP, Oracle, Salesforce and Dynamics?
- What data quality threshold must be met before production deployment?
- Who resolves exceptions, and within what timeframe?
- Can we trace an AI-generated recommendation back to its source data?
- What happens when the AI is wrong?
- Are users rewarded for maintaining data quality?
- Which business outcome will prove that the work was worth funding?
If the answers are unclear, scaling AI is premature.
Frequently Asked Questions
What is master data quality?
Master data quality is the reliability of core business records such as customers, products, suppliers, cost centres and legal entities. It is measured through dimensions including accuracy, completeness, consistency, uniqueness, validity, timeliness and lineage.
Why does master data matter for AI?
AI depends on business context. Duplicate customers, inconsistent product hierarchies and unmapped finance structures can produce unreliable predictions, inaccurate reporting and unsafe automation. Better models cannot compensate for fundamentally broken inputs.
Should an organisation fix all data before starting AI?
No. That approach creates unnecessary delay. Organisations should define the business outcome, identify the critical data domains and establish readiness thresholds for the specific use case. Remediate what matters first, then expand systematically.
Should ERP modernisation happen before AI deployment?
In most enterprise environments, core ERP and master data foundations should be stabilised before AI is scaled. Controlled AI pilots can run earlier, but production deployment requires governed data, clear ownership, traceability and operational controls.
What is a data readiness assessment?
A data readiness assessment evaluates the quality, ownership, definitions, lineage, architecture and governance of the data required for a planned ERP or AI outcome. It identifies the execution risks before significant implementation spend is committed.
Conclusion: Fix the record before you scale the model
Your AI programme will not be saved by buying another platform.
It will be saved by deciding what your business data means, who owns it, how it is governed and whether people use it consistently.
Master data is the bottleneck between AI ambition and business value.
Treat it as a technical clean-up task and it will return as a migration delay, a failed pilot, a finance dispute or a regulatory problem.
Treat it as part of the operating model and it becomes an advantage.
If your organisation is preparing for ERP modernisation, enterprise AI or a multi-platform data programme, start with a focused data readiness assessment and Delivery Diagnostic. The objective is not to produce another report. It is to identify the records, decisions, owners and controls that must be fixed before execution begins.
About the Author
Kunal Patel : CEO & Founder, Dark Consultancy
Kunal Patel founded Dark Consultancy after two decades leading technology and transformation programmes across the public sector, financial services, defence, and energy industries. He has directly managed programme recovery engagements for government agencies, development finance institutions, and regulated enterprises across the US, Middle East, South Asia, and Southeast Asia : ranging from $5M platform migrations to $200M+ enterprise transformation portfolios. Kunal is a recognised practitioner in delivery governance for regulated environments and holds PMP and PRINCE2 Practitioner certifications. He leads every new client engagement personally and remains accountable throughout the programme lifecycle. Connect with Kunal on LinkedIn
SEO Assets
- SEO title: Master Data Quality: The AI Programme Bottleneck
- Meta description: Poor master data can derail AI and ERP modernisation. Learn how to fix ownership, golden records and governance before scaling enterprise AI.
- Suggested URL slug:
master-data-quality-ai-erp-modernization - Focus keyword: master data quality
- Secondary keywords: master data management, AI readiness, ERP modernisation, data governance, enterprise AI
- Image alt text: Enterprise data leaders reviewing duplicate records, product hierarchies and finance data being consolidated into a governed golden record
- Search intent: Informational with commercial investigation intent
- Internal linking suggestions:
- External authoritative source recommendations:
- Recommended schema: Article Schema, FAQPage Schema, Organization Schema