Matching the licence to the role, and the evidence that makes it stick. 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 seven. Last time we read the catalog: every user type, what it permits, where it stops, and the tests that place somebody sitting between two of them. Today we take that understanding and turn it into a change. Reclassification. Moving real people to the right type, at scale, in a way that survives contact with the next measurement and the one after that. I want to frame this carefully, because the framing is where most programmes go wrong. Changing a licence type on a user record takes about four seconds. That is the whole technical exercise. Which means the difficulty is not in the change, it is in being able to explain the change to somebody two years later who was not there. So this session is mostly about evidence. The four artefacts that make a reclassification defensible, the five step method and why the order is the method, why role redesign is the actual project, what SAP asks and what closes each question, and how to make the whole thing a habit rather than a project you run twice. Three knowledge checks. Let's start.
Five things by the end. First, build the evidence chain: the four artefacts that turn a licence change from an assertion into a position. Second, run the five steps, in order, because the order genuinely is the method here and not a suggestion. Third, fix roles first, which means understanding why you downgrade an authorisation rather than a person, and what specifically happens when a project skips that. Fourth, answer the challenge, which means knowing the four questions SAP asks about a reclassified population and exactly what closes each one. And fifth, choose your cadence: one batch project or a permanent habit, and what each of those costs you over five years. That last one is the difference between saving money once and saving it every year.
Four things to set the frame. Seconds: that is how long it takes to change a user type. Which is precisely why reclassification looks easy, and precisely why so much of it gets reversed. Two years: the usual distance between making the change and being asked about it. Whoever answers will not be whoever decided, and memory is not evidence. Roles: you do not downgrade a person, you remove an authorisation, and the lower type follows from that. If you take nothing else from today, take that sentence. And backwards: a reversed reclassification is genuinely worse than never having done one. You paid the effort, you lost the saving, and you have taught your own organisation that this work does not stick, which means the next person to propose it will not get funded. So the measure to judge a programme by is not how many records it changed. It is what it can prove about them. Let's play a clip on exactly that.
Guest analyst clip. I want to tell you about the most disheartening thing I see in this work, because it is entirely avoidable. An organisation runs a proper reclassification. Real analysis, thousands of users moved down a tier, a saving somebody put in a board pack. Two years later SAP asks a question about that population, and nobody can answer it. The people who did the work have moved on. The analysis lives in a spreadsheet on a laptop that was replaced. Nobody wrote down which definition they were applying or who signed it off. And so the whole thing collapses, not because it was wrong, but because it is unprovable. And here is what makes that so much worse than never having tried. You paid for the effort. You lose the saving. And you have taught the organisation that this work does not stick, which means the next person who proposes it will not get funded. So I would judge a reclassification programme by a different measure than most people use. Not how many records it changed. What it can prove about them, cold, two years later, to somebody who was not there and is not inclined to be generous. If the answer to that is a folder somebody can open, the programme worked. If the answer is that we would have to look into it, it did not, whatever the spreadsheet said at the time.
Unprovable rather than wrong. That is the distinction that matters, and it is worth sitting with for a second, because it changes what you spend your time on. The analysis was correct. The users genuinely belonged at the lower type. And none of that survived, because the thing that survives is not correctness, it is the record of correctness. Which is unfair, and it is also simply how any review works, in licensing or anywhere else. So let's look at what that record has to contain.
Four artefacts, and the chain is only as strong as the weakest one. The activity record: twelve months of transaction history per user, not a sample and not a quarter, showing what the person actually executed, with a date on the observation. The authorisation record: what the person could execute, before and after. This is the artefact people forget, and it is the one that decides the argument, so I will keep coming back to it. The decision note: one line per population saying why this type, under which definition, approved by whom, on what date. Short is genuinely fine here. Absent is not. And the role change ticket: proof from the system that manages roles that the authorisation actually went away. Without that one, the other three describe an intention rather than a change. Notice the shape of the set. Two artefacts are data, one is a decision, and one proves the decision was carried out. A challenge attacks whichever of those is missing, which is a useful thing to know in advance, because it tells you where to spend the effort.
Five steps, and each one has to produce something before the next begins. Step one, measure: twelve months of transaction history per user across every production system, producing dated, repeatable evidence of what people really execute. Step two, map: every transaction mapped to the lowest type that permits it, producing a proposed type per user that came from data rather than from anybody's opinion. Step three, review: a human reads every exception and everybody near a boundary, producing decisions somebody can explain in one sentence in a meeting. Step four, fix the roles: remove the authorisations nobody uses, through the normal role process, producing a lower type that is genuinely correct rather than optimistic. And step five, apply and record: change the user records, file the four artefacts with the entitlement baseline, and you have a position rather than an edit. The order is the method. Step four before step five is the whole difference between a saving and an exposure, and step four is also the step under the most schedule pressure, which is not a coincidence.
First knowledge check. Activity analysis shows twelve hundred Professional users executed nothing above self service level all year. What do you change first? A, the licence type on all twelve hundred records, then review the exceptions. B, the roles, removing the unused authorisations, then the licence types. C, nothing yet: ask SAP whether the downgrade would be accepted. D, the licence type for the clearest three hundred, as a pilot. Pause here and pick one.
The answer is B, the roles first. The type has to cover what a user can do, not what they happened to do, and until the authorisation is gone those twelve hundred people still hold Professional rights. A lower type is simply wrong, however quiet the year was. A creates twelve hundred exposures in an afternoon, and it will look like progress in a status report, which is what makes it dangerous. D is the interesting wrong answer, because piloting is usually good practice. Here it just creates three hundred of the same exposure and calls it prudence. The problem with A is not the volume, it is the sequence, so doing less of it in the wrong order does not help. And C invites your counterparty to price your estate. Their answer is not neutral and it binds nobody, including them.
So, roles. Five things worth knowing before you start. You cannot downgrade a person: you remove an authorisation, and the licence type is a consequence of that removal, never a substitute for it. Composite roles hide the problem, because one role bundles a dozen others and the expensive authorisation is three levels down where nobody has read it in years. Project roles never expire: granted for a go live or a migration, kept indefinitely, because no process was ever built that takes one back. Copy from a colleague is the commonest way an authorisation spreads, and one person's exception becomes a department's baseline in about eighteen months. And the owner is not you. Roles belong to security and to the business, so a licensing team that tries to change them alone will be entirely correct and comprehensively ignored. Let's play a clip on that last point, because it is where good programmes stall.
Guest analyst clip. There is a sentence I repeat until people are tired of hearing it. You do not downgrade a person. You remove an authorisation, and the licence type follows. Everybody nods, and then under schedule pressure the project does it the other way round anyway, because changing a licence type takes seconds and changing a role takes a conversation with the security team and the business. So the type gets changed, the role stays, and what you have created is not a saving. It is an exposure with a date on it, and it will surface at the least convenient moment. Now, I do understand why it happens. Role redesign is genuinely hard. Composite roles bundle a dozen others, and the expensive authorisation is three levels down where nobody has looked in years. Project roles were granted for a go live in 2019 and no process has ever existed to take one back. And somebody copied a colleague's profile once, so an exception quietly became a department's baseline. None of that is a licensing problem. It is an access management problem that happens to have a price tag attached. Which tells you who has to be in the room. A licensing team that tries to redesign roles by itself will be completely correct and comprehensively ignored. Bring security, bring the business owner, and bring the number, because the number is the only part of this conversation that is yours.
The number is the only part of this conversation that is yours. I think that is the most practical sentence in this session. You do not own the roles, you cannot remove an authorisation unilaterally, and you should not want to. What you own is the price, and price is the thing that turns a request nobody wants to refuse into a trade somebody can weigh. Security will not remove an authorisation because licensing asked. A business owner will often give one up when they can see it costs them fourteen thousand a year and nobody in their team has used it since March.
Second knowledge check. You reclassified eight hundred users to a lower type eighteen months ago. SAP asks why. What settles it fastest? A, the activity analysis that showed they did not use the higher functions. B, the role change records showing the authorisations were removed, with the dated decision note. C, the current USMM output, which already shows them at the lower type. D, a statement from the business that these people do not do that work. Pause here before you continue.
The answer is B. The question being asked is whether those users could perform the higher functions, and only the authorisation record answers it. A is necessary supporting evidence and it is not sufficient on its own, because low usage of a right you still hold proves precisely nothing about the right. That is the trap, and it catches careful people, because A feels like the strongest answer and it is the one most likely to be in the folder. C is circular: it restates the change rather than justifying it. Showing an auditor a report that says these users are now cheaper, as evidence that they should be cheaper, is the answer most likely to prolong the conversation. And D is an opinion, offered by people with no visibility of authorisations, about the exact thing that matters here.
So here are the four questions, and what closes each one. On what basis did you downgrade these users? The dated decision note, citing the definition from your price list version. What does not close it is a description of the tool you used, and tooling is what people reach for first. Can they still perform the higher functions? The before and after authorisation record plus the role change ticket. What does not close it is twelve months of quiet activity data, for the reason we just covered. Who approved this? A named approver and a date inside your own governance. What does not close it is the licensing team acting alone, because that reads as a cost exercise rather than a business decision. And has anything changed since? Evidence that the review runs on every role change. What does not close it is silence, which reads as nobody has looked. Let's play a clip on how that conversation actually goes.
Guest analyst clip. Let me describe how a challenge to a reclassified population actually goes, because people imagine something much more adversarial than it usually is. You will be asked four questions. On what basis did you downgrade these users. Can they still perform the higher functions. Who approved it. And has anything changed since. That is generally it. There is no trap in there and no clever cross examination. It is simply somebody checking whether a decision was made properly. Now, here is the asymmetry that matters. If your four artefacts exist, every one of those questions is answered in minutes, from a folder, by somebody who was not involved at the time. If they do not exist, every one is answered with a version of we would need to look into that, and the conversation changes character immediately, because you have just told your counterparty that nobody is in control of this. And I would draw your attention to the second question in particular, because it is the one that catches careful organisations. People bring activity data to it. Twelve months of history showing these users never touched the higher functions. That is good evidence of something, and it is not evidence of what was asked. The question was could they, and only the authorisation record answers that. Bring the wrong artefact to the right question and you look unprepared while holding a perfectly good file.
Unprepared while holding a perfectly good file. That is a very specific failure and I have seen it more than once. The organisation did the work, the folder exists, and the wrong document comes out of it, so the conversation continues for another three weeks. The fix is trivial and almost nobody does it: write the four questions on the front of the pack, with the artefact that answers each one named underneath. Ten minutes of work, done once, and it means the right document is in somebody's hand within a minute of being asked, by whoever happens to be in the room.
Now, the cadence question. One project or a permanent habit. The batch project runs three to six months, has a clear number attached and a visible saving. It is genuinely the right way to clear a decade of accumulation, and it fixes nothing structural. The continuous habit is classification at account creation, review on every role change, and a quarterly exception report. Almost no cost once it is running, and no business case to write, which is also why it rarely gets built. Do both, in order: run the batch to clear the backlog, then hand the habit to the role approval process before the project team disperses. That timing matters, because the window closes fast. And the failure mode is batch only. The estate drifts straight back, and three years later somebody presents the same project to the same people with the same slide. The batch buys the saving once. The habit is what makes it an annuity.
Five ways a reclassification comes undone. Type changed, role untouched: the saving is real for exactly as long as nobody asks the authorisation question, and then it is an exposure with a date on it. Activity evidence only: twelve months of quiet does not remove a right, and this is the most common gap in otherwise careful work. No dated decision: nobody recorded who decided or under which definition, so an entire population becomes unexplainable at once, which is a bad way to discover a gap. Business pushback wins late: somebody loses an authorisation, escalates, it gets quietly restored, and nobody changes the licence type back, so your record now says something that is no longer true. And one and done: the project ends, nothing changes in the joiner and mover process, and the drift restarts the following Monday. Notice that only the first of those is a licensing mistake. The other four are record keeping and process, which is where this whole session keeps landing.
Last knowledge check. Mid project, a business unit refuses to give up authorisations for two hundred users. What is the right response? A, downgrade them anyway, the activity data supports it. B, leave them at the higher type, record why, and put the cost against that business unit. C, escalate to the CIO and have the authorisations removed by mandate. D, exclude them from the programme and say nothing further. Pause here, and think about who should be making this trade.
B. They keep the capability, so they keep the type. That is simply correct, and attaching the cost to the unit that chose it turns an argument about permissions into a budget conversation those managers can actually have and are used to having. A is the exposure this entire session exists to prevent, and it is tempting precisely because the data looks supportive. C sometimes works, and it spends political capital on two hundred users, which is rarely the best use of it. Save the escalation for a population where the money justifies the friction. And D is B without the record, which sounds like a small difference and is not: next year nobody will remember this population was a deliberate decision, so it will read as an oversight, and somebody will spend a week rediscovering what you already knew.
Five things that keep a classification correct once it is correct. Attach it to role approval: whoever approves a role approves the licence type it implies, which is one extra step in a process that already runs rather than a new process to build and staff. Price the request: show the annual cost of an authorisation at the moment somebody asks for it. Report exceptions quarterly: one page listing new high type users and why each one exists, short enough that somebody senior will actually read it. Keep the pack: the four artefacts filed with the entitlement baseline, so the next challenge is a lookup instead of an investigation. And name an owner: one person accountable for the classification being true, because without a name this becomes everybody's concern and nobody's job. Let's hear why the second of those is more powerful than it looks.
Guest analyst clip. I have watched a lot of organisations run this project twice, and the second time is always more awkward than the first, because somebody in the room remembers the first one. So let me be direct about why it happens. The batch project is easy to fund. It has a number attached, a defined end, and a saving somebody can claim. The habit that stops you needing it again has none of those things, so it never gets built, and the estate drifts straight back. Three years later the same slide is presented to the same people. What I would do instead is much less impressive and much more effective. While the project team still exists, attach the classification decision to the role approval process. Whoever approves a role approves the licence type it implies. That is one extra step in a process that already runs every day, owned by people who already own it, and it costs essentially nothing once it is in place. Then add one thing on top: show the annual cost at the moment somebody requests an authorisation. Not a policy, not a refusal, just the number, visible at the point of the request. You will be surprised how many requests get withdrawn by the person who made them. Nobody argues with a price tag the way they argue with a licensing team, and a request that never happens is the cheapest saving available to you.
A request that never happens is the cheapest saving available to you. And notice the mechanism, because it is not really about money. It is about who is doing the refusing. When licensing declines a request, licensing is the obstacle and the requester escalates. When the requester sees the price and withdraws it themselves, nobody has been refused anything and there is nothing to escalate. Same outcome, no friction, no political cost. That is worth more over five years than any single batch project, and it is a change to a form.
Three sentences. The licence type follows the authorisation, so the role change is the work and the type change is just the paperwork that records it. A reclassification is worth exactly what you can prove about it, and four artefacts prove it: activity, authorisations, a dated decision, and the role change itself. And the batch project buys the saving once, while only a change to the role approval process turns it into something you keep. Next session goes after the cheapest money in the estate: dormant accounts, duplicates, and people who exist in several systems at once. No negotiation, no reclassification argument, just records that should not be counted.
Homework before session eight, about an hour. One, pick one population. One department, one plant, one job family. Twelve months of activity against current authorisations. Do not attempt the whole estate, because you will not finish and you will learn less. Two, find the composite roles in that population and check what the expensive authorisation inside each one actually is. Three, ask who owns roles. Name the person or team who approves a role change. If nobody can name them, that is your finding, and it outranks everything else on this list. Four, test the four artefacts: take one historic reclassification and try to produce all four. Whatever you cannot find is your gap, and you have just learned it cheaply. And five, draft one decision note. One line: this population, this type, this definition, this approver, this date. That single sentence is the template for everything that follows.
Five guides, all on redresscompliance dot com. The licence optimization guide covers the reclassification programme end to end, with the savings arithmetic on both axes. Mapping legacy SAP ERP licences to S/4HANA user roles is the role to licence mapping in written detail, which is the mechanics behind slide five. The named user licence types guide covers the types you are reclassifying into, and the definitions your decision note has to cite. The compliance best practices piece for cloud and hybrid estates deals with keeping a classification true when your users span on premise and cloud systems, which is where this gets genuinely harder. And establishing an internal compliance program is where the ownership from slide sixteen lives, and how the quarterly exception report gets governed. That is session seven. Next time, dormant and duplicate users. See you then.