Wissenstransfer und Kommunikation mit Data Owner sind das A und O
ESG-Tagebuch | Industriekunde setzt auf mehr Nachhaltigkeit | Teil 2
Im letzten Beitrag unseres ESG-Tagebuchs hatte ich kurz über die IBM Envizi Projektmethode gesprochen. Bei ihr konzentrieren wir uns mit den Nachhaltigkeitsexperten des Unternehmens zu 100 Prozent auf deren fachliche Analyse- und Reporting-Anforderungen, statt mit IT-Experten über Functions & Features zu diskutieren.
Herausforderung: Wissenstransfer
Die größte Herausforderung besteht darin, den Mitarbeitenden des Kunden den Umfang der Lösung zu vermitteln. Ihr Input hat ganz wesentlichen Einfluss auf das fertige Projekt. Daher führen wir derzeit viele Gespräche mit ihnen, um sicherzustellen, dass ausreichend Basiswissen über die Lösung vorhanden ist.
Bezeichnet wird diese Phase der Einführung in Envizi, der Bestimmung aller Mitarbeitenden und der Anforderungsaufnahme als „Requirements Gathering“.
Quelle: IBM
Team ins Projekt einbinden
Weil das Team schon bereitsteht, möglichst schnell in die Umsetzung starten zu können, binden wir es in den methodischen Ansatz des Projekts ein. Konkret sieht die Methode einige Workshop mit dem Team vor, um alle Kollegen inkl. Management einzubinden und mit der Methode vertraut zu machen. Die Gefahr droht, dass wir in einer späteren Phase erkennen, unnötige viel in falsche Vorbereitungen investiert zu haben, was entweder nicht oder viel später zum Ziel führt. Insbesondere der GAP zwischen Wunsch nach Detailinformation und verfügbaren Daten beschäftigt uns. Merke: nur, was erfasst wird, kann auch analysiert werden! Ein Beispiel: Gewünscht wird die Aufteilung des Energieverbrauchs einer Produktionslinie nach einzelnen Produkten, erfasst wird aber nur der Gesamtverbrauch. Die Aufteilung nach Produkten, etwa prozentual ist zwar nachträglich möglich, wird aber von der Genauigkeit eines womöglich künstlich geschätzten Faktors abhängen.
Ziel: Datenbestand und -eingaben
Ziel in dieser Phase ist es nun, alle relevanten Informationen an das Team weiterzugeben, um die richtigen Ansprechpartner („Data Owner“) zu motivieren, sich einzubringen. Sie müssen einerseits historische Zeiträume für den Datenbestand ermitteln, anderseits die Ziele für den Detailgrad zukünftiger Dateneingaben festlegen. Hierbei setzen wir auf einen iterativen Prozess, in dem das Projektteam in enger Abstimmung mit dem Kunden steht und in dem Ansprechpartner, Vorgehen und Details klar definiert sind. Ein nahezu durchgängiger Austausch des Projektteams seitens des Herstellers mit uns, hilft, offene Fragen schnell und umfassend zu klären. Merke: Es ist wichtig, gemeinsam ein Verständnis für die Envizi ESG Suite zu bekommen. Nur so können relevante Informationen und Daten korrekt ermittelt werden. Aus unserer Erfahrung heraus, haben wir die Bedeutung der korrekten Konfiguration schon beim Kick-Off angesprochen und im „Requirements Gathering Workshop“ eingehend thematisiert.
Master Data Matrix erstellen
Aktuell definieren wir die Basis für die „Master Data Matrix“ (MDM), also die Stammdaten für die Auswertung, die digitale Kopie der relevanten Geschäftsprozesse. In diesem Zusammenhang möchte ich auf die Bedeutung des Begriffs der „Dimensionen“ hinweisen. Dieser Blick in die Zukunft hat sich als hilfreich erwiesen, um analytische Lösungen passgenau zu konzipieren.
Standardbestandteil der Matrix, und im Umfang von Envizi enthalten, sind weiterhin die für das Ausfüllen der jeweiligen Frameworks (in diesem Fall ESRS) notwendigen Strukturen, unter anderem Fragen aus den Vorgaben und die passenden Felder für die Antworten.
Hier einige Beispielzeilen, die für das Füllen des ESRS Frameworks notwendig sind:
| Framework | Question Code | Question |
| ESRS | ESRS-2-GOV-1 | The role of the administrative, management and supervisory bodies |
| ESRS | ESRS-2-GOV-2 | Information provided to and sustainability matters addressed by the undertaking’s administrative, management and supervisory bodies |
| ESRS | ESRS-2-GOV-3 | Integration of sustainability-related performance in incentive schemes |
| ESRS | ESRS-2-GOV-4 | Statement on due diligence |
| ESRS | ESRS-2-GOV-5 | Risk management and internal controls over sustainability reporting |
Kundenanforderungen definieren und strukturieren
Da einige Fachtermini für das Füllen des ESRS-Frameworks mit kundenspezifischen Details wiederkehrend sind, hier die wichtigsten im Überblick:
- „Locations“: Wir definieren Hierarchien und deren Auswirkungen auf das Reporting und die Analysen, z.B. Firmenstruktur, Geografische Strukturen, Produktlinien, aber auch künstliche Reporting-Strukturen
- „Accounts“, „Account Styles“, „Data Types“ und „Data Type Categories”: Wir spezifizieren zu speichernde Datenpunkte, inkl. der Zuordnung zu Scopes nach GHG.
- „Emission Factors“: Envizi stellt in seiner Anwendung ein umfangreiches Set von vordefinierten Emissionsfaktoren bereit, mit der die Eingaben z.B. in CO²-Äquivalente umgerechnet werden kann, aber nicht für JEDEN Anwendungsfall. Bei diesem Kunden ist die Aufnahme von „custom managed factors“ für die Inhaltsstoffe von Reinigungsmitteln relevant. In der Praxis zeigt sich, dass die Beschaffung der notwendigen Information nicht ganz leicht ist.
Envizi bietet eine Vielzahl von vordefinierten Möglichkeiten, die individuell für dieses Projekt ausgewählt werden müssen.
Hier ein Beispiel für einen international tätigen Kunden, der bevorzugt englische Begriffe nutzt:
Account Style Name (given by customer): own Air Travel - Domestic or International
Account Style Caption (provided and selected by Envizi): Air Travel - Domestic or International
Data Type Name – Internal (provided and selected by Envizi): Air Travel - Domestic or International
Data Type Category (provided and selected by Envizi): Air Travel
Scope* (provided and selected by Envizi): Scope 3
Factor Provided? * (to be selected): “” (means Factor is provided by Envizi)
Sub Type (modifier): Business Class
Primary UOM*: km
Local Input UoM (only if different from Primary UOM):
Conversion (only if different from Primary UOM):
Calculation/Rules (only if calculated):
Accrual Method (Event-Based, Calculated, Continuous): Event
Field1 label (How this Account Style will be presented in Envizi Frontend): “Distance”
Field1 help text (How this Account Style will be presented in Envizi Frontend): “Please enter Distance”
Field1 type: numeric
Field1 contents/notes:
(in diversen weiteren Feldern können weitere Informationen gepflegt werden)
Ausblick
Es bleibt also spannend: sobald die Basis für die Master Data Matrix erstellt wurde, kann dieser Task abgeschlossen und der Plan für die Konfiguration erstellt werden. Bleiben Sie dran, wenn ich im nächsten Blog über die finale Abstimmung und die Tätigkeiten im Rahmen der Konfiguration, sowie der ersten Datenübernahme berichte. Im Anschluss berichten wir über die fließende Übergabe an den Kunden, Schulungsmaßnahmen und die Übertragung der Aufgaben an die „Data Entry User“.
Der Autor: Marc Bastien
Haben Sie Fragen, Feedback oder wünschen eine Beratung? Kontaktieren Sie mich gerne direkt.
