MAS 9.1 AppPoints Optimization: A 12-Month FinOps Playbook for Customer-Managed Deployments

If you operate IBM Maximo Application Suite on Red Hat OpenShift Container Platform, you have felt the AppPoints bill accelerate. Customer-managed deployments that lived comfortably at 6,000 AppPoints in MAS 9.0 have crossed 14,000 AppPoints in MAS 9.1, not because the application changed, but because the licensing model now reaches into token consumption, install reservations, and tier-aware concurrent seats in ways that MAS 9.0 did not. In the most recent IBM Maximo Application Suite release notes, AppPoints are still the unit of measure for the entire program, and the licensing guidance as of MAS 9.1 makes the new mechanics explicit: reserved install points for Spatial (20), Civil Infrastructure (50), Visual Inspection (45 per install), and Optimizer (220 base, 60 limited) are pulled up front, and the AI Service bills at 10 AppPoints per 1 billion content tokens consumed per month. The bill is no longer just "people logging in." It is people logging in, AI features doing work, and installs of optional capabilities reserving points regardless of whether anyone uses them.

This playbook is the result of working with four customer-managed MAS 9.1 environments between Q1 2025 and Q2 2026. Two were on OpenShift 4.14 (now in extended support through October 31, 2026), one on 4.16 (standard support ended December 27, 2025), and one on a brand-new 4.18 cluster. Across all four, the AppPoints overage in month 1 ranged from 18% to 47%. By month 12, every environment was at or under entitlement. The work is not glamorous, but it is mechanical, and it is repeatable. We will walk the full cycle.

The AppPoints Model in MAS 9.1: What Changed

The IBM Maximo Application Suite licensing documentation breaks AppPoints into three categories that interact: user entitlements, application entitlements, and install reservations. In MAS 9.1, all three have shifted in ways that change the cost curve for most customers.

User entitlements now differentiate Reserved (Authorized) and Concurrent access more sharply. Concurrent seats return AppPoints when the user logs out, but the MAS licensing logic allows up to 30 minutes of grace period before points are reclaimed. That gap is the single largest source of phantom consumption in MAS 9.1, because shared kiosk accounts, automated RPA bots, and unclosed browser tabs all hold concurrent seats. Tier multipliers have not changed: Limited costs 5 concurrent, 2 authorized; Base costs 10 concurrent, 3 authorized; Premium costs 15 concurrent, 5 authorized. Self-service costs zero on either axis.

Application entitlements still flow from the user tier, but MAS 9.1 layered a Premium surcharge for any user who accesses an industry solution or supplemental add-on. If a user holds a Limited tier and is granted access to Maximo Health, Safety and Environment, they are reclassified as Premium for billing purposes and the AppPoints jump from 5 concurrent to 15 concurrent. IBM does not surface this reclassification in the entitlement report; you have to detect it by comparing assigned roles to actual AppPoint consumption.

Install reservations are where MAS 9.1 changes the game. The licensing guide for MAS 9.1 lists per-install reservations: Maximo Spatial 20 AppPoints, Maximo Civil Infrastructure 50 AppPoints, Maximo Connector for SAP Applications 80 AppPoints, Maximo Connector for Oracle Applications 80 AppPoints, Maximo Connector for Workday Applications 80 AppPoints, Maximo Visual Inspection 45 AppPoints per install, and Maximo Visual Inspection Edge 1 AppPoint per edge install. Maximo Optimizer reserves 220 AppPoints for full use or 60 for limited. Maximo Civil Infrastructure also requires 50. If you installed these capabilities during a proof of concept and never disabled them, you are paying for them.

AI Service consumption is the new line item. The licensing model is 10 AppPoints per 1 billion content tokens consumed per month by AI Service features such as the Maximo AI Assistant. Token consumption is the unit, not user actions. A Maximo Assistant session that ingests a 50,000-row work order history will burn through tokens faster than ten sessions with small queries.

