In most organizations with multiple business units, the same data point exists multiple times. Scope 2 emissions are found in an energy bill at one location, in an Excel export from the facility manager at another, and nowhere at a third — there, it is estimated. That is not the mistake of one department. It is the result of years in which no one centrally defined the data point, let alone its source.
The question "what do you do with this" assumes there is one answer that fits everywhere. That is not the case. The approach depends on what is already present per business unit, and that differs.
Before deciding anything about a data point without a source, you set out side by side what each business unit actually has. For some units, a source exists that no one has written down — a system, a supplier, a local administration. For others, that source does not exist, and the figure is currently filled in based on an estimate or a colleague who "roughly knows". These two situations call for something different. Where does a data point already exist is the question you answer unit by unit, before adding anything to or changing anything in the register.
Only once that overview exists do you see where the problem actually lies: not with the data point as a concept, but with the spread of sources that are subject to it.
A data point register does not contain one line per data point but as many lines as there are sources. For a data point that occurs at three business units, there are three rows: each with its own source, its own owner and its own quality rule. That may seem cumbersome, but it prevents something worse — merging figures with different origins into one number that no one can trace back anymore.
Each row contains at minimum: the definition of the data point as it applies to this unit, the source system or document the figure comes from, who is responsible for supplying and checking it, and the rule used to test whether the value is plausible — a range, a comparison with the previous year, a check on the unit of measure. Without that last rule, you only notice an error when someone happens to look.
A complication that often surfaces during this process: unit A and unit B call it "the same" data point, but measure something different. One includes lease cars in scope 1, the other does not. That is not a source problem but a definition problem, and it must be resolved before a source is linked to it. How you recognize that kind of difference is described in how do you recognize a duplicate data point at multiple business units. Only once the definition is the same for all units does it make sense to start linking sources — otherwise you are registering three different things under one name.
If, after this investigation, it turns out a business unit truly has no source for a data point, there are two routes. The first: a system or process exists from which the figure could come, but no one has ever designated it as the source. In that case you designate that source and record who manages it. The second: there is truly nothing, and the figure is currently estimated or taken over from another unit. In that case you register that explicitly as an estimate, with the underlying assumption, instead of letting it pass as a measured value. Both routes belong in the register — an estimate that is not labeled as an estimate is a risk that only shows up during an audit.
Before spending time finding a source for every missing data point, it is worth determining whether that data point is relevant for that business unit. A small office with five employees may not need a material scope 3 data point that is relevant for a production site. Which data points do you actually need helps make that distinction, so you don't go looking for a source for something that turns out not to be needed.
There is a tendency to keep searching for sources until everything is perfectly covered. That is not the criterion. The register is complete when, for every relevant data point, per business unit, it is established whether a source exists, who the owner is and which check is applied to it — not when every number is traceable with one hundred percent certainty. When is a register complete at multiple business units describes that endpoint concretely, and how many of your data points have a source is the question you use to measure progress in the meantime.
This is work that happens unit by unit and not all at once for the entire organization. How much time it takes depends on the number of business units, the number of data points and how many of those already have a source. Part of this work — querying owners, bringing sources together, filling in the register — is the kind of task that can be structured and partly accelerated. The work scan from FTE TO AI calculates per task which part of it can be taken over by AI, so that before you start you know which part remains manual and which part does not.
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.