PegaWorld iNspire 2024: Nordea Builds a Pan-Nordic Lending Solution on Pega, from Advisory to Operations!

- All right, let's start. Thank you everybody for coming for this session. I'm Jim Nielsen, I'm the client executive for Nordea, working for Pega, and we're here today to have a presentation here from Anna Johnson who's the head of business process automation. But it's not just that he's also a dive master. So this is the perfect thing as we now gonna have deep dive into how to transform the end-to-end banking. So you're in safe hands, I hand you to Anders.

- Thank you very much. They can picture me wait through for the rest of the presentation. That's gonna be really helpful next time anyway. Yes, so my name is Anders. I'm really happy to see that somebody showed up. It's really hard to compete with lunchtime. Well aware of that also, when we are talking about the second day of the conference, I work for a company called Nordea. It's an amazing company. And when you are asked to be a presenter and work for an amazing company, it is very tempting to talk about all the amazing things that you have achieved for your amazing company. All the benefits, all the results that you've achieved, all the credit that you kind of had when you paraded those things around to your senior management. However, I am a Dane and Danes have a reputation for being brutally honest, which also means that I will be brutally honest today. So I'll also talk about the things that didn't work so well, the pain points, some of the pitfalls, some of the things where we scratch our heads today and say we wouldn't do the same thing in a million years if we had to do it all over again. I do that for two reasons. One, I think that's a much more fun topic to talk about. And I'm the one giving the talk, so I wanna have fun. And then the second part, and that's the added benefit, hopefully you will learn a little more from that. Generally speaking, I think it's easier to learn from your mistakes rather than learning from your successes. So with that in mind, I think we will go towards that direction for the rest of the presentation. We also talk a little bit about the positive things. It's not only that. We also do this a little bit, 'cause Nordea has a, let's say, general sense that we are not just here for our customers, we are also here for the community at large, right? And now we are part of the Pega community. So we also see it as a, it's called a moral imperative to share all the pain points that we kind of had so others can learn from them and help their customers and clients in their path towards Pega, yeah? Have I made you nervous enough now?

- [Participant] Not all, sorry, Jim.

