Data-Software auf einem kaputten Prozess liefert nur schönere Berichte, während die zugrunde liegenden Zahlen unzuverlässig bleiben

Bauen Sie zuerst ein Datenpunkteregister, gestalten Sie dann je Datenpunkt einen Source-to-Report-Prozess mit konsistenten Definitionen über Einheiten hinweg, statt jeder Einheit ihren eigenen Erhebungsansatz unabhängig entwickeln zu lassen. Inkonsistente Definitionen zwischen Einheiten sind meist unsichtbar, bis jemand versucht, die Zahlen auf Konzernebene zu addieren, wobei das Ergebnis still Zahlen kombiniert, die nie dasselbe gemessen haben.

Reparieren Sie zuerst den Prozess, Eigentümerschaft, Definitionen, Kontrollen, bevor ein Tool eingeführt wird; ein Tool auf einem kaputten Prozess liefert nur ordentlichere unzuverlässige Berichte, die glaubwürdiger wirken, als sie sind. Tabellen sind eigentlich nicht das Problem; das fehlende klare Eigentum, konsistente Definitionen und jegliche Kontrolle darüber, was als gültige Zahl zählt, ist das Problem, und kein Softwarekauf löst das für sich allein.

Gestalten Sie jeden Erhebungsprozess mit Kontrollen, Aggregation, Normalisierung, Berechnung und Standardisierung, sodass jede Zahl auf eine Quelle zurückführbar ist, statt im Endbericht als unerklärte Zahl zu landen, die niemand bei Nachfrage verteidigen kann. Ein prüfbarer Prozess ähnelt stark dem, wie Finance bereits mit Finanzdaten umgeht, nur wurde genau diese Disziplin traditionell nie auf Nachhaltigkeitszahlen angewendet, und genau diese Lücke wird hier geschlossen.

Die Dokumentation, je Datenpunkt, woher er stammt, welche Verarbeitung er durchläuft, und wo er im Endbericht landet, sodass der gesamte Weg von der Rohquelle zur veröffentlichten Zahl explizit und überprüfbar ist, statt etwas, das nur eine Person in der Organisation wirklich versteht. Ohne dieses Mapping ist eine Zahl im Endbericht praktisch eine Black Box, die niemand unabhängig verifizieren oder bei Nachfrage rekonstruieren kann.

Weisen Sie ein RACI je Datenpunkt und Prozess zu, Definitionseigentümerschaft bei Sustainability, Prozess- und Kontrolleigentümerschaft bei Finance, statt Eigentümerschaft implizit zu lassen und anzunehmen, dass jemand von selbst Verantwortung übernimmt. Nachhaltigkeitsdaten neigen dazu, niemandem zu gehören, da sie zwischen Abteilungen fallen, die jeweils annehmen, die andere sei zuständig, genau das soll ein explizites RACI verhindern.

Bestimmen Sie, welche Datenpunkte angesichts Ihrer wesentlichen Themen und des Berichtsstandards tatsächlich erforderlich sind, und erfassen Sie, was bereits existiert versus was gebaut werden muss, statt zu versuchen, jeden denkbaren Datenpunkt zu erheben, den der Standard theoretisch erlaubt. Ein Register, das auf das wirklich Erforderliche basierend auf Ihren spezifischen wesentlichen Themen begrenzt ist, ist ein Bruchteil der Größe eines Registers, das jede mögliche Offenlegung unabhängig von Relevanz abzudecken versucht.

Standardisieren Sie die Definition auf Ebene des Datenpunkteregisters, bevor ein Erhebungsprozess gestaltet wird, da inkonsistente Definitionen im Nachhinein zu versöhnen deutlich störender ist, nachdem jede Einheit bereits ihren eigenen Prozess gebaut hat. Sich früh auf eine gemeinsame Definition zu einigen, auch wenn es vorab länger dauert, vermeidet die weit höheren Kosten, später inkompatible Prozesse wieder auseinanderzunehmen.

