PegaWorld iNspire 2024: Vodafone Networks, Intelligent Process Orchestration, Harmonization, and Automation

Hi. Good afternoon everyone. Uh, thanks for attending the session today. I have the privilege and honor of introducing, uh, Ben Cuthbert and Mark Pocock from Vodafone, who are going to touch on, uh, Vodafone networks, uh, with Pega and intelligent automation with process orchestration. Um, please, could I ask you to switch off your mobile phones, or at least put them into silent and we will be, uh, if you've got questions at the end of the session, we'll be happy to take questions, but just please them. Hold them to the end of the session. Without further ado. Um, Ben and Mark, thank you very much. Great.

Thanks. And, uh, hi, everyone, and thanks for joining us. I know this is, uh, straight after lunch, so hopefully you didn't miss dessert to come and come and see us. But I'm pleased that you're here. Anyway, um, we got a really exciting story to tell around. Not only what we're doing with Pega, but also evolution of Vodafone and particularly want to take you through kind of our bit of our history, how we're, um, actually approaching intelligent automation within Vodafone networks. And also we're going to show you a couple of the use cases that we've actually done to deliver some value back to our organization as well. So I'm going to hand over to Mark initially, and Mark is going to take you through the sort of history of Vodafone and also what we're what we're known for and what we do for our customers. Mark.

Thanks, Ben. Um, so very conscious that not everybody here necessarily knows who Vodafone are. So we start with a bit of a story, I suppose. So we leading European and African telco, um, 330 million customers. So T-Mobile we're talking about being the most valuable. We like to think we've got the most customers. Right. Um, we're running as well, one of the world's largest IoT platforms at the moment, which is part of the evolution, the drive behind the continuous growth and the technology transformation within the within the wider organization. Um, the organization within Europe, um, we are what is the largest 5G network in Europe ?

We're growing our super fast network at the fastest rate that we have done for many years now. Um, we've talked about the IoT side. We're also running a fixed business as well as a mobile business, and we are the largest pay TV entity within the German market as well. We've also got a large presence within Africa. We're a fintech organization within Africa. So M-Pesa started out in Africa a number of years ago. First time I got involved with Vodafone was actually go and look at how we were operating on the M-Pesa systems in the countries. This is really something we're very proud of. It's about turning what is effectively an unbanked economy into a banked economy, and using the power of the network to connect individuals and really empower it.

Well, what is quite, quite a significant cultural change within the African continent. So where are we now? If we take a step back as Vodafone, our strategy and our goals are pretty simple. Really. It's about driving the best customer experience. It's about becoming the number one place to work for our people. And it's also about bringing together a conversion network across our different markets. We talk a lot about what is now customer simplicity and growth as our three key drivers. And the transformation really started over two years ago, three years ago in this general direction.

So the big question really, and getting on to I guess the meat of the conversation is what's the problem? Okay, so if I take a step back into Vodafone's path for a minute, 1985 first mobile call was made in the UK and that was on the Vodafone network. 2000 largest global M&A deal at the time ever. When we purchased Mannesmann in Germany, which was a huge effort and consolidation on the back of that. What that means is we're in our mid 40s just about right. So we're going through a bit of a midlife crisis is probably the best way to describe it. Um, I, I kind of look at this and think, what happens to all of that age? We reflect, we step back a little bit. We look at the complexity that's inherent within the organization, within the network's business.

This really shows up within our OS, sitting behind the technology that runs the networks. For those of you who aren't telco experts, um, the way I would describe it would give you some numbers. There are over 1200 systems tools supporting the OSS across Europe, right? So we're running a major consolidation program at the moment. Um, taking out what is just shy of 50% of them over a five year period. And that means that what we really need is some way of consolidating that. So that's 12 markets working across those systems. It's a set of processes that are disparate. If you look at how we go around network deployment, it's different in every single market.

The tools and systems that underpin it are different in every single market. So our processes need to be simplified. That's part of the simplification agenda. Um, we've got duplication in different markets with individual CEOs. See, CIOs who have their own home grown, home developed set of tools, set of processes. They're bought into the way that they're working currently. Um, it takes a significant amount of time, therefore, to fulfill a number of core network processes, right. So it bluntly takes us too long to deploy network. 5G rollout is not where we would like it to be from the point of view of progress, partially because of the complexity of the underlying system, it's really difficult for customers to see the progress of some of their challenges within those different markets.