- Okay, so Nordea, as I said, name comes from the two words, Nordic and idea. We have around 10 million customers. We are based in the Nordics. For those of you who don't know the Nordics, Denmark, Norway, Sweden, and Finland. We have near shoring options in Poland. Estonia marked with the light blue colors on the slides. We don't have offshore in-house. For that, we use our partners, so predominantly LTNI and TCS, which we are very, very happy with. And then we also get now a lot of support from Pega. Obviously when we're talking about the Pega platform. We have around 30,000 people working for us. And our operating income is around, yeah, roughly 12 billion euros. It's roughly the same in US dollars, more or less. And our operating profit is around 6.3 million billion, sorry, euros as well. Generally speaking, we are reaching our targets, which we of course we're very happy with. And again, Pega's helping us also to continue that journey going forward. The general vision of the general offering that we have from Nordea it's quite a broad rank and we have a broad range of financial services. We want to make sure that when our customers come to our organization, they don't have to go to any other bank. They can have everything in one place. When we're looking at our vision and the way that we are driving this, we're looking at three different things or different elements, which I'll get back to in detail a bit more. But one thing is the idea of omnichannel experience. For those of you who don't know what omnichannel experience is in brief, it means that if you start as a customer through a digital talent, through self service, you can quite easily or seamlessly move over to talking to an advisor without having to repeat yourself, repeat data, come up with new things that are already informed us spout through the digital talent. The other two parts are very much for me, interconnected, it's the growth, profitable growth, and then it's operational capital efficiency. Now from my point of view, the growth element is very much about the transparency you can create and the offering that you can give to your customers. And again, that's why it's very much connected to the efficiencies that we kind of looking at. 'Cause the more efficient you can be, the better offerings you can give to your customers. There are also two levers that we're using to support our general strategy. One is being a digital leader. This is obviously very much in line with the journey that we are on with Pega. And then we are also looking very much towards our sustainability, which is a competitive edge that we are kind of looking for as well. I think when it comes to sustainability is not something that I can touch too much on today, but it is still part of the core element that we are looking at for our strategy. Now, the way we've kind of positioned Pega when we came into the bank and we're trying to sell it to our senior management and explained that we wanted to do this, we did it in two ways. One, we were very, very clear on how we positioned this and we positioned it as a workflow and case management tool. I know that it has a lot of other functionalities, which is great, but from our point of view, that was the key element that we really wanted to get outta Pega. And the reason why we wanted that is because we have thousands of processes in Nordea, right? And we have almost as many applications. And sometimes when we are talking about this and we're trying to explain it to people that don't know what a workflow tool is and what it can do for you, we compare, let's say Nordea to a factory. It sometimes dissatisfies people when we talk about it as a factory, they say, no, no, we are very special and we are a bank. We're certainly not a factory. But on the other hand, for the analogy of explaining what a workflow tool does, it is quite useful to use that analogy. And the way we describe it's that the customer comes through the door at one of the factory and out of the other end, you want to make sure that they get the service and the product that they're asking for. And what Pega does is the conveyor belt connecting those two points, bringing through that the factory and making sure that you also then have all the legacy applications, which would be the machineries next to that conveyor belt, connecting their different components to that delivery. And that's effectively how we described the benefit and what we wanted to achieve by introducing Pega as a workflow and case management tool in Nordea. We also took it a step further explaining that when you're looking at Nordea, we have four business areas, right? So effectively you have four different category belt, what do you call that? Factories within the organization. And each of those won't have one conveyor belt. Well, they will have multiple conveyor belts. And one of the arguments we had, and I'll get back to this in a bit, is that you really need to be in control of all of that to ensure that they don't go in very different directions and that they can connect towards the end when and if they need to. The other part that we did when we were trying to, let's say, pitch Pega internally and try to make people understand what we could achieve was connecting it to the strategy that I mentioned before, right? So when it comes to omnichannel experience, again ensuring that you have a seamless handover between a digital channel and then a human channel, you need to understand where all your cases are, right? If you don't understand where your cases are during your caseload, it's impossible for you to have a seamless handover. If you don't understand the data that's been given in previous steps of that caseload, it's impossible for you to have an omnichannel experience. And that was effectively what we were explaining to our senior management. The other part, and we have some use cases that I'll go into later, was the transparency in the sales part, right? That in order for you to offer something that is of value to your customer, you need to have a very strong understanding of what that customer wants. Where are they in the process of all the other offerings that we are normally giving to our customers? Because it's normally just not one thing that we have. It's multiple products, right? And again, if you don't have that understanding it through a workflow, it's very, very difficult for you to give a concise and precise offering to your customers. And the last part, and this is what's nearest and dearest to me because I come from operations and we talk about cost a lot. That's effectively what we put on earth to do. When you're running change in operations, it is about reducing cost, right? And the way we reduce costs is looking at the lead time. So how much time does it take from the customer comes through the door until they have their product at the other end. The touch time, how much time do we spend on actually delivering that product? And obviously the error rate, how much can we standardize? How much can we simplify our processes by using Pega? So one of the things that we tried to explain to our senior management where we were taking in Pega as well was that due to this analogy with the factory in all the different conveyor belt, you need to have a really, really strong CoE. And we set that from the very, very beginning. And it's one of the things that we actually did well, that we actually succeeded with. And I think would also a clever move that what I would advise to everybody else. Again, the way we kind of explained this is another analogy that we kind of used. We set that if you are coming as a business area and you want to jump on the Pega train, if you want to buy a ticket to go with us on that journey, if you have a business need, a customer need, if you have a efficiency need, if you have a regulatory need, you can explain that to us and what you would want to achieve with Pega. And where we are kind of going with this, and what we're trying to do is to say that in order for you to actually utilize that ticket, there are some things that need to be in place. And we kind of broke it down to this to say that you need to lay the tracks, need to have somebody actually build the train. You need 'em to make sure that you're guiding the train so they don't crash into each other going in the wrong direction. And you need to actually schedule the trains, right? So you need to be able to describe which trains go in which order. And then what we try to do with the CoE is effectively match these different tasks if you want to, the different parts of the virtual CoE that we set up. Now, laying the tracks was done by a technology organization. So this is a line organization in Nordea technology responsible for the actual application being the provider of the application to ensuring the DevOps IT operations to service transitions. So when you're moving from the different levels in the Pega platform, then the actual building of the trains was placed with our group data management. So we have Aaron who's sitting here today, which is my better half when it comes to the CoE. We had a lot of conversations on where to place the development. You could argue that you could have placed in the technology. We did get that question. And I think the reason why we did that is a bit on how we understand both Pega, but also banking. Because if you take banking and break it down to its very, very core, like the smallest molecule that you kind of have, then effectively consists of three very basic things, right? It's about storing data, taking that data, lifting it up into a customer journey, enriching that data and then storing it then, right? The best example you can do with this is if you have a credit card, right? You go in and you wanna purchase something, we go in and look at your credit card and see how much money do you have? You take that up into your customer journey, you pay something, we register, you paid it, and we put it back down in your account again, right? Very simple example. You can have the same example though for the lending journey. Slightly more complex, but still the same idea, right? You would go in and you would see how much do you earn? You would go in and see how many assets do you have? You would go in and look at different offerings that we have and products. You would lift those things up into a customer journey. You would have a conversation with the customer about what is it that you want to buy, what can you actually afford? And then finally give them an offer and then bring that down. Once they've decided, and we've agreed on the offer, you would register that again in the legacy systems that we kind of have. So one of the arguments and one of the reasons why we placed the building of the trains in group data management was precisely because of this. It's about handling data, right? Storing them, taking them from the right places, bringing them up, ensuring that you're developing them and enriching them in a structure format. And then you are also storing them in the right places, once again. Yep. When it comes to the guiding of the trains, this was sitting with group architecture again, ensuring that whatever we did with Pega was fitting into all the transition architectures and the target architectures that they were kind of drawing off, making sure that Pega didn't shoot off in one direction and then all the other technologies were shooting off in another. And then last but not least, and again, this is obviously the most important part 'cause it's my part is the operations, right? Making sure that you actually apply Pega in the right places. Understanding that when you're embarking on this, there needs to be a solid full cost business case, right? You need to understand what are the processes you're actually looking at. You're also looking at the actual portfolio and the financial models that you have internally in your organization in order for you to actually arrive at the right place, at the right time, and with the right cost and a profitable journey in that. So the other part why we chose to do this as a virtual CoE, rather than creating a separate entity, which you could have done, right? You could have created a new Pega unit somewhere in the organization, probably in one of those four line organizations. The reason why we did not do that was also because we wanted to make sure that everybody had a bit of skin in the game, right? We wanted to make sure that everybody owned something of Pega, wanted to do and make sure that it was success. It made it slightly more complicated because you needed all those four areas to actually collaborate. I've been very, very fortunate that the people who were with me on this journey, we got along really, really well. I would say it was also rather painful. I said this earlier to some people that we did end up having to install a weekly meeting, which was called a Pega therapy session, where you could effectively go back and talk about all the horrible things that you were experiencing on this journey, all the difficulties that you were kind of facing and the hardship that you had. And if I was give to give any advice to any of you, I would do the same to everybody else, right? And the reason I say this is not because that I think we were particularly bad at it. It's just the fact that whenever you have to do these type of changes, right? It takes a lot of people, right? And it takes a lot of people to collaborate together for a long time. And unless you establish those personal relationships in that collaborations, it's gonna fail, right? There is really no room for you to have a chink in the armor for these four units when they go off into the rest of the organization. If they start wavering any of these levels, you're gonna be in trouble, right? Because the business is gonna ask questions all the time about why are we doing this? What's this gonna cost, what are we gonna get out of it? Is it really gonna be successful? Is it gonna be another IT project that doesn't succeed? And in order for you to achieve those and answer those questions successfully and being consistent, you need really strong collaborations between all these different units. Yeah, cool. The other part, and this is more where we're at now, we were trying to explain what is it that then they get out of the CoE besides what I explained before, right? And we've said that a lot of what we actually do in the beginning is laying the foundation for this, right? So we've created a Pega architecture forum to ensure that all of our projects go to the same forums to get an approval of the architecture that's setting in motion. Similarly, we have quite a few communities. So we have a BA community, an SA community, a project management community, to ensure that we bring the different projects together and leverage also the fact that people locally in each of the, let's say, projects, actually know how to collaborate with each other. The third part that we did, and I think this was again, a lot of credit to Aaron, I think he came up with this first, is the fact that you needed to define very clear principles of how to apply Pega. I've said this many times before and I will say it many times again, I think, but the good thing about Pega is you can build pretty much anything with it, right? And the bad thing about Pega is that you can build pretty much everything with Pega. So unless you control it quite significantly, there is a very big risk that you're gonna develop things in very different ways. If you allow and federate that development into your organization, I think you should federate it. But if and when you do federate it, you need to make sure that it's done in a controlled manner. 'Cause if you don't do that, there's a very high risk that the end users will feel it very, very differently. You're not gonna reap the benefits of actually having a common platform. Again, the example would be that if you take, what do you call that? The office package, right? Every time you need to go and print something, it's the same kind of place. And it's the same type of thing with Pega, right? If you are sitting in the front end and you are banking advisor, you would probably have at the end of the day, maybe 5, 10, 20 different Pega applications, right? You would have one for loan origination, loan amendments, you would have one for credit cards, all these different applications. And if from the COE point of view, you don't ensure that those have a same logic built into it, that they have the same user experience, it's gonna feel foreign every single time that they open those applications. And then you're not gonna have the benefits of having one common tooling and one common technology supporting the entire journey. The other part that we kind of go into, and this is kind of the project journey that we are kind of looking at, is the early investigations, the securing of approvals. And then at the end of the day, also our accesses and our enterprise layers when it comes to the early investigations. We also accept the fact that although we do now have, and I'll show this in a bit, I think we have around 27 projects going on at the moment. Different definitions from projects, but nevermind. But that still leaves a huge portion of our organization who don't know and haven't gotten any experience with Pega, right? So what we do from the CoE point of view is try to help them understand what Pega can offer them and how it kind of works. The other part that we do from the CoE is very much helping them to design their to be processes. We also say this all the time, that the risks that you have with Pega is that if you don't redesign your process before you build it in Pega, you can take all the child seizures that you have from your old manual processes and just digitize those, right? It's gonna do something for you, but it's not gonna do everything that you can if you don't redesign your processes before you actually start building them there. The other part is, and I've said this before, is trying to make them understand that when you're building a business case for something like Pega, it's fine to look at the IT investment, right? All good, all fine. But you also need to understand, and I think this is also what they're targeting with the new blueprint. There's a lot of work going into actually understanding the business requirements, right? There's a lot of hidden costs that lies outside your initial IT development resources. There's also a lot of cost related to actually the maintenance, right? It's not cheap. There's license costs. Jimmy needs to earn his money, otherwise he doesn't get his bonus, right? Sorry man, we've worked together for quite a while. But I think from our point of view, right? You need to understand that when you set these projects in motion, that you cannot just look at that IT investment, the initial investment that doesn't help you. You need to look at the totality of it to fully understand it, fully grasp what are the consequences of what you're embarking on. And we from the CoE try to help on that. The other part is securing the approvals. Again, from our point of view, this is, as I said before the architecture sitting behind it. So the high level design, the target architecture, and the transition architecture of, again, what you want to move towards. Similarly, again, we control it from our central point of view, how they establish things in the layer cake. Again, ensuring that the things that are common that we can have as common components are placed in the right place in the K layer cake. So we can reuse as much of this as humanly possible. When it comes to the access controls, we've also been quite strict saying that if you want to have access to Pega, you do need to be certified, right? I know you have citizen development sheet, but again, from our point of view, and we are not quite there yet where we feel comfortable in doing that. So we're very, very strict in saying you have to have a certify certification from Pega before you're allowed onto the platform just to make sure, again, we don't mess it up and use it in the wrong way, where we're making things even worse and even more complicated, but that we actually start making things simpler. I'm not gonna go into the other means 'cause I don't necessarily think that's relevant for this conversation. But needless to say, the part where we spend most of our efforts and most of our time is when they actually go into development and our continuous controls, right? So we give a lot of time and effort from my unit, particularly also from Aaron's unit on the technical design and the process design. Again, we do this because we will have partners who are coming in and they're super experienced, right? With Pega, but they know nothing about nor data. They don't know our values, they don't know how we work, they don't know our, let's say IT landscape. And in order for us to make sure that they leverage and build within those parameters and ensuring that they stay within the boundaries of what our principles have set, we try to advise them on a continuous basis from the CoE point of view, that puts quite a lot of strain on us because again, we have a lot of projects and not such a big CoE, but it is really, really important for us. The other part I think, which we are spending quite a lot of time is then audit them them along the way, right? So as they kind of progress in development, we will audit and make sure that they stay within those principles and those guidelines. And for that particular reason, we also assign a CoE LSA and a CoE LBA to support them along the way. So they're gonna start build personal relationships between the COE and then the projects themselves. We also have the guardrails and the diagnostics. I think this is role more running in the background, something we're doing on a continuous basis to ensure that we can stay within the parameters of what Pega is also supporting for. It's also important to say that when we go into these developments, quite often you become wise, right? You don't know everything from the beginning. So what we have also advised 'em to do, if you're making any significant changes during your development, we are telling the products that you have to go back and secure new approvals. Again, because we know that these applications will live for a long time. And when they're living for a long time, there's risks that people will leave and people forget. And if you don't have documentation that mirrors almost a 100%, what you actually built is gonna be really difficult to maintain things. And it's also gonna be really, really difficult to fix them if and when they break. So from that point of view, we are quite strict and saying that if you deviate too much from the original design, you have to go back and you have to ask for a new, let's say, approval of whatever design you're creating. The other part, which we've also said is that of course we can become wiser. It might be that we've built some common components, but it can be that we've missed something that a new project is asking for that common component. And same kind of instance, we obviously can go back and revisit those common components from a functional point of view and from a technical point of view, if and when new projects kind of come knocking on our door. The last parts, again, we're not spending so much time on from the CoE if I'm really honest, because this is more, when they go into production mode, again, we will continuously support them as they go into the work of running their business. Because there's always tweaks, right? There's new regulation coming in, or there are tweaks to the projects or the processes. There are tweaks to the applications that were integrated to whatever it might be, right? But in all honesty, where we see the majority of the work, as I said, is in the left hand corner where we are looking at the development part and the continuous controls. Yep. So in terms of what our portfolio looks like today, it's been a bit of a journey. We started off with three pilots. If you start with the top left hand corner, we chose a small medium, and a very, very, very large process. We could get back to the very, very large one in a bit. And then we wanted to secure that we finalized, or at least came very far in the understanding of those processes before we jumped into something new. We wanted to make sure that Pega was actually giving us what we needed and what we wanted. We wanted to make sure that we could actually realize the benefits that we were trying to achieve before we got to that point. That also means that it took quite a bit of time before we started sort of truly seeing scale in the terms in the number of users that we have. And we are now seeing this ramp up. And I'm a little sorry because I know that we've actually, when we go beyond February and we go into April and March, this number wouldn't have been 127. We've been closer to 200%, right? So we are really seeing a hockey stick now where more and more of our applications are adding more and more users at a faster and faster pace. So just to give you an indication in the snippet of this, when you start looking at this trend, it's gonna go like this. It is gonna be a hawk stick. You often say that, but we can now start seeing that which we're really happy about. 'Cause we've also been selling that idea into the organization that there will be a haw stick. And now that's picking up. It also means that you need to be very careful in terms of how you construct your contracts with Pega. Again, I think from our point of view, we are quite happy with the setup that we have, but it is something you need to be aware of because you can have a lot of users very, very quickly, at least seen from our point of view when you take some of these large processes. Now, I said that we have 27 now ish, 28 projects going on. It's also really important to understand that there are very different sizes of this, right? When I say we have 28, we have some projects which are effect programs, right? They will be full release trains with multiple delivery teams sitting underneath several hundred or well at least a hundred people working on it. If you take the totalities on not just developers, but also business resources and architects and other IT developers, right? And then you have these smaller projects in this slide, each of those would still count only as one, right? But it's just to say there's a lot of work sitting behind this, even if the number in itself doesn't seem so much. Now, again, the thing that that we can learn along the way as well is, that it's not necessarily the development as such, which is the problematic part. It is rather also the change management element that making sure that the organization is ready and mature to actually adopt whatever you build is hugely important. And I think you sometimes underestimate that because you go in and you talk about the Pega release trains and the express, sorry, of Pega Express trains, right? And say we can develop this within such and such period of time, which you can also, right? But then you need to think of the fact that there is a very long period after that initial development where you're in production, where you actually need to get the organization to use the application. And I think that's part is sometimes somewhat undersold. And particularly if it's a complex, let's say, process that you're looking at, it takes a lot of time, right? And particularly if you're changing it a lot, which we will see in a bit with one of the cases that I have where we changed multiple things at the same time. It takes, it's almost a project in and of itself to roll these things out. The other part that we also learned from this is that the benefits come sequentially, right? Again, in Nordea we have a lot of manual processes. Some of them are handheld. You still have in some, as we hand in some companies snail mail, write physical letters. We have processes which are carried through or orchestrated with emails or some of our old internal ticketing systems, which effectively only gives you a possibility to hand over something and then it kind disappeared into a big hold of blackness. But in order for us to then achieve the benefits, we first need to digitize those processes, right? You need to move them into Pega. And that gives you, again, some value. But where you get the true value is when you start having the integrations and the automation. And they normally come as a second step, like in your MVP2 and MVP3 and so on and so forth. So I think a realization also is that when you build those business cases, you need to understand that it's not all gonna come with the first release that you're gonna put into production, right? It might come with the second or third one, which takes quite a bit of time before you sometimes achieve this. And then the last part of this is a bit of a general statement, right? We are, as I said, very happy with the stakeholders that we have and with the partners that we're kind of working with. But we do also recognize that getting qualified resources is a constant, constant struggle. Also, we are starting now to build up our in-house resources. We have a lot, relied a lot on us, sort of partners. And we will continue to do so, but we also want to build something internally in Nordea. And it's quite difficult we found to, to find the right and the good people in order for us to progress as we want. So again, also a little cautionary tale that they don't come cheap and they don't hang on the trees all over the place. It does take a lot of effort to to move them in. And I think particularly maybe also because we're based in Nordics and there isn't a huge base in the Nordics quite often you need to pull them from all over the world in order for you to attract the right talent. Yeah, okay I'm gonna go into three cases and then I'll open up for some questions. The first case that the corporate lending one, so the three cases I mentioned is the small, medium and the very, very, very large. This is the very, very, very large, right? So we have corporate lending, it's our most complex process that we have pretty much in the entire bank. Maybe we can find one or two others that are kind of similar to this. It's usually complicated. There are, I don't know, a hundred different steps in this process, right? And there are super many variations, right? Because you have thought companies and different financial structures, you can have different types of loans and different types of credits and collaterals and all of these things, right? So there's a lot of variation in this. And when we started working with the corporate lending part, we were also faced with two other quite large factors. One, the business areas wanted to go from local corporate lending processes. So one in each of the four countries that we're normally serving to a Nordic process. And at the same time, quite recently before we started this journey, we had moved our head offices from Stockholm in Sweden to Finland. Sweden isn't part of the Euro zone, but Finland is. So we were suddenly sort of introducing quite a lot of new credit guidelines that we had to implement at the same time. And they hadn't been fully developed. So we understood the guidelines, but converting the guidelines into something that's tangible on how you want to implement those that hadn't been done. So again, we were starting with a new technology, right? We were going from local to Nordic and then we were facing these new credit guidelines, which hadn't been fully fledged or blessed out, right? Which was a bit of a perfect storm in terms of trying to get this wrapped and understood and qualified. And I think we spent, I don't know how long did we spend on trying to get the scope right, Aaron? Six months just trying to do more, nine, 12 should like, okay, whatever between between six and 12 months trying to get the scope right. I remember that day evening, it was a Friday where we got that done and I went home and I don't normally drink a lot, but I drank a bottle of wine and smoked three cigarettes and I normally don't smoke. I mean it was such hard work to get all of these different parties to come together. Also, because this process isn't sitting in one unit, right? It's sitting in four different elements or four different parts of our organization. So have business banking, large corporates, institution, the credit organization and operations. And all of those four want a piece of the pie. All of them want to be first in line. All of them have particular needs and particular wants and particular benefits that they want to get out of it. And you had to get all of that to fit together while at the same time understanding what the scope is. Now, the reason why I feel comfortable sharing this, and as I said, I would share the pain points and the things that we probably wouldn't do, we wouldn't do this again. I think at that point in time, that early on in our Pega journey, if we had to do it again, I can pretty much guarantee that. However, what I would say is that because of the effort that we put in to get this to work, this is now being positioned as something aspire towards, the governance that we've now managed to set up where we have those four units represented at the very senior level at an operational steering committee with a separate release train covering all of those four areas where we have different delivery teams addressing different parts of the value chain, but with a coordinated roadmap and a coordinated funding. That is what we are now saying that others if they want to do these large scale projects have to do and have to install in order for us to get to where we want to get to. But as I said it, it was rather painful to get there. But we can also see now that a lot of the benefits that we are kind of getting out, again, the numbers that you see in the middle here are predominantly towards the back end of that process. But we are growing quite quickly from five to 35% efficiency gains. That's the business case that we kind of have and are seeing that we are moving towards, again, a bit of a hockey stick here, but that's what we are trending towards, which I think is pretty good for something that's very, very complex. Also, just underline when you're talking about the scope will be a 100% done by 2027. That's the scope we've defined now, right? There is way more scope, right? You can continuously develop and improve these type of things, right? You can build more and more into these things if you want to. But what we've done at the moment is defined this and this is what we're kind of working towards. I think in terms of the learnings we kind of had with this, aside from what I kind of said before is that it's really, really crucial to understand that if your business is not super crisp in defining both the business requirements and also their business processes, it makes it tremendously difficult for you to be efficient in what you want to develop. I think we also did this, we wanted to shoot out of the gate and we're talking to Pega about sort of running really, really fast and delivering really fast. So we ramped up development teams very, very fast, right? But we faced then the issue that we didn't actually have the ability to feed that beast or feed that delivery train with the requirements fast enough and quick enough. So we ended up having a lot of iterations while the development teams kind of going like, what do you want us to build? What do you want us to build? What do you want us to build? Which again, we've now completely gone out and half and it's running like clockwork now. But it wasn't that in the beginning. And again, as I said, for anybody who starts on these type of projects, I would say that you have to be wary of that and understand that if you can define your business requirements and your approaches really well, then you're off to a good start, right? If you can't do that, you're gonna have trouble throughout the process. Cool, conscious of the time, I'm gonna skip to the next one. And the other one is the middle example, which is your mortgage lending process. So this one is country based still, again, slightly less complicated process, but I think a huge amount of customers that's kind of going through this is the one of the core processes that we have in the entire bank. And one of the things that impacts most of our customers, right? I think what we try to achieve with this one and what we also learn from this is, is that there is a need sometimes to have a common high level design. But as soon as you go into the details of it, because there are local regulatory requirements in each of the country because they're local legacy systems that you cannot necessarily change at the same time. Although you need to design things at a high level in a common way. If you want to have a common Nordic process and you want to leverage scale quite often if you go down to the sort of lowest level, there will have to be variations at least in some steps, right? Other steps can be common. And I think that's also the learning here. Rather, not all of these are individuals, some of them are actually Nordic, but not all of them are. 'Cause again, there are boundaries set that sort of prevents you from doing that. So again, from our point of view, what we wanted to do with this as well and what we tried to do is to use the workflow tool to get as common as possible, right? We often talk about leveraging Nordic scale internally own organization. 'cause you're a Nordic country, and again, when you have four markets, you want to make sure of much of that as possible is common to leverage the scale that you kind of have and use that as a competitive edge against the other banks, which aren't necessary in Nordic. Now again, I think it's equally important to understand that when you're building the Pega applications, you can also serve different purposes as we kind of try to do with the color coding here. Is that you can see that some of the areas we are focusing more on improving the transparency, the cross sales and the data sourcing. This is very much in the needs analysis, for example, and the offerings. On the other hand, there are other elements where you're only looking for the transparency and the data sourcing, right? Ensuring again that they take things that take the data from the right golden, or at least as Aaron says, from cool data, manage the most appropriate data sources if you don't have a golden source. But that can itself can be a golden or a target for you to kind of move towards. And then when you're looking at my end of the woods in operations, it's mostly about improving speed and efficiency, right? Nobody wants to sit around waiting for documents or sitting around waiting for, let's say the final signature before you can actually go out and purchase your house or place your bid for a house that you want to buy, right? You want that to happen as fast as humanly possible. Super stressful being in a individual, individual sitting there wanting to buy your dream house and having to wait for something that's not a good customer experience. Now the last example is, in the unfortunate event that when you get towards the end of the lending process and you are at fault of defaulting, so we have something called automated recovery data, which was our, let's say, small process. So this is part of the process where if a customer's looking towards a trending towards not being able to pay back their loan, you have to go in and collect quite a lot of data to ensure that you can support the customer as much as humanly as possible. But we want to get them to the right place. We want to make sure that they can get the help that they need and they can find out how to get out of whatever predicament they're kind of in. Now, from our point of view, when we are looking at this, we were really, really lucky with this case business case. I mean the return of investment that we kind of have here is humongous, right? But it was again, a bit of a perfect storm that when we started building this, we were only looking at a smaller efficiency, but while we were building this, we got hit by a new regulatory requirement that would've meant that we would have to go out and hire, I don't know, 80 to a hundred FTs, right? But because of what we built and what we created and what we managed to automate and completely eliminate as a task, as a manual task, because we were in the process of doing that, we avoided having to hire all those people and bring all those people in. So I think sometimes you get a little bit lucky, right? So when we were trying to push again, our management and make them understand and push us beyond being just in pilot mode, going into full fledged now with scaling things, when you are on that journey and you get these kind of cases, then you do want to again parade them around. But at the same time, as I said, with a very large process, we had some struggles and you were kind of constantly balancing this saying that we need to be realistic about what we can do, how we can do it. And at the same time, we also want to showcase what we can kind of achieve. And I think aside from what we did here with decreasing the delivery time, I think we also improved the error rate with like 50% on top of this, right? And the last point to be made here on this particular case is also that even though we say that this is our smallest kind of project, it's still running, right? We are still doing things to enhance and improve the process and constantly try to shave off the amount of FTs and the amount of time and effort we put into the process. And we are still to this day building business cases that sort of evolve around this process because there's still a very large untapped potential, although it is compared to the two other process, a very small process, right? And something that's fairly simple. Yep. Again, I wanna leave a little time for questions, so I'm not gonna say too much about where we're gonna go, which is the last slide. But needless to say, again, we've only started this journey, right? We don't talk about ai, we don't talk about blueprints, we don't talk about much else than the workflow and case management. So I think we have quite a lot of potential in front of us. But I would also say that with what we have going on at the moment, we are quite confident that we can continue to deliver very positive business cases. And again, a lot of positive impact for our customers within the coming years. And as I said, for many of the things that we are looking at, we are in support of also the general direction that we're seeing with our technology strategy, with our data strategy and our overall vision. As I said in the very beginning of where we want to go. Yeah, have I missed anything Aaron?

