When organizations struggle to trust their dashboards, reports, and analytics, the diagnosis is usually predictable: there is a data quality problem. Customer records are duplicated, product classifications are inconsistent, critical fields are missing, and numbers reported by Finance do not match those presented by Sales or Operations.

The response is equally predictable. Organizations launch data-cleaning exercises, introduce additional validation rules, establish governance committees, or invest in new technology platforms designed to improve the quality and consistency of enterprise data.

Yet, after months of effort and significant investment, the same problems frequently return.

I believe the reason is straightforward. Most organizations do not primarily have a dirty data problem. They have a business discipline problem that eventually becomes visible in their data.

Data rarely becomes inconsistent by itself. A duplicate customer record is often the consequence of a poorly designed customer onboarding process. Conflicting KPIs emerge because different functions have developed their own definitions over time. Missing information may indicate that employees do not understand why the data is being collected or that the process makes accurate data entry unnecessarily difficult.

What we call “dirty data” is therefore often the digital footprint of thousands of operational decisions, process gaps, unclear responsibilities, and inconsistent behaviors accumulated over many years.

This distinction matters because organizations continue to invest heavily in cleaning data downstream while paying insufficient attention to the business processes creating the problems upstream.

We Keep Trying to Fix Data at the Wrong End

Consider how a typical analytics transformation begins. An organization decides that it needs better visibility into business performance. It invests in a modern data platform, integrates information from multiple systems, develops dashboards, and creates sophisticated reporting capabilities.

Then the problems begin.

Customer names do not match across systems. Product hierarchies have evolved differently across business units. Financial and operational systems use different definitions. Important fields are incomplete. Multiple records represent the same supplier or customer. Business rules embedded in legacy systems are poorly documented or no longer understood.

Suddenly, what was intended to be an analytics initiative becomes an extensive data-cleaning exercise.

There is nothing inherently wrong with cleaning data. Every organization needs processes to identify, correct, and manage data-quality issues. The problem arises when cleaning becomes a substitute for addressing the underlying cause.

An organization may spend months deduplicating customer records without changing the process that continues creating duplicates. It may standardize product classifications without establishing ownership of the product taxonomy. It may reconcile conflicting KPIs without requiring business leaders to agree on common definitions.

The immediate problem is resolved, but the system continues producing new problems.

Cleaning data without changing the process that created it is like repeatedly repairing a defective product without correcting the manufacturing process. The organization becomes more efficient at managing failure rather than preventing it.

This is why I increasingly believe that data quality should be viewed less as a technical discipline and more as an organizational capability.

The Most Dangerous Data Problems Are Often Invisible

When people discuss dirty data, they usually think about obvious issues: duplicate records, spelling errors, inconsistent date formats, missing values, and incorrect addresses.

These problems are important, but they are not necessarily the most dangerous.

The data-quality issues that concern me most are often technically correct, perfectly formatted, and fundamentally misleading from a business perspective.

Consider a seemingly simple metric: an active customer.

Sales may define an active customer as an organization with an open opportunity. Finance may consider a customer active only if it has generated revenue during the financial year. Marketing may classify anyone who has engaged with a campaign during the last 90 days as active. Customer success may use product usage as the primary criterion.

Each team can create an accurate report based on its definition. Every query can run successfully. Every dashboard can refresh on time.

And yet, the organization may have four different answers to the same question.

This is not a technology problem. It is not even a conventional data-quality problem. It is a business-definition problem that has manifested itself through data.

The same issue occurs with metrics such as revenue, churn, profitability, qualified leads, on-time delivery, customer acquisition cost, and inventory availability. Organizations can spend millions building modern data platforms while fundamental business definitions remain unresolved.

This is why I do not believe data quality should be measured only through technical dimensions such as completeness, validity, accuracy, and uniqueness.

A more important question is: Can leaders confidently use this data to make a decision?

That is a much higher standard.

From Clean Data to Trusted Decisions

The objective of a data-quality initiative should not be to create perfect data. In most large organizations, achieving perfect enterprise data is neither realistic nor economically desirable.

The objective should be to create sufficiently reliable data for important business decisions.

