Work Order Reporting in MAS 9: Rationalizing BIRT into KPI Manager (and When Cognos Wins)

🎯 Who this is for: Reporting teams, Maximo administrators, and maintenance managers who own a pile of BIRT work order reports and just got told "we're moving to Cognos" — and need to know what that actually means for the WO catalog on upgrade day.

Series: Part 5 of 6 — MAS 9 Work Order Operations: The Missing Pieces | Read time: 18 minutes

📖 Where Work Order Reporting Actually Stands in MAS 9

Somewhere in your MAS 9 upgrade plan there is probably a line item that reads something like "Reporting migration: BIRT → Cognos." And somewhere in a planning meeting, someone counted your BIRT reports, multiplied by an effort estimate, and produced a number that made everyone flinch.

Here is the calmer truth, scoped to work orders.

BIRT is not formally deprecated in MAS 9, and your existing work order reports still run. The strategic direction of the platform points toward Cognos Analytics and the Operational Dashboard — that is where IBM is investing — but a direction of investment is not a switch that turns BIRT off. Your WO Detail print report did not stop working the moment you logged into MAS 9.

So the mistake to avoid is not "we didn't move to Cognos fast enough." The mistake is treating your report catalog as a rebuild backlog — assuming every legacy work order report should move 1:1 into Cognos, and burning weeks recreating reports that never needed to be reports in the first place.

This post is the WO-scoped version of doing it right: rationalize the catalog first, then choose a target for each report — a KPI Manager card, a report that stays a report, or Cognos Analytics.

📊 The Old Reporting World vs. MAS 9

Reporting aspectMaximo 7.6MAS 9
Report engineBIRT, built inBIRT still runs; Cognos Analytics is the strategic direction
Report migrationN/ANo automatic BIRT-to-Cognos tool — recreation is manual
Operational monitoringBIRT portlets on Start CentersKPI Manager cards on the Operational Dashboard
Ad-hoc extractionLimited BIRT ad-hocAsynchronous CSV export via REST from WO list views
Complex multi-page reportsBIRTCognos Analytics (no KPI equivalent)

<aside>
💡 Key insight: Two facts sit side by side here and both are true. BIRT still works, and there is no automatic BIRT-to-Cognos migration tool. That combination is exactly why blind rebuilding is a trap — you would be doing expensive manual recreation work for reports that BIRT is still perfectly happy to run, or that shouldn't exist at all in MAS 9.
</aside>

🧭 The Rationalization Mindset

Rationalization means you do not ask "how do I rebuild this report?" You ask "what business need does this report serve, and what is the right MAS 9 surface for that need?" Sometimes the answer is a KPI card. Sometimes it's a queue. Sometimes it's Cognos. And sometimes the honest answer is "retire it."

Four rules keep the exercise disciplined:

  1. Keep operational, near-real-time consumption in dashboards and queues. If someone stares at a report every morning to see today's numbers, that is a dashboard job, not a scheduled report.
  2. Use formal reporting tools for scheduled distribution, print-ready output, audit packs, and multi-table analytics. That is where Cognos (or a kept BIRT report) earns its place.
  3. Retire reports that duplicate live queue or KPI behavior. If the Operational Dashboard already shows "overdue WOs" live, the weekly overdue-WO email report is dead weight.
  4. Validate BIRT support posture in your exact MAS version before deciding whether to keep, replace, or retire. Support posture moves across releases; check yours rather than assuming.

<aside>
💡 Key insight: Rule 3 is the one that saves the most effort and is skipped the most often. A large share of a legacy WO report catalog exists only because Start Centers couldn't show live operational data well. MAS 9's Operational Dashboard can — so a chunk of your catalog isn't a migration candidate, it's a retirement candidate.
</aside>

📋 A Work Order Report Triage Table

Before you touch a single report, sort your WO catalog by business need and assign each one a target. This is the triage IBM's own reporting guidance points to, narrowed to the work order reports you actually run:

WO report needPriorityRecommended target
Work Order Detail printCriticalKeep or rebuild in the format that best supports technicians, supervisors, and compliance reviews
WO Backlog by Site/CraftHighKPI Comparison card, or Cognos
PM Compliance MonthlyHighKPI Trend card, or Cognos
WO Completion SummaryHighKPI Value card, dashboard, or Cognos
Technician Labor ReportHighCognos or a governed export
Detailed WO Cost ReportHighCognos or another governed reporting tool
Work Order History by AssetMediumCognos, classic report, or REST export depending on audience
Open WO Aging ReportMediumWork Queue plus Table card, or Cognos if formal distribution is required
Emergency Work TrendMediumKPI Trend card
PM Forecast ReportMediumGraphical Scheduling view, export, or a formal report if needed

Notice what this table refuses to do: it never says "rebuild in Cognos" as a reflex. The Work Order Detail print — the report a technician tapes to a job packet, or a compliance reviewer signs off on — is Critical and is kept or rebuilt in whatever format serves that audience best. Meanwhile several High and Medium reports collapse into KPI cards or a queue and never become a formal report at all.

📈 KPI Manager as a Reporting Alternative

