Ein großer Teil der Nachhaltigkeitsdaten stammt nicht aus einem System mit festen Feldern und festen Einheiten, sondern aus einer Tabellenkalkulation, die ein Mitarbeiter zusammengestellt hat. Energieverbrauch in kWh neben Liter Kraftstoff, Abfallzahlen pro Standort in unterschiedlichen Einheiten, Mitarbeiterzahlen, die zu unterschiedlichen Stichtagen erfasst wurden. Bevor eine solche Zahl in einen Bericht passt, ist sie normalisiert: umgerechnet in eine gemeinsame Einheit, korrigiert für den Zeitraum, zusammengeführt auf Organisationsebene. Diese Normalisierung findet häufig in derselben Tabellenkalkulation statt, mit einer Formel, die niemand außer dem Ersteller kennt.
Das Problem ist nicht, dass normalisiert wird. Das Problem ist, dass der Schritt unsichtbar ist. Eine Formel in einer Zelle zeigt ein Ergebnis, nicht die Annahme dahinter. Wenn jemand anderes die Datei öffnet, sieht er eine Zahl, keine Begründung.
Zwischen der Rohdaten-Tabellenkalkulation und der veröffentlichten Zahl liegen meist mehrere Schritte: Einheiten umrechnen, fehlende Werte schätzen oder überspringen, Zahlen mehrerer Standorte addieren, einen Korrekturfaktor für eine bekannte Abweichung anwenden. Jeder Schritt verändert die Zahl, und jeder Schritt ist eine Entscheidung. Welcher Umrechnungsfaktor wurde verwendet, über welchen Zeitraum wurde summiert, warum wurde ein Ausreißer berücksichtigt oder nicht. Ohne Dokumentation existieren diese Entscheidungen nur im Kopf desjenigen, der die Tabellenkalkulation erstellt hat. Eine Übersicht über welche Bearbeitungsschritte liegen zwischen Quelle und Bericht zeigt, dass Normalisierung selten ein einzelner Schritt ist, sondern eine Kette, in der jedes Glied einzeln kontrollierbar sein muss.
Die Dokumentation der Normalisierung ist nicht dasselbe wie eine Erläuterung zu schreiben, nachdem der Bericht fertig ist. Es geht um den Moment, in dem die Bearbeitung stattfindet: welche Formel, mit welchen Parametern, auf welchen Rohwert angewendet. Das ist der Unterschied zwischen einem Audit Trail und einem Logbuch. Ein Logbuch verzeichnet, dass etwas geschehen ist; ein Audit Trail macht deutlich, was geschehen ist und warum diese Bearbeitung zu diesem Zeitpunkt die richtige war. Diese Unterscheidung wird ausgearbeitet in warum ein Audit Trail mehr ist als ein Logbuch, wenn die Quelle eine Tabellenkalkulation ist. Wer die Normalisierung erst nachträglich dokumentiert, läuft Gefahr, dass sich die ursprüngliche Entscheidung nicht mehr rekonstruieren lässt, insbesondere wenn der Ersteller der Tabellenkalkulation inzwischen eine andere Funktion hat oder die Organisation verlassen hat.
Eine häufig gehörte Annahme ist, dass Lineage — die Rückverfolgung einer Zahl von der Quelle zum Bericht — ein System erfordert, das dies automatisch nachhält. Das ist nicht notwendig. Auch mit Tabellenkalkulationen als Quelle ist es möglich, pro Datenpunkt festzuhalten, welcher Quellwert verwendet wurde, welche Bearbeitung darauf angewendet wurde und wer diese Bearbeitung genehmigt hat. Das erfordert Disziplin statt Software. Wie das in der Praxis aussieht, ist beschrieben in wie erstellen Sie Lineage ohne Tool, wenn die Quelle eine Tabellenkalkulation ist. Der Kern ist eine feste Struktur: pro Datenpunkt die Quelltabelle, die angewendete Formel und ein Verweis darauf, wer diese Formel festgelegt hat. Das ist eher ein Format als ein System, und es ist anwendbar, bevor überhaupt über ein Tool nachgedacht wird.
Eine Normalisierungsregel — etwa der Umrechnungsfaktor einer Kraftstoffart in CO2-Äquivalent — ist selbst ein Datenpunkt, der einen Eigentümer benötigt. Nicht den Eigentümer der Endzahl, sondern den Eigentümer der Regel: wer entscheidet, dass dieser Faktor der richtige ist, und wer passt ihn an, wenn sich die Norm ändert. Ohne diese Zuweisung verschiebt sich die Verantwortung implizit auf denjenigen, der zufällig die Tabellenkalkulation erstellt hat. Die Frage wem gehört die Definition eines Datenpunkts behandelt genau das: Eine Definition und eine Berechnungsregel benötigen einen Eigentümer, der unabhängig davon ist, wer die Daten eingibt. Das ist einer der Bestandteile des Source-to-Report-Mapping, erläutert in was ist Source-to-Report-Mapping: nicht nur woher eine Zahl stammt, sondern auch wer für jeden Schritt dazwischen verantwortlich ist.
Es gibt Tools, die Normalisierung automatisieren und Lineage anzeigen. Diese Tools lösen nichts, wenn der zugrunde liegende Prozess nicht eingerichtet ist: Wenn niemand festgelegt hat, welche Regel für welchen Datenpunkt gilt, zeigt das Tool nur schneller eine Zahl, deren Herkunft weiterhin unklar ist. Zuerst der Prozess, dann das Werkzeug. Wer über diese Einrichtung entscheidet, ist eine Frage, die über die Normalisierung allein hinausgeht; sie wird behandelt bei wem gehört der zugrunde liegende Prozess.
Sobald klar ist, welche Normalisierungsschritte es gibt, wer sie ausführt und auf Basis welcher Regel, entsteht eine zweite Frage: welcher Teil dieser manuellen Arbeit in der Tabellenkalkulation sich an KI übertragen lässt. Der Werkscan von FTE TO AI berechnet pro Aufgabe, welcher Teil der Arbeit übernommen werden kann, und ist einsetzbar, sobald Normalisierungsschritte als eigenständige, erkennbare Aufgaben beschrieben sind, statt in einer Formel verborgen zu bleiben.
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.