Eine Tabellenkalkulation wirkt wie eine einfache Quelle. Eine Zelle mit einer Zahl, ein Tab mit einem Namen, ein Export aus einem anderen System, der eingefügt wurde. Aber zwischen dieser Zelle und der Zahl, die letztlich in einem Bericht steht, liegt eine Reihe von Bearbeitungen, die meist nirgendwo festgehalten ist. Source-to-Report-Mapping ist das Erfassen dieser Reihe: jeder Schritt, den eine Zahl durchläuft, vom Moment, in dem sie in die Tabellenkalkulation gelangt, bis zu dem Moment, in dem sie in einer Berichtszeile landet.
Bei einem System mit festen Feldern und einer festen Struktur lässt sich oft noch nachvollziehen, welches Feld woher kommt. Eine Tabellenkalkulation hat diese Struktur nicht von sich aus. Jemand fügt einen Zwischentab hinzu, um zu aggregieren. Jemand anderes kopiert eine Spalte in eine andere Datei, um eine Umrechnung vorzunehmen. Ein Dritter fügt das Ergebnis als Wert in ein Berichtsblatt ein, wodurch die Formel und damit die Spur verschwindet. Nichts davon ist falsch in dem Moment, in dem es geschieht. Das Problem entsteht ein Jahr später, wenn jemand erklären muss, woher eine Zahl kommt, und die Antwort nicht mehr zu rekonstruieren ist.
Source-to-Report-Mapping für eine Tabellenkalkulationsquelle besteht aus einer Reihe erkennbarer Schritte, die jeweils eigene Aufmerksamkeit benötigen.
Der erste Schritt ist die Herkunft der Rohdaten: welche Datei, welcher Tab, welche Zelle oder Zellbereich, und wer dies eingibt oder liefert. Ohne diesen Ankerpunkt gibt es keine Quelle, auf die man zurückverweisen kann.
Der zweite Schritt ist welche Bearbeitungen liegen zwischen Quelle und Bericht, wenn die Quelle eine Tabellenkalkulation ist. Man denke an Einheiten, die umgerechnet werden, an Filter, die bestimmte Zeilen ausschließen, an Formeln, die Werte summieren oder neu skalieren. Jede Bearbeitung verändert die Zahl, und jede Bearbeitung, die nicht festgehalten ist, ist ein Schritt, der später nicht mehr überprüft werden kann.
Der dritte Schritt ist die Aggregation: mehrere Zeilen, Tabs oder Dateien, die zu einer Zahl zusammengeführt werden. Bei einer Tabellenkalkulation geschieht dies oft manuell, mit einem Klick auf die Summenfunktion über einen Bereich, den jemand selbst abgegrenzt hat. Wie dieser Bereich gewählt wurde und was darin enthalten ist, bestimmt die Zahl genauso stark wie die zugrunde liegenden Daten. Genau deshalb muss festgehalten werden wie Sie Aggregation festhalten, wenn die Quelle eine Tabellenkalkulation ist: nicht als Formalität, sondern weil der Aggregationsschritt selbst eine Fehlerquelle ist, die sonst niemand sieht.
Der vierte Schritt ist die Normalisierung: unterschiedliche Einheiten, unterschiedliche Berichtsperioden oder unterschiedliche Standorte, die auf eine gemeinsame Basis gebracht werden, bevor sie vergleichbar sind. Auch hier gilt, dass die Wahl eines Umrechnungsfaktors oder Referenzwerts das Ergebnis steuert und dass diese Wahl nachvollziehbar sein muss. Wie das funktioniert, wird erläutert in wie Sie Normalisierung festhalten, wenn die Quelle eine Tabellenkalkulation ist.
Der letzte Schritt ist die Stelle, an der die Zahl landet: die Berichtszeile, der Indikator, die Jahressumme. Auch dieser Übergang muss eine Spur haben, nicht nur einen Verweis auf das Quelldokument.
Es ist verlockend zu denken, dass eine Liste, wer was geändert hat, ausreicht. Das ist ein Logbuch, und ein Logbuch registriert Änderungen, ohne die Logik dahinter zu zeigen. Ein Audit Trail, der etwas bedeutet, zeigt nicht nur, dass eine Zelle geändert wurde, sondern auch warum, auf Basis welcher Regel und mit welchem Ergebnis, zurückverfolgbar bis zur ursprünglichen Quelle. Dieser Unterschied wird weiter erläutert in der Erklärung, warum ein Audit Trail mehr ist als ein Logbuch, wenn die Quelle eine Tabellenkalkulation ist.
Die meisten Organisationen, die mit Tabellenkalkulationen arbeiten, haben kein System, das automatisch die Lineage nachhält. Das bedeutet nicht, dass Mapping unmöglich ist, es bedeutet, dass es manuell geschehen muss, mit Disziplin statt mit Software. Welche Schritte dafür notwendig sind und wie ein tabellenkalkulationsgetriebener Prozess trotzdem nachvollziehbar wird, steht beschrieben in wie Sie Lineage ohne Tool erstellen, wenn die Quelle eine Tabellenkalkulation ist. Eine verwandte Frage, die oft übersprungen wird, ist wer die Definition eines Datenpunkts besitzt: ohne einen benannten Eigentümer der Definition verändert sich die Bedeutung eines Datenpunkts mit der Person, die gerade darauf schaut, und dann hat das schönste Mapping wenig Wert.
Ein Tool, das Berichte hübscher macht, ändert nichts an der Zuverlässigkeit der Zahlen, die hineingehen. Wenn der Weg von der Zelle zum Bericht nicht festgehalten ist, produziert ein Tool ordentlichere Berichte über dieselben unsicheren Zahlen. Das Mapping von Quelle zu Bericht ist daher kein Schritt, der nach dem Tool kommt, sondern einer, der davor liegt.
Sobald die Schritte zwischen Quelle und Bericht ausgeschrieben sind, wird auch sichtbar, welche dieser Schritte Handarbeit sind und welche einer festen, wiederholbaren Bearbeitung folgen. Dieser Unterschied ist die Grundlage für den Werkscan von FTE TO AI, der pro Aufgabe berechnet, welcher Teil der Arbeit von KI übernommen werden kann, basierend auf dem, was bereits über die Bearbeitung, die Regeln und die Herkunft der Daten festgehalten ist.
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.