Reporting Options in MAS 9: Cognos, BIRT, Dashboards, and Beyond
🎯 Who this is for: Maximo administrators, reporting analysts, and IT leads planning the reporting side of a MAS 9 upgrade who need one honest map of every tool available — not a single "here's how to use Cognos" tutorial.
Read time: 19 minutes
📖 There Isn't One Reporting Answer in MAS 9 — There Are Four
Ask three people on a MAS 9 upgrade team "what's our reporting strategy?" and you'll get three different answers, and all three will be partially right. One will say "we're moving everything to Cognos." Another will say "the dashboards handle most of it now." A third, usually someone who has already looked at the Cognos entitlement paperwork, will say "we need Power BI or something bigger, three users isn't enough."
They're all describing one piece of the same picture. MAS 9 does not have a single reporting tool the way Maximo 7.6 had BIRT as the report engine. It has a four-tier reporting stack, and the upgrade mistake is treating any one tier as the whole answer:
- BIRT — the legacy engine, still running, not where new investment goes.
- Operational Dashboard + KPI Manager — the native operational monitoring layer, free with MAS.
- Cognos Analytics — the native formal BI layer, entitled but capacity-limited.
- Beyond — watsonx.data, Databricks, Power BI, and Tableau, for when you outgrow tier 3.
This post maps all four, with the real numbers, the real field names, and the real ceiling on each one, then gives you a decision framework for routing your actual report catalog across them. If you specifically own work order reporting, our companion piece — Work Order Reporting in MAS 9: Rationalizing BIRT into KPI Manager — takes the WO catalog through the same triage in much finer detail. Think of that post as the deep dive into tiers 1–2 for one report domain; this post is the platform-wide map across all four tiers and every domain — assets, inventory, purchasing, safety, and beyond.
🗺️ The Four-Tier MAS 9 Reporting Stack
| Tier | Tool | Best for | Native cost | Ceiling |
|---|---|---|---|---|
| 1 | BIRT | Legacy print/audit reports still in daily use | Included, no new investment | No new features; strategic direction points away from it |
| 2 | Operational Dashboard + KPI Manager | Near-real-time operational monitoring, glanceable numbers | Included with MAS | No ad-hoc exploration, no cross-system joins, limited personalization |
| 3 | Cognos Analytics | Formal, scheduled, print-ready, and ad-hoc BI against the Maximo DB | Included entitlement, 3 authors | Only 3 report authors; scoped to the Maximo database only |
| 4 | Beyond (watsonx.data / Databricks + Power BI / Tableau) | Cross-system analytics, unlimited self-service BI, custom ML | Separate platform, separate cost | Real infrastructure and governance investment |
💡 Key insight: Notice the ceiling column. Every tier's limitation is structural, not a bug you can configure around. BIRT's ceiling is that IBM isn't building it forward. The dashboard's ceiling is scope — it was never meant to be a BI tool. Cognos's ceiling is a hard, licensed number: three. And tier 4's "ceiling" is really the opposite — it exists precisely because it doesn't have the other three tiers' ceilings, at the cost of standing up real infrastructure. Once you see the stack this way, the question for every report stops being "which tool is best" and becomes "which ceiling does this report actually need to clear."
📄 Tier 1: BIRT — Still Running, Not Forever
BIRT (Business Intelligence and Reporting Tools) was the built-in report engine for Maximo 7.6 and every version before it, and it did not disappear on upgrade day. MAS 9.1 ships with BIRT 4.16 support during the transition period, and for most established Maximo shops that means well over 100 standard and custom BIRT reports keep running exactly as they did before — work order detail prints, PO printouts, RFQ PDFs, asset history reports, and whatever else accumulated over a decade of use.
What changed is the direction of investment. IBM still keeps the engine current — Manage 9.1 supports BIRT 4.16 and Manage 9.2 supports BIRT 4.21 — but that is maintenance of the runtime, not new reporting capability; the new features in every release since MAS 8.9 have landed in the Operational Dashboard, KPI Manager, and Cognos Analytics. That is not an off switch. It is a signal about where five years of new features will land, and it will not land on BIRT.
What this means practically:
- Do not treat your BIRT catalog as an emergency rebuild backlog. Nothing breaks the day you go live on MAS 9.
- Do treat new investment as a one-way door. Every new report request from this point forward should default to Cognos, a KPI Manager card, or an export path — not a new BIRT report, because you'd be building on a platform IBM has told you it is not extending.
- Validate BIRT's exact support posture in your specific MAS version before you plan a multi-year retention strategy. Support windows move release to release; "still works in MAS 9.1" is not a permanent guarantee across every future MAS release.
💡 Key insight: The report migration mechanics IBM documents for MAS upgrades cover moving BIRT report components forward safely from one Maximo/MAS release to the next during a database migration — a version-to-version carry-forward, not a BIRT-to-Cognos conversion. Don't confuse the two: your BIRT reports surviving an upgrade is not the same claim as an automatic path into Cognos. There is still no automatic BIRT-to-Cognos migration tool (see Tier 3).
📊 Tier 2: Operational Dashboard + KPI Manager — The Operational Layer
The Operational Dashboard is IBM's strategic replacement for the Start Center — a card-based, Carbon Design System landing page introduced in MAS 8.9 and meaningfully expanded through 8.11, 9.0, and 9.1. Unlike a report, it's meant to be watched, not generated and archived.
Card Types, and What Each MAS Release Added
| Card type | Introduced | What it shows |
|---|---|---|
| KPI Value | MAS 8.x | A single KPI number with a trend indicator |
| KPI Trend (was KPI Chart) | MAS 8.x | A KPI's value over time as a line chart |
| KPI Comparison | MAS 8.x | Up to nine KPIs compared as a line, bar, pie, or donut chart |
| Table | MAS 8.x | Tabular data from a chosen data source, configurable columns and row count |
| Favorites | MAS 8.x | Quick links to frequently used apps or records |
| Quick Actions | MAS 8.x | One-click buttons for common tasks (create WO, create location) |
| Work Queues | MAS 9.0 | Live counts and drill-down into a configured work queue |
| External Content | MAS 9.0 | Embeds any external URL — third-party BI, internal web apps — directly on the dashboard |
| Threshold Tile | MAS 9.0.2 / 9.1 | Color-coded tile against defined thresholds (functionally close to a Value card at introduction, matured through 9.1) |
MAS 9.0 also added multi-dashboard support (multiple tabs, similar to Start Centers) and public dashboards bound to a security group, which is what makes a shared departmental dashboard possible instead of every user rebuilding the same cards individually.
MAS 9.1's headline reporting change isn't a new card type at all — it's a connection. You can now link a KPI Value card directly to the Work Queue behind it, so clicking the number takes you straight to the records driving it instead of forcing a separate navigation step into a list view. That single change is what turns the dashboard from "pretty charts" into an action surface: a manager sees "Overdue WOs: 34" and is one click from the actual 34 work orders, not a second search.
KPI Manager: Building the Numbers Behind the Cards
KPI Manager is the application that defines what those KPI cards actually compute. Each KPI is built from:
- A Select and Where clause against a chosen Maximo object — the query defining the number.
- A Calculation Type of
DECIMALorPERCENTAGE. - Caution At and Alert At threshold fields, which drive the green/yellow/red color-coding you see on the card.
- Optional Cron Task scheduling, which captures historical KPI values automatically so KPI Trend cards have something to plot.
- As of MAS 9.1, the ability for a KPI service to return JSON from an external API, not only from a Maximo query — a small but real opening toward pulling in non-Maximo numbers without a full lakehouse project.
Out of the box, MAS ships KPIs for Emergency Work Orders, PM Compliance, Overdue Work Orders, Work Order Backlog, MTBF, MTTR, Asset Downtime, and Planned-vs-Unplanned Work Ratio — enough to stand up a credible Maintenance Manager dashboard on day one before you author a single custom KPI.
KPI Manager — new custom KPI definition
Object: WORKORDER
Select: COUNT(*)
Where: STATUS = 'INPRG' AND SCHEDSTART < :TODAY
Calculation Type: DECIMAL
Caution At: 15
Alert At: 25
Refresh: Cron Task, every 60 minutes
Card: KPI Value → linked Work Queue: "Overdue In-Progress WOs" (MAS 9.1+)💡 Key insight: A large share of what looks like "reporting demand" in a legacy Maximo shop is actually monitoring demand that BIRT and Start Centers happened to be the only available tools for. If a number gets checked every morning and acted on immediately, it was never really a report — it was a KPI wearing a report's clothes. Move those into KPI Manager first; you'll be surprised how much of the catalog evaporates before Cognos even enters the conversation.
What the dashboard is explicitly not: IBM's own MAS 9 guidance is blunt about the boundary — Operational Dashboards do not do ad-hoc data exploration, complex cross-object joins, or statistical analysis, they do not replace Cognos or Power BI for formal reporting, and they do not support data sources outside MAS (short of the External Content card embedding an outside URL, or a JSON-returning KPI service). And as of MAS 9.1, dashboards still cannot be assigned to individual users or security groups the way personalized Start Center views can — several Start Center behaviors (quick-insert during ticket-template application, work-queue graphics, attributes from related tables, a true Workflow Assignments equivalent) simply have no dashboard equivalent yet. Most organizations run both side by side rather than treating the dashboard as a full Start Center replacement.
📈 Tier 3: Cognos Analytics — The Formal BI Layer
When a reporting need genuinely can't live on a card — scheduled distribution, print-ready audit output, multi-page layouts with sub-reports, or true ad-hoc cross-table exploration — MAS 9 hands you off to Cognos Analytics, deployed either alongside MAS on Red Hat OpenShift via Cloud Pak for Data, or as a standalone Cognos instance connected to the Maximo database.
The Entitlement: Three Authors, No Concurrent Option
This is the number that surprises the most teams mid-planning: the MAS 9 Cognos entitlement restricts report *authoring* — creating and editing reports and dashboards — to three named administrative users, and there is explicitly no concurrent-use option to stretch that pool further. Everyone else who only needs to run and view existing reports is added to the COGNOSUSERS security group, which is a much larger, effectively unrestricted population by comparison — the constraint is specifically on who can build, not who can view.
| Cognos role | Who | Limit |
|---|---|---|
| Report/dashboard author | Named administrative users | 3, no concurrent option |
| Report/dashboard viewer | Anyone in the COGNOSUSERS security group | Effectively unlimited |
If your organization has more than three people who need to build or maintain formal reports — a common situation once you count reporting analysts across finance, operations, and compliance — you either purchase additional Cognos licensing outside the MAS entitlement, or route that authoring load to Tier 4.
What You Actually Get, and What Changed from BIRT
| Reporting aspect | BIRT (Maximo 7.6) | Cognos Analytics (MAS 9) |
|---|---|---|
| Report designer | BIRT Report Designer (Eclipse-based) | Cognos Analytics drag-and-drop authoring |
| Migration path | N/A | None — every BIRT report is manually recreated |
| Ad-hoc reporting | Limited | Full ad-hoc query and exploration |
| Dashboards | BIRT portlets on Start Centers | Cognos dashboards + Operational Dashboard |
| Distribution | Manual | Scheduled report distribution via email |
| AI assistance | None | Cognos Assistant: natural-language report/dashboard authoring (newer Cognos releases) |
| Data scope | Maximo DB (plus whatever BIRT could reach) | Maximo DB only, by default |
There is still, as of this writing, no automatic BIRT-to-Cognos migration tool. Report logic, queries, layouts, and formatting are manually redesigned in Cognos — a real, and often underestimated, effort for shops with a large legacy catalog. That's exactly why Tier 1's guidance matters: don't rebuild everything, triage first (see the decision framework below).
Newer Cognos Analytics releases add a genuinely different capability worth knowing about even if your immediate MAS entitlement is scoped to Maximo: Cognos Assistant, which lets a user describe a dashboard in natural language — "create a dashboard showing the factors affecting downtime" — and have Cognos generate the query, chart selection, and layout. It's the same conversational-analytics pattern MAS's own AI Service brings to Maximo Assistant, arriving independently on the reporting side.
Configuring the Integration: What an Admin Actually Touches
Cognos Analytics connects to Maximo through a defined set of Maximo system properties and a dedicated MXCOGNOS end point. You won't hand-configure most of this from intuition — knowing the property names in advance saves real setup time:
# Maximo system properties that govern the Cognos Analytics integration
mxe.report.cognos.serverURL # Cognos dispatcher/gateway URL — launches reports & admin
mxe.report.cognos.cpdnamespace # CPD project namespace, e.g. ibm-cpd
mxe.report.cognos.content.store.package.location # Team Content folder, e.g. PUBLIC
mxe.report.cognos.datasource # Cognos data source name for the Maximo DB, e.g. MXDB
mxe.report.cognos.db.schemaName # Maximo DB schema tied to that data source
mxe.report.cognos.namespace # Cognos auth namespace (users/groups/roles), typically "jwt"
# MXCOGNOS end point properties (used for publishing framework packages)
AUTHENTICATION_METHOD = CPD
DATA_SOURCE_NAME = MXDB
NAMESPACE_ID = jwt
PROJECT_BASE_DIR = /opt/ibm/cognos/analytics/projectsThe deployment itself runs through Cloud Pak for Data: create a platform connection (Cognos Analytics content store, backed by Db2, Oracle, or SQL Server — not Db2 Warehouse), provision a Cognos Analytics instance from the CPD services catalog, then add users and publish your Maximo object structures as a Cognos metadata package so report authors have something to build against. Every Maximo user who touches Cognos, author or viewer, has to land in the COGNOSUSERS security group first — that mapping is the actual access-control lever, not the Cognos-side user list alone.
💡 Key insight: The three-author ceiling is a licensing constraint, not a technical one — Cognos itself can support far more authors with additional licensing. That distinction matters when you're deciding between "buy more Cognos seats" and "stand up a Tier 4 self-service platform": if your only problem is author headcount and your data stays inside Maximo, buying seats is simpler. If you also need cross-system data Cognos can't reach, Tier 4 solves both problems at once.
🚀 Tier 4: Beyond — When Three Cognos Authors Isn't Enough
Every ceiling in tiers 1–3 is structural, and MAS 9 doesn't pretend otherwise. When a reporting need clears past what BIRT, the dashboard, and a three-author Cognos entitlement can serve, the honest next step is a lakehouse analytics platform sitting alongside MAS — not replacing its native reporting, extending it.
| Need that outgrows Tier 3 | What Tier 4 adds |
|---|---|
| More than 3 report authors | Unlimited self-service BI seats via Presto/Db2 SQL, Power BI, or Tableau |
| Cross-system analytics (ERP, IoT, weather, financial data) | A shared Iceberg or Delta lakehouse joining Maximo with everything else |
| Custom ML beyond Predict's fixed model catalog | Full data-science notebooks, Spark, custom model training |
| Enterprise-wide data governance | A catalog and lineage layer spanning every system, not just Maximo |
IBM's own positioning is direct about where the line sits: Cognos Analytics reporting is for management information and BI against the Maximo database specifically — it is not designed to replace a full data platform, and it does not join Maximo with external systems. Two concrete paths exist depending on how IBM-standardized your stack already is:
- watsonx.data — IBM's own open, hybrid data lakehouse, built on Apache Iceberg. The natural choice if you're already invested in Maximo, Cognos, OpenShift, and watsonx.ai — same vendor, same governance fabric (IBM Knowledge Catalog), same AI layer via Maximo's AI Service bridge. See our MAS-WATSONX-DATA series for the full build-out, including how it feeds unlimited self-service BI through Presto, Db2, Power BI, and Tableau where Cognos tops out at three authors.
- Databricks — the deeper-MLOps, widest-third-party-ecosystem choice, especially if your organization is already running Databricks elsewhere. Our MAS-DATABRICKS series covers the equivalent architecture on that platform.
Both series make the same core point from their own angle: keep MAS native for what it does well — Health scoring, Monitor's real-time alerting, Predict's quick-start models, Assistant's Q&A, and Cognos reporting when three authors and Maximo-only data are genuinely enough — and add the lakehouse tier only for what MAS structurally cannot do: cross-system joins, unlimited self-service authors, and custom ML.
💡 Key insight: Don't reach for Tier 4 to solve a Tier 2 problem. If the actual complaint is "too many reports and not enough dashboard cards," that's a KPI Manager and Cognos-triage conversation, not a lakehouse project. Tier 4 earns its cost when the blocker is structural — author count, cross-system joins, or ML — not when better use of the free tiers would have solved it.
🧭 The Decision Framework: Routing Any Report to Its Tier
Run every report or reporting need you own through these questions in order, and stop at the first "yes."
Is it operational and acted-on-immediately, using only Maximo data?
→ Tier 2 — KPI Manager card on the Operational Dashboard. Counts → KPI Value. Trends → KPI Trend. Multi-KPI comparisons (up to nine) → KPI Comparison. Threshold-driven glances → Threshold Tile. Actionable lists → Work Queues, optionally linked from a KPI Value card (MAS 9.1+).
Is it a live queue or KPI wearing a report's clothes?
→ Retire it. If the dashboard already shows the number live, the scheduled BIRT/Cognos report duplicating it is pure overhead.
Does it need scheduled distribution, print-ready/audit-grade output, or ad-hoc multi-table analytics — and does it use only Maximo data?
→ Tier 3 — Cognos Analytics, if you have author capacity among your three named authors; otherwise keep it on BIRT while you triage, since BIRT still runs and there's no forced cutover date.
Does it need data Cognos can't reach, more than three authors, or real data science?
→ Tier 4 — watsonx.data or Databricks, feeding Power BI, Tableau, or Cognos itself from a cross-system foundation.
💡 Key insight: Notice this framework never says "migrate everything to Cognos" or "everything modern goes to a lakehouse." The two biggest planning mistakes run in opposite directions — over-investing in Cognos rebuilds for reports that were really KPI cards, and reaching for a lakehouse platform to solve a three-author licensing problem that more Cognos seats would fix just as well. The framework's job is to stop both.
🔬 A Worked Triage: One Organization's Reporting Catalog, All Four Tiers
Here's a maintenance and reporting team routing seven real reports spanning multiple domains through the framework in one sitting — deliberately not just work orders, since that ground is already covered in depth by our companion post.
- "Open WOs by status," checked hourly by the shift supervisor. Acted on immediately → Tier 2, KPI Value + Threshold Tile, linked to its Work Queue in MAS 9.1.
- "Weekly overdue-PM email," Preventive Maintenance team. The dashboard already shows PM compliance live → Retire.
- "Monthly inventory turnover by storeroom," Purchasing. A trend, reviewed monthly, occasionally exported for a leadership pack → Tier 2 KPI Trend for the dashboard, Tier 3 Cognos for the monthly export version.
- "Asset warranty and compliance audit report," signed quarterly by a compliance officer. Print-ready, audit-grade, simple layout, currently on BIRT → Keep on BIRT for now, migrate to Cognos only when the author queue allows or BIRT's support posture in your version demands it.
- "Cross-site spend vs. budget by GL code," Finance. Multi-table join across Maximo purchasing data and an external ERP GL feed → Cognos can't reach the ERP side at all → Tier 4. This is the report that finally justifies the lakehouse conversation.
- "Safety incident trend with weather correlation," EHS. Needs Maximo incident data joined against an external weather feed for a genuine root-cause analysis → Tier 4, and a strong candidate for the custom-ML tier once the join exists.
- "Ad-hoc parts usage extract," an analyst pulls whenever asked. Not really a report → REST asynchronous CSV export directly from the relevant list view, no report tool needed at all.
Tally: one retired, two on KPI cards, one staying on BIRT, one on Cognos, two on a lakehouse tier, one off the report-tool track entirely. That spread — not "everything to Cognos," not "everything to a lakehouse" — is what a genuinely triaged catalog looks like once you stop assuming every report needs the same destination.
⏱️ What Changed When: A MAS 8.9 → 9.1 Reporting Timeline
| Release | Reporting-relevant change |
|---|---|
| MAS 8.9 | Operational Dashboard introduced as the Start Center's strategic successor; core KPI Value, KPI Trend, KPI Comparison, Table, Favorites, and Quick Actions cards |
| MAS 8.11 | Dashboard maturing; Cognos Analytics 11.2.4 commonly deployed alongside this release in practitioner environments |
| MAS 9.0 | Multi-dashboard tabs; public dashboards bound to a security group; Work Queues and External Content cards added; KPI cards gain "Available Actions" (jump to KPI Manager/Viewer, refresh) |
| MAS 9.0.2 | Threshold Tile card introduced |
| MAS 9.1 | KPI services can return JSON from external APIs; KPI Value cards can link directly into their Work Queue for one-click drill-through; BIRT 4.16 support retained during transition |
💡 Key insight: Read this timeline as evidence, not trivia. Every release since 8.9 added capability to Tier 2, not Tier 1 — that's the concrete proof behind "BIRT isn't where investment goes," independent of anything IBM says in a roadmap slide.
⚠️ Edge Cases and Troubleshooting
| Symptom | What it usually means | What to do |
|---|---|---|
| A report doesn't fit cleanly into one tier | It's serving two audiences at once — an operational glance and a formal archive | Split it: a KPI card for the glance, a kept/Cognos report for the archive |
| Cognos author capacity is maxed at 3 | You've reached the entitlement's structural ceiling | Buy additional Cognos licensing for Maximo-only needs, or route new authoring demand to Tier 4 if cross-system data is also needed |
| A viewer can't see a Cognos report | They're missing from the COGNOSUSERS security group | Add them to COGNOSUSERS; viewer access, unlike authoring, isn't capped at 3 |
| A BIRT report errors post-upgrade | It references a removed surface (a retired Work Center) or stale labeling | Repoint it to the current app/object, or retire it if a KPI/queue now covers the need |
| The Cognos rebuild estimate looks enormous | The catalog was never triaged — everything defaulted to "rebuild in Cognos" | Re-run the decision framework; most catalogs split across all four tiers, not just Cognos |
| Threshold Tile shows the same output as a Value card | Expected at introduction (MAS 9.0.2) — the two cards started functionally close and matured separately through 9.1 | Confirm your MAS version's card behavior before assuming it's a bug |
| Users keep requesting the old printed report after a KPI card replaces it | Trust hasn't transferred yet | Run the card and the legacy report in parallel for a sprint, then retire the report |
🧠 Why the Platform Is Built This Way
IBM's reporting stance in MAS 9 looks scattered — four tools instead of one — until you see the design intent: match the reporting surface to how the information is actually consumed, and don't force every need through the same door.
Leaving BIRT running, rather than forcing a hard cutover, is a deliberate risk-reduction choice: work order prints, purchase order printouts, and audit packs are woven into compliance and finance processes that can't tolerate a forced rebuild on a vendor's calendar. Building the Operational Dashboard and KPI Manager as free, native capability acknowledges that a large share of what looked like "reporting demand" for a decade was really operational monitoring that had no better home than a scheduled report. Capping Cognos authorship at three, rather than bundling unlimited seats, keeps the native entitlement genuinely free while being explicit that formal, scale-out BI is a deliberate purchase decision, not an assumed default. And treating watsonx.data/Databricks as a complementary tier — not a MAS replacement — reflects the honest limit of what any single EAM platform's native reporting was ever going to do: MAS was built to run assets and work, not to be a general-purpose data platform for your whole enterprise.
The net principle: watched-in-the-moment data belongs on a dashboard, distributed-and-archived data belongs in Cognos or BIRT, and cross-system or high-author-count analytics belongs in a lakehouse tier built for exactly that job. Everything in this post is that principle applied tier by tier.
🔧 Practical Notes Before You Plan the Reporting Migration
- Inventory before you route anything. You cannot triage a catalog you haven't listed. Pull every BIRT report, tag it by actual usage and audience, and only then apply the decision framework.
- Count your would-be Cognos authors before you assume Cognos solves everything. If you have more than three people who genuinely need to build reports, that headcount alone may justify a Tier 4 conversation even before cross-system data enters the picture.
- Map COGNOSUSERS deliberately. Viewer access isn't capped, but it also isn't automatic — plan the security-group mapping as part of the rollout, not as a post-launch support ticket queue.
- Build the KPI cards first, retire the underlying report second. Let a card earn trust for a sprint before you turn off what it replaces.
- Size your Cognos rebuild estimate off the triaged catalog, not the full one. After routing, the Cognos-bound column is usually much smaller than the report count that first alarmed the project team.
- Treat Tier 4 as a deliberate infrastructure decision, not a reflex. It solves real structural ceilings — author count, cross-system joins, custom ML — and is worth the investment when you hit one. It is not the answer to "we have too many BIRT reports."
Key Takeaways
- MAS 9 reporting is a four-tier stack, not a single tool: BIRT (legacy, still running), Operational Dashboard + KPI Manager (native operational monitoring), Cognos Analytics (native formal BI, 3-author entitlement), and Beyond (watsonx.data/Databricks self-service BI).
- There is no automatic BIRT-to-Cognos migration tool. Route reports through triage by business need first — a large share of any legacy catalog becomes a KPI card or a retirement, not a Cognos rebuild.
- Cognos Analytics is entitled to exactly three named report authors with no concurrent option; everyone else gets viewer access through the COGNOSUSERS security group, which has no such cap.
- MAS 9.1's real dashboard upgrade is drill-through, not a new card type — linking a KPI Value card straight to its Work Queue turns monitoring into action in one click.
- Reach for watsonx.data or Databricks only when you hit a structural ceiling — more than three report authors, cross-system data Cognos can't reach, or custom ML — not as a reflex for "too many reports."
References
- IBM Maximo Application Suite Documentation
- Installing Cognos Analytics — IBM Maximo Manage Documentation
- Report Migration — IBM Maximo Application Suite Documentation
- Maximo Manage – Analytics (Maximo Secrets)
- Operational Dashboard (MAS 9.0) (Maximo Secrets)
- MAS 9.1 Dashboards: From KPI to Action in One Click (LinkedIn, Maximo Minute)
- Cognos Analytics on CP4D with Maximo Application Suite (Interloc Solutions)
Related reading: Work Order Reporting in MAS 9: Rationalizing BIRT into KPI Manager for the WO-scoped deep dive · Why watsonx.data: IBM's Open Lakehouse Answer for Maximo and Why Your Maximo Data Belongs in a Lakehouse for Tier 4 in full.
About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.
Published by TheMaximoGuys | July 2026
Surendra Katta
Venkat Achanta