Work Order Intelligence in Maximo Manage 9.x: From Raw Descriptions to Reliable Failure Codes

Maintenance data quality has always been a quiet crisis. A technician creates a work order with a description like "pump making noise again," a supervisor approves it, and six months later a reliability engineer tries to determine whether the site has a recurring bearing problem, a cavitation problem, or a lubrication problem. The failure code field is blank, the problem code was guessed, and the long description contains everything except the one fact that would make the data useful. Maximo Manage 9.0 introduced Work Order Intelligence to address exactly this problem, and the capability has been refined through 9.1 and 9.2. The goal is simple: use the work order description, the failure class, and related historical records to recommend the correct problem code at the moment the data is being entered.

This article is a deep dive into how Work Order Intelligence works under the hood, how to configure it, and how to make it useful in production rather than letting it become another ignored AI recommendation. We will look at the model template that drives the recommendations, the AI configuration application, the invocation channels and cron tasks that keep the model current, and the work queue and dashboard integration that turns recommendations into a review workflow. We will also cover data quality, feedback loops, and the common pitfalls that cause early pilots to stall.

Why Work Order Intelligence Matters

The business case for Work Order Intelligence is not about replacing the maintenance manager. It is about reducing the friction that prevents good data from being captured in the first place. In most organizations, the people who know the most about the failure are the technicians who are standing in front of the asset, and they are also the people with the least time to navigate a code hierarchy. The result is inconsistent coding, missing failure codes, and a downstream analytics problem that only becomes visible when someone tries to run a reliability study and discovers that half the work orders cannot be classified.

Clean failure and problem code data is the foundation of several important workflows. It powers Mean Time Between Failure analysis, preventive maintenance optimization, asset health scoring, and the training data for predictive models. Without consistent coding, every reliability improvement initiative starts with a data cleansing project that consumes months of effort. Work Order Intelligence attacks the problem earlier in the lifecycle by prompting the reviewer with a ranked recommendation while the work order is still open and the context is fresh.

The capability uses generative AI from IBM watsonx to interpret the work order description and predict the most relevant problem code. The recommendation is presented with a confidence score, and the maintenance manager can accept it, override it, or regenerate it after adding more detail. Each accepted or corrected recommendation feeds back into the model, improving future predictions for similar assets and descriptions. Over time, the model learns the language your organization actually uses, which may include site-specific shorthand, asset nicknames, or regional terminology.

The financial and operational upside is straightforward. Faster problem code assignment means faster work order approval. More consistent coding means better reliability analytics. Better analytics means more targeted preventive maintenance and fewer reactive fire drills. The technology is impressive, but the outcome depends entirely on whether it is adopted as part of the daily workflow.

The Architecture of a Problem Code Recommendation

At the heart of Work Order Intelligence is the pcc model template, short for problem code classification. The template defines the inputs, the target attribute, the training process, and the inference flow. Inputs include the work order short and long description, the failure class, and optionally other structured fields. The target attribute is the problem code on the work order. The model is trained on historical work orders that already have problem codes assigned, and it learns the relationship between natural language descriptions and the coded values.

The model lifecycle is orchestrated through two invocation channels. The AITRAINWOPROBLEMCODE channel handles training tasks, and the AIINFWOPROBLEMCODE channel handles inference tasks when a user opens a work order that meets the inference filter. Both channels are wired into cron tasks. The AITRAINJOB cron task has a WOAI instance that schedules training runs. By default, training happens on a periodic schedule, but you can adjust the cron expression if you need faster iteration during a pilot.

The inference flow is straightforward from a user perspective but involves several backend components. When a work order is created or edited, the inference filter determines whether the record is eligible for recommendations. If it is, the AIINFWOPROBLEMCODE channel sends the record to the Maximo AI Service, which runs the model and returns the top recommendations with scores. The recommendations are displayed in the work order editor, typically in the Problem code field, with the highest scoring option surfaced first. The user can select a recommendation, ignore it, or add more description detail and regenerate.

The AI Service itself is a platform-level component in MAS 9.x. It is deployed as part of the suite and must be running before Work Order Intelligence can be enabled. In 9.0, the AI Service was new. In 9.1 and 9.2, it matured into a shared service that supports multiple AI configurations across Manage and other applications. This shared architecture is important because it means the same operational patterns for monitoring, logging, and entitlement apply to Work Order Intelligence, Reliability Strategies AI enhancements, and any future AI-driven features.

For administrators who want to inspect the pipeline, the key objects are the AI configuration record, the invocation channels, the cron task instance, and the model status. The configuration record captures the template, filters, and arguments. The invocation channels define how the AI Service is called for training and inference. The cron task instance schedules training. The model status shows whether the latest trained model is ready and reports an accuracy score. Understanding these four objects makes troubleshooting much faster than chasing symptoms in the UI.

Configuring the AI Configuration for Problem Codes

