Airports, Rail, and the New Asset Lifecycle: Three 2026 Maximo Case Studies Where Reliability and Operations Converge

The 2026 Maximo case-study signal is not in the "we deployed Maximo and our backlog went down" stories. Those are old. The signal is in the industries where the platform is being used to connect maintenance, fleet operations, inspections, and operational visibility in a single model — where the question is no longer "did the WO close" but "did the asset make its operational window."

This article walks through three of the most useful 2026 case studies: a regional airport operator consolidating ground support equipment (GSE) and facilities on Maximo, a Class II freight rail operator using Maximo Health and Predict to drive a condition-based maintenance program, and a public-sector transit operator using Maximo Mobile and the Reliability Strategies library to operationalize an RCM program at scale.

Case 1: Regional airport operator — GSE, terminals, and operational turnaround

The operator runs a mid-size regional airport with eight commercial gates, a cargo apron, and a general aviation ramp. The asset base is a mix of facilities (terminals, jet bridges, HVAC, baggage handling) and operational fleet (GSE: pushback tractors, belt loaders, ground power units, passenger buses, baggage tugs, tow tractors). The fleet is ~340 powered units and ~1,200 facility assets.

The problem

The airport's maintenance operation was split. Facilities ran on a legacy CMMS. GSE was tracked on a spreadsheet. Inspections were paper-based. The cargo operator, the airline tenants, and the airport's own operations team all had different views of "is this asset available."

The operational consequence was visible: aircraft turnarounds were being delayed by GSE availability issues that the maintenance team could not see in time. A belt loader failure on a cargo flight meant a 40-minute delay and a missed cargo connection. A GPU that was due for a PM was the GPU that was needed for the next gate.

What they built

The operator deployed Maximo Application Suite 9.1 on a managed cloud (IBM Cloud / ROKS), with Manage as the core, plus Monitor for live operational visibility, Health for asset scoring, Mobile for the field force, and Visual Inspection for the security and safety inspection workflow.

The configuration was a single Maximo instance, with:

• GSE and facilities in the same asset hierarchy. A single asset record per piece of equipment, with classification (powered GSE, facility asset, vehicle, structure) driving the PM, inspection, and KPI logic.
• Location hierarchy modeling the airport operational model. Terminal → gate → apron → stand, with assets placed at the operational location (not the administrative location). A belt loader is "at Gate 4," not "in the GSE bay."
• Work order and PM generation tied to operational triggers. A PM is generated based on a metered trigger (engine hours for GSE, runtime hours for HVAC) or a calendar trigger (annual inspection for jet bridges, quarterly safety inspection for fueling areas).
• Maximo Health scoring on the critical assets. The GSE that drives the turnaround (pushback tractors, belt loaders, GPUs) is scored on a combination of contributors: engine hours, maintenance cost, age, sensor data (where available), and failure history. The health score drives a daily prioritized work list.
• Maximo Mobile for the field force. Technicians carry ruggedized tablets with the Mobile app. They see the day's work, scan the asset QR code, complete the work, record labor and materials, and close the WO. The data is available to operations in real time.
• Maximo Visual Inspection for security and safety inspections. The technician takes a photo of the asset condition, the MVI model classifies the defect (corrosion, damage, wear), and the inspection record is stored against the asset.

The operational outcome

The KPI that matters is turnaround delay minutes attributable to GSE availability. Before Maximo, this was not measured. The airport's operations team has now been tracking it for 14 months. The first three months showed the baseline (an average of 18 minutes of delay per flight attributable to GSE). After 14 months on Maximo, the average is 6 minutes per flight. The savings are split between improved PM compliance (PMs are no longer being missed), faster response to in-shift failures (the work list is prioritized by health score), and better visibility for the airline tenants (the cargo operator can see the GSE status in real time and adjust their operation).

The KPI that matters for the maintenance team is PM compliance rate. Before Maximo, PM compliance was ~78% (the percentage of PMs that were completed on time). After 14 months on Maximo, PM compliance is 94%. The improvement is driven by the metered-trigger PM generation (PMs are no longer being missed because the meter is being read) and the Mobile execution (the technician closes the WO in the field, the PM record updates immediately).