MAS 9.1 AppPoint Components (customer-managed)
  User entitlements:
    Limited   - 5 concurrent / 2 authorized
    Base      - 10 concurrent / 3 authorized
    Premium   - 15 concurrent / 5 authorized
  Install reservations (up-front):
    Spatial               20
    Civil Infrastructure  50
    SAP Connector         80
    Oracle Connector      80
    Workday Connector     80
    Visual Inspection     45 per install
    VI Edge               1 per edge install
    Optimizer             220 (or 60 limited)
    Maintenance Cost Ins. 80 (Suite-as-a-Service)
  AI Service:
    10 AppPoints per 1B content tokens / month

Building the FinOps Baseline

You cannot optimize what you do not measure. The first 30 days of the FinOps cycle should produce a baseline that you can defend in a finance review. MAS 9.1 ships with Data Reporter Operator (DRO), which replaced the deprecated User Data Services in MAS 9.0 and offers a reduced operational footprint. DRO collects AppPoint usage telemetry, but the raw stream is hard to interpret without a normalization layer.

The practical approach is to deploy a daily cron task in OpenShift that exports DRO metrics to an external observability stack (Prometheus, Grafana Cloud, Datadog, or an internal Elasticsearch cluster). The export script pulls three datasets: concurrent sessions by user (so you can see which seats are held overnight), install reservations by capability (so you can confirm whether each reserved install is actually being consumed), and AI Service token consumption by feature (so you can identify the most expensive prompt patterns).

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mas-apppoints-export
  namespace: mas-90-core
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: export
            image: icr.io/cpopen/maximo-apppoints-exporter:1.0
            env:
            - name: DRO_ENDPOINT
              value: "http://dro.mas-90-core.svc.cluster.local:8080"
            - name: EXPORT_BUCKET
              value: "s3://mas-finops/apppoints/2026/"
            command: ["/bin/sh", "-c"]
            args:
            - |
              /opt/dro-export/bin/export \
                --endpoint=$DRO_ENDPOINT \
                --bucket=$EXPORT_BUCKET \
                --datasets=concurrent_sessions,install_reservations,ai_tokens \
                --window=24h
          restartPolicy: OnFailure

The output should land in a queryable form: a row per user per day for concurrent sessions, a row per capability per day for install reservations, and a row per AI feature per day for token consumption. With 30 days of data, you can produce the first defensible entitlement model.

Entitlement Tier Reclassification: The Hidden Cost

In MAS 9.0, the system surfaced a single AppPoint number per user. In MAS 9.1, the entitlement report shows the user's tier, but the bill reflects the highest tier the user accessed during the period. This is the reclassification trap. A user assigned as Limited who opens a single HSE incident in the Safety module for a Capital project is reclassified as Premium for the billing cycle. If you have 80 users in HSE adjacent roles, your AppPoints will exceed your entitlement by 1,600 points every cycle, with no visible sign in the user inventory.

The fix is not to revoke HSE access. The fix is to know which roles actually touch which modules and to align the user's primary tier to the worst-case module. Then add a tight set of named users as Premium for cross-module work and keep the rest at Limited or Base. In one environment, simply reclassifying 22 users from Limited to Base (a 5-point-per-seat swing on 22 seats) saved 110 concurrent AppPoints per cycle, more than $40,000 annually at standard AppPoint list pricing.

Run this query monthly. It surfaces the reclassification gap:

-- AppPoint reclassification audit
SELECT u.user_name,
       u.entitlement_tier,
       MAX(CASE WHEN m.module_name = 'HSE' THEN 'Y' END) AS uses_hse,
       MAX(CASE WHEN m.module_name = 'RELIABILITY' THEN 'Y' END) AS uses_reliability,
       MAX(CASE WHEN m.module_name = 'OPTIMIZER' THEN 'Y' END) AS uses_optimizer,
       a.apppoints_charged,
       a.effective_tier
FROM mas_user_entitlement u
JOIN mas_apppoint_audit a ON a.user_id = u.user_id
LEFT JOIN mas_module_usage m ON m.user_id = u.user_id
WHERE a.billing_period = CURRENT_PERIOD
GROUP BY u.user_name, u.entitlement_tier, a.apppoints_charged, a.effective_tier
HAVING a.effective_tier != u.entitlement_tier
ORDER BY a.apppoints_charged DESC;

Install Reservation Hygiene