- No.

- Okay, good. And I haven't embarrassed you too much, cool. Are there any questions? I think we have about eight minutes left. Seven and a half now.

- I fellow talk there.

- I am Danish but you can come with Swedish. Fair enough.

- [Participant] Are you using traditional like waterfall or is it full agile organizations data? Because the naming of stuff and-

- Yeah.

- [Participant] How do you keep track of the development?

- Yeah.

- [Participant] Confluence era or how do you end to end keep it from like a business call or?

- Yeah, so the boring answer to this is a bit of both.

- [Participant] Right?

- Also because we effectively, the way that we've kind of done this is that we've tried to secure and anchor the development in the local business units and they have their own way of running things, right? Some of our business areas are fully agile. They have fully fledged kind of release trains and PI plannings and sprints and all that, right? And delivery scores. So they will run it fully agile, right? Others have a more waterfall approach, right? They will do natural projects as you kind of do. Both of those kind of methodologies are kind of defined in what we call our delivery guides. So there is a set methodology for those and we are trying to make sure that whatever we do with Pega kind of fits into this, right? It's one of Aaron's favorite topics, right? We want to be as vanilla as humanly possible. As you know, you should have been part of this presentation. Why am I only here? No, but he could, he quite often, and I think we agree on this very much, right? That you do need to stay within that framework that you already have. And I would even say that in some areas, right? We have an agile delivery, but then on top of that you have, you don't call us steering committee because the agile people are gonna go ah, right? But you also need to recognize that if you have four business areas, right? So a business banking, large corporate institutions as two entities, you have a credit organization and of races, if you want those to all feel comfortable, right? Then you need to have a forum where they can meet and talk, right? Because you will never have one product owner who understands and can represent all of those that will never, at least I think they will never happen, right? And there will always be that type of silo in your organization, which means that on top of the actual delivery part, which I at least feel that agile fits better. But on top of that, you might have something that resembles the steering committee where you can bring those senior stakeholders together and they can feel comfortable that what's happening is also in their interest, right? That's a fair question. Yeah, fire away.

