Enterprise Data and Master Data Management

Introduction and Context

Enterprise resource planning (ERP) systems integrate finance, procurement, production, sales, inventory, human resources, and logistics through shared processes and databases. Their value depends not only on software functionality but also on the quality, meaning, ownership, and governance of enterprise data. Poorly governed data can cause duplicate customers, inconsistent product descriptions, incorrect inventory balances, failed interfaces, inaccurate reports, and regulatory exposure.

Enterprise data management is therefore a managerial and technical discipline. It establishes how data is defined, created, validated, stored, exchanged, protected, retained, and retired. Master data management (MDM) focuses on the entities that are shared across processes and systems, such as customers, suppliers, products, employees, locations, assets, and charts of accounts. Transactional data records business events involving those entities, while reference data supplies controlled classifications and codes.

The central challenge is to achieve a reliable, shared interpretation of important business entities without eliminating legitimate local requirements. The single-source-of-truth principle is useful, but it must be interpreted carefully: the goal is not necessarily one physical database. Rather, the goal is one authoritative definition and one governed source for each critical data element, with controlled synchronization to consuming systems.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish master, transactional, reference, metadata, and analytical data.
2. Explain the single-source-of-truth principle and its limitations.
3. Design roles, decision rights, and governance mechanisms for enterprise data.
4. Evaluate data quality using appropriate dimensions and metrics.
5. Develop standards for data definitions, identifiers, metadata, and lifecycle management.
6. Analyze migration and interoperability risks in ERP environments.
7. Recommend ethically and legally responsible data governance practices.

1. The Enterprise Data Landscape

1.1 Master data

Master data describes relatively stable business entities that participate in many processes. Typical domains include:

Master data is not necessarily static. A supplier can change its address, a product can be discontinued, and an employee can move departments. “Relatively stable” means that master records change less frequently than transactions and are reused across multiple business activities.

1.2 Transactional data

Transactional data records events, commitments, or states resulting from business activity. Examples include a sales order, goods receipt, invoice, payment, production confirmation, inventory movement, maintenance work order, or journal entry. Transactions normally refer to master records through identifiers. A sales order may contain a customer ID and product ID rather than repeating the full customer and product definitions.

Transactional integrity requires more than accurate master data. It also depends on chronology, authorization, completeness, document relationships, and controls against duplicate or unauthorized events. Once a transaction has legal or financial significance, changes may need to be recorded through reversals or adjustments rather than direct deletion.

1.3 Reference data

Reference data consists of controlled values used to classify, validate, or interpret other data. Examples include country codes, currency codes, tax categories, order statuses, units of measure, industry classifications, and payment-method codes. Reference data may be internally defined or adopted from external standards.

Reference data is often underestimated. If one system uses “US,” another uses “USA,” and a third uses “840,” integration and reporting become unnecessarily complex. Reference-data governance therefore establishes approved code sets, meanings, translations, owners, effective dates, and mappings.

1.4 Metadata and data lineage

Metadata is data about data. It may describe a field’s business meaning, data type, permitted values, owner, sensitivity, source, update frequency, retention period, or transformation rules. A data catalog makes metadata discoverable to users and technical teams.

Data lineage records the movement and transformation of data from origin to destination. For example, a revenue figure may originate in sales invoices, be aggregated in a data warehouse, and be adjusted by a recognized accounting rule before appearing in an executive dashboard. Without lineage, users cannot easily determine whether a report is authoritative or why two reports differ.

2. The Single-Source-of-Truth Principle

A single source of truth (SSOT) is an authoritative source for a defined data element or business entity. It reduces ambiguity by specifying which system or governed repository should be trusted for a particular purpose. For example, an ERP customer master may be authoritative for billing identity, while a customer relationship management system may be authoritative for sales opportunities.

SSOT should not be confused with “one system for everything.” Different systems may legitimately own different aspects of an entity. A product lifecycle system may own engineering specifications, an ERP system may own purchasing and costing attributes, and a warehouse system may own operational bin locations. Governance must specify the authoritative source at attribute level where necessary.

A practical SSOT design answers five questions:

1. What is the business object or attribute?
2. Which system or repository is authoritative?
3. Who has authority to define and change it?
4. How are changes distributed to other systems?
5. What happens when sources disagree?

The principle has important limitations. A source may be authoritative but still contain errors. Replicated data may be temporarily inconsistent because of interface delays. Organizational mergers may create overlapping definitions. Consequently, SSOT requires stewardship, validation, monitoring, and reconciliation; it is not a substitute for those controls.