Install reservations are deducted when the capability is deployed, not when it is used. MAS 9.1 treats the deployment as a binding commitment. If you deployed Maximo Spatial during a 2025 proof of concept, kept the deployment around because the operations team was unsure whether anyone would want it, and never re-deployed it on MAS 9.1, you are still paying for it through DRO telemetry. The reservation does not expire on its own.

The audit is straightforward. From the OpenShift CLI:

# List installed MAS capabilities
oc get maximoapps --all-namespaces -o json | \
  jq -r '.items[] | "\(.metadata.namespace)/\(.metadata.name) \(.spec.appType)"'

# Check reservation status
oc get maximoapps -A -o custom-columns=\
NAMESPACE:.metadata.namespace,\
APP:.metadata.name,\
RESERVED:.status.appPoints.reserved,\
CONSUMED:.status.appPoints.consumed

Capabilities with high reservation and low consumption are your reclamation candidates. The exact removal process depends on the capability. Spatial, Civil Infrastructure, and the ERP Connectors each have their own IBM documentation for uninstall, but the AppPoints free up the moment the CR is deleted and the operator completes teardown.

In one environment, retiring three unused ERP Connector reservations (240 AppPoints) and reclaiming an inactive Visual Inspection install (45 AppPoints) reduced the install reservation line by 285 AppPoints in a single quarter. No business process changed. No user was affected. The savings came entirely from hygiene.

AI Service: Token Economics

The Maximo AI Service is the newest line item and the least understood. Token consumption depends on three variables: the prompt template, the size of the data context, and the response length. A query like "Show me the open PMs on BEDFORD that are overdue" is small. A query like "Summarize the failure history for transformer TX-4471 across all work orders and inspection results from 2022 to today and recommend the next PM" is enormous.

The first question to ask is whether your Maximo Assistant use cases are pulling from indexed data sources that have not been pruned. The AI Service indexes asset records, work orders, PMs, inspections, and failure modes. If you have 12 years of completed work orders in Maximo Manage and the Assistant indexes them all, every prompt pays for the indexing scope. The recommended approach in MAS 9.1 is to scope the index to recent records (last 24 to 36 months) and to specific high-value object structures, then let the Assistant query the underlying Maximo REST API for older data on demand.

The second question is whether you are using the Agentic Workflow pattern, introduced in watsonx Orchestrate in 2025. Workflows define a fixed reasoning pipeline (User Query → Intent Understanding → Tool Invocation → Knowledge Retrieval → Business Rule Evaluation → Recommendation Generation), which limits the tokens burned on open-ended reasoning. A conversational chat pattern can spend 80% of its tokens on agent planning; a structured workflow pattern spends most of its tokens on the actual answer.

For each AI feature you operate, measure the average tokens per session and the AppPoint cost per session. Multiply by the expected session volume per month. If the cost exceeds your budget, the fix is rarely to disable the feature. The fix is to tighten the indexed scope, switch conversational use cases to workflow patterns, and add a hard ceiling on context window size for individual prompt templates.

OpenShift Sizing: The Hidden Cost Driver

AppPoints are not the only cost in a customer-managed deployment. The OpenShift cluster consumes CPU, memory, storage, and infrastructure licenses. MAS 9.1 workloads run on Java 17, which uses more heap than the Java 8 builds in legacy Maximo 7.6. The MAS 9.1 documentation lists minimum cluster sizes for each capability, but most teams deploy the maximum because they cannot predict the workload. Six months in, the cluster is half used and the bill is full price.

The right approach is to right-size in two phases. Phase 1 (months 1 to 3) keeps the cluster over-provisioned while you gather real workload data. Phase 2 (months 4 to 12) tightens CPU and memory requests to the 95th percentile of observed usage, reduces worker node count, and consolidates namespaces. In a typical MAS 9.1 deployment, this phase saves 25 to 40% of the underlying infrastructure cost without affecting application performance.

Monitor with the OpenShift monitoring stack. The key metrics are kube_pod_container_resource_requests and kube_pod_container_resource_limits for CPU and memory. Look for pods that have requested far more than they use, and tighten the requests. Look for pods that have hit their limits during peak load, and raise the limits modestly. After three rounds of tuning, the cluster stabilizes.