Definieren Sie je Datenpunkt, was ein gültiger Wert ist und welche Abweichung ein Signal auslöst, dieselbe Disziplin, die Finanzdaten bereits haben, erweitert auf Nachhaltigkeitszahlen, die historisch mit deutlich weniger Rigorosität erhoben wurden. Ein Kontrollrahmen muss nicht aufwendig sein, um wirksam zu sein; er muss je Datenpunkt festlegen, wie ein plausibler Bereich aussieht und was geschieht, wenn eine Zahl außerhalb liegt.

Stellen Sie sicher, dass jede Zahl von Anfang an eine nachvollziehbare Quelle und einen genannten Eigentümer hat, dies nachträglich zu rekonstruieren ist erheblich teurer, insbesondere sobald diejenige Person, die eine Zahl ursprünglich zusammengestellt hat, die Rolle gewechselt hat oder das Unternehmen verlassen hat. Assurance-Anbieter suchen gezielt nach genau dieser Nachvollziehbarkeit, und ihr Fehlen ist einer der häufigsten Gründe, warum ein Nachhaltigkeitsbericht keine saubere Assurance-Aussage erhält.

Reparieren Sie zuerst den Prozess. Funktionale Anforderungen an ein Tool sollten aus dem gestalteten Prozess folgen, nicht umgekehrt, da Software vor Existenz des Prozesses auszuwählen bedeutet, Anforderungen zu raten, statt sie aus einem echten, getesteten Ablauf abzuleiten. So gewählte Tools stellen sich oft als fehlend genau die Fähigkeiten heraus, die der Prozess wirklich braucht, oder enthalten eine lange Liste von Funktionen, die der Prozess nie nutzt.

Definieren Sie funktionale Anforderungen basierend auf Ihrem gestalteten Erhebungsprozess und führen Sie dann erst die Auswahl durch, nie bevor der Prozess existiert, denn eine Anbieter-Demo ist weit überzeugender als eine nüchterne Einschätzung dessen, was Ihre spezifische Datenerhebung wirklich braucht. Aus einem echten Prozess abgeleitete Anforderungen erweisen sich bei der Anbieterauswahl als nützlicher als eine generische Funktionsliste, die aus einem Branchenbericht kopiert wurde.

Definitionseigentümerschaft liegt bei Sustainability; Prozess- und Kontrolleigentümerschaft liegt bei Finance, das die Systeme und Disziplin dafür bereits hat, weil Finance jahrzehntelang genau die Rigorosität aufgebaut hat, die Nachhaltigkeitsberichterstattung jetzt erreichen muss. Diese Aufteilung vermeidet das häufige Fehlermuster, bei dem Sustainability sowohl Definitionen als auch Prozess besitzt, ohne die Systeme, die Finance dafür bereits bereitstehen hat.

Nutzen Sie dasselbe Datenpunkteregister und Prozessdesign als Vorlage, je Einheit angepasst, aber nie neu definiert, damit die Aggregation auf Konzernebene bedeutungsvoll bleibt, statt zu einem Flickenteppich lokal neu erfundener Ansätze zu werden. Lokale Anpassung ist in Ordnung und oft nötig; den zugrunde liegenden Datenpunkt oder seine Definition auf lokaler Ebene neu zu definieren, ist es, was die Vergleichbarkeit auf Konzernebene bricht.

Wochen für ein einzelnes Thema; ein vollständiger konzernweiter Rollout mit Governance ist eine Frage von Quartalen, vor allem bestimmt durch Anzahl der Einheiten und Beteiligten statt durch die technische Komplexität der Daten selbst. Der Zeitrahmen skaliert deutlich stärker mit organisatorischer Koordination als mit der Schwierigkeit der zugrunde liegenden Messung, weshalb ein Einzelthema-Pilot so viel schneller laufen kann als ein vollständiger Rollout.

Pflegen Sie das Source-to-Report-Mapping und den Kontrollrahmen als Dokumentation selbst, es ist von Anfang an prüfungsbereit gestaltet, statt Dokumentation als separate Aufgabe zu behandeln, die erst abgeschlossen wird, wenn der Prozess bereits läuft. Dokumentation nachträglich auf einen bestehenden Prozess aufzusetzen ist sowohl zeitaufwändiger als auch weniger genau, als Dokumentation als natürliches Nebenprodukt einer von Anfang an richtig gestalteten Prozessgestaltung entstehen zu lassen.