3. Data Governance as an Operating Model

Data governance is the exercise of authority and control over data assets. It defines decision rights, policies, standards, responsibilities, and escalation mechanisms. It differs from data management, which includes the operational and technical activities used to implement those decisions.

3.1 Governance roles

A mature ERP data-governance model commonly includes:

• Executive sponsor: Provides authority, funding, and strategic alignment.
• Data governance council: Resolves cross-functional conflicts and approves enterprise policies.
• Data domain owner: Is accountable for a domain such as customer, product, or supplier data.
• Data steward: Applies definitions, validates records, monitors quality, and coordinates issue resolution.
• System owner: Maintains the application and its technical controls.
• Data custodian: Operates storage, security, backup, and access mechanisms.
• Data consumer: Uses data and reports quality problems.

Accountability must be explicit. A useful responsibility matrix distinguishes who is accountable for policy, responsible for execution, consulted during decisions, and informed of outcomes. A technical administrator may be responsible for configuring validation rules, but a business owner should remain accountable for the meaning and fitness of the data.

3.2 Governance decision rights

Governance should define who can:

• approve a new data element or code;
• create, change, merge, or deactivate a master record;
• define mandatory fields and validation rules;
• approve exceptions to standards;
• resolve conflicts between business units;
• authorize access to sensitive data; and
• determine retention and destruction requirements.

These decisions should be embedded in workflows rather than relying solely on informal agreement. For example, creation of a supplier should require verification of legal identity, tax information, bank details, duplicate risk, and approval by an authorized procurement role.

4. Data Quality: Dimensions, Measurement, and Improvement

Data quality is fitness for a defined purpose. A record may be sufficiently accurate for operational scheduling but insufficient for legal reporting. Quality must therefore be assessed in context.

A simple completeness rate for a field can be calculated as:

The metric assumes that the assessed population and the definition of “valid” are clearly specified. If 9,600 of 10,000 supplier records contain valid tax identifiers, the completeness rate is 96%. This does not prove that the identifiers are accurate; completeness and accuracy are different dimensions.

A duplicate rate can be expressed as:

Organizations should establish thresholds according to business risk. A 1% duplicate rate in a low-risk marketing list may be tolerable, while one duplicate bank account in a payment master may be unacceptable.

Quality improvement follows a closed loop:

1. Define quality requirements with business users.
2. Profile existing data to identify patterns and defects.
3. Determine root causes, such as weak processes, unclear definitions, or manual entry.
4. Correct existing records.
5. Prevent recurrence through workflow, validation, training, and monitoring.
6. Review indicators and revise controls.

Correcting records without addressing root causes creates recurring remediation costs. Conversely, excessive validation can slow operations and encourage users to create workarounds. Controls should be risk-based and proportionate.

5. Standards, Definitions, and Metadata

5.1 Business glossaries

A business glossary defines important terms in language understood by business and technical stakeholders. It should distinguish similar concepts. “Customer,” for example, might mean a legal entity, a sold-to party, a ship-to location, a payer, or an individual consumer. Ambiguity produces inconsistent reports and flawed process design.

A high-quality definition usually states the term, meaning, inclusion and exclusion rules, owner, related terms, source, and examples. Definitions should be approved through governance and version-controlled.

5.2 Data standards

Standards may address naming, identifiers, formats, units of measure, address structures, code sets, date and time conventions, and permissible values. Internal standards should be aligned with relevant external standards where practical, including recognized currency, country, language, product, and industry code systems.

Identifiers require special care. A meaningful identifier can become unstable when business meaning changes. A non-semantic identifier, such as a generated numerical key, is often more durable, while descriptive attributes carry the changing meaning. Organizations should define whether identifiers are globally unique, system-specific, reusable, or permanent after retirement.

5.3 Metadata management

Metadata should support both operational use and control. Important metadata categories include:

• business definition and domain;
• technical name, type, length, and format;
• permitted values and validation rules;
• source system and authoritative owner;
• sensitivity classification;
• lineage and transformation logic;
• retention and disposal requirements; and
• quality indicators and known limitations.

Metadata is valuable only if maintained. Automated discovery can reduce effort, but business interpretation still requires human accountability.

6. Interoperability and Integration

ERP landscapes commonly contain legacy applications, cloud services, manufacturing systems, e-commerce platforms, data warehouses, and partner networks. Interoperability requires agreement at several levels:

