There is a question that lingers beneath virtually every sustainability report, even after the report has been published: where does this figure come from. Not the conclusion, not the surrounding text, but the number itself. Who entered it, which system or spreadsheet is behind it, and whether anyone can still point to that without calling three colleagues.
At many organisations, the answer is vague. There is a report, there are figures, but the line back to the source has been lost somewhere along the way. That is not necessarily a sign of carelessness. It is a consequence of how sustainability data usually comes into being: spread across departments, systems and people who, with the best of intentions, have supplied their part, without there being one place where that whole comes together.
A data point register is not a report and not a dashboard. It is an overview: for each data point it records what it is, where it comes from, who owns it, and which rules determine whether a value is valid. For CO2 emissions, energy consumption, personnel figures or supply chain data, this makes little difference in terms of approach. The question is always the same: is there an identifiable source, and is there someone who bears responsibility for it.
What the register does not do is correct that source. If a figure comes from a spreadsheet that nobody fully understands anymore, the register documents that fact. It does not solve it. The registration makes visible where the weak links are, so that an organisation can decide what is needed next. That is a modest claim, but one that holds true.
The temptation is great to first acquire a tool that generates reports or fills in questionnaires, and only later look at the underlying data. That works the wrong way round. A tool placed on top of an unorganised process produces neater reports about the same unreliable figures. The underlying question, whether the data point can be traced to a source and an owner, then remains unanswered. Only afterwards it looks more convincing than it actually is.
That is why the scan starts with the data point register, the lineage from source to reporting point and the question of ownership, not with software placed on top of that. What data maturity is and how you measure it is essentially the same question in a different form: not whether a report exists, but whether the organisation knows where its figures come from and how solid that foundation is.
It is not the case that a scan maps all of an organisation's data points completely in one go. The first pass records what is known and, just as importantly, what is not yet known. Some sources are obvious: an energy bill, an HR system. Others are less clear-cut, such as an estimate that was made at some point and has since been maintained as a fixed value without anyone still knowing on the basis of which assumption.
Nor does the scan claim that every data point can ultimately be made assurance-proof within a fixed timeframe. How much time that takes depends on how many systems are involved, how many owners still need to be identified and how dispersed the sources are. An impression of how long it takes to get a topic in order helps to form that estimate, without this becoming a promise about a specific timeline.
And the scan does not assume that spreadsheets are the problem. Often a spreadsheet is nothing more than the place where the lack of structure becomes visible; the question why spreadsheets are not the problem explains why replacing the tool itself rarely solves the underlying issue.
In practice, CO2 is often the first topic for which this question is asked pointedly, simply because it tends to be the most dispersed and most traced figure in a report. There is a reason why CO2 is usually the first topic to start with, and that reason says something about how data points run through an organisation, from meter reading to reporting line.
The scan as described here is under construction. What exists now: a way of looking and a structure for asking questions that most organisations do not yet ask systematically. Anyone who currently needs this approach can sign up for the waiting list. That is not a waiting list for a vague future, but for an instrument that is still being completed, and we would rather state that honestly than offer something that is not yet fully in place.
Once it is clear which data points have a source and which do not, another question follows naturally: how much of the work involved in checking, maintaining and tracing those sources actually needs to be done by people, and how much a system can take over. That is a different question from the one this page answers, but a logical next step nonetheless. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, giving a picture of where people spend time on work that, once the data is in order, can largely be automated.
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.