Work Order Intelligence in Maximo Manage 9.x: AI-Assisted Failure Codes, Duplicate Detection, and the JSON Integration Layer

The Work Order Lifecycle in Maximo Manage 9.x

Work orders are the operational currency of IBM Maximo. Every maintenance action, whether a routine inspection, an emergency repair, or a complex shutdown, flows through the work order module. Mastering work order management in Maximo Manage 9.x means understanding its type structure, status lifecycle, planning and actuals data model, workflow automation, and the new AI-assisted capabilities that have arrived with the 9.x release stream.

IBM Maximo defines multiple record types within the Work Order Tracking application. The Work Order (WO) is the most common type, covering corrective maintenance, planned maintenance, and project-based work. Most organizations process 70 to 90 percent of their volume as standard work orders. Preventive Maintenance (PM) records are templates, not executable work orders. They define the task, frequency, and asset for scheduled maintenance. When a PM frequency trigger fires, whether time-based or meter-based, Maximo automatically generates a child work order. The PM itself remains as the recurring template.

Change work orders manage formal changes to assets, systems, or infrastructure configurations. They typically include additional approval steps and risk assessment fields, making them appropriate for IT change management use cases or regulated industries where unauthorized asset modifications carry compliance risk. Release work orders function as parent containers for grouping related child work orders into a single package. They are used for complex shutdowns, turnarounds, or project-based maintenance where multiple teams and trades must coordinate. Activity records are sub-tasks within a parent work order, allowing each to be tracked independently while remaining linked to the parent cost and schedule.

The work order status lifecycle in Maximo follows a defined progression. Work orders enter as WAPPR (Waiting Approval), move to APPR (Approved), then to INPRG (In Progress), and finally to COMP (Complete) or CLOSE (Closed). Each status transition triggers different behaviors including workflow notifications, assignment scheduling, and financial processing. Understanding these transitions is critical because they control when labor, materials, and tools can be charged to a work order, when assignments become available to technicians, and when the work order is eligible for financial closing.

In MAS 9.x, the Work Centers that existed in Maximo 7.6 have been removed. They have been replaced by the MAF (Maximo Application Framework) role-based applications, which provide a more modern and flexible user experience. The Work Supervision Work Center is gone, replaced by the Work Order Planning application and the Work Queue Manager application. These new applications are built on the MAF framework and provide card-based interfaces that display essential information about each work order.

The key fields on a work order remain consistent with Maximo 7.6, but the user experience for interacting with them has changed significantly. The minimum required fields for manual creation are the work order number (auto-generated), description, status (defaults to WAPPR), and either an asset or a location. Additional key fields include work type (used to distinguish corrective, preventive, inspection, and capital work for reporting and KPI calculations), priority (numeric value where 1 is highest, used by schedulers to sequence the backlog), job plan (links a pre-defined task list with estimated hours and standard materials), target start and finish dates, and failure class (enables structured failure reporting at completion).

AI-Assisted Failure Code Recommendations

Work Order Intelligence is the umbrella term for a set of AI-assisted features that landed in Manage 9.0 and have continued to evolve through 9.1 and 9.2. The most visible feature is the recommended failure code, which appears on a work order when a technician describes the problem in free text. Behind the scenes, an AI broker takes the description, runs it through an inference model, and returns the top three most likely problem and failure codes. The technician sees the recommendations, picks one, and the work order is updated with the chosen code.

The configuration is straightforward but requires the AI broker to be properly enabled. The AI broker is configured in the ManageWorkspace custom resource, and the model is referenced by name. Inference happens at the moment the technician saves a long description, not at the moment the work order is created. The recommendations appear in a panel on the work order, and the technician can accept, reject, or override. The history of acceptance and rejection is stored on the work order and is fed back into the model, creating a continuous learning loop.

Here is how the AI broker is configured in the ManageWorkspace custom resource:

# ManageWorkspace Custom Resource - AI Broker Configuration
apiVersion: mas.ibm.com/v1
kind: ManageWorkspace
metadata:
  name: maximo-manage
  namespace: masdemo-manage
spec:
  # AI broker settings
  settings:
    aiBroker:
      enabled: true
      model: "maximo-failure-prediction"
      endpoint: "https://ai-broker.masdemo.svc:443"
      confidenceThreshold: 0.75
    # Work Order Intelligence features
    workOrderIntelligence:
      failureCodeRecommendation: true
      duplicateDetection: true

The practical impact of this feature is significant. Before AI-assisted failure coding, technicians often selected generic or incorrect failure codes because they did not have the time or expertise to navigate the full failure class hierarchy. This resulted in poor failure data quality, which undermined reliability analysis and made it difficult to identify recurring problems. With AI-assisted recommendations, the technician types a description and immediately sees the three most likely codes. The friction of navigating the failure class hierarchy is eliminated.

