Know before you go: How to reduce SAP Licensing costs before moving to S/4HANA & SAP Cloud ERP

My name is Monica Rojas, and I'm with the marketing team here at EPI-USE Labs. I'm here today with Roy Topman, SAP security and GRC architect with EPI-USE Labs. Before we start, a quick note on questions. We'll have time at the end of the presentation to answer all your questions, so please feel free to drop them into the go to webinar panel as we go. Thank you, Roy, for being here, and I'll let you take it from here. Thanks very much, Monica. And so and thanks to everyone who's joined today. So we'll this is me. And as Monica said, I'm the principal cybersecurity and GRC architect in Labs in our global service team for privacy and security. And part of my job is to help people with the new fully licensing, full user equivalent licensing for Saturnize. So, well, that's the our topic for today. Just a quick word about our company. So we, we operate in, in about fifty countries and have, people in forty two of those. We're very experienced in the SAP area, and we help our clients in a variety of SAP related projects. So the agenda that we're going to look at today, we're going to start off to, talk a little bit about, the migration to SAP Cloud. Then I will try and explain the concepts of the full user equivalent and the star measurement program that SAP uses. I'll talk about our free licensing assessment and give you a quick demo of the tool. And then as Monica said, we'll try and answer any questions that you have at the end of the session. First, of all, we've got a question for you. So we're going to ask you what your biggest concern is with SAP licensing as part of your SAP or your s four migration. So, Monica, if you could please start the poll. Yes. Launching the poll. Thank you. So we want to see whether you what your concerns are with this, and then we'll see if we can answer those concerns as we go forward. Yeah. So we've got a fairly even split across people who need to understand the FURU requirements, those who are looking to reduce their licensing costs, and people who are still in the early planning stages. So, luckily, our topics today cover, really, all those areas. So we're looking towards people who are already on that RISE journey and beginning to have concerns about the licensing, but also to the people who are yet to start that journey and try and give them some ideas of how they can sort of preempt problems with the licensing and try and get a leg up on that as they start. So let's continue. First, of all, we'll talk about the migration to SAP ERP Cloud, and sometimes still referred to as RISE. I will use the word RISE. It's it's easier to obviously, easier to say. And so what do we have to think about when we're moving from ECC to s four? There's quite a list there of things, you know, Fiori authorizations, that's new. Is it something that we're going to be, concentrating on, or is it something that, you know, a few of our users will be using, people still using the GUI, talk about the management of master data and the testing processes. But a couple of the most important things that we need to think about in the contract negotiations are data volume and licensing costs. Those are the two things that are going to really drive costs when we're moving to s four. So I know Dan has spoken quite a lot about the data volume part, and so I'm going to concentrate today on the licensing costs. So what are the changes now that, moving to s four? So in ECC, users were licensed individually as a level, you know, so that you could have professional users and limited professional self-service and so on. And that was based on a rough description of the functionality measured by the access that users had to a specific range of transactions. It was all fairly open to interpretation. There was a single annual self disclosure and assessment, so it was reasonably easy to, get on top of that and make sure things were in order, for the, assessment, although it was a little bit, wishy washy, let's say. Now when we move to s four, SAP has introduced the full user equivalent concept or FUI's as I'm going to call it going forward. The FUI concept, we've got the style measurement program to measure the number of licenses. It's definitive. Black and white people are either one of three license categories, but also there is a monthly assessment. So SAP will be monitoring this in real time, and we'll be able to see if licenses start to creep and people are then consuming more than they've actually paid for. So let's try and have a look at those two concepts, the FUIs and the star measurement program. So the FUIs now we're not, we're no longer buying, packets of licenses of the different user types that I mentioned before. We, buy a number of full user equivalents which are consumed according to the access that people need. So an advanced user will require one complete FUI, a one to one ratio. The core users, which were, like, functional users, limited professional users in the old system, will only consume a fifth part of a FUI, and self-service users with their limited capabilities will only need the thirtieth part of a FUI. The developers then actually need two FUIs each, but they're measured in quite a different way, which we won't go into today. They're usually a very small proportion of the number of licenses in any case. So according to those ratios, then if we have a client who's currently on ECC and they have a two hundred and fifty professional users, that's three point three thousand functional users and so on, total of four thousand users currently. According to those ratios, moving to s four, they would need about nine hundred and fifty FUIs. However, the important thing to remember in all this is that the user type is defined by authorization objects and through the star measurement program, which you'll see in a moment, but the access that they have assigned. So this is similar to how things worked in ECC and also how access risk is determined by auditors. It's important about what the users have. Doesn't matter whether they know they have it, whether they ever use it, but if they have it assigned, if it's in their user buffer, then that is what SAP is measuring. Okay. So the other important thing to bear in mind is that the number of who is actually drives the infrastructure costs. Now this slide is a little out of date. There's a SAP were working on nine levels of t shirt sizes here. There are I think there are now fourteen, so they've just recently changed that. But the point is that the number of purchased drives the amount of memory and storage that you can have in the different tiers of the application. So it's obviously important, this linkage, but the most important thing is that you don't want your consumption to be actually pushing you into levels of infrastructure that you don't really need. So it's very important. I mean, we can always buy add ons for memory and storage. So and usually, that is more cost effective than actually moving up a t shirt size. So this although this is linked in this way, as I say, it's very important not to have your consumption, not to be in a level of that requires you to have a level of infrastructure that is higher than you actually need. So how does the star measurement program work? How is it that SAP determines what the license level each of your users requires? What they have is a matrix, and this is a little extract from the matrix here. They have a number of authorization objects with activities, and those are categorized either as advanced users, the red ones, core users, the orange ones, or self-service users, the green ones. If a user has assigned any of the red ones, they will be categorized as an advanced user. None of those but some of the orange ones, they will be categorized as a core user. None of those. And green ones, they will be categorized as a self-service user. Now it's possible. There's only two and a half thousand lines in this matrix. It's quite possible that users wouldn't have any of those authorization objects, in which case they would be classified or they'd be unclassified users. However, they'll still need their license and the cheapest license is a self-service user, so they will be cat they will be categorized as self-service. So what does that mean in the context of SAP user? So the this person we've got here has needs to do some functions in SAP. Each of those functions requires transactions and authorizations to be able to do that, and there are each of those requirements then takes some objects from that list and will be categorized. So those functions he has one function here which is advanced, and as I say, if they have anything from the advanced list, they will be categorized as advanced. So that's the way it works, in practice. So what are the differences here? We can say that SAP is obviously able to look at this, in a much more detailed way and in a much timely manner, but there is a greater clarity here and it's definitive. So in fact, as far as the consumer's concerned, the star measurement form is a much better way of my it's much easier for someone to know exactly what it is or where they stand. Okay. However, there are some costing traps here. So the main thing to understand is that the legacy roles that you have in an ECC system are certainly not optimized for the star measurement program. When people create roles, they're thinking about what the users need to do, and they will give them the amount of access that I think is required to do that, but I certainly won't be thinking whether this activity on this authorization object should be allowed or not as long as, you know, that they enable all the functionality that someone's going to do. So there will always be a huge gap between what people are actually authorized to do and what they do actually do in the system. Once your licensing baseline is set in RISE, it can't be reduced later. Now there is a new form of contracts which is coming in shortly, which would allow some use of credits, which it seems as though there may be a possibility to reduce license costs or move or rather move license contribution from of from licenses to some other functionality that you might require in SAP. But it's always gonna be credits. There's never gonna be any money back. When you are negotiating the contract, then SAP will run the star service. They'll use that star measurement program to have a look at your current access, and they will decide how many FUEs you need according to that, and they will have a line in the sun. It's quite possible that they will tell you that all your users are advanced users. So we've certainly had clients with twenty thousand users, all of which SAP told them were advanced. So, obviously, there's a then a huge license cost. They once they have that line in the sandal, then they will I am quite reluctant to actually drop it. And but so it's very important that you can argue that where your real licensing costs should be. As I mentioned earlier, that inaccurate fully sizing can have infrastructure implications, so it may be forcing you to take on larger infrastructure than you really want. And in certain cases, it can even make the business case inviolable. It's just too expensive to move to rise because the licensing costs are just too high. So the idea or the advice that we give is that you should start to prepare your licensing as soon as you start to think about the s four project. One should be one of the first things that you start to think about. Minimize the infrastructure requirements as we'd spoken about in the earlier session and also minimize your exposure. So what can we do to help you with that? What you should do is conduct a comprehensive license audit before you sign the RISE agreement and understand what the users are actually using versus what they're assigned. Look at your overused over assigned and unused roles, and check what roles are driving your account, and validate your numbers before SAP sets that baseline. Now having said all that, that's obviously aimed at people who are just beginning their RISE journey, Perhaps it's certainly valid for people who are already there as well and suddenly finding that the requirements that they have are rising, that they need more functionality, they bring on new users, and all that is driving consumption, which is higher than their entitlement. So this idea of doing this type of audit is certainly applicable to use to clients who are already on RISE as well. And we do have a free no obligation assessment for this, which we'll talk about in a moment. So the assessment will help you in this way. So the important thing to look at here is you can gain an understanding of the potential cost of moving to RISE, and that can support your business case. Understand what the remediation options are. So how can you actually reduce that free exposure either with a cleanup or a complete role redesign and how long that might take you to do, and determine three key data points. Those data points are your current exposure with your current role structure that you have assigned, what you could get to with a cleanup of that, and what you could get to with an actual work complete role redesign. It'll help you to hold your service providers accountable if you have service providers who are actually doing your security administration designing your roles. You can check what they're doing, and it will ensure that you're better prepared for your contract negotiations with SAP. So what are the requirements of the actual assessment? I spoke about the difference between what people are assigned, in their user buffer and what they're actually using. So that difference will be large, can be huge. In order to find out what that is, what that difference is, we need to know what people are actually doing in the system. So by default, we'll SAP records users' transactional usage, but what we don't know is what they are using, what authorization objects and activities they are using as well as those transactions. So to do that, we need to activate a standard SAP trace, which will record then what people do in the or what authorization objects they use. So we need to activate that for all the users in the system and accumulate some data. Couple of months of data will allow us then to see really what people are doing, run that over a month end. The only things that we will probably be missing then are certain activities that people might do vary occasionally, such as year end activities, but we can pretty much tell after a couple of months exactly what people are doing in the system. What we can then show you are some headline numbers, your current licensing exposure under the FUI model and examples of potential savings from the role optimization. I'm going to now show you a demo of the tool so that we can see exactly what you would see from this assessment. This is our tool Sutterium for SAP, which is a GRC tool, access risk tool with some optional modules, one of which is the license manager. So it's a SaaS solution, connects to SAP through certified RFC, either through the SAP router or through a VPN. We can then look at your system and see what's going on. So this is the actually, the access risk module that we've got here, which is the where we enter the tool, and this is all about the risk in the system. So as I mentioned, Sertarian is a modular tool that the basic module is the access risk manager. We've got some process control functionality, elevated rights, which is firefighter. We can look at who has access to personal information in the system. We can we have a periodic review manager, which allows us to do user certifications, which are required for socks, for example, and then we come to the licensing, module. So let's have a look here at this. This is what we can see on the landing page of the license module. So this is real user data, obviously been scrambled. We've got no real names or anything in here, but this is from a European company which was already on rise, but they had a big problem here. As you can see, their consumption was up at twelve hundred over their entitlement of only six fifty, what they'd actually purchased from SAP. So they very quickly needed to do a reduction on their FUI consumption. So what we can see here is the consumption according to their current role design, so according to all the roles that they have in the system and the assignment of those roles to the users, and that would that implies a free consumption of those twelve hundred. And then we can see what they would be able to get to if they do the cleanup and if they did a complete role redesign. Now I'll come back to that in a second, but I just want to show you what we're actually measuring this against. So the license rule sets that we have here, this is that matrix that I showed you an extract of on the slides. So here are all the authorization objects and activities that SAP is measuring against. There's about two and a half thousand lines on this matrix. If I just order this by auth object, you'll be able to see that some of these are advanced, some of them are core, and some of them are self-service. So according to what users have assigned, so what the contents of the roles that the users have assigned are, they will be classified. They have anything from the red lines, they'll be an advanced user. None of that, but something from the orange ones, they will be a core user, none of those. And from the green, they'll be a self-service user. This is version sixty nine. So this is published by SAP. Every time they consider it necessary, they have a new version of this. So they've changed that sixty nine times so far. I will say that the rate of change is a lot slower now. So they've it's embedded in a bit better and they know more things. But if they bring in new functionality, they will add authorization objects to this. If they find that they feel they've made a mistake and that some of these should be in different categories, they will do that as well. And that has with this particular client that this demo system was taken from, that actually happened when they moved from sixty eight to sixty nine. They had a big jump in free consumption because some of these authorizations were changed from core to advanced. Now SAP can do this at any time. It is or we have had, clients who've tried to fix the, matrix that they'll be measured against. I don't know if anyone has actually succeeded in that yet. It would be a bit of a maintenance nightmare for SAP to be trying to measure people against different versions of this, but it's a possibility that we might be able to fix the matrix that you measured against. Anyway, returning to the standard page, the landing page, we've got here this view of those three different levels. So let's just have a look at what we mean by the cleanup. So if we go into the cleanup, we can see that we would be able to reduce the consumption down to around eight hundred. That's done in a couple of steps or in about three steps, but on two sides. So we can do a user cleanup, first of all, the which would give us here about an eleven percent full year reduction, and we can also do a roll cleanup, which will give us a larger cleanup. So we'll go and look at that in a little more detail in a moment, but what we can see here on the potential is that we can actually get this down to a hundred and sixty FUIs if we did a complete role redesign based on that what the users were actually doing in the system. Now there's always gonna be a balance here somewhere where you can get to the stage where the role design is too atomized and too granular to be easily maintained. So we need to have a certain level of being able to extend things across groups of users. So we're we need to be able to say that all the accounts payable clerks are gonna have more or less the same access. That's important, but we can actually use these sort of redesign projects to drive business to use the same business processes to homogenize their business processes across and use best practices across the whole of the organization. So that has a double benefit there. Sometimes these role redesigns can actually help business processes to be more standardized and easier to control as well. Anyway, let's have a look at what we could do actually on the cleanup. So if we look at this tab of get clean, I mentioned there were cleanup activities on the user side and on the role side. On the user side, the simplest thing we can do is to look at inactive users, people who haven't logged on to the system for usually ninety days. We need to lock them down, lock them and expire them. Now most companies will have a process in place to do that to make sure that those users are that there's a process in place to keep those users locked down. In this case, there were some to lock down, and that would have given this company a four percent reduction in their consumption. The second thing we can do on the user side is to remove roles that people aren't using. So I mentioned we've got that trace running. We know what people are doing. We know what transactions they're using. We know what authorization objects they're using. So we can see which roles they have assigned, where they're not using anything from those roles. If we can remove those roles, then we can also do a reduction there. In this case, we could downgrade about forty three users from the different levels of licensing. When we've done that, what we can look at then are the roles themselves. So the roles contain a series of transactions, authorization objects, their activities. If we are monitoring the usage, we can see that what users are using from those roles, and we will identify superfluous authorizations in those roles from the matrix that no one is using. So if we remove those from the roles, then we will obviously be able to do some user downgrades there as well. So let's have a quick look at some examples of that to see exactly how we would do that. So on the user side, here we've got a list of all the users in the system, the measured classification according to the access that they have assigned currently, and the optimized classification according to what they're actually using. So let's have a look at one particular user here, Andrew. Currently, he's measured as an advanced user, and is telling us that he could be optimized to a self-service user. So how would that be done? These are this is the list of all the roles that he has assigned with their measured classification here and whether he's actually using them or not. So if I order this by classification, we can see he's got one advanced role, a few core roles, and the rest are all self-service. Now he's not actually using anything from most of these roles. You can see down here, he's starting to use some roles here, and we can see what he's actually using from those roles. But so these are all the all objects that he's used from that particular role. But the ones that he's not using could obviously be removed from him, and then that's how we can reduce his license requirement from advanced to self-service. If we look then on the role side, we can have a look up of cleanup of the roles there as well. Now in companies that use the derived roles, so the parent or master role and derive roles out for the different organizational areas of the company. Those derived roles, that adds a certain complication because we can only make changes to the master role and not the individual derived. So in order to maintain the integrity of the model, changes can only should only be made to the master roles. So we have to roll up then the access to all the derived or child roles so that we can only remove things that no one is using in any of the derived roles. But Sutterion can do that analysis for us. This company doesn't use the derived role concept, so we can just look at the single roles that they have assigned to their people. So here, the summary tells us that from the advanced roles, we've got several that we can downgrade. Same thing on the core roles and on the self-service roles. I mentioned that many roles might be unclassified. So, obviously, if we reduce the higher level roles, we're going to increase the non classified roles, but that will not have any license implications for us. So let's have a look at the summary of that as well. So here we have now a list of all the roles in the system with their measured classification and the usage classification of each of them with the number of users assigned. So, again, I'm going to order this by the most advanced roles first of all, We can see that there are several that can be downgraded here. We've got a number of users assigned to each of the roles as well. Let's look at this one. This is assigned to ten users. It currently has a measured classification of advanced, but according to what these ten users are using, it could actually only be a self-service role. So, again, we have here a list of all the auth objects and activities which were in the matrix that this role contains. So there are a couple of authorization objects here with their activities, and we can see how many of the ten users assigned to this role are using each of those. So there are several superfluous ones here. We can see that this one is in use. So just one person, Laura, is actually using this. We can see one person who's using this one. Now again, I'm going to order this by the most advanced ones first. So the one advanced auth in this role and one core and all the rest are self-service. We can see again who's using them, so nobody's using the advanced nor the core. We've got three people here using this one. So we can see here that this object is being used by three pre promise. It's taking a little time to load, which is odd. Not really important. And so we can see if I actually just filter on this object, it's been easier to see exactly what is happening here. So this object has two, six activities possible, which are in the matrix there. So activity six is an advanced one. Nobody's using that. Activity one is core. No one's using that. The only one that's being used is activity three display. The client has actually coded a star, an asterisk in this activity field in the role, which means that users can have can use any of the activities. If we remove that star and we replace it by zero three, we will be able to drop this role from advanced to self-service and all those ten users could potentially drop from advanced to self-service. Of course, that depends on what other roles they have assigned, but we have the information here about all the roles so we can go forward and do the do this activity for all the roles. So there is one other thing I will just show you here. So if we are talking now about the cleanup not being sufficient and that we do actually need to look at role redesign, we could look at something like this on this role. So this role is an advanced role. It's being used in as a as an advanced role. But, if I just, again, look at the advanced objects in this role, we can see that some of them are not in use. There are a couple that are in use. But of the fifteen users, there are only five people who are actually using this. So to get further benefits from this, if we split this role, split out these activities into a new role and assign that just to those five people, the other ten, we could actually reduce then from advanced to core. So those are the sort of analysis that we can do with the tool to then make further savings on the fuel consumption. I'm just gonna show you here what this looks like in terms of cost. So this company, European company, they are paying fifteen hundred euros per Fui. With their current role design, that would cost them one point eight million euros. If we did a cleanup for them, that's going to cost money. The projects is a cleanup project. That might be done with internal resources. It might be done with a partner. In any case, it's gonna cost money to do that, and they will have to pay for the software as well. But the obviously, the those eight hundred FUIs are only going to cost them a much more amount. And in total, they would still be able to save about half a million euros there. If we did the role redesign, that's a more expensive project. It's gonna take longer, but the software cost will be the same. Overall, they could save a lot more. Now that's just a projection over one year. Our RISE contracts are usually over three, five or even seven years. If we look at that over five years, the projection, the costs are obviously going to be a lot more instead of paying nine million if nothing was done they could reduce that to one and a half million if they did the work. Okay. I just want to show you one more bit of functionality that the tool has. So I mentioned that we have an access risk manager here with simulation functionality to look at what would happen if we assign more access to someone. If we change a role, we can do simulations there to see what the risk impact would be. Now I just want to show you the simulation of adding more roles to a user. So let's say that Kayla here is going to do some more work. She's works in HR and payroll, and they wanted to do some posting. So they're going to assign this role to her. When we run the simulation, Sertarian will check what the risk impact of adding this role to the user is, so that's going to introduce some new risk, a couple of new high level risks. But we can also see that it's gonna have a license impact here. If we look on the license tab, shows us that this adding this role to Kayla would push her from being a self-service user to an advanced user. So we can kick off a workflow from here, and we could obviously on the risk side, we can ask Kayla's manager, maybe a role owner or a risk owner or a business process owner if they approve for her to have this hosting role, but we could also add a workflow item that would go to the SAP license manager and ask him whether he's prepared to pay for Kayla to go from a self-service user to an advanced user. So this sort of functionality allows us to monitor the use of fluids as we go forward and make sure that there's no creep to push us then over entitlement levels. Okay. I think that's what I wanted to show you as far as, the functionality demo of the tool is concerned. So let's just return here to the presentation and ask if anyone has got any questions. Hi, Variance. I have a few questions here in the chat. So let's just start with this one. When should we start preparing for FUE licensing? Well, really, as soon as it's possible. So if you're thinking of moving on to RISE, then you should start. One of the first steps should be run the star report, which is available from SAP. There's a notes that you can apply that will run the star report, and that will tell you what your current fully consumption would be according to the roles that you have assigned at that time. That will give you a starting point. It's probably going to be quite an eye opener. It's probably gonna tell you that you need a lot more licenses than you thought according to the breakdown of your current users. But that's because, as I mentioned, the roles legacy roles will not be optimized for food consumption. So if you think you're moving to Rise as soon as possible, if you're already on Rise, then it's something that you should be monitoring as well on a regular basis. Thank you, Roy. How frequently should organizations review their FUE classification, and how does the tool help track changes in user activities or roles over time? Okay. So yeah. Really, as I mentioned, SAP is gonna be monitoring this on a monthly basis, so you should also be monitoring it at least on a monthly basis. You don't want to have a surprise when some change that you may have made to some functionality, a new role has come into the system and suddenly pushed everyone into a higher level and your fluid consumption has jumped. And SAP will probably give you a little while to try and remediate that, but it's certainly much better for you to be able to proactively manage that and make sure that you're not pushing that over the limit. The tool, obviously, can will be monitoring people's usage, and we'll be able to see, you know, if things change. And maybe you introduce some new more changes to the business process, which drive food consumption. So you will be able to see that if you have the tool installed. And business as usual, you'll be able to see those things in real time. Thank you. I think that's all the time that we have for today, but we will answer the rest of the question via email. Thank you for joining us today, and thank you, Roy, for a great session. We'll be sharing the recording with everyone soon. And as always, reach out if you have any additional questions, and we look forward to seeing you at the next one. Thank you, Robert. Thank you, Monica, and thanks everyone for joining us today. Have a great rest your day. Bye. Bye.