Ask five units for the same figure — say, the number of FTEs, the fuel consumption of a vehicle fleet, or depreciated equipment — and you get five lines of reasoning that run just slightly differently. One site counts temporary staff, another doesn't. One plant reports in liters, another has already converted it to liters per vehicle per year and so delivers a different kind of figure than was asked for. On paper, it's all the same metric. In reality, these are different definitions that happen to sit in the same column.
That is not a data-entry error. No one typed anything wrong. The problem sits one layer earlier: it was never established what the valid value for this data point actually is, so each unit fills the gap with its own logic. What counts as a valid value and what does not is worked out on what is a valid value — the question that should precede any comparison between units.
The core question is not whether deviations occur — they always do — but who sees them before the figure ends up in a report. In many organizations, the answer is: no one, until an external party or an auditor notices a figure that doesn't align with last year's. By then, the question is already being asked too late.
A data point without a flagged deviation has no way of making itself suspicious. A figure that is three times higher than last year's does not automatically stand out if no range has been established within which a value is plausible. How you determine that range — a fixed percentage, historical spread, a threshold per unit — is worked out on how do you set up a flagged deviation. The question is not complicated, but it does need to be asked, per data point, before the data point is filled in.
A flagged deviation catches the extreme case: the figure that is clearly wrong. But most definitional differences between units are more subtle than that. A site that does count temporary staff does not produce an absurd figure — it produces a figure that looks perfectly normal, and precisely for that reason goes unnoticed.
That is why each data point needs more than one check: a range within which the value must fall, a fixed unit, a source requirement specifying which document type counts as substantiation, and a description of what is and isn't included in the count. Which combination of checks is needed differs by data point and by organization — an R&D expenditure calls for different safeguards than an emission factor. An overview of which checks belong to which type of data point is on which checks belong to a data point. Without that combination, false precision arises: a figure with two decimal places that is built up from five definitions that don't align. Where that false precision comes from and how to recognize it is covered on how do you prevent false precision.
A definition fixed on paper is not automatically a definition that gets applied. Someone has to answer the question when a unit raises a borderline case: does this form of collaboration count as an FTE or not, does this supplier fall under scope 3 or not. Without a designated owner, that question falls to whoever happens to be closest to the form, and the definition shifts again, silently, per unit.
The Data Readiness Scan records, per data point, what the valid value is, which flagged deviation applies, which checks belong to that specific data point, and who owns the definition. It is not a reporting tool or a questionnaire — it is the register that records what lies beneath the report, so that a difference between units becomes visible before the figure is added up.
Systems exist that can perform these checks. But a system running on top of five different, never-established definitions performs those checks based on rules no one has agreed on. The result is a tidy interface containing unreliable figures. Why the order — definition first, then the tool — matters is covered on buy a tool first or set up the process first. And which requirements a tool actually needs to meet does not follow from a vendor list but from your own process — see which functional requirements follow from your own process.
The Data Readiness Scan is under construction. Anyone already struggling with definitions that differ per unit can sign up for the waiting list and will be kept informed as soon as the instrument becomes available.
Once it is established what a valid value is, who guards the definition, and which check belongs to which data point, it also becomes visible which part of that work is repetition: checking the same source documents against the same rule, testing the same range with every new entry. That is work that, once made explicit, can be calculated. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI — not as a replacement for the owner who decides on the definition, but as a way to see where control and repetition can be distinguished from one another.
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.