- [Participant] Okay, so I missed the first five minutes.

- That was the best part.

- But I'll try to get.

- Sorry, there's a microphone.

- [Participant] So the CoE is set up. Is it specific to only the Lending Avenue or applications across Nordea is being considered?

- No, the CoE is for everybody, right?

- [Participant] For everybody.

- I think originally we set it up for these three pilots that are kind of explained here, but we are now serving the entire portfolio and we also don't have an interest in creating a separate CoE because if you have multiple CoE then they start competing and having different messages, right? And it's hard enough with the virtual setup to make sure that we are 100% aligned whether we communicate to the projects. So no, we don't have.

- [Participant] Yeah, because the reason behind, because since you mentioned there is also a business stakeholder involved in the CoE. So how do you manage AP, I mean, because everyone, for example, people from FINCRA will have their own strategies view, they want to implement it, whereas in lending and wholesale, they have a different perspective. So how do you handle this with your roadmaps and timelines?

- Yeah, I think the way we would kind of view it as again, that they would be a receiver effect of the CoE, right? So they would have their own ability to develop and bring forward ideas. They can also do their own prioritization. We from the CoE do not prioritize what they want to build, right? That's left to the business areas. If we started to do that, we would be in a lot of trouble. What we do say is that if you want to do something, there are certain requirements, right? You do have to have a business case. Technically speaking, we don't care about what's in the business case. The business case can even be negative if you have regulatory requirements that kind of outweigh that, but want to leave that with the businesses. But what we set as requirements that you need to do a business case, right? You need to understand what is the cost of this and not just, again, as I said, the IT cost. And the other part would be that from a CoE point of view, we are also, we are constantly, or no, let's say this, we are painfully aware that if we do not support what the business areas wants to do, right then they're not gonna be working with Pega. Right, we are not forcing them. We're not saying that you have to do it, right? So they need to prioritize this alongside all the other potential IT development initiatives that's sitting in the bank, right? And there's, although we are a bank, there is a finite number of investment currency that you kind of put towards the IT development.

