 Ik ben hier vandaag met Micha van der Haven, VP, vice president, consulting expert in our oil and gas unit. Mijn naam is Raamon Bouter, I'm a director of consulting services within the same unit as well. So what we noticed over the past period, if the recent period is that not every organization who is willing to implement and work with OSDU might have the right knowledge or expertise or maybe budget to implement its own OSDU platform. And we all know that it is a complex platform using a lot of technologies and you should have the availability, but also the knowledge and the people at the time with the organization to on one hand implement an OSDU platform, but on the other hand also maintain it. En I think it was also within one of the earlier OSDU forum meetings that specifically the request came. Is there or will there be a pass version of OSDU available, because we do not want to focus on the technology, we want to focus on the usage and being able to implement it as easy as possible. Dat is where our drive started to work on an implementation of OSDU in the past four months. But on the other hand when you have this platform, when you have the platform running, of course the focus and the value of OSDU comes in its usage in the value of the data that you have in it and that you can work with and combine probably from various sources. But that means that you need to migrate data into OSDU. You might, we have seen several examples where you need to adopt your applications and maybe your own scripts within your organizations. And that might require you also to set up a development environment, a test environment. You want to do some proof of concepts, maybe sort out some use cases. How can this work for my specific department or in this specific workflow? You do not want to test that on your production environment. So that might require that you have various instances of OSDU running apart from your production environment. You want to be able to easily start it up and then work with it, when you have done your tests, maybe close it down or what I mentioned before that you set up this development pipeline with a development test and production environment. So that already requires several instances of OSDU running. To implement and maintain that, as I mentioned, you want to spend as less time as possible for that and you want to focus on the functionality. So those were a few of the, say, design drivers of thoughts that we had when we were thinking about what would an organization need if it starts the journey working with OSDU. The main thing, of course, is ease of use. You want to immediately or as quick as possible start working with the data, start integrating it or inserting it and do your thing with it. You also want to spend as less time as possible on your operational maintenance and, of course, the quicker you can start with it and reduce your implementation time the better. Some efficiency ease of use are a few of the main drivers that we had in the development of CGI Pivot. Supporting the possibility to start and stop various OSDU instances easily should be included as well. And we also understand that every organization might have its own cloud service provider dat they work with, either it be Amazon or Azure or maybe Google Cloud. So if you build such a platform, you should also be able to support various cloud service providers. Now, with that, CGI started its journey to build our Pivot platform, which comprises all those items that I just mentioned, reducing the implementation cost by immediately within a few minutes being able to start up an OSDU instance, and then within that selecting which cloud service provider you want to use as your infrastructure provider. En dat makes it easier for, for example, for all operators or also maybe startups or research companies to say, OK, if I need to develop a specific application, I can immediately and within a few minutes set my, a few instance up and then start developing, start testing and start doing your business work. Also with the knowledge that we have built with the development of our platform, the years of experience we have in the oil and gas industry, and in doing these kinds of projects with integrating and migrating data, we efficient to bring that together. So we are starting to set up our CGI OSDU center of excellence, where we bring this all together on the one hand, the platform, but on the other hand also at the consulting expertise and the project expertise to support your organization in implementing an OSDU environment and running your applications on top of that. Now, to show how this would work in practice, I would like to ask Michael to give us and lead us through a demonstration that we've created to show you how CGI Pivot works and how easy it is to start up an instance and integrate some data into the platform. Michael? Yeah, thank you, Ramon, if everybody can hear me. So this is a video that we quickly recorded for a quick demonstration. This is the more less landing page or the page that you confronted with as soon as you're onboarded into CGI Pivot. You can create organizations, you can create projects, which you can use as a logical setup for any instance that you want to run on. We start out with creating a first organization, obvious one, CGI Netherlands with a description on what we're doing there. You can provide a couple of tags in there as well. This is quite useful if you're, for example, a service supplier that is managing OSDU instances for others. Within an organization, you can create a project or multiple projects and you can do that along with actual projects that you're doing in your organization or like we're doing here along the lines of the different data types or locations of data that we have. We created an extra project here and since we created an offshore project, we now create a non-shore project. There we are. We have got a couple of projects in the environment. Like I said, we can also create multiple organizations, so if you're indeed a service provider that is doing the IT or OSDU management for other operators, this could be another customer. In this case, we're setting up something for CGI Netherlands, but now in an R&D environment. Provide a description again, simple tag, and we add the organization. Ofcort within the organization, we can create projects again. In this case, it's also along the lines of the same projects that we set up in the main organization, but now in the R&D context. Another one for the onshore, and there we are. Another organization with multiple projects and also two projects again. We have multiple organizations. We have multiple projects now. We go to the original one that we created, and we select one of the projects, North Sea Data. Let's start working with that project. Let's start creating an instance. Let's say that we have never worked with OSDU yet, we really want to test it out. Let's set something up where we start testing out and working with the data ingest into the platform. We're going to set up a completely new OSDU instance. As you can see, we can choose between AWS and Azure. We set up something in Azure, provide a quick description for it. Once we start creating it, in this case, it's going to be created in a couple of seconds. Why is it done in a couple of seconds? Because it is an area in which we have OSDU instances running already. If it's on a region that is completely new in our first customer there, then it can also be created, but it's going to take a little bit longer. Like I said, we have a test environment for ingestion. Let's create a production environment as well. Once we're happy with the ingestion logic, we can start uploading our data into a production environment. In this case, we're doing it on AWS. We have a couple of instances running. Once we have the instance running, we want to have data in there as well. We're starting to test our ingestion. In this case, we have a Kibana setup connected to the instance. As you can see, there's no data in there yet. What is it that we're going to test? We're going to test a new schema, for example. In this case, we have enhanced the schema for fields with a bit more of a geodjagens shape format. We're going to upload that schema and we're going to upload a couple of wells into the system as well. We're doing that with an alternative ingestion pipeline, which is a tad bit faster than the native one. As you can see, we'll upload a schema. It takes just a second. If we upload a dataset with, what is it, I think 10 or 12 wells or something like that. We're going to upload sample one here. Upload the records. It's also processed in a couple of seconds. We go back to the Kibana setup. We can visualize the data that we have just loaded. Kibana is a system that refreshes every 15 minutes. We're now going to force refresh the data. As you can see, some data is appearing. We're going to resize the map, or at least fit the map to the data that we just loaded. As you can see, a field has been loaded. If we zoom out a little bit, there's a couple of wells that have been injected into the system as well. As you can see, we had an Azure setup here set up in a couple of seconds, uploading the data was taking just a minute or something or something like that. It's easy to set up an environment and quickly toy around. Let's say that with this new schema, we're happy with the ingestion results and we want to redo that for the production data, but with a different dataset. We're going to go to the production environment. As you can see, that one is running on AWS. We're using this file manager to upload the data. We're going to pick exactly the same schema again that we enriched the system with. There we go. It's taking just a second as well. We upload the sample so this one is with different data. Another field, another set of wells. Also in North Sea, so again a Kibana setup that is connected to the OU instance. We force refresh again. Now it looks kind of similar until we zoom in. As you can see, there's a field with a different shape, actually with wells inside of the field. A couple of them around there as well. Of course, we can view the data side by side as well. We have the Kibana setup from the AWS setup and the Azure setup as well. This illustrates the scenario that Ramon just described. If you want to test out with your data, quickly set up an environment. Work with the data, work with new schemas and stuff like that. In our time frame, we don't have sufficient time to look into the APIs, into the billing aspects and stuff like that. There's a lot more to this platform, but this was the quick demo that we're rather giving. So thanks for your attention on that one. Ja, thank you, Michael. Also what we were not showing you in this demo at the moment is that apart from, let's say, creating the instances, you're also able to close down and shut down an instance or close a project. And then we start up a new one. So that's the flexibility that we bring with CGI Pivot. And of course, it's fully OVDU compliant or compatible with the APIs and the way of working. Just a short or brief use case or customer case that I wanted to share with you as well based on CGI Pivot. Recently, we have been executing a proof of concept with the Norwegian company London Energy Norway, where we use in this case specifically an hybrid version of implementation of OVDU. So a hybrid solution in general. So we had OVDU running in the cloud on CGI Pivot, as we just showed. On the other side, the company wanted to leave the data on-premise where it currently is. But being able to combine the data, the metadata, and make it searchable through OVDU, through CGI Pivot in the cloud. So we've been working with data sets from well-tops and well-logs from different applications, waar we had tremendous support as well from one of their current suppliers, Scott Mee, who with their barrel-off solution is able to synchronize data between different locations and then provide the index to our... and the metadata to our platform. And with that being able to do analysis or search for the data through the OVDU platform. We've done that in a, let's say, a specific way of working, where in six weeks we executed this proof-of-concept. Sorry to interrupt, you've got two minutes. Ja, I'm also, thank you. So, from the business case in the first week, to finding that in more detail, setting up the infrastructure, all the way to at the end showing the results of this proof-of-concept and demoing that to the business, we've been able to do that in a standardized way of six weeks. And that really showed that both OVDU is a very powerful platform. And if you build it with CGI Pivot, you can immediately start and execute such a proof-of-concept in a tremendous less amount of effort. So that's what we wanted to share with you today. Thanks for your attention. I hope you enjoyed the demonstration and the presentation, and it was a very good view as well. Thank you very much.