AI-Ready #10. Prioritizing AI-Ready Master Data by Domain: Customer, Material, Supplier, Product and Employee

Not every master-data domain should become AI-Ready at the same time.

That sounds obvious, but many enterprise programs still begin by ranking domains according to generic assumptions:

Material should always come first because it affects cost.
Customer should always come first because it affects revenue.
Supplier should always come first because supply-chain risk is critical.

None of those rules is universally correct.

The appropriate priority depends on the AI use case, business dependency, current data weakness, action risk and reuse potential of each domain.

The right question is not “Which master-data domain is most important?” It is “Which domain is currently constraining the highest-value AI decisions?”

This article develops a practical way to answer that question across five common enterprise domains:

Customer,
Material,
Supplier,
Product, and
Employee.

The framework is intended for prioritization, not as an industry benchmark or universal ranking.

First, Separate the Domain from the AI Use Case

A domain becomes strategically important when an AI use case depends on it.

For example, “Customer Master” by itself does not define an AI priority.

These use cases create very different requirements:

customer-service assistant,
next-best-action recommendation,
credit-risk assessment,
account hierarchy analysis,
customer churn prediction, and
autonomous account-maintenance agent.

Each one requires different attributes, freshness, identity confidence and controls.

The same principle applies to every master-data domain.

AI Use Case → Business Decision → Required Entities → Critical Attributes → Quality / Access / Control Requirements

That sequence is more useful than beginning with a large enterprise-wide master-data cleanup program.

What MDM Already Provides to Enterprise AI

Master Data Management is not a new discipline created for generative AI.

SAP defines MDM as the discipline of creating and maintaining a trusted view of critical business data such as customers, suppliers, products, materials and assets across systems.

Current SAP MDG documentation also provides governed processes for domains including business partner, product and financial data, with capabilities such as data quality, workflow, approval and distribution.

SAP — What Is Master Data Management?

SAP Help Portal — Master Data Governance

For AI, this matters because many enterprise questions are ultimately entity questions.

Which customer?

Which supplier?

Which material?

Which product?

Which employee?

Which relationships between them?

AI can reason over large amounts of information, but it still needs reliable enterprise identity to know what the information refers to.

A Better Domain Prioritization Framework

I would avoid fixed rankings such as:

Material = Priority 1
Supplier = Priority 2
Customer = Priority 3

Instead, evaluate each domain across six dimensions.

Dimension	Question	Evidence
Business Dependency	How strongly does the target AI workflow depend on this domain?	Process map, business KPI
AI Demand	Are production AI use cases already waiting for this data?	AI portfolio, backlog
Current Data Gap	Do duplicates, missing fields, inconsistent semantics or stale records materially affect the use case?	Profiling, incidents, samples
Decision Risk	What happens if AI uses the wrong entity or attribute?	Risk scenarios, controls
Relationship Complexity	Does AI need hierarchies, relationships or cross-domain context?	Hierarchy and relationship map
Reuse Potential	Would improving this domain support several AI use cases?	Use-case dependency matrix

I would review these dimensions with evidence rather than convert them immediately into a weighted score.

A score can support discussion, but it should not replace it.

Domain 1 — Customer Master Data

Customer data is often the first domain discussed in AI because it connects directly to sales, service, marketing and experience.

But “customer data” usually exists across several systems:

CRM,
ERP,
commerce,
service platforms,
billing,
identity systems, and
analytics environments.

The main AI-Ready challenge is therefore often identity and relationship context.

What AI Needs from Customer Master Data

Requirement	Why It Matters
Canonical Identity	Prevents an AI system from treating one customer as several unrelated entities.
Account Hierarchy	Allows B2B AI to understand parent, subsidiary and account relationships.
Status	Prevents recommendations based on inactive or inappropriate records.
Consent / Access Context	Helps ensure customer information is used within approved boundaries.
Relationship Context	Supports account-level reasoning rather than isolated-record analysis.

Typical AI Use Cases

customer-service copilots,
account intelligence,
next-best-action,
churn analysis,
lead or opportunity support, and
customer-maintenance agents.

Critical Failure Pattern

The AI combines transactions from only one of several duplicate customer records and produces an incomplete view.

The model itself may be functioning correctly.

The entity context is wrong.

