An organization with multiple business units often counts the same sustainability data multiple times, without anyone noticing. The energy consumption of a location appears in an Excel file from the facility manager, in a reporting tool of the business unit, and in an aggregation table of the group. Three places, three possibly different figures, and no one who can say with certainty which one is correct.
This is not an exception. It is the normal state of sustainability data in an organization that has grown per business unit, where each part has built up its own systems, definitions and spreadsheets before reporting became a shared topic.
A data point register records, per data point: what it is, where it comes from, who the owner is and which quality rules apply to it. At an organization with multiple business units, this means you don't just record that a data point "energy consumption" exists, but also where that data point is recorded per business unit, in which system, by whom, and with which definition.
Once that is laid side by side, it becomes visible whether business units are measuring the same thing. It often turns out that one records consumption in kWh and another in a converted CO2 value, or that the scope of "energy consumption" at one unit only covers electricity while at another it also covers gas. The data point has the same name, but is not comparable in substance. You will not find that difference by looking at a report. You find it by laying the source, the definition and the owner side by side per unit.
The register does not fill itself. Someone must ask each business unit which data points are recorded, in which system, and on the basis of which source. That is inventory work: checking with the owner of each system, tracing the origin of each figure back to the original record, and recording what you find, even if that is unclear or inconsistent.
The way you structure that inventory determines whether overlap becomes visible or stays hidden. An approach per business unit, done separately, produces five registers that cannot be compared. An approach per data point, cutting across all units, produces the overview you need. How you set that up is described in how you draw up a data point register with multiple business units. It is about a structure that actually reveals duplication rather than a structure that itself keeps the duplication in place.
A data point register is not complete as soon as there is a list of data points. It is complete once every data point has a source that can be traced, an owner who takes responsibility, and a recorded definition that can be compared with other business units. Without that, you can see an overlap, but you cannot determine whether that overlap is a problem or a deliberate choice.
The question of how many of your data points actually meet that condition is in practice often smaller than hoped. Some data points have no identifiable source, only a figure that has been carried over from the previous report for years. How you map that number is covered in how many of your data points have an identifiable source. And in case you come across a data point for which simply no source can be found, even after asking around, a separate approach is described in what you do with a data point without a source at multiple business units.
The moment at which the register is "finished" is not a fixed point in time but a status per data point. Some data points are quickly in order, others require several rounds of asking around and verifying. What that means for your planning is covered in when a register is finished at multiple business units.
Once you see that three business units are recording the same data point, the next question arises: is that a duplication you can clean up, or are they three data points that happen to have the same name but a different scope? That distinction cannot always be made immediately, and making that distinction is central to recognizing a duplicate data point at multiple business units, which is further elaborated on in how you recognize a duplicate data point at multiple business units. This is work that revolves around precision: laying the definition, the scope and the calculation rule of each instance side by side before you conclude that it concerns the same data point.
Mapping data points, sources and ownership across multiple business units is recurring work: new reporting periods, new regulations and organizational changes call for repeating the same inquiry. Part of that work, such as comparing definitions side by side or tracing a source in a system, is repetitive enough to examine whether AI can take over part of it. FTE TO AI calculates per task which part of the work qualifies for that, with the work scan as a starting point to look into this for your situation.
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.