The FUE weights, the committed volume, and what growth above it costs. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session twenty two. Last time we opened module five with what is actually inside the RISE bundle. This session is the arithmetic underneath the price of it. Two numbers decide what RISE costs you: a weighted user figure called FUE, and a capacity figure for the system itself. The first of those is very largely within your control, because classification is a decision rather than a fact, and this session is mostly about making that decision well and making it early. Three knowledge checks, one of which is arithmetic, so have a moment ready to pause. Let's begin.
Five objectives. First, apply the weights: Advanced at one point zero, Core at nought point two, Self-Service at roughly one thirtieth, and what each classification actually permits. Second, convert your population, meaning turn a named user list into an FUE figure you can defend, using the cleanup sequence from session seventeen. Third, set a commitment, which means sizing to the end of the term rather than to today, and using a ramp where the growth is real and dated. Fourth, price the overage: know what a user above the commitment costs, and settle that rate before you sign rather than after. And fifth, separate the two meters, because FUE prices people and capacity prices the system, and confusing them is how sizing conversations go wrong.
Four things to frame it. FUE: your weighted user population, almost entirely within your control, because classification is a decision you make. Capacity: compute, memory and storage for the system itself, driven by data volume and workload rather than by headcount. The commitment: the volume you promise to buy for the term, set once and paid for every year whether or not you use it. And the overage: what a user above the commitment costs, negotiated cheaply now or expensively in year three. The whole of this session is really one argument, which is that the FUE number is a decision rather than a fact, and the time to make that decision well is before the baseline is taken. Let's hear why that timing matters so much.
Guest analyst clip.
Before the baseline, not after. That is the single most valuable sentence in this session, and it is worth being blunt about why. Once a measurement is taken and written into a contract, it stops being a technical figure and becomes a commercial fact. Everything you could have done to it cheaply, you now have to do expensively, by asking permission. So the work goes first and the measurement goes second. Let's look at what the weights actually are.
Four user types. Advanced Use at one point zero: full functional users, so finance, controlling, procurement, anyone configuring or transacting broadly. Core Use at nought point two: operational users with a defined scope, meaning warehouse, shop floor, service entry, straightforward transactions. Self-Service Use at roughly one thirtieth: occasional users doing their own admin, a leave request, an expense claim, a purchase requisition. And Developer Use at one point zero: anyone building or extending, small in number, and never the place to look for savings. Here is the thing to hold onto. Five Core users cost the same as one Advanced user. Thirty Self-Service users cost about the same as one. That ratio is the entire negotiation, and notice that it rewards accuracy rather than optimism, because a misclassification in either direction is expensive, just in different ways.
So how do you get from a named user list to a number you can defend? Four steps, and the order matters more than the effort. One, remove: leavers, duplicates, test and system accounts, which is session eight's work and still the cheapest FUE you will ever save. Two, observe: what each remaining user actually does, taken from transaction history rather than from the role they were given years ago. Three, reclassify: move users to the lowest band their real usage supports, which is the lever, and which is entirely legitimate. And four, baseline: only now take the measurement that becomes the commitment. A baseline taken before step three is money given away, and given away annually for the length of the term. The same population, measured before and after this work, routinely differs by a quarter or more.
First knowledge check, and this one is arithmetic. You have three hundred Advanced, five hundred Core and three thousand Self-Service users. Roughly what is the FUE figure? A, about three thousand eight hundred, since every user counts once. B, about five hundred, being three hundred plus one hundred plus one hundred. C, about eight hundred, being three hundred plus five hundred, with Self-Service free. D, about three hundred, since only Advanced users are counted. Pause here and do the arithmetic before you continue.
The answer is B. Three hundred Advanced at one point zero is three hundred. Five hundred Core at nought point two is one hundred. Three thousand Self-Service at roughly one thirtieth is about one hundred. So that is five hundred FUE from three thousand eight hundred human beings. A is the error that makes people think S four HANA is unaffordable, and it is exactly the number you get if you never classify anybody. C treats Self-Service as free, which it is not, and that gap alone is one hundred FUE. D ignores two thirds of the cost. But notice what the arithmetic actually implies: moving one hundred users from Advanced down to Core saves you eighty FUE, every year, for the whole term. That is the highest paid hour of work available to you in this entire programme.
Now, sizing the commitment. Five rules. Size to the end, not the start: you are buying a run rate for the whole term, so model the population in the final year rather than the one you have today. Use a ramp for dated growth: if an acquisition or a rollout lands in year two, commit to a lower figure now and a higher one then, and ask for that explicitly. Do not commit to hopes: growth that is planned but undated belongs in the overage rate, not in a volume you pay for from day one. Leave the headroom small, because unused commitment is shelfware with a subscription label, and it converts into nothing at renewal. And write the measurement method down: who counts, how often, from which system, and what happens to a disputed classification. That third rule is the one people argue with, so let's hear it properly.
Guest analyst clip.
Do not pay today for a headcount you might have in year four. And notice the asymmetry that makes this rule work, because it is the whole reason the advice is one-directional. If you undersize, you buy the difference later at a rate you negotiated. If you oversize, there is usually no mechanism at all to give it back. One error is recoverable and the other one is not, so when the forecast is genuinely uncertain you should be wrong in the recoverable direction.
Second knowledge check. You expect to grow twenty percent over a five year term, with no dated milestone attached to that growth. What should you commit to? A, today's figure plus twenty percent, so you are covered. B, close to today's figure, with the overage rate negotiated and capped. C, today's figure minus a margin, and buy the shortfall later. D, whatever figure produces the best headline discount. Pause here before you continue.
The answer is B. Undated growth is a forecast, and you pay for a commitment from day one whether the growth arrives or not, so buying it up front means five years of paying for users who may never exist. The correct instrument is a negotiated overage rate, agreed while you still have leverage, so that growth costs a known amount when and if it happens. A pays for a forecast. C sounds clever, but it leaves you buying the shortfall at the undefended rate, which is the same trap approached from the other side. And D is how organisations end up committing to a number that was chosen by a discount table rather than by their own headcount, which is a genuinely common way to overspend by a large margin.
So the overage. Four things to establish in writing, because all four are easy to agree now and expensive to discover later. The rate: what one FUE above the commitment costs, and it should be the same rate you negotiated rather than a list price with the discount quietly removed. The trigger: measured when, and against what, because an annual true-up is a very different thing from a monthly one if your business is seasonal. The direction: can the commitment come down if the population does? Usually not, and that is precisely why you do not oversize it in the first place. And the effect on renewal: does an overage year reset the baseline for the next term, because if it does, one busy year gets priced in permanently. Let's hear this one argued.
Guest analyst clip.
The rate you never negotiate is the rate you eventually pay. That is session twelve's lesson arriving in a new metric, and it will arrive again before this course is finished. An undefended overage clause is the most reliable way I know for a genuinely good first term to turn into an expensive fourth one, and the thing that makes it so effective is that nobody ever feels it happening. There is no renegotiation, no meeting, no decision to point at. There is just a true-up, and a number that was set by default years earlier.
Now, the other meter, and this is the part that gets missed. Five things FUE does not cover. Compute and memory: the system is sized on data volume and workload, in capacity units, which is a separate line that grows with your data rather than your headcount. Non production systems: development, test and quality landscapes are capacity you pay for, so ask how many are included before you assume. BTP consumption: integration and extension run on the platform allowance from session twenty one, metered separately and running out quietly. Digital Access: indirect document creation is its own meter, entirely unchanged by the move, so module three applies inside RISE exactly as it did outside it. And the implementation, which is not a meter at all, and is usually the largest number in the first two years, sitting outside every figure on this slide.
Five traps, and you will recognise most of them. Baselining before cleaning: taking the measurement first and doing the classification work afterwards, which turns a technical figure into a commercial fact you then have to buy your way out of. Buying the forecast: committing to undated growth from day one, so you pay for five years for users who may never join. Leaving the overage undefended: no agreed rate above the commitment, so growth is bought at whatever the price list says in the year it happens. Modelling capacity off headcount: assuming the system meter follows the people meter, when it follows your data, and for many businesses those two diverge sharply. And letting the bands drift back up: reclassifying once, at signature, and never again, so the roles creep upward on their own and the saving quietly reverses.
Last knowledge check. Your data volume doubles but your headcount is completely flat. What happens to your RISE cost? A, nothing, since FUE is flat so the price is flat. B, capacity rises even though FUE does not. C, FUE is recalculated upward to reflect the data. D, it triggers a Digital Access assessment. Pause here, and think about which meter is turning.
B. The two meters are independent. FUE prices people and capacity prices the system, so a data-heavy, people-light business can hold its user number completely flat and still watch the bill rise year after year. A is the assumption that makes budgets wrong, because it treats the user number as though it were the whole price. C is false, since data volume does not reclassify users. And D confuses two different things, because Digital Access is about documents created by external systems, not about how much data you happen to be storing. The practical consequence is that your capacity growth needs its own forecast and its own owner. Let's finish on that.
Guest analyst clip.
Two meters, two owners. So, five things to run the number once you are in. Measure quarterly rather than annually, because a surprise at the true-up is a failure of measurement rather than of luck, and you want to know your position before the vendor tells you what it is. Rebalance the bands continuously, because roles drift upward on their own, and a quarterly review that moves drifted users back down pays for itself in a single cycle. Track capacity separately, with its own line, its own trend and its own forecast. Watch the BTP allowance, since consumption grows quietly and the allowance is finite. And keep the classification evidence: usage data behind every reclassification, kept current, because a defensible classification is one you can show rather than one you assert, and almost nobody keeps it.
Three sentences. FUE weights your population rather than counting it, at one point zero for Advanced, nought point two for Core and roughly one thirtieth for Self-Service, so three thousand eight hundred people can be five hundred FUE, and classification is where the money is. The commitment is sized to the end of the term rather than to today, with a ramp only where growth is dated, because undated growth belongs in a negotiated overage rate rather than in a volume you pay for from day one. And FUE is only one of the meters, since capacity, BTP consumption, Digital Access and the implementation are all priced separately, and a business whose data grows faster than its headcount will feel that immediately. Next session moves to GROW with SAP, which is the public edition path for mid-market and net-new customers, and what standardisation actually costs you.
Homework before session twenty three, about ninety minutes, and the first one is genuinely worth doing properly. One, convert your own population: take your named user list, apply the four weights, and write down the FUE figure. Most people are surprised by it, usually in the good direction. Two, find the drift: how many Advanced users have not performed an Advanced action in ninety days? That number is your reclassification opportunity, stated in money. Three, model the final year: what is your population in year five, and what is that actually based on? Separate the dated growth from the hoped-for growth, because they get treated completely differently. Four, write the overage question: one sentence asking for the rate, the trigger, the direction and the renewal effect, sent before the shape is agreed. And five, ask for your capacity forecast, meaning get your data growth rate from whoever owns the database, because it is the meter nobody in the licensing conversation is watching.
Five guides, all on redresscompliance dot com. The RISE pricing benchmarks show where the FUE rates actually sit, which is what you need for sizing a budget before a quote arrives. The S four HANA FUE model explained takes slide four and the conversion sequence into much more detail than we had time for here. RISE negotiation tactics covers the overage and commitment clauses and what is realistically winnable on each. SAP user classification and cleanup is the reclassification work that has to happen before the baseline, and if you only have time for one, take that one and read it before you let anybody take a measurement. And RISE hidden costs expands slide twelve, meaning everything that is metered separately from the user number.
That is session twenty two. The thing to take away is that FUE is a decision rather than a fact, so do the classification work before the baseline, not after it. Next time, GROW with SAP and the public edition. See you then.