Across multiple business units, a question often arises that no one can answer precisely: which data points are actually needed, and which are collected simply because they were requested last year too. Without a register, the questionnaire keeps growing along with the fear of missing something. With a register, it becomes visible what each unit actually delivers, where that comes from, and whether the answer to the question is the same data point as at the unit next door.
A data point register is not a reporting template and not a questionnaire. It is a list of data points with, for each point: the definition, the unit, the source, the owner, and the quality rule it must meet. For an organization with multiple business units, this means that every data point can be traced back to a specific place in a specific system, held by a specific responsible person. Not 'scope 2 emissions per unit', but 'kWh consumption from invoice X, entered by Y, traceable to Z'.
The question of which data points are truly needed cannot be answered in one go. It follows from combining what already exists. An overview of where a data point already exists across multiple business units shows which part of the question is already answered by existing systems, and which part still sits loose in spreadsheets or isn't recorded anywhere. Only once that picture exists does it become clear which data points actually need to be requested and which have become redundant.
Building a register does not start with a system, but with a list of questions: which data points are currently used, by whom, and based on which source. That is an organizational exercise, not a technical one. A step-by-step approach for compiling a data point register across multiple business units describes how that inventory usually proceeds: per unit, per data point, along with the source and owner.
During that inventory, two recurring problems tend to surface. The first is the data point without a clear source: a figure that has been passed along for years, but that no one can point to the origin of anymore. An approach for a data point without an identifiable source across multiple business units addresses what to do in that case: not simply adopting the data point, but first reconstructing the source or marking the data point as unreliable until that is possible.
The second problem is the duplicate data point: two business units that, under different names and different units, deliver the same underlying figure. A way to recognize a duplicate data point across multiple business units helps make that visible, so the register does not record the same reality twice under two different labels.
A data point in the register is only complete once four things are established: the definition is unambiguous, the source is identifiable, the owner is known, and there is a quality rule that determines when a value is considered valid. If any one of those four is missing, the data point is not yet finished, no matter how many times it has already been delivered.
The same applies to the question of whether the register as a whole is finished. A register is not complete because it contains a long list of data points, but because every data point on that list is traceable and every unit knows which part of the list applies to it. A test for when a register is finished across multiple business units describes that boundary: not completeness in number, but completeness in traceability.
A useful indicator here is simply how many of the data points already have a source. A measurement of how many of your data points have a source gives an initial picture of how far the organization has actually come, independent of what this year's report or questionnaire looks like.
It is tempting to purchase software first that collects, validates, and reports data points. That order backfires when the underlying process is not yet organized: a tool placed on top of an unorganized data collection produces neater reports about figures that are still not traceable. The register — who delivers what, from which source, according to which rule — needs to be in place first. Only then does a tool have something reliable to run on.
Once the register is in place and it is clear, per data point, who delivers it, from which source and according to which rule, another question becomes relevant: which part of that delivery process still requires human work, and which part is repetitive enough to be left to a system. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, and can, based on the register, indicate per data point where manual entry, checking, or handover gives way to an automated step.
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.