Ein Logbuch sagt, dass etwas geschehen ist: eine Datei geöffnet, eine Zelle geändert, ein Export erstellt. Das ist nützlich, beantwortet aber nicht die Frage, die zählt, sobald jemand eine Zahl im Nachhaltigkeitsbericht in Frage stellt: wie genau ist diese Zahl aus der Quelle entstanden, und stimmt dieser Weg noch immer.
Ein Systemlog registriert Aktionen. Ein Audit Trail für einen Datenpunkt verantwortet ein Ergebnis. Es geht nicht um die Frage, wer zu welchem Zeitpunkt auf welchen Knopf gedrückt hat, sondern um die Frage, welche Verarbeitungen einen Rohwert in die Zahl verwandelt haben, die jetzt im Bericht steht. Ohne diese Verantwortung ist jede Zahl eine Behauptung, die niemand schnell belegen kann, auch nicht die Person, die sie geliefert hat.
Zwischen der Quelle und dem Bericht liegt meist keine gerade Linie, sondern eine Reihe von Verarbeitungen, und jede Verarbeitung ist eine Stelle, an der sich etwas verschieben kann, ohne dass jemand es merkt. Denken Sie an die Umrechnung von Einheiten, das Zusammenführen von Standorten zu einer Konzernebene, die Korrektur eines Ausreißers, die Anwendung eines Emissionsfaktors. Welche Verarbeitungen das genau sind, unterscheidet sich je Datenpunkt und ist beschrieben bei welche Verarbeitungen liegen zwischen Quelle und Bericht. Wer diese Schritte nicht festhält, sieht nur den Startpunkt und den Endpunkt und muss bei einer Frage zur Zahl den ganzen Weg erneut rekonstruieren, oft anhand von jemandes Erinnerung.
Zwei Verarbeitungen verdienen Aufmerksamkeit, weil sie am häufigsten zu Abweichungen führen. Aggregation summiert Werte aus verschiedenen Quellen zu einer Gesamtsumme, und bei jeder Summierung muss feststehen, welche Posten einbezogen wurden und welche nicht. Wie diese Festlegung aussieht, wenn die Quelle eine Tabellenkalkulation ist, ist beschrieben bei wie Sie Aggregation festhalten, wenn die Quelle eine Tabellenkalkulation ist. Normalisierung skaliert Werte auf eine gemeinsame Einheit oder Periode um, und ein kleiner Fehler in dieser Umskalierung wirkt sich auf jede Zahl aus, die später darauf aufbaut. Die Festlegung dieses Prozesses ist beschrieben bei wie Sie Normalisierung festhalten, wenn die Quelle eine Tabellenkalkulation ist. Beide Verarbeitungen sind in einer Tabellenkalkulation unauffällig und in der Verantwortung unverzichtbar.
Viele Nachhaltigkeitsdaten beginnen nicht in einem System mit festen Feldern und festen Regeln, sondern in einer Tabellenkalkulation, die jemand nach eigenem Ermessen aufgebaut hat. Eine Formel kann überschrieben worden sein, eine Spalte kann verschoben worden sein, ein Zwischenschritt kann nur im Kopf des Erstellers existiert haben. Was Source-to-Report-Mapping bedeutet, wenn die Quelle eine Tabellenkalkulation ist, ist ausgearbeitet bei was Source-to-Report-Mapping ist, wenn die Quelle eine Tabellenkalkulation ist. Der Kern ist, dass das Mapping nicht dem Zufall einer Zelle oder eines Tabellenblatts überlassen bleiben darf, sondern getrennt und wiederholbar festgehalten werden muss, unabhängig von der Tabellenkalkulationsdatei selbst.
Ohne festgehaltene Schritte besteht der Weg von Quelle zu Bericht nur, solange die Menschen, die ihn zurückgelegt haben, noch da sind und sich noch erinnern. Ändert sich etwas am Prozess, kommt ein neuer Kollege hinzu, oder wird eine Frage nach Abschluss des Berichtsjahres gestellt, dann bleibt nur die Möglichkeit, es erneut herauszufinden. Das ist kein Audit Trail, sondern nachträgliche Improvisation. Ein Tool kann dieses Problem nicht lösen, wenn der zugrunde liegende Prozess nicht festgehalten ist; es liefert dann nur ein ordentlicheres Log einer Rekonstruktion, die genauso unsicher ist wie zuvor.
Die Festlegung von Herkunft und Verarbeitungen muss nicht auf Software warten. Wie Sie Lineage ohne Tool aufbauen, mit den Mitteln, die bereits vorhanden sind, ist beschrieben bei wie Sie Lineage ohne Tool erstellen. Für Tabellenkalkulationen als Quelle gelten dieselben Prinzipien wie für den Audit Trail im Allgemeinen: die Festlegung betrifft dieselben Schritte, angewendet auf eine Quelle ohne feste Struktur, wie ausgearbeitet bei warum ein Audit Trail mehr ist als ein Logbuch, wenn die Quelle eine Tabellenkalkulation ist. Wer diese Festlegung einmal für einen Datenpunkt vorgenommen hat, kann sie für den nächsten wiederholen und baut so ein Register auf, das nicht von einem Tool, sondern von einem Prozess abhängt.
Sobald feststeht, welche Schritte eine Zahl durchlaufen hat und wer welche Verarbeitung ausführt, entsteht eine andere Art von Frage: welcher Teil dieser Arbeit repetitiv genug ist, um automatisiert zu werden. Aggregieren nach einer festen Regel, Werte auf eine feste Einheit normalisieren, eine Verarbeitung gegen eine festgelegte Qualitätsregel prüfen, das sind Aufgaben, die sich erst auf Automatisierbarkeit beurteilen lassen, sobald sie als eigenständige Schritte existieren. Der Werkscan von FTE TO AI berechnet pro Aufgabe, welcher Teil der Arbeit von KI übernommen werden kann, und benötigt dafür genau die Art von Aufgabenebene, die ein Audit Trail liefert.
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.