Before a figure ends up in a report, it already has a history. It comes from an energy bill, an HR system, an Excel file that someone updates every quarter, or an estimate made three years ago that has never been revised since. The question "where does this data point already exist" seems simple, but at most organizations the answer is not recorded anywhere. It sits in people's heads, in last year's email exchange, or nowhere at all.
A data point register is the place where that answer actually is recorded. Not as a report, but as an administration: for each data point, recording where the value comes from, who is responsible for it, and which rules the value must meet before you use it.
A register contains a fixed set of fields for each data point. The name and definition of the data point, so that two people do not mean something different by the same term. The source systems or documents the value comes from. The owner: the person who can explain where the figure comes from and who is the point of contact if it turns out to be wrong. The operations that take place between source and reporting, from unit conversion to aggregation across locations. And the quality rules the value must meet, such as an expected range or a check against a previous year.
This is not a reporting document. It is the layer beneath it: the place where you can look up where a number comes from, without having to call anyone.
A register does not fill itself automatically. It starts with the list of data points you need, and for each one the question: does this already exist somewhere, and where exactly. For most data points, the answer is not a single source but a series of steps: an export from a system, an operation in a spreadsheet, a manual addition, and then the final value. Every step in that sequence belongs in the register, not just the last one.
Two questions belong with this and should not be skipped. First: who is the owner of this data point, not as a formality but as someone who can account for the value. Second: what happens with a data point whose source cannot be traced. That happens more often than expected, and what you do with a data point without a source is a question that should not be dismissed as too difficult to answer.
Building this register is a separate exercise with its own order: first identify the data points, then trace the sources, then assign the owners, then formulate the rules. How you set up a data point register describes that order step by step.
Having a data point recorded in the register is not the same as having a data point that is correct. Being correct means that the source is traceable, that the operations between source and reported figure are known, and that there is a rule against which the outcome can be tested. Without these three, a figure is an assumption with a number attached to it.
The operations are the part that is most often missing. A data point rarely goes directly from source to report; there is usually a conversion, an aggregation, or a correction in between. Which operations sit between source and report is therefore a separate question alongside the question of where the source itself sits, and together these two questions form what is known as source-to-report mapping: the complete route from raw source to reported figure, mapped out.
A second problem that only becomes visible once you fill in the register is duplication: the same data point supplied through two routes, with two slightly different values. How you recognize a duplicate data point is then not a theoretical question but a practical check you run on the register before marking it as reliable.
And because a register is never complete in one go, there is a separate question for the moment at which you can stop searching: when a register is complete describes what that depends on, rather than naming a fixed number of data points or a deadline.
A data point register tells you where a data point comes from and who is responsible for it. It does not tell you how much time it takes to collect that data again every year, or which part of that collection work remains manual and which part can be taken over. Once the register is in place and you know which steps repeat themselves, that question comes up automatically. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, connecting precisely to the point where the register stops: not where the data sits, but how much work it takes to gather it again each time.
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.