Enabling recommendations is not a single checkbox. The AI configuration application in Maximo Manage requires a deliberate setup. The first step is to deploy the Maximo AI Service and configure Maximo Manage to connect to it. This is typically done by the platform administrator during the MAS installation or upgrade. Once the service is available, a Manage administrator creates a new AI configuration.

In the AI configuration application, click Add configuration and give it a meaningful name. Select the PCC template and choose the latest template version. The object structure should contain the problem code attribute for work orders, and the target attribute should be the problem code field. The target description field is optional but highly recommended because pointing the model directly at the description field improves the quality of recommendations. Then select the training and inference invocation channels and the training and inference filters.

The filters are the most important part of the configuration because they define what the model learns from and what records receive recommendations. Both filters should be public and should use the osclause type. The training filter should select historical work orders with reliable problem code data. A common mistake is to train on every closed work order in the system, including records that were miscoded or left blank. It is better to train on a curated set, even if it is smaller, than to pollute the model with bad examples.

A well-designed training filter typically includes conditions such as status equals CLOSE or COMP, problem code is not null, problem code is not in a generic bucket like OTHER, the description is not null, and the work order was closed within the last two years. You may also want to filter by site or asset class during a pilot so the model learns a specific domain before generalizing.

The inference filter determines which open or in-progress work orders are eligible for recommendations. A conservative starting point is to include work orders in a specific status range, such as APPR or INPRG, with a non-null description and a failure class. You can broaden the filter once you are confident in the recommendations. The filter also controls which work orders appear in the work queue used by maintenance managers to review recommendations.

After the configuration is created, set arguments such as the score_threshold. The score measures how recommendable a problem code is for a given work order, and only codes above the threshold are presented. The right threshold depends on your tolerance for false positives. A high threshold reduces bad suggestions but may leave many work orders without a recommendation. A low threshold gives more suggestions but increases the chance of an irrelevant recommendation. Start with the default, review the results for a few weeks, and adjust based on acceptance rates.

The final steps are to activate the configuration, check data requirements, and train the model. Checking data requirements reviews the training set for quality issues such as missing descriptions or problem codes with too few examples. Training launches the model build, and the model status dialog shows when the model is ready and reports an accuracy score. Only when the model status shows Ready with a reasonable accuracy score should you enable the recommendations for production users.

Integrating Recommendations into Work Queues and Dashboards

A recommendation that nobody sees is useless. Work Order Intelligence is designed to surface recommendations in two places: the work order editor for detail review, and the work queue for bulk triage. The work queue named WOs with problem code recommendations, or a similarly named queue in your environment, collects all work orders that meet the inference filter and have pending AI recommendations. The queue card on the Operational dashboard shows the count, so a maintenance manager can see at a glance how many records need review.

The dashboard integration matters because it changes the job from reactive hunting to proactive review. Instead of discovering miscoded work orders during a monthly report, the manager can process them daily in small batches. The queue can be filtered, sorted, and personalized. If a manager sorts or filters the queue, that view is saved as their personalized view, which reduces repetitive setup.

From the queue, the manager can open a work order, see the ranked recommendations with confidence scores, and select the best match. If the recommendation is wrong, the manager can either enter the correct code manually or add more detail to the description and regenerate. Each decision teaches the model. Over a few hundred decisions, the model learns which descriptions map to which codes in your specific environment.

For developers extending the workflow, the AI recommendation objects are available through the MAS APIs and object structures. This means you can build custom review interfaces, integrate recommendations into mobile workflows, or export recommendation history for analytics. The same inference channel can be invoked programmatically, which is useful if you want to recommend problem codes during bulk work order import or migration from a legacy system.

The following pseudocode illustrates how a custom automation script or integration could call the inference channel for a set of work orders. It is not production code, but it shows the moving parts.

# Pseudocode for batch problem code inference via MAS API
import requests

MAS_BASE = "https://mas-manage.example.com/maximo/oslc"
API_KEY = "your-api-key"
INFERENCE_CHANNEL = "AIINFWOPROBLEMCODE"

def get_eligible_work_orders(site_filter):
    url = f"{MAS_BASE}/mxwodetail"
    params = {
        "oslc.select": "wonum,description,description_longdescription,failurecode,problemcode",
        "oslc.where": f"status in ('APPR','INPRG') and siteid='{site_filter}'",
        "_lid": API_KEY
    }
    response = requests.get(url, params=params, verify=True)
    response.raise_for_status()
    return response.json()["member"]

def request_problem_codes(work_order):
    payload = {
        "channel": INFERENCE_CHANNEL,
        "workorder": work_order["wonum"],
        "description": work_order.get("description_longdescription") or work_order.get("description"),
        "failureclass": work_order.get("failurecode")
    }
    url = f"{MAS_BASE}/ai/inference"
    response = requests.post(url, json=payload, headers={"apikey": API_KEY}, verify=True)
    return response.json()

