A reporting obligation comes up, and the first reaction is to look for a tool. A dashboard, a platform, a module added to the existing software. That feels like progress: something new appears, money is being spent on it, there is a vendor to consult with.
The question that gets skipped is where the tool gets its figures from. A tool calculates, visualizes and reports, but it invents nothing. The data that goes into it comes from the same spreadsheets, the same emails to the facility manager, the same estimates that already existed. Only now that data sits behind an interface that looks organized.
Choosing a tool before you know which data you have, who is responsible for it and how reliable it is, means choosing a tool based on assumption. The vendor asks which functionality you need, and you answer based on what you think you have — not based on what actually exists in terms of data points, sources and owners. Which functional requirements come from your own process is a question that can only be answered once the process is already in place; without that foundation, the tool is chosen based on a list of requirements someone else drew up, or one that later turns out to be missing exactly what was needed.
The reverse order — first arranging the data point register, the lineage and the ownership, only then selecting a tool — costs more time at the start. There is no dashboard to point to, no progress that can be shown in a meeting. But the questions that are then put to a tool are questions based on what is actually happening in the company, not based on a list copied from a demo.
The costs of tool-first cannot be captured in a single line item, but they can be recognized.
There is the tool itself, which after a year turns out to be missing what was needed — a connection to a source system that isn't there, a reporting structure that doesn't match how the organization works, a module that does something nobody needed. There is the time of the people who had to fill the tool: if the data point register wasn't there, the tool is filled with the same loose Excel exports as before, only now within a system that suggests it is under control.
There is the false sense of certainty, which is the most costly of all. A tool with a convincing dashboard gives the feeling that the data is in order. That feeling holds up until an assurance process, an auditor or a question from the supervisory board about the origin of a figure. Then it turns out nobody can point to who supplied the source, which assumption is built into it, or whether this year's figure was calculated the same way as last year's. The tool didn't know that, because the tool never asked that question — it assumed whatever was entered.
And there is the replacement. A tool chosen without insight into the process underneath it is, after some time, traded in for another tool, in the hope that it will do better. The problem shifts, but doesn't disappear: buying a tool first or setting up the process first is exactly the choice that comes up again with every replacement, and which, without an answer on the process side, again turns out wrong in the same way.
How heavily the wrong order weighs depends on where the data originates. In a construction company, a large part of the sustainability data sits with subcontractors, on the building site and in project administrations that were not made for reporting — where the sustainability data in construction comes from determines which connections a tool actually needs. In the installation sector, the data is spread across service tickets, material registrations and maintenance contracts, and where the sustainability data in the installation sector sits shows that a generic tool built for an office-based organization quickly falls short here. A tool that doesn't know these differences cannot resolve them either — no matter how good the interface is. Anyone who still wants to choose a tool first would do well to read how to choose a tool without regretting it afterwards, though the core remains the same: a tool does not solve a process that isn't there.
The order that remains is not complicated, but it is less attractive to offer: first establish which data points exist, where they come from, who is responsible for them and which quality rules apply. That is the work the Data Readiness Scan from CSRDready.net was set up for — a data point register, source-to-report lineage per data point, ownership and quality rules, without any tool or report format attached to it yet. The tool is under construction; anyone who wants to get started with this now can sign up for the waiting list.
Once the data point register is in place, there is still a question that does not need to be put to a software vendor: how much of this work — collecting, checking and repeating the same data points — needs to remain human work, and which part can be taken over. That is what the work scan from FTE TO AI was made for: it calculates, per task, which part of the work can be taken over by AI, based on the tasks as they are actually carried out in your organization.
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.