Customer AI-Ready principle: improve identity resolution and relationship context before assuming that adding more behavioral data will solve customer-AI quality problems.

Domain 2 — Material Master Data

Material master data is particularly important in manufacturing, procurement, inventory and supply-chain environments.

It often connects technical, logistical, purchasing, planning and accounting attributes.

SAP's current MDG documentation continues to provide specific governance capabilities for Material Master Data, including governed access and change-related roles.

SAP Help Portal — Master Data Governance for Material

What AI Needs from Material Master Data

stable material identifiers,
material type and classification,
units of measure,
plant-specific status,
procurement and planning attributes,
technical characteristics,
substitution or compatibility relationships, and
validity and lifecycle state.

Typical AI Use Cases

inventory optimization,
purchase recommendation,
material substitution,
demand-planning support,
engineering search,
duplicate-material detection, and
maintenance or spare-parts assistance.

Critical Failure Pattern

Two technically equivalent materials exist under separate identifiers because of historical creation practices.

An inventory AI interprets them as unrelated stock.

The result may be technically correct at record level but economically wrong at enterprise level.

Do Not Vectorize Everything

Material descriptions and technical documentation can benefit from semantic search.

But exact identifiers, units of measure, status and planning attributes should normally remain accessible through authoritative structured sources.

Exact Operational Attribute → Structured Master Data

Semantic Technical Similarity → Search / Embeddings Where Useful

The two patterns are complementary.

Domain 3 — Supplier Master Data

Supplier Master Data sits at the intersection of procurement, finance, supply-chain risk and compliance.

SAP MDG for Supplier explicitly supports governed supplier data and distribution across systems, including authorization and change-request processes.

SAP Help Portal — Master Data Governance for Supplier

What AI Needs from Supplier Master Data

canonical supplier identity,
legal and organizational relationships,
supplier status,
purchasing-organization context,
category relationships,
location and country information,
approved / blocked status, and
links to risk and performance evidence.

Typical AI Use Cases

supplier-risk assessment,
supplier discovery,
procurement copilots,
delivery-risk prediction,
contract or sourcing support, and
supplier-onboarding agents.

Critical Failure Pattern

A supplier exists under multiple entities across regions or systems.

Risk data is attached to one record while purchasing history is attached to another.

An AI agent evaluates only part of the exposure.

Here the critical capability is not merely a risk model.

It is the ability to connect risk evidence to the correct supplier identity and relationship structure.

Supplier AI Requires Stronger Action Controls

Reading supplier information and changing payment-related master data are fundamentally different actions.

A supplier agent should therefore distinguish:

Read → Analyze → Recommend → Submit Change → Approve → Execute

Higher-impact changes should use stronger workflow, segregation-of-duties and approval controls.

Domain 4 — Product Master Data

Material and product are sometimes treated as the same domain.

That can be appropriate in some ERP environments, but the business concepts are not always identical.

A useful distinction is:

	Material-Oriented View	Product-Oriented View
Primary Focus	Planning, sourcing, manufacturing, logistics	Commercial offer, catalog, sales, customer experience
Typical Attributes	Plant, MRP, procurement, UoM, inventory	Features, descriptions, taxonomy, channel content
AI Use	Supply-chain and operational optimization	Search, recommendation, commerce and content generation

SAP S/4HANA Cloud also documents Master Data Governance for Products as a specific governance area.

SAP Help Portal — Master Data Governance for Products

What AI Needs from Product Data

stable product identity,
category and taxonomy,
structured attributes,
commercial status,
product relationships,
channel-specific content,
language variants, and
lifecycle information.

Typical AI Use Cases

product recommendation,
semantic product search,
catalog enrichment,
product comparison assistants,
commerce copilots, and
automated content generation.

Critical Failure Pattern

The product exists, but key attributes needed for search or recommendation are missing, inconsistent or represented differently across channels.

The model compensates by relying heavily on unstructured description text.

Results may appear plausible while important product constraints are missed.

Product AI-Ready principle: semantic search is valuable, but it should complement — not replace — clean taxonomy and critical product attributes.

Domain 5 — Employee Master Data

Employee data requires a different discussion.

In many enterprises, the authoritative system is an HCM or HR platform rather than a traditional MDM hub.

That does not make employee identity less important.

It means the AI-Ready architecture must respect the existing system of authority and the higher sensitivity of workforce data.