• Technical: Connectivity, protocols, formats, and authentication.
• Syntactic: Structure and representation of messages.
• Semantic: Shared meaning of fields and codes.
• Process: Compatible timing, status, and exception handling.
• Organizational: Agreement on ownership, policies, and accountability.

An interface that successfully transmits a message may still fail semantically. For instance, a “quantity” field may represent sales units in one system and inventory base units in another. Unit-of-measure conversion must be explicit, controlled, and reversible where necessary.

Common integration patterns include point-to-point interfaces, centralized integration platforms, application programming interfaces (APIs), event-driven messaging, and governed data hubs. Point-to-point designs can be quick initially but become difficult to maintain as the number of connections grows. A hub or integration platform can centralize transformation, monitoring, and security, although it introduces its own governance and operational dependencies.

Interoperability controls should include schema validation, reference-code mapping, interface monitoring, retry policies, error queues, reconciliation, and audit logs. Real-time integration is not always superior. Batch processing may be appropriate where latency is not critical and operational simplicity is more important.

7. Data Migration in ERP Programs

Migration is the controlled movement of data from existing systems into a target ERP or related platform. It is a business transformation activity, not merely a file-conversion exercise.

A robust migration lifecycle includes:

1. Scope and ownership: Identify objects, history requirements, owners, and regulatory constraints.
2. Profiling: Examine formats, missing values, duplicates, obsolete records, and relationships.
3. Mapping: Map source fields, codes, units, and structures to the target model.
4. Cleansing and enrichment: Correct, standardize, deduplicate, and supplement records.
5. Transformation: Convert formats and apply approved business rules.
6. Validation: Test structure, quality, relationships, totals, and business usability.
7. Rehearsal: Execute trial conversions and measure defects and duration.
8. Cutover: Freeze or control source changes, load approved data, and reconcile.
9. Stabilization: Monitor defects, user feedback, interfaces, and operational outcomes.

Migration decisions should distinguish data that must be converted from data that may be archived. Bringing every historical record into a new ERP can increase cost, complexity, and privacy risk. Conversely, inadequate history can impair auditability and analysis. The decision should consider legal retention, operational need, analytical value, accessibility, and total cost.

Reconciliation should compare independent control totals, such as record counts, monetary balances, inventory quantities, and key relationships. A successful technical load is not sufficient if the business cannot process orders, pay suppliers, close the books, or meet reporting requirements.

8. Security, Ethics, and Regulatory Responsibilities

Enterprise data governance includes confidentiality, integrity, availability, accountability, and privacy. Access should follow least privilege: users receive only the access necessary for legitimate duties. Segregation of duties is particularly important in ERP systems; for example, one person should not be able to create a supplier and approve payment to that supplier without independent control.

Privacy principles commonly require purpose limitation, data minimization, accuracy, retention control, transparency, and appropriate protection. Personal data should not be copied into test environments unnecessarily. Sensitive attributes should be classified, encrypted where appropriate, monitored, and disclosed only to authorized users.

Ethical governance also addresses bias and exclusion. Poorly designed customer or employee classifications can produce unfair treatment, while automated duplicate matching can incorrectly merge individuals. AI-assisted data cleansing and matching should be explainable enough for responsible review, tested for differential error rates, and subject to human escalation for high-impact decisions.

Organizations must align governance with applicable laws, contractual obligations, accounting requirements, sector regulations, and records-management rules. Because obligations vary by jurisdiction and industry, governance policies should be reviewed by qualified legal and compliance professionals rather than copied from generic templates.

9. Applied Case: Orion Components ERP Consolidation

The following is an illustrative case.

Background

Orion Components, a multinational manufacturer, operated three regional ERPs and separate procurement and customer-service applications. The same industrial customer appeared under different names in each region. Products had inconsistent units of measure, and suppliers were occasionally created more than once.

Problem

During consolidation, management found that sales reports differed by region, inventory was overstated by approximately 2.4%, and supplier payments required manual review. A proposal to create a central “golden record” database was approved without first assigning business ownership.

Analysis

A profiling exercise identified four root causes:

1. No enterprise definition of customer, product, or active supplier.
2. Regional identifiers were treated as global identifiers.
3. Reference codes for units and countries were not governed.
4. Duplicate detection occurred after records were loaded rather than during creation.

The team also discovered that some product attributes were legitimately owned by engineering, while costing and purchasing attributes were owned by operations. A single physical owner for the entire product record would therefore have been inappropriate.

Approach and solution

Orion established a data governance council and appointed domain owners. It adopted the following design:

