Kennisbank

Was ist Source-to-Report-Mapping

Eine Zahl in einem Nachhaltigkeitsbericht ist fast nie dieselbe Zahl wie die Zahl im Quellsystem. Zwischen dem Moment, in dem ein Mitarbeiter eine Energierechnung eingibt oder ein Sensor einen Zählerstand registriert, und dem Moment, in dem diese Zahl in einer Berichtstabelle steht, geschieht etwas. Es wird umgerechnet, addiert, korrigiert, mit anderen Quellen zusammengeführt. Source-to-Report-Mapping ist das Festhalten dieses Verlaufs: jeder Schritt, den die Daten zwischen Quelle und Bericht durchlaufen, in der Reihenfolge, in der er stattfindet.

Warum der Verlauf selbst Information ist

Das Ergebnis einer Berechnung sagt nichts über deren Zuverlässigkeit aus, wenn niemand rekonstruieren kann, wie dieses Ergebnis entstanden ist. Eine Emissionszahl kann korrekt sein, weil die zugrunde liegenden Schritte stimmten, oder korrekt erscheinen, weil ein Fehler in einem Schritt einen Fehler in einem anderen zufällig ausgeglichen hat. Ohne Mapping ist dieser Unterschied nicht zu erkennen. Mit Mapping schon: Jeder Schritt steht für sich, mit einer eigenen Quelle, einer eigenen Bearbeitung und einem eigenen Ergebnis, das überprüfbar ist.

Dieser Verlauf besteht meist aus mehr Schritten, als man erwarten würde. Zwischen den rohen Quelldaten und der Berichtskennzahl liegen oft mehrere Bearbeitungen nacheinander: Einheiten, die umgerechnet werden, Werte, die zusammengeführt werden, Ausnahmen, die manuell korrigiert werden. Welche Bearbeitungen zwischen Quelle und Bericht liegen, unterscheidet sich je Datenpunkt, doch der Aufbau ist stets derselbe: eine Reihe von Schritten, die jeweils etwas zu den Daten hinzufügen oder verändern, und die jeweils einzeln festgehalten werden müssen, um das Ganze nachvollziehen zu können.

Die zwei Bearbeitungen, bei denen es am häufigsten schiefgeht

Zwei Arten von Bearbeitungen verdienen besondere Aufmerksamkeit, weil sie am häufigsten vorkommen und am leichtesten unbemerkt Fehler einführen.

Die erste ist die Aggregation: das Zusammenführen von Zahlen aus mehreren Quellen oder mehreren Zeiträumen zu einer einzigen Zahl. Wer festhält, wie diese Addition genau verläuft, welche Posten einbezogen wurden und welche nicht, verhindert, dass eine Berichtskennzahl zur Black Box wird. Wie Sie die Aggregation festhalten, entscheidet darüber, ob jemand nachträglich noch nachvollziehen kann, wie Sie die Aggregation festhalten auf eine Weise, die zu den zugrunde liegenden Posten rückverfolgbar bleibt.

Die zweite ist die Normalisierung: das Zurückführen unterschiedlicher Quelldaten auf eine gemeinsame Einheit oder Definition, damit Zahlen aus verschiedenen Systemen vergleichbar werden. Ein Liter Diesel und eine Kilowattstunde Strom werden erst nach einer Umrechnung vergleichbar, und diese Umrechnung enthält Annahmen. Festzuhalten, wie Sie die Normalisierung festhalten, bedeutet festzuhalten, welche Annahmen das sind, sodass eine andere Partei dieselbe Annahme nachvollziehen oder infrage stellen kann.

Mehr als ein Logbuch

Es ist verlockend, Mapping mit einem Aktivitätenlogbuch zu verwechseln: einer Liste, wer was wann geändert hat. Das ist ein Bestandteil, aber nicht das Ganze. Ein Audit Trail, der nur Änderungen registriert, sagt nicht, warum eine Bearbeitung angewendet wurde oder welche Regel dahintersteckte. Warum ein Audit Trail mehr ist als ein Logbuch, hängt mit der Frage zusammen, die jeder Prüfer letztlich stellt: nicht nur, was geändert wurde, sondern aufgrund welcher Logik und welcher Quelle.

Ohne Tool, mit derselben Disziplin

Source-to-Report-Mapping wird oft mit Software verwechselt. Es gibt Tools, die Lineage automatisch anzeigen, doch diese Tools registrieren nur das, was bereits strukturiert angeliefert wurde. Eine Organisation, die noch mit Tabellenblättern und manuellen Übergaben arbeitet, kann den Verlauf ebenso gut festhalten, nur mit anderen Mitteln: einem festen Dokumentationsformat pro Schritt, einem festen Ort, an dem Quelldateien aufbewahrt werden, einer festen Methode, Änderungen zu vermerken. Wie Sie das ohne Tool organisieren, ist beschrieben unter wie Sie Lineage ohne Tool erstellen. Die Disziplin liegt nicht in der Software, sondern in der Wiederholbarkeit der Erfassung.

Diese Disziplin ist besonders wichtig, wenn die Quelle selbst bereits ein Tabellenblatt ist. Eine Zelle in einem Arbeitsblatt hat keine eingebaute Herkunft: Niemand sieht automatisch, wer einen Wert eingegeben hat oder auf Grundlage welches Dokuments. Was Source-to-Report-Mapping bedeutet, wenn die Quelle ein Tabellenblatt ist, ist, dass diese Herkunft manuell mitorganisiert werden muss, mit derselben Genauigkeit wie bei einem automatisierten System.

Was dieses Festhalten konkret bedeutet

In der Praxis läuft Mapping auf eine Frage hinaus, die bei jedem Datenpunkt wiederholt wird: Woher kommt dieser Wert, was wurde damit gemacht, bevor er im Bericht landete, und wer hat diesen Schritt ausgeführt oder freigegeben. Diese Frage bei Hunderten von Datenpunkten zu stellen, ist arbeitsintensiv, und genau das macht es attraktiv, sie zu überspringen. Doch ein Bericht, der auf einer nicht rückverfolgbaren Grundlage steht, bleibt anfällig für Fragen, die niemand in dem Moment beantworten kann, in dem sie gestellt werden.

Diese Schritte je Datenpunkt und über mehrere Quellen hinweg zu erfassen, ist repetitive Arbeit mit einer festen Struktur: Quelle identifizieren, Bearbeitung beschreiben, Verantwortlichen feststellen, für den nächsten Datenpunkt wiederholen. Arbeit mit einer festen Struktur ist genau die Art von Arbeit, von der sich ein Teil durch KI übernehmen lässt. Der Werkscan von FTE TO AI berechnet je Aufgabe, welcher Teil dieser Arbeit sich dafür eignet, sodass deutlich wird, wo Menschen für die Beurteilung nötig bleiben und wo Wiederholung automatisiert werden kann.