Before you move a piece of data, name its owner

In 1 minute

When a company brings its data together in one place, the technology does not replace the agreement on who answers for each set of data. If a figure comes out wrong, who fixes it, in which system and with what agreed priority? Industry practice asks for three things before loading any data: an owner with a name, a written agreement between whoever produces the data and whoever uses it, and a few quality rules that can be checked on every load. Not everything calls for the same rigor: with a single source and a narrow use, you can start light.

Imagine a mid-sized distribution company. It is fictitious, but it looks like many. It sells through three channels, invoices in one system, keeps inventory in another and collections in a third. At the end of every month, Finance and Sales arrive at the meeting with a different figure for net sales.

Management decides to solve it once and for all: bring all the data together on one platform, with dashboards for every area. The project starts well. After three months the data is arriving, the dashboards look good and the meeting… is the same as before. Now they argue in front of a bigger screen.

What happened? Nobody asked a simple question before moving the first piece of data: who answers for it?

This article is for whoever is about to approve —or has already approved— a project to bring the company's data together. It makes one argument: before moving a piece of data, you name its owner, you write down what it promises and you decide how it is checked. The technology comes after.

Why data without an owner falls apart

A sales figure is produced by one area (the one that invoices), transformed by others (the one that reconciles, the one that builds the report) and used by many. When something goes wrong, each one can point at the next. If nobody is responsible for that figure being correct, the error is fixed by hand in the report, every month, and the next one shows up again.

The industry has been naming this problem for years. Zhamak Dehghani, in the text that gave rise to the idea of data mesh, proposes spreading the responsibility for data among "people who are closest to the data" and treating each data set as a product, with its users treated as customers [1]. You do not need to adopt that whole approach to keep the essential part: data that is shared needs someone who answers for it, just as a product needs someone who answers for its quality.

Three things you define before loading

1. An owner with a name, not an area

"Finance looks at it" is not an owner. An owner is a person with a name, in the area that produces the data or the one that understands it best, who has three responsibilities:

• Say what the data means. What is a "net sale": with or without returns? With or without credit notes? At the invoice date or the collection date?
• Approve changes. If the source system changes a rule, the owner decides whether the definition changes too and tells whoever uses the data.
• Respond when it does not add up. When a check fails, someone has to answer, within an agreed time.

The UK government's data quality framework assigns to the data owner decisions such as whether data that is no longer used is archived or destroyed, and asks that information about its quality be stored with the data [3]. It is public guidance, not a rule for your company, but the principle holds all the same: decisions about a piece of data have someone responsible.

2. A written agreement between whoever produces and whoever uses

The second step is to put in writing what that data set promises. The industry calls it a data contract: an agreement between whoever produces the data and whoever consumes it. The open standard for these contracts, the Open Data Contract Standard (Bitol project, under the LF AI & Data Foundation), organizes them in sections: fundamentals, the structure of the data, quality rules and support channels, among others [2].

A committee does not need a technical format. It is enough that the agreement answers, on one page:

• What it contains: which fields, with what meaning and in what unit.
• How often it arrives: at the close of the day, every hour, as it happens.
• What quality it promises: the rules in the next section.
• Who is told when something changes or fails, and how quickly it is handled.

The agreement protects both sides. Whoever uses the data knows what to expect; whoever produces it knows what it cannot change without notice.

3. A few quality rules that are checked on every load

Quality is not declared; it is checked. The UK framework uses six dimensions defined by DAMA UK: completeness, uniqueness, consistency, timeliness, validity and accuracy [3]. Its example is useful: 300 students, 294 emergency phone numbers captured; the field is 98% complete, but that does not say the phone numbers are correct. Complete is not the same as correct.

Translated to a company, the first rules tend to be simple:

Example rules, for illustration; each owner defines those of their company.

As a starting point, choose the rules that cover the most relevant risks of that data —missing records, duplicates, differences against the source—, agree on when they are checked and who handles a failure, and make sure the result is seen by whoever uses the data before they use it.

When you need all this and when you do not

Naming owners and writing agreements takes the time of busy people. It does not pay off in every case.

You can start light if:

• Your reports come from a single system, with a narrow use and an identified person responsible.
• It is a one-off analysis that nobody will repeat or use to decide about money.
• It is an experiment with test data, with no effect on operations.

Even in those cases, and more so if personal data or a regulatory obligation is involved, put in writing what the data means, who answers for it and who can see it.

It pays to do it before loading if:

• The same number is built from data in two or more systems.
• Two areas already arrive at the meeting with different figures for the same thing.
• The data feeds a money decision, a report to an authority or an AI model.
• New sources will come in every year: each one multiplies the ways of getting it wrong.

What we ruled out, and why

• "First we load everything and then we see." It is the most common temptation, because it feels like progress. The problem is that governance added later, on data that is already in use, is negotiated with areas that have already built reports on different definitions.
• "Let IT be the only owner of the data." IT can answer for operation, security and access, but it is not for IT to decide whether a return subtracts in the month of the sale or in the month of the credit note. That meaning, its use and its quality belong to the business area. Put both roles in writing, and who resolves it when they do not agree.
• "A data committee decides everything." A committee helps resolve conflicts between areas, but if every change waits for its monthly session, people go back to the spreadsheet. The owner decides changes within their scope; if a change touches a shared definition, access, privacy or another area, the committee resolves it, with a person responsible and a date.
• "Buying a catalog tool solves governance." A tool stores definitions; it does not write them or make them stick. Without owners, the catalog fills up with fields that have no description.

Five questions for your next board meeting

1. Who, by name, answers for each of the five numbers most argued about in the meeting?
2. Is it written what each one means, and did its owner approve it?
3. Which rules are checked on every load, and who sees the result before the number is used?
4. When a rule fails, who is told and how quickly is it handled?
5. If the source system changes a rule, who finds out before the report goes wrong?

If most of the answers are "nobody" or "it depends", the data project is not ready to grow yet.

Where to start this week

Take the three data sets behind the numbers that are argued about most —invoices, payments, inventory, whichever they are— and fill in one sheet for each:

• Owner: name and area; and, separately, who runs it in IT.
• Who uses it: which areas and for which decisions.
• What it promises: what it contains and how often it arrives.
• Rules: how you know it is complete, free of duplicates and reconciled against its source.
• Access: who can see it.
• Notice: who is told when it does not add up, and with what priority it is handled.

If any box stays empty, that is the first task, before buying or building anything.

What Hábil does

At Hábil we build custom systems and integrations that move your company's data, and we operate the platform where that data comes together.

If your company needs a single version of its numbers, the proposal is in Hábil Lake. We choose together the three to five questions that cost you the most today. For each one we put in writing which system each piece of data comes from, how it is calculated and what it is reconciled against. Every load is compared against the source system —counts, sums, totals by date— and the result is visible, like a traffic light: it reconciles or it doesn't. Each table has its description, its source system and the record of the tables it comes from, and access is granted by role.

The conversation can start with your three sheets, even if they are half done: which data, who produces it and where the figures part ways. With that, we review together where it makes sense to start. Write to us on WhatsApp; to protect your information, do not share data about your customers or your systems through that channel: we will agree in the conversation on the channel for the case.

Request your first conversation, at no cost.

Consulted on 13 November 2026. Each reference carries its confidence: high (primary source read).