Es gibt einen festen Moment in fast jedem Gespräch über Nachhaltigkeitsdaten: Jemand zeigt auf das Spreadsheet. Zu viele Tabs, zu viel Handarbeit, zu viel Fehleranfälligkeit. Die Schlussfolgerung liegt nahe: Ersetzen Sie das Spreadsheet durch ein System, und das Problem ist gelöst. Diese Schlussfolgerung ist meist zu früh gezogen.
Ein Spreadsheet ist eine Oberfläche. Es zeigt Zahlen, addiert sie, verknüpft sie miteinander. Was es nicht tut, ist erklären, woher eine Zahl kommt, wer dafür verantwortlich ist, oder ob sie noch mit der Definition übereinstimmt, die vor zwei Jahren festgelegt wurde. Diese Fragen sind nicht an das Spreadsheet gestellt worden — sie wurden nirgendwo festgehalten. Das Spreadsheet bekommt die Schuld für etwas, das bereits vorher schiefgegangen ist: bei der Erfassung, beim Abtippen, bei der Annahme, ein Kollege wisse schon, welche Zahl gemeint war.
Ersetzen Sie das Spreadsheet durch ein Softwarepaket, und diese Fragen bleiben unbeantwortet. Das System zeigt dann eine ordentlichere Übersicht derselben Unsicherheit. Der Bericht wirkt professioneller; die zugrunde liegenden Daten sind dadurch nicht zuverlässiger geworden. Das ist die Fallgrube: ein Tool kaufen, bevor klar ist, was dieses Tool ordnen soll.
Meist geht es um drei Dinge, die sich unabhängig voneinander entwickelt haben. Es gibt keine aktuelle Übersicht darüber, welche Datenpunkte eine Organisation benötigt — diese Übersicht wurde einst für einen alten Berichtsstandard erstellt und nicht aktualisiert. Es gibt keine festgelegte Linie von der Quelle bis zur Berichtszahl, sodass niemand mit Sicherheit sagen kann, ob eine Zahl aus dem einen System oder dem anderen stammt, oder aus einer Schätzung, die jemand einmal eintrug, weil die echten Daten nicht verfügbar waren. Und es gibt keinen Eigentümer pro Datenpunkt — die Person, die die Zahl liefert, ist nicht automatisch diejenige, die erklären kann, woher sie kommt oder wie ihre Qualität einzuschätzen ist.
Diese drei Dinge haben nichts mit Spreadsheets zu tun. Sie würden in jedem System dasselbe Problem verursachen. Ein Spreadsheet macht sie nur sichtbarer, weil keine Schicht darüberliegt, die das Durcheinander verdeckt.
Ein Datenpunktregister mit Source-to-Report-Lineage legt fest, woher ein Datenpunkt kommt, wer dafür zuständig ist und welche Qualitätsregeln darauf anwendbar sind. Das ist nützlich, und es ist auch begrenzt. Das Register zeigt kein inhaltliches Urteil darüber, ob eine Zahl korrekt ist — es zeigt, ob der Weg zu dieser Zahl nachvollziehbar ist. Zwei Organisationen mit demselben Register können trotzdem unterschiedlich bei der Datenqualität abschneiden, weil die eine Organisation eine Quelle hat, die selbst ungenau ist, und die andere nicht. Das Register macht diesen Unterschied sichtbar; es löst ihn nicht.
Wichtig ist auch: Nicht jeder Datenpunkt braucht dieselbe Menge an Lineage. Für manche Zahlen reicht eine einfache, gut dokumentierte Quelle; für andere ist mehr Detail nötig, weil zwischen Quelle und Bericht mehr Schritte liegen. Welche Datenpunkte eine Organisation tatsächlich benötigt, hängt von der Berichtspflicht und der Branche ab, und das ist etwas anderes, als anzunehmen, dass alles die gleiche Aufmerksamkeit verdient. Wie viele der bestehenden Datenpunkte bereits eine Quelle haben, unterscheidet sich stark von Organisation zu Organisation — bei der einen ist das in einer ERP-Anbindung festgelegt, bei der anderen im Gedächtnis eines einzelnen Mitarbeiters.
Der Aufbau eines Registers und der Lineage ist keine Frage, ein System einzuschalten. Es geht darum, Thema für Thema nachzuvollziehen, wo eine Zahl entsteht, wer sie sich ansieht, bevor sie den Bericht erreicht, und was passiert, wenn diese Person nicht mehr da ist. Diese Arbeit unterscheidet sich je nach Thema: Für das eine Thema liegt die Quelle schon bereit, für das andere muss sie noch gefunden oder rekonstruiert werden. Wer sich fragt, wie viel Zeit das pro Thema erfordert, findet eine realistischere Antwort in der Einschätzung der Durchlaufzeit pro Thema als in einer Tool-Demo, die verspricht, dass alles automatisch geht.
Dieser Ansatz liefert keinen Bericht — den erstellt ein anderes Werkzeug, auf Basis dieser Daten. Was er wohl liefert, ist eine Struktur, die stehen bleibt, auch wenn das Spreadsheet ersetzt wird, auch wenn der Mitarbeiter, der alles wusste, das Unternehmen verlässt. Was das in der Praxis für diejenigen bedeutet, die künftig ins Register schauen, steht beschrieben unter wer das Datenpunktregister konsultiert, wenn der Ersteller nicht mehr da ist, und was sich ändert, sobald die Lineage einmal festgelegt ist, steht unter den Folgen einer einmal festgelegten Lineage.
Spreadsheets sind nicht das Problem, aber sie sind das erste sichtbare Symptom. Wer das Spreadsheet ersetzt, ohne vorher zu wissen, welche Datenpunkte wirklich relevant sind, welche Quelle dazugehört und wer dafür zuständig ist, verlagert das Problem in ein teureres System. Was dann übrig bleibt, ist die Frage, die dieser Arbeit vorausgeht: welche Datenpunkte tatsächlich für die Berichtspflicht benötigt werden, und ob ein Teil davon vielleicht schon irgendwo in der Organisation existiert, ohne dass jemand es weiß, wie unter wo ein Datenpunkt möglicherweise schon vorliegt zu lesen ist.
Das ist Arbeit, die Menschen heute größtenteils manuell erledigen: Quellen aufspüren, Definitionen vergleichen, Eigentümerschaft erfragen. Ein Teil dieser Recherchearbeit lässt sich mit KI strukturieren und beschleunigen, ein Teil nicht — genau diesen Unterschied betrachtet der Werkscan von FTE TO AI. Der Werkscan berechnet pro Aufgabe, welcher Teil der Arbeit von KI übernommen werden kann, und liefert damit ein realistischeres Bild als die Annahme, dass ein Tool das Problem als Ganzes löst.
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.