The music is called Busy City from a group called TrackTribe.

Hello, and welcome back to Maximo Bite Size. A series of videos on the functional aspects of Maximo Manage.

Title

Good afternoon, my name is Andrew Jeffery, and this is the twelfth episode in the series on Asset Management and today I’ll be introducing you to Failure Codes and Failure Reporting. If you are finding these videos useful, then don’t forget to subscribe to the channel.

Learning Objectives

The Assets module has an application called Failure Codes which is where you define a hierarchy of codes that you then later use on a work order when you make a failure report following a breakdown of an asset. In the section on Work Order Failure Reports we will also discuss the pop-up dialog to alert you when Maximo detects a problem that has already been reported.

Failure codes can be used on tickets, an incident, or problem, and on the Activities and Tasks application, so we’ll discuss this along with the differences between failure reporting and applying a solution and why we have both.

So, let’s get started.

Failure Codes

The Failure Codes application will be found in the Assets module. It both defines failure codes as well as allowing you to build a failure hierarchy from those codes. The standard failure hierarchy starts with a failure class, and then at successive levels has problem, cause, and remedy codes, four levels. If you scrolled down, you would see a table window for Remedies. You are not restricted to four levels, but this is rarely changed.

When you use the action New Failure Code you are adding a new failure class at the Organization level . When you use New Row on the Problems table window you are creating a problem code which is a child of the failure class that you first entered. Both the new failure class and the new problem code are entered into a library of failure codes which also exist at the Organization level, and these can be reused in other failure hierarchies using the Select Value. A code which you use for a problem code in one failure hierarchy can be used at another level in another failure hierarchy, but this would be unusual.

When asked what is the difference between failure classes, an asset type and an asset classification, the answer is that it depends and starting out you may align them. You won’t go far wrong by aligning them, and then later deviating from this alignment when you find a good reason to do so. If you do only one thing start by thinking about failure classes because you do want to drive your organisation towards being able to report problems when failures occur. A failure class will allow you to analyse failures even if the problem, cause, and resolution are entered as text.

Asset Classifications requires more thought as they are typically implemented in a classification hierarchy, perhaps only two levels, and you should consider their attributes, with some attributes entered on the parent classification. I would leave the implementation of Asset Types until you are starting to review performance management of your assets, although some will start with Asset Types because they are simple to implement. Asset Types have little reach across core Maximo, they can be referenced on an Asset Template, on Warranty Contracts, and as filter criteria on a Service Level Agreement. But it is in Maximo Health where they start to be used.

When starting out, building a failure hierarchy four levels deep for all your asset classes is a lot of effort. Consider starting off with a good set of problem codes for each failure class and capturing the root cause and remedy as text. Later you can then review the text to see what sort of cause codes and remedy codes you might create. When you do expand to a 3rd or 4th level consider doing this for each failure class in turn starting with the asset classes that contain your critical assets. For some failure classes you may never add cause and remedy levels, or you may have only a cause level and only the most common causes of failure, not a complete set. You need to be practical how you approach building the failure hierarchies.

If you or your client is in the Petroleum, Petrochemical or Natural Gas sectors then there is an ISO standard ISO 14224:2016 for both equipment classifications (two levels) and failure hierarchies. If you are using the Maximo Oil & Gas Industry Solution these are available for download from the List tab of the OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More (Oil) application. They are not available in the add-on Maximo Health, Safety and Environment Manager (HSE).

If you have built-out a failure hierarchy then there is an action Copy Failure Hierarchy which copies the hierarchy for one or more problem codes to the current failure class as can be seen at the bottom left. This copies the problem code, and its cause and remedy codes. 

The Duplicate Failure Hierarchy action will duplicate the failure class and its whole hierarchy. The Failure Class field will be empty waiting for you to enter the new failure class. The Organization field can be changed, so this action allows you to copy a failure class and its hierarchy from one organization to another. The action cannot be used from the List tab, so the duplicate only works one failure class at a time.

Work Order Failure Reports

There is a failure class field in both the Assets and Locations applications, for locationsA physical place where assets exist and where work can be performed. More it is only locations of type OPERATING where the failure class can be entered. If you have created failure classes, remember I said if you do one thing then you ought to create failure classes, then you should indicate for your assets which failure class they belong to. Similarly for locations, although not all locations will have a failure class, probably only the locations at the leaf nodes in the primary hierarchy.

When the location and/or asset is entered on a work order the failure class of the asset is copied to the work order. In the example shown on the right, asset 11430, a centrifugal pump has a failure class of PUMPS which is copied to the work order, and this allows you to select the Problem Code immediately below this, in this case the pump is leaking and so we chose LEAK , one of the problem codes that belong to the PUMPS failure class.

If there is no asset, then the failure class will be derived from the location. If the location has a failure class but the asset’s failure class is null, then the location’s failure class will be used. 

On the Failure Reporting tab , the Failure Class is shown, and any Problem Code is shown in the Failure Codes table window . When you are starting out you may ask your maintenance technicians just to fill out the Problem Code and the Remarks and Remark Date. The Remarks is a short description, defaulting to 100 characters which of course can be extended. I wouldn’t extend this but encourage your technicians to fill out the long description in the Remarks field, use the shorter description for reporting purposes.

