 Okay, welcome back. I think we'll get started here in a minute. So we perhaps had a bad precedent with the long break to start, but I know there's a lot of catching up to do, so thanks for spending time. So this is good. We're gonna start with this session and talk a little bit about, again, I mentioned kind of a theme for today about what's been going on. So we'll talk about this focus on a capability-based organization and sometimes you hear it called a pivot, but really what that means is, and again, like I said in the opening, hopefully you see some parallels and the work you do inside, but it is this focus on value streams, right? And it is how do we really deliver value to our community and the way we deliver value to our community? Of course there are many, but the primary is through working software, right? We ship that platform every 10 weeks or so. That is really how people encounter value. And again, you may notice from your internal organization, but we have a tendency to organize functionally, right? And so these functions are oftentimes deep specialists, which we need, critical part of the journey that we have here to come together and do this work, but sometimes you can kind of sub-optimize for that value when your deep functional expertise kind of cuts the other way. So that's the notion of a pivot. Sometimes we showed a picture that kind of shows the typical kind of matrix-based organization with kind of functions running down the verticals and capabilities running across the horizontals. And that's really what we're talking about. And we have been talking about this for a long time. So I think that's the other key here is that this has been something we've been nudging and nudging towards. And I think good teams have come together recently to do more work around this and help us, help teams basically get there. So excited to talk about this. The case for change, if you wanna understand more about why we are doing this, like I said, the really why are we here? For many of us it is we're here to deliver a platform that can run business workflows on top of it. And so hopefully that's intuitive, but it's important to kind of hold that in your head because sometimes you can get often quite lost in the work and understand why am I here? That is why we're here. We know we have a strong platform that's here today, but that we need to focus on value, like I said, and as we focus on value, how can we help streamline our ways of working? Which as many of you know, working in a community can be quite interesting. We've not got handcuffs on any of you. You all volunteered to come here and spend time with us. You all volunteered to do the work that you do. So how do you get all those people who take different kinds of value for themselves out of our community and get them to give us the value back? So we've been talking about this and maybe sometimes operating model is a strong word, but if you were reorganizing the company, you might talk about an operating model. And it really is, what is our community model and how can we set ourselves up? Not just for the success we've already had. And again, to Steve's point, a lot of other industries watching what's going on with those to you and saying, wow, that looks like it works, but how can we build on that success and keep going forward? So we believe that evolving our operating model to optimize the path to deliver value will create more streamlined ways of working and that'll help increase adoption of the platform. And I think also it should make it more, it'll make it easier for you to do the work. And so I think we have these conversations a lot. It's hard to get engaged. How can I contribute to something? How do I get started? So we believe by creating this focus or continuing to nudge in this direction that this will help. So these are, the vision's not new. And I've often said a stable vision statement is something that we should all be very comfortable with. Is that we know we're aimed at the right problem. So I think you take a lot of comfort in the fact that we have figured out that there's a large and difficult challenge, that no company can really do this alone and that we have to come together to build this platform. But then we've really started talking about taking an outcome-based approach. How do you pull that apart? How do you start to create some real outcomes that can focus on this vision? So we've got a few up there. And I think, again, it's really focusing on these platform capabilities as things that enable workflows, that enable us to adopt the platform for these workflows. And then some other dimensions as well that you may not think about that really, we want a broad and active base of contributions from across the industry. And we really want to make sure that our partner ecosystem is also engaged in this. So I think Paul said it, this is a team sport. That is the case. Chevron believes fundamentally the same thing. No company can do this on their own. Just not gonna happen. So with that, I'm gonna turn it over to our esteemed panel. So we're gonna call an audible here and do a little bit of a panel session. So be thinking in your mind, Q&A, because I think we will get to that point. But I'll just introduce them. So you saw Ian Betts up here on stage. We have Dave Butcher, Jan Jepsen, Martin Quantroll, and Oivenberghoff. So we're all going to take you through some of this work that has been done on the operating model. And again, everybody loves pictures. So this is a new picture-ish if you haven't seen this, but talk a little bit about what this means. And again, evolution, not revolution. And also I think talk pretty candidly about some of the stuff that's not quite figured out. So with that, I don't know who I'm turning it over to, but some gentleman here is going to take us through the start of this picture. Just a sound check, it's okay. Very good. So maybe just a little bit of background on how we arrived at this and why the five of us are sitting here staring into the lights and not quite sure how to approach this. On the top right of the slide, it says very clearly this is work in progress. So this is not something we're trying to launch on you and tell you this is how we should work. It's the outcome of a two and a half day session that we had together in Paris when the Data Definitions Workshop was happening recently. And so we spent quite a lot of time talking about what works well. There's an awful lot of things that are working well. You know, you heard Paul mentioned in his keynote the fact that we're shipping a new release every eight weeks or so and we're delivering functionality that really matters. It's clear that lots of things are working really well, but it was a discussion around what could be even better. So it's not criticizing, it's just saying how can we take things to another level? And we spent two and a half days talking about examples of what works well, what could we think could be different and better. And it came, we quite quickly realized that what's difficult is framing all the things that we do in something coherent so that when I'm working in the forum I can see my place within the community and I can see how I interact with other people. So if I'm dependent upon things or people, where does that come from? If other people are dependent upon me, who are they and what am I producing that they're then going to build on and use? And so after probably two days of deep discussions and please bear with us because we're trying to convey two days of deep discussions in 10 or 15 minutes of presentation, we arrived at a framework that we thought, yeah, okay, that starts to have most of the important elements built into it. And what we're gonna do is we're gonna talk through some of our thinking that's in there, try to be clear what's existing, maybe try and point out some of the things that are maybe there but not working as well as they need to. And then we're very much using this as a chance to test the pulse of the group. So we want to get through our presentation pieces quickly as possible and then we are looking for Q and A. So we want to get feedback, is it a pile of rubbish? Does it really not resonate with you at all? Are there bits that don't resonate? Are there things that are clearly missing? We think we've covered most of the bases and so the dialogue starts to drill into those things and say, well, maybe it appears to be missing, but we've thought it through, then it's a communication gap. So if the ideas are there but not presented in the right way, that's also quite likely. So anyone who wants to jump in, please feel free. I can kick off or? And I would say it's very important that we look at this as we need to test it. We need to be agile. We don't know how it will work out of the bats. So let's start with something in an area, see how it flies, apply what we do within the community and maybe we do it good enough, then it's fine. Let's continue. If we see places we can improve and we agree as a community to improve, let's do it. I think that's the mindset. So we're not trying to impose anything, it's like stimulating us to be better as a community. I think that is the thought, yeah. Maybe one other thing to add is that we didn't really come up with all this completely on our own. We had a great support from Sapne and James sitting over there from ThoughtWorks who came and sort of sometimes poked us in when we went too far down a street with no ends, then they kind of pulled us a bit back and gave us good insights to how industry practices. So that was really, really helpful. I think one of the things that James and Sapne brought to the conversation, which we've touched on, we're trying to do some of it or we have been trying to do some of it, was this idea of portfolio management. It's on the right-hand side of the slide. In my view, we're not good enough at articulating what do the required components of this thing look like? What are we all working towards? So we have the vision and mission, that's all good enough for us to align behind, but more specifically, what do we all need? Not just the operators, but what does the broad church of members, what do we need for this to be successful across our industry? And if we can paint that picture better in terms of the portfolio of things we work on, then the rest of the machinery should spin into action more efficiently, more effectively. It should be more pleasant to work, actually. That's a key part of this for us as well, was it's not just about the what we work, it's how we do it. Sometimes it can be really quite clunky to work in the forum. I've put a ticket in AHA, no one's looked at it for three months. That doesn't encourage me to do more. So why are things getting stuck in the way that they do? How do we unblock things and allow things to move through the processes more quickly, more efficiently? I think we went, I think that was an area that we sort of had a bit of a sort of discovery and AHA moment, actually, because I think we went into it. You know, we talked at the October event about aligned autonomy and we were thinking more around the delivery model and the capability of the platform. And I think that was an area that we did spend a lot of time on that. I don't think we went into it thinking more about that and we did end up talking a lot about how do we tie that vision down to delivering capability? And it does come from having that portfolio management and then into detailed workflow requirements, both from informing internally down to those teams, but also how do we pull members into the community? How do we pull in more contributors? It allows us to sort of inform back to ISVs and operators what we're doing in real terms. I mean, as Paul said this morning, he said ultimately it's about delivering value and how do you go from high level value to sort of quite abstract elements of data and delivery mechanisms? You know, it is through portfolio management and workflows. I think you can tell that this hasn't been scripted or rehearsed, so bear with me. What I think a few of us were speaking before coming up here and sort of looking at the desk layout and one of the things we've really talked a lot about is wanting the OMC not to be this sort of glass ceiling overarching sort of leadership style body but to actually be active working amongst the community. So I think part of this operating model is to bring far more sponsorship. And I think we can go through this model in a little bit more detail in a minute. I don't want to paraphrase, I don't want to repeat what people have said, but I've got some notes I wouldn't mind talking through. So again, the purpose, right, why are we all here? Patrick talked earlier about adoption of the platform wanting to drive an enterprise product, right, enable us to scale it out to our industry. This is really key for us now. Becoming an effective digital enterprise solution. What we want to be able to help with because there's been a huge amount of effort, great work. This isn't about a number of us new people coming along saying, right, you know, we need to do this better. It's about how we can evolve, how we can help the community advance at greater pace. Improve ways of working where we can, the structuring, to release that value. Listening to Paul earlier, I took some, it's really, it's always interesting when you hear a different company's perspective and some of the different language. So I think we're all shooting at the same objectives, but just here was great. Finding, accessing, trusting, benefiting from data. Enabling better, faster decisions. Easily discoverable, frictionless data access. New AI, ML opportunities. Auditability and lineage. The underpins, important investment decisions in our businesses. Keeping data secure. Autopublishing and results, I like that notion. Removing data silos, these are all things that we know, these are all outcomes that we are chasing. Having a review of Jono Bacon's book last night, one word popped out at me and that was meaningful work. I don't know who's read the book and we'll hear more tomorrow, but that meaningful work piece I think is so important. It's the purpose. Why are we all here? We want the community to be healthy. The community, I would imagine, wants to feel that you're all benefiting some outcome, right? So what does that mean in terms of the work we're doing? Is it meaningful working in support of a purpose? What is our purpose? And I think the key thing for me and I think this team is bringing more purpose to the collective community, so that alignment. What is the North Star? Can we be less ambiguous? Can we be more clear about the types of business outcomes that we want this community to help us achieve? So some of the themes on this operating model around governance and transparency, how we work, enabling more discovery. So being clearer than maybe we are on the types of business capabilities, and we talk a lot about business workflows. So the actual impact we want to create on the business by providing the platform capabilities to support those shifts, improving our delivery structures so we can speed up the delivery of code, the expansion of this data platform. What we can do about sponsorship. So we've heard a lot around, we're not clear on what people are looking for and we need some help, but the committee isn't necessarily providing that help. So what more can we do to help you all? What about the investment side and the people side? So I think we're here shortly from some of the example work that's happening and some of that feedback will talk around the lack of resource, the lack of people, the lack of expertise to help us meet the objectives we've got. Clarity of key roles and responsibilities. So as we make this change, we introduce slightly different ways of working. Does that bring new roles? And some of you would have heard about capability leads. I think that's something we really need to discuss in more detail. What does that mean? Why do we think we need this? And very much focusing on the value. As always, process is important, but the value is key here. Do we wanna go around the operating model, I wonder? So there's a few more slides. I don't think there's a need to drain the slides, especially if we wanna make this conversational. So I think we would be remiss without, again, reminding us that we're building on a lot of work that's come before us. So for those of you who work with Nick, pick us who can't be here. A lot of this work has been in progress, as I said, for quite some time. So it's building on the work we've done, and I had an opportunity to work with Nick before he was working in the forum, and he's helped us do very similar things. It's a unique skill set, but understanding, organizing for value in a software organization is challenging. So like Martin said, I think we need to wrap our heads around. What does that mean, and how exactly do we get there? So there's a couple more slides. I don't know if I'll just click through them real fast and then try and turn it into a panel if that's okay, but really it comes down to cross-functional teams. And so if you hear that word, but don't really feel it or know what it means, it really does require us to come together to work on these problems, right? It takes a village. And so making sure that we, as I said in the beginning, don't get over-indexed on those kind of functional silos that we bring people together early, that we have these conversations together early, is really the critical piece. And sometimes, unintentionally, I think governance structures get set up that reinforce a siloed way of working. So we just need to keep our eyes open and encourage teams to gather this way. And as Martin said, we're going to quickly have some examples of teams that are already doing that. This is it. This basically says there's already many good examples. Here's a couple of teams that are starting to work this way, but I think they've learned a lot, and you'll probably see in some of the presentations today some of the things that are working well, some of the things that could be working better. And that's good. We need to be talking about that. I remember Jane in the last one, it's like, I think sometimes you have to force people to talk about the good stuff first, because they tend to, we tend to be a room full of problem solvers. We just want to jump into what's broken and what's not working, but also taking that moment to say, yeah, there are some things that are actually working okay, is good for us too. So I'll tee up a softball to start, I hope, because I think I already heard some folks describing it, but maybe I can go back to the picture as a guide if people want to use this to throw questions out here, but my first one would be in a, because I heard all of you talk a bit about it, but maybe in the concise way, what problem is this solving? In my perspective, just as an example, we're doing an interoperability project, we're going to present that tomorrow within APNOR, focusing on a workflow which is seismic interpretation, sorry, that sounds like it again. And then we're really trying to utilize the platform, how can it be operationalized? How can we actually take all the Lego bricks, which is very good that we have, put them into something that delivers something end-to-end and a value for the business. And I think to kind of build a capability around not the competing side of that workflow, but the 60% we need to get the Lego bricks to fit a bit better together than they maybe are today. Many of them are really playing together fine. Some of them have some challenges. Some of them have even a bit more challenges if you're really looking at an interoperability perspective where we say a whole industry are going to agree on data formats and APIs. We're not going to solve this in a short term, but the capability is kind of saying, well, we're all trying to have this workflow. The 60% of it is probably non-competing. It's equal. Let's put it out there and try to set it together. Then you get the whole flow going and you can see what is missing. Where do I need to pitch in? If this is very valuable for me, where can I put my resources in? I think that's my take on it. Very good, thanks for that. Any other responses? We want to take one from the room. Yeah, I can perhaps add to it. I think what Owen is saying is that value comes from piecing the bricks together and what we see and what we have learned, in, for example, in Total when we try to use the platform and integrate with it is that there are small gaps. When you really map a workflow into it, then there are small features in each of the capabilities which are maybe not working super clearly or it's not very easy to use. And the idea of having these workflow analysis is not being able to tell people what to do, but more have software developers involved in speaking with the platform teams to understand what are missing or what is clunky, what could have been done better and have a conversation around that. And in case where the existing teams are actually, we are not able to do this because it's not in our interest or it's not in our, you can say we don't have the resources, then you can have a conversation around, okay, so how can we help you? And I think that's one of the things which is happening today, but it's not always happening very open and transparent. And if we can facilitate that, so it happens much easier and is less dependent on individuals, then I think it would be very helpful for the community. Well, I think, I mean, one of the challenges now is we're really moving into this adoption phase and that's when it becomes real and that's when you do have workloads you need to move and you do have existing tool sets and applications and that's where we're starting to see activity now. And I think, again, back to mapping those detailed workflows. So rather than talking about data, and in fact, I was talking to an old colleague who represents a large operator here, they're not very active in the community and he just said, don't talk to me about data, talk to me about workflows. So again, it's that translation into that world. I would say driving up business decision quality and improving business productivity. So I think if we can provide easier access to trusted data, that, for example, improves subsurface uncertainty, enables a better business decision and a quicker business decision. Paul mentioned that earlier, and the sort of productivity side by linking, integrating, tooling that we use across our workflows to talk to each other in terms of the way that data flows and needs to flow is gonna dramatically improve productivity. And the other piece is the innovation in the marketplace as well by standardizing this ecosystem will drive a huge amount of innovation and disruption. So I'm gonna nudge us towards the room, so we don't have to spend all the time answering my softball question. So we have one up front. Hi, Jamie Cruz, SLB. Quick questions. So this sounds very exciting there. Just wanted to ask and maybe the information's out there and I just haven't read it yet about the portfolio management and something you just touched on as well, Martin. When we're working with people, one of the biggest challenges in data platform and data investments is tying it back to business value. And I think there's been a real consensus building over the last 12 to 18 months since the Mercury release that one of the most powerful things we can do when we're deploying OSDU is to always make sure we're asking the question for this investment that we're making here in the data platform, how does that tie back to business value? And that's very different perhaps from when we were building corporate databases in the past where we were just happy that we were storing and keeping data safe and all of those things, right? So is the scope of the business capability group and everything else, is the ambition to be able to capture these use cases and provide examples like concrete examples so that somebody that's starting up a pilot or something like that will benefit from the experience of the earlier doctors so that you don't start from a blank sheet of paper. Because I do sometimes feel like that when we're doing projects, everybody's having to work from first principle so it'd be really good if these use cases, if you like, became surfaced. And maybe in the past, we didn't do that because that might have been perceived as being in the competitive space or whatever it is, but is there any opportunity to start capturing those use cases? I think that the, yes, absolutely. And we're just starting to figure out how to do this. So we've had the BCM team in place for about two years now and we've done things like the survey of interests and we've got a good idea on what our priority should be. This, I think, is supercharging it and taking it to the next level, breaking things down into, if we understand a workflow has 10 steps, which of those steps are enabled by something that comes from our SDU data platform? If it's only two of the steps, which are they and how do we really double down on getting those things right? If we've got examples from operator and partner experiences we can use to learn from, that's fantastic. We have to be really careful about when we get towards the business value was X million dollars. But we have all the right protections to keep us safe. Sharing the experiences and learning from those, generically, that's what we need to start doing in that space. Perfect, thank you. And just to comment, Jamie, as well, it's also, I think, oh, it's you where we are, not where we are now, sorry. We've been on it for a while, but actually many of our oil and gas companies, we're starting to utilize it, we're taking value of it already. So it's not saying it's not mature, but when we're looking at the next step, that is really bigger workflows and more interaction between disciplines, we need to bring that in towards you. And it hasn't been up to now, it's been more focused on data types, can you find it, can I index it, can I use it, can I do a data science thing? It's there, it's bottom up. Now we go from the workflow and trying to do that, and that's the challenge. But we need to address it totally. I think Jamie just said, I think it's critical. I think it's the cost of capital increases and the competition for investment money increases in our businesses, right? Without these examples, and they've got to be more than anecdotal, and I know from my own house, there's a bunch of beebeers in the room, we spend a lot of time thinking about value and how to describe it, and working the cases through the investment, governance cycles, it's only gonna get more difficult, I think. So if we're able to share, albeit possibly anonymized, some success stories in the industry, that would be very helpful, I think, to all of us. Got another question in the room? Hi, it's Mick Bass from the 47-lining Hitachi team. As we shift towards adoption and more enterprises have strong dependencies on the capabilities in the data platform, there's also, I think, a shift to a mentality of stability, maturity, readiness, and being able to discern between capabilities that are stable and ready and have been demonstrated in workflows as compared to those that are still in the innovation space and being proven out. There's like a strong lens of engineering and operational improvements as compared to incremental feature development and some explicit trade-offs there. In the operating model that you're brainstorming here, how do you think about propagating that concept through so that as people are releasing and beginning to use the data platform, they can be safe in their deployments and further so that the ISV ecosystem who are encouraging to invest in adopting these capabilities can have confidence that the capabilities that they're investing in are stable ground? Dave? I'll think about a first piece there. There was many things, Mick, in that that we could unpack. I think one of them for me was around the stability. So yes, we need to have confidence. We all need to have confidence in that this mechanism delivers things which are understood and where we're taking risks around delivering new functionality that they're well-managed. Currently, I think we could be a bit better at making that transparent. That's a large part of this model. How do you make the dilemmas transparent and known so that they can be risk-managed? Hopefully that's one of the things that this would bring. And also bringing that those challenges we have each as an operator. We're in an early production and we're moving into all of those things. So the more of those things we also can bring into the community and discuss as a community will help us driving forward. I think that's my go-in statement as least. So let's get it on the table. Yeah, I think Martin said it earlier, but we've talked about these capabilities as kind of the linchpin of making this model work, which really is to say, I think most people have a general sense of capabilities, but there's a list. There's a set of things that the platform does and having leaders in that space to help us guide those kind of conversations to make sure that we are prioritizing sometimes new features versus sometimes stability. It needs to be a leader-led conversation or at least a community leader, which is a very different kind of thing. It's not someone who's telling, it's really someone who's serving and facilitating but is able to have those conversations. So it maybe is feedback from me on the picture. It doesn't jump right out, but again, these capabilities and agreeing on the list of what those things are and what we call them and then helping to raise up leaders from our communities in that space is a critical piece of this. Because I think the other piece for me is you can enter this wheel from any of these stages, that's okay, but naturally, I think what we're gonna see is to that discussion on workflows. We've been trying to have a workflows-based conversation basically since the beginning, where it often gets tripped up is then who breaks those things down into what I would always call the difference between business requirements and software requirements. Who's actually gonna pull the software requirements out? And that's usually where it falls short, right? And it is understanding then our contribution model and all these other things to understand how are we really gonna pick these apart so that we don't end up having a very long and detailed conversations about workflows that then just hits a brick wall when it doesn't go anywhere. So we did a workflow analysis left by Hink this last autumn, about seismic interpretations. And I think one of the learnings from that was exactly that we were actually missing, you can say the software developers who turned, you can say those requirements into, oh, I'd say the workflow into how, what that application needed from the platform. And I think this is what we want when we say requirement specification, that's what we mean. It's not saying that you need to deliver this, but it's turning it in from a data and business perspective into what does the capabilities in the platform need to deliver. So that's one thing. Around the other thing, the stability, then in the capability ways of working, there are various types of initiatives around creating, let's say, a more stable component. And Jane is pushing forward or leading the drafting of capability maturation process. And so as that matures, and I guess it's fair to say that it's in the early days, supposingly being going to be tested with the rock and fluid sample DDMS, at least that's being discussed, I know, then that will bring that stability. But that's one component we are trying to test it on and then it will need to be broadened out. So that's something. And I think it's worth to say that today, we actually don't have any certified or any components or capabilities in the platform which has reached the level of standard. So everything is experimental, if you like. Some is more experimental than others. But that's kind of the fact where we are today. And today is really based on when you adopt, then it's an individual decision by the company using the platform whether they want to take the risk of using it. That's how it is today. So it's been, it's gone fast. We're gonna add one more. I'll give you one more if you wanna. See, Kate's got the mic. Oh, well, I was gonna say, I think we're short for another question. I don't wanna steal from the break but I would offer you to pin any of these folks down at a coffee break and ask the same question. So sorry, Keith, but we'll move on so we don't steal from the, one more, please. So this is not a top-down tell and it's work in progress and we need your help. And those that are not in the room to work it further. So how will we do that? We're gonna move all of this work into the business model working group going forward. So this is a shameless plug to come and join those meetings on a Friday afternoon European time and contribute to making this working fit for purpose for all of us. It's not gonna be five or six of us cooking it up on our own anymore. We've got lots of other things to do as well. We need and we want your help. So if you've got passion, experience, desire, please come and work with us and help to mature it. Yeah, thanks Ian. It's a Friday morning coffee if you're in the States and yeah, I count no less than five exclamation points on this as work in progress. Just to be clear. Very good. Okay, well thank you to the panel. So thanks for the questions. We appreciate it. Thank you. Thank you.