PegaWorld 2025: Speeding Up: How Deutsche Telekom Utilizes Blueprint and Reference Case Management to Accelerate Time to Market

PegaWorld 2025: Speeding Up: How Deutsche Telekom Utilizes Blueprint and Reference Case Management to Accelerate Time to Market

I think we begin with our presentation. We slightly modified the title and named it Implementing Processes at the Speed of Light. We have a long running Pega project since 2018, and let's say we learned our lesson. Karsten and myself are representing Deutsche Telekom. It's the largest telecommunications provider of the world. Some greetings to the keynote this morning. Serving more than 250 million mobile customers all across the planet.

And we are also members of a project that is called HRcules. And HRcules had the job to transform more than 800 processes, and we have a fixed retirement deadline at the end of 2025, so that is quite a stretch for us. And while we are doing it, we are under continuous pressure to be more efficient. The world around us doesn't stop turning. So also we need to modify processes, comply to rules and regulations. And still we did our best to become faster and faster. And the ambition for us is to build a process within a day.

And who are us to present that to you? Karsten Karsten Froeschke is our chief architect of the Pega environment and my name is Daniel Wenzel. And I'm taking care of a function called design Authorities, which is the IT and process governance for finance and HR systems.

So some mistakes that we made were I will elaborate later on. But what would you think is the general struggle when you're implementing a variety of processes? What is giving you a hard time? What is making it slow? Sorry. Concentration. Resistance to change.

So we try to phrase it and say it's like an arm wrestling match between business and it. Yeah, business is giving a hard time. I don't understand what I need to deliver. Maybe it's the first time that you've noticed, Pega that I have this experience. And to be honest, from my personal perspective, the biggest shortage or the biggest bottleneck of running a successful digitization is to have people that talk it and talk business and have this translation function on the other side.

You have the IT guys who said, just give me the requirements, we do the deal. And uh, in order to scale a development system. But anyhow, those guys are always the ones under pressure, aren't they? Because business is always finger pointing. Yeah, I always say, yeah, they need to be faster. Everything should be clear. Just do it. And now you're confronted with a backlog of 800 processes.

And I think every one of you is familiar to the conventional way of agile development. So we work with a three phase model where we do a preparation, an elaboration and an implementation. Yeah. Or in other words, definition of ready and definition of done with all the regular planning. So having the sprints, having the delivery targets and so on, but we were also the first ones to pilot Pega Blueprint already in fall 2023. Yeah, because we have this pressure 800 processors five years times five years time. We need to get the thing done.

Unfortunately, Other Pega Blueprint not. Unfortunately. Pega Blueprint has a lot of strengths and speeds up a lot of the elaboration part. From my perspective, you're very quickly in prototyping and getting a feeling and make life easy for people who are in first contact with Pega. Anyhow, it's still a bit of way to go that out of Pega. A finalized, fully integrated system with proper representation of reusable items is going to come.

That is, from our perspective, the biggest weakness which is limiting us that Blueprint for sure doesn't know what we build as reusable models, how our enterprise class structure looks like. And therefore we needed a third way of doing it, which we call reference case model. And Carsten will tell you a bit more in a couple of minutes about it.

But first of all, I want to share a bad news. There is no shortcut in becoming fast, and what might sound strange means that you always need to balance if you want to have a tough life at the beginning and an easy life in the long run, or have an easy life now and then drown in complexity. We experienced both worlds to the extent that we even scrapped one implementation and set it completely new up. So we failed with our first Pega project, but we learned our lesson.

