A tool is often bought as a first step: there is pressure, there is a deadline, there is a vendor with a convincing demo. The question that is rarely asked in that moment: is there already something for this tool to sit on top of? A tool does not organise anything by itself. It displays, calculates and structures whatever you put into it. If the underlying data has not been recorded — no register of data points, no documented origin, no designated owner per figure — then you end up with a tool that neatly displays what is, in fact, still a collection of loose spreadsheets and loose assumptions.
The tool itself usually works fine. The problem lies in what goes into it. A dashboard showing energy consumption per site is only as good as the input it receives. If no one has recorded which department supplies those figures, using which source files, according to which calculation rule, then the tool fills a gap with an estimate, an incorrect link, or a figure that a colleague entered once three years ago and that has never been updated since. The tool itself does not flag this. It simply keeps calculating.
The costs of that order are impossible to capture in a single figure, and that is precisely the point: they are diffuse and spread out. Time spent again on figuring out where a figure came from, after it was already in the tool. Discussions between finance and sustainability over who supplied which number. A controller who, at the first external audit, has to admit that the origin of a key indicator cannot be reconstructed. An implementation that has to be redone, partly or fully, because the data structure was not set up for it. On this page the core question itself is worked out in more detail: which order is logical, and why exactly that one.
A tool is chosen based on functionality: can it handle the right data points, does it connect to the right reporting standard, is the reporting structure flexible enough for what is still going to change. Those requirements cannot be formulated in the abstract. They follow from what data already exists, who manages that data, and what the gaps are. Without that overview, the tool is chosen based on what the vendor shows in a demo, not on what your organisation needs. Which functional requirements actually follow from your own situation is explained on this page about functional requirements from your own process.
The reversed order — tool first, process later — leads to a second purchase, a migration, or a tool that is permanently supplemented with the spreadsheets it was supposed to replace. Anyone caught in that spiral notices that the tool does not solve the problem it was supposed to solve: unreliable, untraceable or unmanaged data. It simply moves the problem behind a nicer interface.
Organising in advance is not a bureaucratic exercise. It is a register: which data points are needed for the reporting, where do they come from, through which systems or spreadsheets do they move towards the final figure, who is responsible for their accuracy, and what quality rule applies to flag an error in time. That register exists independently of whichever tool is eventually placed on top of it. It is the foundation on which a tool functions, regardless of which vendor is chosen.
To avoid the second mistake being the same as the first, it is useful to know how a tool actually can be chosen without regret: the steps involved are set out on this page about choosing a tool without regret. For organisations in specific sectors, it is also useful to see exactly where sustainability data comes from in practice: in construction it is often scattered across project administrations and subcontractors, as described on this page about sustainability data in construction, and in the installation sector it is distributed differently again, as explained on this page about sustainability data in the installation sector.
The Data Readiness Scan builds that register before any tool is discussed: per data point the origin, the owner and the quality rule. Not a report, not a completed questionnaire, but the structure on which a report or questionnaire can later rely. The tool is under development; anyone interested can sign up for the waiting list.
Once it is clear which data points exist, where they come from and who manages them, a more precise picture also emerges of the work surrounding them: who collects, who checks, who records. That work is not equally suited to automation everywhere. The work scan from FTE TO AI calculates per task which part can actually be taken over by AI, based on what that task precisely involves and not on a general estimate about the sector.
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.