A bootcamp sounds like a training, a few days of an intensive program after which everyone can carry on. That is not what is meant here. It concerns a structured process in which an organization maps its sustainability data: which data points exist, where they come from, who is responsible for them and which quality rules apply to them. Not a training on reporting obligations, not a workshop on the standard. Work on the data itself.
The result is a data point register: an overview of every data point the organization needs, with for each data point the origin traced from source system to reported figure, a designated owner and the rules the data must satisfy to be called reliable. That is not a report and not a dashboard. It is the underlying layer that determines whether a report, whatever report it may be, stands on something solid. Where does a data point already exist is often the first question this process answers, and that question regularly turns out to be harder than expected: the same data sometimes appears in three places, in three definitions.
It is not the implementation of a tool. Software that generates reports on top of an unorganized process produces neater reports about the same unreliable figures. The data bootcamp precedes that step: first establishing what a data point is, where it comes from and who is accountable for it, only then thinking about systems to support that process. Nor is it a guarantee of assurance-readiness. It puts in place the structure that makes assurance possible, but whether an accountant approves a figure depends on more than a register. Anyone wishing to go deeper into this can find, on how do you make ESG data auditable for assurance, exactly where that boundary lies.
A commonly heard assumption is that spreadsheets are the source of unreliable data and that a system is the solution. That is a misconception. The problem is rarely the medium, it is the absence of ownership and traceability. A spreadsheet with a clear owner, a documented origin and a quality rule is more reliable than an expensive system without those three things. Why spreadsheets are not the problem elaborates on this further. The data bootcamp therefore does not focus on replacing tools, but on documenting what already exists, wherever it may reside.
The time investment depends on the number of data points, the number of source systems and the degree to which ownership has already been assigned. An organization with a few central systems and a small number of material data points goes through the process differently than an organization with dozens of subsidiaries, each with their own spreadsheets and their own definitions. No fixed duration can be given without that context, and anyone expecting a concrete figure will not be handed a number pulled out of thin air here.
Once every data point can be traced to its source and has an owner, the conversation shifts. Questions such as "where does this figure come from" and "who can explain this" then have a direct answer, instead of a search through email exchanges and old files. That affects not only this year's reporting, but also the handover to a successor, a new controller or an external team. What changes once the lineage is in place describes that shift, and who reads your data point register once you are no longer there shows why that transferability often weighs more heavily than the reporting of the current financial year.
A common mistake is wanting to make the register complete in one go for every data point a standard might ever ask for. That leads to a project that never gets finished. The data bootcamp starts with the data points the organization actually needs, given its materiality and its sector, and expands from there. Which data points do you actually need is the question that stands at the start of every process, before anyone begins building a register.
The tool that supports this process is under development. Anyone who wants to start mapping data points, origin and ownership now can sign up for the waiting list; nothing is delivered that does not yet exist, but the request is noted for the moment the instrument becomes available.
A data point register tells you where the data comes from and who stands behind it. It does not by itself tell you how much of the surrounding work, the retyping, the checking, the merging of sources, will still have to remain human work going forward. Anyone wanting to know that can have FTE TO AI calculate the work scan: it maps, per task, what portion of it can be taken over by AI, so that it becomes clear where time is freed up and where human oversight remains necessary.
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.