USMM, LAW and SLAW, the self declaration engines, and the STAR classifier. 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 five, and this closes module one. We have covered the two axes, named users and engines, and we have covered the paper that turns a count into an obligation. Today we deal with the mechanism that connects them, which is the measurement. How SAP counts you, what the tools can and cannot see, and how you count yourself first. I want to set the frame properly, because almost everybody gets this wrong in the same way. The annual measurement looks like a compliance chore. An email arrives with a deadline, somebody runs the programs, the output gets sent. What actually left the building is the opening number in a commercial negotiation, assembled under time pressure by a person who was probably never told that. So we are going to look at the four tools, the order you run them in, what to look at when you read the output, how a submission should be presented, and the annual rehearsal that changes the whole conversation. Three knowledge checks. Let's start.
Five things by the end. First, name the tools. USMM, LAW, SLAW, STAR, and what each one produces, but more usefully what none of them can tell you. Second, run the sequence, in the right order, with the fixing done between the steps rather than after all of them. Third, read an output, which means looking past the total to the classifications, duplicates and declarations that produced it. Fourth, prepare a submission that is accurate and presented in a way that closes questions rather than inviting them. And fifth, run a rehearsal. Do the entire thing months early, when what you find is still fixable. That last one is the whole session compressed into a diary entry, and if you only act on one thing today, make it that.
Four ideas. Yours. You run the programs, on your data, and you submit the result. SAP receives what you send and works from it. That is a genuinely unusual position in a commercial relationship and most customers do not treat it as the advantage it is. Once. One submission a year sets the baseline that everything else gets argued against, including things nobody has thought about yet. Early. Everything worth fixing takes weeks, because it involves other people and other teams. A month before the deadline you can see the problems perfectly clearly and change none of them, which is the worst place to be. And total. The interesting information is never in the total. It is in the classifications, the duplicates and the declarations sitting underneath it. So here is the reframe for the whole session. The measurement is not the event. The preparation is the event, and the measurement is just the day it becomes visible to somebody else. Let's play a clip on what that looks like in practice.
Guest analyst clip. I want to describe what actually happens when the annual measurement request arrives, because the pattern is remarkably consistent and it is where a lot of value is lost in about a fortnight. An email arrives, usually addressed to somebody fairly junior. It has a deadline in it. The deadline feels short, and it feels non negotiable, and neither of those things is necessarily true. So the organisation goes into compliance mode. Somebody runs the programs, exports what comes out, and sends it, because the deadline is the thing everybody can see and the content is the thing nobody has time to examine. And that is the whole error, right there. What just left the building is not a compliance return. It is the opening number in a commercial negotiation, and it was assembled in four days by a person who was never told that. The organisations that handle this well treat the request the way they would treat a regulatory filing or a set of statutory accounts. Somebody senior reviews it. It gets checked before it goes. And crucially, the work that determines what it says happened months earlier, not in the week the email arrived. If you take one thing from this session, take that. The measurement is not the event. The preparation is the event, and the measurement is just the day it becomes visible.
Addressed to somebody fairly junior, with a deadline that feels non negotiable. Both of those details matter. The seniority point is not a criticism of the person, it is an observation about how organisations route things that look administrative. And the deadline point is worth testing, politely, because deadlines in these requests are frequently more flexible than they appear, particularly if you ask early and give a reason. But notice that neither of those is the real fix. The real fix is that the work happened months ago, which is where we are going to end up at the end of this session. So let's look at the tools themselves.
Four tools, plus one thing that is not a tool at all. USMM is the per system measurement. It classifies users from the licence type on their record and counts what can be counted automatically. Say that back to yourself, because it is the key limitation: it reports what somebody typed in, not what people do. LAW is the consolidation across systems, with deduplication of people who exist in more than one, and it only matches when the identifying data matches. SLAW is the newer consolidation, same purpose, better suited to larger and more distributed estates, and with exactly the same dependency on clean identifying data. STAR is classification support, proposing user types from actual activity. Genuinely useful input, and never a verdict you should accept unexamined, for reasons we will test in a moment. And self declaration, which is not a tool at all. It is the engines no program can measure, where you supply the number and your own figure becomes the evidence. Now notice the pattern across all five. Every one of them reports your own data back to you. Not one of them knows your entitlement. So none of them can tell you whether the number is a problem, and that comparison is entirely yours to make.
Here is the run order, and the important column is the third one, because the fixing happens between the steps. Step one, clean. You do not run anything yet. Leavers, duplicates, technical accounts. You are fixing the population so that you are not about to carefully measure people who left the company. Step two, measure. USMM on each production system, and then fix the classifications that do not match documented activity. Step three, consolidate. LAW or SLAW across systems, and then fix the identifying data, so that one person is matched and counted once. Step four, declare. The self declared engine figures, and then fix any number you cannot trace back to a report you can rerun. Step five, review and submit. The whole pack, read by somebody senior, and at this point there is nothing left to fix, because fixing is over and presentation has begun. Run all five in one week and you have produced a report. Run them across a quarter, fixing between each step, and you have produced a position. Same tools, completely different outcome.
First knowledge check. Your LAW consolidation shows fourteen thousand two hundred users. Your combined USMM results across systems show seventeen thousand eight hundred. What is the most likely explanation? A, something is broken, the numbers should match. B, deduplication worked, and three thousand six hundred records are the same people in more than one system. C, LAW has excluded users it could not classify. D, USMM has double counted dialog users. Pause here and pick one.
The answer is B. Per system totals should exceed the consolidated total, and that gap is your deduplication doing its job. Three thousand six hundred records collapsed into people who already existed somewhere else. But here is the follow up question that actually matters, and it is the reason this check exists. Did it catch everything? If your identifying data is inconsistent across systems, a different spelling, a missing email, then the real overlap is larger than three thousand six hundred, and you are paying for the difference. So the number to be curious about is not the gap you can see, it is the gap you cannot. A misreads the design, since these totals are not supposed to match. And C and D describe genuine failure modes that are worth ruling out, but neither is the first explanation for a difference in that direction.
So you have the output in front of you. Look past the total, at four things. The type distribution. Why are this many users Professional? If the honest answer is that nobody classified them, they defaulted, then you have found session two's problem sitting in front of you with a number attached. The deduplication rate. How many records collapsed into one person? A low rate usually means dirty matching data rather than genuinely few duplicates. Last logon. How many counted users have not logged in for a year? Every one of those is somebody you are paying for who is not there. And the declared engines. Where did each number come from? If nobody can say, that figure is now your evidence regardless, which is an uncomfortable position to be in without noticing. Four questions. You can ask all of them in an hour with the output in front of you, and essentially everything in this course that saves money on either axis starts with somebody actually doing that. Let's play a clip on when to do it.
Guest analyst clip. People ask me how early they should run their own measurement, and my answer is always the same. Early enough that what you find is still fixable. In practice that means a full dry run about a quarter before the request is due, and a lighter check every quarter after that. Here is why the timing matters so much. When you run USMM and LAW yourself, you are not looking for a number. You are looking for the things that are wrong: the classifications that do not match what people do, the leavers still sitting there, the duplicates the deduplication failed to match, the engine somebody declared badly last year and everyone has copied forward ever since. Every one of those is fixable, and every one of them takes weeks rather than days, because it involves other people and other teams. A month before the deadline, none of that is available to you. You can see the problems perfectly clearly and you cannot do anything about any of them, which is genuinely the worst position to be in. So the discipline is unglamorous but simple. Run it when you can still act, not when you can only report. And read the output properly, line by line, because the interesting information is never in the total.
You are not looking for a number, you are looking for the things that are wrong. That is the difference between running a measurement and reading one, and it is why the dry run has to happen when you can still act. Notice she also mentioned the engine somebody declared badly last year that everyone has copied forward. That is a specific and very common failure, and it compounds, because each year of repetition makes the figure look more established. If you find one of those, fixing it is slightly awkward and entirely worth doing, because the alternative is that it hardens into precedent. Now, on to the arithmetic of a proposal.
Second knowledge check. STAR proposes downgrading nine hundred users based on their actual transaction activity. What do you do with that? A, apply it, since it is SAP's own tool and therefore defensible. B, ignore it, since only your own analysis counts. C, treat it as input, verify against authorisations and roles, then decide. D, apply it only to users below a certain activity threshold. Pause here before you continue.
The answer is C. Treat it as input, verify, then decide. Here is why this one is subtle. Activity based proposals miss the rule from session two: the type must cover the highest privileged thing a user can and does perform, and a quiet quarter does not remove an authorisation. Somebody who could raise a purchase order but happened not to, in the window STAR examined, is still a Professional user until you remove the authorisation. A is the tempting wrong answer, because it treats a proposal from SAP's own tool as though it were approval from SAP, and it is not. B discards perfectly good free analysis out of suspicion. And D invents an activity threshold that the licence model simply does not contain. Use STAR to find your candidates, then check the roles, then act. That is also, not coincidentally, exactly the reclassification method from session two.
Five ways a measurement misleads you. It measures records, not people. Leavers, duplicates and test accounts all count as human beings until somebody removes them. It reports intent, not behaviour. The licence type on the record is what somebody typed years ago, and it is not evidence of what that person does today. It cannot see your entitlement. No tool in this session knows what you bought, which means the comparison that actually matters, consumption against entitlement, is one only you can perform. Copied declarations. Last year's engine figure plus a bit, forwarded annually, quietly becoming an unexamined number with years of apparent precedent behind it. And scope silence. Systems excluded from the run are not excluded from your obligation, so you need to know exactly what was measured and what was not. Let's play a clip on what you can legitimately do about all of this at submission time, because there is an important line to draw here.
Guest analyst clip. There is a distinction I want to draw carefully, because people sometimes hear this advice and take it somewhere it should not go. Accuracy is not optional. You submit what is true. What is discretionary is everything around that: when you look, what you fix before you look again, how the submission is presented, and what context goes with it. Those are entirely legitimate and they matter enormously. Let me give you a concrete example. Two customers, same estate, same software, same volumes. The first submits a raw export with no commentary. The second submits the same corrected figures, with a short note explaining that the user population was reclassified in March following a role review, that the engine figure reflects a measurement methodology they can evidence, and that three systems were decommissioned in the period. Both are accurate. But the second one has answered the questions before they were asked, and it reads like an organisation that knows its own position. That changes what happens next. The first submission invites investigation, because it looks like a machine output nobody examined. The second one closes topics. And none of that requires you to shade a single number, which is important, because the moment you do, you have handed away the only real advantage you have, which is credibility.
Accuracy is not optional, and everything around accuracy is discretionary. I want that line to be completely clear, because the advice in this course is consistently to prepare, to time things deliberately, and to present well, and none of that ever extends to the numbers themselves. The reason is not only ethical, although it is that. It is practical. Credibility is the only advantage in this relationship that compounds, and it is the only one you can lose permanently in a single afternoon. Everything else, a bad classification, an overage, a missing document, is recoverable. That is not.
So what does a good submission consist of? Four things. The numbers: true, complete, and traceable, with every figure pointing at something you can rerun in front of a sceptical person. The context: a short note on what changed and why. Reclassifications, decommissioned systems, the methodology behind any declared engine figure. It does not need to be long. Half a page is often enough. The reviewer: somebody senior reads it before it goes, because a submission nobody reviewed reads exactly like a submission nobody reviewed, and that is visible from the other side. And the record: keep the pack, the evidence and the working with your entitlement baseline, so that next year begins from this rather than from scratch. Two customers with identical estates can get very different outcomes from this step. One sends a machine output, which invites investigation. The other sends the same numbers with the obvious questions already answered, which closes topics.
So what does a rehearsal actually turn up? In my experience, five things, in roughly this order of value. One, dormant accounts. Valid records for people long gone. Usually the largest single item and almost always the easiest to resolve. Two, failed deduplication. The same person counted twice because a name or an email does not match across systems. Three, default classifications. Whole populations sitting at Professional because that is what the template did at go live. Four, an unexplained declaration. An engine figure nobody can source, carried forward for years because nobody ever questioned it. And five, scope surprises. A system in the measurement that should have been decommissioned, or one missing that should not be. Notice that none of these are dramatic and none of them require a negotiation. They are a list of small corrections, most of them somebody else's afternoon, and together they are routinely worth more than anything you will win by arguing at a renewal.
Last knowledge check. The measurement request arrives with a four week deadline, and you have done no preparation. What is the best available move? A, run everything immediately and submit early to look cooperative. B, do the fastest high value cleanup, submit accurately on time, and schedule a proper rehearsal for next year. C, request a long extension and start a full optimisation project. D, submit last year's figures while you investigate. Pause here, and think about what is genuinely achievable in four weeks.
B. Do what is achievable, submit accurately and on time, and fix the underlying problem for next year. Leaver removal and obvious duplicate resolution are genuinely doable in four weeks and they are worth real money, so do those. A is interesting because it feels virtuous: submit early, look cooperative. But goodwill is not a currency you can spend here, and you have just locked in an unexamined number a fortnight sooner than you needed to. C usually fails, and asking for a long extension signals disorganisation at precisely the moment you would rather not. And D is inaccurate, which forfeits the credibility we just discussed, in exchange for a delay you could have requested honestly. Accept the constraint this year. Then make absolutely sure it is a constraint you never face again, which brings us to the last slide.
The rehearsal. Five components. A full dry run, annually, months before anything is due, run as though it were real and then read rather than sent. A quarterly light check: user counts by type, dormant totals, consumption against entitlement per engine, on one page. Fix between the steps, because the dry run produces a list of ten to thirty small items and most of them are somebody else's afternoon. Own the calendar, because you know the request is coming, so nothing about the date should ever be a surprise and everything about the content should be settled before it arrives. And keep the pack, filed with the entitlement baseline, so next year starts where this year finished rather than from nothing. That is the habit. It is not sophisticated and it is not expensive. Let's hear why it matters more than anything else in this session.
Guest analyst clip. The single habit that separates the organisations I worry about from the ones I do not is the rehearsal. Once a year, months before anything is due, they run the whole thing as though it were real. Full measurement, consolidation, the engine declarations, the lot. Then they sit down and read it. Not to submit it, just to see it. And what that produces is a list. Usually somewhere between ten and thirty items, most of them small, most of them fixable by somebody who is not in the room. Dormant accounts. A system that should have been decommissioned. An engine declaration nobody can explain. A classification rule that was applied inconsistently between two subsidiaries. None of those are dramatic. Together they are frequently worth more than anything you will win by arguing at a renewal. And the second benefit is harder to quantify but I think it is bigger. When the real request arrives, nothing about it is a surprise. You are not discovering your own estate under time pressure while somebody waits for an answer. You already know what the number is, you already know why, and the conversation you have with SAP is a completely different conversation from the one you would otherwise be having. Same software, same volumes, entirely different posture.
Same software, same volumes, entirely different posture. That is the sentence that closes module one, really, because it is true of everything we have covered. Your estate does not change because you understood it. What changes is whether you are discovering it under time pressure while somebody waits, or reporting something you settled months ago. Sessions one through five have been about getting to the second position. The counting rules, the two axes, the paper, and now the measurement. From here the course goes deeper into each one, and it assumes you have the baseline.
Three sentences. The tools report your own data back to you and not one of them knows your entitlement, so the only comparison that matters is one you have to make yourself. The fixing happens between the steps, which means a measurement run in a single week produces a report and one run across a quarter produces a position. And accuracy is not negotiable while presentation is entirely discretionary, which is the difference between a submission that invites questions and one that closes them. That closes module one. Next session opens module two, and we go back to the user axis in depth: the full user type catalog and the classification decisions that carry the money.
Homework before session six, about an hour. One, find the date. When is your measurement request normally issued, and who receives it? If nobody knows, that is your first finding and it is a significant one. Two, get last year's pack. The actual submission that went to SAP. Read it, and then ask who reviewed it before it left. Three, check the deduplication. Compare your per system totals to the consolidated figure, and the gap is your dedupe rate. Four, trace one number. Pick a single declared engine figure and follow it back to whatever produced it. And five, book the rehearsal. Put a full dry run in the calendar for one quarter before the next request is due. That one diary entry is the point of this entire session, and it is the only item on this list that changes anything permanently.
Five guides, all on redresscompliance dot com. The piece on USMM, LAW, SLAW and STAR is the toolkit from slide four in written detail, with the run order and what each output proves. The audit readiness strategy guide builds the rehearsal habit into a repeatable annual cycle. Establishing an internal compliance program covers who owns the measurement, who reviews it, and how the calendar gets governed, which is the organisational half of this. The audit preparation toolkit has practical checklists for the four weeks before a submission, and for the quarter before that. And the licence optimization guide covers what to actually do with everything a dry run finds, across both axes. That is session five, and that is module one complete. You now have the map, both axes, the paper and the measurement. See you in module two.