Eine Zahl in einem Nachhaltigkeitsbericht hat fast immer eine Reise hinter sich. Sie beginnt als Zeile in einer Energierechnung, als Zählerstand in einem Produktionssystem, als Eingabefeld in einem HR-Tool. Bis die Zahl im Bericht steht, ist sie gezählt, umgerechnet, zusammengeführt und manchmal korrigiert worden. Diese Zwischenschritte sind im Endergebnis selten sichtbar. Wer nur auf den Bericht schaut, sieht eine Zahl. Wer auf den Weg dazwischen schaut, sieht eine Reihe von Entscheidungen.
Zwischen Quelle und Bericht liegt in der Regel eine feste Abfolge von Bearbeitungen, auch wenn niemand sie je aufgeschrieben hat.
Zunächst werden Daten erfasst: aus einem System exportiert, aus einer Rechnung abgeschrieben, aus einer Tabelle kopiert. Danach werden sie normalisiert: Liter werden zu Kubikmetern, Kilowattstunden werden zu Gigajoule, lokale Währung wird zu einer festen Rechnungseinheit. Anschließend werden sie einer Kategorie oder einem Scope zugeordnet, was eine Entscheidung ist und kein Automatismus. Dann folgt die Aggregation: Zahlen aus Standorten, Monaten oder Abteilungen werden zu einer Jahressumme zusammengeführt. Unterwegs erfolgen Korrekturen, wegen Doppelzählungen, wegen fehlender Monate, wegen einer fehlerhaften Einheit, die jemand vor einem Jahr bemerkt und manuell korrigiert hat.
Jeder Schritt ist eine Stelle, an der eine Annahme getroffen wird. Ein Emissionsfaktor wird gewählt. Eine Schätzung ersetzt eine fehlende Messung. Eine Rundung wird angewendet. Für sich genommen ist keines davon ein Problem. Das Problem entsteht, wenn niemand mehr weiß, welche Annahme getroffen wurde, von wem, und warum.
Eine Berichtszahl, die nicht auf ihre Quelle zurückgeführt werden kann, ist eine behauptete Zahl. Sobald ein Controller, Wirtschaftsprüfer oder eine Aufsichtsbehörde fragt, wie eine Zahl zustande gekommen ist, muss die Antwort mehr sein als „das steht im System“. Die Antwort muss den Weg aufzeigen können: diese Quelle, diese Umrechnung, diese Aggregation, diese Korrektur.
Diesen Weg zu dokumentieren hat drei unmittelbare Folgen. Erstens wird die Fehlersuche zur Sache von Minuten statt Tagen, weil klar ist, wo eine Umrechnung angewendet wurde und wo nicht. Zweitens wird eine Übergabe möglich: Wenn die Person, die die Tabelle verwaltet, das Unternehmen verlässt, geht das Wissen über die Bearbeitungen nicht mit ihr mit. Drittens entsteht eine Grundlage für die Prüfung, weil eine externe Partei die Schritte nachvollziehen kann, ohne sie erst rekonstruieren zu müssen.
Ohne diese Dokumentation ist jeder Berichtszyklus eine Wiederholung von Detektivarbeit. Jemand ruft den vorherigen Verantwortlichen an, sucht in alten E-Mails, rät nach dem Grund für eine Rundung. Diese Arbeit ist im Bericht selbst unsichtbar, bestimmt aber, wie viel Vertrauen dieser Bericht verdient.
Nicht jede Bearbeitung erfordert dieselbe Herangehensweise. Aggregation, bei der Zahlen aus mehreren Quellen zu einer Summe zusammengeführt werden, erfordert eine andere Dokumentation als Normalisierung, bei der Einheiten und Definitionen vereinheitlicht werden. Wer wissen möchte, wie Aggregation genau zu dokumentieren ist, findet das in einer Erläuterung zur Dokumentation von Aggregationsschritten, und wer sich fragt, wie mit Normalisierung umzugehen ist, liest das in einer Beschreibung der Dokumentation von Normalisierung. Beide sind Teil derselben Kette, aber die Fragen, die sie aufwerfen, sind unterschiedlich: Aggregation wirft Fragen zur Vollständigkeit auf, Normalisierung zur Konsistenz.
Die Situation ändert sich auch, wenn die Quelle selbst kein System ist, sondern eine Tabelle. Dann gibt es keinen automatischen Export, kein Systemprotokoll, keine feste Struktur, und die Dokumentation muss anders aufgebaut werden. Wer mit dieser Situation zu tun hat, findet Anhaltspunkte in einer Erläuterung zum Source-to-Report-Mapping bei einer Tabelle als Quelle und in einem Überblick über die Bearbeitungen zwischen Quelle und Bericht speziell bei Tabellenquellen. Für wen kein Budget für ein Tool vorhanden ist und die Lineage mit den bereits vorhandenen Mitteln aufgebaut werden muss, gibt es eine Arbeitsweise, um Lineage ohne spezialisierte Software zu erstellen.
Die Dokumentation von Bearbeitungen wird oft mit einem Logbuch verwechselt: einer Liste, wer was wann geändert hat. Das ist ein Teil der Geschichte, aber nicht das Ganze. Ein Audit Trail, der nur Änderungen erfasst, erklärt nicht, warum eine Entscheidung getroffen wurde oder welche Regel angewendet wurde. Der Unterschied zwischen einem Logbuch und einer echten Verantwortungsstruktur wird ausgeführt in einer Darlegung darüber, warum ein Audit Trail mehr sein muss als ein Logbuch.
Der Data Readiness Scan bildet diesen Weg ab: welche Quelle welchen Datenpunkt speist, welche Bearbeitungen dazwischen liegen, wer Eigentümer jedes Schritts ist und welche Qualitätsregel dazugehört. Das ist kein Bericht und kein Fragebogen, sondern die zugrunde liegende Struktur, die beides erst zuverlässig macht.
Sobald die Bearbeitungen zwischen Quelle und Bericht beschrieben sind, wird sichtbar, welche Schritte feste manuelle Arbeit sind: das Abschreiben einer Rechnung, das Anwenden eines festen Umrechnungsfaktors, das Zusammenführen von Monatszahlen nach einer festen Regel. Das ist genau die Art von Arbeit, für die berechnet werden kann, welcher Teil davon von KI übernommen werden kann, ohne dass die Dokumentation von Quelle zu Bericht ihre Funktion verliert. FTE TO AI berechnet pro Aufgabe, welcher Anteil davon übertragbar ist, auf Basis des Werkscans, der diesen Unterschied pro Aufgabe sichtbar macht.
Der Data Readiness Scan befindet sich in der Entwicklung. Wer die Bearbeitungen zwischen Quelle und Bericht dokumentieren lassen möchte, sobald der Scan verfügbar ist, kann sich für die Warteliste anmelden.
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.