Data Governance and Data Quality: Why Good Data is Not a Software Feature

The new PIM system is live. Data has been migrated, workflows set up, and interfaces tested. Almost all indicators on the dashboard are green. The project team is satisfied.

Six months later, the world looks a little different.

Some product attributes are only maintained sporadically. Two departments use different values for the same property. New employees are unsure who is authorized to approve changes. Technical information is missing for individual products in the webshop, while seemingly similar data is fully available in the ERP. And when a new marketplace is to be connected, it turns out that no one can definitively say which source is actually authoritative for certain information.

The system still works. But the data is becoming less and less effective.

At this point, two topics converge that are often considered separately when selecting and implementing PIM, MDM, or other data management solutions: data governance and data quality.

Both belong together. And both begin much earlier than the selection of a software.

The Most Important Thing First:

• Data quality describes the state of the data. Data governance creates the structures so that this state can be achieved and maintained permanently.
  
  
• A PIM or MDM system can support rules, workflows, and quality checks – but it does not define responsibilities and goals on its own.
  
  
• Therefore, for software selection, not only functions but concrete governance and quality processes should be described and tested as requirements.

Good data is not an end in itself. When data quality is discussed, the conversation quickly turns to completeness, timeliness, or consistency. This is correct – but too narrow. The more important question is:

What must the data be good for?

Let's take a manufacturer who sells their products through their own webshop, specialist retailers, and several marketplaces. For product management, a dataset may appear complete as soon as all technical attributes are maintained.

For the customer, however, the same dataset can still be insufficient. Perhaps the information that clearly differentiates two variants is missing. Perhaps a designation is technically correct but hardly understandable for the buyer. Or a marketplace requires a feature that has not played any role internally so far.

Data quality is therefore always purpose-driven. Data only creates value when it can actually be used. For product data, this means, for example, better purchasing decisions, less uncertainty, more efficient processes, and more trust in the information provided.

The consequence of this is important: a general quality value of 95 or 98 percent says little as long as it is not clear what quality is actually needed for which process and which channel.

And who decides what "good" means? This is where data governance begins.

Let's stick with our manufacturer. Sales want to publish new products as quickly as possible. Product management values technical accuracy. Marketing needs compelling texts and images. Technical editing works with its own structures and terminologies. E-commerce, in turn, knows the requirements of the marketplaces.

Everyone works with product data. But who owns it? The answer "the PIM" would be convenient – and wrong.

A system does not have data responsibility. It can technically map responsibilities but not organizationally create them. Data governance describes the framework within which a company works with its data. This includes responsibilities, decision-making rights, quality goals, rules, and processes. Who can change what information? Who defines quality requirements? Who decides in conflicts? When is a product ready for release? And who is informed if values are missing? Only when these questions are answered can technology meaningfully support them.

Data Governance and Data Quality: Cause and Effect

The relationship can be simply described as follows: Data governance creates commitment. Data quality makes the result visible. If, for example, 2,000 products in the PIM do not have a weight specification, this is initially a data quality problem.

The governance questions begin one step earlier. For example, whether the weight is even mandatory for this product group. Who is responsible for maintenance? From which source system must a value originate? Which unit is correct in the respective context? Can a product be published without this information? And who is informed if values are missing?

Without these rules, the company can recognize an error, but can hardly prevent it from recurring. This is precisely why data quality often declines again after system implementations if governance was only considered during the project (and even then, in the hectic rush of a project with a deadline, it sometimes seems like a topic that can be dealt with later).

The system remains. The project organization, however, dissolves. Decisions are made informally again, responsibilities blur, and exceptions become the new process. Sustainable data quality therefore requires permanent structures.

The Building Blocks that Determine Data Quality

Effective data governance combines several elements: clear data organization, sufficient data expertise, regulated data management and enrichment, defined quality goals, and continuous monitoring of data quality.

What is crucial is not so much the name of the individual building blocks as their interaction.

A Data Owner, for example, can be professionally responsible and define what quality a certain data area requires. A Data Steward takes care of ensuring that rules are adhered to and problems are processed closer to the operational process. Departments provide or supplement information. Systems check mandatory fields, formats, or value ranges.

This transforms "We need better data" into a controllable process. And it is precisely at this point that data governance becomes interesting for software selection.

Why Software Selection Should Not Start with a Feature Catalog

Let's imagine our manufacturer is looking for a new PIM or MDM system. The first requirement could be:

"The system must support data quality."

Almost every provider will answer this question with yes. The selection team has not learned much from this. A better requirement only emerges from the real process:

A product manager wants to publish a new assortment. Before approval, the system should automatically check whether all information required for the product group and target channel is present. Errors should be assigned to the responsible department. Critical errors prevent publication, less critical ones only generate a warning. The history must remain traceable. Now, a software can actually be evaluated.

Can it map quality rules depending on product groups and channels? Can responsibilities be assigned automatically? Can thresholds be defined? Are there workflows for error processing? Are test rules understandable and maintainable for business users? Can it be traced when and why a value was changed? An abstract demand for "Data Quality" has become a testable use case.

Not Every Poor Data Quality Requires a New System

If product information is incomplete, contradictory, or outdated today, the cause is not automatically due to the existing technology.

Perhaps there are simply no clear responsibilities. Perhaps different definitions of the same attribute exist. Perhaps no one knows which data is really relevant for which channel. Or processes allow quality checks to be bypassed permanently. A new PIM can make such problems more visible and support them better. But it will not solve them automatically.

Therefore, before selecting software, it should be clarified which part of the problem is organizational, process-related, and technological. This not only prevents false expectations but also changes the requirements for the future solution.

From business goal to quality requirement

A meaningful selection process therefore does not begin with the question "What data quality functions does the system offer?", but with a business goal.

Suppose a company wants to shorten the time-to-market for new products. Then, it should first investigate where time is currently being lost. Perhaps products regularly wait for missing technical attributes. This leads to a quality problem. The analysis then shows that the responsible department only learns about the missing information shortly before publication. Now, governance becomes relevant: the responsibility and timing of maintenance must be changed.

Only then does the system requirement arise: the future solution should identify missing relevant information early, assign it to a responsible person, and make progress transparent.

This creates a comprehensible chain:

Business goal → Process problem → Governance rule → Quality requirement → Software function.

This order makes a significant difference for the selection. A good system supports governance – it does not replace it. Today, PIM and MDM solutions can contribute a lot to systematically controlling data quality. They can check mandatory fields and value ranges, detect duplicates, map approval rules, manage roles, calculate quality metrics, and automate processes. But they cannot decide what quality a company needs.

They do not know what information is crucial for a customer's purchasing decision. They cannot independently determine which department should take responsibility for a characteristic. And they also cannot judge whether a complicated maintenance process is organizationally sensible.

That remains the company's task. The suitable software is therefore not the solution with the most governance features, but the one that best supports the desired governance model and the necessary quality processes.

Conclusion: Data quality is measured in the system – but generated within the company

Companies invest a lot of time and money in PIM, MDM, Data Platforms, and other systems. This makes sense, because without suitable technology, large amounts of data can hardly be managed efficiently. But business value does not automatically arise with the go-live.

It arises when people can generate, maintain, and use reliable data in functioning processes. Data governance creates rules, roles, and responsibilities for this. Data quality shows whether these structures are effective. And software supports the scalable implementation of both.

For companies currently looking for a new solution, this results in a simple but important recommendation:

Do not first define what software you need. First define what data quality your business needs – and what governance is necessary to achieve it permanently. A system can enable good data. But reliably good data only arises when responsibility, rules, and technology interact.