The Failed Date will be set to the current date and time when the failure class is entered, unless it already has a value, it can be modified. Often it will be found to be the same date and time as the reported date and time, simply because the work order record is entered quickly and one of location or asset is entered initially. Some sectors do record both the failure date and the reported date, particularly those providing services to customers. The Affected Date on the Service Request can sometimes be copied to the Failure Date on the Work Order.

Display Duplicate Problem Warning

In the Organizations application, Work Order Options, and Other Organization Options you’ll find at the bottom of the dialog a section called Display Duplicate Problem Warning with two toggles for On Asset and On Location. In the Work Order Tracking application, when making a save, this displays the Problem Already Reported dialog, which you can see on the right, when the same Problem Code and location and/or asset is referenced on another open work order. The dialog shows the other open work orders and invites you to select them and then use the Relate Records action . If you do use the button, you can see the record created in the Related Records tab, it will have a relationship type of RELATED. If you believe that a new work order is effectively a duplicate of another, then after relating the work orders you would cancel the work order that was reported last, thereby retaining the original work order which should have more history.

There is another Organizations setting worth mentioning, it is found in the Work Type action’s dialog. The field Failure Prompt can be set for the work types where you would like a warning when completing or closing a work order and no failure report has been created. The warning is ‘BMXAA45437W – There has been no failure report created. If you would like to report a failure first, cancel this status change and go to the Failure Reporting tab.’. The message is output when there is a Failure Class, but there is no Problem Code.

Failure Codes in Other Applications

You can report a failure in the Incidents and Problems applications. These applications may only be available to you if you have the Health, Safety and Environment Manager add-on or the Oil & Gas Industry Solution or you are using IBM Control Desk. I mention it because Incidents and Problems are based on the TICKET object, a Service Request is a ticket, and if there were a need you could easily configure a Failure Reporting tab onto the Service Requests application.

The Failure Reporting tab works almost identically as it does on a work order. There is no Failure Class and Problem Code on the Incident or Problem header and no Failed Date, the Affected Date would be used instead. There is no Problem Already Reported dialog, there is an action Show Similar Tickets, but this is based on the classification. There is no Failure Prompt when resolving the ticket.

You’ll find that there is a FAILURECODE, PROBLEMCODE, FR1CODE and FR2CODE on the SOLUTION object but these fields are not displayed. The four fields also exist on the TICKET object. When you add a failure report to an Incident or Problem the Cause Code is added to FR1CODE and the Remedy Code to FR2CODE. This will make it easy to report using these fields because they persist in the TICKET table. Not so, with the FR1CODE and FR2CODE on the WORKORDER object, they are non-persistent, a pity from the reporting point of view. For reports based on work orders you need to join to the FAILUREREPORT table.

You can create a Failure Report on the Activities and Tasks application for both types, a work order task and a ticket activity. The Failure Details table window will be found at the bottom of the main tab, you can just about make it out in the screenshot on the right. You use the action Select Failure Codes and the dialog that opens will start with the Failure Class if this has not been populated from the Asset or Location. In the screenshot I was using asset 11430 which has a failure class of PUMPS, although this is not displayed. The Select Failure Codes dialog starts at the problem level for the PUMPS failure class.

Some people have asked, can Maximo report multiple failure reports for a work order? This may be because they wish to follow a Failure Reporting, Analysis, and Corrective Action System (FRACAS). It is possible, a work order allows you to create additional tasks during work completion, those tasks can reference a different asset or location from the parent work order, and they would allow a failure report to be created for each task. If you were using Maximo out of the box you would need to navigate to the Activities and Tasks application, but I expect it can be configured on the Work Order Tracking Actuals tab to link a Failure Reporting tab alongside Labor, Materials, Services and Tools tabs, similar to what you see in Quick Reporting, but linked to the current task rather than the parent work order.

Incidentally, the failure remark descriptive fields are not stored in the WORKORDER table but are stored in the FAILUREREMARK table.

Failure Codes versus Solutions

The Incidents and Problems applications have a tab for Solution Details and Failure Reporting . A Solution has a Symptom, Cause and Resolution, it sounds similar to Problem, Cause and Remedy but what are the differences?

A solution is a knowledge base where Symptom, Cause and Resolution are descriptions and not codes, the solution itself may have attached documents. You find a solution to an incident or problem because they share the same classifications. When you apply a solution to an incident it can apply the same solution to all related tickets, the service requests that reported the same issue, in our example a network connectivity issue. This doesn’t apply to failure reporting on work orders. 

So why do we need both Solution Details and Failure Reporting on an Incident? Think of the network connectivity issue, the solution’s resolution may require a user to perform an action, for example to update VPN software. Another network connectivity issue might have been related to a hardware failure in a Cisco switch. The solution provides information to the end user who reported an issue. The failure report provides information to the IT engineers who review reliability of equipment over time. They are both needed because they provide information to a different audience.

Thank you for watching

I hope you have enjoyed this episode on Failure Codes and Failure Reporting, you found it useful and thank you for watching. We would like to see you back in our next episode when we will review the Location and Asset Status. 

Don’t forget to hit the Subscribe button, and you can use the Notifications button to receive an alert when the next episode has been published.

The music track is called Busy City from the group called TrackTribe, do check them out on tracktribe.com, all one word. 

Until another time, Goodbye.