And that means we built a scalable process with proper reusable items, supported by a strong governance that helps us to protect these standards. And that is some of the thoughts I want to share. And I was hoping that my preview is a bit bigger than what I see at the very beginning. We had the arrogance to treat Pega like just another tool, but it's a tool that comes with a certain philosophy. It has certain mechanics you need to respect, be it the difference between an interaction and case, or a case and an assignment is, and how you interplay with those tools. That's something you need to train not only your IT guys, but also your business people. Um, also what I strongly dissent is to build reusable items up front. It's always an academic exercise. It may be that you have a good paper situation, but Mike Tyson once said everyone has a plan until they get the first punch. And it's the same when we do process implementation. So it's by far better than do the first processes. And as we go, implement the reusables instead of the other way around, because it will turn out that reality is different than what it actually started.

Also, one of the mistakes is to start with the most complex process available. Have a knowledge curve. Have a learning curve and and get. There is one of the things that we are trying to make. And our journey starts with the education of the people and that includes IT business. But also what we invested heavily is the intermediates, what we call business architects. So to have this translation function between what is the business requirement and how does that how is that bridge towards it? Maybe Blueprint at any point in time will make this function obsolete, but today that is one of the most crucial functions from my perspective.

And as you go, you industrialize, you pile up your reusables, you get faster and faster and. Then you scale Pega Blueprint. As I said, especially giving an idea about a process where it didn't have an idea. Yeah, we have a lot of knowledge, trained turnover, expertise, knowledge is scarce, is rare. Documentation is for sure excellent. Yeah. Until you take a look and that is giving you a helping hand to get the first versions of it done. And it helps to facilitate to get a first feeling.

And my impression is that what in the past took 1 to 2 weeks getting the people around the table, having all those flip charts around the post-its, the discussion is now pulled together until half a day day workshop to get these things ready and done. And that is really what we consider as the biggest benefit, that it helps to speed up the elaboration and to start on a white page.

I mean, it's a learning curve for business. Acceptance is tricky, I must say, because they always have their legacy system in mind, and getting them away from that and think it in a fresh manner is sometimes tough. And that is also something that limits us, because you need to imagine 800 processes. Now the HRcules implementation project is stopping by and everyone knows now is my chance. Now I need to pull everything in that I can because afterwards they're doing something different. So cutting off at the right point in time is difficult, but also they have no clue.

Very often they see these amazing functions that Pega brings. But it's too many. It's too many to be considered. And my comparison is always if you have kids and family around very often on Christmas, the kids drain in presents, right? It's just piling up more and more and more and more. What's the result on Christmas? They play with the boxes so they get rid of all the toys and play with the boxes.

And that's the part where we say we want to translate that towards our delivery environment. We are taking away the toys. We are focusing on a certain set of functions and have a pick and choose list what you can use for your process. Sure, there may be more innovative, more compelling, more efficient ways, but we focus on the biggest bang for the buck. So we selected these functionalities, these modules that are scalable and that deliver us the majority of the efficiency.

Being it a big topic for us is having functions that assure production readiness, that get rid of redundancies, that automate our document creations to have default SAP interfaces. So these kind of stuff should be available. What we didn't do CDH we limited AI functionalities and what may sound like a limitation of the potential of the project actually made it very, very fast. And that situation is named reference case model. And I'm glad that Karsten is carrying us forward through the approach.

Karsten: Thank you. Daniel. So yeah, let's speak about the reference case model. And the intention was not only to reduce the possibilities here. The intention was really to have an industrial, industrialized approach of the whole delivery chain. And we want to start with this situation here.

So and um, the issue is with the 800 processors we have is we have a lot of business sites. We have to talk with them. Yeah. If you if you're starting implementing a new process family, you have to talk with new business people here, they are not familiar with Pega. They do not know what Pega can do. And we start always with this situation. I'm pretty sure that I hope everyone of you knows the situation here, so that you stand in front of each other. So the business says, what are you able to offer here? And just the project says, yeah, what are your requirements?

So and then everyone has different experiences, different socks. Yeah. What he would expect from the other one. Yeah. And here we try to really come in with a reference case model to yeah to capture the situation and makes it a bit more easier here. Yeah. And so as I said, our goal was not only to capture the technical part of the process implementation here or really start from scratch with an industrialized approach here.

