Passport Advantage reports, bundled and restricted use entitlements, and what the portal does not tell you. 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 IBM 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 module one closes here with the document that everything after it depends on. The entitlement baseline. Every remaining session in this course, the sub capacity regime, the container estate, the mainframe, and the audit, quietly assumes you know two numbers: what you own and what you run. And the uncomfortable finding is that most estates know neither precisely, and quite a few believe they know one of them when what they actually hold is a purchase record. So today is about building the thing properly, including the parts no report will hand you. Three knowledge checks. Let's begin.
Five objectives. First, pull the right reports, because Passport Advantage tells you what you bought, which is one half of a baseline and the half most people mistake for the whole thing. Second, name what the portal cannot see, and specifically that it has no view of what you deployed, which is the number an audit is actually built on. Third, read a bundled entitlement, because a Cloud Pak bundles entitled programs at published ratios, and the flexibility is genuinely real while the assumption that a bundle is automatically cheaper is not. Fourth, respect restricted use, because an entitlement supplied with another product is licensed for use with that product, and deploying it standalone is a finding waiting to happen. And fifth, rebaseline before any discount conversation, because a discount applied to a clean footprint beats a deeper discount applied to a number you should never have been paying.
Four framings. Six of ten, which is the share of estates where the larger number was not the discount at all, it was the shelfware and the full capacity exposure from ILMT gaps. Two directions, because a baseline finds waste and exposure at the same time, since entitled above deployed and deployed above entitled are both live in most estates simultaneously. What you bought, which is all the portal can tell you, authoritative on entitlement and completely silent on deployment. And before the ELA, because an enterprise agreement negotiated on a bloated baseline simply locks in a discounted version of overspend, for years rather than for one renewal. The note underneath is the whole argument for doing this first, and I would quote it directly. Discount applied to a clean footprint beats a deeper discount applied to a number you should never have been paying.
Guest analyst clip. There is a specific meeting I have sat in more times than I can count, and it always has the same shape. Somebody from procurement brings a Passport Advantage export to the table. It is a real document, it came from IBM's own system, it lists part numbers and quantities, and everyone in the room treats it as the licence position. And it is not the licence position. It is the purchase history. Those are different things, and the difference is the entire subject of an audit. Because what IBM will eventually ask is not what did you buy, it is what are you running, and then they will compare the two. So a room that has only one of those numbers is a room that cannot answer the question, and worse, does not know that yet. What I find interesting is why the mistake is so durable, and I think it is because the export feels authoritative in a way a discovery report does not. It is signed by the vendor, it is complete, it has no gaps in it. All of that is true. It is a complete and authoritative answer to half the question. So the discipline I would ask for is small: whenever somebody says here is our licence position, ask which half they are holding, and where the other half is.
A complete and authoritative answer to half the question. Whenever somebody says here is our licence position, ask which half they are holding. So let's lay out where the halves come from.
Four sources. Passport Advantage reports, authoritative on what you purchased by part number and quantity, and unable to tell you whether any of it is installed anywhere. Proof of entitlement documents, authoritative on the specific rights attached to each purchase, and silent on deployment or version. ILMT and discovery, authoritative on what is actually installed and the capacity it can see, and unable to tell you what you are entitled to or under which terms. And the agreements themselves, authoritative on the definitions your counts are measured against, and carrying no numbers at all, because an agreement defines, it does not count. Now the note, which is the honest part. No single source answers the question. The baseline is the reconciliation between them, and the reconciliation is the work, which is precisely why it always takes longer than anybody plans for.
Knowledge check one. Somebody presents a Passport Advantage export as the licence position. What is missing? A, nothing, it is the authoritative record. B, deployment, because the portal records what you bought and has no view of what is installed. C, only the pricing history. D, only entitlements bought before the current agreement. Pause here, and ask which half of the comparison the portal actually holds.
The answer is B, deployment. The portal is authoritative on entitlement and silent on deployment, and an audit is built on deployment measured against entitlement, so an export on its own cannot answer the question that will actually be asked. Answer A is the most common mistake in this entire module, and I want to be sympathetic about why. The export looks complete, it has no obvious gaps, and it is generated by the vendor's own system, all of which makes it feel like an answer rather than like one half of one. That feeling is the trap, and naming it is most of the defence.
So, in fairness, what does Passport Advantage genuinely give you. The purchase record, part numbers and quantities and dates for everything bought under the enrolment, and that is a real and useful spine to build a baseline around. The support position, showing what is under subscription and support and what has lapsed, which is last session's anniversary file in raw form. The point level, showing where your accrued points have placed you, which is one of the two uplift arguments we covered. Proof of entitlement, the document stating the rights attached to a purchase, and the thing to archive now rather than assume you can retrieve later. And then the fifth point, which is easy to overlook. It is per enrolment. So if you buy through several site numbers, the portal shows you several partial pictures rather than one complete one, and that is exactly how estates lose track of their own entitlement without anybody being careless.
Now the gaps, five of them, and each one costs money. What is deployed, which is the largest gap by a distance, because everything about audit exposure lives on that side of the line and none of it is in the portal. What is bundled inside something else, because programs entitled through a Cloud Pak or another product do not read as separate purchases, so they can be bought twice without anybody noticing. Which entitlements are restricted, meaning whether a licence may be used standalone or only alongside the product it arrived with, and that restriction lives in the terms rather than in the quantity. What arrived through acquisition, because entitlement inherited with an acquired company sits on somebody else's enrolment until somebody moves it, and frequently nobody does. And whether you qualify for sub capacity, which is an operational question about ILMT rather than a purchasing one, and it is the subject of the next two sessions.
Guest analyst clip. The double purchase is the finding that most annoys the people it happens to, because unlike most licensing problems there is nothing defensible about it at all. You paid twice for the same right. And the way it happens is completely mundane. A project team needs a database. Somebody sensible checks whether the organisation already owns one, searches the purchase records, finds nothing, and raises a purchase order. Entirely correct behaviour, good governance even. But the entitlement did exist, it just arrived bundled inside a Cloud Pak that somebody in a different part of the business bought eighteen months earlier, and bundled programs do not appear as separate line items anywhere a purchasing team would look. So the search was competent and the answer was wrong. What I take from this is that bundled entitlements have to be recorded deliberately, by hand, in whatever your organisation treats as the list of what it owns. No report will volunteer that you already have something. And the cost of not doing it is not subtle, it is buying software you own, which is the one licensing mistake nobody can explain away afterwards.
No report will volunteer that you already own something. That is why bundled rights get written into the baseline by hand, and it is the one licensing mistake nobody can explain away afterwards. So let's take bundles properly.
Knowledge check two. A team buys a database licence. The same database was already entitled inside a Cloud Pak you own. What has happened? A, nothing, separate purchases are always separate rights. B, a likely double purchase, because bundled entitlements do not read as separate line items in the portal. C, the Cloud Pak entitlement is voided. D, the new licence automatically converts into Cloud Pak ratios. Pause here, and ask where that bundled right would have shown up.
The answer is B, a likely double purchase. A Cloud Pak bundles a set of entitled programs at published ratios, so the right to run that database genuinely exists without ever appearing as a database purchase. And I want to stress the human sequence, because it matters for how you fix it. The buying team searched the portal, found nothing, and bought correctly on the information available to them. Nobody was careless. Which is exactly why the baseline has to record bundled entitlements explicitly rather than inferring them from purchase lines, because inference from purchase lines is the thing that just failed.
Bundled entitlement, five points. The mechanism, where a Cloud Pak bundles a set of entitled programs and a published ratio converts each underlying product into the Cloud Pak metric. The genuine benefit, which is flexibility across the bundled products, and that is real and is often exactly why the bundle is worth buying. The assumption to test, which is that the bundle is cheaper by default, so check whether you will actually use the bundle breadth before paying for it, because breadth you do not use is still priced in. The reconciliation problem, where bundled rights have to be written into the baseline by hand for the reason we just covered. And ratios deserve their own modelling, because conversion ratios decide how much of the underlying product your bundle actually entitles, which is a quantity question rather than a naming one, and it is the question people skip.
Guest analyst clip. Restricted use is the one I would most want a room to understand, because it is invisible in exactly the place people look. Picture a capacity check. Somebody pulls the numbers, sees that the organisation is entitled to more of a product than it currently runs, and concludes there is headroom. So a new project deploys into that headroom. Sensible, thrifty, exactly what you would want somebody to do. Except that the entitlement in question came bundled with another product and is licensed only for use with it, and the new deployment is standalone. Now you have an exposure, and it was created by somebody trying to save money using a number that was accurate. That is what makes it dangerous. The quantity was right. The quantity is always right. What was missing was the context attached to the quantity, and context does not appear in a column of numbers. So the control is simply a flag in whatever your baseline is: restricted, yes or no, and if yes, with what. It takes a few minutes per entitlement to record and it means that when somebody goes looking for spare capacity, the spare capacity they find is capacity they are actually allowed to use.
The quantity is always right, and what is missing is the context attached to it. A restricted flag per entitlement means the spare capacity somebody finds is capacity they may actually use.
So let me set restricted use out properly. What it means, an entitlement supplied for use with a specific product rather than a general right to run that software wherever you like. Why it is easy to miss, because the quantity looks completely identical in a report and the restriction lives in the terms attached to the entitlement, which is a different document that nobody opened. How it goes wrong, which is the story you just heard, where a team finds spare capacity in the numbers and deploys it standalone, entirely reasonably, creating an exposure that no quantity check would ever catch. The control, a restricted flag in your baseline per entitlement. And it applies to bundles too, because programs entitled through a Cloud Pak carry the Cloud Pak's context with them, which is the same rule wearing different clothes.
Now the part that makes this worth doing rather than merely prudent. A baseline finds waste and exposure in the same pass. Entitled above deployed is waste, meaning middleware you own and never deployed, carrying support every single year and lifted by every uplift from session four. Deployed above entitled is exposure, which is the audit number, and it arrives with a deadline attached rather than with a saving. Most estates have both at once, which is why a baseline that only looks in one direction reports half a result and usually the less urgent half. The fix order matters, so you remove undeployed middleware and fix coverage before any discount conversation, because the discount gets applied to whatever number you bring to the table. And all of it is fixable without negotiating, because both the shelfware and the coverage gaps can be closed before a renewal without a single point of discount being discussed with anybody.
Knowledge check three. You are offered an enterprise agreement with a strong discount, and your baseline has never been reconciled. What is the risk? A, none, a bigger discount is always better. B, you lock in a discounted version of overspend, for the length of the agreement. C, only that the true up terms may be complex. D, the agreement cannot be signed without a baseline. Pause here, and ask what the discount is actually being applied to.
The answer is B. A percentage applied to a bloated quantity is still a bloated quantity, and an enterprise agreement fixes it in place for years rather than for a single renewal, which is what makes this worse than an ordinary bad renewal. Answer C names a completely genuine second risk, because a flexible looking agreement can carry a costly annual reconciliation and those terms deserve reading, and it is not the main one here. So the sequence is fix ILMT coverage, remove undeployed middleware, rebaseline, and only then have the discount conversation. In that order, every time.
Guest analyst clip. The hardest part of this advice is not analytical, it is that it asks an organisation to delay something exciting in order to do something dull. An enterprise agreement with a headline discount is exciting. It gets presented to a board. Somebody has a number they can report. Whereas rebaselining is a quarter of unglamorous reconciliation work with no announcement at the end of it, and the person arguing for it is arguing to postpone the good news. So I want to arm anybody in that position with the sharpest version of the argument, which is this. The discount is a percentage. The baseline is what it multiplies. If the baseline is twenty percent too big, then a thirty percent discount on it is worse than a twenty percent discount on the right number, and no amount of negotiating skill closes that gap afterwards, because you have signed for years. I have never had a client regret spending a quarter on the baseline first. I have had several tell me, at the second renewal of an agreement, that they were still paying for the decision to skip it, and by then there is nothing to be done except wait for the term to end.
So here is what a baseline actually contains, five things. Entitled per product with the source, so part number, quantity, and where the number came from, which means any line can be defended later without repeating the work. Deployed per product with the date, from ILMT or discovery, and dated, because a deployment number without a date is an anecdote. The gap in both directions, explicitly signed, so waste and exposure show as separate findings rather than being netted into one comforting number that hides both. Bundled and restricted flags, recorded per entitlement by hand, because neither is inferable from any report you can export. And an owner and a review date, because a baseline is a standing document, and rebuilt annually in a panic it is a project, while maintained quarterly it is about an hour.
Three sentences. Passport Advantage is authoritative on what you purchased and silent on what you deployed, which makes an export half a baseline, and specifically the half an audit is not built on. Bundled entitlements arrive inside Cloud Paks at published ratios and never read as separate purchases, restricted use entitlements look identical to unrestricted ones in any quantity report, and both have to be written into the baseline by hand. And the reconciliation finds waste and exposure in the same pass, and in six of ten estates the larger number was not the discount but the shelfware and the full capacity exposure, which is why you rebaseline before any discount conversation rather than after it.
Homework, about an hour. Pull one Passport Advantage export, any enrolment, look at what it tells you, and then write down the question it cannot answer, because writing that sentence yourself is worth more than hearing me say it. Find one bundled entitlement, so if you own a Cloud Pak, list the programs it entitles and ask whether any of them have also been bought separately. Check for restricted use by picking three entitlements and finding the terms attached to each, then answering whether they can be used standalone or only with the product they came with. Count your enrolments again, and where session four asked for the commercial reason, this time the reason is that each one is a separate partial picture of what you own. And name the owner, meaning who maintains the baseline and when it was last updated, and if the answer is nobody and at the last audit, then that is your finding.
Five guides. IBM licensing explained sets the estate and the agreements around the metric catalog, including why the baseline rather than the discount decides most outcomes. The Passport Advantage guide covers what the agreement records, how points and enrolments work, and why several site numbers means several partial pictures. The IBM audit defence playbook explains why a defensible deployment baseline beats a vendor estimate and what walking in with one actually changes in the room.
The ILMT comprehensive pillar covers the deployment half of the baseline, which is exactly where the next two sessions live. And the analytics and data platform licensing guide gives you a worked example of bundled entitlement and conversion ratios in a product family most estates already own, which makes the abstract concrete. That is module one complete. Next time we open module two with PVU licensing, the value unit table, core factors, and what full capacity actually costs in money. See you there.