When sustainability data is spread across systems, spreadsheets and loose emails, the first impulse is often: surely there's a tool that solves this. That impulse is understandable. A tool feels like progress, while setting up a process feels slow and administrative. Yet the order in which you take these two steps largely determines whether purchasing a tool delivers something or just costs money.
A tool processes, displays and reports data. It does not determine which data exists, where it comes from, who is responsible for it and which quality rules apply to it. Those questions precede the process. If nobody has answered them before a tool is purchased, the tool has to improvise the answer, or worse, assume the answer is already there.
When a tool is placed on top of an unorganized process, a specific pattern emerges. The tool receives data that nobody can precisely trace back to which system it came from, who adjusted the figures, or which definition was used. The tool itself functions fine; the problem lies in what goes into it. The result is a report that looks polished, while the underlying figures are just as unreliable as before the purchase. Anyone wanting to know how costly that becomes will find an elaboration in what a tool on top of an unorganized process costs and in what the wrong order between tool and process costs. Both describe where the costs come from: not from the license, but from having to figure out again things that were already figured out once, only never recorded.
Setting up the process means: recording which data points are needed, where each data point originates, through which systems and spreadsheets it flows into the report, who owns each data point and which rule determines whether a value is credible. That work takes time, but it delivers something independent of whichever tool you ultimately choose. A data point register with lineage and ownership remains usable, even if you switch software vendors. A tool without that register has to figure out, at every switch, what the previous tool apparently had already solved, when in reality it was never recorded.
This is also why functional requirements for a tool do not come from a brochure, but from your own process. Only once it is clear which data points you have, where they come from and who decides on them, does it become visible which requirements a tool actually needs to fulfill. More on this can be found in which functional requirements come from your own process, and the cost side of that in what it costs when functional requirements don't come from your process.
Setting up the process does not prevent you from choosing the wrong tool, but it does prevent you from choosing a tool based on a demo instead of based on what your data actually requires. Selecting a tool without that foundation means choosing on gut feeling, on sales pitch, on what competitors use. How to do this properly is worked out in how to choose a tool without regret afterwards, with the flip side in what the wrong order between tool and process costs in regret.
An organized process guarantees neither a perfect report nor a trouble-free audit. It does deliver something concrete: a register in which every data point can be traced back to its source, an identifiable owner per data point and quality rules agreed upon in advance rather than invented afterwards. That is the foundation on which a tool can do meaningful work, instead of a foundation the tool itself would have had to lay.
The scan that elaborates on this exists as a data point register with source-to-report lineage per data point, ownership and quality rules: the data underlying the report, not the report itself. This tool is under construction. Anyone who wants to get started with this now can sign up for the waiting list; nothing is being sold that doesn't exist yet.
Once the process is in place and it is clear which data points come from where and who is responsible for them, a follow-up question arises: how much of that work, such as retyping sources, checking quality rules or compiling lineage, can be handed over to AI, and how much still requires a human to assess and decide. FTE TO AI calculates this per task with a work scan, which precisely indicates which part of the work can be taken over by AI and which part cannot. For sustainability data, that is a logical next step after setting up the process: first know what needs to happen, only then decide who or what carries it out.
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.