Part 1 of this article series is available here. This part establishes a background related to SDG, ESG and Sustainability.
Part 2 of this article series is available here. This part explored the high-level data exchange scenarios.
The previous article explored the high-level data exchange scenarios between TRIRIGA and Envizi. Next, we shall dive into the Portfolio level data exchange scenario in more detail.
As mentioned earlier, the “Portfolio Data” within TRIRIGA is a natural match to the “Organization Data Hierarchy” in Envizi. The question that would come to mind is, is this as easy as linear mapping? The answer would be, “No, it is not”.
While some data elements could have explicit mapping, other data elements require some thought process to align them with the specific business needs.
Let’s dive into TRIRIGA and Envizi data models to lay the foundation. After that, we will dive into the specific data elements.
TRIRIGA data modal:
Within the Portfolio data, we can collate the datasets into two groups which can map to Envizi. The first set is the core portfolio data required for the essential working of the joint solution.
The second set comprises specific data sets that are optional and need to be imported and kept in sync as per the need driven by the data segregation and reporting requirements. TRIRIGA has many data elements. We don’t need to migrate and sync the data elements just because we can. So, we must reason and decide on the data sets required for the exchange. The process should consider the data segregation requirements in Envizi, for example, who gets to see what data under which groupings and the requirements related to the reporting filters.
Each time we set up a Group and subsequent Sub-groups in Envizi and link data with those Groups and Sub-groups, it is a complex and costly affair. Hence, we should make decisions regarding the Integration points only after the Organisation’s data hierarchy within Envizi has been discussed and agreed upon upfront.
The current assessment is from an early evaluation of the Envizi solution. I intend to cross-validate the outline defined here with Envizi solution experts in future.
Core Portfolio data:
The following elements of TRIRIGA portfolio data could be candidates for the core portfolio data, which can map one-to-one with the Envizi data structure.
- Property / Campus
The primary data object shall be Building, and in specific scenarios, it is possible to use a Property or a Campus, which is essentially a collection of Buildings. There is no roll-up hierarchy for Locations in Envizi, so it will be either a Property or a Building location in Envizi, which we shall use for anchoring the data.
Although the location hierarchy within TRIRIGA contains other elements, they are not required to set up the Organisation data hierarchy in Envizi.
While setting up the group structure, we could use specific attributes against the TRIRIGA Building record in Envizi. We shall discuss these in the “Optional portfolio data” section.
The second element of the Core portfolio data section is Organisation Hierarchy:
- My Company
The “My Company” data shall map directly to the Organisation record in Envizi. The organisation data is flat, so just one level, “My Company”, is generally required in the Organisation set up on the Envizi side.
There are multiple other hierarchy levels within the TRIRIGA organisation hierarchy, for example, “Division”, “Departments”, and “Work Groups”. These could be of use in Envizi while setting up group structure. We shall discuss these in the “Optional portfolio data” section.
Apart from the core “My Company” records, TRIRIGA also hosts data for external companies that are either Customer organisations or Supplier / Vendor organisations. External companies’ usage is an open item to explore further to ascertain how to capture the external organisations as supplier organisations in Envizi and collect the environmental impact data included in “Scope 3 – Indirect emission” data sources.
Optional Portfolio data:
- World Regions
- Metropolitan Area
Within the TRIRIGA Geography hierarchy, we have multiple elements, as listed above. We could use these data elements to define the Groups or Sub-groups within Envizi. However, the data segregation requirements, access requirements and reporting roll-up requirements collectively drive the choice of Groups and Sub-groups within Envizi.
- Work Groups
- External Companies
Similarly, within the Organisation hierarchy, we have multiple elements listed above that can be used to define the Groups or Sub-groups within Envizi, again driven by the specific requirements.
In place of the Organisation hierarchy in Envizi, we could potentially set up the External Companies as groups and Sub-groups in Envizi; however, the roll-up and % appropriation would need to be clarified.
Other Building Attributes and Classifications:
- Building Usage Classification
- Building Zoning
- Building Primary Use
- Location Category
- Carbon Calculation Region
We could use other specific attributes to group the data based on the reporting requirements.
- Building Usage Classification could contain values like Corporate Office, Distribution Centre, Manufacturing, etc.
- Building Zoning could contain values like Agricultural, Commercial, Industrial, etc.
- Building Primary Use could contain values like Administration, Back office, Bank Branch, Computer Data Centre, Acute Care, etc.
- Location Category is a logical grouping in TRIRIGA that we can use to group data in Envizi.
- The Carbon Calculation Region is another logical structure in TRIRIGA that we can use to group data in Envizi.
There might be other optional portfolio data elements not covered here that could be useful for grouping the data. This assessment must be part of the initial discovery and data mapping exercise.
The following diagram brings all the above information together.
Figure 01: TRIRIGA and Envizi portfolio data exchange diagram
Initial synchronisation shall be required across both core and optional portfolio data objects. After that, a scheduled update of delta changes should be good enough to keep the data up-to-date.
For all the core Portfolio data, TRIRIGA could be the system of record as the broader custodian of the data for the Physical Assets. Based on the agreed data modal, we could import some data elements back into TRIRIGA.
I shall pause here and conclude the discussion regarding the portfolio data. Then, in future articles, I’ll talk about other Sustainability related data objects like utility billing data, weather data, sustainability logs and emission factors before moving on to the Envizi hierarchy.
Please provide me with your feedback either by leaving a message here or through a direct message.
MobileKraft offers a pre-built Sustainability APIs pack where the Core Portfolio data and other Optional portfolio data mentioned here are available and ready to go. Depending on the evolving data needs, we can adapt the APIs in a short time. Additionally, we are looking at options for Scheduling and Transformation of the portfolio data to make it available to Envizi in the format and structure it understands through the transmission channels it may utilise.
Please get in touch with us if you would like to explore these solutions.
[…] Beyond the mist – TRIRIGA and Envizi – Part 3 […]