The cheapest money in the estate, and the deduplication rate that finds it. 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 eight. The last two sessions were about getting the right licence type onto the right person. Today we deal with something simpler and, in most estates, worth more per hour of effort than anything else in module two. Records that are being counted and should not be. Dormant accounts, duplicates, technical users configured as people, and accounts nobody owns. I want to be honest about the character of this session. It is not strategically interesting. There is no clever argument, no leverage, no negotiation. It is administrative work. And that is precisely why the money is still sitting there, because administrative work with no owner does not get done. So we will cover the four kinds of phantom record and why each needs a different fix, how to read a deduplication rate and what it actually tells you, why matching fails and what to correct, the safe removal procedure, what the whole thing is worth, and how to make sure you never have to do it again. Three knowledge checks. Let's start.
Five things by the end. First, name the four phantoms: dormant, duplicate, technical and orphaned records, and understand why each one needs a different answer even though they look identical in a user list. Second, read a deduplication rate, which means comparing per system totals to the consolidated figure and knowing what a low rate is really telling you. Third, fix the matching data, because the reason LAW and SLAW miss duplicates is almost always mundane and almost always correctable. Fourth, remove an account safely: lock, wait, then delete, with an audit trail, so that nobody loses access to something they genuinely needed. And fifth, keep it clean, by attaching the cleanup to the leaver process so the count stays true without another project in two years.
Four things to frame this. No debate: nobody defends a licence for somebody who left in 2021. There is no business owner to persuade and no authorisation to remove, which makes this unlike every other saving in this course. Five to fifteen percent: that is the share of a typical named user population that turns out to be dormant, duplicated, or not a person at all. It is rarely nothing, and the number usually surprises the people who know the estate best. Weeks: that is how long a proper cleanup takes, and the time goes into waiting periods rather than analysis, so start it before you need the number rather than when somebody asks for it. And invisible: nothing in SAP ever tells you that a user left the company. The record stays valid, and valid records get counted, indefinitely. So this is the first place to look and the last place anybody looks. Let's play a clip on why that is.
Guest analyst clip. Of everything in this course, this is the topic I have the least interesting things to say about, and it is probably where you will find your first money. Let me explain the contradiction. Almost every other saving in SAP licensing requires an argument with somebody. Reclassification means persuading a business owner to give up an authorisation. Engine optimisation means changing how people work. Negotiation means leverage and timing and a lot of preparation. This one requires none of that. Nobody is going to defend a licence for somebody who left the company in 2021. There is no business owner to convince, no authorisation to remove, no negotiation to have. The record simply should not be counted, everybody agrees the moment you show them, and the only work is doing it carefully. And here is why it survives anyway, in organisation after organisation. Nothing in SAP ever tells you that a person left. The record stays perfectly valid. It does not expire, it does not flag itself, it does not appear on anybody's report as a problem. It just sits there being counted, every year, quietly, until somebody deliberately goes looking. So the reason this money is still on the table is not that it is hard. It is that it is nobody's job, and it is not interesting enough for anybody to volunteer.
It is nobody's job, and it is not interesting enough for anybody to volunteer. I would take that seriously as a diagnosis, because it tells you the fix is organisational rather than technical. If you go looking for a smarter report you will not find one. The report is easy. What is missing is a person whose responsibility this is, and a date in the calendar. That is the whole difference between an estate that carries a thousand phantom users and one that does not. So let's look at what is actually in that population.
Four kinds of record, and they look completely identical in a user list. Dormant: a real person who has gone, or a real person who never used the system in the first place. Valid, licensed, counted, and usually the largest group by a wide margin. Duplicate: one human being with accounts in several systems where the consolidation failed to match them, so you pay once per unmatched record rather than once per person. Technical: interface, batch and communication accounts set up as dialog users. Not people, counted as people, at a person's price. And orphaned: accounts nobody owns. A shared login, a contractor from a project that finished, a test account created for a go live and never removed. Those are a real security risk as well as a real cost. Now, the important part. Dormant needs a leaver process. Duplicate needs clean matching data. Technical needs a configuration change. Orphaned needs somebody to make a decision. Four different problems producing one symptom, so separate them before you start or you will apply the wrong fix to three quarters of your list.
Now the deduplication rate, which I think is the single most informative number in a measurement and which almost nobody looks at. Four patterns. Per system totals far above the consolidated figure: deduplication is working and your estate has real overlap, so confirm the matched pairs are genuinely the same people. Per system totals barely above consolidated: that means matching is failing, not that overlap is absent, and you should check the identifying fields before you believe the number. Consolidated total above the per system sum: something is wrong, because that should not be possible, so check your scope and whether a system got counted twice. And the rate falling year on year: either data quality is degrading or new systems arrived unmatched, and you find out by comparing field completeness rather than totals. Notice what all four have in common. The deduplication rate is telling you about your data quality, not about your headcount. It is a diagnostic disguised as a statistic.
First knowledge check. Your per system totals sum to twelve thousand and the consolidated figure is eleven thousand eight hundred and fifty. What is the most likely explanation? A, your estate genuinely has very little overlap between systems. B, matching is failing, and the real overlap is much larger. C, the consolidation excluded users it could not classify. D, the systems were measured at different dates. Pause here and pick one.
The answer is B. A rate of about one percent is not a finding about your people, it is a finding about your data. In any estate with several production systems a meaningful share of users exists in more than one, and finance and procurement staff are frequently in three. A takes the number at face value, which is the mistake this entire session is about, and it is the comfortable answer because it requires nothing of you. C and D are both worth ruling out, and neither produces a pattern this extreme on its own. If you want a rough sanity check, ask yourself how many people in your organisation you personally know who work across more than one SAP system. If that number is more than a handful and your dedupe rate is one percent, the arithmetic is not describing your company.
So why does matching fail? Five reasons, and none of them are sophisticated. The email field is empty, and email is the single most useful matching key there is, missing on a large share of records in most estates, so the match has nothing to work with. The name is spelled differently: an accent dropped in one system, a middle initial in another, a married name never updated in a third. The user ID convention changed, so one system uses the employee number and another uses initials plus a digit, and nothing connects them. A system was out of scope, which means its users were never candidates for matching in the first place. And contractors have no employee record, so nothing anchors them to a person, and every system they touch produces an independent, separately counted human being. Let's play a clip on what to do about that.
Guest analyst clip. When somebody shows me a deduplication rate of one or two percent, they usually present it as good news. Look, our estate has very little overlap. And I have to tell them, gently, that this is not a fact about their people. It is a fact about their data. Think about who works in more than one SAP system. Finance staff are typically in three. Procurement people cross several. Anybody in a shared service centre, anybody supporting multiple regions, anybody who moved teams in the last five years and kept an old account. In any estate with several production systems, real overlap is substantial. So if the consolidation is not finding it, the consolidation cannot see it. And the reasons are almost always mundane. The email field is empty on a large share of records, and email is the single most useful matching key there is. Names are spelled differently: an accent dropped in one system, a middle initial in another, a married name never updated in a third. User ID conventions changed at some point and nothing connects the old scheme to the new. Contractors have no employee record anchoring them to a human being at all. None of that is sophisticated. It is data hygiene. But it is worth saying plainly: fixing the email field on your user master is probably the highest value data quality work available to you, and it will never appear on anybody's roadmap.
It will never appear on anybody's roadmap. That is true, and it is worth understanding why, because the reason is instructive. Data quality work has no visible output. Nobody demos a populated email field. It does not close a ticket queue or light up a dashboard. So it loses every prioritisation conversation it enters, forever, unless somebody attaches a number to it. Which you can: take your current dedupe rate, estimate the rate you would get with complete matching keys, and price the difference. That converts an invisible chore into a line item, and line items get scheduled.
Second knowledge check. You find four hundred accounts with no logon for eighteen months. What is the correct first step? A, delete them, since eighteen months is more than enough evidence. B, lock them, notify the owning managers, then delete after a defined waiting period. C, change them to the cheapest user type and leave them in place. D, leave them until the next measurement to see whether they become active. Pause here before you continue.
The answer is B. Locking stops the count and is instantly reversible, which is exactly the property you want when you are wrong about a handful of the four hundred. And you will be wrong about a handful: the annual process owner, the auditor who logs in each March, the person on long term leave whose record looks identical to a leaver. A is right about the money and wrong about the risk, and one broken year end close will cost you the entire programme, which we will come back to. C keeps paying for people who are not there, just at a discount, and it also leaves an active credential belonging to somebody who has gone, which is a separate problem you have now chosen not to solve. And D delays a full year to learn what a lock teaches you in thirty days.
So here is the procedure, five steps. One, identify: last logon plus HR leaver status where you have it. Two independent signals, because either one alone produces false positives. Two, notify: tell the owning manager, with a date and a way to object. That step converts your risk into their decision, and it surfaces the exceptions before they become incidents. Three, lock the account, do not delete it. The record stops counting immediately and nothing is lost if you are wrong. Four, wait: thirty to ninety days, defined in advance and applied consistently, which is long enough for a quarterly or annual task to surface an objection. And five, delete and record: remove the account, and file what you removed and why, so you can explain the reduction next year rather than being asked about it. Notice where the money arrives. Step three. A locked account does not count, so everything after it is housekeeping. Let's play a clip on why that ordering matters more than it sounds.
Guest analyst clip. There is one rule in this work that I would put above all the others, and it is this. Lock, do not delete. Wait, then delete. The reason is not caution for its own sake. It is that a locked account stops being counted immediately, so you get the entire saving on day one, and you can undo it in about four seconds if you turn out to be wrong. Deletion gives you exactly the same money and no way back. And you will be wrong about some of them. Not many, but some, and they are always the same characters. The person who runs one process at year end and logs in every January. The internal auditor who appears for two weeks in March. Somebody on long term sick leave or parental leave whose account looks identical to a leaver from the outside. The contractor who is genuinely coming back in September. Eighteen months of silence looks conclusive right up until one of those people cannot close the books. And here is the organisational point, which matters more than the technical one. If you break a year end close by deleting the wrong account, that single incident will end your cleanup programme. Not delay it. End it. Nobody will approve the next phase, and the story will be told for years. Lock and wait costs you thirty days and buys you the right to keep going.
Not delay it. End it. That is the right way to think about the risk here, and it is not really a licensing risk at all. It is a credibility risk, and credibility is the thing that lets you do the next four pieces of work. One broken year end close and you will spend two years being the team that broke the year end close. Thirty days of waiting is an absurdly cheap insurance premium against that, and the saving is already in your hands the moment you lock, so the waiting costs you nothing but patience.
What is it worth? Four things to run on your own numbers. Volume: five to fifteen percent of a named user population is commonly dormant or duplicated, so on ten thousand users that is five hundred to fifteen hundred records. Mix: dormant accounts skew expensive, because leavers were disproportionately operational staff sitting at the higher types rather than self service users. That matters, because it means the average value per removed record is above your blended average, not below it. Compounding: every one of these also converts into an FUE at conversion, so the same phantom record costs you twice, once now and once again in the new agreement, for years. And effort: no negotiation, no role redesign, no business case. Mostly a report, a notification, and a waiting period that somebody has to own. This is the highest ratio of money to argument anywhere in this course, and it is also the work that gets deferred most often, because nothing about it is interesting.
Five ways a cleanup goes wrong. Deleting the annual user: the person who runs one process each year end, eighteen months of silence, entirely legitimate, and the one deletion everybody will remember. Locking a technical account: it has no last logon in the human sense, so it looks maximally dormant, and an interface stops overnight. Separate technical accounts out before you start, not during. Merging the wrong two people: two employees with the same common name in different countries, and deduplication by name alone will eventually find them. Cleaning without recording: the count drops by nine hundred and nobody can say exactly why, which turns a genuinely good result into an awkward question at the worst moment. And one pass only: a cleanup with no leaver process behind it rebuilds the same population in about two years, at roughly the same rate, and you will not enjoy proposing it again.
Last knowledge check. Deduplication merges two records into one person. A month later, both accounts are active. What happened? A, somebody unlocked an account that should have stayed locked. B, they are two different people who matched on the same name. C, the consolidation ran before the last measurement date. D, one account is a technical user that resumed a batch job. Pause here, and think about what deduplication actually matches on.
The answer is B. Two active accounts across the same period is the classic signature of a false merge, because one human being rarely works in two systems simultaneously all month. Weak matching keys create these, and a false merge is worse than a missed duplicate, which is the point of this check. A missed duplicate means you are overpaying, which is bad. A false merge means you have understated your count, and that is the one direction of error you genuinely cannot afford, because it turns a cleanup into an underdeclaration. A, C and D are all real events that happen, and none of them explains sustained simultaneous activity across a month. So before you present the improvement, check the merges. Specifically, look for merged pairs where both underlying accounts show activity in the same period, and look hardest at the common surnames.
Five things that stop the population rebuilding. Join the leaver process: HR termination triggers an SAP lock, one integration built once, and the dormant problem largely stops existing. Fix the matching keys: make email mandatory and consistent across systems, which is the highest value data quality work in this entire topic. Separate technical accounts: a naming convention and the correct user type, so they never appear in a human count again. Report dormancy monthly: count of accounts with no logon in ninety days, by department, visible and small, which means it never has to become a project again. And name an owner for orphans: every account has a responsible manager, and an account whose manager has left is itself an exception worth reviewing. Let's hear why the first of those five matters more than the other four together.
Guest analyst clip. I want to end on the thing that makes all of this permanent, because otherwise you will do it again in two years and it will be the same size. Ask one question in your organisation: when HR records a termination, does anything automatically lock that person's SAP account? In most places the honest answer is no. There is a process on paper. It depends on a manager remembering to raise a ticket during the week somebody leaves, which is the week they are busiest and least likely to think about system access. So it happens perhaps half the time, and the other half quietly accumulates, year after year, into the population you just spent three months cleaning up. That single integration, HR termination to SAP lock, is the whole answer. Build it once and the dormant problem largely stops existing. It is not a licensing project, it is an identity management one, and it usually has a security sponsor already, because the compliance argument is even stronger than the cost one. Somebody who left the company should not retain access to your finance system, and everybody agrees with that sentence immediately. So use it. This is the rare case where the cheap argument and the important argument point the same way, and you can let somebody else own the work while you count the saving.
Let somebody else own the work while you count the saving. That is not cynicism, it is good sense, and it generalises well beyond this topic. The leaver integration is genuinely a security control, it genuinely belongs to identity management, and the compliance argument for it is stronger than the licensing one. Your job is to notice that the two arguments point at the same build, and to make sure the licensing benefit is quantified in whoever's business case eventually carries it. You do not need to own everything that saves you money. You need to know which projects already underway will do it for you.
Three sentences. Dormant, duplicate, technical and orphaned records look identical in a user list and need four completely different fixes, so separate them before you begin. The deduplication rate tells you about your matching data rather than your headcount, which means a low rate is a data finding and not good news. And lock, wait, then delete, because locking stops the count immediately and it is the only step you can undo on the day you turn out to be wrong. Next session closes module two by going back to the second axis: engines and packages. Measuring consumption properly, right sizing it, and the metrics that drift while nobody is watching.
Homework before session nine, about an hour. One, calculate your deduplication rate: per system totals against the consolidated figure, one division. If it comes out under five percent, your matching is the finding, not your headcount. Two, count the dormant: accounts with no logon in twelve months, sorted by user type, because the expensive types are the ones to act on first. Three, check the email field: what proportion of your user records carry a valid, consistent email address? That single number predicts your deduplication rate better than anything else. Four, find the dialog interfaces: any technical account set up as a dialog user, because each one is a machine at a human price and the fix is configuration rather than negotiation. And five, ask about the leaver trigger: does HR termination lock the SAP account automatically? If the answer is no, you have just found the reason the dormant population exists at all.
Five guides, all on redresscompliance dot com. The piece on USMM, LAW, SLAW and STAR explains how the consolidation actually matches records, which is the mechanism sitting behind slide eight. The licence optimization guide puts the cleanup in the context of the wider programme, with the arithmetic worked through. Establishing an internal compliance program is where the leaver trigger and the monthly dormancy report get owned and governed, which is the part that makes this permanent. The audit preparation toolkit has checklists for the cleanup work that should happen before a measurement rather than after it. And the audit readiness strategy guide fits the cleanup calendar around the annual rehearsal from session five, so the two habits reinforce each other instead of competing. That is session eight. Next time, engines and packages. See you then.