USMM, LAW, and controlling what your submission actually shows. 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 thirty two, and this is the practical half of the audit. Last time we established that the annual measurement is a document you author. Today is how you author it: USMM in each system, LAW to consolidate, and the pre measurement pass that decides most of the number before anybody runs anything. I want to warn you that the most important idea in this session is very simple and almost universally misunderstood, which is what the tool actually reads. Today: the two tools, the corrections that hold, the corrections that do not, and how to read the output. Three knowledge checks. Let's begin.
Five objectives. First, know what the tool reads, because USMM reports the licence type recorded against each account rather than anything about what people did. Second, understand consolidation, since LAW exists so one person counts once and it only works if it can recognise that person across systems. Third, run a pre measurement pass, because the corrections that reduce a declaration are ordinary housekeeping done early and evidenced. Fourth, read the output properly, knowing which figures matter, which are noise, and where the errors habitually hide. And fifth, separate defensible from wishful, because classification follows authorisations, so rare use is a reason to change authorisations rather than labels.
Four things to frame it. A field, not a fact: the contractual user type is something a person typed, often years ago, often in a hurry. Knowable in advance, because you can read your own user master record today and nothing about the November number should be a surprise. Consolidation matters, since one human in five systems should count once and only matching makes that true. And housekeeping is the lever, because leavers, duplicates and stale types move the declaration more than any argument does. Let me be precise about that first point, because it changes how you treat the whole exercise.
Guest analyst clip.
If the figure shocks you in November, the problem was never the tool. That is worth sitting with, because it moves the whole exercise from something that happens to you to something you manage. Now, the tools themselves, starting with the system measurement.
USMM, run in each production system and client in scope, and four things it does. It counts users by type, so every account with a contractual user type totalled by type, and locked and expired accounts follow specific rules worth checking in your own agreement. It measures engines, where price list linked measurement programs read the metric for each engine you hold, and for some you no longer use. It reads assignment, meaning the classification field rather than authorisations and rather than activity, so wrong assignments are counted exactly as entered. And it runs per system, treating development, quality and production separately, which makes scope and client selection a decision you take before you start rather than a detail. The output at this stage is raw and system local. It is not your declaration and it should never be sent as one.
Then LAW, the consolidation, and five points, because this is the step that decides your number. One person counted once: LAW brings the system results together so a human working in five systems is one licensed user at their highest type. Matching is the whole trick, since consolidation depends on recognising the same person across systems, usually by user ID or a defined mapping. Acquisitions break it, because inherited estates arrive with different naming conventions and the tool has no way to know that J dot Smith and SMITHJ are one person. The highest type wins, so a Professional in one system and an Employee in four is a Professional, which is correct and worth understanding rather than resenting. And unconsolidated is expensive, because submitting per system totals without consolidation inflates your declaration for no reason at all.
First knowledge check. One person has accounts in five SAP systems. What should the consolidated measurement show? A, five users, one per system. B, one user at their highest type, provided the consolidation can match the identity. C, one user at their lowest type. D, it depends how often they log into each system. Pause here and pick an answer before you continue.
B. Counting one human once is the entire purpose of consolidation, and the highest type applies because the licence covers what the person is entitled to do anywhere in the estate. Now, the condition in that sentence carries the money. If the user IDs do not match across systems, the tool sees five separate people and counts five, which is answer A happening by accident rather than by rule. C would be convenient and is not how it works. And D is the usage assumption again, and by now you know that entitlement is the meter. Check the matching before you check anything else.
So, the pre measurement pass, five things. Archive the leavers, meaning terminated employees whose accounts still carry a licence type, which is the cheapest correction in SAP licensing and the most often skipped. Resolve duplicate identities, so the same human under different user IDs, fixed before the run rather than explained afterwards. Review classifications against roles, because where authorisations changed and the licence type did not, you correct it and record why. Check technical accounts, since system, interface and background accounts follow their own contractual rules and you need to know which of yours qualify. And retire dead engine measurements, because modules you decommissioned can still be measured, and a decommissioned engine reporting volume is an easy correction. People often ask me whether this looks bad.
Guest analyst clip.
The honest version and the defensible version are the same version. That is genuinely the case here, and it is worth stating plainly because compliance work attracts a certain amount of nervousness. You are correcting records that were wrong. Do it continuously, date it, and there is no conversation to have.
Second knowledge check. You reclassify three hundred Professional users to Employee because they log in only a few times a year. Is that defensible? A, yes, since they clearly do not need a Professional licence. B, no, because classification follows authorisations rather than frequency of use. C, yes, provided you document the login statistics. D, only if SAP agrees in advance. Pause here before you continue.
B. A user who can perform professional activity is a Professional user whether they do it daily or twice a year, so relabelling on login frequency is a correction that will not survive being questioned. C actually makes the position worse rather than better, because the evidence you carefully documented proves you applied the wrong test. D outsources a decision that is yours to make correctly. And the honest route reaches the same destination: reduce the authorisations to match what the person actually needs, record the change and its date, and the lower classification then follows from a fact rather than from a hope.
Now reading the output. Users by type tells you assigned classifications totalled, and the error is usually leavers, duplicates and types never reviewed. The consolidated total tells you the population after matching, and the error is identity matching failing silently. Engine metrics tell you the volume read for each engine held, and the error is decommissioned engines still reporting. The system list tells you which systems were included, and the error is a production system missed or a sandbox included. And the comparison to entitlement tells you the gap that gets priced, where the error is entitlement records that are themselves out of date. Read that second row again, because it is the one that costs the most and announces itself the least.
Guest analyst clip.
Prove that your headcount in the measurement resembles your headcount in the organisation. That is a five minute check and I would do it before anything else, because if those two numbers are wildly apart then nothing further down the analysis is worth your time until you know why.
Right, what a defensible correction looks like. Five characteristics. It states a fact: this person left on this date, or these authorisations correspond to this type under our contract definitions. It carries a date and an owner, so who made the change, when, and on what basis, because a correction nobody can trace is a correction you cannot use. It follows the contract's own definitions, since your agreement defines the user types and those words, rather than the general market understanding, are the test. It is repeatable, because if the same review next year produces the same answer then the method is sound, and if not it was an opinion. And it happens before submission, since a correction made before you declare is housekeeping while the same correction afterwards is a dispute. Let me be precise about the reclassification case.
Five traps. Running it on the deadline, so no time to review, no time to correct, and every error you inherited becomes a declaration you made. Submitting unconsolidated totals, meaning per system numbers added together, counting the same people repeatedly, for no benefit to anybody. Silent matching failures, where consolidation completes, the total looks plausible, and thousands of people are counted twice. Reclassifying on usage, which is the correction that feels obvious and does not hold. And no evidence trail, so corrections nobody documented, and in two years the reasoning is gone and only the changed number remains.
Last knowledge check. One month before submission. What produces the largest defensible reduction? A, archive terminated users and fix duplicate identities. B, reclassify infrequent users to a cheaper type. C, exclude systems from the measurement scope. D, ask SAP for an extension while you decide. Pause here, and think about which one is a fact rather than an argument.
A. Both of those are facts rather than arguments: the person left, and these two accounts are one human. Nobody can dispute either, they frequently remove more from the declaration than any reclassification would, and they need permission from nobody. B is knowledge check two, still wrong an hour later. C is not a correction but an omission, and omitting a production system that is in scope is the one move in this module that turns a licensing question into a very different sort of conversation, so do not do it. D buys time you do not need for work you could finish this month. Let me close the loop on what evidence for a reclassification actually looks like.
Guest analyst clip.
Reduce the authorisations, document it, and the classification follows honestly. So, five things for running this as a routine. Archive on exit automatically, tying account archiving to the HR leaver process so the correction happens without anybody remembering to make it. Run a dry measurement each quarter, giving you four data points a year so a movement is noticed when it happens rather than in the annual run. Own the identity mapping, meaning one maintained mapping of people to accounts across the estate, reviewed after every integration. Review classifications when roles change, attached to the authorisation change process, which is the only moment when the right answer is obvious. And keep the correction log, every change dated with the reason, because that is the difference between a defence and an assertion.
Three sentences. USMM reads the licence type recorded against each account rather than anything about usage, which means the measurement is an inventory of your own administrative decisions and is entirely knowable before you run it. Consolidation is what makes one person count once, so identity matching across systems is worth checking before anything else, because a silent matching failure inflates the declaration with nobody noticing. And the corrections that survive are facts with dates: the leaver who left, the two accounts that are one human, the authorisations that define the type, all recorded before submission rather than argued after it. Next session takes on the metric behind the largest findings in the market, which is digital access, and how to defend one.
Homework before session thirty three, about two hours. One, count your leavers, meaning accounts with a licence type belonging to people who have left, and multiply by list price, because that is your business case for the archiving rule. Two, compare two headcounts, the consolidated user total against the actual people in your organisation who use SAP, and explain the difference. Three, test the matching, so pick ten people you know work across several systems and confirm the consolidation sees each of them once. Four, list your engines, every engine being measured and whether you still use it, because decommissioned engines still reporting are a quick win. And five, find the correction log, and if corrections were made last year, ask whether anybody can say why, because if not then start the log this week.
Five guides, all on redresscompliance dot com. USMM and LAW in practice covers running both tools properly and reading what they produce, which is the reference version of today. User classification and clean up goes into the corrections that hold and the ones that do not, in far more detail than we managed. The SAP audit process explained is session thirty one's reference and shows where the measurement sits in the wider process. SAP digital access explained is where session thirty three picks up, so the document metric and how it is counted. And SAM tooling for SAP estates covers what tooling adds once the routine exists, which we come to in session thirty five.
That is session thirty two. The thing to take away is that the tool reads your decisions rather than your usage, so check the matching, archive the leavers, and make every correction a dated fact. Next time, defending a digital access finding. See you then.