The metrics that track your business, how each one is measured, and where they 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 three, and we cross to the second axis. Sessions one and two were about people: who has access, what type sits on their record, and how much of that is wrong. Today is about everything that is not counted on people. Packages and engines, counted on business volumes. Orders, employees, spend, revenue, documents, cores, memory. Here is why this session has a different character to the last one. Named user waste is static. It sits there, wrong, until somebody fixes it, and when you fix it, it stays fixed. Engine exposure is dynamic. It moves every single day, in the direction of more, because your business is growing, and nobody in your organisation is watching the number. So the discipline is not cleanup, it is tracking. By the end of the next twenty seven minutes you will know what your engines are counted on, who does the counting, how far a normal growth rate pushes you in four years, and what a register looks like that turns all of that from a surprise into a diary entry. Three knowledge checks as usual, and the second one has compounding in it.
Five things by the end. First, read a metric. Take any engine off your order form and say what it is counted on and over what period, which sounds trivial and almost nobody can do it. Second, know who counts. Some engines are measured by a program, some you declare yourself, and those two groups need completely different handling. Third, project the drift. Take a business growth rate and turn it into a licensing requirement three years out, before it turns into a finding. Fourth, build the register. One row per engine: metric, entitlement, consumption, owner. Fifth, time the true up. Because the same capacity costs radically different amounts depending on whether you are buying it or being sold it. That last one is where this session pays for itself.
Four ideas. Business. Engines are counted on business numbers. Orders, employees, spend under management, revenue, documents, cores, memory. Look at that list and notice how little of it anybody in IT controls. Auto. Growth is automatic. Twenty percent more orders is twenty percent more requirement. Nothing was installed, nobody made a decision, no project ran. The number simply moved because the company did well. Quiet. There is no alert for this. Your systems do not warn you when you cross an entitlement, because your systems do not know what your entitlement is. It is a figure in a contract, and the gap builds silently for years and then arrives all at once, in a measurement, priced at list. And declared. A large share of engines cannot be measured by a program at all, so SAP asks you for the number, and whatever you write down becomes the evidence. This is the axis that surprises finance, because nobody bought anything and the compliance position got worse anyway. Let's play a clip.
Guest analyst clip. The conversation I have most often about engines starts the same way. A CFO says, we have not bought any new SAP software in four years, so why has our compliance position got worse? And the answer is that the engine axis does not care what you deployed. It cares what your business did. If you license a module on the number of sales orders, and your order volume went up thirty percent because the business grew, your licensing requirement went up thirty percent as well. Nobody installed anything. Nobody made a decision. The number simply moved. What makes it hard to see is that engines are quiet. A named user shows up in a system that people log into every day. An engine metric is a number in a contract from twenty nineteen that describes a volume, and nobody is watching that volume against the entitlement. There is no alert. There is no dashboard. The gap accumulates for years and then arrives all at once, in a measurement, priced at list. So the discipline here is different from the user axis. With users you are cleaning up something that already exists. With engines you are tracking something that keeps moving. The organisations that handle this well know their volume against their entitlement, per engine, at least once a quarter. Most organisations I meet cannot tell me what a single one of their engines is measured on.
That last line is the one I would test on yourself right now. Can you name what a single one of your engines is measured on? Most people cannot, and it is not a criticism, because the information is genuinely hard to get at. It lives in an order form referencing a price list version, and the definition of the metric lives in that price list, not in the system. Also notice the framing she used. With users you are cleaning up. With engines you are tracking. Those need different governance, different owners, and a different rhythm. Cleanup is a project with an end. Tracking is a habit with a calendar. So let's start with the metrics themselves.
Engine metrics fall into about five families, and once you can place a metric in its family, you know what makes it move. Transaction volume. Orders, deliveries, shipments, invoices, documents. Driven by trading activity, so it tracks the top line, and it is the most volatile family. People. Employees, master records, subscribers. Driven by head count, which means it usually drifts gently and then steps hard, on the day an acquisition closes. Financial. Revenue, spend under management, payment volume. Driven by growth and also by inflation, which is worth pausing on, because it means the number rises even when your actual activity is flat. Technical. Cores, memory, the HANA sizing metrics. This is the only family your Basis team can genuinely influence, and it is also the one where a sizing decision taken for performance reasons has a licensing consequence nobody mentioned in the meeting. And contract scope. Restricted use rights, tied to one application. That is not a volume at all, it is a boundary, and it is quietly the easiest one to cross. Four of those five families move because of decisions taken in operations, finance, or the boardroom. That should tell you where the owner needs to sit.
Some worked examples, so this stops being abstract. Payroll and HR processing is typically counted on master records or employees, so it moves with head count and, again, with acquisitions on the day they close. Transportation and logistics engines are counted on shipments, deliveries or freight orders, so they move with trading volume, and also with how your documents are batched, which is a process decision with a price attached. Procurement and spend tools are counted on spend under management or supplier counts, so they move with growth, with inflation, and every time somebody pulls another spend category into the tool, which everyone treats as an adoption success. The HANA database is counted on memory in gigabytes, so it moves with data growth and with sizing decisions, and it carries the runtime versus full use boundary we will keep coming back to. And digital access is counted on documents created by other systems, which moves with every new interface anyone builds. Now, one warning about this table. Your own price list version defines these precisely, and the definitions matter far more than the names. Two customers with the same engine can be counted differently, because their order forms reference different price list versions.
First knowledge check. Your revenue grows twenty percent. You deploy no new SAP software and you create no new users. What happens to your engine licensing requirement? A, nothing, because entitlement is fixed until you buy something. B, it rises with the metric, for any engine counted on a business volume. C, nothing until the contract renews, when it is recalculated. D, it rises only if you enable additional functionality. Pause here and pick one.
The answer is B. Your entitlement is fixed, and that is precisely the problem, because your requirement is not. A confuses what you bought with what you need, and those two numbers separate the moment the business grows. C is the most expensive misunderstanding on the slide, and I meet it constantly. The requirement grew on the day the volume grew, not at renewal. What happens at renewal is that somebody finally counts, and by then you have been accumulating a gap for four years. And D describes the user axis, where deploying functionality is what changes things. On this axis, the business changes things, and it does not consult you.
So who does the counting? Two categories, and you must treat them differently. Program measured engines. USMM and the engine measurement programs read your system and produce a number. It is your data, read by SAP's code, applying rules you did not write, which is exactly why you run it yourself first and read every line of the output. The risk here is that the program counts more broadly than you assumed, and you find out at the worst moment. Self declared engines. SAP asks you for the figure and you supply it. It comes from your own report, your own query, or somebody's estimate. And the risk is completely different: your number becomes the evidence, and it gets quoted back to you in any later discussion. What good looks like on the left is that you ran it early and understood it. What good looks like on the right is that every declared figure traces to a named report you can rerun in front of somebody. The self declared column is where customers most often overpay, and the reason is human rather than technical. Let's play a clip.
Guest analyst clip. Self declaration is the part of SAP licensing that people underestimate, and I want to be very direct about why. When an engine cannot be measured by a program, SAP asks you to declare the number. Somebody in your organisation types a figure into a form once a year. That figure becomes the official record of your consumption. It is the basis of your compliance position, and if there is ever a dispute, it is your own number being quoted back at you. Now, in most companies, who actually fills that in? Usually somebody in Basis, or a license administrator, who has been asked for a number they have no way of independently verifying. So they use last year's figure, or they ask a business owner, who gives them an estimate. And that estimate becomes evidence. I am not suggesting anybody is being dishonest. Quite the opposite. What I see far more often is customers declaring numbers that are too high, because nobody wanted to under declare and get into trouble. They pay for volume they never processed. So treat the declaration like a filing. Know where the number comes from. Be able to point at the report or the query that produced it. Keep it with your entitlement records. If you can do that, the declaration stops being a risk and becomes one of the very few places in this relationship where you control the narrative completely.
Customers declaring numbers that are too high. Sit with that for a second, because it runs against the instinct. We spend most of this course worrying about under licensing, and on the self declared engines the more common error is the other direction, driven by an entirely rational person protecting themselves. The fix is not to declare lower. The fix is to declare accurately and be able to show your working. That single change protects you in both directions at once, and it costs one afternoon per engine. Which brings us to what a normal growth rate does to a normal entitlement.
Second knowledge check, and this one has compounding in it. An engine is licensed for five hundred thousand orders a year. You bought it four years ago. Order volume has grown nine percent every year since. Where are you now? A, about nine percent over entitlement. B, about twenty four percent over. C, about forty one percent over. D, about sixty five percent over. Pause and do the arithmetic.
The answer is C, about forty one percent over. Nine percent compounded over four years is a factor of one point four one, so five hundred thousand orders becomes about seven hundred and six thousand, against an entitlement that is still five hundred thousand. Now, the arithmetic is not really the point. The point is what the arithmetic describes. Nine percent annual growth is a number any business would be pleased with. It is not a boom. Nobody made a mistake. And it produces a forty one percent compliance gap in four years, with no deployment, no new users, and no decision that anybody would recognise as a licensing decision. That is the whole session in one sum. And if that engine is one of your larger ones, forty one percent of it, priced at list during somebody else's renewal conversation, is a very uncomfortable number.
Five ways this drift happens, and only one of them is the obvious one. Organic growth. The business grows and every volume metric grows with it. Slow, compounding, invisible until somebody counts. Acquisitions. People and volume metrics step overnight, and the licensing question almost never makes it into the integration plan. I have seen a company double its payroll metric on a Monday morning and discover the consequence fourteen months later. Process changes. How documents are batched or split can multiply a chargeable count without changing the underlying business at all. Same orders, same customers, three times the documents. Scope creep. A restricted use right attached to one application quietly starts serving a second one. That is not a volume problem, it is a boundary problem, and it is usually invisible to everyone except the person who built the interface. And inflation. Metrics based on revenue or spend rise with prices, so you can be completely flat in real terms and still drift over your entitlement. Let's play a clip about what happens when all of that meets a renewal.
Guest analyst clip. Here is a pattern worth watching for at renewal, because it is very effective and completely legitimate from SAP's side. You are over your entitlement on an engine. Volumes grew, nobody tracked it, and now there is a gap. SAP arrives with two things at once. A compliance number, priced at list, and a proposal that makes the compliance number go away if you sign something bigger. Usually a cloud commitment, or a conversion, or a broader agreement. That is not a threat. It is a well designed commercial offer, and the reason it works is that the compliance number was calculated at list price, on volume you have already consumed, so it feels like a debt rather than a negotiation. Your defence is arithmetic that you did first. If you know your volume against your entitlement per engine, and you have known it for two years, then you arrive with a position rather than a surprise. You can true up deliberately, at a negotiated rate, at a moment you chose, instead of accepting a settlement structured around your own lack of visibility. And the timing matters enormously. Buying additional engine capacity while you are compliant and unhurried costs a fraction of what the same capacity costs when it is presented to you as remediation. Same volume, same product, completely different price, decided almost entirely by who knew the number first.
It feels like a debt rather than a negotiation. That is exactly right, and it is worth understanding as a mechanism rather than as something unfair. A compliance number is computed at list, on consumption that already happened, so psychologically it sits in a different category from a purchase. You are not deciding whether to buy, you are settling something. And once you are in that frame, the bundled proposal that makes it disappear looks generous. The only defence is sequence. Know the number before they do. Everything else in this session is in service of that one sentence.
So here is the artefact. The engine register, four columns, one row per engine. Column one, the metric. For every engine on every order form: what it is counted on, over what period, and which price list version defines it. That last part matters, because the definition lives in the price list, not in your system. Column two, the entitlement. The quantity you actually bought, taken from the order form itself, not from a summary spreadsheet somebody produced in 2021. Column three, the consumption. What you measured or declared last time, plus where that number came from and who produced it. And column four, the owner. A named person in the business who owns the underlying number and can forecast it. Not an IT contact, not a shared mailbox, a person who knows whether order volume is going up next year. Four columns. Two days of work in most estates, not a project. And if you build nothing else from this entire course, build this, because it is what converts every future engine surprise into a date in your own diary.
Five places engine money hides. One, over declaration. Cautious estimates on the self declared engines. Customers routinely pay for volume they never processed, because a high number felt safer to the person filling in the form. Two, shelved engines. Bought for a project that never went live, still sitting on the order form, still carrying support at twenty two percent, year after year. That one is pure waste and it is often the easiest phone call you will make. Three, the counting rule. Documents split or batched in a way that multiplies the chargeable count. Same business, different number, and it is fixable in the process rather than the contract. Four, runtime versus full use. A database licensed to serve one application quietly serving reporting or a second workload. The most common technical finding there is. And five, unpriced growth. Volume that passed your entitlement three years ago and gets settled at list price in a renewal you did not control. Notice that the first four are things you can fix without asking anyone. Only the fifth requires a negotiation, and it only requires one because the first four were not done.
Last knowledge check. You discover you are forty percent over entitlement on one engine, nine months before your renewal. What is the strongest move? A, wait for the measurement and negotiate the finding when SAP raises it. B, verify the number, then true up deliberately as part of a planned purchase. C, reduce usage below entitlement and say nothing. D, declare the overage immediately and ask SAP for their remediation proposal. Pause here, and think about who controls the timing in each option.
B. Verify, then true up deliberately as part of a planned purchase. Nine months is plenty of time to check your own number, price the capacity, and buy it on your terms. Look at what the others give away. A hands SAP both the timing and the list price, which are the two things you actually control today. C is not available on most metrics, because the consumption already happened, and on any metric it is indefensible. And D is the interesting wrong answer, because it looks like honesty. It is not dishonest to check your own arithmetic before you concede a number. Declaring an overage you have not verified, and then asking the other side to propose the remedy, concedes the framing, the timing, and the price, all in one email. Verify first. Then decide.
Which brings us to governance, and on this axis it is genuinely short. One owner per engine, and that owner sits in the business, not in IT. A quarterly read: consumption against entitlement, per engine, four times a year. Not an audit, not a project, just a number on a page that somebody looks at. Traceable declarations, so every self declared figure points at a report you can rerun in front of a sceptical person. Acquisitions in the loop, meaning any deal that adds people or volume gets a licensing line in the integration plan before completion, not fourteen months afterwards. And buy early, deliberately, because capacity purchased while you are compliant costs a fraction of the identical capacity purchased as remediation. Five things. The first one carries most of the weight. Let's hear why.
Guest analyst clip. If I had to reduce engine governance to one habit, it would be this. Every engine on your order forms gets an owner in the business, not in IT. The reason is that the metric is a business number. Orders, employees, spend, revenue, documents. IT cannot forecast any of those. The person who can tell you that order volume will rise forty percent next year because of an acquisition is sitting in operations, not in the Basis team. So the register looks like this. One row per engine. What it is measured on, what you are entitled to, what you consumed at the last measurement, and who in the business owns that number. Four columns. Most organisations do not have this, and building it is a couple of days of work, not a project. Once it exists, two things change. Growth becomes visible before it becomes a compliance event, so you can buy capacity on your own terms. And the business owner starts making licensing relevant decisions knowingly. I once watched a supply chain director change how documents were batched, purely because somebody finally showed them that the way they were doing it created three times as many chargeable documents for exactly the same volume of business. Nobody had ever told them. It was not their fault. It was simply invisible, and once it stopped being invisible it took a fortnight to fix.
The document batching story is the one to remember, because it shows what visibility actually buys you. That supply chain director was not being wasteful. They were optimising for something sensible and nobody had told them there was a meter attached. Three times the chargeable documents for the same business, fixed in a fortnight, once somebody made it visible. You will find at least one of those in your own estate, and you will only find it by building the register and then showing it to the people who own the underlying numbers. That is the difference between licensing as a compliance function and licensing as something that actually changes decisions.
Three sentences. Engines are counted on business volumes, so your requirement grows when the business grows, with nothing deployed and no decision taken by anyone in IT. Many engines are self declared, which makes your own number the evidence, and makes a cautious estimate a permanently expensive habit. And the register of metric, entitlement, consumption and owner is the artefact that converts every future engine surprise into a date that you chose. Next session we go to the paper properly. The SAP contract stack: the agreement, the price list and why its version matters, the use rights, the order forms, and the true up clause that decides how all of today's arithmetic actually gets settled.
Homework before session four, about an hour. One, list the engines. Every package and engine line on your three largest order forms. Names only at this stage, no analysis. Two, find the metrics. For each one, what is it counted on and over what period. And if nobody knows, write down that nobody knows, because that is the actual finding. Three, split the list. Mark which engines are program measured and which are self declared. That second column is your risk list and it is where you will spend your time. Four, trace one declaration. Pick a single self declared engine and find out exactly where last year's number came from and who produced it. Just one. It is usually an instructive hour. And five, get one growth rate. For your largest volume metric, ask the business what it has done over the last three years, compound it, and compare that to your entitlement. That last number is the one that will get you a meeting with your CFO.
Five guides, all on redresscompliance dot com. Managing SAP package and engine licenses is this session in written form, with the metric families and the optimization levers. The compliance best practices piece for engines and packages covers the governance from slide sixteen in detail. The EAM and industry engine licensing guide goes into the industry specific engines, which is where metric definitions get least standard and most expensive. The HANA runtime versus full use guide covers the technical family and the boundary that produces the most common finding in this whole area. And bundling SAP modules for licensing discounts is about how engine purchases get structured commercially when you are buying deliberately rather than under remediation, which is exactly the position this session is trying to put you in. That is session three. See you in session four, where we finally read the contract.