Eine Tabelle mit Energieverbrauch, Reisedaten oder Einkaufsdaten ist selten der Endpunkt. Bevor eine Kennzahl in einem Nachhaltigkeitsbericht steht, ist sie abgetippt, addiert, umgerechnet, gefiltert und manchmal manuell korrigiert worden. Jeder Schritt ist eine Stelle, an der etwas von der Quelle abweichen kann, und jeder Schritt, der nicht dokumentiert ist, ist ein Schritt, den niemand nachträglich nachvollziehen kann.
Der gängige Weg von der Quelle zum Bericht besteht aus einer Reihe erkennbarer Bearbeitungen. Daten werden aus einem Quelldokument übernommen, oft mit einem manuellen Kopierschritt. Anschließend wird normalisiert: Einheiten werden vereinheitlicht, Notationen angepasst, fehlende Werte ergänzt oder geschätzt. Danach folgt die Aggregation, bei der Zahlen aus verschiedenen Standorten, Perioden oder Abteilungen zu einer Zahl zusammengeführt werden. Zwischendurch finden Korrekturen statt: eine fehlerhafte Zeile wird angepasst, ein Ausreißer wird entfernt, eine Annahme wird auf ein leeres Feld angewendet. Am Ende dieser Kette steht die Kennzahl, die im Bericht erscheint.
Das Problem ist nicht, dass diese Bearbeitungen stattfinden. Normalisieren und Aggregieren sind nötig, um Tabellendaten brauchbar zu machen. Das Problem ist, dass diese Schritte in der Regel im Kopf eines einzelnen Mitarbeiters sitzen, oder höchstens in einem E-Mail-Verlauf, den niemand mehr wiederfindet.
Wenn eine Kennzahl im Bericht zur Diskussion steht, muss nachvollziehbar sein, woher sie stammt und was mit ihr geschehen ist. Ohne diese Nachvollziehbarkeit wird jede Frage zu einer Zahl zu einer Suche: Wer hat diese Zeile angepasst, aufgrund welcher Grundlage, und wurde dieselbe Bearbeitung im Jahr davor ebenfalls angewendet. Bei der Normalisierung geht es beispielsweise um Fragen wie: Welcher Umrechnungsfaktor wurde verwendet, und wurde dieser Faktor seitdem geändert. Bei der Aggregation geht es um: Welche Quellen wurden addiert, und wurde ein Standort versehentlich doppelt gezählt oder gerade übersprungen.
Eine Tabelle ohne dokumentierte Bearbeitungen kann im Jahr darauf bei denselben Quelldaten eine andere Kennzahl ergeben, einfach weil jemand anders die Normalisierung durchführt oder eine Korrektur anders interpretiert. Das ist kein Betrug, es ist das Fehlen eines dokumentierten Prozesses. Die Folge ist dieselbe: Die Kennzahl ist nicht reproduzierbar.
Manche Organisationen denken, dass ein Änderungslogbuch in der Tabelle ausreicht. Ein Logbuch registriert, dass sich etwas geändert hat, aber nicht warum, von wem in welcher Rolle, und aufgrund welcher Regel. Der Unterschied zwischen einem Logbuch und einem Audit Trail liegt in diesem Kontext: Ein Audit Trail macht eine Bearbeitung nachvollziehbar, ein Logbuch registriert nur, dass etwas geschehen ist.
Das Fehlen eines Tools ist keine Ausrede, um Lineage zu überspringen. Auch ohne spezialisierte Software ist es möglich, pro Datenpunkt festzuhalten, aus welcher Quelle er stammt, welche Bearbeitungen darauf angewendet wurden und wer diese Bearbeitungen durchgeführt hat. Das kann mit einer festen Struktur neben der Tabelle selbst erfolgen: einem Register, in dem Quelle, Bearbeitung und Verantwortlicher zusammen stehen. Wie das aussieht, ohne dass ein Tool zum Einsatz kommt, ist beschrieben auf der Seite über Lineage ohne Tool aufbauen.
Zu jedem Bearbeitungsschritt gehört ein Eigentümer. Nicht nur des letztendlichen Datenpunkts, sondern der Bearbeitung selbst: Wer hat festgelegt, dass diese Normalisierungsregel angewendet wird, und wer darf diese Regel ändern. Diese Eigentümerschaft ist oft nicht festgelegt. Zwei Fragen sind dabei zu unterscheiden: wer die Definition eines Datenpunkts besitzt, also was die Zahl genau bedeutet, und wer den Prozess darunter besitzt, also wer verantwortlich ist für den Weg, auf dem sie entsteht. Ohne dass diese beiden festgelegt sind, bleibt eine Bearbeitung eine individuelle Gewohnheit statt eines Organisationsprozesses.
Der Data Readiness Scan bildet diese Bearbeitungen ab: welche Schritte zwischen Quelle und Bericht stattfinden, wer sie durchführt und welche Regeln dahinterstehen. Das ist kein Berichtstool und kein Fragebogen, sondern eine Erfassung des Prozesses, der der Kennzahl vorausgeht.
Wenn einmal klar ist, welche Bearbeitungen zwischen Tabelle und Bericht stattfinden, entsteht auch ein Überblick darüber, welche dieser Schritte repetitiv und regelbasiert sind und somit dafür in Frage kommen, anders eingerichtet zu werden. Der Werkscan von FTE TO AI berechnet pro Aufgabe, welcher Teil der Arbeit von KI übernommen werden kann, und schließt damit genau an die hier beschriebenen Bearbeitungen an: Normalisieren, Aggregieren und Korrigieren sind Schritte, die sich, sofern zuvor dokumentiert, auf diese Frage hin beurteilen lassen.
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.