What AI May Need from Employee Data

employee identity,
organization and reporting structure,
role and job family,
skills or certifications,
location,
employment status, and
approved access context.

Typical AI Use Cases

internal knowledge assistants,
skills search,
training recommendation,
workforce planning support,
service-desk routing, and
role-based enterprise agents.

Critical Failure Pattern

An internal AI agent uses outdated organizational or role information and provides access, recommendations or routing based on a previous position.

Freshness and authorization may be more important here than duplicate matching.

Use Extra Caution with Workforce AI

Employee-related AI can involve sensitive decisions and personal data.

Therefore the AI-Ready requirement should include:

data minimization,
role-based access,
clear purpose limitation,
auditability,
appropriate human oversight, and
risk evaluation proportional to the decision.

NIST's AI Risk Management Framework is useful here because it emphasizes risk management across the design, deployment and evaluation of AI systems rather than only model performance.

NIST — AI Risk Management Framework

The Five Domains Have Different AI-Ready Bottlenecks

Domain	Typical AI Dependency	Frequent Data Bottleneck	Control Focus
Customer	Personalization, service, account intelligence	Identity, hierarchy, consent, fragmentation	Privacy, access, identity confidence
Material	Planning, inventory, sourcing, manufacturing	Duplicates, classifications, UoM, lifecycle	Operational accuracy and change control
Supplier	Risk, sourcing, procurement	Duplicate entities, relationships, status	Segregation of duties and high-impact changes
Product	Search, recommendation, commerce	Attribute completeness, taxonomy, channel inconsistency	Content accuracy and lifecycle
Employee	Knowledge, skills, workflow and role context	Freshness, organizational context, sensitive attributes	Privacy, fairness, role-based access

Cross-Domain AI Is Where MDM Becomes More Strategic

Many valuable enterprise AI use cases do not operate inside one domain.

Consider a supply-chain disruption agent.

It may need:

Supplier — who supplies the component?
Material — which materials are affected?
Product — which sellable products depend on those materials?
Customer — which strategic customers may be impacted?
Employee / Organization — who owns the decision or escalation?

The value comes from the relationships between domains.

Supplier → Material → Product → Customer → Business Owner

An AI system can traverse this chain only if the identifiers and relationships are sufficiently reliable.

This is where master data evolves from “clean reference records” into enterprise context for AI.

Do Not Create One Universal Golden Record

“Golden Record” is useful language, but it can become misleading.

A single enterprise record is not always the answer to every business question.

For example:

a customer may have a legal identity, commercial account structure and digital identity,
a supplier may have legal-entity and purchasing-organization views,
a material may vary by plant or sales context, and
an employee may have HR identity, organizational role and application identities.

The AI-Ready objective is therefore not necessarily:

One record containing everything

It is:

A governed identity model that tells AI which representation is authoritative for which decision

Domain Priority Should Change by Use Case

The same enterprise may have several valid priority orders.

AI Initiative	Likely Primary Domain	Secondary Domains	Main Bottleneck to Test
Customer Service Agent	Customer	Product	Identity + entitlement + current product context
Inventory Optimization	Material	Supplier, Product	Duplicate material + UoM + lifecycle
Supply-Risk Agent	Supplier	Material, Product	Supplier identity + relationships + risk evidence
Commerce Recommendation	Product	Customer	Taxonomy + attributes + customer context
Enterprise Knowledge Agent	Employee / Organization	All business domains	Role, authorization and authoritative knowledge

There is no permanent enterprise-wide “Priority #1 domain.” Priority should follow the AI portfolio and business risk.

Do Not Use Universal Data-Quality Thresholds

The original version of this type of framework often includes numbers such as:

Customer duplicates must be below 2%.
Product completeness must exceed 95%.
Supplier accuracy must exceed 98%.

Those numbers may be reasonable targets in a specific environment.

They are not universal AI-Ready standards.

The correct threshold depends on the business decision.

For example, an incorrect supplier bank account and a missing marketing description do not represent equivalent business risk.

A more useful design is:

Critical Attribute → Failure Scenario → Business Impact → Acceptable Threshold → Control

Domain-Level AI-Ready Metrics