I use a simple framework to think about this: TRUST — Truth, Responsibility, Uniformity, Source, and Timeliness.

The framework starts from a different premise. Rather than asking how an organization can clean all its data, it asks what conditions must exist for decision-makers to trust and act on that data.

Truth: Define the Business Reality Before Building the Data

Every meaningful data initiative should begin with a deceptively simple question: What business truth are we trying to represent?

What exactly constitutes a customer? When should revenue be recognized for management reporting? At what point is an order considered complete? What makes a lead qualified? When should a customer be classified as having churned?

These questions may appear basic, but they are often surprisingly difficult to answer consistently across a large organization.

The challenge is that technology cannot resolve disagreements about business meaning. A data engineer can integrate multiple systems. An analyst can create calculations. A dashboard can visualize the result. But none of them can independently determine which business definition the organization should adopt.

That requires management judgment.

Before organizations invest heavily in pipelines, dashboards, analytics, or governance technologies, they need to establish the business truths that their data is expected to represent.

A single version of the truth requires an agreed version of the meaning.

Responsibility: Put Data Ownership Where It Belongs

One of the most persistent problems in enterprise data management is unclear ownership.

When asked who owns the data, many organizations point toward IT, the data team, or the analytics function. I believe this is a fundamental mistake.

Technology teams may own systems. Data engineering teams may own pipelines. Analytics teams may own reports and models. However, the business must own the meaning and quality of the information generated through its processes.

Who owns the definition of a customer? Who is responsible for the product hierarchy? Who approves changes to supplier classifications? Who decides how profitability should be calculated? Who is accountable when critical information is repeatedly missing?

Without clear answers, data-quality problems become organizational orphans. Everyone uses the data, everyone complains about its quality, but nobody has sufficient authority or accountability to fix the underlying problem.

Data without ownership eventually becomes data without trust.

Effective data governance therefore requires more than committees, policies, and data catalogs. It requires explicit accountability for critical data domains and business definitions.

Uniformity: Consistency Often Matters More Than Perfection

Organizations frequently underestimate the value of consistency.

The same customer may appear differently across multiple systems. The same product may belong to different categories across business units. The same KPI may be calculated differently depending on who produces the report.

Each inconsistency may appear minor in isolation. At enterprise scale, however, thousands of such inconsistencies create enormous complexity.

The answer is not necessarily more governance documentation. Most employees will never read a 200-page data-governance manual.

Organizations need practical standards that employees can understand and apply. Which fields are mandatory? Which classifications are permitted? What is the accepted naming convention? Which system is authoritative? What happens when information is unavailable? How should exceptions be managed?

These may appear to be operational details, but analytics ultimately depends on patterns. When information is captured differently across teams, systems, and geographies, those patterns become increasingly difficult to identify.

In many cases, consistent data is more valuable than theoretically perfect data.

Source: Stop Managing Symptoms and Correct the Cause

The fourth principle is perhaps the most important.

Organizations should systematically identify and correct data-quality problems at the point where they originate.

If customer records are repeatedly duplicated, the question should not only be how to improve deduplication algorithms. The organization should investigate why the customer creation process allows duplicates in the first place.

If product categories require continuous manual correction, the organization should examine who owns the classification process and whether employees have sufficient guidance.

If Finance and Sales spend several days every month reconciling numbers, leaders should investigate the underlying definitions and processes rather than accepting reconciliation as a normal part of business operations.

Too many data teams have effectively become permanent cleaning departments for broken business processes.

This creates a dangerous organizational dynamic. Because the data team repeatedly fixes the problem downstream, the business experiences little pressure to improve the process upstream.

The best data-quality problem is the one that never enters the system.

This requires organizations to shift from reactive data cleaning toward preventive data management.

Timeliness: Perfect Data Delivered Too Late Has Limited Value

The final dimension is timeliness.

Data quality is often discussed as though every piece of information should achieve the same standard of accuracy. In practice, the required level of quality depends heavily on the decision being made.

A regulatory submission may require extremely high accuracy and extensive validation. A real-time operational dashboard may prioritize speed and accept a reasonable level of uncertainty. A strategic forecast may depend on assumptions that are directionally useful rather than perfectly precise.

