Who is Responsible for Data Quality in the Company?

It's Friday afternoon, and the preparation of the management report still cannot begin. Sales see a different customer number in the CRM than finance does in the billing system. The warehouse inventory data does not match the webshop's, and an important spreadsheet lives in a colleague's personal folder. Naturally, the question arises: who is responsible for data quality in the company?

The short answer: not a single person. The effective answer is that every important piece of data needs a clear business owner, a responsible party for daily maintenance, and an operator for the technical environment. If these roles are not clarified, data quality deteriorates unconsciously. Simply put, no one feels it is their task to notice, correct, and prevent errors in time.

Why is data quality not solely an IT task?

In many companies, the initial reaction is that IT should sort things out. IT can indeed be responsible for ensuring systems are accessible, integrations run correctly, permissions are manageable, and data is not lost between systems. However, IT cannot decide which contact belongs to a customer, which product code is valid, or what business status an order should have.

These are business decisions. The person responsible for the sales process must define when a lead becomes a real customer. Finance must determine which invoice data is authentic and what rules govern corrections. Logistics must clarify what available inventory means, especially when reservations, returns, and external warehouses are involved.

Therefore, data quality does not start from a software issue but an operational one. First, it is necessary to understand how information is created, modified, and used. Only then can it be decided whether system settings, integration, automated checks, or new applications are needed.

Who is responsible for data quality in the company? Three levels to distinguish

In most medium-sized companies, three different levels of responsibility provide a clear framework. It doesn't require launching a complex corporate governance program, but the roles must be visible.

1. The business data owner decides on the rules

The data owner is usually the leader of the given business area. They do not correct every incorrect address or product code but determine what acceptable data is, who can use it, and what the consequences of errors are.

For example, the customer master data owner could be the commercial director. Their task is to decide whether the same customer can appear under multiple names in the system, which fields are mandatory for new partner registration, and when a record can be considered inactive. The product master data owner could be the product manager or production manager, depending on how the company operates.

This role is not an administrative label. Without decision-making authority, the data owner remains just a name in a document. If an area cannot define its own data rules, reliable reporting or consistent operations cannot be expected later.

2. The data steward ensures daily quality

The data steward, often referred to as a data steward, works closer to the daily process. They monitor discrepancies, handle correction requests, and indicate if a rule does not work in practice.

In a manufacturing company, this could be the colleague coordinating the entry of product and raw material data. In a commercial company, it might be the sales coordinator responsible for customer data. It is important that this is not automatically an additional task for an overburdened administrator. If there is no time, authorization, and well-defined process, error handling always falls behind urgent daily matters.

The data steward does not need to manually check every record. Ideally, the system prevents the most common errors: it requires mandatory fields, uses a uniform set of values, indicates duplication suspicion, or does not allow an incomplete document to proceed. However, these checks must be derived from business rules.

3. IT ensures the technical conditions

IT or the technology partner is responsible for ensuring the data path is reliable. This includes system integration, access management, logging, backup, monitoring data transfers, and technical error investigation.

If a product name modified in the webshop only appears in the ERP two days later, it could be an integration issue. However, if the product name exists in three different ways across three systems because there is no clear source system and approval process, it is primarily an operational shortcoming. The two situations may cause similar symptoms externally, but they require different solutions.

The first question: which data has real business consequences?

Not every data field needs to be treated with the same rigor. A missing secondary phone number might be inconvenient, but an incorrect tax number, bank account number, inventory quantity, or shipping address poses direct financial and customer experience risks.

Therefore, it is not advisable to start with "clean all the data." This is usually costly, slow, and quickly exhausts resources. Instead, it is better to examine where data errors cause repetitive work, delays, incorrect decisions, or disputes between departments.

A good starting point could be a few specific processes: order to invoice, quote to contract, procurement to inventory, or production order to fulfillment. In these processes, it quickly becomes visible where people manually transfer data from one system to another, where something needs to be checked in Excel, and where different truths about the same business event are born.

The lack of a source system is often the real problem

A customer's address, a product's price, or an order's status can only be reliable if it is clear which system is the primary source. If the same data can be modified in the CRM, ERP, webshop admin interface, and a spreadsheet, the company will eventually work with contradictory data.

The correct question is not whether the data should be available in every system. It is often needed in multiple places. The question is where it originates, who can modify it, how it reaches other systems, and what happens if the transfer fails.

A simple rule can eliminate much confusion: every critical data should have a designated source system. Other systems should use this and not maintain their own version. This is not always immediately feasible, especially with older systems, but as a guideline, it helps decide what needs to be fixed first.

Data quality is measurable if not discussed in general terms

"Our data is bad" is not a manageable problem statement. Management can only make decisions if it is clear what error occurs how often, how much work it causes, and which process it endangers.

Measurement can be simple. For example, in the customer master, the ratio of duplicate records, the number of incomplete mandatory fields, or the number of bounced billing addresses can be tracked. For inventory, the number and value of discrepancies, for orders, the ratio of items requiring manual correction, and in production, the number of halted or replanned jobs due to incorrect master data can provide a real picture.

The indicator itself does not improve anything. However, it helps distinguish between isolated inconveniences and regular operational losses. If the same three people spend two days reconciling order errors every month, it is not a disciplinary issue but a poorly designed process.

Do not repeatedly fix the erroneous data, but its cause

The cause of data quality deterioration is often entirely understandable human adaptation. A colleague keeps their own spreadsheet because they do not receive data from the central system in time. They enter the same information twice because the systems do not communicate. They do not fill in the mandatory field because no one explained why it matters, or because the field does not actually fit their work.

Therefore, before introducing a rule, it is worth reviewing the entire process. Who initiates it? What data is taken from where? Who checks it? Where must decisions be made? Where does re-entry occur? And why? It may turn out that a small change - such as standardizing order statuses or introducing error notifications for data transfers - is worth much more than a large data correction project.

Responsibility is thus shared, but it cannot be anonymous. The business leader defines what good data means. The designated data steward ensures daily discipline and feedback. IT ensures that systems reliably support this. If these three roles see the same operation, data will no longer be an uncertain byproduct but a usable foundation for company management.