The KPI that matters for finance is cost per asset per year. The first full year on Maximo showed a 12% reduction in cost per asset, driven by the elimination of duplicate data entry, the reduction in emergency callouts, and the better warranty tracking (the warranty status is now visible on the asset record, and the team is claiming warranty repairs that were being missed).

What the practitioner takes away

The pattern is a single Maximo instance, with the asset hierarchy modeling the operational model (not the administrative model), the PM and WO generation tied to operational triggers, and the field force on Mobile. The integration of Manage, Health, Mobile, and Visual Inspection is what closes the loop. None of the individual components is novel. The integration is the case study.

Case 2: Class II freight rail — condition-based maintenance on a 1,800-mile network

The operator is a Class II freight railroad with 1,800 miles of track, 38 locomotives, 1,200 freight cars, and ~2,400 miles of wayside assets (signals, switches, grade crossings, defect detectors). The maintenance operation is decentralized across 12 maintenance-of-way (MOW) territories and 3 locomotive servicing points.

The problem

The railroad's legacy maintenance program was time-based: every asset had a calendar PM, and the calendar drove the work. The result was over-maintenance on assets that did not need it and under-maintenance on assets that did. The signal was in the failure data: 62% of locomotive failures in 2024 were in assets that had passed their most recent PM within the previous 90 days. The calendar was not protecting them.

The cost was visible: $4.2M annually in unscheduled locomotive maintenance, $1.8M annually in emergency MOW callouts, and a customer-facing on-time performance metric that was 6 percentage points below target.

What they built

The operator deployed Maximo Application Suite 9.1 on a customer-managed OpenShift cluster, with Manage as the core, plus Monitor, Health, Predict, and Mobile. The configuration was deliberately focused on the highest-cost failure modes:

• Locomotive engine health scoring using Maximo Health, with contributors including engine hours, fuel consumption trend, oil analysis results, vibration sensor data, and maintenance cost history. The health score is updated daily and surfaced on a locomotive-status board that the operations team and the locomotive shop foreman both use.
• Predict models on the highest-failure locomotive subsystems (traction motors, alternators, air compressors, brake systems) using Maximo Predict. The models are trained on 5 years of failure history and the corresponding sensor data. The model output is a probability-of-failure-in-the-next-30-days score, surfaced on the asset record and on the locomotive-status board.
• Condition-based PM generation triggered by a combination of meter readings (engine hours, traction motor hours, brake applications) and the Predict model's probability score. A locomotive subsystem is PM'd when the meter reaches the threshold OR when the Predict model score crosses a configured threshold, whichever comes first.
• Wayside asset inspection via Mobile with Visual Inspection for defect classification. The MOW technician walks the territory, records observations against the asset, takes photos, and the MVI model classifies the defect. The inspection record drives a follow-up WO if the defect classification indicates action is required.

The outcome

After 18 months, the metrics:

• Locomotive unscheduled maintenance cost is down 34% ($4.2M to $2.8M annually). The reduction is driven by the Predict models catching the traction motor and alternator degradation before failure, allowing planned replacement during a scheduled maintenance window instead of an emergency shop visit.
• Mean time between failures on the instrumented subsystems is up 41% (from 1,840 hours to 2,590 hours). The condition-based PMs are catching the degradation that the time-based PMs were missing.
• Emergency MOW callouts are down 22% ($1.8M to $1.4M annually). The Visual Inspection pattern is catching the defects (broken ties, signal-head alignment, switch-point wear) that were previously only being found when they failed.
• On-time performance is up 4.5 percentage points since deployment. The improvement is attributed to the locomotive reliability (fewer failures in service) and the wayside reliability (fewer slow orders for track defects).

What the practitioner takes away

The pattern is Predict models on the highest-cost failure modes, Health scoring on the critical assets, and condition-based PM generation tied to both meter and prediction thresholds. The railroad did not try to instrument everything. They instrumented the 12% of assets that drove 78% of the unscheduled maintenance cost, and they got the ROI from that focused scope.

The other pattern is the integration with the operations team's existing decision-making. The locomotive-status board is what the operations team and the shop foreman look at every morning. The Predict model output is what drives the daily maintenance planning meeting. The model is not a side artifact. It is a primary input to the operations decision.

Case 3: Public-sector transit — Reliability Strategies at scale