For simple WO reporting needs, KPI Manager plus the Operational Dashboard replaces a lot of BIRT. The mapping is clean enough to memorize, and it lines up directly with the card types you built in [Part 4](/blog/wo-missing-pieces-custom-wo-kpis):

  • Simple counts → KPI Value card. "Open WOs: 147." A single number a manager wants at a glance. That was never worth a report; it's a KPI.
  • Trends → KPI Trend card. "Monthly WO volume over the last 12 months." Anything where the shape over time is the point — WO volume, PM compliance, emergency work — is a Trend card.
  • Comparisons → KPI Comparison card. "Backlog by site," rendered as a bar chart. Site-vs-site, craft-vs-craft, crew-vs-crew comparisons become a Comparison card.
  • Detail lists → Work Queues card + Table card. "Overdue WOs, with details." A tabular list people act on becomes a live Work Queue plus a Table card, not a printed grid.
  • Complex multi-page reports → Cognos Analytics only. Multi-page layouts with charts, sub-reports, and formatting have no KPI equivalent. Do not force these into cards.

<aside>
💡 Key insight: The tell for "this belongs in a KPI card, not a report" is whether anyone acts on the number the moment they see it. A live count of open WOs drives a staffing decision on the spot — that's a card. A quarterly cost report that gets archived and referenced later is a document — that's Cognos or a kept report. Action-in-the-moment versus distribute-and-archive is the cleanest dividing line you have.
</aside>

🧩 The Decision Framework: KPI Card vs. Keep-as-Report vs. Cognos

Every work order report you own falls into one of three destinations. Run each report through these questions in order and stop at the first "yes."

Is it operational and acted-on-immediately?

Does someone consume this operationally, in near-real-time, and act on it immediately?
→ KPI Manager card on the Operational Dashboard. Counts, trends, comparisons, and actionable detail lists all live here. This is the largest bucket and the one people underuse.

Is it a live queue or KPI wearing a report's clothes?

Is it something the dashboard already shows live?
→ Retire it. Don't rebuild what the dashboard already shows live. This is the bucket people skip entirely.

Does it need to stay a formal document?

Does it need scheduled distribution, print-ready or audit-grade output, or multi-table analytics — but the layout is simple enough to reproduce as-is?
→ Keep or rebuild it as a report. The Work Order Detail print for job packets and compliance is the canonical example; BIRT still runs it today, so keeping is a legitimate choice while you validate your version's support posture.

Is it complex, multi-page analytics?

Is it a complex, multi-page WO report with charts, sub-reports, or heavy formatting, or does it join many tables for analytics?
→ Cognos Analytics. This is the only bucket where Cognos is genuinely required, and it's smaller than most upgrade plans assume. There is no automatic BIRT-to-Cognos converter, so recreate these deliberately and prioritize by usage.

<aside>
💡 Key insight: Run this framework before anyone estimates the reporting migration. The number that made everyone flinch was almost certainly "every BIRT report → Cognos." After triage, the Cognos column is only the last bucket — the complex, multi-page, must-be-a-document reports — and the estimate drops accordingly.
</aside>

🔬 A Worked Triage: One Team's WO Report Catalog

Frameworks click when you watch them run. Here's a maintenance-reporting team taking six real work order reports through the decision framework in one sitting.

  1. "Open WOs by status" (checked hourly by the supervisor). Acted on immediately, in near-real-time → KPI Value + Threshold Tile. Retire the BIRT report once the card is trusted.
  2. "Weekly overdue-WO email." The Operational Dashboard already shows overdue WOs live → Retire. This is the bucket that saves the most effort and nearly got rebuilt out of habit.
  3. "Monthly PM compliance." A trend leadership reviews → KPI Trend card for the dashboard; if it also needs to go into a formal monthly pack, a lightweight Cognos version for distribution.
  4. "Work Order Detail print" (taped to every job packet, signed for compliance). Print-ready, audit-grade, simple layout → Keep on BIRT for now, rebuild later if the version's support posture demands it. Critical — do not disrupt it casually.
  5. "Detailed WO cost report" (finance, multi-table, multi-page). Complex analytics joining WO, labor, materials, and GL → Cognos Analytics. The genuine Cognos case, and worth doing carefully.
  6. "Ad-hoc WO extract" (an analyst pulls it whenever asked). Not really a report at all → REST async CSV export. Wire it to the export path and stop maintaining a BIRT report for it.

Tally the outcome: of six reports, two retired, two became KPI/dashboard cards, one stayed on BIRT, and only one landed in Cognos. That ratio — a small Cognos column after triage — is the whole argument for rationalizing instead of rebuilding, made concrete.

<aside>
💡 Key insight: The most valuable output of a triage session isn't the "build in Cognos" list — it's the "retire" list. Every report you retire is effort you don't spend, forever. Teams that rebuild blindly never produce a retire list, which is exactly why their estimates are so frightening.
</aside>

📤 Getting Data Out: Export Paths

Rationalization also changes how people get data out, because a KPI card and a queue aren't a printed report you can email. MAS 9 gives work order reporting two governed export paths.

From the Operational Dashboard

  • CSV export of table and grid data — the tabular contents of a card, straight to a spreadsheet.
  • PNG / JPG export of chart visualizations — for a KPI Trend or Comparison chart you want to drop into a slide or a status pack.

