The path to SAP S/4HANA: Understanding your true FUE licensing position

Hello, everyone, and thank you for joining us today. So I am Joey, and I look after marketing for Asia at EPI-USE Labs. Joining me today is Roy Toppin, our principal SAP security and GRC architect. So today, Roy will be covering a topic that's generating a lot of conversation right now, and that is SAP FUE licensing. Whether you're on your s four HANA journey or you're already live and approaching your contract renewal, this session is for you. So I can see there is a couple of new faces that are joining us today. So a quick introduction on who we are. EPI-USE Labs is a global company providing software solution, IP led transformation, privacy security, as well as custom innovation services. Operating in fifty countries with more than a thousand nine hundred clients worldwide, we are passionate about helping our clients to transform and optimize the performance, management, security of their SAP and SAP SuccessFactors system. So as a proud member of group elephant, we also contribute one percent of our revenue to ERP, stands for elephant, rhino, and people, which is a nonprofit organization that's close to our heart. So before I hand over to Roy today, just a quick housekeeping note. Your line will be muted now throughout the entire session, but please feel free to submit any question through the control panel, and we will address them at the end. So over to you, Roy. Thanks, Right. So today, yeah, we're going to talk about how we understand the flu licensing situation that you might find yourselves in. And these this is sort of the agenda that I'm going to go through today. So we'll talk about migration to the SAP cloud, these new concepts of full user equivalent and the star measurement program. And I'll give you a quick demo of the Sorterian license manager module or our GLC tool, and then we'll talk about the free licensing assessment that we can do for you. So migration to cloud. There's a lot to think about there. All these things about how much you'd like to use Fiori, how much data you're going to take with you and all those sort of questions. But the total cost of ownership of an Sfour system can be a lot higher than expected because there are some hidden cost drivers inside your current system that can follow you into that new world if they're left unaddressed. So the two main things there are the size of your database or the data volume, and that determines the tier of your subscription. And the other thing is the licensing costs. So the licensing costs how the way that they are calculated has changed in s four, and those two things are actually quite closely linked, which we'll see in a moment. So when I'm talking about s four, what I'm talking about really are the cloud options principally the private cloud options. The FUI licensing also is relevant on prem systems or they're measured in the same way at least, so this is also relevant to those customers as well. So what are the changes now in the licensing if people are moving from ECC to S4? We the previous way of measuring licenses was quite open to interpretation and it was fairly easy to prepare for a license audit and then try and ensure that you were within the parameters that you'd agreed with SAP. In s four, we have this new fully concept full user equivalent. We have the star measurement program, which measures the license types that you need. It's definitive. It's black and white. It's there's no room for for interpretation there. And it's also assessed monthly. Well, can be done, we could say continuously. So SAP is continuously monitoring the license levels and will start to charge you more if you go over the agreed levels. So let's try and explore those two concepts and make sure that we understand what's going on there. So full user equivalent, we now no longer buy packets of licenses of different types, professional, limited professional, self-service, and so on. What we do is buy a number of FUIs, which are consumed according to the requirements of the users. So if we start here with the advanced users, those consume one complete FUI and that gives the user access to virtually all the functionality of the system. The next level, Query users. So they have the more limited solution capabilities, but they only consume the fifth part of the FUI. And then we have the self-service users. They have much more limited capabilities in the solution, but they only consume to the FUI. And the to con FUI is normally not a very relevant number of users in the system. So how does that work with these ratios here? If a particular user or client had this number of users in their system, so a number of professional users, functional users, productivity users, and developers, then according to the ratio that we've just seen, the FUI quantity that they would require for those four thousand users would be about nine hundred and forty five. But that of course is in the best case scenario when all the users are classified as they should be. The important thing to remember in all this is that the user type is defined by the authorization objects that they have assigned, not that what they're using. So this is the typical gap that we see when we're looking at risk analysis as well. What is it that people have assigned? They might not know they have it assigned. They might may never use it, but if it's there on their user, then that is what they're being measured against. So the I did mention when we started off that the number of FUIs is also linked to the infrastructure. So there are t shirt sizes, so the number of FUIs, level of FUIs there could be related to the infrastructure that's provided by SAP. Now this matrix is a little bit out of date. SAP have increased the number of levels in it, the number of t shirt sizes on it since since this slide. But what you have to bear in mind basically is that you don't want your infrastructure costs to be pushed by the number of FUIs, the number of licenses that you have. So you need to optimize the number of licenses. If that means that you actually need a little bit more infrastructure, then it's easy enough to buy some add ons to get some more infrastructure. So let's just now talk a little bit about this star measurement program, which is how SAP determines what level each user is, what level of license each user needs. So they've published a matrix, and this is a little extract of that matrix, which contains some authorization objects and associated activities, and those are classified according to advanced core or self-service. And so how does that work when we look at a particular user in the system? So this user in the system has several functions that they need to do. Each one of those functions requires some transactions and some authorization objects and activities. And according to that, then that access is provided to them and that gives them a level. So for the first function, they actually need some of the red authorization object activity pairs here, which will make them an advanced user. If that user had none, needed none of these red ones, but they had some yellow ones, then they'd be called a core user. If they didn't have any of those, but they needed some green ones, then they'd be a self-service user. And, obviously, this isn't a list of all the auth objects in SAP. There's about twenty thousand auth objects with all their different activities. So but these are the ones that SAP believes are the ones that are important from the point of view of categorizing the licenses. So it's possible that someone might not need any of the auth objects in the matrix, in which case they would be an unclassified user. But any user to SAP requires a license and the cheapest license is a self-service license. So even those unclassified, even if they don't have any of the green auth objects, they will still be classified as a self-service user. So as I mentioned, this particular user, as they need an advanced one, just one advanced auth object, they will be classified as an advanced user. Okay. So what we can see from that is that there's much greater clarity and it's definitive. It's black and white. Either you have one of these auth objects or you don't. So we find that's a much better system, better from the client's obviously, better from SAP's point of view, but certainly from the client's point of view as well. However, there are some traps, hidden away here. So once your licensing baseline is set, it can't be reduced later. So once you've signed up for a certain number of FUIs, that's it until the end of your contract. Unless, of course, you start consuming more, in which case SAP will start to charge you for a higher number of FUIs. As I mentioned before, these metrics are based on the authorization objects assigned, and the gap between the assignment and what people are actually using can be huge. So you must remember that the roles that have been designed and applied in an ECC environment do not take into account these authorization objects. So they've not been optimized for that and there will always be a difference between what users are actually using in the system and what they're not using or what they have assigned, which means that there can be gaps then people can be in a pushed into a higher level than they actually need to be. So when SAP starts to talk to you about moving on to rise or a cloud solution, they will ask you to run the star measurement program and they will tell you what level your users are. It's quite possible that they will tell you that all your users are at advanced level. So we've had clients, very large clients in the US with several thousand users, and all those users were advanced simply because there are some auth objects in very widely assigned roles, which push those users into the advanced level. And that can sometimes make the business case for moving to RISE just not viable. The other thing to take into account is that inaccurate Pruise sizing might have infrastructure implications. As I mentioned before, it might push you into a higher band, make you purchase more infrastructure than you actually need, and that can be very costly too. So the advice is to start preparing for this as soon as you start to think about the s four move, then you should start to think about these two points here. Minimize your infrastructure requirements, minimize the data that you're taking with you or that you propose to use on the system, and also try and minimize your FUE exposure. So how can we help with that? We have a user licensing module in our Sorterian GRC tool, and that can actually help you to look at what, the users actually what their exposure would be with the role, role assignment that they currently have, and also look at the cleanup opportunities that you would have there. And this is, relevant for people who are not yet on Rise, who are thinking about moving there, but it's also relevant for people who are already on rise and who have a pressure to they're getting close to their limits maybe, or maybe they've even gone over, and they need to make sure that they aren't starting to be charged a lot more than they anticipated. So let's have a look at the at our demo. And let's just end the slideshow moment. So Sauterian is a software as a service solution. It's web based, so I'm just going to log on to the demo system here. So this is the landing page, and this is to do with access risk. So we're looking here at the access risk area, but what we want to look at today is the licensing, which is a optional module on the GLC tool. So this now this was a real client data that's been that has been disconnected and scrambled, disconnected from their SAP system and scrambled here, but this was actually a real, real client. So first of all, I'd just like to show you here. This is where the that matrix sits that I spoke to you about. So this is the full matrix. This is version sixty nine. So it has been changed. I'm just going to order on orthobject so that you can see the different levels here. Version sixty nine, so it has changed it can be changed by SAP whenever they want to without reference to anyone. So it is possible that the goalposts move and you some of your users are recategorized if a new version of this matrix is published. The latest one was published almost a year ago now, so the rate of changes has slowed, but it's still possible that it could change. So going back to the front page here, what we can see is the consumption of this client, and they had an entitlement which was actually much lower than that, so they are in trouble here. We below that, we have three bars here that show the FUI consumption according to their current role design, that is the all the access that people have assigned in the system. There is a bar which shows how what we could do if we did a cleanup on that, and I'll show you what that cleanup entails in a moment. And there's also a potential here, which is what the minimum requirement would be if we redesigned the roles and gave people access only to the things that they actually needed to do their job. So let's have a look at the cleanup here. We could, with the cleanup, get these get this down to seven hundred and ninety. The cleanup consists of cleanup in the user domain and in the role domain, and we'll have a look at those two options for cleanup in a moment. I'll just show you as well the potential here. So this is this company could actually get down to a FUI exposure of only a hundred and sixty four if they redesigned the roles solely using what people are actually using in the system. So you may say, how do we know what people are using in the system? And obviously, we need actually to record what people are doing. So there is, luckily, a trace called STUserTrace, a standard trace, SAP trace, but that needs to be activated. It needs to be activated for all the users so that we can actually see what they're doing from the authorization object level and then see what it is they're not doing and how we can do that cleanup. So let's look at the cleanup perhaps in the user context first of all. So we'll just look here. So in the on the user side, we could get it with this client an eleven percent cleanup, and the roles would give us another twenty three percent cleanup. So there are two activities on the role side on the user side rather. First, of all, locking down any inactive users. Now this is something that most companies will have some sort of procedure to lock down users that aren't using the system. Obviously, if someone hasn't logged on for ninety days, they don't need a SAP license. They need to be locked and expired. And in that case, we can make a reduction here with this particular client of about five percent. The second thing we can do is remove roles that people aren't using. So if someone doesn't use anything from a role, they don't use any of the transactions, they don't use any of the authorization objects, then we can actually remove that role from them. And in this case, this would result in a six percent cleanup of the FURIs. Then if we go across to the role side, what we do is look at the usage of the authorizations within a role. So all the people who have that role assigned find the authorization objects that they're not using from the matrix, and if we remove those, we can get another twenty three percent. So let's have a look at how we clean up a user. So here we have a list of all the users in the system with their classification. So this is the measured classification according to all the roles that they have assigned and all the access they have assigned and the optimized classification of what we could do if we removed roles that they weren't using. So let's have a look at Andrew here. Andrew, his measured classification currently is advanced, but Sartarian says we could get him down to a self-service user here. So these are all the roles that he has assigned with the relative dates and, obviously, when he last used them. Now he's not using a lot of roles here. Most of them or a lot of them are superfluous. So if we just order these from advanced downwards, so we've got one advanced role, which he isn't using, four core roles, which he isn't using, So removing those is how we would get him down from advanced to self-service. So the roles that he actually is using are these down here. We can see when he did use them for the last time. So he is using some roles, but not those dangerous ones that say at the top. Okay. So that's how we would clean up a user. If we go and have a look at the roles, now, this particular client does not use the derived role concept, with master roles and child roles. If that was the case, then obviously, we would have to roll up the usage of the derived roles so that we get as we can only remove objects from the parent roles. But in this case, we're just looking at single roles. So I can show you here, this is an overview. So we've got nineteen advanced roles of which we could downgrade eleven of those, forty nine core roles downgrades here. So we can see all the downgrades. This would actually push up the unclassified roles, but that's not going to have a new license impact for us. So let's have a look at these roles. These are all the roles in the system with their measured classification according to the auth objects that they contain and the usage classification according to how the users are using those. So again, I'm going to order that for have the advanced roles first of all, and we can see here the number of users assigned to each of those roles and some of them have a possibility of being downgraded. So let me just show you this role here. So this is a HR payroll posting role. It's currently measured classification is advanced, but according to how these ten users are using this role, it could be downgraded to self-service role. So these are now all the auth objects from the matrix that are within this role with their measured classification here and whether how many of the users are using them. So we can see here that this one is being used by one person, these aren't being used at all. So again, I'm going to order this from high to low. So we have one advanced authorization which no one is using and one core authorization that no one's using either. So let's just filter that on the auth objects to make it a little bit more easy to understand as well. So this is the auth object that has those two more advanced auths in there. You can see here all these activities are in the matrix. So activity six, one, seventy seven, and so on are all in the matrix. But these ten users are only using activity three here. We can see who those who that user is and what they're doing. We have all that data here to show. So if we the client here has coded a star, an asterisk in that activity value for this object. If we remove that star and we replace it by a three, then we are going to drop that role from advanced to self-service. Okay. So you we can see here that there's lots of scope now to do this this cleanup. I just want to show you what the cost implications are of this. So currently, with this current role design, this is at a value of fifteen hundred euros per FUI, which is what this client is paying, that would cost them one point eight million euros. If they did the cleanup, now that's gonna cost them. There's a it you know, there's time involved. It might be external or internal consultants, but it's still going to cost them to do that project and the software to the Sertarian software will also cost them. But even so, that lower number of FUIs means that they'll only be one point three million and if they did the role redesign, that's a bigger project, cost them more, software is the same, that they would get a much greater saving. If you we project that over five years of a full, RISE contract, then you can see there's a big difference there between nine million euros and one and a half million euros. So there's just one more thing that I'd like to show you very quickly here. So this is a GRC and access risk tool and there is some simulation here. We can simulate the risk of adding more access to a user. But if we have the license manager as well, we can add some more functionality to that. So here we're imagining that Kayla is asking for some more access. She wants to do some payroll posting. We'll run the simulation. What is the risk of giving that role to Kayla? It's going to introduce some new risk that's detailed down here, but it's also going to have a licensing impact. If we look at this here, adding that advanced role to Kayla will push her from a self-service user to an advanced user. So we can have a workflow here where someone approves the risk, but they could also improve approve the license impact as well. So let's jump quickly back to the presentation, and I just like to give you some advice of what you should be doing, really. If you would like to go for a license assessment, you can understand what the users actually use. We can see what roles are unused and how those are driving your FUI count. The benefits of the licensing assessment, you can get an understanding of the potential cost of moving to RISE and support your business case. You can understand what the remediation options are, and you can also look at those three key data points, which are the you know, what you're using now, the cleanup opportunity, and whether it's worth actually doing a full role redesign. What do we need to do for that? We need to turn on that trace, and we need to accumulate at least two months of usage data so that we can be sure that we know what people are actually doing in the system. And what we will give you for the free assessment are the headline numbers, those three numbers of what your current and cleanup opportunities are, and some examples of the savings as I just showed you there. So I'll pass back to you, Joey, to finish off. Yes. Thank you, Roy, for such a wonderful, insightful session about SAP FUE licensing. So I believe our attendees now have much clearer understanding of the FUE licensing. So what you see on the screen here is that we actually created a SAP S4HANA FUE licensing readiness checklist that can help you assess whether your organization is prepared to navigate FUE licensing model and to avoid locking in inflated and also long term cost. So we will include this checklist download link in a follow-up email together with the webinar recording. So since we have run a little bit over time, we will also answer the remaining question in the follow-up email. Thank you everyone for joining us. Thank you, Roy, for this session. Very welcome. Thank you everyone for joining. Bye. Thank you. Bye.