And we defined in the reference case model. This is not only a technical implementation, it's a big part of it. But we also have a lot of tools, documentation, videos here, um, checklists, helper functionalities, all those stuff which is supporting the whole delivery chain here. Yeah.

So and to take a look on our delivery delivery chain here, I think it's quite familiar. It's just a normal one here. You start with an offering. What you are able to do here where you align on the requirements and and stuff like that. Then the business goes into a kind of self preparation. Here. They just playing with their ideas what they wanted to what what they want to achieve here. So maybe they do some drafts of of of things they want to have here. And then the elaboration phase is starting. So where then our business architects comes into the game and tries to to to translate the business requirements into the technical requirements on the platform.

Daniel: Carsten, before you go on, I think we should once general explain what this mystical reference case model is. I'm always failing to do that properly. But it's one master case, right?

Karsten: Yeah. And then at the end, what we try to do from a technical point of view is to capture really all the things we had in the platform here, all our interfaces, root functionalities, routing, master data, all this stuff, and plug it into one big case type. So and what we did in addition. So this would be a template case type. You can use it in Pega. This is out of the box functionality here. But we did one thing in addition.

Here we also Defined the functionalities, the process steps which we call module at the end. We talk about the flow here and that's are all in this case type here. And we put in a configuration cockpit so to say how you can define a process flow. So we make always use of the same case type with slightly different UI screens and slightly different data here. But at the end the case type itself is always the same here. And uh it can be configured here.

And this to, to define and find out how this configuration looks like. So we tried to or not not we do not write it. We make it I would say. Yeah. Um, to really support every single phase here with a specific toolbox which is best fit for this.

Daniel: Exactly. this phase in the delivery chain. Very good. You understood this? Finally.

Karsten: So. Okay, so then let's go ahead shortly. We have the elaboration phase where our BA comes in. Here we have the quality approval. There are two premiums used here. On the one hand side the process design board. This is a business approval. And the design authority which is more the technical approval of that. After the approval was given here we starting with the implementation phase. This is highly standardized. We have only four steps to do there. To have a fully working process at the end. And then it starts with a user acceptance and for sure the life at the end.

To have it really in a different view here. So that are our three major phases here. Exploration, elaboration, implementation. Um, so and for each of these phases we have the right tool created I would say here.

So first of all the business needs to prepare itself here so they can take a look on some video tutorials on our documentation here. So even there are some checklists available available. What should be done. So take a look on your process documentation. Find out all emails which should be sent out. Collect all documents you want to create. So this is sounds very simple, but if we started it was always not complete. So and so I think this is very helpful to start.

Then in the second phase, the elaboration phase where our bas here just take the drafts, the preparations done from the business here and try to Get the real solution done and defined and put all these details in like the data fields, UI mock ups and how things can be done correctly so that the business is aligned with the project, that the process can be implemented here and in the second phase, the implementation phase. Yeah, for sure. We have our configuration cockpit which needs to be filled out. We have a couple of things which needs to be done. But this is shown in a later slide.

So here shortly again the exploration elaboration phase here. So we've shown that for the reference case model for the business we have the documentation videos examples which are already mentioned right now. So on the right hand side there are our business architects comes in. They have a couple of more more specific tools here at hand where they can make use of to fill in. So to draw the flow process flow with a we make use of all here. So it's a very easy to use tool. It's just a flowchart. Everyone can draw a flowchart. So for data model and functions we have an Excel template also known. And for the integration we just writing user stories here. It's it's a pretty simple approach and everyone can make use of these tools I would say.

