As soon as sustainability data comes from more than one business unit, the problem arises before the register even exists. Each unit has its own systems, its own spreadsheets, its own definitions of what a data point means. A register that does not put that in order will end up counting the same flow three times or missing it entirely.
A data point register is not a list of reporting topics, but a register at the level of the individual data point: the scope 2 emissions of location A, the number of FTEs with a temporary contract at unit B, the water consumption of site C. For each data point, it should be recorded exactly what it measures, in which unit, over which period and for which entity. Without these four elements, a data point cannot be traced back and is therefore not verifiable.
In addition, the register contains the source for each data point: the system, the file or the person the figure comes from. That is not always as simple as it sounds. With multiple business units, it regularly happens that a data point is filled in without anyone being able to point out where it comes from; what you do with a data point without a traceable source is therefore a question the register itself must be able to answer, not something that gets figured out afterwards.
The temptation with multiple business units is to have each unit deliver a list separately and then merge those lists afterwards. That does not work, because units rarely use the same definitions. One unit reports energy consumption per location, another per production line. One counts temporary workers as part of the workforce, the other does not. When those lists are merged without first aligning the definitions, duplications arise that are not recognizable as duplications.
The order that does work: first determine which data points genuinely matter to the organization as a whole, regardless of which unit supplies them. That is a question of necessity, not of availability — which data points you actually need is a different question from which data points already exist somewhere in a spreadsheet. Only after that is it determined, per data point, which unit, which system and which person is the source. This creates a single register with one definition per data point, in which multiple units provide input without the data point itself being duplicated.
Recognizing duplications remains necessary after that, because even with good definitions two units can unknowingly record the same underlying fact under a different name. How you notice that — how you recognize a duplicate data point between business units — is a check carried out on the register itself, not on the report that follows from it later.
A common mistake is assigning ownership at the unit level: unit A is responsible for all data from unit A. That works as long as the units remain manageable, but with multiple business units with overlapping processes — a shared purchasing department, a central vehicle fleet — that assignment quickly becomes unclear. It is better to have ownership per data point: one name who can explain where the figure comes from, what the unit is and when it was last updated. That name does not have to be the person who enters the figure, but it should be the person who knows the source.
How many of the existing data points already have such a traceable source is usually the first question that comes up once this is checked systematically. How many of your data points have a source is exactly the question that must be answered separately per business unit, because the answer can differ considerably between units.
With multiple business units, the temptation is to wait until all units have the same level of depth before considering the register complete. That is not a realistic standard. A register is complete when it is clear, for every data point, who the owner is, what the source is and which quality rule applies to it — even if that answer is, for some data points, for the time being, "unknown source, action with unit X". Incompleteness that is visible and assigned is workable; incompleteness that stays hidden behind a filled-in figure is not. What that standard exactly entails is set out under when a register is complete with multiple business units.
How much time it takes to set up such a register depends on the number of business units, the number of systems per unit and the extent to which definitions already align with each other. For an organization with a few units and manageable sources, that is considerably less work than for an organization with dozens of units on different ERP systems. An indication of where that work comes from is given at how long it takes to get a topic in order.
Setting up and maintaining a data point register across multiple business units consists of a series of recognizable tasks: requesting definitions, tracing sources, assigning owners, detecting duplications. Part of that work is repeatable enough to automate, another part requires judgment that must remain with a human. The work scan from FTE TO AI calculates, per task, which part of that work can be taken over by AI, so that it becomes clear where human hours remain necessary and where that is not the case.
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.