PVU, VPC, RVU, UVU, Authorized User, Concurrent, Floating, Install and MAPC. 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 today is the metric catalog. This is the vocabulary session, and I want to be honest about why it matters: almost every expensive IBM outcome I have seen began with somebody not knowing which variable their licence quantity was attached to. Nine metrics cover nearly everything in a normal estate. We will go through them, spend proper time on the two capacity metrics because that is where the money is, deal with the user metrics and the way they quietly inflate, and finish with a table you can build in an afternoon that changes how the whole discipline works. Three knowledge checks. Let's begin.
Five objectives. First, name every metric you are likely to meet, because nine of them account for almost every product in a normal estate. Second, tell capacity metrics from user metrics, and know which variable each one follows, since that is what makes the number move. Third, use the value unit table, and understand why a core is not simply a core. Fourth, separate processor value units from virtual processor cores, which are two generations of the same idea running side by side in your estate right now. And fifth, build the metric inventory, which is one table with four columns, and the fourth column is the one almost nobody fills in.
So, why does the metric decide the money? Four things. It compounds, because a capacity metric grows with infrastructure, so the same deployment costs more each year without anybody making a decision. It is chosen once, since the metric is genuinely negotiable at purchase and essentially unavailable to change afterwards. It sets the owner, because whoever controls the variable your metric follows is the person who can move your licence position. And it sets the risk, since capacity metrics carry the audit exposure while user and install metrics are countable and defensible. Let me put that in the sharpest form I can.
Guest analyst clip.
Available to you at purchase, and essentially unavailable afterwards. That asymmetry is the reason this session sits in module one rather than in the negotiation module at the end. By the time you are negotiating a renewal, the metric question has usually already been answered, years ago, by somebody who was not thinking about it.
Right, the catalog. Nine metrics. Processor value units, counting value units per core by processor family, following infrastructure. Virtual processor cores, counting the virtual cores available to the workload, also following infrastructure. Resource value units, counting units of whatever the product manages, so following the managed estate. User value units, banded by user population, following headcount. Authorized users, counting unique people given access whether they use it or not, following identity administration. Concurrent users and floating users, counting people or sessions at the same moment, so following peak demand. Install, counting copies or servers or devices, following deployment. And millions of authorizations per compute unit, following transaction volume. Internalise the third column rather than the first: every metric is a bet on a variable, and the interesting question is always who controls it.
First knowledge check. Which question is worth more at purchase? A, what discount can we get on this quantity. B, which metrics is this product available on, and what is the count on each. C, what is the support uplift capped at. D, can we co-term this with our other renewals. Pause here and pick an answer before you continue.
B. The metric governs every year you own the product and it is practically unchangeable afterwards, so it is the only question on that list whose answer compounds in your favour. A is worth asking and it applies to one transaction. C is genuinely valuable, and it protects the annuity rather than the quantity the annuity is charged on, so it comes second to this. And D is good housekeeping that improves your leverage next time rather than your number this time. The order matters: ask B first, then ask the others, because once you have signed on a metric the others are all you have left.
Now the value unit table, and why a core is not a core. IBM publishes a table, and it is the published table that governs: processor family and socket count map to a value unit rating per core. Most current x86 server cores rate at seventy, so a two socket host with eight cores per socket is one thousand one hundred and twenty value units at full capacity. Larger platforms rate higher per core, with Power and mainframe class processors carrying higher ratings that reflect the work a core actually does. The rating is per core rather than per socket, which is the part that catches people, because a hardware refresh to denser processors can raise your licence quantity with no new deployment at all. So check the table at refresh time. The cheapest moment to discover a rating change is while the purchase order is still a draft.
Which brings us to the two capacity metrics. Processor value units are hardware aware, so the processor family changes the quantity and the same workload costs differently on different silicon. Virtual processor cores are not, so a virtual core is a virtual core, you count what the workload can use, and the chip underneath is irrelevant. The newer portfolio uses virtual cores, particularly the Cloud Paks and the container generation. Most estates run both at once, older middleware on value units and newer platform products on virtual cores. And that means your reporting has to cover both. Let me draw that line properly, because the two look similar and behave differently.
Guest analyst clip.
Two different ways at the same time, and your reporting has to handle both. That is worth checking this week, incidentally. A quarterly report that covers your value unit products beautifully and says nothing about your container estate is not a complete position, and it will not read as one to an auditor.
Second knowledge check. You refresh hardware to newer, denser processors. Same workloads, same software. What happens to a product licensed by processor value units? A, nothing, the deployment did not change. B, the quantity falls, since fewer machines are needed. C, the quantity can change, because the rating per core can differ. D, it converts automatically to virtual processor cores. Pause here before you continue.
C. Value units are a function of the processor, which means the licence quantity is a property of your hardware as much as of the software, and a refresh recalculates it. A is the assumption that turns hardware refreshes into licensing events discovered afterwards, usually by an auditor. B is sometimes true and sometimes exactly backwards, because fewer and denser machines can carry more countable cores than the estate they replaced. And D does not happen, since changing metric is a commercial transaction rather than a technical consequence. The habit to build here is simple: the infrastructure team tells licensing before the purchase order, not after the racking.
Now the user metrics, which look like the safe option and mostly are. Authorized counts access rather than usage, so the number falls when access is removed, and that is a different event from somebody stopping using the product. Concurrent and floating count peaks, meaning simultaneous sessions against a pool, so your number is set by your busiest moment rather than your average. Non-human accounts count too, so service accounts, test identities and integrations that authenticate as people are all authorized users. Leavers are the standard finding, with access that outlives employment sometimes by years. And the fix is free. Let me be specific about how this fails, because it is always the same way.
Guest analyst clip.
Defend them as one entry rather than forty. That last point is worth underlining. Non-human accounts are usually legitimate and usually licensable in a sensible way, but only if somebody can say which ones they are. Unlabelled, they are just forty more authorized users on a list.
Four more worth recognising on sight. Resource value units count what the product manages, so servers, devices, terabytes or endpoints, and the number grows with the estate the tool administers rather than with the tool itself. User value units are banded, pricing a population in tiers, so crossing a band boundary matters far more than adding a person. Install is the simplest thing you can own, a count of copies or servers or devices, easy to audit and easy to defend, which makes it a good outcome when you can get it. And millions of authorizations per compute unit follows transactions, so the number tracks business volume rather than infrastructure or headcount. All four reward the same habit: know the variable, know who owns it, and check it on a schedule rather than at audit.
Five failures. Negotiating price before metric, because a good discount on the wrong metric is a worse outcome than list price on the right one. Hardware refresh with no licensing input, so denser processors, higher ratings, and a quantity change nobody modelled. Authorized user lists that only ever grow, carrying leavers, contractors and service accounts, all counted, all removable in an afternoon. Assuming one estate means one metric, when value units and virtual cores coexist and a report covering only one of them is not a position. And ignoring band boundaries, because on a banded metric the marginal user is free right up until the one that moves you a tier, and that one is not.
Last knowledge check. Which column of a metric inventory is most often missing, and most useful? A, the current count. B, the metric name. C, who owns the variable the metric follows. D, the annual cost. Pause here and pick an answer before you continue.
C. The other three columns describe your position. This one tells you who can change it, and that is what turns licensing from a periodic panic into a handful of ordinary conversations with named people. A is a snapshot, and it is out of date the moment infrastructure moves. B is necessary and it is the easy part. And D is what finance asks for, and it is a consequence of the first three rather than an input. Fill in column four and the person expanding a cluster next month finally understands what their change costs. Let me describe the table properly.
Guest analyst clip.
Named people who now understand what their changes cost. So, the table. One row per IBM product you run, and start with the ten largest by spend, because the tail can wait a week. Column one, the metric, taken from the License Information document rather than from memory or from the order form. Column two, the current count, from the tool where one exists and from the directory for user metrics, and dated. Column three, what it follows: infrastructure, headcount, managed estate or transactions, and one word is enough. Column four, who owns that variable, as a named person. And then go and tell them, because right now they almost certainly do not know that their decisions move your licence position.
Three sentences. Nine metrics cover almost every IBM product you will meet, and the useful way to hold them is not by name but by the variable each one follows, because that variable is what makes your number move between now and your next renewal. Capacity metrics carry the exposure, and they come in two generations that run side by side: value units, where the processor family changes the quantity, and virtual processor cores, where a core is simply a core. And the metric is chosen once and it outlives every discount, so the question to ask at purchase is which metrics the product is available on, while the table to build afterwards names the person who owns the variable each metric follows. Next session, the annuity.
Homework before session four, about an hour, and this one produces something you will use for the rest of the course. One, build the metric inventory: ten rows, four columns, metric, count, what it follows, who owns it. Two, confirm each metric from the License Information document rather than the order form, and note anywhere the two disagree, because that is worth knowing early. Three, pull one authorized user list and count the leavers and the service accounts on it, and I would expect that number to surprise you. Four, ask when the next hardware refresh is, what processors it uses, and whether anybody has looked at the value unit ratings. And five, name the four owners and introduce yourself to them.
Five guides, all on redresscompliance dot com. IBM licensing explained carries the full metric catalog with the estate and the agreements around it, which is the reference version of today. IBM PVU and sub capacity licensing goes into the value unit table, core factors and the counting rules in detail. IBM Cloud Paks and VPC licensing covers the virtual processor core metric and the conversion ratios, which we come back to in module three. IBM Passport Advantage explained is where metrics meet bands, part numbers and renewals. And the IBM licensing assessment page describes what an independent review of an estate covers.
That is session three. The thing to take away is that every metric is a bet on a variable, the variable is usually controlled by somebody who has never been told, and one table with four columns fixes that. Next time, Subscription and Support: the annuity, the uplift, and what dropping support actually costs you. See you then.