Is your SAP licensing strategy fit for purpose in the S/4HANA era?

Welcome to today's session. Is your SAP licensing strategy fit for purpose in the S4HANA era? My name is Maria Robinson, and I'm the head of marketing here for EPI-USE Labs. Today, my colleague Roy Topham, he is our principal SAP security and GRC architect, will cover a very popular topic at the moment for everyone in their s four HANA journey, or maybe you're already on s four HANA and you're close to negotiating your contract, and that is FUE's licensing. As you might have heard, very important changes are coming up when it comes to the new licensing model. So in the next thirty minutes, we want to give you a clear explanation of SAP FUE licensing, focusing on how the usage is measured and where unnecessary costs often arise, what are the changes in how SAP users are licensed, and then we will finish off with a demo of Sutterion's license manager, which is the module of Sutterion that can help you and support you in this specific area. Before we start, I see a few new faces in our attendees, so I'm just gonna do a very brief introduction of EPI-USE Labs in case you don't know us. We are a global company that we provide solutions and IP leverage transformation, privacy and security services, as well as custom innovations. We operate in fifty five countries, and we have more than one thousand eight hundred clients worldwide. We're very passionate about partnering with our clients to optimize the performance management and security of their SAP systems and SAP SuccessFactors. We are a very proud member of Group Elephant. We go beyond corporate purpose by providing one percent of our revenue to ERP, elephant, rhinos, and people, and all the programs that they focus on at the preservation of at risk elephants and rhinos through their economic uplift on their rural people. Before I hand over to Roy, just a few housekeeping items. So the lines will be muted for the duration of the webinar, But if you have any questions, you can always use the chat box that you see on your screen and we will try to answer the questions at the end of the webinar if we have time. If not, we will send the answer via email. This webinar is being recorded so you will be able to receive the recording afterwards and you can share it with colleagues. Web when the webinar will be over, you will see a quick survey pop up on your browser. We will be asking you three questions, so it only takes one minute, and it will give us really good feedback for us to be able to create really interesting and good webinars in the future as well. So without further ado, I'll hand over to you Roy, and thank you very much for being with us today. Thanks, Maria, and thanks to everyone for joining today. So Maria already mentioned what we're going to cover today, so let's jump straight in and talk about the migration to SAP Cloud. So when we move from ECC to s four, and I'm talking here about the cloud version, the private version, there's been a few name changes recently, but I'm going to stick with the nomenclature of RISE for the moment. So we're talking about the RISE variant of Cloud s four. So these are some of the things that obviously we need to think about when we're moving there, how we're going to how much we're going to depend on Fiori and looking after our master data and so on. But the total cost of ownership when we move on to these new cloud environments can be higher than expected because there are some hidden cost drivers inside your current system that can follow you into the new world if left unaddressed. So first of all, in RISE, the size of your database determines your subscription tier. So if you migrate everything, all your old data, all your unused company codes, lots of historical stuff, then you may find yourself in a much higher and more expensive tier than necessary. So data volume is more very important. But as well, the licensing costs can be a problem. And there is a new way of measuring licenses, a new way of providing licenses, and we're going to discuss that today. So what are the changes in ECC? There was a rather rough and ready way of determining the license required for a user. It wasn't very specific. There was room for maneuver, which in some ways is good, I suppose. But there was also just an annual assessment, which meant that we were able to prepare for that assessment before it came along and try to ensure that we were compliant. However, when we move to s four, we've got the full user equivalent concept, which we will talk about in a moment. The star measurement program, which means that SAP is measuring or can measure continuously the number of FUIs that you are consuming. It is definitive. It's black or white. You are a particular level of license, there's no argument about that. But also, there is now a monthly assessment. So SAP is reviewing that. And if you start to creep up, then you will be charged for a higher level of licensing before the contract ends. So let's have a look at the FUI concept. So now instead of buying packets of licenses of different types, we buy a number of FUIs, which are consumed according to the user's requirements. So we have starting off self-service users here. We can have they can they will consume only the thirtieth part of a FUI, so we can have plenty of ESS users. That's good. Core users or basic users who have who needs more functionality, they will consume the fifth part of a FUI, whereas advanced users that need plenty of functionality are people who are working on SAP all day. They will require an advanced user which consumes one complete FUI. And developers, if we have any, they consume two FUIs. So every developer consumes two FUIs. So if we look at the user requirements of a typical client down here at the bottom, they've got a total of four thousand users of the different types. That translates into a requirement for about nine hundred and fifty FUIs. The thing that you must bear in mind when we're talking about this is that the user types are defined by the authorization objects that they have assigned. Now we'll look at the authorization objects in a moment, but it's the assignment of those authorization objects which is the problem. Okay. So the other thing to bear in mind is that SAP sales rise by t shirt size. So a band of numbers comes with a specific amount of memory and storage. So if the numbers are inflated, you also have to pay for more infrastructure. So it's always best to try and minimize the and if you did if that doesn't give you the infrastructure you require, then you can buy some more. We wouldn't be forced into more infrastructure than you need. So let's talk about the star measurement program that SAP uses in s four. So what we what they have published is a matrix of some authorization objects and activities. There's about two and a half thousand lines in that matrix, so nowhere near all the authorization objects. I think it's twenty four thousand authorization objects in SAP. So a small section, but those are the ones that they are measuring. They're the ones that they consider to be important in the functionality that people are using and that will determine the level of license requirement. So these are categorized as advanced, core, or self-service. So what does that mean for a normal SAP user? So if this user has a few functional requirements, they maintain purchase orders, vendors, etcetera. Each of those functional requirements requires them to use transactions and authorization objects in SAP. What SAP will do is check what authorization objects they have assigned. So for each of these functionalities that they will look at that and say, okay. Well, this needs advanced. These are all core. If they have one authorization object assigned from the advanced list, they will be considered an advanced user. So it's very important here these levels of authorization required for each of these activities. So this does give us much greater clarity and is definitive. And so it's much better for SAP, but in fact, it's better for us as well because at least we know when we stand, and we can if we take steps to address that, we can certainly be on top of it. So what we do have to think about are some of these costing traps that we might fall into. So you have to remember that once the licensing baseline is set in RISE, it can't be reduced later. So once you've signed up for a thousand FUIs, that's what you're going to pay for. And if you go over that, you'll probably start paying for some more as well, but you can't go back ever. The metrics are based on authorization authorizations that are assigned, as I mentioned before, and the gap between assignment and use will be very large. With most clients, they have great over assignment not only of transactions, but also of authorization objects. Once SAP runs the star service, so if someone's thinking of moving to RISE, then SAP will, run that star measurement, and they will have a line in the sand, which they will be usually not very keen to back off from. And we get lots of clients who've been told, well, all your users are advanced, so you've got a thousand users and you'll need a thousand FUIs. So it's very you might have just one role which is widely assigned, which is makes all your users advanced users, and that's very common. Inaccurate FUI sizing has those infrastructure implications that I mentioned, and it can make the business case just inviolable to move to s four. So it's just the FUI requirements are so high that the business case just is too expensive. So what do you need to do? Start preparing as soon as s four is even a twinkle in the eye. So once you've started to think about it, think about how you can minimize your infrastructure requirements and EPI-USE Labs has a DSN tool which can help you with that and also minimize your free exposure. So let's see. How can we help with that? We have a license user licensing module in our Srotarian GRC tool, which will help you with that. So let's have a look at that tool. I'll just log on to this demo system. So TURN is basically a GRC, risk tool. This is the standard access risk module, and we also have then optional modules that we can add on to that here. So we're going to be talking about the licensing module. So this demo is taken from a client who ran into trouble. They were already on this floor, but they found that their consumption had gone through the roof. Their entitlement was six fifty, and they were actually consuming twelve hundred. So we can see here that their current role design, which gives them that consumption of twelve hundred is here. We can have a look at how we can clean that up, and we can also see what we could do if we redesigned the roles just based on what their users are actually using. Let's have a look at that in a little bit more detail. So if we do a cleanup, there are three stages to the cleanup, which I'll explain in a moment. We could get them down to seven ninety two. In this case, that's actually not enough. Well, they would still have to buy some more for us if they were if we did that. If we go then more radically and do a complete role redesign, as I said, based on what their users are actually using, we could get them down to a much lower level of consumption there. So what is it that we can do to do this cleanup? The cleanup is based on, as I said, three levels here. So first of all, easy thing to do is to lock down our inactive users, users who've never logged on or haven't logged on for ninety days or whatever period you consider. Just lock those down, lock them, and expire them, and then they won't be subject to a license. So that's fairly easy in this play in this case, that would do a reduction of four percent. Then what we can look at is superfluous roles. So roles that people have assigned which they're not using. They don't use transactions or any of the authorization objects and values in that role. So we can take those roles away from them without affecting their day to day work on the system. And that will give us a further cleanup there, in this case, about seven percent. But most cleanup will come if we start to look at the roles which are actually are in use but have superfluous authorizations in them. So those are roles where there are some activities that people aren't using, and we can see the detail of that as we go forward here. So let's first of all have a look at the users and how we can clean up users. So these are some examples of how this company could clean up their users. Here's a summary of all their users with the measured ratio sorry, the measured classification here. That's what they are consuming currently and the optimized classification. So you can see here that some of these people would be able to be downgraded. And let me show you how that would work for Andrew. So these are all the roles that Andrew has assigned, and these are the measured classification of these roles. So that's according to the authorization objects that they have in the role. So let me just show you here. This is the rule set. So this is the full published rule set with all the authorization objects and those activities that they have. So if we jump back here, we can see that all the roles are classified according to those authorization measured authorization objects. So if I order this by high to low, we can see that Andrew has one role which is classified as an advanced, four that are core and all the rest of the roles that he has assigned are self-service roles. But we can also see that these roles here, when there's a tick here, it means they're superfluous. He's not using any of the functionality in those roles. So we could remove those roles from him, and we could then drop him down from an advanced user to a self-service user. If we have a look then at so that's our cleanup activities for users. I mentioned that most of the cleanup will come from the roles. So if we look at the roles, now if we're using derived roles, we have to roll up into the parent role the usage. But in this case, they don't use derived roles. So single roles. We can look at these single roles and we can see here that of the advanced roles, there is currently twenty. We could reduce that to nine, the core roles from forty nine to thirty seven and so on. So let's have a look at again at the details of that. So these are all the roles and with their measured classification and the classification according to usage. So again, we will order these and have a look at one which is which we could actually downgrade. Let's have a look at this one here. It's assigned to ten people. Its current classification is advanced, but we could optimize that to self-service. So those ten people are calling depending on the other roles that they have assigned, but there's a potential that we could drop those ten people from advanced to self-service. So here we have a listing of all the authorization objects and activities which this role contains that are in that matrix. And we can see here how many users are actually using those. So we can see here that we have one authorization object that makes this role in a blunt stroke. No one is actually using that. The first one that people are using is actually list this one, and we can see who those people are and what are the activities and other values in the authorization objects that they're using. So let's if we look at this first object here, and I'm conscious of time, but let's just try and be as clear as possible. So this particular authorization object, it has six activities which are in that rule set. And one of them is a advanced activity, one a core activity, and the other for self-service. We can see here that the only one that those ten users are using is this one. So the client has put a star in the activity for this. That means that all activities are allowed. So what we would do to drop this role is to replace that star value with the value three, which is actually a self-service value. So this role would then drop to self-service. So what we can see here then is in our projections, We can have a look at what this would mean in cost terms. So here we have our three data points, the current role design, which is causing us a consumption of twelve hundred FUIs. What we could get with a cleanup, which would bring us down to seven hundred ninety two FUIs, and here with a complete role redesign we could get down to one hundred and sixty four FUIs. So the cost of those FUIs according to this client is paying fifteen hundred euros for each of their FUIs, so this amount would cost them one point eight million. If they were to do the cleanup, there would be a software cost, and there would also be a project cost, but someone's got to do that work. So if we add those sums onto here with the fully cost, we'll see that we can get a significant reduction there. If we actually do the role redesign project, that's a bigger project, a more costly project. The software cost is the same, but we can bring that down considerably. Now we're looking at one year projection here, but these contracts are usually three or five years. So if we look at that, we can see over three years, this would be five and a half million, and we could get that down to under a million. So there is a huge potential here for savings. I've mentioned a lot about how we clean up. Just to mention how we might do this role redesign. So then what we would do is look at the roles and find out how we could actually split those maybe so that we could have if a particular role is used by several people, we could then split that role so that the people that are actually using the higher level of functionality could have a new role, and the ones that are using the low level of functionality could have that functionality removed from the current role. So those are the sort of things that we can do to help with that. So let's just jump back to our presentation. And so that what we can do for you is actually do an assessment on your own system so that we can see exactly what your current consumption is and what you could get to. So there are sort of two scenarios here probably. We're talking about clients who are still on ECC, thinking about moving to RISE so you can gain an understanding of the cost of that, and we can support the business case. We can help you understand what the remediation options are, so reducing the cost either with the cleanup or the role redesign and the associated timelines with that. And we can look at the, as I said, those three key data points. It also helps you to hold your service providers accountable. So if you could outsource your security admin, you can check that the service providers are actually doing a good job with that, and we can make sure that you're better prepared for the contract negotiations with SAP themselves. So what do we need for this? We need to have the authorization an authorization trace activated. So this is a standard SAP user trace, ST user trace. And what that does is record not only the transactions that people are using, but the authorization objects. So whenever they execute particular transaction, that brings in authorization objects, and this trace records those. So we need a couple of months of that usage data so that we can see what people are doing in the system. And then we can give you these data points of what can be done there. So SAP also has a service, which they called SAM4HANA, I believe, that is based purely on transactional usage. So they will say, if you're using a posting transaction, then you're going to be an advanced user, for example. Now that does not take into account that a lot of the usage that's made of those posting transactions doesn't actually require advanced usage. So the matrix is actually quite lenient. And the activity one, for example, in the main object for posting is only a self-service arrangement. So although SAP will say, okay, so the highest level of this is advanced, we can actually tell you, no, your users are not using advanced authorization. So you they're only using call or self-service. So we'll show you the headline numbers of your current licensing exposure and the three model and examples of the savings potentials that you can get from role optimization. So the idea then would be that you could use our tool going forward to make sure that there is no creep onwards from the usage so that you don't, again, get higher charges as you go forward through the contract. Now, I think we're coming to the end of the presentation, or of our time rather. So I'm not sure if we have time really for any questions. Maria Yes. I think we do. I can see a couple of questions popping on the chat. And if you have them, please just write them down on the chat box, and we will make sure to get back to you via email. Also, please remember to let us know on the feedback form what you thought of this webinar and if there is anything else, any other information that we can provide for you on this topic. Thank you so much, Roy, for this webinar today. I believe it was very insightful and hopefully it's given a lot of new ideas for people and knowledge just within this new FUE topic and regulations and licensing. And thank you very much for your time today, and, yeah, see you the next time. Thank you. Have a lovely day. Thank you. Bye.