Planning Analytics Licensing Explained
IBM Planning Analytics, the platform built on the TM1 engine, is licensed mostly by user role rather than by processor. That makes the user list, not the server, the thing IBM measures, and the roles assigned to those users decide the bill. Get the roles wrong and the count moves against you fast.
The metric is the user, and the role inside it
Where products like Db2 and WebSphere are metered on hardware capacity through PVU, Planning Analytics is metered primarily on authorized users grouped by what they are allowed to do. A user who builds models and a user who only reads a published view are not the same license, and they are not the same price. The platform also offers capacity based options for some deployments, but for most estates the audit turns on counting people and classifying them correctly, not on counting cores.
The roles that decide the count
- Modeler or administrator: the heavyweight role that builds cubes, rules and models, the most expensive to entitle
- Contributor or analyzer: users who input data, run what if analysis, and work with the models others build
- Viewer or explorer: read mostly access to published content, the lightest role
- Service and integration accounts: non human IDs that should not be counted as authorized users
Where Planning Analytics audits go wrong
The classic finding is role inflation. Over time, users get provisioned at a higher role than they use, viewers are granted modeler rights for a one time task and never downgraded, and leavers stay active in the directory. IBM counts the entitlement a user holds, not the work they do, so an estate full of over provisioned accounts reads as a large modeler population even when most people only view. The second trap is service accounts and duplicates counted as distinct human users, and the third is named users measured without removing the inactive ones.
How buyers defend it
This is a reconciliation exercise, and it is winnable. We pull the full authorized user list, strip out service accounts, duplicates, and disabled identities, then map each remaining user to the role their actual usage supports. A viewer provisioned as a modeler but only ever reading content is a viewer for licensing purposes once the entitlement is corrected. Where the audit counts inflated roles, the corrected mapping is the counter, and it usually moves the number well before any negotiation on price. The same Cognos user reconciliation discipline applies here, because the analytics portfolio shares the pattern.
Planning Analytics is a people count, not a core count, and the role is the lever. Role inflation, stale accounts, and service IDs counted as users are what push the number up, and all three are answerable with a clean reconciliation. Build the corrected user and role map before you respond, downgrade what was over provisioned, and challenge the finding with the list, not the price.