With SAP moving to access-based licensing under the Full User Equivalent (FUE) model, businesses need to take a closer look at their roles and authorizations to avoid unnecessary costs. Instead of being viewed as a challenge, the shift is an opportunity to save money and enhance compliance.
This blog answers key questions about the FUE license model and its implications for your business. This comprehensive and continuously updated list includes questions asked during our webinar – RISE Right: How to Avoid FUEing Up Your S/4 Licensing – and others that we’ve received during workshops and conversations with clients.
The FAQs covered here will help you navigate the change with confidence, for better cost optimization and compliance, whether you’re preparing for a license renewal or exploring a RISE with SAP migration.
About the FUE License Model
Q: If FUE is about 'consumption' of SAP, how does it apply if we buy on-premise licenses?
Q: Can anyone run a STAR report?
Q: Is the STAR report based on usage by user (real use), or assignment and classification?
FUE Pricing and Savings
Q: How does derivative pricing work?
Q: What is the estimate of the approximate savings you could bring?
How to Proceed
Q: If we've already run a STAR report, is it too late for us? What can I do now?
Q: How close to the beginning of an S/4HANA project should this activity be completed?
Q: Is there anything we can do if SAP has the STAR report already?
Q: What are the different roles that Turnkey and Invictus play within this transition?
RISE Renewals
Q: For FUE uplift from the initial RISE contract, are the delta contracts true-up and down-scalable?
Q: What happens after the initial contract term with RISE? Can we renegotiate the terms?
About the FUE License Model
Q: What is an FUE?
A: FUE stands for Full User Equivalent. It refers to the new license metric that equates users to licensable units, and provides an index to value different user types based on their system usage. Under the FUE system:
-
Developers and support users are classed as 0.5:1, equating to 2 FUEs per user.
-
Advanced users equate to former "professional" users with a 1:1 mapping.
-
Core equates to Functional users transacting business tasks with a 5:1 mapping, or 0.20 FUE per user.
-
Self-serve is mapped to "productivity" users with a 30:1 mapping or 0.03 FUE per user.
Q: If FUE is about 'consumption' of SAP, how does it apply if we buy on-premise licenses?
A: The FUE license model is only available in cloud editions of S/4HANA (Public and Private). Traditional on-premise, perpetual license quantities still need to be maintained per user type as deployed in the system.
Q: Are the critical considerations for FUE purely for a RISE option, or are FUEs relevant for a Hyperscaler (e.g. native Azure) deployment of ECC EHP7 with a later move to S4?
A: No, FUEs are only applicable to Cloud editions of S/4HANA (i.e. Public and Private). Where you take your systems to Azure natively, SAP still considers this an "on-premise" deployment and your traditional perpetual licenses are to be used. Any license move in this scenario from ECC to S/4HANA would likely require a contract conversion where you license perpetually for S/4HANA and retain use rights to ECC for a period of time. Q: How is FUE assignment done? Is this done by individuals within the SAP authorization team by reviewing user access and authorizations, and then assigning the correct FUE? Or is there an automated SAP tool that can do this for us?
A: In any S/4HANA system (on-prem or cloud) users are assigned roles to carry out their jobs. These roles/authorizations then indicate what User License Type that user falls into. In on-premise systems, the quantity of User Type Licenses need to be managed by type and appropriate license levels maintained.
In an S/4HANA system in cloud (i.e. RISE) exactly the same technical process is performed to allow a user to do their jobs. However in RISE, at a point in time, a snapshot view of the various users and their user types (taken from SLAW and likely Object Analyzer) are pushed through the FUE "ratios" to get to a Total FUE count. This is then compared to your contracted entitlement.
The PC User Metering being introduced to RISE is "just" an automated way to do the above.
Q: Can anyone run a STAR report?
A: Yes - sort of. The underlying SAP report is the Object Analyzer. This produces screen output and some binary files that are sent to SAP (if you allow the system to). The STAR Service that SAP provides takes the output from the Object Analyzer and presents it back to you to determine the FUEs required.
The Object Analyzer screen output also presents this data in a more raw format, but the information is clearly available and can be rerun time and again so you can monitor the impact of any remediation changes being made. We recommend you work with Turnkey on the STAR report.
Q: Is the STAR report based on usage by user (real use), or assignment and classification?
A: The STAR report looks at authorizations assigned to users (what they can theoretically do) and how these authorizations map to the various license types. Assignment and classification are ignored during an audit because that is the customer-labelled assignment. This can be run in ECC6 as well as S/4HANA.
Authorization assignments are almost always a mess, so overlaying this with the user's actual usage (what they actually did) aids in remediating any apparent overuse the authorization assignments have created.
Q: Is the ‘Rule of 7’ based on seven times our annual perpetual support spend, or something else? Does it still apply if we move payroll to ECP in Success Factors?
A: The ‘Rule of 7’ is an internal model that SAP will use to offset the potential future losses of perpetual maintenance in favor of a term license. Whilst it is known about in the market, it is not an absolute rule and is at the discretion of SAP's own business decisions.
SAP views the commercial life of any maintenance value today at seven years. So when maintenance revenue is being replaced by cloud revenue, the net spend in cloud TCV (total contract value) must equal or be more than seven times the maintenance value being terminated.
This applies to any maintenance being terminated in favor of cloud (called the Cloud Extension Policy within SAP) so terminating perpetual payroll licenses and maintenance in favor of ECP would need to meet this rule.
For example, if payroll maintenance spend is £1000 then the ECP TCV must be at least £7000. However, it doesn't need to be a seven-year ECP contract.
If ECP is a five-year agreement, the ACV (Annual Contract Value) would need to be at least 7/5 (or 1.4x) the current annual maintenance fee:
-
£1,000 x 1.4 = £1,400 ACV
-
£1,400 x 5 years = £7,000 TCV
If ECP is a three-year agreement, ACV needs to be at least 7/3 (or 2.33x) the current annual maintenance fee:
-
£1,000 x 2.33 = £2,333 ACV
-
£2,333 x 3 years = £7,000 TCV
Q: How is compliance managed for FUE and licenses within RISE/S4 HANA - is this done via 'SAP For Me' or an alternative tool?
A: As SAP builds out the automated metering for RISE, the usage levels will become available in SAP For Me. FUE metering has been released and they continue to develop the metering for engines and other license types.
It appears that the metering in the cloud will be done on a monthly basis. Contractually, you will need to be appropriately licensed at all times, although in practice, SAP does not appear to be rigorously prosecuting any overuse as it happens in RISE. SAP has indicated to some of our customers that if there is persistent overuse for a number of months, your Account Executive will partake in a discussion and a true-up is probably needed.
FUE Pricing and Savings
Q: How does derivative pricing work?
A: Derivative pricing is used for SAP materials that derive their fee calculation from other materials in the BoM. In this manner, once you have your FUE count and the default sizing applied, variances or add-ons can be added based upon that starting point. For example, Disaster Recovery is calculated at 17% of the net fee of the DR-relevant in the BoM. Other examples are the 4-hour RTO and 99.9% SLA uplifts.
Q: Can a larger T-shirt size save more money than a lower size, whilst giving us the comfort of more FUEs to work with in our authorization design?
A: There is a link between the FUE volume and the T-shirt sizing for infrastructure. There is usually a sweet spot, where you may be able to get a better overall price by uplifting to a larger FUE bucket to default to the larger system sizing, and thus avoid the costly add-on extensions to scale up to your target sizing. It is not always the case, but when discussing your needs with SAP, it’s useful to remain aware that this link exists and to factor that into your commercial management strategy.
Having a clear understanding of current user types and quantities, system landscape sizing, solution roadmap and growth trajectory all feed into where to find that sweet spot.
Q: What is the estimate of the approximate savings you could bring?
A: Although each case is different, in many cases we have managed to save approximately 50% of the planned SAP license exposure for our clients.
Q: What sort of data/reports can I share with you to give me a ROM/estimate of the approximate savings and costs involved?
A: All materials discussed in an active workshop will be indicative, although we can support you in a more specific advisory service directly. In principle, the main items to bring with you are:
-
Your current number of SAP licenses.
-
Current license breakdown by users.
-
Current scope of solutions (systems, modules etc.).
-
Current broad database/system sizing.
-
Planned business strategic use cases (e.g. growth targets, divestments, application hosting approach etc).
-
Anticipated deployment model (e.g. public cloud, private cloud, hyperscaler, on-premise).
How to Proceed
Q: If we've already run a STAR report, is it too late for us? What can I do now?
A: It depends if the STAR service has revealed any significant exposure or not. If there is exposure, this has given SAP some leverage over you to contract something commercially. SAP will likely push for a resolution and will make any on-premise true-up very unattractive, by onlye offering low discounting and simultaneously presenting a RISE TCO that looks like a slam-dunk.
However, it is never too late to indicate to SAP that, while you have put your best efforts into maintaining accurate user assignments, the authorizations mappings have always been hard to navigate. Ask for time to remediate the problem and talk to us at Turnkey for help and advice if you feel you need it.
If RISE is something you could entertain in the future, you can get some time back to remediate the problem while you also assess the viability of RISE for your organization.
Q: If we have already signed our RISE contract, based on a phased increase in FUE and infra sizing as more countries are implemented onto RISE, and then the implementation project is delayed, can we renegotiate with SAP to defer the FUE and infra increase?
A: While SAP is not contractually obliged to defer or terminate agreements unless they are at fault, SAP wants successful RISE go-lives they can talk about. Consequently, SAP is usually open to discussion about changes to agreement timelines. Deferring revenue impacts the revenue that SAP is able to recognize, so any agreement would likely be shaped by financial year timing and commitments within set timelines.
Q: What is the best way forward: consult Turnkey before running the STAR report, or explore alternatives for RISE and go with a hyperscaler who could offer a managed service?
A: When executing the reports that feed into the STAR service SAP offers, do not send the results to SAP. The output can be read without sharing the detail with SAP, but it can be a little confusing to get the exact detail required. This is where Turnkey and Invictus can provide assistance in understanding the result and determine a course of action if remediation is required.
We feel it is important for customers to be informed about all options available to them, not just the ones SAP is pushing. So exploring alternatives to RISE doesn't necessarily mean you wouldn't select RISE in the end. Having a clear, unbiased view of the options aids in making the decision. SAP does this en masse and is equipped to provide the service. Whether you feel a native hyperscaler with a managed service is better for you is a decision you need to make based on the factors most important to your business.
Q: How close to the beginning of an S/4HANA project should this activity be completed?
A: Ideally, the roles and authorizations work should be factored in as early as possible in these initiatives to unlock the greatest value from the activities.
Roles and authorizations are often elements of a program that end up being either rushed or cut. If you have an existing deployment of SAP, in whatever form, the FUE conversion is a time-critical activity required to sort out the upfront licensing conditions for the future. The sooner you get clarity and control over the FUE calculation and needs, the more value you'll unlock later in the deployment. That could be authorization optimization or just business use forecasting.
The change is that SAP has a mechanism to determine the authorizations by user (both in cloud and on-premise) thus the correct allocation of authorizations becomes more important commercially right at the outset of your program. Continuing to keep a focus on the assignment of these authorizations means you protect yourself from future compliance issues and simplify future license negotiations as well.
Often the roles and authorizations just get moved over from ECC to S/4HANA without any remediation. If there is work to be done it probably makes sense to do it during the migration to S/4HANA, thereby minimizing any retesting, etc.
Or start now - you're already overusing (according to SAP that is).
Q: Is there anything we can do if SAP has the STAR report already?
A: No, not really. If the STAR report indicates significant over-use, it would be up to the Account Executive to initiate an audit or not. If your relationship is good, then you’ll likely be able to have a discussion about it.
If there is exposure, depending on your SAP rep, they may use this as leverage over you to contract something commercially. SAP will likely push for a resolution and will make any on-premise true-up very unattractive with low discounting and, at the same time, present a RISE TCO that looks like a no-brainer.
However, Invictus and Turnkey have collectively supported our clients through these challenges if they occur. It is never too late to indicate to SAP that, while you have put your best efforts into maintaining accurate user assignments, the authorizations mappings have always been hard to navigate. Ask for time to remediate the problem and talk to us to help.
Q: What are the different roles that Turnkey and Invictus play within this transition?
A: Turnkey and Invictus do the analysis of security together. Turnkey provides the service to identify opportunities to "fix" any role/authorization problems identified in order to improve licensing. Invictus takes the end result of "fixed" role/authorization user numbers converted to FUEs and helps with sizing, BoM validation, commercial negotiations, etc.
RISE Renewal
Q: I know about cloud lock-in for Microsoft and AWS, and I'm currently on RISE after a big 5 implementation 3 years ago - it hasn't been a smooth experience. As we come towards our renewal, can you advise on how you will approach this beyond just the Enterprise Central Component (ECC) considerations?
A: For customers already on early RISE contracts (or RISE precursors like Single Tenant Edition), where the renewal is approaching and adjustments to the commercials are required, this is a good opportunity to look to recut the agreement in your favor.
Obviously SAP is invested in keeping your revenue locked in, so they should be open to the request. Be cautious to ensure all systems remain as they are from a technical standpoint and that any changes are commercial in nature.
The important thing is to go into the renewal with the best possible clarity on your current use of the solution, and your plans for the future. If you have control of your FUEs and know what you're looking to do (i.e. grow organically, acquire, divest, etc.) you can set out the correct story with SAP to match your demands with the best options available to you. That way, you're taking more control of negotiations and can support the data with the appropriate story to suit your desired outcomes.
Q: As we go into renewal, we find that there is a massive gap in understanding between the service description and feature description documents from SAP RISE PCE. This pertains to the associated roles and codes that are supposed to outline the difference between FUE Advance, Core and Self Service. What is available to support this easily and model it?
A: SAP has maintained this obscurity for a long time. Recently there has been some collateral released about the relationship between authorizations and license types, particularly in relation to the STAR service that SAP offers.
Based on this information (and not just giving the data to SAP to analyze for you), Turnkey and Invictus Partners have helped numerous customers gain a more granular view of their authorization-to-license mix.
The "rules" for the triggering of different license types have now been published and are part of our standard assessment and ruleset criteria for implementations. However, that is only part of the picture. As explained, the FUE allocation is a starting point for the contractual negotiation and the source for further derivative pricing calculations and right-sizing for computing power.
Getting this FUE starting point right is a key dependency for your solutions, but it’s a service/activity where we at Turnkey can give you all the support you need throughout.
Q: For FUE uplift from the initial RISE contract, are the delta contracts true-up and down-scalable?
A: As always with SAP, the price never goes down. You're always able to true-up but reducing spend is hard. Within initial term agreements, flexibility can be negotiated into the contract and allow for swap rights, but even then the spend does not reduce and it's not always something the SAP Board is willing to give.
For subsequent renewals of the RISE agreement, there is an opportunity to recut the commercials in a way that reduces the quantities, but SAP will be very keen to at least maintain the previous revenue level. Your Account Executive is effectively penalized if the spend value decreases, so assistance from SAP to do this will be feeble.
There are various options to consider, for example, if you have other SAP LoB solutions in your roadmap. Bringing the commercial discussions of downsizing RISE while increasing (or newly subscribing to) other SAP cloud LoB will ease this process.
Q: Our current contract proposal includes a final year FUE 'doubling' - SAP claims this will give us a lower Price Per User (PPU) over the 5-year term and enable access to a larger infrastructure landscape. Should we be concerned about this approach? Will the Year 5 FUE figure become the baseline for subsequent contracts? SAP suggests this is 'renegotiable' in Year 4, but how realistic is that?
A: While ramping up in a RISE agreement is common and necessary, having a massive double-up in the final year should raise some red flags. In theory, the PPU for the whole agreement is driven by the highest tier level in the BOM (i.e. lowest price). SAP is likely to crack down on their Account Executives for modeling deals like this because it's not good business for them.
There are also some considerations for you to be aware of:
-
The exit rate of the agreement (i.e. the value to be renewed) will be at the highest level and will continue on.
-
The larger infrastructure landscape is only available when that FUE tier level comes into effect (i.e. the last year). For the first four years, you will have to uplift the intermediate tiers with memory extensions, database/file storage, etc, to have a landscape that works. There is a tipping point where the higher T-shirt sized tier is cheaper than a lower tier plus extensions. Finding this sweet spot is key to a cost-effective arrangement.
-
Renegotiating at Year 4 is a throw-away line. It may well be possible, but it may also come with constraints and restrictions at the time that are unknown now. This is lazy deal crafting and will leave you exposed to risk.
Price is only one (albeit important) aspect of what is a once-in-a-generation negotiation with SAP. Switching out an ERP is not done lightly, so getting the commercial construct right with the flexibility and certainty you need for both the initial term and subsequent renewals is key.
Q: What happens after the initial contract term with RISE? Can we renegotiate the terms?
A: Generally, RISE agreements have an auto-renew status, where if you do not notify SAP ahead of time, it will just roll into the subsequent years with the contract fee uplifts etc.
Terms can be renegotiated after the initial term, should you have the need to do so. The trick to being successful in doing this is understanding what SAP can move on and what they can't. Ask for the hard changes with an eye on how SAP is able to say yes to the request. Having a negotiation strategy laid out with clear positions on the various requests would be advisable.
Navigating SAP’s new licensing model? Turnkey can help with license review, user role optimization, and ongoing access governance support to help minimize costs and boost compliance. If you're preparing for a renewal or migration, get in touch with us today to get started.
