Who Owns the Number? How to Assign Data Ownership Across Departments

Every leadership meeting has a version of the same moment. Someone shows a number, someone else says it does not match theirs, and the next twenty minutes go to arguing about whose spreadsheet is right instead of deciding what to do. The number is rarely the real problem. The problem is that nobody was ever asked to own it.

Data ownership in business sounds like an IT topic, but it is an operating question: who is accountable when a metric is wrong, who decides what it means, and who approves changes to it? In a single-site company the answer is usually whoever built the report. Across many locations, departments and systems, that answer stops working, and nobody notices until a board pack contradicts a regional dashboard.

This article covers who owns data in a company in practical terms: why unowned metrics drift, how to diagnose it, what it costs, and a lightweight model of four assignments per metric that needs no governance committee. It then explains where The Ninjaz Group and the Ninjaz Operating Platform fit.

Why metrics without an owner drift

A metric is not a fact. It is a set of decisions about what to count, where to count it from, and when to count it. Terms like active customer, open order, first response time and gross margin each hide a dozen choices. When no one owns those choices, they get remade by whoever builds the next report.

Definitions fork first. Sales counts a customer as active after one purchase, service counts only customers with an open contract, and finance counts anyone invoiced in the last twelve months. Each is reasonable. Together they guarantee three answers to one question.

Sources multiply next. A figure pulled from the ERP gets exported, adjusted by hand and pasted into a workbook, and the copy outlives the original. Then fixes go unrecorded: someone corrects a mapping in one report and not the other six. Finally, changes arrive silently. An administrator adds a status value in the CRM, and every report filtering on the old list shifts without anyone deciding it should.

None of this is anyone's job, so none of it gets resolved. Disputes are postponed, or settled by whoever has the most authority in the room, which is not the same as being right.

How fragmented systems turn a metric into an argument

Consider a group with twelve locations. Sales works in the CRM, purchasing and stock in the ERP, invoicing and cost in the finance system, and customer issues in the helpdesk. Leadership asks two plain questions: what is revenue per customer, and how many customers are unhappy?

The CRM holds a customer record per location, so one company appears up to twelve times. The ERP holds an account per billing entity. Finance rolls up to the parent. The helpdesk identifies people by the email address on the ticket. That is four systems and four customer identifiers. Revenue per customer depends on which one you divide by, and the complaint rate depends on matching tickets to accounts, which someone does by hand each month and slightly differently each time.

Every location manager sees a number that is correct for the system they use. The regional lead sees another. Finance's figure reconciles to the ledger, so it is treated as official, yet it cannot be drilled down to a site. Nobody is wrong, and nobody owns the reconciliation between them.

The same pattern appears inside single departments. Helpdesk response time can mean time to first reply, time to first human reply after an automated one, or time to resolution, and the choice changes the result considerably. Each is a legitimate metric. The trouble is that all three go by the same name.

That is why data governance for operations has to be about named people and decisions rather than tools. Fragmentation creates the versions. Ownership decides which one is authoritative and how the others relate to it.

How to tell you have an ownership problem

You do not need an audit to find out. Look for these signs:

• The same KPI has different values in two places, and the first question in the meeting is "which report is that from?"
• Nobody can say, without checking, which system a metric comes from.
• Definitions live in people's heads or in the footnotes of one slide deck.
• A report breaks after a system change and takes days to trace.
• Manual reconciliation happens every month, always by the same person, who is not formally responsible for the result.
• Teams keep private versions of shared numbers because they do not trust the shared one.
• Escalations about numbers go to executives because no one closer can decide.

A quick test: pick your five most-quoted metrics and ask three people in different departments who owns each. If you get silence, or three different names, you have your answer.

What an unowned number costs

The cost rarely shows up as a line item, which is why it persists. It shows up as time, as stock, as missed revenue and as tired people.

Time goes first. Analysts and managers spend hours each reporting cycle reconciling exports and defending figures instead of acting on them. Inventory follows: if the ERP and the site-level view define available stock differently, purchasing orders against the wrong number, and one location overstocks while another runs short. Deals are lost when a sales team chases leads the CRM shows as untouched while service has already spoken to the customer, or when pricing and margin figures disagree and quotes wait for approval.

Mistakes compound quietly. A bonus calculated on one definition of a metric and reviewed on another creates disputes that damage trust. Burnout grows in the people who act as human reconciliation layers, the one person who knows why the numbers differ and gets every call about it. And customers feel it when a support agent cannot see the order history that sales and finance both hold, so the customer explains the problem a second and third time.