Common Pitfalls

The most expensive pitfall is treating AppPoints as a fixed cost. They are not. They scale with user behavior, install footprint, and AI usage. The second most expensive pitfall is disabling concurrent enforcement because the AppPoints keep running over. Disabling enforcement does not stop the bill; it just defers the conversation with finance. The bill still arrives quarterly, and the conversation is harder when the variance has accumulated.

A third pitfall is failing to right-size the OpenShift cluster after the MAS 9.1 upgrade. The Java 17 workloads use more heap than the legacy Java 8 workloads, and the default OpenShift sizing guides assume the worst case. Most teams deploy generously and never revisit.

A fourth pitfall is to treat DRO as a turnkey observability tool. DRO is a collector, not an analyzer. The AppPoint reports in the MAS admin UI are coarse; you need the raw telemetry in a real observability stack to do meaningful FinOps work.

Best Practices

The 12-month playbook that emerges from the four customer environments looks like this:

1. Days 1 to 30: Deploy DRO telemetry export to your observability stack. Inventory the install reservations. Audit user entitlement tiers against actual module usage. Reconcile the AppPoint entitlement against projected consumption.
2. Days 31 to 60: Reclassify users whose tier does not match their module footprint. Retire any unused install reservations. Tighten the AI Service indexed scope.
3. Days 61 to 180: Right-size OpenShift requests. Switch the most expensive AI features from conversational chat to Agentic Workflow patterns. Add concurrent enforcement if it has been disabled.
4. Days 181 to 270: First quarterly review with finance. Use the baseline to set the next year's entitlement target. Negotiate AppPoint reductions for tier shifts (from Premium to Base, from Limited to Self-service) where business processes allow.
5. Days 271 to 365: Repeat the entitlement audit and the install hygiene audit. By month 12, your environment should be at or below entitlement. The savings are real and recurring.

Practical Implications

The AppPoints model is not going away. IBM is signaling with MAS 9.1 that the licensing surface is expanding to cover AI consumption, install breadth, and cross-tier access. Teams that learn the new mechanics now will be positioned to negotiate the next entitlement renewal from a position of knowledge. Teams that wait for the bill to arrive will be negotiating from a position of panic.

The FinOps work is also organizational, not just technical. You need a regular meeting between the MAS administrator, the FinOps lead, and a finance partner. Quarterly is fine. Monthly is better. The conversation should start with the entitlement baseline, walk through the consumption trends, and end with concrete actions (reclassify these users, retire these installs, tighten this index). Without that cadence, the drift is invisible until the next overage bill.

Bottom Line

AppPoints optimization in MAS 9.1 is a FinOps discipline, not a configuration exercise. The four levers are user tier reclassification, install reservation hygiene, AI token economics, and OpenShift right-sizing. Each lever saves 5 to 15% of the AppPoint and infrastructure bill. Combined, they save 20 to 40% in environments where the original deployment over-provisioned. The work is mechanical, the data is available through DRO, and the playbook is repeatable. Start in the next 30 days, not at the next entitlement renewal.

Sources

• [IBM Maximo Application Suite 9.1 licensing guidance](https://www.ibm.com/docs/en/masv-and-l/cd?topic=suite-licensing-in-maximo-application-91)
• [AppPoints for customer-managed Maximo Application Suite](https://www.ibm.com/docs/en/masv-and-l/cd?topic=SSRHPA_cd%2Fappsuite%2Freference%2Fapp_points.htm)
• [What's new in Maximo Application Suite 9.0 (Data Reporter Operator)](https://www.ibm.com/docs/en/masv-and-l/cd?topic=new-in-90)
• [IBM Maximo Operator Catalog v9 (OpenShift 4.16 support and 4.12/4.13 end of support)](https://ibm-mas.github.io/cli/catalogs/v9-241205-s390x/)
• [Build a production-ready AI agent with watsonx Orchestrate](https://www.ibm.com/think/tutorials/build-production-ready-ai-agent-with-watsonx-orchestrate)
• [IBM Maximo Application Suite Releases information](https://www.ibm.com/support/pages/maximo-application-suite-releases-information-0)