The model that powers the recommendations is trained on historical work order data from your environment. This means the recommendations improve over time as more work orders are processed and as technicians provide feedback by accepting or rejecting suggestions. The model also accounts for the asset type, location, and work type, so the same description may yield different recommendations depending on the context of the work order.

A practical concern is what happens when the AI broker is unavailable. If the AI service is down or the model is not loaded, the work order behaves exactly as it did before the feature was enabled. The technician manually selects the failure code. There is no degradation in core functionality. The AI assistance is additive, not dependent. This design is important because it means you can enable the feature without worrying about service availability affecting critical work order processing.

Duplicate Work Order Detection

The second feature in the Work Order Intelligence family is duplicate detection. When a new work order is created, the system compares it against recent work orders on the same asset, the same location, or the same problem code. If a probable duplicate is found, the technician is shown the existing work order and asked to confirm whether the new work order is genuinely a duplicate.

This feature addresses a common problem in maintenance operations. Multiple people can report the same issue, especially in large facilities with many operators. A pump fails and three different operators submit work requests for the same pump. Without duplicate detection, three work orders are created, three technicians may be dispatched, and three sets of labor and materials are charged against what is actually a single repair.

The duplicate detection algorithm considers several factors. The asset number and location are the primary matching criteria. The time window for comparison is configurable but typically looks at work orders created within the past 7 to 14 days. The problem code and work type are used as secondary matching criteria. If the asset matches and the work type matches and the work order was created within the time window, the system flags it as a probable duplicate.

Here is how duplicate detection is configured:

DUPLICATE DETECTION CONFIGURATION
----------------------------------------
Application: Work Order Tracking
Navigation: System Properties > workOrder.duplicateDetection

Properties: workOrder.duplicateDetection.enabled = true workOrder.duplicateDetection.timeWindow = 7 (days) workOrder.duplicateDetection.matchCriteria = ASSET,LOCATION,PROBLEM workOrder.duplicateDetection.confidenceThreshold = 0.80