And after this is done here we're starting with the process design board, which is just looking on. The process of the process makes sense. So if we have access to, for example, a process which only executed eight times a year here, and we see that the process was designed with 20 steps. This is overengineered. So and at this point in time the business or process design board can say, no, this is not the right design here. Please go back and reduce the steps of the process so that it fits to the wheel, to the business value and requirements we have here. Daniel: Allow me to comments. Because I mean we are Germans. We love structure, we love formalities and administration. But this is giving a robust framework to do so. And the second part when we rehearse that my point was be boring. Yeah. And this time you don't want to have fancy discussions. Ideally everyone comes to this meeting and nods and say, yeah, that's like, it should be. We know the forms, we know the structure. We don't need to spend time in understanding how you're presenting that. And same applies for the developers. Yeah, be boring is not a bad thing when it comes to reducing complexity.

Karsten: Kirsten, please. Exactly. So. And then we have the design authority here. So with a reference case model um, the design authority is there to really take care about the patterns and guidelines from a technical perspective here. So taking care that we do not do things which we should not do. So standardization is a big key word here with a reference case model. It's a. It's a bit complicated but the framework itself is a standardized framework. So but nevertheless from time to time we identify a new interface which is needed here. Or maybe a specific integration which needs to be done. And then also the technical design authority comes into the picture here here. And just check if this is within the standard or should be done differently here.

So and first and uh if both Bolts have given their approvals here. The implementation will be started. So we have a couple of processes, which is uh, comes maybe three times into the process design board or something like that. But I think it's a really good approach that you have this kind of quality gates in that you say at this point in time, I get all your requirements here and there, right? So and this is exactly the reason why we do that.

Let's take a look on the implementation from the reference case model. And as I said, um, based on the fact that this is a really a prepared case type, we have not so much to do anymore. So for sure, we start with doing the base settings here. Even if we have this big case type, we need an, uh, we we need to create an own one. We need to create a so-called class business repository object model. That's nothing else. This is a specific class structure which covers the data and the UI screens here of the case type. And uh, yeah. And due to the fact that we have a skill based routing. So we have to define the skills which are used in the whole process here.

The second part is doing the configuration. Yeah. So no one needs to create a flow rule anymore here. So this is just an Excel file and a table which will be um defined in the system here. And you have kind of check marks which functionality you want to use here. Can I delete the case. Can I cancel the case. Can I transfer the case here. So the options in the three dot menu are all can all of this stuff can be controlled by settings in this configuration sets the process flow.

Then we have our communication templates. If you want to send out emails here we have a defined a set of standard emails. But you can also use your own ones in the process. This needs to be configured as well. And each or nearly each process handles with documents and documents which can be attached. But the most of the documents will be generated here. And this needs also be defined and configured. Um, in this configuration.

The third step here is the data model. At the end. You need to define your properties here for the case type itself. Which properties are used in the UI screens? Which properties comes in here from maybe an interface or something like that, or goes out to another interface to a third party systems. And you have to define the mapping here.

And the last step is just to define the UI screens. Um, so we make use of UI kit with sections and the validation rules, and that's it. Yeah. And our colleagues here, they tried to also to automate the first two steps here. So even that can be simplified. And I think this is a really good procedure. With a case ID by the way. Yeah. It's a. Pega case. ID. They develop their Pega case ID to implement this right away. Yeah.

So at the end we have the user acceptance. And even there so the created artifacts can be used just to check what is implemented and what was uh what was the requirements for that. So um, this is also covered by the reference case model here. And at the end, if everything is fine. Maybe we have the technical life and later and later on, the business life of the things. And afterwards we have a checklist. And if all things are done here. So I hope, or maybe most often our business are quite happy here, even if they are recognized that something can be made better or should be made differently. This is kind of a normal stuff if you go live with the process, I think.

