PegaWorld | 31:21
PegaWorld 2026: Transform and Deliver Your Legacy App with Pega Blueprint in Just Weeks!
Why wait a year when you can deliver in 12 weeks? Proximus reimagined its legacy B2B order exception app using Pega Blueprint™ to bring business and IT together for a seamless redesign. With end-to-end orchestration and 360-visibility, they achieved speed, agility, and a smarter way to work. Learn how rapid transformation can become reality.
Good afternoon everyone. Thank you very much for coming after lunch. It's an absolute pleasure to introduce Evie and Kurt, uh, from Proximus. Uh, could I just simply ask you, please turn off your mobile phones and hold your questions to the end? There will be questions if you like. Thank you very much. Without further ado. Yeah. Welcome, everyone. So first of all, who knows Proximus and has heard her our story or part of our story last year already? Anyone in the room? Yeah, I know. Okay. And what do you still remember from the story? Nothing. Okay. But I'll quickly introduce ourselves. Who is Proximus? So Proximus is the largest telecom operator in Belgium. And of course, our yellow friends who are also at the conference are not here, so they cannot argue the fact that we are the largest one. We have two entities. So we have Proximus global, where we deliver a cpaas and identity access management.
So through Telesign Root Mobile and Pixel, your company might be a customer of us, but you might not know it. But today we are here mainly to talk about Proximus domestic, where we offer a telco services towards our B2B and B2C market. Next to that, we have also our new strategy. It's about amplify and we want to amplify our customer impact. We are doing well on B2C, but we want to reinforce that one on B2C. We have some difficulties also there. We definitely need to do better, but also a very important message now is our infrastructure. So we are really rolling out 5G. So we are the best coverage. We are also now doing 5G plus already. But also we have quite a lot of challenges in rolling out fiber. So that's one of the things about our infrastructure. Sorry. And then of course everything more and more sovereign infrastructure, you know, all everything about regulations, but also make sure it's resilient.
And then of course, the future is challenge D known as really mandate from our CEO to challenge every processes we are having today to see if we cannot optimize them. So challenge the known, discover the unknown. And of course, our moonshot is our network is our computer. So with everything evolving, we want to bring the power of the computers Closer to the network where we need it. Think about self-driving cars. If all the computation needs to happen in a data center somewhere, we don't know where we want to bring it closer to the street cabinets because we own the infrastructure. So that's one of our strategic pillars of Proximus. And of course, as you can see, AI plays an important role. So I think it was Alan who said this morning, everyone the CEO hears about AI and everyone should use AI, but we should see to use it in the right way.
We also have an important pillar about sustainability and of course, the regulations, but we come back later to it. Let's bring this to. Our application. But first of all, a bit of history. Okay. So good afternoon everyone. I would like to take a couple of minutes to talk to you about the IT problem statement that we faced, as well as the business problem that we faced at Proximus. So we'll talk about B2B orders at Proximus. And just to give you an idea, in terms of volumes, we have around 4050 K B2B customers, around five K orders every month. Now, um, a little bit strange maybe, but a couple of years ago, we didn't really have a proper tool to do specifically the follow up of our B2B orders. Um, we were part of the mass, but as you all know, B2B orders are often the most complex, the most long, the most complicated.
So we were missing something. And then we had one very creative dispatcher at Proximus that decided to make his own tool because he wanted to support for his daily operations. And he built a tool which was called tofu, not the fake meat, but tofu like technical order follow up. And he built the tool years after years. It became a spaghetti of colors and buttons and what so on. But it was a good tool because it was made by somebody who did the job himself. So he covered the needs. And after a while, the whole department started using the tool. So it became important, but it was shadow it. And then after a couple of years, the dispatcher decided to leave Proximus and we were left with a shadow IT tool. That was very important for Proximus, but that was not well maintained, not secured as it should be.
We didn't know very much about the logic. So we faced a business risk. And that's the moment when for the first time business talked to it. So that's the IT problem statement that we faced. But we had a business problem as well occurring at the same time. So in Belgium the fixed telco market was changing very rapidly, and the network itself became more and more agnostic. So it became less of a differentiator for us versus competition. So our B2B customers really claimed Proximus. We want you to step up and provide us a better customer experience versus your competition. And you may need to make the difference in your human interactions with us. So we were challenged on that. And let me show you maybe a very short video hereafter. It's very short. It's the customer is speaking in Dutch, but underneath you will see that there are subtitles in English.
It's a famous customer called Newhouse. They make excellent chocolate and pralines famous in Belgium. But you will hear the customer explain or share the frustrations that they felt because of a bad experience they had with Proximus. So let's hear it. And. I think. That was Proximus problem with that in the West is overall, the players come in and say in turn three, three Technical Lead Alan three and said. Okay, I think I've made my point. I hope we made a point. So we have we had a very frustrated B2B customer, and that's where we decided that we wanted to do something. And that's when business talked to Kurt, and Kurt heard about Pega and heard about some sort of a Catalyst workshop that they were facilitating that could maybe help us in this context. And that's where we went to talk to Pega. Yeah, Indeed.
So the people who were here last year, they might have seen the slide. So in 2020, for my first visit to PegaWorld, I made my first Blueprint. And there I came back home saying, look, this is wonderful. It can help us. And then business came to talk to me. We have this tofu application, shadow IT. So you have to take it over and say, no, no, I don't take it over. It's old Legacy. You know what I've seen? Pega Blueprint. Here is the tool. Talk to Pega. Try it out. And that's where it all started. So in the end of 24, we had the Catalyst workshop together with Pega, where we sat together with the business users. The outcome of Pega Blueprint and also where Pega did assess of what would be your future vision. And that's where we come came to that catalyst workshop.
So that was the start of our whole new, uh, can I no, I will not disclaim the name yet of our new application that we built through Pega Blueprint into the Cloud. So. But a bit more about Pega Blueprint. Sorry about Peacock. Yeah. So the end result of that Catalyst workshop of two days was the birth of what we envisioned to be our new tool, which was called Peacock Personal Coordination cockpit. And of course, that's why the logo became a peacock that speaks for itself. But what we envisioned was a tool that would cover more broader needs than what we had before. We wanted a tool that was capable of giving our agents an end to end view on an order status, so a full view in one screen or as easy as possible. And we wanted then to have built in automated workflows and triggers and notifications to make life of that agent as easy as possible, but in particular also so that we could do.
Anticipation and that we could anticipate problems before them even occurring. That was the whole vision that we had. And the five features that you see mentioned. Here is what we wanted to be embedded in this new tool that we envisioned. And the first one was the auditory. 60. So that speaks for itself. We wanted the agent to have one screen on which he would have an end to end view of the status order, because today he needs to open 2 to 3 different applications. So we would gain in time and efficiency there. The second and the third point are about communication. So with this new application, the agents would be able to communicate within the tool by direct messaging. And there would also be a notification. So in case an agent is following a case and something changes or it gets a message from a colleague, he will get a notification and you can respond directly.
This way, we avoid quite a lot of separate emails and phone calls that go all over. So that again, gains efficiency. Now the fourth pillar is where the intelligence and where the added value is in. Because the fourth pillar means that we have built in more than 25 triggers in the application. Now, what does that does do to give you maybe an example, a trigger could be that when we see that an intervention will go wrong, or we assume that it can go wrong because material, for example, is not yet delivered. Two days before the intervention, we send a trigger to the agents so that the agent knows this is not going well. Let me take action. Let me reschedule this appointment so that we avoid a missed appointment and that we have that we avoid a frustrated customer. So that's the trigger in. And that's where the most of the complexity is.
And then the last part is about reporting, because of course, if you can measure all these triggers, you can find out where you need to do problem management to avoid these issues to occur in the future. So that was the vision that we wanted to build. I come back to our journey and you see that between the end of 2024, you also have something which is called the first half of 2025, where we said we had quite a lot of contractual discussions. It's about the protection of the data, the Cloud. So it was a very lengthy process. I make the same joke as last year. We are most probably the only company who faces those challenges. None of you have this, so you always sign directly. Um, but okay, that was where we lost a lot of time. Also finding the money to implement the application.
But yes, finally, in June 2025, just after PegaWorld 2025, we started the implementation. So there um, what I would like to mention here is that we have built this application thanks to a wonderful Pega team who know everything, because we counted on Pega to build that application with the help of Blueprint because we didn't have the skills. Constellation was also new for us. The cloud was new for us, so that's where we did it through the Pega team. And as you can see, we built it in four sprints. Very efficient, very good. Um, and we also did it through a fixed price. So meaning it was contained from a cost point of view planning. So very well. Also one of the things is that there was no customization. So it was built very rapidly. Again the four sprints. But then also what I paid a lot of attention to is that we make use of Pega unit.
Also something I discovered at PegaWorld. So yes, we were compliant and you might say yes, Pega unit compliance is 74%. That's not high. No, of course, because of the Layer Cake of pizza of pizza, sorry, of Pega. The three bottom layers are the common one across the application that did exist. So this is lowering, uh, our, uh, Pega unit coverage and the same for the guardrail. So guardrail was 93 something, which also pay a lot of attention to, is to make sure that the code we deliver is of good quality. So, so far, so good. I was in the Accenture presentation and it was about three, three, three, three days of brainstorming, three days, three weeks of design, three months of development. We did it very well. So far, so good. But then in Q4 2025 and October, the application was built very rapidly. There were some tests being done.
We were ready to go to production. And let me show again another small video about our testimonial of what we found back of the whole Pega, Blueprint and the Peacock application back in October 2025. AI is everywhere. Everyone is talking about it, but here it is real. It works. We have done it. Proximus is selling telecommunications within Belgium. I'm responsible for the customer experience on installations on telco products. The application was there to connect our complex IT architecture to detect when something was going wrong, like for example, in the delivery of telco products, it was detecting whether if the material is not delivered, the technician cannot do the installation. So for to be honest, it was a shadow IT application. I did not know about it until the moment Lora came to my desk saying, look good, you have to take it over. And I said to Lora.
This is not for me. I don't have the skills I want to PegaWorld I got to try Blueprint and it opened a lot of new opportunities. I offered Pega Blueprint to Lora to discuss with her end users to see. Can it help to replace tofu? The first time I used Blueprint, I could see how this vision could actually work in an application within 15 minutes. Like yeah, this is a no brainer. Basically, in one day time we had our application. It's very impressive. You have a lot of AI within development AI to formulate these cases. But here AI is really from the beginning to the end, creating requirements and then really implementing the application. It allows you to use your existing documentation, flow diagrams, screenshots, whatever you added to the tool, and it builds you for 50, 60, 70%, a new application on the platform.
You could prompt something as business explaining your requirements. And the outcome was something our colleagues from it could really understand and visualize how they would build it. If they say, yeah, but we want this to be changed. We change it and your front end is redeveloped or represented immediately, almost. And you can start interacting with the business again by using Blueprint to build the application. We did it in four months and we have much less defects, much less change requests. It's very dynamic. If you do it in a traditional way, it costs you much more time and much more money. You have from day one, the buy in of your end users which make the change adoption to a new tool much smarter and faster. So for me, really, it's an enabler to do this Legacy transformation. I've never seen a celebration moment for a new application that so many people being there.
It was just wonderful. Pega is so proactive and also really committed. It's top notch software, top notch people. It's amazing. So far the good news. And now the honest feedback about what came after. So remember the three three, three. But what about the testing change management adoption. Which figure should you put on that one. So here we are now in the second quarter of 2026 and we face some problems. So I'll let the word to Avie to explain a bit. Yes. Okay. Thank you. So we were at the end of 25 and we started the handover to the Proximus team. And we envisioned we forecasted like one quarter to do the handover phase. And then we steam to do a full rollout, I would say beginning of April. That was the ambition that we faced, but that appeared to be for us, a little bit too ambitious.
So let's be transparent and share some of the experiences that we had and why it took a little bit more time than what we expected originally, because it has proven that a handover remains a very complex operation. And so we had such a speedy process. But the moment that we did the hand over, we noticed that our technical teams that needed to get familiar with the technical and functional specifications, that took a little bit more time than what we expected. So the adoption, the learning phase that they needed to go through that took time. Um, that took more time than we expected. And once that was done, uh, immediately after the handover, we faced some small issues. We had 1 or 2 functionalities that were all of a sudden only partially working. So we were immediately confronted with some first bugs that we needed to fix.
Um, which was a challenge for the team at Proximus. But then on the other hand, we had, um, our really, our end users that were started to test this new tool in a test environment. And due to that testing, all of a sudden they came up with a lot of new change requests, things that they had forgotten during the ideation phase and that were absolutely important for them to go roll out in, go in, roll out. So, um, so we needed to spend more time in that phase and maybe to share with you some of the, the thoughts or the experiences that we had is that first of all, um, if we would do it again, maybe we would consider to involve our technical teams a little bit sooner in the project so that the adoption and learning phase would start sooner, so that they could become familiar with the functionalities and the technologies sooner in the process.
So that's one. Secondly, to support the speedy process that we wanted to respect, the data flows were set up really quickly. So we set it up, uh, to support going, going into the implementation mode. But once we did the handover and we wanted to incorporate this into our enterprise architecture with a lot of governance around data, we were confronted with some additional investments because the quick data flow setup that we did was not really, uh, for a long term period, uh, stable enough. So we needed to better secure and better monitor and better set up these data flows. So that took some of the investment that we hadn't foreseen. And then thirdly, we did involve our end users in the ideation phase, in the implementation phase. But, um, maybe we didn't pick all the right persons or we didn't pick the person that were really going to do the job on a daily basis.
And maybe we should have been a little bit more selective in who to involve so that we would have avoided some of these small change requests all popping up at the end of the cycle. And then fourth. Last but not least was change management, which we probably underestimated because we had a tofu tool that was made by the users themselves. So it was their tool. It was their baby. They believed in it. It was customized completely. It had all buttons and spaghetti things made for every individual team that wanted something. Um, and then we came with an overall tool that was meant for a broader audience and to cover broader needs, but we couldn't cover all of the customizations that they had in tofu. So they were like resistant a little bit in the beginning and disappointed and pushing back. Um, so I think if we would do it again, we will probably need to take more time to cover that communication and change management aspect, that's for sure.
Um, now maybe let's go to my next slide because I would like to share with you three key takeaways that I want you to remember from this presentation. Um, would we recommend to do a project with Pega? The answer is yes. Yes, we would absolutely go for it. Um, but take into account these takeaways. Um, Pega goes really fast. That's, that's great, but make sure that you are ready to follow that pace. So do your homework well in advance. Make sure that you are well aware of your scope, who you need to involve. When can you do the project? We did it in the summer period. Maybe not ideal. Um, make sure that the people that you want to be involved have the dedication and the focus in that period, because it will be very intense so that you don't need to slow down the speedy train of Pega because that would be a pity.
That's my first key takeaway. Second one is, as I already mentioned, make sure that your technical people who will need to take over afterwards are involved as soon as you can in the process, so that the adoption phase, technical adoption phase goes as fast as it can. And last is change management. Again, communication, communication, communication. We're in that situation right now because I mentioned that we weren't able to respect the one quarter to go live. But the good news is that I can announce now that as of next Monday, we will go live in production. We will start with 90 users to in a pilot mode to test the the application and then hopefully, fingers crossed, we can go in a full rollout. And then I'm talking about almost 300 users as of September. So that's the goal that we face. And then I think I give the word to Curtis for the ending or the closure.
Yeah. Okay. We are not just using Pega for that one. So what do we still do with Pega? First of all, thanks to the Peacock application was built into the cloud. So during the whole process, the upgrade was already done in a very smooth way to Infinity 25. So that's a positive side. But we still have other eight applications with a different route to lives which are still on premise and which are today still in 8.6 version. So we are now in a process of doing the upgrade towards Infinity 25 or 26, because that process on premise has taken quite a long time. So we are challenging the time, but it will take us about 18 months to do the upgrades of our eight route two lives applications on premise towards Infinity 25, and it was a company decision to remain on premise and not to go to the cloud yet.
So that's one of the things next to that. We also heard a lot about legacy transformation. So yes, we also have COBOL applications. I was inspired last year over here by the AWS transform. So yes, we did do a proof of concept with a mobile ordering application, which is 25 years old, still on COBOL. So we did do a kind of Catalyst workshops as well. Is it still the right name? Catalyst workshops. So they did scan the code document, loaded it up in Blueprint. So far, what we learned out of this is that 50% of our COBOL code is no longer used. Something we didn't know before. So that's the good thing. But now, to bring it into production, we are still debating on the figures. Uh, but also a bit. The vision is lacking because our main core ordering system will be upgraded on premise.
And yes, should we build a new mobile ordering system next to it into the cloud? There's still a lot of discussions which are ongoing, but that's what we are still doing at Pega. And you might say, yes, but the world is evolving fast, but within our Proximus company we also a bit and maybe you have you face the same thing as. People do not intend to take decisions these days because the AI world is changing that fast, that maybe we're waiting another two months. There is something new, um, to be very honest and transparent. And also a question that I ask is what is the relevance, especially before coming to PegaWorld this year, what is the relevance of Pega as a workflow application, knowing that you have all those AI tools which might do what Pega is offering. So these are things which are happening and there's AI everywhere.
So there is a bit of stop stand still at this moment to decide. But okay, I saw and heard great new things. So especially the limitation of the tokens cost. So it might give other ideas, uh, open new perspectives to rediscuss those things. But that's a bit where, why we are standing still and taking decisions on Pega. Also the upgrade on premise. So let's see. But yeah, we saw a lot of new things today, uh, this week. So I think it will give another perspective to potentially continue with our legacy transformation. And maybe one day or another, uh, move to the cloud with our eighth route to lives. We have on premise. That's a bit our story. So thank you for your attendance. Not sure if you have any questions. Happy to take them. If I may ask one question. My name is Durga. I'm at BCU engineering Director there.
We also have a couple of use cases of back office operations where we plan to use the Pega Blueprint and then modernize it. We have the full support from business. But when I was looking at your presentation. You did mention that you didn't have the Pega skill set in your IT department, and then you hired the Pega guys to come and do it for you, which is good. But then I was surprised that they took four Sprint to do the development, but nevertheless. So now in the change management, as you saw, saw that all the challenges. But after that, when the support was handed over to IT staff, you will have to hire some Pega folks to do the support. And in future, any enhancement you would have to do. How do you go about doing that? Or you still have dependency with the Pega consultant to come and do some enhancement for you.
In the meantime, since October and now we have trained our upskilled, our internal resources. So yes, we are backing up on that one. But this is one of the things which you should have anticipated us to to avoid this. But in the meantime, we are upskilling our people. But yes, indeed, Constellation was was brand new for us, so we had to learn about it. Also, the first application onto the cloud. Okay, most of the things were operated by by Pega because it's Pega as a service, but it's a change. So and this is something in the whole process about change management we should have anticipated. And that's also where AV was saying, let's bring some more IT people earlier in the process to, to avoid this, this kind of pitfalls. Yeah. Okay. Okay. Thank you. Thank you for joining. Thank you.
Related Resource
Product
App design, revolutionizedOptimize workflow design, fast, with the power of Pega Blueprint®. Set your vision and see your workflow generated on the spot.
Reimagine your processes and turn any workflow into a build-ready application with confidence.
Visualize customer journeys and engagement strategies across all touchpoints and activate them.