And the operating model has been going through a significant consolidation over the last three years. Yeah. What we did was we introduced verticals, which a lot of the telcos have done network deployment, vertical network quality, vertical network operations, vertical strategy and engineering vertical. And we sit within the engineering function. So our role is really to support the business who need to understand clearly what are their processes, what are their workflows? How do they deliver value in the deployment of that network? In understanding the performance of the network? Where to put the new assets to drive better customer outcomes. And it's our job to then turn that into a reality for them to build the tools, systems and processes to make that work.

So, Ben, do you want to take us through? Sure. So, um. Thanks, Mark. And, um, as you can see, Mark's highlighted. There's quite a lot of opportunity and, uh, that we can drive forward here. And we are particularly proud of the actions we're taking at the moment, which help us distill really all of the goodness out of our legacy, different organizations, different markets that we've been working across for the, um, for the last however many years. And we are particularly focused on understanding where we can find commonality and drive singular processes where possible, where where we've got common, common goals, common outcomes that we need to achieve. So we're distilling all of the different processes across markets and trying to find that one best way approach of doing, um, network deployment, network fulfillment and so on.

Um, we got to remove some of the waste and some of the legacy in order to do that, in order to do that well and efficient, a good price point. But we're well into that journey now. And, um, that is also a very much a prerequisite before we do technology transformation as well, from our perspective. Um, and also we've got to make sure that whatever we do, we still can be flexible enough because we do work across lots of different markets, different rules, policies and so on, that we can still cater for that. So we don't want to simplify to the level where we're inflexible. We but we do want to be able to simplify enough that we can actually do things in a more coherent and joined up way. So in terms of the tools, we obviously we're in the market some years back in networks for some something super flexible that can cater for all these differences, but also help us incrementally build on our processes and technology and capabilities as we move through time. And really, that's where Pega for us came to to be utilized in networks. And we've been really driving processes, um, into Pega and from Pega ever since, making use of things like the Layer Cake.

And as Mark alluded to, you know, we're going through our own transformation internally as well, with a operating model, changes and ways of working changes. And with that, we've adopted agile and delivery of our engineering and process change comes through agile approaches. And Pega lends itself super into that as well. Um, what we do want to do in terms of, uh, providing our technology to our staff is make sure that the interfaces they get are now are familiar and common, and they can recognize them so that when we do deploy new processes and change that, they actually recognize from the outset. And I think Constellation lends itself really well to this as well, which you may become familiar with if you're not already over the course of the next few days, is you start getting that common approach to UI, and you know how people see layouts and screens and, you know, it just feels familiar and more usable. Um, and then we very much incrementally just want to drive forward at our own pace, but also at the right pace, depending on the value of, of the change. That's, um, what we're delivering. Um, we very much recognize that we have processes which are across the spectrum of maturity from our perspective. And the ultimate goal for us is to move towards more autonomous.

And I know Alan mentioned that this morning. And absolutely, our goal is as well, we don't want to be having humans working on mundane tasks or things that they shouldn't have to spend time on. We want them worked on working on the most important things, the most complex, and where we really need, you know, that that human touch to, to make a complex decision or, you know, help us drive the business forward. Um, with that in mind, we now start to understand the measure where we are on this scale. For us, it's really important to make sure we have that foundation in place. So having a managed process well orchestrated within something like Pega a digital bedrock almost. And then we can incrementally add capabilities on top of that so that we do move up that autonomous scale. We don't, though, think it's a good idea just to go, oh, you know, GenAI, let's just see where we can apply that, even if we don't have that strong foundation in place. So there is definitely a set of steps that we should consider if you haven't already.

And you're looking at this kind of thing, making sure you've got some of those prerequisites in place to move off on safe footing. And then for us, we definitely would like to introduce more capabilities over time. So where we have got a good foundation now, we are definitely looking at how can we apply some more of the especially in the Pega 24.1 that's just come out. How can we apply some of that and more sophisticated AI and machine learning and so on into our processes? We're going to talk through now a few examples of oh, sorry. Actually, I'm going to tell you about how we actually use the Pega technology before I go into the examples. But the key three areas for us that we're using it is in intelligent capture. So intelligent capture for us is all about how do you get the right information from the people that want a piece of work done in the right way, ideally in the most real time way possible, and ideally in the most structured and easy to deal with way possible. So we don't restrict channel though.

