Professional, Limited Professional, self service, Developer, and the S/4HANA names. 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 six, and this opens module two. Module one gave you the map: the two axes, the paper, and the measurement. Module two goes back to the first axis and stays there for five sessions, because the user axis is where most organisations have the most money sitting in plain sight. Today is the catalog itself. Every named user type, what it permits, and more usefully where it stops. Session two introduced these names. Today we read them properly. I want to be clear about why that is worth twenty seven minutes of your time, because a list of definitions sounds like the least interesting thing in this entire course. Here is the reason. Every type in that catalog is a price, and the words in its definition are the only thing deciding which price a given person attracts. Nothing else. Not their job title, not their seniority, not how busy they are. Just whether the words fit. So we will go through the four human types, the three tests that place somebody sitting between two of them, the special types that are not ordinary seats, the S/4HANA translation, and the five ways a catalog goes wrong. Three knowledge checks. Let's start.
Five things by the end. First, describe every type, which means saying what each one permits and, the part people skip, where it stops. Second, place a user at the boundary, using three tests that settle it when two types both look plausible and everybody in the room has an opinion. Third, handle the special types: developer, test, information and technical users, and understand why the last group is not a seat at all. Fourth, translate to S/4HANA, mapping a classic catalog onto the newer names and weights without carrying your old mistakes across, which is the expensive version of that exercise. And fifth, own your own catalog. Write the definitions down once, in your language, so that classification stops being a debate and becomes a lookup. That last one is the deliverable of this session, and it takes an afternoon.
Four numbers to set the stakes. Ten times: that is the spread between the cheapest self service type and the most expensive developer type in a typical price list. Same person, same building, ten times the cost depending on which line they sit on. One word: the types are separated by phrases like create, or approve, or only display. A single authorisation moves somebody across the line, and nobody announces it when it happens. Yours: SAP publishes the definitions, and you decide which one each person meets. That is your decision, made with your data, and defended by you. Nobody is going to make it for you, and the one party who might offer is not neutral. And forever: a classification set at go live is still there a decade later, because nothing in the system ever asks whether it is still true. Put those together and here is the frame for the whole session. You are not choosing a job title. You are choosing a price, and the definition is the argument you will have to make for it. Let's play a clip on why this particular list of definitions is worth reading.
Guest analyst clip. I want to explain why I spend so much time on something as dry as a list of user type definitions, because it does not sound like where the money is. Here is the thing. Every one of those types is a price. The definition is just words, but the words are the entire argument about which price a particular human being attracts. And in most estates nobody has ever read them. What happens instead is remarkably consistent. At go live, a template sets everybody to the top type, because that is safe and because the project has forty other things to worry about that week. Nobody revisits it, because nothing in the system ever asks. And ten years later I walk in and eighty percent of the population is sitting at the most expensive type in the catalog, doing work that two rungs down would cover comfortably. Nobody decided that. It is the residue of a decision nobody made. And the reason it survives is that classification looks like an administrative detail rather than a pricing decision, so it never reaches anybody senior enough to care about the number. So when I say read your four definitions side by side, I am not being pedantic. I am saying go and look at the four sentences that are quietly setting your annual user bill, because in my experience it is genuinely the first time anyone in the organisation has actually done it.
The residue of a decision nobody made. That is the honest description of most user catalogs, and it is worth holding on to, because it tells you something about how to fix one. There is no bad actor here and there is nobody to blame. A template did something sensible under deadline pressure in year one, and then a decade of nothing happened. Which means the fix is not an argument with anybody. It is somebody sitting down and reading. So let's read them.
Four human types. Professional: operational, administrative and management use, effectively unrestricted within the licensed software. Notice that it stops nowhere. That is precisely why everything defaults to it, because a type that stops nowhere is never wrong, and it is also why it costs the most. Limited Professional: a defined and narrower set of operational tasks. It stops at administration, configuration and cross functional management work. Typically a third to a half of Professional, and this is the type most reclassifications land on. Employee and self service: your own record and your own transactions. Time, expenses, leave, payslips, plus read only reporting. It stops at anything touching somebody else's data or a business document. A small fraction of Professional, and where the large populations belong. And Developer: design, development and configuration against the system. It stops at nothing technical, which is why it prices above Professional. Now, the exact names and rights come from your own price list version, and I will keep saying that, but the shape is stable across estates and price list generations. Read the four definitions in your own contract side by side once. They are shorter than people expect, and the differences between them are the entire argument.
Most users are obvious. The ones that are not sit between two types, and this is where classification programmes stall, because everybody has an opinion and nobody has a rule. Three tests, in this order. The authorisation test: what can this person execute today, whether or not they have? Rights, not habits. The definitions are written against what a user is permitted to do, so an authorisation nobody has used still counts. Second, the document test: do they create, change or approve a business document, or only view one? Creation and approval are the usual dividing line between the operational types and the self service tier. Third, the scope test: is the data their own, their team's, or the organisation's? Own record work belongs in self service, and work across other people's data is operational by definition. And a tie break, for the small number of cases that survive all three. If two types still fit, which one can you defend in writing in one sentence? If the cheaper type needs a paragraph, you have not yet removed the authorisation that makes it wrong. Run them in that order. Most boundary cases resolve at test one.
First knowledge check. A warehouse supervisor views stock reports all day, and once a month approves a stock write off. Which type applies? A, self service, because viewing reports is almost all of what they do. B, Limited Professional, because approving a business document is operational work. C, Professional, because approval authority is management use. D, it depends on how many write offs they approve in the measurement window. Pause here and pick one.
The answer is B, Limited Professional. The document test decides it: one approval a month is still approval, and it is on somebody else's data, so both the document test and the scope test point the same way. A is the tempting answer because it describes what the person spends their day doing, and the type covers the highest privileged thing they can do, not the most frequent. That distinction is the single most useful sentence in this session. C over reaches, because a defined approval inside one process is not unrestricted management use, and reaching for the top type when you are unsure is exactly the habit that produced the estate we are trying to fix. And D invents a frequency threshold that the definitions do not contain, which is worth flagging because it is precisely the mistake activity based tooling makes when nobody checks its output.
Now the types that are not ordinary seats. Developer: writing or changing code and configuration, priced above Professional, needed by a handful of people, and routinely still attached to consultants who left three years ago. Test user: non production testing only, on defined systems. Cheap, legitimate, and a genuine saving when it is set up deliberately rather than discovered by accident. Information or read only user: reporting and display, nothing else. Useful for large analyst populations, and easy to break by granting a single create authorisation to somebody who asked nicely. Technical and system users: RFC, batch, communication and background accounts. These are not human seats. Configure one as a dialog user and it counts as a person, at a person's price, for as long as nobody notices. And indirect and platform users: people reaching SAP data through another system. Not covered by anything on this slide, which is Digital Access, and it is module three of this course. Let's play a clip on where the money hides in these small lists.
Guest analyst clip. The special types are where I find the fastest money, and it is counterintuitive, because these are small lists. Developer seats, test users, technical accounts. A few dozen records in an estate of thousands. But they are the expensive end of the catalog, and they are almost never reviewed, precisely because they are small enough to be invisible. Developer is the one I would look at this afternoon if I were you. It prices above the top operational type. It is granted during an implementation, to consultants and to internal people on a project, and then the project ends. The consultants leave. The internal people move on. And the seats stay, because removing a developer authorisation requires somebody to be certain it is no longer needed, and nobody wants to be the person who broke a release. So the list only ever grows. Technical accounts are the other one, and that failure is different in character. An interface or a batch account is not a person and should not be counted as one. But if somebody set it up as a dialog user, whether through habit or a copied template, the measurement counts it as a human being and prices it as a human being. And it will keep doing that every year until somebody looks. Both of these are fifteen minute checks. Both are on lists short enough to read in one sitting. Very few organisations have anybody whose job it is to read them.
Nobody wants to be the person who broke a release. That is the real mechanism behind developer seat creep, and it is worth naming, because it tells you how to solve it. It is not a licensing problem, it is a risk asymmetry: the cost of removing an authorisation lands on one identifiable person, and the cost of keeping it is spread across a budget line nobody owns. The fix is to make the review a scheduled event with a named owner rather than a judgement call somebody has to volunteer for. Fifteen minutes a quarter, and the question is not is this safe to remove, it is who still needs this and why. Now, the S/4HANA translation.
Second knowledge check, and this one is deliberately about the boundary of the whole topic. An integration account posts forty thousand sales orders a month into SAP from a web shop. How is it licensed? A, one Professional user, because it can create business documents. B, a technical or system user, because no human logs in with it. C, it is not a named user question at all: it is indirect use and Digital Access. D, one Limited Professional user, because it only does one kind of transaction. Pause here before you continue.
The answer is C. It is not a named user question at all. The account is the pipe, not the licensable thing. What matters is the forty thousand documents, and the people and systems behind them, which is the Digital Access model and which is module three. Now, B is the answer most estates give themselves, and I want to be careful here, because B is not stupid. No human does log in with it. But treating the account as the licensable object is the single most expensive assumption in SAP licensing, because it makes a large exposure invisible: everything looks tidy, one technical user, nothing to see, and the actual liability is sitting in the document count where nobody is looking. A and D both try to price a whole population of external activity as one seat, which no definition anywhere supports. If you take one thing from this check, take this: when the answer to who is using this is not a person, stop applying the user catalog and go and look at the documents.
The two vocabularies, and the weights that make this expensive. Professional becomes Advanced Use, and counts as one full unit. Limited Professional becomes Core Use, at zero point two. Employee Self Service becomes Self Service Use, at roughly one thirtieth. Developer becomes Developer Use, licensed separately and priced above Advanced. And technical and system users are the same principle in the new world as the old one: still not a seat, worth zero, unless somebody configured one as a dialog user, in which case it is worth a great deal more than zero. Look at those weights for a moment, because they are the whole point of this slide. A Professional user is five times a Limited Professional and about thirty times a self service user. Which means conversion rewards a clean catalog and punishes a lazy one, at a ratio you can calculate this afternoon. Five hundred people wrongly sitting at Professional convert to five hundred units instead of a hundred, and you pay that difference every year of the new agreement. Let's play a clip on the timing of this, because the timing is the part people get wrong.
Guest analyst clip. There is a moment when a dirty catalog stops being an annoyance and becomes very expensive, and that moment is conversion. When you move to S/4HANA, and particularly into the subscription world, your user types get translated into a weighted count. The top type weighs a full unit. The middle type weighs about a fifth of that. The self service tier weighs almost nothing at all. Now think about what that does to a population that was never classified properly. Five hundred people sitting at the top type because a template put them there ten years ago convert to five hundred units. Classified honestly, most of them are middle tier, and they would convert to something closer to a hundred. That difference is not a one off. It is baked into the baseline of a multi year subscription, and you pay it every single year of that agreement. And here is the part that catches people. Conversion feels like a technical migration project, so it is run by technical people to a technical timetable, and the licensing work gets scheduled after the cutover, because that is when things calm down. By then the count is set. You have negotiated against your own bad data. So the rule is simple, and the timing is everything. Clean the catalog before you convert, not after. It is the same work either way. Done in the right order it is worth a great deal of money, and done in the wrong order it is worth nothing at all.
The same work either way, worth a great deal in one order and nothing in the other. I would underline that, because it is unusual. Most of the advice in this course is about doing more, or doing better. This one is purely about sequence, and it costs nothing extra. If a conversion is anywhere on your roadmap, even loosely, the catalog cleanup moves to the front of the queue today, ahead of things that look more urgent. And if a conversion is not on your roadmap, do it anyway, because the savings are real in the current world too. They are just smaller and slower, which is a good problem to have.
So where do you spend the hour? Your prices are yours and confidential, and I am not going to guess at them, but the ratios hold across most price lists, and ratios are what you plan with. Professional to Limited: moving one user down one rung typically saves half to two thirds of that seat. This is where reclassification programmes find most of their money, and it is the least glamorous work in the estate. Limited to self service: another large step down, and the reason the self service tier is where big populations belong when the work genuinely is own record only. Developer above Professional: the only rung above the top of the operational ladder, which means ten unnecessary developer seats can cost you more than a hundred unnecessary self service seats. That inversion surprises people every time. And so, where to spend the hour. Sort your population by type and count, and find the largest group sitting at Professional with the thinnest role. That single population is usually worth more than every other cleanup combined, and it is almost never the one people expect before they look.
Five ways a catalog goes wrong, roughly in order of cost. The go live default: everybody set to Professional by a template in year one, never revisited. The largest single item in almost every estate, and the one we have already discussed. Role creep: authorisations added for a project and never removed, quietly promoting people to a type nobody chose for them. Nobody signs anything, and the type moves anyway. The local dialect: two subsidiaries using the same type name for different work, so the same job is priced two different ways inside one company. This one is embarrassing rather than expensive, until somebody outside notices the inconsistency and asks which of the two is correct. The technical seat: an interface or batch account configured as a dialog user, counted as a human being at a human being's price. And the stale definition: a catalog written against a price list version you no longer buy on, so your internal rules and your contract have quietly diverged, which means your careful internal discipline is now enforcing the wrong rules. Notice that four of those five are maintenance failures rather than mistakes. Nobody did anything wrong. Things just moved and nobody was watching.
Last knowledge check. You inherit an estate where four thousand of five thousand users are Professional. What do you do first? A, reclassify the obvious cases immediately, since the direction of travel is clear. B, write the catalog definitions down in your own language and agree them internally. C, ask SAP to confirm which type each population should be. D, wait for the next measurement to show which users are dormant. Pause here, and think about what makes the next thousand decisions cheaper rather than what makes the first one faster.
B. Write the definitions down first. One afternoon spent turning contract language into your own job shaped rules makes every later decision mechanical, consistent and defensible. A is not wrong, it is premature, and that distinction matters because A feels like progress. Without written rules you will make four thousand individual judgements, and a year later nobody will be able to explain any of them, including the people who made them, which means the saving is real and the defence of it is not. C hands the pricing question to your counterparty, and however helpful the answer sounds, it is not neutral advice and it is not binding on them either. And D delays an entire cycle to learn one thing you could check today, and dormancy is a different problem from classification anyway. Both are worth fixing, and neither depends on the other.
So how do you keep a catalog true? Five things. Write your own definitions: the contract definition on the left, your own job shaped rule on the right, one page, approved internally and dated. Classify at the door: the type is chosen when the account is created, from the role, by whoever approves the role, and never by a default. That one change stops the problem at source rather than cleaning it up annually. Review on role change: the type follows the job, so every role change is a classification event, which is the only thing that actually stops role creep. Audit the special types quarterly: developer, test and technical accounts are short lists, so a quarterly read is fifteen minutes and it catches the expensive mistakes. And re-baseline on price list change: when you sign onto a new price list version, re-read the definitions, because that is the moment the words move under you and nobody sends a notification. Let's hear why the first of those five is worth more than the other four together.
Guest analyst clip. If I could persuade an organisation to do one thing out of this whole topic, it would be this, and it takes an afternoon. Write your own definitions down. Not a rewrite of the contract, and not an interpretation you would be embarrassed to show anybody. One page, two columns. On the left, the contract definition exactly as it is written. On the right, what that means in your organisation, in your language, with your job titles and your processes named. A plant supervisor is this type. A finance business partner is that type. Someone who only books their own time and expenses is the self service tier. Approved internally, dated, and kept with the entitlement baseline. Here is why that page changes everything. Without it, every classification is an individual judgement made by whoever happens to be looking, and a year later nobody can explain any of them, including the people who made them. With it, classification becomes mechanical. New joiner arrives, their role maps to a rule, the rule names a type, done. And when SAP asks why a population sits where it sits, you hand over a page rather than assembling an argument under time pressure. It is not sophisticated work. There is nothing clever in it. But it converts an endless series of arguments into a lookup, and in my experience it is the difference between an organisation that reclassifies once as a painful project and one that simply stays correct.
It converts an endless series of arguments into a lookup. That is the sentence to take away, and notice the two columns matter as much as the content. Contract wording on the left keeps you honest and gives you the citation. Your own language on the right is what makes the page usable by somebody in HR or in a plant who is never going to read a price list. Most organisations that attempt this write only the right hand column, and then a year later nobody can trace a rule back to the words it came from, which is exactly the position they were trying to leave.
Three sentences. Every user type is a price, and its definition is the only argument that decides which price a person attracts. Boundaries are settled by authorisations, documents and scope, never by how often somebody happens to exercise a right they hold. And if you write your own definitions once and classify at the door, reclassification stops being a project and becomes a habit. Next session takes the catalog you now understand and turns it into a reclassification programme: matching the licence to the role, with the evidence that makes it stick, and the order of operations that keeps it defensible.
Homework before session seven, about an hour. One, read your four definitions. Find the named user definitions in your own price list version and read them side by side, and note where each one stops. Two, count by type. One table: user type, headcount, and what proportion of the population that is. Most estates have genuinely never seen this on a single page. Three, list the developers. Every developer seat with a named person and a current reason. Anyone missing either is your first saving. Four, find the dialog interfaces. Check whether any interface, batch or RFC account is set up as a dialog user, because each one is a human price for a machine. And five, draft one page. Your own definitions in your own language, next to the contract wording. That page is the deliverable of this session, and everything in module two gets easier once it exists.
Five guides, all on redresscompliance dot com. The S/4HANA licensing types piece is the catalog from slide four in written detail, type by type, with the newer names. The FUE licensing guide covers the weights from slide eleven, and how to calculate a count from a real population rather than a rounded guess. Mapping legacy SAP ERP licences to S/4HANA user roles is the translation exercise, and it is the one to read before a conversion rather than after. The employee self service user licence guide covers the tier where the largest populations belong, and the authorisations that quietly break it. And the named user negotiation guide covers what to do with a clean catalog once you have one, at the next renewal, which is where the work finally turns into a price. That is session six. Next time, reclassification. See you then.