AppPoints, the consumption models, and how the AI additions get charged. 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 to session fifteen, which closes module three. Today we take the newest end of the IBM catalog, Maximo Application Suite and the watsonx portfolio, and I want to set an expectation. These metrics look nothing like a processor value unit. Points allocated to users, resource units drawn against a commitment, capacity measured in tokens. Genuinely different machinery. And yet they fail in precisely the way session five described, which is that an organisation buys the number it might need rather than the number it uses, and then renews it every year. Three knowledge checks. Let's begin.
Five objectives. First, price a user in AppPoints, where Premium is fifteen, Base is ten, Limited is five and Self Service is zero, and the application gates the tier rather than the job title. Second, size to concurrency rather than headcount, because an Authorized user reserves points permanently while a Concurrent user returns them at logout, and those are different pools entirely. Third, survive a suite conversion, because converting the full named list carries idle accounts, leavers and over tiered users into the new pool and locks the bloat in for the term. Fourth, read a Resource Unit, where one unit is a thousand tokens, the conversion varies by service, and rates are set per release so an upgrade can raise consumption on a deployment nobody changed. And fifth, structure a consumption commitment, because committed pools ran two to three times measured consumption in the first year, while a measured floor with a fair true up cut first year cost by twenty to thirty five percent.
Four numbers. Forty two percent, the pool reduction on a benchmark one thousand user Maximo estate, from tier correction and concurrency alone, with no functionality removed. Three times, what switching on one Premium gated application does to a user, taking five points to fifteen with no change to their role at all. Forty percent, the median share of a committed Resource Unit pool that went unused, and it rarely carried forward cleanly. And two to three times, how far committed pools ran above measured consumption in the first year of an AI commitment. Then the note, which is the sentence that ties this session to session five and to session eleven. A bigger pool does not buy safety, it buys shelfware that renews. The measurement is the asset, not the headroom.
Guest analyst clip. There is a pattern running through this entire course that I want to name explicitly, now that you have seen it in four different metrics. Every time IBM introduces a new licensing model, it is genuinely new. Points are not value units. Tokens are not cores. The mechanics change completely and you have to learn them properly, which is what this course has been for. But the failure mode does not change at all. In every single model, the organisation buys headroom. It buys the number it might need, because that feels prudent and because nobody was ever criticised for having enough licences. And then it pays for that headroom annually, forever, and the headroom does not show up anywhere as a problem because it is not a compliance issue. It is just money leaving quietly. What I find useful about seeing the pattern is that it tells you where to look in a model you have never met before. Whatever the next metric is, and there will be a next metric, the first question is not how does this count. It is what does this model let me buy that I will not use, and how would I know. That question travels across every model in this catalog and it will travel across the ones that have not been invented yet.
What does this model let me buy that I will not use, and how would I know. That question travels across every metric in the catalog. Now the newest one.
AppPoints, four tiers, and the same person costs five, ten or fifteen points depending on which one they sit in. Premium is fifteen points, covering power roles and anybody touching a Premium gated application such as Predict. Base is ten points, covering core work management, health and safety, so planners, supervisors and managers. Limited is five points, covering monitor, mobile and a small number of modules, which is technicians and light users. And Self Service is zero, covering requesters who raise and track tickets only, and who cost nothing at all, which is worth knowing because a great many people in a large organisation belong in that tier and are frequently not put there. And then the note, which is the mechanic that catches everybody. The application gates the tier, not the job title. Switch on one Premium gated application and every user of it is pulled to fifteen points, however lightly they use it.
Knowledge check one. You pilot a Premium gated application for forty technicians who currently sit at Limited. What does the pool need? A, nothing, it is a pilot and their roles have not changed. B, an extra four hundred points, because they move from five to fifteen. C, an extra six hundred points, because forty users at fifteen points replaces forty at five. D, nothing until the pilot goes into production. Pause here. Forty users, moving from five points each to fifteen. What is the new total, and what is the increase?
The answer is B, an extra four hundred points. Forty users at fifteen points is six hundred in total, against the two hundred they already drew at Limited, so the increase is four hundred and the pool now carries six hundred for that group. Answer C confuses the new total with the increment, and I have deliberately made that the trap because it is exactly the slip that matters when you are negotiating a pool size, where the difference between a total and an increase is the difference between a right answer and a fifty percent error. And answer A is the assumption that costs the money, because a pilot of a Premium gated application can add hundreds of points before a single work order changes.
So, Authorized against Concurrent, which is the largest single lever here. An Authorized user holds points permanently, even when they never log in, which makes a named list the most expensive way to size a suite. A Concurrent user checks points out for the length of the session and returns them at logout, so you size to peak concurrency rather than to the named list, and in most organisations those two numbers are very far apart. Concurrency has a ceiling with teeth, because if more users try to log in at once than the pool supports, the suite denies the session, so a busy Monday morning becomes a help desk queue, and that is the real constraint on cutting too deep. Mobile entitlements ride along quietly, so a five hundred strong crew can carry an extra two thousand five hundred points for an entitlement nobody in the crew has ever used. And shared logins are counted upward, because an audit counts the highest tier ever assigned to the account, so one Premium assignment on a shared login prices every use of it.
Now the conversion from classic licensing to the suite, five points. The unit changes completely, from named users per product to a shared pool across the whole suite, which is genuinely more flexible and is priced accordingly. The safe looking move is the expensive one, because converting the full named list carries idle accounts, leavers and over tiered users straight into the new pool, locking the bloat in for the term. The published ratio is rarely the negotiated ratio, and in roughly eighteen of thirty conversions reviewed, the published legacy to points ratio left the customer short of like for like entitlement. The platform cost is real and often missing, because the suite runs on OpenShift, which has added ten to twenty percent that the legacy business case never included. And size against year three, because the contract should be sized against the third year deployment rather than the first, since the pool is the thing you cannot easily shrink afterwards.
Guest analyst clip. A conversion to a suite is the single best opportunity you will ever get to clean up a user list, and almost every organisation wastes it. Here is why the waste happens, and it is entirely understandable. A conversion is a project with a deadline. The task is to move from the old model to the new one without breaking anything, and the safest possible way to do that is to take the list you have and convert all of it. Nobody loses access, nothing breaks, the project lands on time. And in doing that you have just carried every leaver who was never deprovisioned, every contractor from a finished programme, and every user sitting at a tier somebody assigned three years ago for a reason nobody remembers, straight into a pool you will now pay for annually for the length of the term. The bloat becomes the baseline. So the argument I make to project sponsors is about timing rather than about hygiene. You are going to have to clean this list eventually. Doing it during the conversion costs a few weeks of effort inside a project that is already touching every user record. Doing it afterwards means renegotiating a pool you have already committed to, which is a much harder conversation with a vendor who has no reason to help you.
The bloat becomes the baseline. Clean the list during the conversion, inside a project already touching every user record, rather than renegotiating a pool you already committed to.
Knowledge check two. Your AppPoints pool is sized on a one thousand name user list, all Authorized. What is the most likely finding? A, nothing, a named list is the safest way to be compliant. B, the pool is oversized by a quarter to two fifths, because concurrency and tier correction have not been applied. C, the pool is undersized, because named lists understate real use. D, it cannot be assessed without IBM's consumption report. Pause here, and ask how many of those one thousand people are logged in at the same moment.
The answer is B. Pools typically sat twenty five to forty percent above measured application and concurrency use before correction, and on the benchmark estate the reduction reached forty two percent with no functionality removed at all. Answer A is the instinct that produces the overspend, and it is worth being fair to it, because a named list genuinely is safe. Nobody is ever denied a session and no auditor ever finds a gap. What is being bought there is safety, and the unusual thing about this model is that the safety is purchased with an annually renewing subscription rather than with a one off payment, which means you buy it again every year for as long as you own the product.
Now the consumption metric, which is where the AI portfolio prices. One Resource Unit is a thousand tokens, which makes the unit legible, and public foundation model rates near two tenths of a cent per thousand tokens make a comparison possible in a way that is unusual in this catalog. The conversion varies by service, because a training workload consumes at a different rate to an inference call or a stored file, and the rates are published per service rather than being one number. The same metric spans the platforms, so AI, data and governance all price on Resource Units whether run as a service, managed on a hyperscaler, or in containers on your own platform. Ratios are set per release, so an upgrade can raise consumption on a deployment nobody changed, which is why the baseline belongs in the contract rather than in a sizing spreadsheet. And the AI operations products count differently again, because Cloud Pak for AIOps licenses by Managed Virtual Server as well as Resource Unit, so the count grows as the monitored estate grows.
Guest analyst clip. I want to make an argument about forecasting that applies to every consumption commitment you will ever be offered. When a vendor asks you to commit for three years, they are asking you to forecast three years of usage of a technology your organisation started using eight months ago. Nobody can do that. Not you, not them, not anybody, and the honest people on the vendor side will admit it privately. And because nobody can do it, the forecast that ends up in the contract is not really a forecast, it is a negotiating artefact, arrived at by working backwards from a number somebody wanted to reach. What we measure bears that out: committed pools ran two to three times actual consumption in the first year, with a median of forty percent of the pool going unused and not carrying forward cleanly. So the structural answer is to stop pretending. Commit to the part you actually know, which is the floor, the usage you are confident you will have because it is already happening. Then take a fair true up rate for everything above it. You will pay slightly more per unit on the overage, and you will avoid buying two years of a curve that never materialised. On every estate we have measured, that trade has been worth twenty to thirty five percent in the first year alone.
Commit to the part you actually know, and take a fair true up on the rest. Which means the shape of the commitment matters more than the rate inside it.
So, over commit and overage, five points. Over commit expires, because committed pools ran two to three times measured consumption in the first year and a median forty percent went unused, rarely carrying forward cleanly. Under commit costs the discount, because overage above the pool prices at standard rates without the multi year band, so a sustained overage event can erode the commit discount entirely, which is the risk on the other side and it is real. Forecasting a young AI workload is guesswork, so the conservative pool with planned overage has outperformed the aggressive pool with idle expiry on the estates measured. Cloud credits expire annually and do not roll over, so credits attached to an agreement need a real consumption plan behind them or they are simply margin handed back. And the horizon is eighteen to twenty four months, which is what an AI commitment should match, rather than the length of whatever enterprise agreement it is being folded into.
Four things to write down before signing, and a fifth. A consumption ceiling with a defined overage rate, because consumption models reward elasticity and punish inattention, and there is no natural ceiling unless the contract writes one. A portability right across the portfolio, so committed spend can move between services as the workload finds its shape rather than expiring against the one you guessed at. A pricing revision guard, holding unit rates through the term, because consumption repricing is where these economics quietly move. Reallocation rights on the points pool, because points re flow across suite applications as you reassign tiers and that flexibility is the product, so without the clause you have bought a bundle rather than a pool. And a substitution right on unused capability, letting you swap an underused component for credit, which reverses the default of paying for capability the deployment never adopted.
Knowledge check three. A vendor proposes a three year AI commitment sized on your projected usage three years out. What is the buyer side position? A, accept, because a larger commitment attracts the deepest rate. B, commit to a measured floor with a fair true up, and match the horizon to eighteen to twenty four months. C, refuse any commitment and buy everything at consumption rates. D, commit fully but negotiate the overage rate down. Pause here, and ask what you actually know about your usage in three years.
The answer is B. An accurate floor plus a fair true up beat a discounted overcommit on every estate measured, and it cut first year cost by twenty to thirty five percent. Answer C is the overcorrection, and it gives away the rate band for no reason, because a floor you are genuinely confident of costs you nothing to commit and buys a better rate on the part you were always going to consume. Answer D is closer than it looks and still accepts a pool sized on a forecast nobody is capable of making, which is the actual problem rather than the overage rate. Fix the shape first. The rate is a second order question.
Guest analyst clip. Let me close module three where session five opened, because I think the symmetry is the useful thing here. Ten sessions ago we said that the discount is a percentage and the baseline is what it multiplies, and that a clean footprint beats a deeper discount on a number you should never have been paying. Everything since then has been a variation on that. Sub capacity is a baseline problem. Cloud Pak pools are a baseline problem. AppPoints are a baseline problem wearing user tiers, and a resource unit commitment is a baseline problem denominated in tokens. In every case, the vendor conversation is about the rate, and the money is in the quantity. Which leads to the sentence I would leave you with from this module. A bigger pool does not buy safety, it buys shelfware that renews. And the corollary, which is more useful still: the measurement is the asset, not the headroom. If you leave this course able to measure your own estate honestly, in whatever units the current model uses, you will negotiate better than somebody who knows every clause and cannot say what they run. I have watched both types in the same room, and it is not close.
So, measuring the newer portfolio, five things. Report peak concurrency quarterly for the suite, because that is the number the pool should be sized against and the only one that falls when you fix something. Hold a tier register, covering who sits at which tier, which application put them there, and which of those applications is actually used, because that third column is where the savings are. Separate non production from the production pool, since development, test and sandbox drawing from the production pool is one of the four recurring audit findings and it is entirely avoidable. Track Resource Unit burn monthly against the committed floor, so the true up conversation happens with data rather than at the anniversary with a surprise. And re read the ratios at every upgrade, because rates are set per release, which makes an upgrade a licensing event on this portfolio in exactly the way a hardware refresh was a licensing event on PVU.
Three sentences. AppPoints price the same person at fifteen, ten, five or zero depending on the tier, and the application gates the tier rather than the job title, so switching on one Premium gated application triples the cost of every user who touches it without changing anybody's role. Sizing to a named Authorized list rather than to peak concurrency is what put pools twenty five to forty percent above measured use, and correcting tiers and concurrency on a benchmark one thousand user estate cut the pool by forty two percent with no functionality removed at all. And the consumption portfolio prices in Resource Units of a thousand tokens at rates that vary by service and are set per release, committed pools ran two to three times measured consumption with a median forty percent unused, and a measured floor with a fair true up cut first year cost by twenty to thirty five percent.
Homework, about an hour. Count your peak concurrency, so for any suite you run, how many users are actually logged in at the busiest moment against how many are named in the pool, because that ratio is your headline finding. Find the Premium gate, asking which applications pull a user to the top tier and how many users sit at that tier because of an application they rarely open. Check for non production drawing on production, asking whether development, test and sandbox users consume from the same pool as the people doing the work. Measure one month of Resource Unit burn against the committed floor, then multiply by twelve and compare it to what you committed to for the year, which takes about ten minutes and is frequently sobering. And read one clause, asking whether your agreement allows points to be reallocated across applications and committed consumption to move across services, because if not, you bought a bundle rather than a pool.
Five guides. The Maximo Application Suite licensing guide covers how AppPoints are drawn by application, the median pool oversize, and the platform cost the legacy business case leaves out. The CIO playbook for Maximo and industry solutions covers the conversion ratio that is rarely the negotiated one, the reallocation clauses that make the pool a pool, and sizing against the third year. And the watsonx licensing guide covers the Resource Unit model service by service, the commit terms, and why the conservative pool with planned overage usually wins.
The analytics and data platform guide covers the seven metrics that portfolio bills through and why consumption baselines belong in the contract rather than a spreadsheet. And the Cloud Pak for AIOps guide covers Managed Virtual Servers and Resource Units together, and how that count grows with the estate you monitor. That closes module three. Next time module four opens with the mainframe: MSU, monthly license charges, the rolling four hour average, SCRT and specialty engines. See you there.