Data Quality Management: Six Dimensions and Who Owns Each One

Most organisations treat poor data as a cleansing problem. That is usually the wrong diagnosis. Data quality management is primarily an accountability problem: someone must define what “good enough” means for each data domain, approve measurable thresholds, own exceptions and fix the process that keeps creating bad records.

Without that ownership, analytics teams repeatedly clean the same customer, supplier, product or financial data while source systems continue producing defects. A wider (enterprise data strategy) should therefore define ownership and authoritative sources before quality teams attempt to standardise everything centrally.

Data Quality Management: Why Poor Data Is an Ownership Problem

• Technology can detect defects: It can flag missing fields, invalid formats, duplicates and inconsistencies, but it cannot decide which business definition is correct.

• Data teams do not own business meaning: An analyst may identify that two revenue figures disagree, but finance must decide which definition is authoritative.

• Quality is domain-specific: A missing mobile number may be tolerable in one dataset and business-critical in another.

• Thresholds require business approval: Engineering can calculate completeness or accuracy, but the domain owner must decide what level is acceptable.

• Recurring defects have process causes: If the same field is corrected every month, the real problem may be the source workflow, application configuration or responsibility model.

This is why a permanent cleansing team rarely solves enterprise data quality. It can improve the current dataset while leaving the process that creates the defect untouched.

Where ownership is disputed across departments, the problem may extend beyond data governance into operational accountability. In that situation, (business management consulting) can help clarify decision rights and process ownership before the organisation attempts to enforce technical quality rules.

The Six Dimensions of Data Quality

A practical data quality framework needs measurable dimensions rather than a single statement that data should be “clean”. The same record can perform well on one dimension and fail badly on another.

1. Accuracy

Accuracy asks whether the stored value reflects the real-world value it is intended to represent. A customer address may be complete and correctly formatted while still being wrong.

Accuracy is often the hardest dimension to measure because a reference source is required. That source may be an authoritative system, verified external source, physical event or confirmed business transaction.

2. Completeness

Completeness measures whether the required data is present. The key word is “required”: not every blank field is a quality defect.

For example, a tax identifier may be mandatory for a particular supplier type while a secondary telephone number remains optional. Completeness rules should therefore follow business purpose rather than counting every null value equally.

3. Consistency

Consistency tests whether the same concept agrees across systems, records or calculations. If CRM classifies a customer as active while the billing system treats the same account as closed, the organisation has a consistency problem.

The solution is not always to make every system identical. It is to define which source owns each attribute and how downstream systems should synchronise it.

4. Timeliness

Timeliness measures whether data is current enough for the decision it supports. Data can be technically accurate but operationally useless if it arrives after the decision has already been made.

A monthly reporting dataset and a fraud-detection workflow therefore need very different freshness requirements.

5. Validity

Validity asks whether data follows the required format, type, range or business rule. Examples include valid dates, recognised country codes, approved product categories and permitted status values.

Validity is usually easier to automate because the rule can often be tested directly at entry or during processing.

6. Uniqueness

Uniqueness measures whether the same real-world entity is represented more than once when the business expects one record.

Duplicate customers, suppliers or products can distort reporting, fragment transaction history and create competing “truths” across departments. Resolving them requires both matching logic and a business rule for deciding which record survives.

Once these six dimensions are defined, (data analytics services) can focus on measurement, profiling and remediation against agreed standards instead of inventing quality definitions during reporting work.

Set Measurable Thresholds by Data Domain

A single enterprise rule such as “data must be 95% complete” is rarely meaningful. Customer, supplier, asset, financial and employee data support different processes and therefore need different thresholds.

A practical threshold model can be built in four steps:

1. Identify the Business Outcome

Start with the process or decision the data supports. The acceptable quality level for regulatory reporting may be different from the level required for exploratory marketing analysis.

2. Select Relevant Dimensions

Not every domain needs equal weighting across all six dimensions. Timeliness may dominate operational telemetry, while uniqueness and accuracy may matter more for customer master data.

3. Define the Threshold and Escalation Point

State the acceptable level and what happens when performance falls below it. A metric without an escalation rule is only a measurement.

4. Name the Business Owner

Quality thresholds hold only when a named business owner signs off on them. The owner should be able to explain why a threshold is acceptable and what trade-off exists between stricter controls and operational effort.

This is the same principle that applies to trusted management reporting. A mature (business intelligence strategy) should connect metrics to accountable owners instead of allowing each reporting team to define quality independently.

Master Data and the Golden Record

Master data management becomes relevant when several systems maintain overlapping versions of core entities such as customers, suppliers, products, employees or locations.

The objective is not necessarily to place every attribute in one database. It is to establish which source is authoritative, how conflicting records are resolved and how trusted values move to consuming systems.

What Makes a Golden Record?

• Identity resolution: Determine which records represent the same real-world entity.

• Source precedence: Define which system wins when attributes conflict.

• Survivorship rules: Specify which values remain after records are matched or merged.

• Ownership: Assign responsibility for disputed values and exceptions.

• Distribution: Define how the trusted version reaches downstream systems.