• Engineering owned technical specifications and revision status.
• Operations owned purchasing, planning, and inventory attributes.
• Finance owned valuation and accounting classifications.
• A governed product identifier linked the related views.
• A central supplier onboarding workflow checked legal identity, tax data, bank details, and duplicates.
• Units of measure and country codes were standardized through approved reference tables.
• Regional records were mapped to global entities using survivorship rules approved by domain owners.
• Historical data that was not needed operationally was archived with searchable lineage.

The migration was rehearsed three times. Each rehearsal included record counts, inventory reconciliation, open-order testing, supplier-payment testing, and user acceptance by regional process owners.

Outcome

At go-live, the organization reduced duplicate active supplier records by 82% and achieved a 98.7% valid completion rate for required product attributes. The remaining defects were logged with owners and due dates rather than hidden. Reporting became more consistent, although some regional reports continued to use different legitimate business scopes. Governance therefore documented not only common definitions but also approved contextual differences.

Learning points

The case illustrates that MDM is an operating model, not merely a database. A reliable golden record depends on ownership, definitions, standards, workflows, quality measurement, and reconciliation. It also demonstrates that harmonization should remove accidental variation without erasing valid business distinctions.

10. Contemporary Developments and Critical Issues

Cloud ERP and platform ecosystems increase the number of applications participating in data processes. Organizations must govern data across vendor boundaries, subscription services, APIs, and partner networks. Data products and data mesh approaches emphasize domain accountability and reusable, well-described datasets, but they do not eliminate the need for enterprise standards and cross-domain coordination.

Machine learning can support entity resolution, anomaly detection, classification, and quality monitoring. However, probabilistic matching produces confidence levels rather than certainty. High-impact merges, such as combining two legal entities or individuals, should require review thresholds, auditability, and reversal mechanisms.

The growing use of generative AI introduces additional risks. Sensitive master data may be exposed through prompts, generated outputs may contain inaccurate values, and users may mistake plausible language for authoritative data. AI tools should therefore use controlled access, approved data sources, logging, validation, and clear limits on autonomous changes to ERP master records.

A mature organization treats data governance as continuous capability development. It periodically reviews definitions, measures business outcomes, audits access, retires obsolete codes, and updates standards as processes and regulations evolve.

Best-Practice Design Principles

1. Assign one accountable owner for every critical data domain and attribute.
2. Define terms before designing fields or interfaces.
3. Establish authority at attribute level when ownership is distributed.
4. Use stable identifiers and governed reference codes.
5. Prevent defects at creation, not only through downstream cleansing.
6. Measure quality according to business risk and purpose.
7. Maintain metadata, lineage, and decision records.
8. Design interfaces for semantic as well as technical interoperability.
9. Rehearse migration and reconcile business outcomes, not only record counts.
10. Protect personal and commercially sensitive data throughout its lifecycle.
11. Treat exceptions as governed decisions with expiration dates.
12. Use AI as an assistive capability with human accountability for consequential changes.

Chapter Summary

Enterprise data management provides the policies, responsibilities, standards, processes, and technologies required to make ERP data trustworthy and usable. Master data describes shared business entities; transactional data records business events; reference data supplies controlled classifications; and metadata explains meaning, structure, ownership, lineage, and constraints.

The single-source-of-truth principle requires an authoritative source for each defined data element or business purpose, but it does not require one physical system for all information. Effective governance assigns accountable owners, stewards, custodians, and decision rights. Data quality should be assessed through dimensions such as accuracy, completeness, consistency, timeliness, validity, uniqueness, integrity, and accessibility.

Business glossaries, identifiers, reference standards, metadata catalogs, and lineage reduce ambiguity and support interoperability. Migration requires profiling, mapping, cleansing, transformation, validation, rehearsal, reconciliation, and controlled cutover. Security, privacy, segregation of duties, regulatory compliance, and ethical use of AI are integral to governance. Ultimately, MDM succeeds when it becomes part of everyday processes rather than a one-time technical project.

Key Terms

Master data: Shared, relatively stable data describing business entities.

Transactional data: Data recording business events, activities, or commitments.

Reference data: Controlled codes and classifications used to validate or interpret data.

Metadata: Data describing the meaning, structure, origin, use, or control of other data.

Data lineage: A record of where data originates and how it is transformed.

Single source of truth: The authoritative source for a defined data element or purpose.

Data governance: Authority, policies, decision rights, and controls for managing data.

Data steward: A person responsible for operational data-quality and definition activities.