- [Participant] Got it, and one last question.

- Yeah.

- [Participant] How do you keep up the pace with respect to the new capabilities, which I believe you are in cloud, if I'm not wrong.

- Sorry.

- [Participant] Or I believe you are in Pega Cloud, if I'm not wrong.

- No, we are on prem.

- On prem.

- And that was also a conscious decision from the beginning because when we started off with a pilot internally in there that there's quite strict requirements that going to the cloud. I think some of the questions I've heard in the other sessions also speaks to that right there, there are some security issues that kind of come into play. It's certainly a kind of a reflection that we have. At one point or the other, we will probably move to cloud. It's not on the roadmap right now. Again, we have enough to deal with, with ramping up and following, keeping up with the portfolio. That's kind of there. But yes, at the moment we are on prem.

- [Participant] Okay, I'll take the remaining questions off late.

- All right, any other questions or comments?

- [Participant] Let me ask the last question then.

- I think there's another dude behind you.

- Okay, go ahead.

- Go ahead.

- [Participants] Yeah, very impressed with your whole vision and especially if I see what you're still planning to do, it's even bigger. So, but the governance is impressive that you're doing it with almost minimal CoE when you want to do things like fully end-to-end digitized value chains, including maybe applications that are not on Pega. Maybe using process fabric for that, at some point in, there has to be some more coordination on that vision.

