IBM Maximo licensing and audit defense.
Maximo is licensed by who uses it and which add ons are enabled, not by a single flat number. The user classification and the active add ons decide the count, and both are routinely read against the buyer. A Maximo finding that puts users in the wrong class, or counts add ons that are not enabled, is inflated at the root.
How Maximo is licensed
Maximo is an asset and work management platform, and its licensing follows the way people interact with it. Users are separated into classes by capability, from authorized users who perform full work management to lighter classes who only request or view. Add on industry solutions and options carry their own entitlements layered on top of the base. As Maximo moves into its modern application suite form, parts of the estate may also be metered on a consumption basis. The single most important variable across all of these is the user classification, because it decides how many of the more expensive licenses you actually owe.
The common Maximo audit traps
Maximo findings cluster around a handful of recurring errors:
- Users counted in the wrong class. A user who only raises service requests counted as a full authorized user is the most frequent and most expensive Maximo over count.
- Inactive and duplicate accounts counted. Accounts left after staff turnover, or duplicated across security groups, inflate the population if they are not filtered against genuine use.
- Add ons counted as enabled when they are not. Industry solutions and options installed but not in use can be swept into a finding as if they were active entitlements.
- Non production environments counted as production. Development, test and training instances counted as production add capacity that was never licensable that way.
How we defend it
The defense rebuilds the Maximo position from genuine use. Every account is mapped to the class its actual activity supports, inactive and duplicate accounts are removed, add ons are confirmed as enabled or not, and non production environments are separated from production. The corrected user classification almost always reduces the count of the expensive classes, and the add on reconciliation removes entitlements the audit assumed were live. On an enterprise estate where Maximo sat alongside Cognos, mapping actual user counts to entitlements removed the excess license claim and cut $2.8M of over deployment at renewal.
A Maximo finding rests on user classification and active add ons. Confirm the genuine class for every user, strip inactive and duplicate accounts, verify which add ons are actually enabled, and separate non production from production before accepting the count. Users misclassified into the expensive class are the most common Maximo inflation, and the most reversible.
Was your Maximo count built on real user classes?
Our Audit Defense engagement rebuilds the Maximo position from genuine use, reclassifies users to the class their activity supports, and reconciles add ons and environments so the finding rests on what you actually run.
See Audit Defense →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.