The common order is: select a tool, configure the tool, and then hope the process adapts to it. In practice that doesn't work, because a tool doesn't bring a process with it. A tool brings fields, integrations, dashboards — but not the question of who in your organization is responsible for the energy consumption of building three, or whether the facility manager who supplies that figure knows it ends up in the scope 2 report.
The correct order is the reverse: first describe the process, then choose a tool based on what that process needs. That sounds like a detour, but it's the shortest route, because every functional requirement you place on a tool must come from somewhere within your own data organization. Without that starting point, you select based on features a vendor considers important, not features that solve your bottleneck.
The cost of the wrong order isn't immediately visible, because a tool that doesn't fit works fine at first — for the part of the process that happens to match what the tool expects. The rest gets built around it manually: an Excel attachment here, an email exchange there, an employee who knows exactly which step falls just outside the system. That works, until that employee leaves or the volume of data grows.
What it costs depends on how many data points run outside the tool and how often those need to be manually re-collected per reporting cycle. With a small number of points, that's an acceptable detour. With a growing number — more locations, more scope 3 categories, more legislation joining in — the detour becomes the main route, and you structurally pay for the mismatch between tool and process. That's another way of saying what is also stated on this page: a tool placed on top of an unorganized process produces neater reports about the same unreliable figures.
A functional requirement is only a requirement if it originates from something. "The tool must be able to show lineage" is not a requirement until you know that your controller has to manually trace where a figure comes from three times a year. "The tool must be able to record ownership" is not a requirement until you've seen that a data point without an owner ends up on nobody's action list.
This is precisely why the data point register, the source-to-report lineage per data point, and the ownership assignment must exist first, independent of whichever tool you ultimately choose. Once those three things are on paper — which data point, where it comes from, who signs off on it — you have a list of requirements that doesn't come from a vendor but from your own organization. You use that list to compare tools, not to blindly pick one. How to approach that comparison without regret is described on this page about tool selection.
Where the data resides differs greatly by sector, and that also determines which functional requirements are relevant. In a construction company, a large part of the sustainability data sits with subcontractors and on the construction site itself, as described on this page about data sources in construction; there, a requirement around multiple external sources per project is likely more important than in other sectors. In the installation industry, data is more often spread across service tickets and material registrations at project level, as described on this page about the installation industry; there, what matters most is whether a tool can consolidate separate entry points without someone doing that manually.
The general question — set up the process first or buy a tool first — is further explored on this page, and the core question of this page, which requirements exactly arise from your own process, is summarized on this page. Both pages start from the same point: the order determines whether a requirement is a requirement, or a guess.
The Data Readiness Scan records the data point register, the lineage, and the ownership before any discussion of a tool takes place. That is not a reporting tool and not a questionnaire solution — it is the step that determines what a tool actually needs to be capable of for your organization. Without that step you buy features; with that step you buy a solution to a problem you can point to.
The scan is under development. Anyone who wants their process mapped this way before making a tool choice can sign up for the waiting list and will be informed as soon as the scan becomes available.
Once the data point register is in place and it's clear which data point comes from which source and who is responsible for it, a second, natural question arises: which part of the surrounding work — collecting, checking, and transferring figures — is still done by people, and which part can a system take over without reliability decreasing. That question is answered by the FTE TO AI work scan, which calculates per task which part of the work can be taken over by AI. That is a different scan from the Data Readiness Scan, and a logical follow-up to it: first know what the data is and where it comes from, only then look at which part of the manual work around it can become redundant.
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.