Lineage ist nichts anderes als der Weg, den eine Zahl zurücklegt: von der Stelle, an der sie entsteht, bis zur Stelle, an der sie im Bericht steht. Dieser Weg existiert auch ohne Tool. Jedes Mal, wenn jemand eine Zahl aus einer Tabelle übernimmt, mit einer anderen Zahl addiert, durch eine Anzahl Vollzeitäquivalente teilt oder in eine andere Einheit umrechnet, legt diese Person ein Stück Lineage zurück — ob das nun festgehalten wird oder nicht. Die Frage ist nicht, ob diese Lineage existiert, sondern ob jemand sie nacherzählen kann, ohne den ursprünglichen Ersteller hinzuziehen zu müssen.
Ein Datenpunkt in einem Nachhaltigkeitsbericht hat fast immer eine Reihe von Schritten hinter sich. Zuerst ist da die Quelle: eine Tabelle mit Energieverbrauch je Standort, ein Export aus einem HR-System, eine Rechnung eines Lieferanten. Danach folgt eine Bearbeitung: addieren, mitteln, in CO2-Äquivalent umrechnen, mit einem Emissionsfaktor verknüpfen. Häufig folgt eine Aggregation: Zahlen je Standort werden zu Zahlen je Land, Zahlen je Monat werden zu Zahlen je Jahr. Schließlich landet die Zahl im Bericht, oft über eine letzte manuelle Abschreib- oder Einfügeebene.
Um zu verstehen, was Source-to-Report-Mapping bedeutet, wenn die Quelle eine Tabelle ist, hilft es, diese Schritte nicht als ein Ganzes zu betrachten, sondern als eine Reihe einzelner Handlungen, jede mit einem eigenen Fehlerrisiko. Wer nur Anfang und Ende der Reise kennt, kann nicht erkennen, wo in der Mitte etwas schiefgelaufen ist.
Ohne Erfassung existiert Lineage nur im Kopf desjenigen, der die Tabelle erstellt hat. Sobald diese Person Urlaub macht, die Funktion wechselt oder die Organisation verlässt, verschwindet das Wissen darüber, was zwischen Quelle und Bericht geschehen ist. Ein Controller, der eine Zahl verifizieren möchte, muss dann raten oder nachfragen. Eine externe Partei, die den Bericht prüft, muss sich auf Vertrauen statt auf Dokumentation verlassen.
Die Bearbeitungen zwischen Quelle und Bericht sind oft unsichtbar geworden, weil sie in Zellformeln, Makros oder im Gedächtnis eines Mitarbeiters verborgen sind. Um herauszufinden, welche Bearbeitungen zwischen Quelle und Bericht liegen, wenn die Quelle eine Tabelle ist, ist es notwendig, jede Formel, jeden manuellen Schritt und jede Verknüpfung einzeln zu benennen — nicht als Black Box, sondern als Reihe einzelner Handlungen.
Dasselbe gilt für die zwei Bearbeitungen, die in Nachhaltigkeitsdaten am häufigsten vorkommen: Aggregation und Normalisierung. Aggregation — das Zusammenrechnen von Zahlen aus mehreren Quellen zu einer Gesamtsumme — verlangt die Erfassung, welche Quellen einbezogen wurden und welche nicht, und warum. Wer wissen möchte, wie Aggregation festgehalten wird, wenn die Quelle eine Tabelle ist, stößt auf die Notwendigkeit, je Summe zu dokumentieren, welche Zellen einbezogen wurden. Normalisierung — das Umrechnen von Rohzahlen in eine vergleichbare Einheit — kennt ein ähnliches Problem: welcher Umrechnungsfaktor wurde verwendet, aus welcher Quelle stammt dieser Faktor, und ist dieser Faktor das ganze Jahr gleich geblieben. Für wen dies festhalten möchte, ist ein Ansatz beschrieben in wie Normalisierung festgehalten wird, wenn die Quelle eine Tabelle ist.
Ein häufiger Irrtum ist zu denken, dass ein Änderungslogbuch ausreichende Lineage liefert. Ein Logbuch zeigt, wann eine Zelle angepasst wurde und von wem, aber nicht warum diese Anpassung nötig war oder welche Regel dahintersteckte. Ein Audit Trail, der nur registriert, was geschehen ist, ohne die zugrunde liegende Logik, lässt dieselben Fragen unbeantwortet wie kein Logbuch. Warum ein Audit Trail mehr sein muss als ein Logbuch, wenn die Quelle eine Tabelle ist, liegt im Unterschied zwischen der Registrierung einer Handlung und der Erfassung des Grundes dahinter.
Ohne Tool bedeutet dies in der Praxis: für jeden Datenpunkt ein festes Dokument oder eine feste Sektion, in der steht, welche Quelle verwendet wurde, welche Bearbeitungen in welcher Reihenfolge angewendet wurden, wer die Bearbeitung durchgeführt hat und auf Basis welcher Regel. Das kann in einem separaten Register erfolgen, in Kommentarfeldern der Tabelle selbst, oder in einer separaten Übersicht, die neben dem Berichterstattungsprozess geführt wird. Es ist mehr Arbeit, als nichts festzuhalten, und weniger Arbeit, als ein Tool über einen Prozess einzurichten, der diese Schritte noch nicht kennt. Genau das ist der Grund, diese Schritte zuerst zu durchlaufen: ein Tool, das auf einen unorganisierten Prozess gesetzt wird, liefert eine ordentlichere Ausgabe über dieselben nicht nachvollziehbaren Zahlen. Für die Details dieses Ansatzes, einschließlich des Formats, in dem Lineage je Datenpunkt geführt werden kann, gibt es eine Ausarbeitung von wie Lineage ohne Tool aufgebaut wird, wenn die Quelle eine Tabelle ist.
Das manuelle Festhalten jedes Schritts zwischen Quelle und Bericht ist bei einer begrenzten Anzahl von Datenpunkten und Tabellen machbar. Bei einer größeren Anzahl von Standorten, Quellen oder Berichtszyklen wird das Verfolgen jeder Bearbeitung zu einer Aufgabe, die viel Zeit erfordert und anfällig für dieselben Fehler ist, die die Lineage eigentlich aufdecken soll. In dem Moment, in dem diese Grenze in Sicht kommt, ist es nützlich zu wissen, welcher Teil dieser erfassenden Arbeit sich nach einer festen Regel wiederholen lässt und somit von KI übernommen werden kann, und welcher Teil weiterhin Beurteilung erfordert. Der Werkscan von FTE TO AI rechnet das je Aufgabe durch, sodass deutlich wird, wo Handarbeit noch passt und wo Wiederholung nach etwas anderem verlangt.
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.