Data domain owner: The accountable business authority for a data domain.

Data quality: Fitness of data for a specified business purpose.

Business glossary: An approved collection of business terms and definitions.

Identifier: A value used to distinguish a data entity or record.

Entity resolution: The process of determining whether records represent the same real-world entity.

Golden record: A trusted, consolidated representation of an entity.

Interoperability: The ability of systems and organizations to exchange and correctly use information.

Data migration: The controlled movement and transformation of data into a target environment.

Data reconciliation: Comparison of independently derived results to confirm completeness and correctness.

Reference-code mapping: The controlled relationship between codes used by different systems.

Data lifecycle: The stages through which data is created, used, retained, archived, and destroyed.

Least privilege: Providing users only the access required for authorized duties.

Review Questions

5 Short Answer Questions

1. What distinguishes master data from transactional data?
2. Why is a single source of truth not necessarily a single physical database?
3. Name four dimensions of data quality and explain one of them.
4. What is the purpose of a business glossary?
5. Why should migration include rehearsal and reconciliation?

5 Long Answer Questions

1. Explain how data owners, data stewards, system owners, and data custodians contribute to ERP data governance.
2. Discuss the relationship between master data, reference data, metadata, and interoperability.
3. Develop a governance process for creating and approving a new supplier record.
4. Evaluate the advantages and limitations of centralized golden-record architectures.
5. Explain how privacy, segregation of duties, and ethical AI considerations should influence ERP data management.

3 Analytical / Application Questions

1. A company has three customer databases with different identifiers, addresses, and status codes. Design a phased MDM and migration approach, including ownership, standards, quality checks, and reconciliation.
2. An interface transmits inventory quantities successfully, but one system records cases and another records individual units. Analyze the semantic interoperability problem and propose controls.
3. Design a data-quality scorecard for a supplier master. Select suitable dimensions, define at least two measurable indicators, identify risk-based thresholds, and explain how exceptions should be governed.

Multiple Choice Questions with Answers

Question 1

Which statement best describes master data?

A. Data that records individual business events such as invoices

B. Shared, relatively stable data describing entities used across processes

C. Temporary data created only for system testing

D. Uncontrolled values entered by individual users

Correct Answer: B. Shared, relatively stable data describing entities used across processes

Question 2

What is the most accurate interpretation of the single-source-of-truth principle?

A. All enterprise data must be stored in one physical database

B. Each employee may select whichever system appears most current

C. Each defined data element or purpose has an authoritative governed source

D. Data must never be replicated between systems

Correct Answer: C. Each defined data element or purpose has an authoritative governed source

Question 3

Which role is primarily accountable for the business meaning and fitness of a data domain?

A. Data domain owner

B. Network technician

C. Report consumer

D. Interface scheduler

Correct Answer: A. Data domain owner

Question 4

If 9,600 of 10,000 supplier records contain valid tax identifiers, what is the completeness rate?

A. 9.6%

B. 40%

C. 96%

D. 104%

Correct Answer: C. 96%

Question 5

Which item is an example of reference data?

A. A posted customer invoice

B. A warehouse goods receipt

C. A supplier bank account

D. An approved currency code

Correct Answer: D. An approved currency code

Question 6

Why is a business glossary important?

A. It increases network bandwidth

B. It establishes shared meanings for important business terms

C. It automatically deletes duplicate transactions

D. It replaces all data-security controls

Correct Answer: B. It establishes shared meanings for important business terms

Question 7

Which migration activity identifies missing values, duplicates, obsolete records, and format problems?

A. Data profiling

B. System decommissioning

C. User password rotation

D. Interface encryption

Correct Answer: A. Data profiling

Question 8

A system sends a quantity of 10, but the receiving system interprets it as 10 individual units when it means 10 cases. What type of problem is this primarily?

A. Semantic interoperability problem

B. Physical storage problem

C. Payroll authorization problem

D. Backup scheduling problem

Correct Answer: A. Semantic interoperability problem

Question 9

Which control best reduces the risk of duplicate supplier creation?

A. Allowing unrestricted manual entry

B. Removing supplier identifiers

C. Duplicate detection during onboarding

D. Archiving all supplier records immediately

Correct Answer: C. Duplicate detection during onboarding

Question 10

Why should high-impact AI-assisted entity merges include human review?

A. Probabilistic matching can produce incorrect merges

B. AI cannot process any structured data

C. Human review eliminates the need for metadata

D. Entity matching never requires auditability

Correct Answer: A. Probabilistic matching can produce incorrect merges