The FUE metric, and what it does to the population you already have. 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 seventeen. Last time was the date. This time it is the product, and specifically what happens to the user model when you move to S four HANA. It changes shape completely. The named user catalog you spent module two learning, with its Professional and Limited Professional and Employee Self Service types and all the definitional arguments that go with them, is replaced by a single weighted number called the Full Use Equivalent, or FUE. And I want to say something unusual at the start of a licensing session: this change is genuinely in the buyer's favour. There is a condition attached, which we will get to, and it is a real improvement. Three knowledge checks, and the first one is arithmetic, so have a pen. Let's begin.
Five things by the end. First, explain FUE: what a Full Use Equivalent is, why it is a pool rather than a list, and what that changes about how you buy. Second, apply the weights: Advanced at one, Core at a fifth, Self-Service at a thirtieth, and the arithmetic that turns a headcount into a licence requirement. Third, map your population, in five steps from role data to band assignment, and understand why translating your old licence types straight across is the expensive route. Fourth, know what is not FUE, because the engines, the database and the optional components sit alongside it and they produce most of the surprise in a conversion quote. And fifth, size the number properly: clean it, weight it, project it by band, and buy for the end of the term rather than for today.
Four things to frame it. FUE: the Full Use Equivalent, one pooled number that replaces a catalog of licence types with a single weighted total. The ratios: Advanced counts as one, Core as a fifth, Self-Service as a thirtieth, and those three numbers are essentially the entire model. A pool: you buy a quantity of FUE and you allocate it, so moving somebody between bands is an internal action rather than a purchase. And classification: the weights only help you if people sit in the right band, so session seven's evidence work applies here completely unchanged. Now the framing sentence for the session. FUE is a better metric than the old catalog for most buyers, because it is arithmetic rather than definitions. And that advantage disappears entirely if your classification is wrong, because a precise weight applied to the wrong band is still the wrong answer. Let's play a clip on that.
Guest analyst clip. I want to be positive about something, which is rare in this field, so I will take the opportunity. FUE is a better metric than the named user catalog, and I think buyers should say so. Here is why. Under the old model, the difference between a Professional licence and a Limited Professional licence was a definitional argument. You would sit in a room and debate whether creating a purchase requisition constitutes operational use or professional use, and the answer determined a price difference of several thousand pounds per person, and there was no arithmetic anywhere in the conversation. It was interpretation, and interpretation favours whoever wrote the definition. FUE replaces most of that with multiplication. A user who only does self service costs one thirtieth of a user who does everything. That is not a matter of opinion. You can compute it, they can compute it, and you can therefore have a disagreement about the facts of who does what, rather than about what words mean. That is a far better kind of disagreement to be in. Now, the condition. The weights only reward you if the classification work has been done honestly. If you take two thousand Professional users and map them all to Advanced because it is Friday afternoon, you have adopted a superior metric and produced an inferior answer. The model rewards precision. It does not supply it.
The model rewards precision, it does not supply it. That is the sentence I would keep. And notice what it implies about sequencing: the classification work from sessions six, seven and eight is not preparation for S four HANA, it is the thing that determines what S four HANA costs you. If you have not done it, the conversion is the moment where not doing it becomes expensive, because every misclassification gets repriced at the new weights. So let's start with what the metric actually is.
Four properties. A weighted total: each band carries a weight, you multiply the headcount in each band by its weight, you add them up, and that sum is your FUE requirement. A pool rather than a list: you hold a quantity of FUE and users draw against it, which means reallocating somebody between bands is an internal action and not a transaction with SAP. Still per named user: and this is the one people miss, because FUE does not remove named user licensing, it reprices it, so every person still has to be identified and classified into a band. And separate from engines: packages and engines keep their own metrics alongside FUE exactly as they did under ECC, so nothing about module two's second axis changes at all. The genuinely useful property is the first one combined with the ratios. A low activity user is now cheap by arithmetic. Under the old catalog the gap between Professional and Employee Self Service was a definitional argument. Here it is a multiplication, and multiplications do not require anybody's agreement.
So here are the bands. Advanced Use, weight one point zero: full transactional and configuration work, which is your professional population. Core Use, weight nought point two: operational transactions within a defined scope, and note what that ratio means, which is that five Core users cost one FUE. Self-Service Use, weight one thirtieth: occasional self service only, so thirty people cost a single FUE. And Developer, at full weight of one, for development and extension work. Two instructions. First, check the weights and the band definitions against your own price list version, per session four, because these are the published ratios and the wording in your paper is what binds you. And second, hold on to the shape rather than the decimals: one Advanced equals five Core equals thirty Self-Service. If you remember only that, you can sanity check any quote you are shown in about thirty seconds.
First knowledge check, and this one is arithmetic. You have four hundred Advanced users, one thousand Core users and three thousand Self-Service users. What is your FUE requirement? A, four thousand four hundred. B, seven hundred. C, one thousand four hundred. D, six hundred and forty. Pause here and actually do the multiplication before you continue.
The answer is B, seven hundred. Four hundred times one point zero is four hundred. One thousand times nought point two is two hundred. Three thousand divided by thirty is one hundred. Four hundred plus two hundred plus one hundred is seven hundred. Now, A is four thousand four hundred, which is simply the headcount added up with the weights ignored, and I want to be clear that this error appears in real budget papers, because somebody sees four and a half thousand users and assumes four and a half thousand licences. It makes S four HANA look several times more expensive than it is and it has killed business cases that should have proceeded. C and D are the kind of slip that happens when the weights are half remembered. Do this calculation on your own population before anybody quotes you a figure, because it is the number the entire proposal is built on.
So how do you get to a band assignment? Five steps. Start from roles and not licences: what people actually do, using session seven's evidence, because the existing licence type is a historical artefact rather than a starting point. Find the Self-Service population: leave requests, expenses, payslips, occasional lookups, and at a thirtieth each, getting this band right is worth more than most negotiations you will ever have. Test the Core boundary: operational transactions within a defined scope, and this is where most of the money moves, so the definitions repay very careful reading. Justify every Advanced: full weight, so each one should carry a named reason, because Advanced by default is exactly how an FUE number quietly doubles. And the fifth: recount, do not translate. Never map old licence types one for one into new bands. Let's hear why that last one matters as much as it does.
Guest analyst clip. There is a decision made very early in a conversion project that determines a large part of its cost, and it is usually made by somebody junior under time pressure without anybody realising it is a decision at all. It is this: do we translate the existing licence assignments into the new bands, or do we recount the population from scratch? Translating is fast. You write a mapping table. Professional becomes Advanced, Limited Professional becomes Core, Employee Self Service becomes Self-Service, and you are finished by lunchtime. And every single classification error your organisation has accumulated over fifteen years travels straight through into the new model, and gets repriced. Think about what is in a typical Professional population. People who changed job four years ago and kept their old access. Contractors who left. Somebody who needed one report once in twenty nineteen. A batch of accounts created for a project that finished. Under the old model each of those was an overpayment. Under FUE each is a full weight unit in a pool you are about to buy. Recounting takes a few weeks and it needs role data, which you should have from session seven anyway. In my experience it moves somewhere between a third and a half of a translated Advanced population into cheaper bands. That is the difference between a good conversion number and a bad one, and it is decided before anybody negotiates anything.
Between a third and a half of a translated Advanced population. That matches what I have seen, and I would add one practical note about how to get the recount funded, because it does need a few weeks of somebody's time. Do not present it as a licensing exercise. Present it as the number itself: here is our conversion cost if we translate, here is our conversion cost if we recount, and here is the difference. The gap is almost always far larger than the cost of the work, and once it is on a page in those terms it stops being a debate.
Second knowledge check. Your ECC estate has two thousand Professional users. What is the right first move for the S four HANA count? A, map all two thousand to Advanced, since it is the same people with the same rights. B, re-derive from role data, then assign bands from actual activity. C, assume a standard split and refine it later. D, ask SAP to propose the mapping from your last measurement. Pause here before you continue.
The answer is B. A Professional population is the accumulated result of years of defaults, leavers and convenience assignments, so mapping it one for one imports every one of those at full weight, which is precisely the clip's argument. B is a few weeks of work that routinely moves a large share of that population into cheaper bands. A is the path of least resistance and it becomes the most expensive line in the proposal. C sounds pragmatic and then quietly becomes the number, because refine later almost never happens once a figure is in a business case. And D hands your classification to the party whose revenue depends on the result, which is not an accusation of bad faith, it is just an obviously poor allocation of the task.
Now, what FUE does not cover, because this is where conversion quotes surprise people. Packages and engines: still licensed on their own metrics, exactly as under ECC, so session nine's engine register carries straight across unchanged. The database: S four HANA runs on HANA, and the database is licensed separately on its own basis, which is next session in full. Digital Access: document based indirect use is priced independently of FUE, so everything in module three applies exactly as it did. And optional components: advanced financial closing, group reporting and similar are separately licensed, and they are very easy to assume are simply included in the product. Put those four together and you have the reason the entitlement baseline has to be complete rather than user focused. Let's hear that made properly, because I think it is the most practically useful warning in this session.
Guest analyst clip. I want to warn you about a specific shape of surprise, because it happens repeatedly and it is entirely avoidable. Everybody focuses on the FUE line. It is the headline, it is where the user story is, it is the number that appears in the business case, and teams spend months getting it right. Then the quote arrives and the FUE line is roughly what was expected, and the total is forty percent higher than the business case, and nobody can immediately say why. The answer is always the same. It is the collection of things around the user line. The engines, which were licensed on their own metrics before and still are. The database, which is now HANA and is a separate line with its own sizing. The optional components that were assumed to be part of the product and are separately licensed. And frequently the Digital Access position, arriving in the same document because the conversion is a convenient moment to settle it. None of that is hidden. It is all in the quote, itemised. The problem is that the organisation only prepared for one line of it. So my advice is procedural rather than clever. Before you request a conversion quote, write down every line you expect to see on it. Users, engines, database, options, indirect. Then compare that list to what arrives. The gap between the two is not a negotiation, it is a scoping failure, and you would much rather find it on your own page than on theirs.
Write down every line you expect to see before you request the quote. That is a ten minute exercise with a very large payoff, and it also tells you what to ask for in advance, because most of those lines need their own preparation. The engine register from session nine. The document count from session thirteen. The database sizing, which is next session. Each of those is a separate piece of work with its own lead time, and discovering you need them when the quote lands is discovering it too late.
So, sizing the number, in five steps. Count today: weighted FUE from cleaned, reclassified role data, which is the starting figure and the only one you can defend. Remove the dead: dormant and duplicate records first, per session eight, and I will come back to that. Project by band, never in aggregate, because Self-Service growth is nearly free at a thirtieth each and Advanced growth is not. Size to the term: the end of term figure rather than today's, which is exactly the same argument as the document tier in session twelve. And state a buffer: a percentage decided in advance and written down, which is better than an unplanned purchase and worse than shelfware, so pick it deliberately. Now, step two deserves emphasis. Every dormant Professional account you carry into a conversion is bought again, at full weight. Session eight's cleanup pays twice: once in ECC and once here, and the second payment is the larger of the two.
Five traps. Translating instead of recounting: old types mapped straight across, importing years of classification drift and repricing all of it at the new weights. Advanced by default: assigning the top band whenever a role is unclear, when unclear should trigger session six's tests rather than the expensive answer. Forgetting the engines: sizing the FUE line beautifully and then being surprised by everything else in the quote, which is the clip we just heard. Sizing to today: buying the current count and buying again in year two, and this course has now described that same mistake in three completely different metrics, which should tell you something about how common it is. And no reallocation process: holding a pool and never rebalancing it, so the one genuine advantage of the model is bought and never used.
Last knowledge check. FUE is a pool. What does that make possible that the old catalog did not? A, buying fewer licences overall. B, reallocating users between bands as roles change, with no purchase. C, avoiding user classification entirely. D, ignoring dormant accounts, since the pool absorbs them. Pause here, and think about what a pool changes operationally rather than commercially.
B. The pool is the real advantage. Under the old catalog, changing somebody's licence type was a commercial event that involved SAP; here it is an internal reallocation, which makes an annual rebalance effectively free. A may follow from good classification and it is not what the pool itself gives you. C is the opposite of the truth, because the weights make classification more valuable rather than less, and I want to be emphatic about that since it is a genuinely common misreading. And D is expensive: a dormant account still consumes its weight, and the pool is finite. Let's hear the argument for actually using the flexibility, because most organisations buy it and then leave it in the box.
Guest analyst clip. There is a habit worth building here and almost nobody builds it, which is a shame because it is close to free money. Under the old named user model, moving somebody from Professional to Limited Professional was a commercial event. It meant a conversation with SAP, possibly a contract change, certainly some friction. So organisations did it rarely, in big painful exercises, usually only when an audit forced them to. That reluctance was rational. Under FUE, the same change is an internal reallocation. You are not buying anything and you are not surrendering anything. You are moving a person from one band to another inside a pool you already own, and the capacity freed up is immediately available for somebody else. Which means the correct cadence is annual, not never. Once a year, take the band assignments, compare them against current roles, and move the people who have changed. Every organisation has drift. People move jobs, projects end, responsibilities narrow, and nobody updates the licence band because under the old model nobody could. In a population of a few thousand, an annual rebalance typically recovers enough capacity to absorb a year of growth without buying anything. That is a day of work producing a purchase you did not have to make, and it is available every single year.
A day of work producing a purchase you did not have to make. So, five things to run an FUE pool properly. Annual rebalance: review every band assignment once a year against current roles and move people, because it costs nothing and it recovers real capacity. Band on joiner, release on leaver: assignment at the point of provisioning and release at the point of exit, inside the same process, so the pool reflects reality without anybody running a project. Track headroom by band: how much of the pool is consumed and how close the Advanced population is to its practical ceiling, because that is the number that triggers a purchase. Keep the engine register: session nine's document, unchanged, because FUE covers users and nothing else and the second axis still drifts on its own. And recalculate before every transaction: any conversation with SAP starts from a current weighted number rather than from last year's figure.
Three sentences. FUE replaces the named user catalog with a weighted pool, Advanced at one, Core at a fifth and Self-Service at a thirtieth, which makes a low activity user genuinely cheap for the first time in this product's history. Recount your population from role data rather than translating old licence types across, because a one for one mapping imports every classification error you already had and reprices all of it at full weight. And FUE covers users and nothing else, so the engines, the database and the optional components around it are what usually surprise people in a conversion quote. Next session is the database, which is the largest of those adjacent lines: SAP HANA licensing, runtime against full use, how memory based sizing works, and the restriction that most customers discover considerably later than they should.
Homework before session eighteen, about an hour, and the first item is the one that matters. One, calculate your FUE today: take your cleaned population, apply the three weights, and write the number down with the working beside it. Two, size the Self-Service band: how many of your users only ever do self service? At a thirtieth each, that count is worth more than most discount conversations you will have. Three, justify the Advanced band: list them, and write one line of reason against each, and the ones you cannot justify are your project for the next month. Four, list what is not FUE: engines, database, optional components, one line each, so that none of them arrives as a surprise inside a quote. And five, project three years by band rather than in aggregate, because the bands grow at different rates and they cost very different amounts per person.
Five guides, all on redresscompliance dot com. FUE licensing explained covers the metric end to end with the optimisation levers set out, and it is the written companion to this whole session. The FUE calculator lets you run slide six's arithmetic against your own population, which is the homework in tool form. The S four HANA licensing guide gives the full on premise picture, users and everything licensed around them, which is slide eleven in detail. S four HANA pricing in twenty twenty six shows where the pricing sits, and I would use it for sizing a budget rather than for reading a quote. And the S four HANA deployment models guide covers on premise, private cloud and public cloud and what each one does to the licence, which is the bridge into module five.
That is session seventeen. The one number to leave with is your own FUE figure, calculated from cleaned data, because everything in module four is priced from it. Next time, the database. See you then.