So if there's stuff that needs to be originated in emails, that kind of stuff, because we have a lot of third parties we deal with and so on, can't always expect them to use our interfaces. We do make sure that we can still handle that , and Pega is ideal for that for us. Um, second, then orchestrating our work, we make sure that we can leverage Pega best in class capabilities from our perspective in terms of workflow and case management, and we make sure that we can get people the right work at the right point in time in the process, and making sure that things like approvals are managed well, decisions are captured and audited. And then finally, how do we make all of those all of the work that's flowing through our workflows? How do we make them as autonomous as possible, leveraging those capabilities have just talked about? Now we'll go into some specific demos and examples. So the first example I just want to talk through is around how we in networks have been managing our unit costs controls. So anybody that knows networks you'll know this Probably our biggest capital expenditure that we do. Deploying our network costs us hundreds of millions a year.

And within that, um, there is a lot of room for costs to spiral out of control if you're not careful. And mainly that's because we're dealing with huge amounts of third parties. There's lots of variation in terms of sites. Some sites we have to dig up brownfield, dig up new sites and so on. Some sites you just put in a, you know, a mast on the side of an existing building, much more simplistic, but within that there's huge amounts of variation. And what we did find, um, a couple of years back now, is that we had, um, on average 25% year on year variation in our unit cost controls. So it's a significant challenge for us. And it's not sustainable for that to go up in that in that ratio going forward. Not without um, not without good reason.

And in many cases we weren't finding the good reasons there. So what we did is a traditional really re-engineer root cause analysis. Have a look at the process. What's going on, what detection points have we got in place, what controls and so on. And initially, what we found is that most of the checks were manual if if done at all, because of the scale and sheer number of things like purchase orders that were being asked for. Um, we essentially couldn't, couldn't apply a manual check to that, that kind of volume. So we had to start looking at what we could do to automate some of this. And the unit, the unit cost really materializes in the purchase order process. So if you think about the process itself, for us, this is where third parties really are requesting money from us to deliver a site for us.

And in the example that we're going to talk about here is usually they would send us a request via an email to say, you know, you need to raise a purchase order for this type of materials because this is what we've got to deliver for you in this particular site, and this is the cost. And they, you know, they would almost tell us the cost. We would then typically look at if it's within the sort of thresholds of that particular site type, and then we would either approve or reject that. But because of the detail within the actual request themselves, we didn't have enough capacity before to check each one. What we've managed to do with Pega is actually automatically ingest the emails that was coming through from our suppliers. And that as as Pega does, creates a case workflows that through. But what Pega is doing at the same time is going off to all our different catalogs and all our different information stores of where we know about different sites, what they should cost, the individual materials, how much they should cost and makes a recommendation immediately around. Is this within the tolerance of that particular site type, and should it be approved if if Pega detects that actually it's within the within the tolerance and is all good, we don't send that to a quantity surveyor. It goes straight through, then to a final approval and the purchase order goes out the door.

If it's outside a tolerance, the traffic light system goes off, goes red. It sends the actual case to a human, a quantity surveyor, and they are then instructed to do a more, deeper, deeper dive check. Sometimes there's genuinely good reason for the variation, but at least now we have a way of detecting those variation and understanding why that is, and then they can capture within the system. Do we approve that variation or do we reject it? And, um, just in in the last few years, year on year, we're saving at least 3% now of that unit cost expenditure that we had before, which I can assure you is a significant number. So we're very pleased with that. Um, I'll hand over to Mark. Now he's going to take you through the second use case. Um, but we can have questions at the end if you want to, and we'll scroll back through the deck, if anything in Thanks, Ben.

So a second use case is is really about demand management. So we envisaged that network organization. Right. There's 12 different markets operating. We've got a commercial business units. We've got enterprise business units within all of those markets. They are pushing significant new product development across all of our different sales channels. Um, and a lot of that ends up touching the networks business. A lot of that ends up touching the centralized network strategy functions, but also the network development functions within each market itself.

We took a step back, starting in the UK market, actually, um, and really asked ourselves the question, do we understand the volume of demand that is being driven into the networks network's organization, with that volume of demand that's being driven into the network's organization? Are we responding to it in a timely manner? Are we prioritizing that workload? Are we gathering what is effectively AV1 cost estimate from the network's organization to hand back to enterprise to consumer so that they can fully understand the potential of the impact of what it is that they're looking to try and do form their business cases, get costs, approval, transfer that work back into networks, and then trigger a delivery cycle within the networks business that can actually execute within the timelines that they're looking for. So sizable challenge started in a single market. We built a solution effectively using an MVP. This was this was one of the very first applications that was developed within the networks organization. Um, MVP one went out into the markets, uh, into the UK, and we sat back and very quickly started to understand, at a bare minimum, the amount of work that was being driven into the organization. Um, we then were able to step back and really understand how much of that was firstly categorized correctly.