None of this needs bad intent. It is what happens when reasonable people each make local decisions about a shared number.

A lightweight ownership model: four assignments per metric

Heavy governance programs fail because they try to own all data at once. Start instead with the metrics leaders actually use, and for each one assign four things.

Source system. Name the one system of record the metric is calculated from: the CRM for pipeline, the ERP for stock and purchase orders, the finance system for revenue and cost, the helpdesk for tickets and response times. If a number needs two systems, name the one that wins when they disagree.

Definition. Write the definition in plain language: what is counted, what is excluded, the time window, the unit and the level of detail (location, region, group). One short paragraph, stored where everyone can find it.

Quality checks. Decide what "wrong" looks like and who looks for it. Examples include duplicate customer records, tickets without an account, orders with no cost, and sites that stopped reporting. Checks can be a weekly review or an automated alert, but each has a named person who responds.

Change approval. Any change to the source, definition or calculation goes through the owner. That includes new status values, renamed fields and altered mappings. Small changes can be approved in a message; larger ones need a note on what will shift in downstream reports.

Take the twelve-location group again. Its customer count gets a metric owner in revenue operations, the CRM as the source, a definition that counts the parent company once, a weekly duplicate check run by a steward, and a rule that no one adds or merges customer fields without the owner's sign-off. Finance still reports on its own basis, but the bridge between the two is documented.

Who does what

These assignments map onto a few data stewardship roles, and one person can hold more than one:

• Metric owner: a business leader accountable for the number and its definition, typically the head of the function that acts on it.
• Data steward: the person who runs the quality checks and fixes records day to day, often in operations or a system admin team.
• System owner: the person who controls configuration of the source system and applies approved changes.

Metric ownership sits with the business, not with IT. IT can maintain the plumbing, but it cannot decide what "active customer" means.

Putting it in place: six steps

Here is a sequence that works without a large program:

1. List the metrics that drive decisions. Start with ten or fewer: the ones in your executive pack and location scorecards.
2. Name a metric owner for each. One person, not a team. If two leaders both claim a metric, its definition is probably doing two jobs and should be split.
3. Document the four assignments. A single page or table per metric covering source system, definition, quality checks and change approval. Resist writing more.
4. Reconcile the current versions. Compare what each department reports today, agree which is authoritative, and record the bridge between the others.
5. Build the checks and approvals into daily work. Route change requests through a simple workflow with a named approver and a log, and turn quality checks into scheduled reviews or automated alerts rather than good intentions.
6. Review quarterly. Retire metrics nobody uses, update definitions as the business changes, and confirm each owner is still the right person.

The data governance workflows in step five matter more than the documents. A definition nobody has to consult before changing a field is just a document. An approval step that sits in the path of the change is governance.

Where The Ninjaz Group and the Ninjaz Operating Platform fit

Ownership is a management decision, and no software makes it for you. What software can do is make those decisions easier to keep.

The Ninjaz Group starts with a Blueprint: a map of the operation that shows where work is done twice, where data goes stale and where money leaks. In ownership terms, it surfaces which systems hold which numbers and where versions diverge. The client keeps the map, and it is a sound basis for the four assignments above.

From there, Build & Link works with the systems you already run, with no rip-and-replace. The Ninjaz Operating Platform is the integration hub Ninjaz deploys and runs, with connectors to CRM, ERP, finance, helpdesk and other systems. Its unified data layer keeps one record per customer, asset and order, which addresses the four-identifiers problem at its root rather than through monthly manual matching. The Command Center shows live KPIs and alerts across locations, so a metric is calculated once and everyone looks at the same figure. Roles and an audit trail record who changed what, and workflow automations can route change requests and quality alerts to the named owner.

Through Managed Link, Ninjaz builds, owns and maintains the integration layer between your systems. Managed Business Operations covers managed IT and day-to-day running after go-live, so the platform and its routines do not depend on one person's memory. To be clear about the limits: Ninjaz can implement and run the mechanics, but your leaders still have to decide what each metric means and who owns it.

Start with one number

Pick the metric that causes the most arguments in your next leadership meeting. Name an owner, write the four assignments on one page, and see how many disputes disappear. Then repeat.

If you want help mapping where your numbers come from and who should own them, book a consultation. If you would rather see how a unified data layer and Command Center work in practice, watch the platform demo.