Measuring consumption, right sizing it, and the metrics that drift. 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 nine, and this is the last of the optimization sessions before we close module two. We have spent three sessions on the user axis: the catalog, reclassification, and the phantom records. Today we go back to the second axis, engines and packages, and we do the same job on it. Measure it honestly, right size it, and stop it drifting. Session three introduced the metric families and the compounding problem. Today is the practical version: how to measure consumption when your own report may be answering a different question, the four levers in the order that costs least, what to do about the engines no program can measure, and the one page register that turns an eventual overage into a date you chose. I want to flag the difference between the axes right at the start, because it explains why this one catches careful organisations. Users grow when you hire. Engines grow when business happens. Three knowledge checks. Let's start.
Five things by the end. First, measure consumption honestly: know what each metric family counts, and know what your own reports can and cannot tell you, which are two different questions. Second, apply the four levers, in the order that costs the least effort per unit saved, because most organisations start with the most expensive one. Third, own the declared numbers: build a method for every self declared engine that you can rerun in front of a sceptic. Fourth, spot the drift, which means recognising the five ways consumption grows without anybody taking a decision. And fifth, run the register: one line per engine, updated quarterly, so that an overage becomes a date you planned for rather than a surprise somebody tells you about.
Four things to frame it. No hiring: an engine can double its consumption in a year without a single new employee, because it counts documents, or orders, or records, not people. Nobody sees it: consumption grows inside a business process, and the person creating that volume has no idea a licence metric is attached to what they are doing. Forty one percent: that is what nine percent annual growth compounds to over four years. Perfectly normal business performance, and an overage nobody planned. And declared: several engines cannot be measured by any program at all, so you supply the number and your method becomes the evidence. Put those together and here is the distinction that matters. The user axis is a headcount problem, and somebody in your organisation already owns headcount. The engine axis is a volume problem, and usually nobody owns it. Let's play a clip on that.
Guest analyst clip. Here is the difference between the two axes, and once you see it you cannot unsee it. Your named user count grows when you hire people. That is visible. Finance forecasts headcount, HR reports on it, and somebody in the building already owns that number. Your engine consumption grows when business happens. More orders, more invoices, more deliveries, more employees on the payroll. Nobody forecasts that against a licence metric, because the people generating the volume have no idea a licence metric is attached to what they are doing. And why would they? A sales manager closing more deals is not thinking about a document counter. So the engine axis moves quietly, in the direction of your own success, and nobody in the process notices. Let me put a number on it, because the number is the part that surprises people. Nine percent annual growth. That is a good year, not a dramatic one. Compound it over four years and you are forty one percent above where you started. Not thirty six, which is what people calculate in their heads by multiplying. Forty one. And at no point in those four years did anybody make a decision that felt like a licensing decision. That is why this axis catches organisations that are watching the other one carefully. They are guarding the door that has a person standing at it.
Growth arriving in the direction of your own success. That is worth holding on to, because it changes the tone of the internal conversation. You are not reporting a failure when you raise this. Nobody did anything wrong, the business performed, and a cost followed it. Which means the ask is not for somebody to stop doing something. It is for the volume to be visible early enough that the cost is a planned purchase rather than a penalty. That framing gets you a much better hearing than arriving with the word compliance. So, how do you measure it?
Five metric families, and for each one the thing your report will not tell you. Volume of records: orders, deliveries, invoices, documents created in the period. What the report will not tell you is whether the same business event got counted more than once. Master data objects: employees, customers, materials, assets held in the system. It will not tell you whether obsolete records are still counted as live, and they usually are. Financial values: revenue, spend or payroll value passing through the process. It will not tell you which currency and which date, both of which move the number, sometimes materially. Capacity and hardware: cores, memory, a sizing figure for the database. It will not tell you whether your non production systems fall inside or outside the metric, which is a question worth settling in writing. And declared only, where no program measures anything, so the report tells you nothing at all and the method is the whole answer. The general rule: read the metric definition in your price list version before you read your own report, because the report answers whatever question it was written to answer, and that may not be the contractual one.
First knowledge check, and it is deliberately arithmetic. An engine is licensed on documents created per year. Your consumption has grown nine percent annually for four years. Where are you? A, about thirty six percent above the original figure. B, about forty one percent above the original figure. C, still inside the entitlement, since growth was gradual. D, impossible to say without the licence value. Pause here and pick one.
The answer is B, about forty one percent. Nine percent compounded four times is one point four one, not one point three six. A is the calculation almost everybody does in their head, multiplying nine by four rather than compounding, and it understates the position by five percentage points every single time. Over a longer horizon the gap gets much worse, which is why this matters beyond being a maths point. C is the belief that actually causes overages: the feeling that gradual growth is somehow gentler than sudden growth. It is not. Crossing a threshold slowly puts you exactly as far over as crossing it quickly. And D is technically true about the money and beside the point, because the question was about direction and size, and you can answer both without knowing what you paid.
Now the self declared engines, where the risk profile is completely different. You supply the number: no program produces it, so whatever you send becomes the record, and the record is what you will be held to. The method is the evidence: a figure with a documented derivation is a position, and the same figure with no derivation is a guess with your signature on it. Last year plus a bit: the most common approach in practice, and it hardens, because each repetition makes the number look more established than the year before. Precision is not accuracy: a number to four decimal places from an unexplained source is worse than a round number you can defend, because it invites a question you cannot answer. And rerunnable or nothing: if you cannot produce the same figure again next year by the same route, you do not have a method. Let's play a clip on this, because it is the part of the engine axis I would fix first.
Guest analyst clip. The self declared engines deserve more attention than they get, because the risk profile is completely different from everything else in licensing. Normally there is a program, it produces a number, and you can argue about what the number means. Here, there is no program. You supply the figure. Which means your method is the evidence, and if you have no method, you have simply signed your name to a guess. Let me describe what I usually find. Somebody produced a number once, years ago, in a hurry, for a submission that was due. Nobody recorded how. The next year, the person who inherited the task took last year's figure and added a bit, because that felt safer than starting from nothing. And that has now happened five times. The number has acquired an air of authority purely through repetition, and not one person in the organisation can tell you where it came from. The uncomfortable part is that it might be too high. People assume an unexamined declaration is understated, but I have seen plenty go the other way, and you have been paying for that difference every year without knowing. So the test I would apply is simple and slightly brutal. Can you produce the same figure again next year, by the same route, in front of somebody sceptical? If yes, you have a method. If no, you have an anecdote with a decimal point in it.
The uncomfortable part is that it might be too high. I want to underline that, because everybody assumes the risk on a declared engine runs one way. It does not. An unexamined number is simply unexamined, and it is as likely to be generous as it is to be short. I have seen organisations discover they had been declaring against a definition far broader than the contract required, for years, and nobody had ever read the wording closely enough to notice. That is money you have already spent and will not get back, which is a strong argument for reading it this quarter rather than next.
Second knowledge check. You are twenty percent over on one engine and the renewal is fourteen months away. What do you do first? A, buy the additional volume now, before the overage grows. B, check whether the consumption is real before buying or disclosing anything. C, tell SAP immediately, to demonstrate good faith. D, wait for the renewal and negotiate it as part of the wider deal. Pause here before you continue.
The answer is B, check that it is real. A meaningful share of apparent overages turn out to be measurement artefacts: test data sitting in a production count, the same business event counted twice by two processes, obsolete master data still counted as live, or a metric read against the wrong price list definition. A buys volume you may not need, at list price, outside any negotiation, which is the worst combination of those three things. C discloses a number you have not verified, and you cannot unsay it, however quickly you discover the error. And D is often exactly right, but only after B: fourteen months of unexamined growth is not a plan, it is a delay. Let's play a clip on what verification actually finds.
Guest analyst clip. When somebody comes to me and says we are twenty percent over on an engine, my first question is never how do we pay for it. My first question is whether the consumption is real, and a surprising proportion of the time it is not. Let me give you the usual suspects. Test data sitting in a production system, generating documents that count. The same business event counted twice, because two processes both create a record for it. Obsolete master data still counted as live, so you are being measured on customers who stopped buying in 2019 and materials nobody has ordered since. And the one people miss most: the metric being read against the wrong definition, because the report was written years ago against a different price list version and nobody re-read the wording when the version changed. Any of those can produce a twenty percent overage that simply does not exist. So before you buy anything, and certainly before you disclose anything, verify. Because both of those doors only open one way. Buy the volume and you have paid list price for something you may not need. Disclose the number and you cannot unsay it, even if you discover next week that a third of it was test data. Verification costs you a fortnight and it is the highest return fortnight in this entire topic.
Both of those doors only open one way. Keep that in mind, because it is what makes the fortnight worth spending. Now, five ways consumption grows with nobody deciding anything. The business grew: more orders, more invoices, more employees. Success, arriving as a licensing exposure that nobody attached to the forecast. A process was automated: what one person used to do in a batch now generates a document per transaction, and the count multiplies overnight with no volume change in the real world at all. A new interface arrived: another system starts pushing records in, and nobody involved in that project ever saw a licence metric. An acquisition landed: new volume on your contract, frequently without anybody recalculating what the contract covers. And master data was never cleaned: obsolete materials, closed customers and former employees still counted, so the metric is measuring your history rather than your activity. Notice that only two of those five are real growth. The other three are artefacts, and artefacts are free to fix.
So, four levers, and the order matters because it is cheapest effort first. One, reduce: clean the master data and stop counting what is not real. Obsolete records, test data in production, duplicated business events. No negotiation, no process change, nobody's permission required. Two, reclassify: check the metric definition against how the volume is actually generated, because some of what you are counting may not meet the definition at all. Three, retire: engines you own and no longer use. They still cost maintenance every year, and nobody cancels them because nobody is looking at the list. Four, renegotiate: buy the headroom you need, at a renewal, on your timing. Now, the point of the ordering. The first three are entirely yours. They cost effort rather than money and they need nobody's agreement. The fourth is the only one that requires the other party, which is exactly why it goes last, and it is exactly where most organisations start.
The register. One line per engine, four columns, fifteen minutes a quarter. Metric: the exact metric, quoted from your price list version, with its date, because definitions change between versions and the wording is part of the number. Entitlement: what you bought, from the order form rather than from memory, because that is the only figure your consumption means anything against. Consumption: this quarter's measured or derived figure, plus a note on how it was produced, because a number without a method is an assertion. And trend and date: the growth rate, and the quarter at which you cross entitlement at that rate. That fourth column is the one people leave out and it is the entire point of the exercise, because it converts a licensing position into a diary entry. Let's hear why that conversion matters so much.
Guest analyst clip. I want to make the case for something that sounds trivially small, because I think it is the highest return fifteen minutes in software asset management. One page. One line per engine. Four columns. The metric, quoted exactly from your price list version. The entitlement, from the order form rather than from anybody's memory. This quarter's consumption, with a note on how it was produced. And the growth rate, with the quarter at which you cross entitlement if nothing changes. That fourth column is the whole point, and it is the one people leave out. Because a consumption figure on its own tells you where you are, which is mildly interesting. A crossing date tells you when you have to act, which is a completely different kind of information. It converts a licensing position into a diary entry, and diary entries get planned around. Think about what that does to a conversation. Without it, you discover an overage during a measurement, under time pressure, and you buy volume at list price outside any negotiation, quickly, because you have no choice. With it, you saw the date eleven months out, you spent three months cleaning master data, the date moved, and whatever was left you bought inside a renewal at a sensible price. Same engine, same growth, same business. Entirely different outcome, and the only difference is a page somebody updates four times a year.
Same engine, same growth, same business, entirely different outcome. That sentence has now appeared in three sessions of this course in slightly different clothes, and I am going to keep repeating it, because it is the through line. Almost nothing in SAP licensing is decided by how much software you use. It is decided by whether you knew your own position before the other party told you what it was. The register is the cheapest possible way of knowing, on the axis where knowing is hardest.
Last knowledge check. Your register shows you crossing entitlement on an engine in eleven months. What is the best use of that information? A, nothing yet, since you are compliant today and the date may move. B, start the reduce and reclassify work now, and time any purchase to a renewal. C, buy the extra volume immediately while the shortfall is small. D, ask SAP for a formal reading of the metric to confirm the projection. Pause here, and think about what the eleven months are actually for.
B. Eleven months of warning is the entire value of the register, and that warning is worth exactly what you do with it and nothing otherwise. The first two levers may move the date on their own, for free, and whatever is left becomes a planned purchase inside a renewal rather than an urgent one outside it. A wastes the warning and arrives at precisely the same problem with none of the time. C pays list price for volume you might have eliminated with a fortnight of master data work. And D is the one I would push back on hardest, because it hands your counterparty a projection of your future growth. That is genuinely useful information to them and there is no reason to give it away, particularly when you are the party who can still change the number.
And when you do have to buy, buy it well. Buy at a renewal: an engine purchase inside a wider deal prices differently from the same purchase made alone in March, and that difference is often large. Buy the trend, not the gap: closing exactly today's shortfall guarantees another one of these conversations in eighteen months, so price the next three years. Fix the metric first: if the definition is ambiguous, settle the wording before you buy volume against it, because buying first removes your reason to discuss it. Ask what else it unlocks: additional volume is frequently the cheapest thing on the table when something larger is being agreed, so it belongs in the bundle rather than in its own invoice. And record the new baseline: the moment it is signed, the register line gets the new entitlement and the new crossing date, otherwise the whole cycle restarts silently and you learn nothing.
The habit. Fifteen minutes a quarter, five things in it. Refresh consumption using the same method every quarter, whatever that method is, because a consistent imperfect method beats a different perfect one each time and it is the only way a trend means anything. Recalculate the crossing date: one line of arithmetic per engine, and it is the only output of this exercise anybody senior will actually read. Note what changed: new interface, new acquisition, automated process, attributed while somebody still remembers the cause, because in six months nobody will. Check the definitions annually, specifically when your price list version changes, because that is the moment the words move under you and nobody sends a notification. And give it to one person, because the register is fifteen minutes for one owner and it is nothing at all for a committee.
Three sentences. Users grow when you hire and engines grow when business happens, which is exactly why the second axis surprises organisations that are watching the first one carefully. Work the levers in order, because reduce, reclassify and retire are entirely yours and only renegotiate needs the other party to agree to anything. And four columns per engine, refreshed quarterly, turns an eventual overage into a date you can plan a purchase around. Next session closes module two. Everything we have measured across the last four sessions, the users, the classifications, the phantom records and the engines, gets turned into one thing: the entitlement baseline. Your own position, written down, which is what every negotiation in the second half of this course is argued from.
Homework before session ten, about an hour. One, list your engines: every package and engine on the order form. Most people are surprised by at least one entry they had completely forgotten they own. Two, pick the three biggest by licence value, not by how interesting they are, and do the register for those three only. Three, find one metric definition and quote it exactly from your price list version with the date, then compare it to what your report actually counts. Those two things are often not the same. Four, trace one declared figure: pick a self declared engine and follow the number back to whatever produced it. If nobody can source it, that is this session's finding and it is a significant one. And five, calculate one crossing date. Entitlement, consumption, growth rate, and the quarter you cross. That single date is the entire point of the register.
Five guides, all on redresscompliance dot com. Managing SAP package and engine licences covers the metric families from slide four in written detail, with the cost optimization arithmetic worked through. The compliance best practices piece for engines and packages is about keeping an engine position defensible between measurements, which is the register habit in prose. The EAM and industry engine guide is a worked example of an industry engine, where the metric sits furthest from anything intuitive and the definition work matters most. The HANA database licensing guide covers the capacity family, runtime against full use and memory based sizing, which behaves differently from everything else here. And bundling SAP modules for licensing discounts is what to do when you reach the fourth lever and buying headroom genuinely is the right answer.
That is session nine, and that is the optimization work complete on both axes. You now know how to find the money on the user side and on the engine side, and how to keep it found. Next time we take all of it and build the entitlement baseline, which closes module two and sets up everything that follows. See you then.