Datum
17.07.2024
content.autor.writtenBy
In the last article in our ESG diary, I briefly talked about the IBM Envizi project method. With this method, we and the sustainability experts at delta pronatura focus 100% on their technical analysis and reporting requirements instead of discussing functions and features with IT experts.
Challenge: knowledge transfer
Source: IBM
The biggest challenge is to communicate the scope of the solution to the employees at delta pronatura. Their input has a very significant influence on the finished project. We are therefore currently holding many discussions with them to ensure that they have sufficient basic knowledge of the solution.
This phase of introducing Envizi, identifying all employees and recording requirements is known as “requirements gathering”.
Involve the team in the project
As the team is already ready to start implementation as quickly as possible, we involve them in the project's methodological approach. Specifically, the method provides for several workshops with the team to involve all colleagues, including management, and familiarize them with the method. There is a danger that we will realize at a later stage that we have invested unnecessarily in the wrong preparations, which will either not lead to the goal or will lead to it much later. We are particularly concerned with the gap between the desire for detailed information and available data. Remember: only what is recorded can be analyzed! An example: The breakdown of the energy consumption of a production line by individual products is desired, but only the total consumption is recorded. The breakdown by product, e.g. as a percentage, is possible retrospectively, but will depend on the accuracy of a possibly artificially estimated factor.
Objective: Data inventory and input
The aim in this phase is to pass on all relevant information to the team in order to motivate the right contacts (“data owners”) to get involved. On the one hand, they have to determine historical time periods for the data pool and, on the other hand, define the targets for the level of detail for future data entries. Here, we rely on an iterative process in which the project team works in close coordination with delta pronatura and in which contact persons, procedures and details are clearly defined. An almost continuous exchange between the project team and us on the part of the manufacturer helps to clarify open questions quickly and comprehensively. Note: It is important to gain a common understanding of the Envizi ESG Suite. Only then can relevant information and data be determined correctly. From our experience, we have already addressed the importance of correct configuration at the kick-off and discussed it in detail in the “Requirements Gathering Workshop”.
Creating a Master Data Matrix
We are currently defining the basis for the “Master Data Matrix” (MDM), i.e. the master data for the evaluation, the digital copy of the relevant business processes. In this context, I would like to point out the importance of the term “dimensions”. This view into the future has proven to be helpful in designing analytical solutions that fit precisely.
A standard part of the matrix, and included in the scope of Envizi, are also the structures required to complete the respective frameworks (in this case ESRS), including questions from the specifications and the appropriate fields for the answers.
Here are some example lines that are necessary for filling in the ESRS framework:
| 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 |
Define and structure customer requirements
As some technical terms for filling the ESRS framework with customer-specific details are recurring, here is an overview of the most important ones:
- “Locations": We define hierarchies and their effects on reporting and analyses, e.g. company structure, geographical structures, product lines, but also artificial reporting structures
- “Accounts”, ‘Account Styles’, ‘Data Types’ and ‘Data Type Categories’: We specify data points to be stored, including the assignment to scopes according to GHG.
- “Emission Factors": Envizi provides an extensive set of predefined emission factors in its application, which can be used to convert the entries into CO² equivalents, for example, but not for EVERY use case. At delta pronatura, the inclusion of “custom managed factors” is relevant for the ingredients of cleaning agents. In practice, it is not easy to obtain the necessary information.
Envizi offers a variety of predefined options that have to be selected individually for this project.
Here is an example of an internationally active customer who prefers to use English terms:
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:
(further information can be maintained in various other fields)
Preview
So it remains exciting: as soon as the basis for the Master Data Matrix has been created, this task can be completed and the plan for the configuration can be drawn up. Stay tuned for the next blog, where I will report on the final coordination and the configuration activities, as well as the first data transfer. We will then report on the smooth handover to the customer, training measures and the transfer of tasks to the data entry users.