So we started to use Pega to carry out categorization for us. We've started to. Indeed, we do use because it's deployed across all 12 markets as of this week in Germany going live finally. So additional security approvals in the German market that we have we have got that right. Um, we've got ourselves to a position now where, um, we have a not only an MVP that was delivered in the first market, but we're delivering more than 10% efficiency at the networks organization because of the time it takes to respond to these demands. We're channeling the demands to the right part of the business. First time to get the response that's required. The volume of rework has significantly reduced. We can now go into financial planning cycles on an annual basis with a clear view of what it is we're looking to try and do to service the product suites that sit across the wider business.

The case management rules that have been set up have taken us to a place where we're constantly evolving them. So we've got a team which Ben runs sitting out in India through our shared services functions. We're able to iterate and adapt to live business requirements. And as a result of that, we've got ourselves to a place now where what was effectively 4000 demands that we had no line of sight on coming into that networks organization, disrupting the plan that was already in place for delivering network site deployment, for delivering new applications, for delivering new systems and tools that we're able to actually turn around to our customers and give them a clear line of sight on what we can do when we're going to have it done by the cost of delivering it. And what is ultimately certainty on on the business outcome for the the business unit. Good. Thank you Matt. So another example then is around international network deployment. So for us this is quite a fascinating use case for me personally actually.

But um, recently we had an example where we were, um, delivering our actual network across the globe effectively in the international networks function. And um, if you I don't know if you've seen any of the news lately around, um, Vodafone's delivered its first subsea or the largest subsea cable, uh, on the planet, I believe, as I understand it at the moment. And it's this kind of international networks, teams that are working on those. Um, so and they had historically been managing their deployment processes with spreadsheets and really legacy technology across the globe, all continents, trying to really tie all that together, all of the different request types, all the different works and the stakeholder groups, massively diverse, different geographies, different continents and so on. And, um, essentially orchestration and really just visibility of the process. Almost impossible. Um, and what we found was you were you were needing extra people in just to orchestrate it, but also to process the work itself. Me just lots of manhandling. Um, so what we what we did essentially is started to re-engineer the whole process, but starting incrementally from demand capture and really putting a really strong front end on the process that's diverse enough to capture all of the information for the different markets, making it super dynamic because different markets have lots of different types of requirements.

So you don't want people filling in lots of onerous forms unnecessarily. We want it to be nice and dynamic. So it's very relevant to what they're having to put in. And then the real time element of this was, you know, super in terms of a benefit for, for this area because before they were sending spreadsheets and, you know, people were aggregating data and probably sending that once a week in some cases. Now we can do that at the click of the button. As soon as the request comes in, it's with the right people to start developing the the request and deploying that network capability as soon as it's ready, which is a massive step forward for them. Not only is it shorten their process, but it's also, um, it's saved a lot of money on that front. Um, in terms of the process workflow as well, we've removed a huge amount of waste and which which is excellent. And they have adopted that kind of one best way approach across the globe now as well, which is fantastic.

Um, so if you deploy something in, you know, in the African continent or if you deploy something in Europe, it's completely standardized and they're using the same interfaces, same workflows and everything else, which is really great. And the feedback is tremendous as well. But from a management layer, who, um, the management layer is all exactly the same. They can have a look in the workflow, all of the different requests that are going on, they can manage the budgets, they can manage the demand and so on. Um, at the click of a button in Pega, it's all there, ready to see. Um, and then on automation standpoint, this is still incrementally being built on at the moment because very much we're doing, as I said earlier, getting that that digital bedrock in place so that it's ready for further transformation. Release eight. Yeah we are on release eight. So and that sounds like a lot, but essentially we're releasing every two weeks these guys.

So we've got a huge, um, backlog over all the stuff they want to do over the next, however long that they want to keep going for. But, um, but we release every two weeks for them, and we're really strong in working together in a partnership. And they are loving the approach of releasing stuff every two weeks, even if it's just small things. Some releases are bigger than others, but, um , you know, they really see the incremental change to their business. Uh, and then, yeah, finally for us, the just the dynamic routing element of where it needs to go to somebody different automatically. I think that's been fantastic in this use case. And we're going to build on that in our in our coming, our coming sprints and releases that are coming up as well. Um, so finally then we just want to touch on where we're going next, and I'll let Mark talk to some of the use cases first, and then I'll talk to the patent. So it's really a question of where next.

