Why are we writing?
Our team was recently invited to take part in the Microsoft Solution Accelerator Hack, a 3-day experience that allows us to work alongside Microsoft to implement a proof-of-concept and quicken our delivery pace by utilising the expertise they have in the Microsoft Services space.
In working with our partner Vysus Group who are leading in the emissions auditing space, a problem was identified around trying to help audit greenhouse gas emissions and creating a visual dashboard for businesses to look at their emissions profiles. Emissions profiles are split into three scopes aptly named Scope 1, 2 ,3.
As the diagram above shows, Scope 3 emissions refer to emissions that are indirect 3rd party activities. On the whole they form between 65% – 95% of a company’s broader carbon impact. In the Oil & Gas sector this would trend towards the upper end of this as oil well drilling being the most carbon intensive process of an operator’s business and with most of the work on an oil rig itself being handled by subcontractors.
Our auditing partner has been highlighting that regulatory bodies will be looking into Scope 3 emissions with more scrutiny over the coming years and as fines increase organisations will want to ensure they are reporting accurately.
So what’s the problem?
As these emissions are generated by 3rd parties with the reporting organisation being accountable lots of the solutions that currently exist are wildly disparate. We have heard accounts of companies passing data on spreadsheets, using databases that can be altered, emails that can be accidentally deleted and having no consistent way to share this information.
From the businesses point of view, they need to ensure that their systems are protected from human mis-entry, data loss and are tamperproof once the data has been reported. Where emissions are following a process or are part of a larger supply chain its vital to prove the chain of custody for data. In the example of processing wheat through to it being a wrapped-up loaf of bread in a supermarket, a company would want to be able to demonstrably prove the lifecycle of emissions generated in that loaf from farm to packaged item.
Therefore, we looked at answering the question “Was it possible to provide a solution for reporting Scope 1 – 3 emissions in the Oil well drilling process for a typical Oil Rig Operator?” For this we would have to solve the problems of data security, provide a full auditable history of emissions, and to provide a dashboarding solution to highlight how close or far an Oil & Gas operator would be to meeting the goals they have set themselves.
A way forward
For the hack we looked to deliver a proof of concept that would:
A) Define the process around a simple oil well drilling process
B) Convert this into a Siccar blueprint
C) Create a Microsoft data connector and use power automate to extract the essential data out of the Siccar platform and load it into Microsoft Sustainability Manager
D) Configure Microsoft sustainability manager to provide dashboards that would meet the user needs for what information an operator would need to see
For the purposes of the hack, we would look to leverage the knowledge of Vysus Group in providing the subject matter expertise around emissions factors and to provide the bones of a process we could build into a Siccar blueprint. In terms of outputting our data, we were paired with Paul Henwood who works within Global Partner Solutions as an expert in Microsoft Sustainability Manager who would be helping us get the best out of Sustainability Manager as a new tool in the Microsoft suite.
Siccar uses a distributed ledger as it is the backbone for sharing data. In turn this meets the need to provide that tamperproof audited trail of transactions. This data structure is backed up by a blueprint which dictates when and where in a process data could be written or accessed and by whom. As an example, this ensures someone providing cement to case a drilled hole could only input data related to that process. They would only be able to input it after the contractor involved in drilling the hole has input their diesel usage. This ensures we avoid fugitive data that appears out of nowhere. Similarly, the platform uses a principle of least privilege to ensure that only the necessary data is sent to sustainability manager, with Microsoft not having access to data such as, name of the contractor who flew the crew to the rig.
What we built:
In our three-day hack we parallelised as much as possible with members on point for ‘blueprint building,’ ‘data connector building,’ ‘test data generation,’ and ‘sustainability manager configuration.’ By the very last moment of the very last day, we did prove that data could be input into Siccar, recorded, and secured as a transaction, with then the appropriate fields being output to Sustainability manager where emissions were calculated.
The timescales here were incredibly tight and we did only manage this for half the blueprint, but the premise and the ‘difficult-bit’ had been accomplished.
What we learned:
Having our team focused on a common goal and setting a tight deadline increased our efficiency. This is something we are now trying to replicate in Agile delivery process, shorter iteration cycles with a true cross functional team all swarmed around the same goal.
Access to Paul from the Microsoft side was key to getting some of our Power Automate queries up and running in time for the completion of the hack.
Microsoft throughout the hack were running mini show and tells across some of their processes, keen to us is application onto the Azure Marketplace and the steps needed to get there. As a company and as a product this will be something we will be aiming to do in the medium term to let as many people try the Siccar platform as possible. Again, as a company we are the experts in sharing data and the integrity, security challenges that come with that. Allowing specialists in their respective fields apply their own use cases is what we are excited to see happen to continually build out our feature set and blueprint building capability.
We are building on what was originally a test proof of concept to now turning this into a fully realised end to end emissions carbon tracking tool. This means we have now delivered a simple UI allowing users to log in and record the data as and when they complete an action in the process. Going further we are looking to integrate with specific drilling tooling and its APIs to further reduce the need for manual entry.
Given our compressed time with the hack the blueprint too has been oversimplified. Whilst we have 10 participants and around 15 different actions, in reality the processes is 20% of what the true to life oil well drilling process looks like. Over time we’ll look to deliver more against the true to life
We are keen on showing this to as many people as possible and building excitement around a genuine solution to the Scope 3 accounting problem. Gathering as much feedback as we can on our proposition is vital. You will all be hearing more information about this proposition in the coming weeks and months.
For more information about the hack, and our proposition feel free to reach out to me on LinkedIn or at firstname.lastname@example.org