From role-based applications

  • Asynchronous CSV export via the REST API from any WO list view. The request runs asynchronously, the paginated data is combined into a single download file, and you get one clean CSV instead of a page-by-page pull.

That REST async export is the quiet workhorse for teams who used to lean on ad-hoc BIRT reports for one-off data pulls. Because it runs through the REST API, it's the natural extraction path for automation — an RBA or an automation script that needs a governed WO extract can trigger the async export and pick up the combined file, no BIRT report required. (Part 6 covers that REST surface in full.)

⚠️ Edge Cases and Troubleshooting

SymptomWhat it meansWhat to do
A report doesn't fit any bucket cleanlyIt's serving two needs at once (operational glance + formal archive)Split it: a KPI card for the glance, a kept/Cognos report for the archive
A BIRT report errors after upgradeIt references a removed surface (a Work Center) or an old labelRepoint it to the classic app/object, or retire it if a queue/KPI now covers the need
The Cognos rebuild estimate is still hugeTriage wasn't actually run — everything defaulted to CognosRe-triage; most of the catalog is KPI cards or retirements, not Cognos
A CSV export is enormous or times outPulling an unfiltered WO list viewFilter the list view first; the async export combines pages, but scope still matters
Two "the same" reports show different numbersDifferent underlying queries, same titleStandardize one definition (same governance point as KPIs in Part 4)
Users keep asking for the old printed reportThe KPI card replaced it before they trusted itRun the card and the report in parallel for a sprint, then retire the report

The recurring theme: reporting problems in MAS 9 are usually classification problems, not tooling problems. A report that "won't migrate cleanly" is almost always one that was doing two jobs and needs to be split, or one that should have been retired.

🧠 Why It Works This Way

IBM's reporting stance in MAS 9 looks ambiguous until you see the intent behind it: don't break what works, but stop using heavy reports for jobs a live surface does better.

Leaving BIRT running — rather than forcing an off switch — is a deliberate risk-reduction choice. Work order reports are woven into compliance packets, job packets, and finance processes; ripping them out on a date would create real operational harm for no functional gain. So BIRT keeps running, and you migrate on your timeline, by business need, not on a vendor deadline.

At the same time, the Operational Dashboard and KPI Manager exist precisely because a huge fraction of "reports" were never really reports — they were operational monitors that BIRT and Start Centers happened to be the only tools for. Give teams a live, glanceable, color-coded dashboard and those "reports" reveal their true nature: they belong on a screen people watch, not in a document people generate. That's why the largest triage bucket is KPI cards and retirements, and the smallest is Cognos.

The net design principle: match the surface to how the information is actually consumed. Watched-in-the-moment → dashboard. Already-live → retire. Distributed-and-archived → report or Cognos. Rationalization is just applying that principle report by report.

🔧 Practical Notes Before You Roll This Out

  • Inventory before you migrate. You cannot rationalize a catalog you haven't listed. Pull the full WO report inventory, tag each report by actual usage, and only then run the decision framework — priority by real usage beats priority by who shouts loudest.
  • Don't turn BIRT off to prove a point. BIRT still runs; keeping low-priority WO reports on BIRT during the transition is a valid phased strategy, not a failure to modernize. Validate your version's support posture and plan around it.
  • Build the KPI cards first, retire second. Stand up the Operational Dashboard cards that replace the operational reports, let people live on them for a sprint, then retire the duplicate reports. Retiring before the replacement is trusted is how you end up rebuilding reports under pressure.
  • Produce a retire list on purpose. It's the highest-value output of triage and the one blind rebuilds never generate.
  • Size the Cognos column honestly. After triage, only the complex multi-page bucket needs Cognos. Estimate the reporting migration off that column — not off the full catalog — and remember every one is a manual rebuild.
  • Point automation at the REST async export. For scripted or scheduled WO data extracts, the asynchronous single-file CSV export is the governed, version-safe path. Wire new extraction jobs to it instead of resurrecting ad-hoc BIRT reports.

Key Takeaways

  • BIRT is not formally deprecated in MAS 9 and your work order reports still run — the strategic direction is Cognos and the dashboard, but that's investment direction, not an off switch. Validate the support posture in your exact version.
  • The upgrade mistake is treating the report catalog as a rebuild backlog. Classify each WO report by business need first, then pick the target — and remember there is no automatic BIRT-to-Cognos migration tool.
  • KPI Manager replaces many WO reports: counts → KPI Value, trends → KPI Trend, comparisons → KPI Comparison, detail lists → Work Queues + Table. Retire reports that merely duplicate a live queue or KPI.
  • Cognos Analytics is only for the last bucket — complex, multi-page, print-ready WO reports with no KPI equivalent. It's a smaller column than upgrade plans assume.
  • Export paths: CSV and PNG/JPG from the Operational Dashboard, and asynchronous single-file CSV export via REST from any WO list view — the natural extraction path for RBAs and automation.

References

Series Navigation

Previous:Part 4 — Building Custom Work Order KPIs
Next:Part 6 — Work Order Integration Changes

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