And it what we started with is building out a series of point applications to solve specific problems where we've had business demand, and we're now moving into the world of saying, okay, we've now got use cases where we've proven the value of Pega as a platform, and the PaaS has been a successful investment. We've proven that we can develop using our internal squads. We built out that internal capability. What are the bigger problems within the network organization that we can start to address? Where are the real value cases that we can push the limits of what we want to achieve? Something that those of you in the, in the business, as it were, will be very familiar with. is the concept of smart CapEx. So for us, that is taking all of our network data and insight, pulling that centrally, and then we'll talk together a little bit more about strategic deployment patterns. And in a little while we pull that data centrally.

And then all of that performance data that comes off the probes within the network can then be utilized to start to understand when I want to make an investment, where is it that I want to put that investment that gives me the greatest return on capital? The best result from the point of view of removing detractors within the network. The challenge is quite simple. The challenge is not everybody uses a centralized smart CapEx solution in the way that you'd like them to in every single market, at every single different point, as they are building their investment plans. The potential solution to that is guided workflow and a guided workflow layer that as those investment plans are being put together and the optimizers who are optimizing the network are thinking about where they're going to deploy, They're going through a guided workflow. So they're being presented with solutions where they're having to determine, am I going to accept this? Am I going to deviate this from this? If I am deviating from this, why we start to really understand what's going on and feed that back into the GCP based central platforms. The other view of that is that we then take our smart CapEx investment plan.

We turn that into demand. So that links into the demand application we're talking about earlier, and that flows as demand into the networks organization. We can capture that automatically. We can then route that through to the right parts of the business to respond to the finance thesis behind it, build the business plan and then go into an execution pattern, which takes advantage of all the reuse that we developed through the international deployment solution. So so the effectively the point applications that we've been developing, the ability to reuse that set of capability, tie that end to end across what is effectively an investment journey, a demand management journey, a delivery journey into ultimately an optimization journey to optimize the network once it's been deployed, which is one of the other areas we're looking at, is really, really exciting. And we've gone from the position, what, three , four years ago where we introduced the platform as a PaaS based service, started with a single application that we're now having these discussions internally within the business, and we've got a clear line of sight now as to how we want to take things forward. Then. Yeah. So as Mark alluded to, really reuse is pretty much Key and King for me as well.

So within my area we focus heavily on developing things in a reusable way. And anything we build, we design it to be reused elsewhere as well. So uh, obviously unless it's can't be for some reason. But one of those things that we definitely want to make sure that is very, very strategic is the way that we interact with, um, our data stores, but also our SaaS. So as Mark alluded to, almost all of our data now is stored within GCP. And we can access that from Pega in a number of ways. But essentially we we don't intend on storing large amounts of data within Pega. And and but we can consume it at the point of need within either a process, or we can push data from our processes back into GCP. And we're setting ourselves up with a strategic connectivity and so on.

That allows us to do that at will across any geography and take and store data as necessary. And that's good for not only for real, real time processes, but also for analytics, data, uh, AI and so on as well. Um, in addition to that, we're investing a lot in our service busses and um, infrastructure integrations as a service now internally. So we're investing very heavily in how we can set up reusable integrations and how we can make sure that Pega workflows are can take advantage of reusable integrations as well, because anybody that's developed on Pega before no. Without integrations, it's actually quite hard to have an end to end process doing all the elements of a process on there. You usually end up having to defer to either a robot or a human to do the sort of last mile. Um, so we particularly want to make sure that we always have those connections in place, but also we want to set them up in a way that we can reuse them. Um, but also within Pega itself, we're developing a lot of individual components that we can reuse across all of our processes, especially when they're common. And, uh, as you probably get in the sense of a lot of the work that we do is very similar in nature across networks, and there are lots of common elements that we should be able to reuse, and particularly across geographies, which is hugely important.

Um, that is the end of our presentation. Um, so we'd like to invite any questions anybody has. Thank you. Farai. Yes, please. He's coming. He's coming to the mic. I don't know if you want to wait. Oh, leave a chair out.

