The figures add up on paper. There's a neat table, with a total per component and a sum across the group. But anyone who asks further — where does this number come from, who supplied it, which definition was used — gets three different answers from three different people. One location counts scope 2 differently from another. The spreadsheet used last year can no longer be found. No one is certain whether this number was built the way the assurance partner will want to see it. That's not a calculation error, that's a foundation that was never laid.
The core is the Data Readiness Scan with a data point register as its backbone. That register places side by side what is needed for the chosen topics and what is already present in the organisation — not an estimate, but a list that follows from the material topics that have been identified.
Around that register sits the source-to-report mapper: a fillable lineage tool following a fixed input-process-output structure. For each data point it is recorded where it comes from, which processing steps it undergoes before it ends up in the report, and who is responsible for what via a RACI. This comes with quality rules — valid values, signal deviations — that make visible when a figure falls out of line before it disappears into the consolidation.
From that designed process follows a generator for functional requirements. That is the reversal that is often missing in the process: not buying a tool first and bending the process to fit it, but first laying down the process and only then looking at which requirements follow from it for any software.
Anyone who would rather work with guidance can follow the three-day data bootcamp — usually with CO2 as the first topic. That is a route 2/3 product from the partner. The underlying design template is also included in the tool, so that anyone who prefers to steer it themselves can go through the same framework independently.
Everything the register and the mapper produce can be traced back to what has been entered: which source, which processing step, which owner, which rule. Nothing is estimated on top and nothing is rounded off into a performance figure. What comes out is a structure — not a judgement on how good or bad the data is, but a precise indication of where the foundations are missing and where they are already in place. Exactly how these steps fit together, from topic selection to remeasurement, is set out on How it works; what is concretely on the table after each step is set out on Outcomes.
Choosing topics. Material topics are selected, if necessary as a starting point from esgia.
Building the register. The register generator lists the data points that belong to those topics.
Filling in lineage and RACI. For each data point, source, processing steps, ownership and quality rules are recorded.
Readiness report and remeasurement. An indication of sequence and lead time per topic follows, and the whole is intended to be measured again periodically — data quality is not a snapshot.
It is not a reporting tool. The report itself, under VSME or CSRD, remains the domain of esgia; here nothing is reported, here the foundation for it is laid.
It is not a questionnaire tool. Anyone who needs to answer a questionnaire from a client or chain partner should turn to supplia or esgreply.
It is not a proven track record. There are no completed projects to point to — that fits a tool that is still in waitlist mode. The tool structures the process and makes visible where the loose ends are; it proves nothing about the outcome and guarantees nothing towards assurance.
Route 1 — do it yourself. The bootcamp template per topic, a register export and a controls checklist as preparation for assurance, all to be gone through independently.
Route 2 — partly guided. The partner runs the bootcamps; the tool remains the place where the register and the lineage are recorded.
Route 3 — outsource. Full setup by the partner, on FTE TO AI's own machine.
Anyone wanting more examples of what a register or lineage map looks like in practice will find background in the knowledge base.
A register and a lineage map only change something once they land in who does which task, how much time that takes and in which system it happens. That is exactly where FTE TO AI's work scan begins: not with the data, but with the work needed to get that data right.
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.