And to give you just a rough overview, how the case model looks like here we have our process flow definition, which is a dry all. It's just a normal flowchart here for sure. We have a template for it. And also the for the UI screens. We have a template. We have this kind of process template where we define the process steps the. The properties which are used uh and, uh, the work parties which are participating in this process. All the stuff will be defined in, in the process template. And this two, uh, artifacts are used then to create, uh, the case. And on the right hand side, I just put in, uh, screenshots from our interaction portal from one of our web self-service screens. And, and for sure, we have also standardized email layout, but I think most of you also have this. Yeah. Daniel: So thanks, Carsten. By the way, we also pitched that to Alan Trefler. And I must say he has mixed feelings because in Pega long term strategy, everything which we are describing here should be done by Blueprint right away. Right? That's what we would expect. And I'm highly impressed how fast Pega turns around with Blueprint and how many features come on and so on. A matter of fact is it will take a while. We don't have that time. So that is something how we are going to bridge that to become fast enough.

And it helps us also to describe that good is sometimes good enough, especially in this area. Must not be perfect. As long as we harvest, let's say, 80, 90% of the potential efficiencies around that. So that is one of our things that we are striving through.

But there is a risk. And I teased that before, be boring is a threat for your developers because no offense to anyone, it becomes stupid routine work and that leads to burnout. So you need to also balance the capacity of your developers because it frees up time. At the end of the day, we can invest in innovative topics and elaborate new stuff. And yeah, prepare us for the age of AI. So in order to make that room, we are using that.

And not everything is the reference case model. But everyone knows the time quality, cost triangle. And here we are saying whenever we have time and it's about quality, we take a robust development approach, what we call classical agile development, deep integrations, very specific functions. It's for the big chunky efficiency processes that offer a lot of efficiency, where we are willing to invest this amount. If it's just an easy use case that doesn't necessarily require deep integrations, reusable items, or that we use to to prototype, we set on Blueprint and for everything that shall balance in between, it's the reference case type for our roadmap.

We have four months remaining at HRcules, and we have 136 processes to go. And within these four months, we are very confident that we are going to deliver them on time.

Just to close with the takeaways in order to leave some rooms room for potential questions. Even though that is a very fast development approach, it requires solid preparation, so there is no fast track. You need to build the environment that allows you to be fast. Also, we introduced three different ways of developing and it's a conscious decision which way you want to go. Everything has the right, but you need to question yourself with the processes you experience in your organization. Is it worth the effort or is good good enough?

Discipline and governance. Everything that we build relies on that. We use reusable items and that we pile them up as we go, continuously developing new ones and also force other units. And I know that you have the same challenges in your organizations. You have different silos, different competitions to insist that these things are used. And that helps us to focus on innovation because that is what we're all actually interested here. So that is let's say retiring legacy is the duty work. Yeah. But the icing on the cake is what we can do on top of that.

And I would, looking at the time, close our presentation. At this point in time, we are very happy to take your questions. And I would ask you to go to the mics so that once somebody watches via the internet, also hear your interesting thoughts. Thank you very much.

Q&A Session Question 1: Hello. Oh, okay. Very high, very loud. I have two questions which may be related to each other, actually. Yeah. You talked about, uh, a failure in the beginning, the first trial in the project and what was the main reason, and was the main reason that considering that you had you have 800 processes, you had to to find a way to, to find the common rules, right to, to for the situational Layer Cake was that the main reason why the project failed at the beginning?

Daniel: So there's never one reason that to the very beginning, and I would say it was a combination. First of all, we didn't have experience with Pega in our group and therefore we treated it like just another tool. Unfortunately, we had an implementation partner who did it the same way and who didn't have certified Pega developers on it, but just had Java coders doing it. That in a combination with a very strong business side who had very strange ideas on how these things should run in order to be most efficient.

And at the end, it's always like always in life, there are certain rules you need to stick to, and there are certain points we need to compromise, and others where you can't compromise. And it turns out that by this total focus on efficiency, we made mistakes that didn't allow us to scale and to do upgrades and so on. It was a tough decision, but what I'm very proud of was that we have the chance to rebuild this architecture in a proper, scalable way. And the enterprise class structure, sure. That was a picture of the development before, was then one of the main points where we invested a lot, or one particular person sitting in the back invested a lot in order to refactor that properly so that it allows us to harvest the reusable efficiencies.