Thank you for the presentation. I have a couple of questions on your dynamic routing. Um, is that based on a set of conditions that to be met and an output is already selected, or do you have a data store with the set of inputs, and then you have a predefined output and a follow up question on that is on the dynamic routing. How are you routing work to your other third party vendors? Do they also use Pega or do you have to invest in API integrations there? Sure. So as of now, all the dynamic routing is handled by rules engine and within Pega itself. So as data comes in triggers the business rules that we've got currently set up and then essentially rooted on that basis, and we've got either individuals or it depends on the the next workflow step related to that, that business rule. Right.

So some of them result in going to work queues and then individuals pick them up. Some of them trigger robots, some of them send emails off to third parties, things like that. Um, So typically they're currently within the application itself. We've definitely got plans at the moment to as we're setting up more of the strategic integrations to GCP. We're doing a lot of the AI generation now in GCP as well. So we're interested in calling services from GCP, AI services, microservices effectively that we can push data out, get a decision and then incorporate that back into the case to then make the next step. So kind of like next best action I guess. But for us strategically, we want to ensure that GCP is where we're doing a lot of the intelligence and especially around the data, um, in terms of how we're interacting with third parties. So it's kind of a mix, but typically, uh, it's by we will push out to them documents or emails.

Um, if, if we need something where they're going to interact with us, um, at the moment it's usually an email, but we, we are getting, uh, heavy requirements coming in. That means that we should probably consider building some interfaces. Um, so we're not there yet, but we are considering it. But we do know that that's likely to be a challenge. Not so much from a Pega capability perspective, but we believe it will be a challenge for the security standpoint. So we've got to make sure that it's, you know, super compliant. But for us as well, it's not just compliant one geography, it's compliant many geographies and many rules in many geographies. Unfortunately, there's no one size fits all. There was a question at the front as well.

Right. So apologize first of all for being a little late. What part of Vodafone are you from? Vodafone Networks. Networks. Um, so I'm going to go back to the comment you made about vendors kind of sending in, um, emails with, uh, work orders or. Yeah, purchase orders usually purchase orders. Right. Um, do you want me to go back to the slide?

Um, yeah, sure. My question is, as a company and as a group, we're still exploring Pega. And part of this exercise is to learn from others. Um, why? For a use case like this, you didn't use, um, maybe, uh, RPA, uh, and you went straight into Pega or were you already using Pega? I just want to understand. Yeah. So, um, for me, so I look after RPA as well. So I should probably tell you that and then it probably makes sense.

You know, we do consider RPA for a number of use cases, but for me RPA is great at integration to other things where you haven't got APIs so it can interact with other systems. You don't have to have humans that kind of stuff, but it's not the best for workflow or managing requests because when you get exceptions, often RPA can fail. And there are. You can't typically get every exception path captured or known. What to do with RPA? As the visibility side of RPA can also be quite a mystery, and the auditing and stuff like that, the beauty of having a case is everything's in there, it's all captured. What's happened ? What step is it at? Who is it with now?

What's happening with the exception? Who's managing that? If there's a problem, you can see it all there nicely. Um, if you have that in RPA, the visibility kind of goes. However, what I do like though, is using a case to then trigger an RPA for then the RPA to come back to the case to say that I've done my job. So for me, um, pairing these things, that's why I call it intelligent process automation or hyper automation as people call it. It's for me, it's the combination of those technologies working nicely together, not one or the other. So I'm not a, um, I'm not not a fan of RPA. I just think it's got a good place.

And I think that was carry on. I think the thing that was unclear is that you're using it as a case management, so you actually are putting it through a workflow end to end. Yes. I think what I wasn't clear on is I thought you were just getting an email and just passing it over. Oh, no. Getting information from it. So yeah. Thanks for the email. Actually creates the case and manages that for a purchase order workflow.

And then as one of the steps within that purchase order workflow is to do the checks against basically all our repositories databases and then show what is the result of that check basically. And that can either then be automated if it's within the threshold or tolerance, or it can be sent to a human if it needs a further, further decision. This is good. This is testing after his hosting duties last night. Um, for your workflow, are you using a headless application? Are you using Pega CSS? We are using Pega CSS. You are. All right.

I had a follow up, but the way you answered it, I have no follow up now. There you go. Thank you. No problem. Any more questions? Feel free to catch us afterwards or send us a message in the app if you want to have an offline chat. Anybody as well. You know we're super available within the last few days and, you know, happy to happy to catch up if especially if you know you're looking at doing similar stuff. Um, and if even if you can't do that in the next few days, I'm sure the Pega guys will happily set something up offline.

Great. Thank you very much, guys. Really informative. Really good session. Thank you.