eligible = get_eligible_work_orders(site_filter="SITE01")
for wo in eligible:
    recommendations = request_problem_codes(wo)
    top = recommendations.get("recommendations", [])[0] if recommendations.get("recommendations") else None
    if top and top["score"] > 0.7:
        print(f"WO {wo['wonum']}: recommend {top['problemcode']} (score {top['score']})")

In a real implementation you would handle pagination, authentication tokens, error retries, and write-back to the work order record through the proper MAS object structure.

Data Quality, Feedback Loops, and Model Maintenance

The most important determinant of Work Order Intelligence success is the quality of the training data. The model cannot learn patterns that are not present, and it will happily learn incorrect patterns if that is what you give it. Before enabling recommendations, perform a data audit of your historical work orders. Look for four problems: missing problem codes, generic problem codes such as OTHER or UNKNOWN, descriptions that do not describe the failure, and failure classes that are inconsistently mapped to problem codes.

A practical way to start is to run a SQL or MIF export of work orders closed in the last two years and count the distribution of problem codes. If the top five codes represent eighty percent of the data and the rest are thinly scattered, the model will be good at the common codes and weak at the rare ones. That may be acceptable, but you should know it going in. If a critical asset class has very few coded examples, consider manually coding a representative sample before training so the model has something to learn from.

The feedback loop is the second critical success factor. When a maintenance manager overrides a recommendation, that override should ideally be reflected in the next training run. Make sure the training filter includes corrected work orders and that the training schedule is frequent enough to capture recent trends. A quarterly training cycle may be too slow for an organization that is actively improving its coding discipline. A weekly cycle is often a better starting point, balanced against the compute cost of rebuilding the model.

Model accuracy should be monitored over time. The model status dialog shows an accuracy score, but the real measure is the acceptance rate in production. Track how often users accept the top recommendation, how often they select a lower ranked option, and how often they ignore the recommendations entirely. If acceptance drops, investigate whether a new asset type, a new failure mode, or a change in description language has drifted the data away from the training set. Retraining or adjusting the inference filter is usually the fix.

The following table summarizes the key data quality checks and their impact.

Common Pitfalls and Field-Tested Patterns

Several patterns tend to derail Work Order Intelligence pilots. The first is enabling recommendations before the data is ready. The AI will produce suggestions, users will see low confidence or irrelevant options, and they will conclude the feature does not work. The fix is to run the data audit and a limited pilot with one well-coded asset class before expanding.

The second pitfall is setting the score threshold too low or too high and never revisiting it. Threshold tuning is an ongoing activity, not a one-time setup. Review acceptance rates monthly and adjust the threshold to optimize the trade-off between coverage and precision.

The third pitfall is treating Work Order Intelligence as a replacement for failure code governance. The model recommends codes, but the organization still needs a maintained failure code hierarchy, clear definitions, and training for technicians and supervisors. AI accelerates coding, but it does not define what the codes mean.

A fourth issue is forgetting the mobile and field context. Many work orders are created or reviewed on mobile devices. Make sure the work queue and work order editor experiences are tested on the actual form factors your teams use. A recommendation that is buried behind a scroll or requires extra taps will not be adopted.

A fifth pitfall is failing to measure outcomes. Without a baseline, it is impossible to prove value. Before starting the pilot, capture the current state: percentage of work orders with blank problem codes, percentage coded as OTHER, average time from work order creation to approval, and the cycle time for coding review. After the pilot, compare. The numbers will guide whether to expand, tune, or redesign the workflow.

A field-tested pattern is to start with a single site or a single asset class. Choose a site that already has relatively clean work order data and a maintenance manager who is willing to review recommendations daily. Run the pilot for six to eight weeks, measure acceptance rates and coding consistency, and use the results to justify a broader rollout. This approach builds organizational confidence and surfaces configuration issues before they affect every user.

Practical Implications

Work Order Intelligence changes the maintenance data pipeline from a downstream cleanup problem into an upstream capture opportunity. The practical value is not in the AI itself but in the workflow it enables: consistent coding at the point of review, a feedback loop that improves the model, and a dashboard-driven queue that makes the review process visible. Organizations that invest in clean training data and a disciplined pilot will see measurable improvements in failure code accuracy. Organizations that enable the feature without that foundation will see another ignored AI bell or whistle. The implication for administrators is that the hard work is data preparation and change management, not model configuration. Plan for that work explicitly in your project timeline.

Bottom Line

Maximo Manage 9.x Work Order Intelligence uses a problem code classification model trained on your own work order history to recommend the right failure code while a work order is still open. The feature requires the Maximo AI Service, a careful AI configuration with training and inference filters, a tuned score threshold, and integration with work queues and dashboards. Success depends on data quality, a healthy feedback loop, and a phased pilot rather than a big-bang rollout. For maintenance teams struggling with inconsistent failure codes, this is one of the most directly useful AI capabilities in the suite. Set it up methodically, and it will pay dividends across reliability analytics, predictive maintenance, and compliance reporting for years.