Behavior: - On WO creation: Compare against recent WOs - Match found: Display existing WO to user - User confirms duplicate: New WO is marked as duplicate - User denies duplicate: New WO is created normally - Duplicate WOs are linked to the original for tracking ```

The confidence threshold determines how aggressive the detection is. A lower threshold catches more potential duplicates but may generate false positives. A higher threshold reduces false positives but may miss actual duplicates. The default of 0.80 is a reasonable starting point, but you should adjust based on your operational experience. Organizations with high work order volume and many similar assets may need a higher threshold to avoid excessive false positives.

The practical impact of duplicate detection is measurable. In environments where it has been enabled, organizations typically see a 5 to 15 percent reduction in duplicate work orders within the first few months. This translates directly to reduced labor costs, reduced material waste, and improved technician productivity because they are not dispatched to work that has already been completed.

The feature also has a cultural impact. Maintenance planners and supervisors become more aware of duplicate reporting patterns and can address the root causes. If a particular asset generates frequent duplicate reports, it may indicate a communication gap between operators and maintenance teams. The duplicate detection data provides visibility into these patterns.

The JSON Mapper: Integration Without Jython

The JSON mapper in Maximo Manage 9.x has quietly become the integration pattern of choice for organizations that need to connect Maximo to external systems. In Maximo 7.6, the standard integration approach used the Integration Framework with Jython-based processing scripts. While powerful, Jython scripts were difficult to maintain, required specialized skills, and created a dependency on individuals who understood the scripting layer. The JSON mapper replaces much of this complexity with a declarative configuration approach.

The JSON mapper allows you to define how JSON data from external systems maps to Maximo business objects. Instead of writing Jython code to transform inbound data, you configure mapping rules that specify how each JSON field corresponds to a Maximo field. The mapper handles the transformation automatically, including type conversion, date formatting, and relationship resolution.

Here is a practical example of a JSON mapper configuration for an inbound work order creation integration:

{
  "jsonMapperConfig": {
    "objectStructure": "MXAPIWODETAIL",
    "direction": "INBOUND",
    " mappings": [
      {
        "jsonPath": "$.workOrderNumber",
        "maximoField": "WONUM",
        "dataType": "STRING",
        "required": true
      },
      {
        "jsonPath": "$.assetNumber",
        "maximoField": "ASSETNUM",
        "dataType": "STRING",
        "required": true
      },
      {
        "jsonPath": "$.description",
        "maximoField": "DESCRIPTION",
        "dataType": "STRING",
        "required": true
      },
      {
        "jsonPath": "$.priority",
        "maximoField": "WOPRIORITY",
        "dataType": "INTEGER",
        "defaultValue": "3"
      },
      {
        "jsonPath": "$.scheduledStart",
        "maximoField": "SCHEDSTART",
        "dataType": "DATETIME",
        "format": "yyyy-MM-dd'T'HH:mm:ss'Z'"
      },
      {
        "jsonPath": "$.failureClass",
        "maximoField": "FAILURECLASS",
        "dataType": "STRING",
        "lookup": "FAILURECODE"
      },
      {
        "jsonPath": "$.laborHours",
        "maximoField": "LABORHRS",
        "dataType": "DECIMAL"
      }
    ]
  }
}

The advantage of this approach is that the integration configuration is declarative and self-documenting. A new developer can read the JSON mapper configuration and understand exactly how data flows from the external system to Maximo. There is no Jython code to trace through, no hidden transformation logic, and no dependency on a specific individual who wrote the script.

The JSON mapper also supports more complex scenarios. Nested JSON structures can be mapped to Maximo relationships. For example, a work order JSON payload that includes a list of tasks can be mapped to the work order's child task records. Conditional mappings can be defined based on field values. Default values can be specified for optional fields. The mapper handles the resolution of Maximo-side lookups, such as converting an asset number from the external system to the corresponding Maximo asset record.

Suite-Level vs Manage-Level Administration

A practical challenge that catches new MAS administrators off guard is the split between Suite-level and Manage-level administration. In Maximo 7.6, all administration was in one place. You logged into the Maximo application and everything was there: user administration, security groups, workflow configuration, system properties, and database configuration. In MAS 9.x, administration is divided between the Suite level (MAS Core) and the Manage level.

Suite-level administration includes user identity, licensing, workspace management, and cluster-level configuration. These tasks are performed through the MAS Core administration interface, not through Maximo Manage. User accounts are managed through the Suite-level identity provider, which can be IBM Security Verify, LDAP, or SAML. Licenses are allocated at the Suite level through AppPoint consumption management.

Manage-level administration includes everything that is specific to the Maximo Manage application: database configuration, automation scripts, workflow design, integration configuration, cron task setup, and security group definitions within Manage. These tasks are performed through the Maximo Manage administration applications, which are familiar to Maximo 7.6 administrators.

The confusion arises because some tasks span both levels. For example, creating a new user involves creating the identity at the Suite level, assigning a license at the Suite level, and then assigning the user to a security group within Manage. If the administrator only does the Manage-level part, the user will not be able to log in because the identity does not exist at the Suite level.

Here is a reference for which administration tasks belong where:

ADMINISTRATION SPLIT REFERENCE
----------------------------------------
Suite-Level (MAS Core):
  - User identity creation and management
  - License allocation (AppPoints)
  - Workspace creation and configuration
  - Cluster-level monitoring and health
  - Certificate management
  - Channel subscription management

Manage-Level (Maximo Manage): - Security groups and application rights - Database configuration and attributes - Automation scripts - Workflow design and activation - Cron task configuration - Integration framework configuration - JSON mapper configuration - Failure class hierarchy - Job plans and PM schedules - Work order status rules ```

Understanding this split is critical for new MAS administrators. A common mistake is to look for user management in Maximo Manage and not find it because it has moved to the Suite level. Another common mistake is to try to configure security groups at the Suite level when they are actually Manage-level configurations. The best practice is to document which administration tasks belong to which level and create separate runbooks for each.

Practical Implications

The AI-assisted features in Maximo Manage 9.x are not just convenience additions. They represent a shift in how Maximo processes maintenance data. Failure code recommendations improve data quality, which in turn improves the reliability analysis that drives maintenance strategy. Duplicate detection reduces waste and improves dispatch efficiency. Together, these features reduce the administrative burden on technicians and planners, allowing them to focus on the physical work rather than the data entry.

The JSON mapper changes the integration landscape. If you are planning a new integration with Maximo Manage 9.x, start with the JSON mapper. Only fall back to Jython scripts if you encounter a transformation that the mapper cannot handle. The declarative approach is easier to maintain, easier to test, and easier to transfer between team members.

The administration split requires organizational clarity. Document which team is responsible for Suite-level administration and which team is responsible for Manage-level administration. In small organizations, the same person may handle both, but the responsibilities should still be tracked separately to avoid gaps.

Bottom Line

Maximo Manage 9.x is not just a new version of Maximo 7.6 in a container. It is a different application architecture with AI-assisted features, a modern integration layer, and a split administration model that reflects its cloud-native foundation. Organizations that invest in understanding these differences will see faster adoption, better data quality, and more successful integrations. Organizations that treat it as Maximo 7.6 in a container will struggle with the transition and miss the capabilities that make the 9.x release stream worth adopting.