A golden record should therefore be the result of governance rules, not simply the output of a matching algorithm.

This becomes especially important during major platform changes. Poor-quality master data transferred into a new ERP does not become better because the target application is newer. A structured (erp data migration) programme should decide what is cleansed, merged, archived or rejected before cutover.

Stop Defects at the Point of Entry

The cheapest quality defect to remediate is usually the one that never enters the dataset. Quality controls should therefore be pushed upstream wherever the business process allows it.

• Required-field controls: Prevent critical fields from being left empty when the business process genuinely requires them.

• Reference lists: Use controlled values for countries, products, branches, statuses and other standard classifications.

• Format validation: Validate dates, identifiers, codes and numeric ranges before records are committed.

• Duplicate detection: Warn users when a likely customer, supplier or asset already exists.

• Workflow approval: Require review when high-impact records or sensitive attributes change.

• Source-system ownership: Fix the application or process that creates the defect instead of relying on downstream correction.

When the Problem Is Between Systems

Some defects are not created by users at all. They appear when systems transform, truncate, map or synchronise data incorrectly.

When quality failures occur at integration boundaries, (systems integration services) may need to address mapping rules, APIs, field ownership and error handling rather than introducing another cleansing step downstream.

Remediate Data Without Creating a Permanent Cleansing Factory

Enterprise data cleansing is sometimes necessary, particularly before migrations, regulatory remediation or major analytics programmes. The mistake is allowing cleansing to become the permanent operating model.

A scalable remediation process separates correction from prevention:

1. Profile the Defect

Determine which quality dimension is failing, which records are affected and whether the problem is concentrated in a particular source, branch, user group or process.

2. Correct Business-Critical Records

Prioritise records according to operational impact rather than attempting to clean the entire estate with equal urgency.

3. Find the Root Cause

Ask why the defect was possible. Common causes include weak validation, unclear ownership, duplicate source systems, integration mapping errors and manual workarounds.

4. Change the Source Process

Update the application rule, workflow, integration or ownership model that produced the defect.

5. Re-measure the Dimension

Confirm that the corrective action improved the relevant metric and that new records no longer reproduce the same failure.

This distinction is particularly important for AI programmes. Models built on inconsistent, stale or poorly owned information inherit those weaknesses. Organisations planning AI use cases should therefore assess (enterprise ai readiness) before treating model selection as the first problem.

Data Quality Scorecard

A scorecard should be small enough for business owners to act on it. Avoid dozens of metrics that show technical detail without making responsibility clear.

The scorecard becomes useful when the owner can act on the result. If a dashboard shows deteriorating customer-data completeness but nobody has authority to change the intake process, measurement alone will not improve quality.

Where disputed metrics are already affecting executive reporting, (business intelligence consulting) can help separate reporting-design problems from upstream data-quality and ownership failures.

If your organisation has quality metrics but cannot identify who owns each failure, use (our five-stage methodology) as a practical sequence for identifying the business problem, evaluating root causes, designing controls and implementing remediation only after ownership is explicit.

Make Data Owners Responsible for Quality, Not the Analytics Team

A sustainable data quality management programme does not begin by hiring more people to clean records. It begins by assigning named owners, defining quality dimensions by domain and deciding which thresholds are acceptable for each business use.

Use cleansing to repair existing defects, but fix validation, integration, ownership and operating processes so the same defects stop returning. Treat master data as governed business information, not merely a technical table.

The practical test is simple: for every critical data-quality metric, someone should be able to explain what the threshold means, why it matters, what action follows a failure and who has authority to fix the source.

Data Quality Management FAQs: Ownership, Metrics and Master Data

What are the six dimensions of data quality?

The six commonly used dimensions are accuracy, completeness, consistency, timeliness, validity and uniqueness. They measure different types of failure, so a dataset should not receive a single vague “quality” score without showing which dimension is weak. Organisations should select the dimensions that matter for each data domain and connect them to measurable thresholds.

Who should own data quality in an organisation?

Business and data-domain owners should own the meaning and acceptable quality of critical data, while technology teams implement controls, monitoring and pipelines. Analytics teams can measure defects but should not decide business definitions alone. Ownership should sit with a role that has authority to change the process or system creating the problem.

How should data quality metrics be set?

Start with the business process or decision that uses the data. Select the relevant quality dimensions, define a measurable metric, set an acceptable threshold and name the owner who approves it. Different fields and domains may require different thresholds. A universal percentage across the entire organisation rarely reflects actual operational risk.

What is the relationship between master data management and data quality?

Master data management establishes how core entities such as customers, suppliers and products are identified, owned and shared across systems. Data quality measures whether those records are accurate, complete, consistent and usable. MDM can reduce duplication and conflicting definitions, but it still requires business ownership and quality rules to determine which values should become authoritative.

Can data cleansing fix poor enterprise data quality?

Data cleansing can correct existing records, but it does not automatically stop new defects. Sustainable improvement requires finding why the error occurs and fixing the source process, validation rule, application, integration or ownership model. Cleansing is most useful as remediation; it becomes expensive technical debt when used permanently instead of addressing root causes.