The user type catalog, the classification rules, and why classification is the whole game. 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 two of forty, and this is the first axis in full: named users. Last session we said that classification, not head count, decides the user bill. Today I am going to prove that, and then show you how to act on it. Here is the shape of the next twenty seven minutes. The catalog of user types and what each one actually buys you. The two vocabularies, classic ECC and S/4HANA, and how they map, which matters enormously the moment anybody says the word conversion. The classification rule itself, which is one sentence long and gets broken constantly. Then the traps, the ones that mean your count is already wrong before you have classified anybody. And finally the process changes that stop all of this creeping back. Three knowledge checks again, and the second one has arithmetic in it, so have something to write on. One thing before we start. Everything in this session is work you can do without asking SAP for anything. No negotiation, no approval, no letter. That makes it the highest return hour in the whole course.
Five things by the end of this session. First, name the types, in both vocabularies, and say what each one permits. Second, apply the rule correctly to any user you are shown, and defend the answer to somebody who disagrees with you. Third, find the waste, which means dormant records, duplicates across systems, and technical accounts that got created as human ones. Fourth, size the prize before you spend anyone's time on it, because a reclassification is a real project and you should know what it is worth before you start. And fifth, keep it clean, which is the part almost everybody skips. I will show you organizations that saved a fortune and then lost most of it back within two years, and the difference was entirely in the joiner and leaver process. None of this is theoretical. By the time you finish tonight's homework you will have your own numbers.
Four ideas, and they frame the whole session. Type. SAP charges for the license type sitting on the user record. Not for what the person does, not for how often they log in. For the type on the record. The record is the invoice. Highest. A user's type has to cover the highest privileged thing they can and do perform. Not the average, not the typical, the highest. One purchasing transaction a month makes somebody a Professional user for the entire year. Default. Professional is the type nobody actually chose. It was the safe option at go live and it propagated, and it is the single most common overspend in the SAP estate. And free. Reclassification, dormant cleanup, deduplication, none of it requires a negotiation with SAP or anybody's approval. It is your work, on your schedule, finished before the measurement rather than argued about after it. That last point is why this session matters more than its position in the course suggests. Before we open the catalog, let's play a clip.
Guest analyst clip. The single most common thing I find, in almost every SAP estate I look at, is that everybody is a Professional user. Not because anyone decided that, but because it was the safe default when the system was set up, and nobody ever went back. I worked with a manufacturer last year, eleven thousand named users, and more than nine thousand of them were classified Professional. When we looked at what those people actually did in the system, about two thousand genuinely needed Professional. The rest were approving a timesheet or looking at a report once a month. Now here is the part that matters commercially. SAP does not charge you for what people do. It charges you for the type on the user record. So the gap between what the record says and what the person actually does is pure overspend, and it has usually been running for years. And nobody notices, because it never appears as a line item called waste. It just sits inside the annual measurement, quietly, as a number everybody assumes is correct.
Two numbers from that worth holding on to. Nine thousand of eleven thousand classified Professional, and about two thousand who genuinely needed it. That ratio is not unusual, it is close to typical, and I want you to notice why it happens. Nobody made a bad decision. Somebody picked a safe default during an implementation fifteen years ago and the system did exactly what it was told, every day since. The second thing she said is the one to write down. It never appears as a line item called waste. There is no report in SAP that tells you that you are overpaying. It shows up as a perfectly ordinary measurement result that everybody assumes is correct, which is precisely why it survives for years. So let's look at what the types actually are.
The catalog. Names and exact rights depend on your price list version and your contract, so read your own paper, but the shape is stable everywhere. Professional. Operational, administrative and management use, effectively unrestricted. The most expensive type, and the default that quietly lands on everybody. Limited Professional. A defined, narrower set of operational tasks. In most price lists that is somewhere between a third and a half of Professional, and it is where the majority of reclassifications land. Employee and self service. Time entry, expenses, leave, payslips, read only reporting. A small fraction of Professional, and this is where your large populations belong, the thousands of people who touch SAP twice a month. Developer. Design and development against the system, priced above Professional, needed by very few people, and routinely left attached to consultants who finished their project two years ago. And technical and special users. RFC accounts, batch users, interface accounts, plus test and information users. These are not human seats. But a technical account that somebody created as a dialog user gets counted exactly as if it were one, and that is a real finding in real audits.
Now the two vocabularies, because you will need both. On the left, what your classic ECC contract calls things. On the right, what S/4HANA and the cloud call the same populations. Full operational users are Professional in ECC, and Professional or Advanced Use in S/4HANA, counted at one full Full Use Equivalent in RISE. Task limited users are Limited Professional, and Functional or Core Use, at zero point two of an FUE. Your self service population is Employee Self Service, and Productivity or Self Service Use, at roughly one thirtieth. Developers stay separate and stay expensive in both worlds. And technical accounts follow the same principle, with the same risk attached. Here is why this table matters more than a translation exercise. Conversion to S/4HANA is where the two vocabularies meet, and your classic classification is the input to that conversion. If nine thousand people are sitting as Professional on the day you convert, you are not converting your reality, you are converting your mistake, and then repricing it. So the order is clean up first, then convert. Never the other way around.
First knowledge check. A warehouse supervisor views reports most days and releases one purchase order a month. What license type do they need? A, Employee Self Service, because that is what they do most of the time. B, Limited Professional, as an average of their activity. C, Professional, because the type must cover the highest privileged activity. D, it depends how many minutes per month they spend in each transaction. Pause here and pick one.
The answer is C, Professional. The rule is the highest privileged activity, not the most frequent one, which rules out A, and not an average, which rules out B, and it has nothing to do with time spent, which rules out D. But now look at what that actually implies, because this is the useful part. If one purchase order a month is what forces this person up to the most expensive type in the catalog, then the cheapest intervention is not to argue about the classification at all. It is to ask whether that supervisor needs the purchasing authorisation, or whether one person in the team could hold it instead. Fix the authorisation and the type falls legitimately. That is the move, and we will come back to it.
So here is the method, in five steps, and the order is the whole defence. Step one, measure. Pull twelve months of transaction history for every user, not a sample and not a single month. You are producing evidence of what people really execute. Step two, map. Map every transaction to the lowest license type that permits it, and let the data propose a type for each user. Step three, review. A human looks at the exceptions and at anybody sitting near a boundary, because the boundary cases are exactly the ones you will be asked about. Step four, fix the roles. Remove the authorisations nobody uses before you change any license type. This is the step people skip and it is the one that makes the saving real rather than optimistic. And step five, apply and record. Change the records, and keep the evidence with your entitlement baseline, because in three years nobody will remember why a thousand people moved down a type. Do it in that order. Let's play a clip on exactly why.
Guest analyst clip. When you reclassify, the question you will be asked, by SAP and sometimes by your own auditors, is very simple. On what basis? So the basis has to exist before you change anything. What we do is build the evidence first. Pull the actual transaction history for every user, twelve months of it, map each transaction to the license type it requires, and let the data propose the classification. Then a human reviews the exceptions. That order matters more than people expect. If you change the license type first and build the justification afterwards, you have a compliance problem dressed up as a saving. If you build the evidence first, you have a defensible position that survives the next measurement, and frankly survives the next three. And the rule underneath all of it is the one people forget. The license type has to cover the highest thing the person does, not the average thing. One purchasing transaction a month makes somebody a Professional user, however light the rest of their usage looks. Get that rule wrong in your own favour and it will come back to you.
On what basis. That is the question, and if you cannot answer it in one sentence per user population, you are not ready to change anything. Notice the sequencing she described, because it is the same five steps on the slide: evidence, mapping, human review, then change. And notice the warning attached. A reclassification done backwards, change first and justify later, is not a saving. It is an exposure with a discount attached, and it surfaces at the worst possible moment, which is during a measurement you did not schedule. The other half of what she said is the rule from our knowledge check, stated the way SAP states it. Highest, not average. Which brings us to the arithmetic.
Second knowledge check, and this one has numbers in it. Five thousand users, all currently Professional, at three thousand each. Your analysis says twelve hundred of them are genuinely Professional, eighteen hundred are Limited at twelve hundred each, and two thousand are self service at two hundred and forty each. What is the reduction on the user line? A, about twelve percent. B, about twenty five percent. C, about fifty eight percent. D, about seventy four percent. Pause and work it out.
The answer is C, about fifty eight percent. Today you are paying five thousand times three thousand, which is fifteen million. Corrected, it is twelve hundred times three thousand, so three point six million, plus eighteen hundred times twelve hundred, which is two point one six million, plus two thousand times two hundred and forty, which is nought point four eight million. Total, six point two four million. So you have taken fifty eight percent off the user line, and you have done it without negotiating a single thing. The exact ratios in your price list will differ from mine, and the mix in your estate will differ too, but the shape of that answer is remarkably consistent. When somebody tells you that user optimization is marginal, this is the arithmetic that says otherwise.
Before you classify anybody though, your count is probably already wrong. Five traps. Dormant users. SAP counts the record, not the person, so leavers keep valid, Professional shaped records for years unless something actively deactivates them. Duplicates. The same human being in ECC, in BW, in SRM, under three different IDs. LAW is meant to consolidate them, but it only matches when the identifying data matches, so a missing email address costs you a license. Technical users. RFC, batch and interface accounts are not seats, but a technical account created as a dialog user is counted as one. Test and training. Sandboxes populated with copies of production users, then measured as though they were production. And expired but unlocked. A validity date in the past is not the same thing as a properly deactivated record, and you need to know exactly what your measurement excludes. Let's play a clip on the first two, because between them they are usually the fastest money in the building.
Guest analyst clip. Dormant users are the easiest money in SAP licensing, and they are also the most neglected. The reason is that SAP counts the user record, not the human being. Somebody leaves the company, HR closes their file, and the user record sits there, still valid, still classified Professional, for years. I have opened systems where fifteen percent of the named users had not logged in for eighteen months. Then there is duplication. The same person exists in ECC, in BW, in SRM, sometimes with three different user IDs because three different projects created them. LAW is supposed to consolidate those, but the deduplication only works if the identifying data actually matches. Different spellings of a name, a missing email address, and the same human being gets counted three times. None of this needs a negotiation. It needs an afternoon with the user list, a leavers report from HR, and consistent data in the fields LAW uses to match people. Do that before the measurement and the number goes down on its own, without anybody from SAP being involved at all.
Fifteen percent with no logon in eighteen months. Ask yourself what that number is in your estate, because you almost certainly do not know it today, and it is in tonight's homework. Two practical things from that clip. The first is that the leaver problem is not really a licensing problem, it is an integration problem. If HR knows somebody has left and SAP does not, no amount of licensing expertise fixes that. The second is the deduplication point, which is genuinely under appreciated. LAW can only count one person once if the fields it matches on are consistent across your systems. Standardising name and email data sounds like housekeeping. It is actually a direct reduction in license count, and it costs nothing but attention.
So what does this look like as a piece of work? Four phases, four to eight weeks in a mid sized estate, and most of that is analysis rather than change. Baseline. Freeze a user list per system, with types, validity dates, last logon, and the identifying fields LAW matches on. Clean. Deactivate leavers, resolve duplicates, correct technical accounts. This phase alone often moves the number by a tenth, and none of it is controversial. Reclassify. Evidence, mapping, exception review, role fixes, then the type changes, in that order. And lock in. Change the joiner and leaver process so the new position actually holds. Notice the sequence once more. You clean before you classify, because otherwise you are paying an analyst to carefully determine the correct license type for people who left the company in twenty twenty three.
Five places the money actually hides, in the order I usually find them. One, the default. Everybody created Professional because it was easiest at go live. Largest single item, every time, in every estate. Two, the leavers. Valid records for people who are gone. Costless to fix and routinely worth a tenth of the user line. Three, the duplicates. One person counted twice or three times because the matching fields were never standardised. Four, the authorisations. Users pushed up a type by a permission nobody uses. Fix the role and the type falls, legitimately and defensibly. And five, the developers. Developer licenses left on consultants and project staff long after the project closed, quietly sitting at the most expensive rate in the catalog. Work that list from the top and you will notice that the first three need no judgement at all. They are just work.
Last knowledge check. You have six weeks before the annual measurement, in a twenty thousand user estate where almost everybody is Professional. What do you do first? A, open a discussion with SAP about a better price per Professional user. B, deactivate leavers and resolve duplicates, then reclassify with evidence. C, reclassify everyone downward and correct anything SAP challenges later. D, submit the measurement as it stands and negotiate the result. Pause here, and think about which action is both fast and defensible.
B. Clean first, then reclassify with evidence. It is fast, it needs nobody's approval, and it shrinks the population you then have to classify. Look at why the others fail. A argues about the rate while leaving the quantity wrong, and the quantity is where the money is. C, the blanket downgrade, is the one I see attempted under time pressure, and it creates an exposure you will pay for with interest, because you cannot answer the on what basis question. And D hands SAP the baseline first, which turns your cleanup from a quiet internal exercise into an argument about why your numbers changed. The order is the strategy. Clean, classify, then submit.
Which leaves the part that decides whether any of this was worth doing. Five process changes. License type is a required field on every new user request, chosen deliberately, never defaulted. Tie the type to the role catalogue, so the role owner owns the cost rather than the service desk. Make leaver deactivation automatic from HR, which is the single highest value integration in SAP licensing and usually one of the cheapest. Standardise the fields LAW matches on, so that one person is counted once. And run a quarterly exception review: new Professionals, new Developers, dormant accounts, one page, four times a year. That is the whole list. None of it is difficult, all of it is boring, and it is the entire difference between a saving and a permanent position. One last clip.
Guest analyst clip. The hard part of user optimization is not doing it. It is making it stay done. I have seen organizations run a beautiful reclassification project, take a genuine seven figure sum off their position, and then find eighteen months later that the number has crept most of the way back. Because the cleanup was a project, and the thing that creates users is a process. So the fix has to live in the process, not in the project. New user requests specify the license type as a required field, not a default. The type is tied to the role, so the role catalogue decides the license, not whoever happens to raise the ticket. Leavers trigger a deactivation automatically, from the HR system, not from somebody remembering. And once a quarter, somebody looks at the exceptions. That is unglamorous work, but it is the difference between saving money once and having a licensing position that stays honest. And when the measurement comes around, you are not preparing anything. You are just reporting what is already true.
A project versus a process. That is the whole point, and it is worth being blunt about it. If you run the cleanup and change nothing about how users get created, you have bought yourself roughly two years. The number will come back, because the mechanism that produced it is still running. And her last line is the one I would put on the wall. When the measurement comes around, you are not preparing anything, you are reporting what is already true. That is what a governed estate feels like, and on the user axis it is achievable faster than anywhere else in this course.
Three sentences. SAP charges for the license type sitting on the user record, so the record, not the person's actual behaviour, is what you are paying for. The type must cover the highest privileged activity a user performs, which means the cheapest reclassification usually starts by removing an authorisation nobody uses. And cleaning and reclassifying needs no negotiation and no permission, but it only stays fixed if the joiner and leaver process changes with it. Next session we cross to the second axis. Packages and engines: the metrics, how each one is measured, and where they drift while nobody is deploying anything.
Homework before session three, about an hour, and this one produces numbers you will use repeatedly. One, split by type. Take the user counts from session one and break them down by license type, per production system. Two, find the dormant. Count the users with no logon in the last six months. You need the number, not the names. Three, check the leaver path. Ask somebody how an SAP user record actually gets deactivated when a person leaves, and who does it. If the answer is vague, you have already found something. Four, look for duplicates. Pick twenty people who work in two systems and check whether their identifying data actually matches. Five, price the gap. Using your own price list ratios, estimate what moving a thousand users down one type would be worth. That last number is the one that gets you the time and the budget to do this properly.
Five guides to go deeper, all on redresscompliance dot com. The named user license types guide is the full catalog in written form. The S/4HANA licensing types piece covers the second vocabulary from slide five. Mapping legacy ERP licenses to S/4HANA user roles is the one to read before any conversion, for exactly the reason we covered. The employee self service guide covers where your large populations belong and what those users may actually do. And the license optimization guide walks through the reclassification project with the governance that keeps it in place. That is session two. Go and get your numbers, and I will see you in session three.