The operator is a metropolitan transit authority with 1,400 buses, 220 rail cars, 18 light-rail vehicles, and 6 maintenance facilities. The asset base is mixed (rolling stock, wayside, stations, depots) and the maintenance operation is heavily unionized with strict role and craft boundaries.

The problem

The authority had been running a time-based PM program for years, with the calendar driving the work. The maintenance budget was under sustained pressure, and the authority was looking for a way to reduce the PM cost without increasing the failure rate. The previous attempt at RCM had stalled because the analysis took too long and the results were not actionable in the existing PM system.

What they built

The authority deployed Maximo Application Suite 9.1 with Manage and the Reliability Strategies library, plus Mobile for the technician workforce. The configuration used the Reliability Strategies library as the starting point for the RCM analysis, not as a replacement for it:

• Reliability Strategies library used as the analysis accelerator. The library has 800+ asset types and 50,000+ failure modes. For each asset type in the authority's fleet, the team used the library as the starting point for the FMEA, then customized the failure modes, the consequence categories, and the recommended tasks for the authority's specific operating context.
• Reliability Strategies activities converted to job plans and PMs. For each asset type, the recommended tasks from the RCM analysis were converted to job plans in Maximo, then to PM records tied to the asset. The PM frequency was determined by the RCM analysis (not by the calendar), and the PM trigger was meter-based where possible (engine hours, brake applications, door cycles) and calendar-based only where meter-based was not feasible.
• Reliability Strategies linkage to work execution. The PM record is linked to the source failure mode and the source Reliability Strategies record, so the technician can see the failure mode the PM is mitigating. The work execution data (WO actuals, labor, materials) flows back to the Reliability Strategies record, so the team can see whether the PM is actually preventing the targeted failure.
• Mobile execution for the technician workforce. The job plan is rendered in Mobile, the technician follows the task list, records actuals, and the data is synced. The craft boundaries are respected (a mechanic's work, an electrician's work, a body shop tech's work all have their own job plan task structure).

The outcome

After 24 months, the metrics:

• PM hours per asset per year are down 28% (from 142 hours to 102 hours). The reduction is driven by the elimination of unnecessary PMs (the RCM analysis showed that several calendar-based PMs were not technically justified) and the right-sizing of the remaining PMs.
• Failure rate on the covered assets is down 19% (from 0.41 failures per asset per year to 0.33 failures per asset per year). The reduction is driven by the right tasks being performed on the right assets at the right frequency.
• Maintenance cost per revenue mile is down 22%. The cost reduction is the combination of the PM hour reduction and the failure rate reduction, and it has been sustained for 12 months.
• RCM analysis cycle time is down 60% (from 18 weeks per asset type to 7 weeks). The Reliability Strategies library is the accelerator — the team is customizing the library's analysis, not building it from scratch.

What the practitioner takes away

The pattern is Reliability Strategies as the analysis accelerator, not as a replacement for the RCM analysis. The library is the starting point, the customization is the value, and the integration with Manage's job plan and PM system is what makes the analysis actionable. The mobile execution layer is what makes the program sustainable at scale.

The other pattern is the sustained, multi-year commitment. RCM is not a one-year project. The library is the accelerator, but the work of customizing the analysis, building the job plans, training the technicians, and running the living-program reviews is a multi-year program. The authority's leadership committed to the program for 36 months, and the metrics show the result.

The meta-pattern across the three case studies

The three case studies are different industries with different asset bases and different operational pressures, but the pattern is the same:

1. Manage as the core. Every case study has Manage as the system of record for assets, work, and PMs.
2. Health and Predict on the critical assets. The case studies are not trying to instrument everything. They are instrumenting the 10–20% of assets that drive 70–80% of the cost or the operational risk.
3. Mobile for the field force. The technician is on a ruggedized tablet, not at a desktop. The data flows from the field to the system in real time.
4. Visual Inspection for the inspection-heavy workflows. The image is captured in the field, classified by the model, and the result drives the work.
5. Integration with the operations team's decision-making. The Maximo data is not a side artifact. It is a primary input to the operations meeting, the maintenance planning meeting, or the locomotive status board.

The 2026 case studies are about the platform as the operational decision-making surface, not just the maintenance system of record. That is the shift that the platform is enabling, and the case studies are the proof.