- Yeah and this is also where I think we, there is an existing structure on when you want to get something approved from an architectural point of view. And I think what again, we are trying to do what Aaron has been the biggest advocate for. And I'll take the credit 'cause I stand it and he can't, he doesn't have a mic, right? But again.

- But we know, we know,

- I know he knows everybody. He's famous. No, but I think what he also ensured was together with our architect back then, a guy called Alex Weiss, was that we latched onto the existing architectural structure that we had and the type of forums and decisions that we kind of had. So we didn't reinvent something for Pega. We just made sure that whatever we were doing with Pega fit into that existing architecture, right? So although we say that we have a Pega Architecture Forum that still sits underneath a broader umbrella of group architecture and the way that they would normally for any technology, right? Ensure approvals and these kind of traditional large scale, what do you call that? Target pictures. So I think from that point of view, we didn't actually invent something or introduce something. It was more question of, again, latching onto something that was already there to ensure that we didn't set ourselves apart from it. 'Cause to your point, right, if you build Pega in isolation and don't consider all the other things, there's a risk that you're gonna go one way with Pega and then everything else is gonna go another way, and then you're not gonna get the benefits, right?

- Thank you.

- It's alright you have six seconds. Four, three, two.

- [Participant] What is the vision for the next five years? Where are you in five years?

- Well, again, building your bonus, right? So, no, I think from our point of view, I think we'll continue to see the portfolio grow if I'm really honest, we're listening to the business areas and looking to our annual cycle of kind of trying to re or not redistribute, but distribute our funding models. There's a very clear demand that we'll continue to look into the landing journeys, we're not done with those. We are also seeing it being scaled up in the KYC area or group financial crime in general. That's a huge priority of ours. So we continue to see that grow and then I think for the whole backend, right, we've barely kind of touched that yet, right? We have a couple of projects that, which are touching that part, but there's a huge potential, there're going in that direction. But still, I think very much centered around the workflow and case management before we venture into all the cool stuff with the AIs and the supporting elements. Yeah, cool, thanks so much.