One factory weighs waste on the weighbridge. Another factory estimates it based on container volume. Both supply a figure for the same line in the report. Nobody lied, nobody made a mistake. It's just that the definition of that data point was never recorded, so each unit chose the most logical interpretation available to it.
This is not an exception. It is the normal state of an organization where the same metric is supplied by different teams, with different source systems and different history. The question is not how you eliminate this difference before it arises. The question is what you do with it once you see it.
The step that is usually skipped is that the definition itself is written down somewhere. Not in the head of the controller who has been doing it this way for years, but in a register: this data point means this, is measured this way, and does or does not include these units. What counts as a valid value within that definition and who notices when a submission falls outside it is described on the page about what a valid value is and who notices when a value falls outside it. Without that record, every sum across units is a sum of things that aren't quite the same, wrapped in one figure that looks unambiguous but isn't.
This recording is precisely the work of the Data Readiness Scan: not rewriting the report, but building the data point register in which it's stated for each data point what it is, where it comes from, and who signs off on it. That register is where the difference between units becomes visible, instead of only becoming visible after the figure has already been added up.
Once you see that unit A and unit B understand the same data point differently, there are roughly three routes.
The first is harmonizing: enforcing one definition across the whole organization, with all the system adjustments that come with it. That is often the right route in the longer term, but not something that gets done overnight.
The second is documenting and correcting: leaving the deviation where it is, but recording how large it is and using a fixed conversion to make sure the total still adds up. This works when the difference is stable and known — for example, when one site structurally uses a different measurement method that can be traced.
The third is flagging: not correcting, but raising a flag as soon as a submission deviates from the pattern you're used to seeing from that unit. How you set up such a deviation flag and who is notified is worked out on the page about how you set up a signal deviation and who notices when it happens. This route isn't there to solve the problem, but to prevent it from going unnoticed while you work toward a structural solution.
Which route is appropriate depends on how many units deviate, how stable that deviation is, and how much time there is before the figure enters a reporting period. That is a judgment call that differs per organization and one this register does not make for you — it does make visible that the judgment call needs to be made.
Definition mismatch is one of the quietest errors there is, because each unit is correct on its own. The site that estimates based on container volume does nothing wrong within its own process. The problem only arises at the level where the figures come together, and it's precisely there that often nobody has been assigned to check whether the underlying definitions are even comparable.
That is why ownership per data point is just as important as the definition itself. Which checks belong to a data point and who notices when one of those checks is skipped is described on the page about which checks belong to a data point and who notices when one is missing. Without a designated owner, the question 'but who actually sees this' remains unanswered, even if the definition is written down on paper.
It's tempting to want to solve this problem with a system that automatically normalizes submissions. But a tool placed on top of a collection of undefined data points normalizes nothing — it just packages the same differences into a neater interface. The order that holds up is to first record the definition and the ownership, and only then look at which system fits. Why that order is not a coincidence is worked out on the page about buying a tool first or setting up the process first.
Once it's established per data point what the definition is, who the owner is, and which deviations are flagged, a different kind of question arises: who will actually carry out the work that belongs to those checks — recalculating, following up with the unit that deviates, maintaining the register itself. Part of that work is repeatable enough to hand over to an automated step, part requires judgment that stays with a person. The work scan from FTE TO AI calculates, per task, what portion of it can be taken over by AI, based on the same kind of concreteness as this register: not the question of whether automation is possible, but which portion of which task falls under it.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.