Domain	Possible Data Metrics	Possible AI / Process Metrics
Customer	Unresolved duplicates, hierarchy exceptions, critical-field completeness	Wrong-customer retrieval, service resolution, override rate
Material	Potential duplicates, UoM conflicts, classification gaps	Wrong substitution, planning exceptions, inventory rework
Supplier	Duplicate suppliers, relationship gaps, status conflicts	Risk-assessment exceptions, sourcing rework, blocked actions
Product	Attribute completeness, taxonomy conflicts, content freshness	Search failure, recommendation quality, content correction rate
Employee	Role freshness, organization errors, identity mismatches	Access exceptions, wrong routing, human override

Targets should be set from the use case, baseline and risk tolerance rather than borrowed from another company.

A Practical Domain Selection Matrix

For an executive portfolio review, I would use a qualitative matrix before building a complex score.

Domain	Business Dependency	AI Demand	Current Gap	Risk	Reuse Potential
Customer	Evaluate	Evaluate	Evaluate	Evaluate	Evaluate
Material	Evaluate	Evaluate	Evaluate	Evaluate	Evaluate
Supplier	Evaluate	Evaluate	Evaluate	Evaluate	Evaluate
Product	Evaluate	Evaluate	Evaluate	Evaluate	Evaluate
Employee	Evaluate	Evaluate	Evaluate	Evaluate	Evaluate

The output should lead to a business discussion, not an automatic mathematical winner.

A 90-Day Domain Pilot

Once one domain has been selected, the objective should not be to make the entire domain “perfect.”

The objective is to prove that improving critical master context materially improves one AI use case.

Period	Work	Evidence
Days 0–30	Select the AI use case, map domain dependencies, profile critical attributes and define business baseline.	Use-case map, baseline, critical-data list
Days 31–60	Resolve the most material identity, quality, relationship and access gaps.	Improved context and evaluation set
Days 61–90	Run the AI workflow with realistic exceptions and compare results with baseline.	AI, data and business outcome evidence

Then decide whether to:

expand within the same domain,
connect a second domain,
standardize a reusable service,
correct another bottleneck, or
stop because the business case is weak.

Five Questions Before Funding a Domain Program

1. Which production AI use cases depend on this domain?

2. Which data defects are actually causing AI or business failure?

3. Which attributes and relationships are critical rather than merely desirable?

4. What business outcome should improve after the domain becomes more AI-Ready?

5. Which capabilities can be reused by the next AI use case?

If those questions cannot be answered, a large domain-wide transformation may be premature.

My Practical Takeaway

The five domains discussed here are not competing for a permanent ranking.

They play different roles.

Customer is often about identity, hierarchy and customer context.

Material is often about operational accuracy, classification and lifecycle.

Supplier combines identity with procurement, risk and high-impact controls.

Product depends heavily on taxonomy, attributes and commercial context.

Employee requires freshness, organizational context and particularly careful access controls.

The strategic value increases when those domains can be connected.

Start from the AI decision.

Identify the master domains that decision depends on.

Improve only the critical identity, quality, relationship and access gaps first.

Measure whether AI and business outcomes actually improve.

Then expand the trusted context across additional domains.

AI-Ready master data is not about making every domain perfect. It is about making the right enterprise context reliable enough for the decisions AI is actually being asked to make.

Sources & Further Reading

Editorial Note
The domain-prioritization framework, domain comparison, AI-Ready metrics, selection matrix and 90-day pilot in this article are Digital Future & Strategy practitioner frameworks. They are not SAP, NIST, Gartner or consulting-industry benchmark models. No universal domain ranking, ROI period, data-quality threshold or maturity score is assumed. Organizations should prioritize domains according to actual AI use cases, business impact, data gaps, risk and reuse potential.

Reviewed: September 2026

AI-Ready Strategy Series

Part 3 — Master Data & Agent Integration

AI-Ready #9. Modernizing Existing MDM for AI: From System of Record to AI-Ready Architecture
AI-Ready #10. Prioritizing AI-Ready Master Data by Domain: Customer, Material, Supplier, Product and Employee
AI-Ready #11. Connecting MDM to AI Agents: APIs, Permissions and Human-in-the-Loop Controls

Previous: Modernizing Existing MDM for AI: From System of Record to AI-Ready Architecture

Next: Connecting MDM to AI Agents: APIs, Permissions and Human-in-the-Loop Controls