Yeah, I have gone through the same. That's why I'm asking. I mean, I failed once and then I did the same, but it works out actually much better. You learn a lot from from failure. So and that is something where we share that very openly, because it's something I hear from a lot of Pega clients as well, and my strong recommendation is I'm a big fan of the Pega Academy and the certification on it, and to invest in education early in the process. Early when you start a project, because you're setting cornerstones that are very tough to turn once you know it better. Thank you. Thank you.

Question 2: Hello, I'm Terry from Groupama. I'm very concerned because I'm a business architect, so I understand what you talk about. I've seen the session you've made the year ago in PegaWorld 24, and at the end, Pega asks you, how can we help you? And I've noticed that you said. We want Blueprint to be able to take account of the existing what we already developed. Absolutely. I do understand that it wasn't happen. So you take another solution.

Daniel: It's not the it's not about not happening. But I'm not an IT guy. Yeah. So but from my perspective, it's the challenge. Everyone is looking to analyzing existing code, identifying the business means that are behind it and incorporating that into your solution design. And that is something that I'm very confident that it will come. It's something which we have at least we are in close talk with Pega. So it's promised to be on the roadmap. Excellent. Yeah, but we can't wait for that. Yeah. And that is why we chose a different path.

And the template you use, uh, you, you you take the template and build a new case each time. And the template could still evaluate. This is this is a template case type at the end. So and you just create a new rule underneath of this case type so that you have the inheritance part and can make use of all these things. For the new ones, and not the old ones that already. Exists. Every time a new case type, uh, but for a really running case type, for a simple process, we need ten rules, not more. So it's a really good, uh, procedure here. And and, uh, to be clear here, this was started before Blueprint was on the market here. So because we had the need to speed up here. So we used this also to, to, to make six, uh, use case, uh, from one which is a common, we build the common template and then make six to, to address the six different cases. Thank you. You're welcome.

Question 3: More questions? Yes, please. I. Uh, also from Germany. So I'm very curious to know about the reference case model which you described. So that looks very interesting. My question is, uh, let's say if your reference case changes with all the advancements coming. Right. So the applications already consumed it to generate the case tape. Are you going to refactor every time or how do you handle it.

Karsten: So this is not an own application. So the reference case model was maybe best fit tailored to for this one use case for cover this 800 processors. Yeah. So for sure we have a couple of internal discussions to make a maybe a framework out of it, which can then also be used in other applications. But as of now it will be handled like a framework. So we have a specific team for that. Yeah. So nearly all rules beside the enhancements or extension points are final. And if someone will change anything you have to raise a request. And this request will be You're checked if this will be done or not be done. So we are really strict in. Yeah. Um, protecting the functionalities and and yeah. As we all know, overwriting final rules is forbidden. All right. Thank you very much. You're welcome.

Question 4: More questions? Yep. At what point do you use the Blueprint? I didn't see in the process. Like, you have the process flow and the documentation and all that. Did you use a Blueprint at all? And if you did, how did that change the process that you were thinking about?

Daniel: It's different use cases. So the more standardized and the more anchored it is in the existing air service, the more we take the reference case model, the more it's adjacent processes or new process playing fields, or maybe even the point that some creative German politics Politic decides that it is a good idea to invent a new law, a new service. It helps us to get this first idea and to kick off this discussion. But we also use that to, uh, to get discussions ongoing with core business and to see where we can be of help.

So yes, the point is totally fair to say, the better it's documented, the more robust it is in existence. With the reference case model, the less we use Blueprint, the more efficiency potential it has, the more out of core. I would say it is, the bigger the effect from Blueprint gets. Okay. Thank you. You're welcome.

Closing: Last chance then. I appreciate your attention and thanks for joining in the session and I wish you all a beautiful day. Thank you, thank you.