BraindumpDiscussion on Demand Management Process and Challenges
Summary:
- The meeting focused on explaining the demand management process used for change requests (CRs) within IT and business units.
- There are automated CR forms to streamline submission and processing, enriched with a value case framework to assess business value.
- Demand management is constrained by the underlying capacity model; hence, priority adjustments occur based on available resources.
- Three types of CRs are tracked: BAU (business as usual), digital Fastlane, and transformation initiatives.
- Each business unit is allowed to submit their top 10 CRs for prioritization, but capacity limitations can lead to backlog and re-evaluation of priorities.
- Environmental issues and design gaps are primary challenges impacting the speed of CR delivery, leading sometimes to delays up to nine months.
- Monthly releases are planned, but capacity and complexity across business units often complicate the process and causes delays.
Content:
Okay. Okay, let's let's… Sorry, I'm seeing you, Mbama. I'm recording already. I might around 12:30 need to join another session as well, but I will remain on hold this side and come back. But I'm not keeping. Okay. Nicole, I think we'll play a big role here. Okay, I'm going to start. We have touched on demand management some like two weeks ago, but didn't go into any detail of the process. So if you can explain to us the process, the steps that you go through in demand management. In my time, we used to call it the CR process.
It's got a fancy name now called demand management. The process you go through and I'm quite interested from what happens within the business unit and then how it goes across to IT. So there, and I suppose we could probably give you guys access to the system as well and maybe just a write-up of what that demand management process does and what it looks like today. So it is an automated flow where the business would complete and give us exactly that form that historically they would manually complete when they submit a CR. So it still is a CR form that they complete with all of the, you know, what is the as-is scenario, what's the to-be requirement, and if they know what systems are impacted.
So all of that is there. It has, however, been enriched with also some, which we refer to as value case framework to establish in terms of the technique, the business value associated to it. So whether it's regulatory, the requirement, I think that was also the study case. Is it a financial benefit? Is it a strategic imperative? Is there some sort of competitive advantage that we will get from that CR or not? So that's in terms of the tool, but right now we are in a process of refining it further because we're also obviously acknowledging that the demand management will only be as robust as the underlining and underpinning capacity model to support the demand because the demand, you know, can kind of exceed the supply to deliver on that.
But what we have done in the interim, and maybe let me pause. That's in terms of the system we ingested. It is the form that you are familiar with. It's just been slightly enriched. We can give you guys access to the system so that you can then have a look at how that would flow and what the business would capture. We have three tracks right now. So we've got our BAU CRs, and then we've got what we call digital Fastlane CR. And then the transformation that's on the go as well. But for each of that, from a tracking perspective, you have to get your CR number.
I'm sure you're familiar with that process as well. This year, then does all of that. It's automated to get this DMC number. Then the DMC number is allocated a CR. So that is still there. Let me pause and then maybe just take some questions on that flow. Okay. Is there a filtering that happens inside the business unit before the CR is logged, or when is the filtering happen within the line of business? Yes. So right now, what they would do is, what we do is we support, roughly give or take, we classified it into 13 lines of business, including there's also IT for IT, what we refer to as IT for IT.
So each line of business will get a top 10 that they can then submit, which is the ratification, that validation that they would do upfront where they would take the requirements to commercial EXCO as well. And they would get some guidance in terms of how they need to be sequencing it as well for them to get to a top 10. Because there's obviously been an acknowledgement on the IT side as well that we can't accommodate everything, but at the same time also being mindful that the business imperatives and the business value that we can derive from these things, we need to be delivering on that.
Hence, I was making reference to the capacity model as well, which is the part that we're looking at because the business, even if they all give us 10, 10, 10, there are some concessions we make on the 10, 10, 10. So for example, your five campaigns, we know we have to kind of accommodate, not even kind of, we have to accommodate those campaigns every year. Summer will happen every winter campaign, back to school campaign, Easter campaign, Black Friday campaign, and so forth. So those are the concessions we don't count that towards the top 10. And if there's a sub CR as well, because IT decided we're going to break down the requirement into smaller chunks, maybe MVPs associated to the business requirement, we don't count that as well.
So even if it's configuration as well, those ones are not part of the top 10 either. So tariff changes, config changes, that would also just go through the process and we've got a consolidated process for that. Yeah, the team, there's no, you've already needed for it. There's no ASD needed for it. The CR is logged and it goes to the teams, to the impacted domains then for implementation on those configuration items. So for example, if the tariff changes, what they do do is just a memo to brief it to the delivery shops. So there are 13 lines.
Are they each prioritizing within themselves before they log a CR? Sorry, what was that? You said there were 13 lines, each of them doing the top 10. So let me just quickly do, I'm just going to put up something. Okay, and then, so what I'm trying to understand is, do they prioritize within their own unit their top 10 before they log a CR? So we've got a portfolio manager, we've got three portfolio managers. I'm just quickly going to, let me just put this up. I'm just trying to understand whether you log all CRs and then start to prioritize or are you filtering it inside the business unit before you're actually logging a CR?
A filter bit prior, however, what we do is we put some of them on backlog as well. Right, so the prioritizer, they would log, and then we would also inform them, but guys, you've maxed out your capacity, you've reached your top 10. So let me just quickly. So does the units go back and say, oh, I want to swap this one for that one? Yes, thank you. So there would be those, but now just in terms of the concessions that we do make, so these are the lines of business that we support, and we've got three portfolio managers.
So this year, this is Google's face over there. And then, but as you can see, we've segmented it and split it into three parts because of the volume of changes that would come through. There's obviously also the business value that we can derive. So it would be 10, oops, 10, 10, 10. That's 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. 12 is IT for IT. So IT for IT is not on this list here. These are just the lines of business. Each one of them would then get four across the portfolio managers that we have.
So this is what the portfolio management team then does with the business. We would get line of sight of the strategic imperatives for that line of business so that we can also overlay that when we get the requirements and through the deliberation when the prioritization happens to then question, you know, is there really merit for you to take this one ahead of the other one? Because if we look at your strategic intent, you're going to derive more value from that one. And hence, I was making reference to some of them even going back onto the backlog.
But to your point, there could be disruptors as well. And then they could ask for us to, we would then ask them to trade off something in favor of this new demand that you've got. Principally, it means you need to have a capacity of 120 a year if you want to do 120 that you list. Exactly. And does that? No, so the capacity part, because it could also be based on the complexity now of that CR, right? Which is why we're saying, we still need to get to that part where, and it's work in flight right now, to build out a more robust capacity model so that upfront we can also see for this demand, does IT actually have the capacity to support whatever the business is asking?
And also adopting more of an agile way of reviewing it. So we wanna do grooming upfront so that we can have a perspective already upfront of the complexity of that CR and which resources would be required for that. We've got something that we refer to as a value case framework, which is on a very high level being embedded, and I'm saying on a very high level embedded into the process because we use this more when we know we've got some sort of a capacity constraint now. And then we say, based on what we've got, because also across the lines of business, they could all have stuff sitting in this bucket over here.
And now it's about contending for capacity across the lines of business, right? Because they might all have the ones got a priority one and the other one's got a priority two and it's eating all the same systems. And now you're constrained in terms of the delivery from that system. They don't have enough resources. So then we would go into a deliberation around what is the business value that we're going to derive from that particular requirement so that we help the teams then to sequence through that. So it's not, yeah, like fully functional and automated completely.
And as you can see, this deck is actually about the improvements within the space. So there's an acknowledgement on the IT side that we need to optimize and streamline the process. This year, in the top part, this is the process that we've already adopted. That's part of the demand management flow. But then these engagements, they happen more within the lines of business. But if we then have to contend for capacity across the lines of business, what we now do is to go, or at least we need to formalize this and take it through the CSB Manco.
So this is only when we're constrained in terms of capacity and we need them to advise us now what needs to give to make provision for maybe this disruptor that you guys have now given us. So we would have these ad hoc sessions, but this year we want to make this more part of the process, like kind of embed it into the process. So yeah, currently it's more ad hoc. So for example, we'll go to someone like Albertus and say, but you know what? We've got this requirement to deliver fiber to the room. You've got your requirement, which we know is priority one, flexible waiting, but it's contending for the same capacity on the Mdoc side.
Can we, through negotiation with him, obviously also then understanding the business value that we'll derive from the other one, he then would then concede and say, okay, you can take mine in the next drop and they can sequence and cycle through it in that way. Do you score these in a way into values? So is there a way one business can have a lot of changes that are very high score, very important, and the other one gets almost nothing because their scores for their stuff are too low? We used to do it like that, but not the Ninsa adoption of the top 10.
However, that does come into play when we now contend with capacity in the IT where we are constrained, where you then have exactly to your point now, right? Like we'll tell Albertus, but that one is less of a priority than this one because we know we need to like pick the competition in the market and we need to launch this now. Can we defer your one, you know, because that's maybe more operationally inclined. So that's part of your Manco prioritization review you've got there. I'm going to call it, it's not formalized like that right now.
It's more ad hoc, but they asked us to bring those things now to Manco. Right now it would have been just an engagement between him and then maybe Google shop like that. And then we'll reach consensus around it. So it's more the as needed basis. Correct. Ad hoc, yeah. So it's a funnel and then another funnel. So how do you, okay, sorry, I want to jump back a moment. When you get to this prioritization, are these CRs then already analyzed so you know the impact, you know the size and the effort involved in these CRs?
No, no. You don't? So you don't? No, so the capacity part, because it could also be based on the complexity now of that CR, right? Of course, of course. Which is why we're saying we still need to get to that part where we, and it's work in flight right now, to build out a more robust capacity model so that upfront we can also see for this demand, does IT actually have the capacity to support whatever the business is asking? And also adopting more of an agile way of reviewing it so we want to do grooming upfront so that we can have a perspective already upfront of the complexity of that CR and which resources would be required for that.
We've got something that we refer to as a value case framework, which is on a very high level being embedded, and I'm saying on a very high level embedded into the process because we, we use this more when we know we've got some sort of a capacity constraint now and then we say, based on what we've got, because also across the lines of business, they could all have stuff sitting in this bucket over here. And now it's about contending for capacity across the lines of business, right? Because they might all have, the one's got a priority one and the other one's got a priority two and it's eating all the same systems.
And now you're constrained in terms of the delivery from that system. They don't have enough resources. So then we would go into a deliberation around what is the business value that we're going to derive from that particular requirement so that we help the teams then to sequence through that. So it's not, yeah, like fully functional and automated completely. And as you can see, this deck is actually about the improvements within the space. So there's an acknowledgement on the IT side that we need to optimize and streamline the process. This year, in the top part, this is the process that we've already adopted.
That's part of the demand management flow. But then these engagements, they happen more within the lines of business. But if we then have to contend for capacity across the lines of business, what we now do is to go, or at least we need to formalize this and take it through the CSB Manco. So this is only when we're constrained in terms of capacity. And we need them to advise us now what needs to give to make provision for maybe this disruptor that you guys have now given us. So we would have these ad hoc sessions, but this year we want to make this more part of the process, like kind of embed it into the process.
So yeah, currently it's more ad hoc. So for example, we'll go to someone like Albertus and say, but you know what? We've got this requirement to deliver fiber to the room. You've got your requirement, which we know is priority one, flexible waiting, but it's contending for the same capacity on the Mdoc side. Can we, through negotiation with him, obviously also then understanding the business value that we'll derive from the other one, he then would then concede and say, okay, you can take mine in the next drop and they can sequence and cycle through it in that way.
Do you, do you score these in a way into values? So is there a way one business can have a lot of changes that are very high score, very important, and the other one gets almost nothing because their scores for their stuff are too low? We used to do it like that, but not the Ninsa adoption of the top 10. However, that does come into play when we now contend with capacity in the IT where we are constrained, where you then have exactly to your point now, right? Like we'll tell Albertus, but that one is less of a priority than this one because we know we need to like pick the competition in the market and we need to launch this now.
Can we defer your one? You know, because that's maybe more operationally inclined. So that's what, that's part of your Manco prioritization review you've got there. I'm going to call it, it's not formalized like that right now. It's more ad hoc, but they asked us to bring those things now to Manco. But it would, right now it would have been just an engagement between him and then maybe Google shop like that. And then reach consensus around it. It's more the as needed basis. Correct. Ad hoc. So it's a funnel and then another funnel. And also, again, socializing if there's any shifts that would come through, because as we're churning out and as it's moving into production, you need to bring the next thing in focus.
So we would then look at what do we have on the backlog, or do you guys have any of these others that you need to bring in as well? So it's a continuous thing that happens, but because we are release-bound, we have to do it every month, but there might be shifts and changes, which is why we do it by every second week. So how many releases are there in a year? So we've got, Tabia can speak to that, but there's monthly releases, which is one release a month, but monthly releases, and I'm excluding emergency releases where required.
So you package a number of CRs for every release for 12 releases a year, or do you have major ones? No, we don't have the split between major and minor releases. We used to do that before, but now we move to monthly releases where we try and every month cycle through a package of CRs, and yeah, that's how we do it now. And it is informed based on the priorities also to see what the priorities, like how they would prioritize what needs to go into a release and so forth, and why we've got that ITBAA to make sure that the factory is aligned with the business priorities as well.
So who leads that final decision on what is in the release? So basically on the delivery shop side, what we do, we look at, because once the CRs come through as whether they are from digital fast lane for development and from for BAU as well for development, we've got the dev managers where we look at the criticals and then align those according to the critical path and then align those with the releases as well. So the critical path to the release. And then that is done from the PMO side. We lead the discussions in conjunction with SQE.
So PMO is like the release leader or do you have a project manager that's managing a release? No, for the release, we've got a release coordinator and the PMO also. PMO leads the release. Okay. Emergency changes and releases, they're always the biggest challenge because they come in from the side. How do you decide when to allow a release and what sort of impact? How's that debate going when there's an emergency that needs to be attended to? Emergency can be a production incident or it can be another disruptor like Anika was explaining now, which is not going to make it for the release timelines that we have for that following month.
So in those cases, we take it through to the, we map out the timelines and then we take it to the CAP for approval to give us emergency date and then we align it to that date and then we implement. Okay, thank you. So from what you experience currently and what you know, what are the biggest factors right now holding back in faster delivery of, I don't want to say releases because once a month is probably as fast as you get from a release perspective, but getting more CRs done, what is the biggest factor that holds back more work being done and getting into production?
Okay, so we've got the first challenge that I can look at is we've got environmental issues sometimes when we package a scope for a release. And then when we go through testing, one of the effects that we get is the environmental issues and where we've got downtimes and that affects our testing timelines and then we end up dropping some of the CRs because we couldn't test all the test cases during that period. And sometimes it's code alignment. So the design, the code that was done, when we get to testing, there's certain design gaps that sometimes we get and those can delay the delivery of the CR because if it goes back to design and then comes back for development again for that portion, sometimes we run out of time to test it in time for that specific release and then we end up implementing the following release or if it's one of those agents, we request an emergency after.
So there can be capacity issues as well sometimes in terms of weather for development or testing. During testing, if we've got too many defects and we've got capacity issue on the DevShop, that affects the defect resolution time. Is this impacted by the number of systems that evolves this particular CR? Yeah, sometimes it's systems and sometimes it's CRs that are across BUs where systems are not necessarily in the CS space, like consumer space. Maybe those systems are in the open self space and that across BUs, it's sometimes a challenge because they have their own priority and we have our own priorities.
And sometimes those priorities, we get to a point where in terms of supporting us for defect resolution, it takes time until we have to escalate and only then get support for those CRs. So sometimes it's across BUs. That's another level of complexity. So who negotiates across BUs to align delivery of CRs? Is that a PMO function? Currently, it's PMO function. We align with the other PMOs on the open self side and on the business engagement as well when changes like those come through. We align with the other BUs and sit and ensure that they understand the priority on our side.
And yes, commitments can be made, but if we have stuff like design gap where maybe one system was missed on the other side, where maybe a system was marked as a regression and actually we were supposed to do some changes on it and it's not on the consumer side, that's where we expose delays, even though the priority was highlighted from the beginning. So between PMO, business engagement in terms of priority, that is handled between us and the BUs, the other BUs. Are there some applications that are consistently giving a problem in delays or incapacity? Are there applications that you always have a bigger challenge with than others?
I think on the consumer side, yes, there are specific ones I'll say. And that hasn't been because almost every CR that we do touches them is AMdocs, because almost every CR we do, there will be a change there. So between development and defect resolutions, sometimes that's where we get the delays and then we have to every time when we get that, we have to manage it by escalation. Why is emergency, emergency can be a production incident or it can be another disruptor like Anika was explaining now, which is not going to make it for the release timelines that we have for that following month.
So in those cases, we take it through to the, we map out the timelines and then we take it to the cap for approval to give us emergency date and then we align it to that date and then we implement. Okay, thank you. So from what you experience currently and what you know, what are the biggest factors right now holding back in faster delivery of, I don't want to say releases because once a month is fast, it's probably as fast as you get from a release perspective, but getting more CRs done, what is the biggest factor that holds back more work being done and getting into production?
Okay, so we've got the first challenge that I can look at is we've got environmental issues sometimes when we package a scope for a release. And then when we go through testing, one of the effects that we get is the environmental issues and where we've got downtimes and that affects our testing timelines and then we end up dropping some of the CRs because we couldn't test all the test cases during that period. And sometimes it's code alignment. So the design, the code that was done when we get to testing, there's certain design gaps that sometimes we get and those can delay the delivery of the CR because if it goes back to design and then comes back for development again for that portion, sometimes we run out of time to test it in time for that specific release and then we end up implementing the following release or if it's one of those agents, we request an emergency after.
So there can be capacity issues as well sometimes in terms of whether for development or testing. During testing, if we've got too many defects and we've got capacity issue on the DevShop, that affects the defect resolution time. Is this impacted by the number of systems that evolves this particular CR? Yeah, sometimes it's systems and sometimes it's CRs that are across BUs where systems are not necessarily in the CS space, like consumer space. Maybe those systems are in the open self space and that across BUs, it's sometimes a challenge because they have their own priority and we have our own priorities.
And sometimes those priorities, we get to a point where in terms of supporting us for defect resolution, it takes time until we have to escalate and only then get support for those CRs. So sometimes it's across BUs. That's another level of complexity. So who negotiates across BUs to align delivery of CRs? Is that a PMO function? Currently, it's a PMO function. We align with the other PMOs on the open self side and on the business engagement as well when changes like those come through. We align with the other BUs and sit and ensure that they understand the priority on our side.
And yes, commitments can be made, but if we have stuff like design gap where maybe one system was missed on the other side, where maybe a system was marked as regression and actually we were supposed to do some changes on it and it's not on the consumer side, that's where we expose delays, even though the priority was highlighted from the beginning. So between PMO, business engagement in terms of priority, that is handled between us and the BUs, the other BUs. Are there some applications that are consistently giving a problem in delays or incapacity? Are there applications that you always have a bigger challenge with than others?
I think on the consumer side, yes, there are specific ones, I'll say, and that hasn't maybe been because almost every CR that we do touches them is Amdocs because almost every CR we do, Across business, we've got like your Unibases or CBS on the other side of the fence of OpenServe. And yeah, those are the ones that I know normally when we have changes that are touching those, we have to manage it closely. Okay, I was in Telkom for many years and it sounds the same. Even the names are the same. Some are going, are falling off, so soon we won't hear them anymore.
Yeah, yeah. Always, always MDOCs and CBS and Unibase. Okay, and MDOCs of course are multiple systems at the moment. You are aware of the Huawei BSS migration? Yes. So do you, just from your view at this moment, when that's a converged platform, do you see that that will assist in making delivery faster? Yeah, I think so. Yes. You will work with less teams. Less teams, yes. And I think even now, I think the little bit we have on Huawei platform, on what we have, when we do changes and they touch MDOCs and they touch Huawei, every time Huawei comes earlier, so I'm expecting... Of course, you're working with the existing OCS.
Yes, yeah. And that delivery is better, faster. It is much better. Yes, it's faster, much better and smoother. So I know in terms of this one, the migration, it's going to be a bigger focus in terms of the applications, in terms of the transactions that they'll be processing, obviously customer orders and stuff. But I'm expecting it to be a smoother process than what we have currently. Let's hope the new system solves everything. I've been there for many years. Yes. Anika, just a little piece then at the end for my understanding. So if I have a release and a few of the top 10s have now gone through a release and they are implemented, how does the next become the top 10?
Is that an automatic process where number 11 and 12 moves up or is there a whole reprioritization done all the time to have a look at what is next? So it's a continuous process, but in instances where we do have that, that's how we would cycle through it. So if they didn't give us the priorities beyond that, and we actually activate that a little bit earlier, so we kind of do that once something moves into the testing stage. So once the CR has been placed to, because I mean, it's going to hit production. So then we would have those discussions, right?
So that happens every second week with the business through the portfolio manager. And then there's also a monthly alignment back with the EXCO execs as well. Okay, thank you. So what I understand the process now, thank you very much for the time. I want to get back to some of the earlier discussions we had, the frustration of a number of people, especially business, were saying it takes nine months to get a change done. So even though we have monthly deliveries, even though I have something in the top 10, it might take nine months. Do you understand why it takes so long or why that is the experience from business that it takes nine months?
Yeah, so I think it's related to those core systems, right? The cross system dependencies. I think the big, most important, the topical issue right now is environments because we've got endless issues with environments, stubbed environments, nothing really. We're making production. I think there's one environment for that in between. There's also these design gaps that would unfold or even business, they're probably not sharing that as well. But once the solution is designed according to what they've signed off in their requirement, they then say no, but we also need, you know, this little thing in addition to that.
So yeah, please don't launch that. And then at that point, it has to go back through the entire process again. So it's a minor, it's like, yeah, a few things that's contributing to it with the biggest issue being environments right now. If I ask for the change today and let's say MDOCs, SNL chain is involved, is the capacity such that I might have to wait a number of months before there is capacity on those teams to develop that? So, no, it's not necessarily the capacity that can only hinder that. The only other thing can just be we have a design and obviously the architects between ourselves and the other side understanding the impact across systems and then having the right design that can be developed and tested.
But obviously, normally we get to a point where certain concessions are made between the two BUs and then the design is agreed upon. And then we go to development and only interesting certain things are uncovered. And that seeps like those, if we look at the impact is more on the design gaps that we have to go back and fix and obviously redevelopment and then testing. So it's not all of them, but it won't just be resources allocation only. As long as all of us understand the capacity, I mean the priority of the change, the resources can be allocated, but when we get to design, the timing to align on that design, understanding the open source systems, how they impact consumer and vice versa, and having that design and then we get to development.
And then when we do the actual testing, getting support across as well for defect resolution, because that's where sometimes we have those issues or where they can say CVS on environment is actually not aligned with the database. This is the issue, then move to another environment. So some of those CRs will end up moving across multiple environments before we can get it right because they've got their own process of aligning the applications, the databases, which is not necessarily, when I look at it, not the same as what we do on the CSB side. So you'll find when they upgrade or update their version or anything, databases, they will select which environment they actually upgrade and sometimes when we get to testing that we find those gaps, yeah.
Yeah, I'm trying to understand how will I answer to a business unit that it takes nine months? Normally that answer is capacity. You're saying it's not capacity, it's more... It's not only. Yeah, it's more complexity across... Complexity comes, yes. And the different business units. I'm surprised by that one, but that's fine. That's good information. So if you could make the call, what would you improve to reduce that time to production of a change? So obviously, in terms of alignment on the environments and as well as the prioritization across business units, to have sort of a group prioritization type forum, maybe, something like that can help as well.
So, yeah, I hear that. So alignment across the business units, is there a forum for that, or that is just ad hoc between the PMOs? It is ad hoc at the moment between PMOs. It's not a standard across all four for the prioritization of changes. Okay. And the allocation of resources, yeah, it's not standard. Okay, thank you. And then maybe just in addition to that, it's also the third party dependencies that we also have, right? Yeah, so sometimes with these resellers and so forth, then if we take PEP as an example, why some of those things would take long, at the time when we need our dev cycle, they might not be ready and so forth.
So there's also those external challenges as well, beyond just alignment across the BUs, third party dependencies. Okay, thank you. Yeah, thanks for that, Annika. Okay, I'm through. Anybody else? Jakob, Wensel? No, I think we covered everything. It, I must say, it took me back to the years when I did the cost of the entry 1.24. Yes, yes. We've all been there. It feels like a monster you just can't win. It just keeps coming back. Blessing, you wanted to add something? Thanks, Gopal. No, I believe, I was thinking, I believe we've already covered what keeps Annika and Gabi are not sleeping at night because of that.
That's Blessing's favourite question. And one more thing, Gopal, I think most of the documents, I'm glad to confirm with you, they were shared here on the graph. Yes. Yes. Yes. But you know, when you show a slide without what's on the slide, you don't necessarily understand what a person means. And then Annika also explained that this is a view of how they want to do it, it's not necessarily what they're doing yet. So all that is important to know. To the group, thank you very much. Then we're done. Thank you. Have a good one. Okay, I will.
Okay. Thank you, everybody. Thank you, guys. Thank you. Okay. Hey, Gopal, thank you, sir. I think it went very well. Can you hear me? Yes, I can hear you. Thank you, sir. I think it went very well. Yeah, thank you very much. Just want to say something.
- The meeting focused on explaining the demand management process used for change requests (CRs) within IT and business units.
- There are automated CR forms to streamline submission and processing, enriched with a value case framework to assess business value.
- Demand management is constrained by the underlying capacity model; hence, priority adjustments occur based on available resources.
- Three types of CRs are tracked: BAU (business as usual), digital Fastlane, and transformation initiatives.
- Each business unit is allowed to submit their top 10 CRs for prioritization, but capacity limitations can lead to backlog and re-evaluation of priorities.
- Environmental issues and design gaps are primary challenges impacting the speed of CR delivery, leading sometimes to delays up to nine months.
- Monthly releases are planned, but capacity and complexity across business units often complicate the process and causes delays.
Content:
Okay. Okay, let's let's… Sorry, I'm seeing you, Mbama. I'm recording already. I might around 12:30 need to join another session as well, but I will remain on hold this side and come back. But I'm not keeping. Okay. Nicole, I think we'll play a big role here. Okay, I'm going to start. We have touched on demand management some like two weeks ago, but didn't go into any detail of the process. So if you can explain to us the process, the steps that you go through in demand management. In my time, we used to call it the CR process.
It's got a fancy name now called demand management. The process you go through and I'm quite interested from what happens within the business unit and then how it goes across to IT. So there, and I suppose we could probably give you guys access to the system as well and maybe just a write-up of what that demand management process does and what it looks like today. So it is an automated flow where the business would complete and give us exactly that form that historically they would manually complete when they submit a CR. So it still is a CR form that they complete with all of the, you know, what is the as-is scenario, what's the to-be requirement, and if they know what systems are impacted.
So all of that is there. It has, however, been enriched with also some, which we refer to as value case framework to establish in terms of the technique, the business value associated to it. So whether it's regulatory, the requirement, I think that was also the study case. Is it a financial benefit? Is it a strategic imperative? Is there some sort of competitive advantage that we will get from that CR or not? So that's in terms of the tool, but right now we are in a process of refining it further because we're also obviously acknowledging that the demand management will only be as robust as the underlining and underpinning capacity model to support the demand because the demand, you know, can kind of exceed the supply to deliver on that.
But what we have done in the interim, and maybe let me pause. That's in terms of the system we ingested. It is the form that you are familiar with. It's just been slightly enriched. We can give you guys access to the system so that you can then have a look at how that would flow and what the business would capture. We have three tracks right now. So we've got our BAU CRs, and then we've got what we call digital Fastlane CR. And then the transformation that's on the go as well. But for each of that, from a tracking perspective, you have to get your CR number.
I'm sure you're familiar with that process as well. This year, then does all of that. It's automated to get this DMC number. Then the DMC number is allocated a CR. So that is still there. Let me pause and then maybe just take some questions on that flow. Okay. Is there a filtering that happens inside the business unit before the CR is logged, or when is the filtering happen within the line of business? Yes. So right now, what they would do is, what we do is we support, roughly give or take, we classified it into 13 lines of business, including there's also IT for IT, what we refer to as IT for IT.
So each line of business will get a top 10 that they can then submit, which is the ratification, that validation that they would do upfront where they would take the requirements to commercial EXCO as well. And they would get some guidance in terms of how they need to be sequencing it as well for them to get to a top 10. Because there's obviously been an acknowledgement on the IT side as well that we can't accommodate everything, but at the same time also being mindful that the business imperatives and the business value that we can derive from these things, we need to be delivering on that.
Hence, I was making reference to the capacity model as well, which is the part that we're looking at because the business, even if they all give us 10, 10, 10, there are some concessions we make on the 10, 10, 10. So for example, your five campaigns, we know we have to kind of accommodate, not even kind of, we have to accommodate those campaigns every year. Summer will happen every winter campaign, back to school campaign, Easter campaign, Black Friday campaign, and so forth. So those are the concessions we don't count that towards the top 10. And if there's a sub CR as well, because IT decided we're going to break down the requirement into smaller chunks, maybe MVPs associated to the business requirement, we don't count that as well.
So even if it's configuration as well, those ones are not part of the top 10 either. So tariff changes, config changes, that would also just go through the process and we've got a consolidated process for that. Yeah, the team, there's no, you've already needed for it. There's no ASD needed for it. The CR is logged and it goes to the teams, to the impacted domains then for implementation on those configuration items. So for example, if the tariff changes, what they do do is just a memo to brief it to the delivery shops. So there are 13 lines.
Are they each prioritizing within themselves before they log a CR? Sorry, what was that? You said there were 13 lines, each of them doing the top 10. So let me just quickly do, I'm just going to put up something. Okay, and then, so what I'm trying to understand is, do they prioritize within their own unit their top 10 before they log a CR? So we've got a portfolio manager, we've got three portfolio managers. I'm just quickly going to, let me just put this up. I'm just trying to understand whether you log all CRs and then start to prioritize or are you filtering it inside the business unit before you're actually logging a CR?
A filter bit prior, however, what we do is we put some of them on backlog as well. Right, so the prioritizer, they would log, and then we would also inform them, but guys, you've maxed out your capacity, you've reached your top 10. So let me just quickly. So does the units go back and say, oh, I want to swap this one for that one? Yes, thank you. So there would be those, but now just in terms of the concessions that we do make, so these are the lines of business that we support, and we've got three portfolio managers.
So this year, this is Google's face over there. And then, but as you can see, we've segmented it and split it into three parts because of the volume of changes that would come through. There's obviously also the business value that we can derive. So it would be 10, oops, 10, 10, 10. That's 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. 12 is IT for IT. So IT for IT is not on this list here. These are just the lines of business. Each one of them would then get four across the portfolio managers that we have.
So this is what the portfolio management team then does with the business. We would get line of sight of the strategic imperatives for that line of business so that we can also overlay that when we get the requirements and through the deliberation when the prioritization happens to then question, you know, is there really merit for you to take this one ahead of the other one? Because if we look at your strategic intent, you're going to derive more value from that one. And hence, I was making reference to some of them even going back onto the backlog.
But to your point, there could be disruptors as well. And then they could ask for us to, we would then ask them to trade off something in favor of this new demand that you've got. Principally, it means you need to have a capacity of 120 a year if you want to do 120 that you list. Exactly. And does that? No, so the capacity part, because it could also be based on the complexity now of that CR, right? Which is why we're saying, we still need to get to that part where, and it's work in flight right now, to build out a more robust capacity model so that upfront we can also see for this demand, does IT actually have the capacity to support whatever the business is asking?
And also adopting more of an agile way of reviewing it. So we wanna do grooming upfront so that we can have a perspective already upfront of the complexity of that CR and which resources would be required for that. We've got something that we refer to as a value case framework, which is on a very high level being embedded, and I'm saying on a very high level embedded into the process because we use this more when we know we've got some sort of a capacity constraint now. And then we say, based on what we've got, because also across the lines of business, they could all have stuff sitting in this bucket over here.
And now it's about contending for capacity across the lines of business, right? Because they might all have the ones got a priority one and the other one's got a priority two and it's eating all the same systems. And now you're constrained in terms of the delivery from that system. They don't have enough resources. So then we would go into a deliberation around what is the business value that we're going to derive from that particular requirement so that we help the teams then to sequence through that. So it's not, yeah, like fully functional and automated completely.
And as you can see, this deck is actually about the improvements within the space. So there's an acknowledgement on the IT side that we need to optimize and streamline the process. This year, in the top part, this is the process that we've already adopted. That's part of the demand management flow. But then these engagements, they happen more within the lines of business. But if we then have to contend for capacity across the lines of business, what we now do is to go, or at least we need to formalize this and take it through the CSB Manco.
So this is only when we're constrained in terms of capacity and we need them to advise us now what needs to give to make provision for maybe this disruptor that you guys have now given us. So we would have these ad hoc sessions, but this year we want to make this more part of the process, like kind of embed it into the process. So yeah, currently it's more ad hoc. So for example, we'll go to someone like Albertus and say, but you know what? We've got this requirement to deliver fiber to the room. You've got your requirement, which we know is priority one, flexible waiting, but it's contending for the same capacity on the Mdoc side.
Can we, through negotiation with him, obviously also then understanding the business value that we'll derive from the other one, he then would then concede and say, okay, you can take mine in the next drop and they can sequence and cycle through it in that way. Do you score these in a way into values? So is there a way one business can have a lot of changes that are very high score, very important, and the other one gets almost nothing because their scores for their stuff are too low? We used to do it like that, but not the Ninsa adoption of the top 10.
However, that does come into play when we now contend with capacity in the IT where we are constrained, where you then have exactly to your point now, right? Like we'll tell Albertus, but that one is less of a priority than this one because we know we need to like pick the competition in the market and we need to launch this now. Can we defer your one, you know, because that's maybe more operationally inclined. So that's part of your Manco prioritization review you've got there. I'm going to call it, it's not formalized like that right now.
It's more ad hoc, but they asked us to bring those things now to Manco. Right now it would have been just an engagement between him and then maybe Google shop like that. And then we'll reach consensus around it. So it's more the as needed basis. Correct. Ad hoc, yeah. So it's a funnel and then another funnel. So how do you, okay, sorry, I want to jump back a moment. When you get to this prioritization, are these CRs then already analyzed so you know the impact, you know the size and the effort involved in these CRs?
No, no. You don't? So you don't? No, so the capacity part, because it could also be based on the complexity now of that CR, right? Of course, of course. Which is why we're saying we still need to get to that part where we, and it's work in flight right now, to build out a more robust capacity model so that upfront we can also see for this demand, does IT actually have the capacity to support whatever the business is asking? And also adopting more of an agile way of reviewing it so we want to do grooming upfront so that we can have a perspective already upfront of the complexity of that CR and which resources would be required for that.
We've got something that we refer to as a value case framework, which is on a very high level being embedded, and I'm saying on a very high level embedded into the process because we, we use this more when we know we've got some sort of a capacity constraint now and then we say, based on what we've got, because also across the lines of business, they could all have stuff sitting in this bucket over here. And now it's about contending for capacity across the lines of business, right? Because they might all have, the one's got a priority one and the other one's got a priority two and it's eating all the same systems.
And now you're constrained in terms of the delivery from that system. They don't have enough resources. So then we would go into a deliberation around what is the business value that we're going to derive from that particular requirement so that we help the teams then to sequence through that. So it's not, yeah, like fully functional and automated completely. And as you can see, this deck is actually about the improvements within the space. So there's an acknowledgement on the IT side that we need to optimize and streamline the process. This year, in the top part, this is the process that we've already adopted.
That's part of the demand management flow. But then these engagements, they happen more within the lines of business. But if we then have to contend for capacity across the lines of business, what we now do is to go, or at least we need to formalize this and take it through the CSB Manco. So this is only when we're constrained in terms of capacity. And we need them to advise us now what needs to give to make provision for maybe this disruptor that you guys have now given us. So we would have these ad hoc sessions, but this year we want to make this more part of the process, like kind of embed it into the process.
So yeah, currently it's more ad hoc. So for example, we'll go to someone like Albertus and say, but you know what? We've got this requirement to deliver fiber to the room. You've got your requirement, which we know is priority one, flexible waiting, but it's contending for the same capacity on the Mdoc side. Can we, through negotiation with him, obviously also then understanding the business value that we'll derive from the other one, he then would then concede and say, okay, you can take mine in the next drop and they can sequence and cycle through it in that way.
Do you, do you score these in a way into values? So is there a way one business can have a lot of changes that are very high score, very important, and the other one gets almost nothing because their scores for their stuff are too low? We used to do it like that, but not the Ninsa adoption of the top 10. However, that does come into play when we now contend with capacity in the IT where we are constrained, where you then have exactly to your point now, right? Like we'll tell Albertus, but that one is less of a priority than this one because we know we need to like pick the competition in the market and we need to launch this now.
Can we defer your one? You know, because that's maybe more operationally inclined. So that's what, that's part of your Manco prioritization review you've got there. I'm going to call it, it's not formalized like that right now. It's more ad hoc, but they asked us to bring those things now to Manco. But it would, right now it would have been just an engagement between him and then maybe Google shop like that. And then reach consensus around it. It's more the as needed basis. Correct. Ad hoc. So it's a funnel and then another funnel. And also, again, socializing if there's any shifts that would come through, because as we're churning out and as it's moving into production, you need to bring the next thing in focus.
So we would then look at what do we have on the backlog, or do you guys have any of these others that you need to bring in as well? So it's a continuous thing that happens, but because we are release-bound, we have to do it every month, but there might be shifts and changes, which is why we do it by every second week. So how many releases are there in a year? So we've got, Tabia can speak to that, but there's monthly releases, which is one release a month, but monthly releases, and I'm excluding emergency releases where required.
So you package a number of CRs for every release for 12 releases a year, or do you have major ones? No, we don't have the split between major and minor releases. We used to do that before, but now we move to monthly releases where we try and every month cycle through a package of CRs, and yeah, that's how we do it now. And it is informed based on the priorities also to see what the priorities, like how they would prioritize what needs to go into a release and so forth, and why we've got that ITBAA to make sure that the factory is aligned with the business priorities as well.
So who leads that final decision on what is in the release? So basically on the delivery shop side, what we do, we look at, because once the CRs come through as whether they are from digital fast lane for development and from for BAU as well for development, we've got the dev managers where we look at the criticals and then align those according to the critical path and then align those with the releases as well. So the critical path to the release. And then that is done from the PMO side. We lead the discussions in conjunction with SQE.
So PMO is like the release leader or do you have a project manager that's managing a release? No, for the release, we've got a release coordinator and the PMO also. PMO leads the release. Okay. Emergency changes and releases, they're always the biggest challenge because they come in from the side. How do you decide when to allow a release and what sort of impact? How's that debate going when there's an emergency that needs to be attended to? Emergency can be a production incident or it can be another disruptor like Anika was explaining now, which is not going to make it for the release timelines that we have for that following month.
So in those cases, we take it through to the, we map out the timelines and then we take it to the CAP for approval to give us emergency date and then we align it to that date and then we implement. Okay, thank you. So from what you experience currently and what you know, what are the biggest factors right now holding back in faster delivery of, I don't want to say releases because once a month is probably as fast as you get from a release perspective, but getting more CRs done, what is the biggest factor that holds back more work being done and getting into production?
Okay, so we've got the first challenge that I can look at is we've got environmental issues sometimes when we package a scope for a release. And then when we go through testing, one of the effects that we get is the environmental issues and where we've got downtimes and that affects our testing timelines and then we end up dropping some of the CRs because we couldn't test all the test cases during that period. And sometimes it's code alignment. So the design, the code that was done, when we get to testing, there's certain design gaps that sometimes we get and those can delay the delivery of the CR because if it goes back to design and then comes back for development again for that portion, sometimes we run out of time to test it in time for that specific release and then we end up implementing the following release or if it's one of those agents, we request an emergency after.
So there can be capacity issues as well sometimes in terms of weather for development or testing. During testing, if we've got too many defects and we've got capacity issue on the DevShop, that affects the defect resolution time. Is this impacted by the number of systems that evolves this particular CR? Yeah, sometimes it's systems and sometimes it's CRs that are across BUs where systems are not necessarily in the CS space, like consumer space. Maybe those systems are in the open self space and that across BUs, it's sometimes a challenge because they have their own priority and we have our own priorities.
And sometimes those priorities, we get to a point where in terms of supporting us for defect resolution, it takes time until we have to escalate and only then get support for those CRs. So sometimes it's across BUs. That's another level of complexity. So who negotiates across BUs to align delivery of CRs? Is that a PMO function? Currently, it's PMO function. We align with the other PMOs on the open self side and on the business engagement as well when changes like those come through. We align with the other BUs and sit and ensure that they understand the priority on our side.
And yes, commitments can be made, but if we have stuff like design gap where maybe one system was missed on the other side, where maybe a system was marked as a regression and actually we were supposed to do some changes on it and it's not on the consumer side, that's where we expose delays, even though the priority was highlighted from the beginning. So between PMO, business engagement in terms of priority, that is handled between us and the BUs, the other BUs. Are there some applications that are consistently giving a problem in delays or incapacity? Are there applications that you always have a bigger challenge with than others?
I think on the consumer side, yes, there are specific ones I'll say. And that hasn't been because almost every CR that we do touches them is AMdocs, because almost every CR we do, there will be a change there. So between development and defect resolutions, sometimes that's where we get the delays and then we have to every time when we get that, we have to manage it by escalation. Why is emergency, emergency can be a production incident or it can be another disruptor like Anika was explaining now, which is not going to make it for the release timelines that we have for that following month.
So in those cases, we take it through to the, we map out the timelines and then we take it to the cap for approval to give us emergency date and then we align it to that date and then we implement. Okay, thank you. So from what you experience currently and what you know, what are the biggest factors right now holding back in faster delivery of, I don't want to say releases because once a month is fast, it's probably as fast as you get from a release perspective, but getting more CRs done, what is the biggest factor that holds back more work being done and getting into production?
Okay, so we've got the first challenge that I can look at is we've got environmental issues sometimes when we package a scope for a release. And then when we go through testing, one of the effects that we get is the environmental issues and where we've got downtimes and that affects our testing timelines and then we end up dropping some of the CRs because we couldn't test all the test cases during that period. And sometimes it's code alignment. So the design, the code that was done when we get to testing, there's certain design gaps that sometimes we get and those can delay the delivery of the CR because if it goes back to design and then comes back for development again for that portion, sometimes we run out of time to test it in time for that specific release and then we end up implementing the following release or if it's one of those agents, we request an emergency after.
So there can be capacity issues as well sometimes in terms of whether for development or testing. During testing, if we've got too many defects and we've got capacity issue on the DevShop, that affects the defect resolution time. Is this impacted by the number of systems that evolves this particular CR? Yeah, sometimes it's systems and sometimes it's CRs that are across BUs where systems are not necessarily in the CS space, like consumer space. Maybe those systems are in the open self space and that across BUs, it's sometimes a challenge because they have their own priority and we have our own priorities.
And sometimes those priorities, we get to a point where in terms of supporting us for defect resolution, it takes time until we have to escalate and only then get support for those CRs. So sometimes it's across BUs. That's another level of complexity. So who negotiates across BUs to align delivery of CRs? Is that a PMO function? Currently, it's a PMO function. We align with the other PMOs on the open self side and on the business engagement as well when changes like those come through. We align with the other BUs and sit and ensure that they understand the priority on our side.
And yes, commitments can be made, but if we have stuff like design gap where maybe one system was missed on the other side, where maybe a system was marked as regression and actually we were supposed to do some changes on it and it's not on the consumer side, that's where we expose delays, even though the priority was highlighted from the beginning. So between PMO, business engagement in terms of priority, that is handled between us and the BUs, the other BUs. Are there some applications that are consistently giving a problem in delays or incapacity? Are there applications that you always have a bigger challenge with than others?
I think on the consumer side, yes, there are specific ones, I'll say, and that hasn't maybe been because almost every CR that we do touches them is Amdocs because almost every CR we do, Across business, we've got like your Unibases or CBS on the other side of the fence of OpenServe. And yeah, those are the ones that I know normally when we have changes that are touching those, we have to manage it closely. Okay, I was in Telkom for many years and it sounds the same. Even the names are the same. Some are going, are falling off, so soon we won't hear them anymore.
Yeah, yeah. Always, always MDOCs and CBS and Unibase. Okay, and MDOCs of course are multiple systems at the moment. You are aware of the Huawei BSS migration? Yes. So do you, just from your view at this moment, when that's a converged platform, do you see that that will assist in making delivery faster? Yeah, I think so. Yes. You will work with less teams. Less teams, yes. And I think even now, I think the little bit we have on Huawei platform, on what we have, when we do changes and they touch MDOCs and they touch Huawei, every time Huawei comes earlier, so I'm expecting... Of course, you're working with the existing OCS.
Yes, yeah. And that delivery is better, faster. It is much better. Yes, it's faster, much better and smoother. So I know in terms of this one, the migration, it's going to be a bigger focus in terms of the applications, in terms of the transactions that they'll be processing, obviously customer orders and stuff. But I'm expecting it to be a smoother process than what we have currently. Let's hope the new system solves everything. I've been there for many years. Yes. Anika, just a little piece then at the end for my understanding. So if I have a release and a few of the top 10s have now gone through a release and they are implemented, how does the next become the top 10?
Is that an automatic process where number 11 and 12 moves up or is there a whole reprioritization done all the time to have a look at what is next? So it's a continuous process, but in instances where we do have that, that's how we would cycle through it. So if they didn't give us the priorities beyond that, and we actually activate that a little bit earlier, so we kind of do that once something moves into the testing stage. So once the CR has been placed to, because I mean, it's going to hit production. So then we would have those discussions, right?
So that happens every second week with the business through the portfolio manager. And then there's also a monthly alignment back with the EXCO execs as well. Okay, thank you. So what I understand the process now, thank you very much for the time. I want to get back to some of the earlier discussions we had, the frustration of a number of people, especially business, were saying it takes nine months to get a change done. So even though we have monthly deliveries, even though I have something in the top 10, it might take nine months. Do you understand why it takes so long or why that is the experience from business that it takes nine months?
Yeah, so I think it's related to those core systems, right? The cross system dependencies. I think the big, most important, the topical issue right now is environments because we've got endless issues with environments, stubbed environments, nothing really. We're making production. I think there's one environment for that in between. There's also these design gaps that would unfold or even business, they're probably not sharing that as well. But once the solution is designed according to what they've signed off in their requirement, they then say no, but we also need, you know, this little thing in addition to that.
So yeah, please don't launch that. And then at that point, it has to go back through the entire process again. So it's a minor, it's like, yeah, a few things that's contributing to it with the biggest issue being environments right now. If I ask for the change today and let's say MDOCs, SNL chain is involved, is the capacity such that I might have to wait a number of months before there is capacity on those teams to develop that? So, no, it's not necessarily the capacity that can only hinder that. The only other thing can just be we have a design and obviously the architects between ourselves and the other side understanding the impact across systems and then having the right design that can be developed and tested.
But obviously, normally we get to a point where certain concessions are made between the two BUs and then the design is agreed upon. And then we go to development and only interesting certain things are uncovered. And that seeps like those, if we look at the impact is more on the design gaps that we have to go back and fix and obviously redevelopment and then testing. So it's not all of them, but it won't just be resources allocation only. As long as all of us understand the capacity, I mean the priority of the change, the resources can be allocated, but when we get to design, the timing to align on that design, understanding the open source systems, how they impact consumer and vice versa, and having that design and then we get to development.
And then when we do the actual testing, getting support across as well for defect resolution, because that's where sometimes we have those issues or where they can say CVS on environment is actually not aligned with the database. This is the issue, then move to another environment. So some of those CRs will end up moving across multiple environments before we can get it right because they've got their own process of aligning the applications, the databases, which is not necessarily, when I look at it, not the same as what we do on the CSB side. So you'll find when they upgrade or update their version or anything, databases, they will select which environment they actually upgrade and sometimes when we get to testing that we find those gaps, yeah.
Yeah, I'm trying to understand how will I answer to a business unit that it takes nine months? Normally that answer is capacity. You're saying it's not capacity, it's more... It's not only. Yeah, it's more complexity across... Complexity comes, yes. And the different business units. I'm surprised by that one, but that's fine. That's good information. So if you could make the call, what would you improve to reduce that time to production of a change? So obviously, in terms of alignment on the environments and as well as the prioritization across business units, to have sort of a group prioritization type forum, maybe, something like that can help as well.
So, yeah, I hear that. So alignment across the business units, is there a forum for that, or that is just ad hoc between the PMOs? It is ad hoc at the moment between PMOs. It's not a standard across all four for the prioritization of changes. Okay. And the allocation of resources, yeah, it's not standard. Okay, thank you. And then maybe just in addition to that, it's also the third party dependencies that we also have, right? Yeah, so sometimes with these resellers and so forth, then if we take PEP as an example, why some of those things would take long, at the time when we need our dev cycle, they might not be ready and so forth.
So there's also those external challenges as well, beyond just alignment across the BUs, third party dependencies. Okay, thank you. Yeah, thanks for that, Annika. Okay, I'm through. Anybody else? Jakob, Wensel? No, I think we covered everything. It, I must say, it took me back to the years when I did the cost of the entry 1.24. Yes, yes. We've all been there. It feels like a monster you just can't win. It just keeps coming back. Blessing, you wanted to add something? Thanks, Gopal. No, I believe, I was thinking, I believe we've already covered what keeps Annika and Gabi are not sleeping at night because of that.
That's Blessing's favourite question. And one more thing, Gopal, I think most of the documents, I'm glad to confirm with you, they were shared here on the graph. Yes. Yes. Yes. But you know, when you show a slide without what's on the slide, you don't necessarily understand what a person means. And then Annika also explained that this is a view of how they want to do it, it's not necessarily what they're doing yet. So all that is important to know. To the group, thank you very much. Then we're done. Thank you. Have a good one. Okay, I will.
Okay. Thank you, everybody. Thank you, guys. Thank you. Okay. Hey, Gopal, thank you, sir. I think it went very well. Can you hear me? Yes, I can hear you. Thank you, sir. I think it went very well. Yeah, thank you very much. Just want to say something.