Organizations therefore need to resist the pursuit of universal data perfection.

The better question is: How good does this data need to be for the decision we are trying to make?

This introduces an important economic dimension into the data-quality discussion. Improving data quality requires investment. Beyond a certain point, the incremental cost of improvement may exceed the incremental business value created.

The objective is not perfect data.

The objective is decision-ready data.

The Biggest Mistake Is Trying to Clean Everything

One of the reasons enterprise data-quality initiatives become overwhelming is that organizations attempt to govern and improve all data simultaneously.

Every system. Every field. Every table. Every record.

The ambition is understandable, but the approach is often impractical.

Most organizations possess enormous quantities of data. Some of it is critical to strategic and operational decisions. Some is useful for reporting and analysis. Some may become valuable in the future. And a significant amount probably creates little meaningful business value.

Treating all data as equally important creates unnecessary complexity and dilutes organizational attention.

I prefer to start from the opposite direction: begin with the decision and work backwards.

The sequence is relatively simple:

Decision → Metric → Data → Process

First, identify the decisions that matter most to the organization.

Next, determine which metrics and insights are required to make those decisions.

Then identify the critical data elements supporting those metrics.

Finally, trace the business processes responsible for creating and maintaining that data.

This approach fundamentally changes the nature of the conversation.

Instead of asking, “How can we improve the quality of our enterprise data?” leaders can ask, “What data must we trust to make our most important business decisions?”

The second question is narrower, but far more actionable.

It also creates a direct connection between data-quality investment and business value.

Better Technology Cannot Compensate for Unmade Decisions

Modern data technologies have created extraordinary capabilities. Organizations can integrate massive volumes of information, monitor data pipelines, automate validation, manage metadata, and identify anomalies at unprecedented scale.

These capabilities are valuable.

But technology works best when it automates and scales decisions that organizations have already made.

It struggles when asked to compensate for decisions that remain unresolved.

A technology platform cannot decide what the organization means by “customer.” A validation rule cannot resolve a disagreement between Finance and Sales. A data catalog cannot determine who should be accountable for a KPI. A dashboard cannot create organizational discipline.

These are management responsibilities.

And this may be the most uncomfortable truth about data quality:

Many problems we call “data problems” are actually leadership problems waiting for a decision.

Data Quality Cannot Belong to the Data Team Alone

There is another contradiction in how many organizations manage data.

Business teams design processes, capture information, define operational rules, change classifications, and use enterprise systems. Yet, when the numbers become unreliable, the responsibility for fixing the problem is frequently transferred to the data team.

“Can you clean the data?”

Of course, data professionals have an important role. They can identify anomalies, establish controls, improve pipelines, create monitoring mechanisms, and help organizations understand the consequences of poor data quality.

But sustainable improvement requires shared accountability.

The business must own meaning and process. Technology teams must ensure system integrity. Data teams must create reliability and transparency. Leadership must establish accountability and resolve conflicts.

Trusted data is not the responsibility of one department. It is an organizational capability.

The Real Test of Data Quality Happens in the Meeting Room

For me, the ultimate measure of data quality is not the percentage of missing values, the number of duplicate records, or the volume of validation rules implemented across the organization.

The real test happens in the meeting room.

A dashboard appears on the screen.

Leaders look at the numbers.

And instead of spending the next 30 minutes debating whether the data is correct, the conversation immediately moves to more important questions.

• What happened?
• Why did it happen?
• What should we do next?

That is when data starts creating value.

The purpose of trusted data is not cleaner databases. It is not more sophisticated dashboards. It is not even better analytics.

The purpose of trusted data is to enable better decisions.

So the next time someone says, “We have a dirty data problem,” I believe leaders should resist the temptation to immediately launch another cleaning exercise or technology initiative.

They should look deeper.

At the definitions behind the data. At the ownership of critical information. At the consistency of business processes. At the source of recurring errors. At the decisions the organization is trying to make.

Because the data may not actually be the problem.

It may simply be revealing the problems the business has learned to ignore.