To configure Problem, Failure and Solution codes, access the Failures module from the Module Menu. Note that, even though this is called the Failures module, we configure all three types of codes in this module. There are not separate Problem and Solution modules.

After accessing the Failures module, we'll create a new record by clicking the New button.

We'll input an ID and Name, and then we'll select a Type. The Type field is where we configure the record as a Problem, a Failure Reason, or a Solution.

Problem codes are meant to drive Work Order routing (as well as potential Failure Reasons and Solutions). This is why, when we select the Problem option as the type, several other fields display.

The Category field is a grouping mechanism for Problem codes, useful for locating these codes in a lookup and for failure analysis reporting based on Category. For this example, we'll use Mechanical as the Category.

When it comes time to add this new Problem code to a Work Order, we can select the Mechanical category on the left side of the lookup, and more easily locate the Incident Problem.

You can imagine how adding categories can also be useful for reporting purposes, allowing you to categorize Problem codes and revealing which Category of Problem is showing up most often, which one is most expensive, etc.

Warning: Despite the Category field displaying for Failure Reasons and Solutions, we recommend that you not apply categories to these types of codes. Doing so increases the possibility of mixing categories on a Work Order (e.g., a Problem code in the Mechanical category and a Failure Reason in the Janitorial category), which in turn would damage reporting data.

The Procedure field lets you add a Task list for technicians to perform in response to a specific Problem. But, beyond that, Procedures are multi-faceted and highly configurable. Using this field can automatically propagate a lot of other information to Work Orders, based solely on the Problem.

Note: For more information on using Procedures, check out the How to Use Procedures article.

We'll add the Incident Response Procedure to this Problem code. This Procedure includes a Task list as well as a technician assigned with estimated labor time and cost.

Now, when we add the Incident Problem to a Work Order, the Procedure will automatically populate, along with the Task list (in the Tasks tab) and labor assignment.

Tip: You can also auto-assign technicians based on a Problem code via the Asset/Location field. You can choose the assignment method that best suits your business processes, but auto-assigning via a Procedure gives the added benefit of assigning technicians based on the specific issue with the Asset, rather than being more generally assigned based on the Asset itself, no matter what issue has arisen with it. Also, keep in mind that auto-assignments based on Procedures will override auto-assignments based on Assets.

The Asset/Location field lets you tie the Problem code to a specific Asset. In this case, we'll add a Spin Bike Asset.

With this in place, the following two processes are possible:

• If you add the Asset to the Work Order, the Problem field will automatically populate with the associated Problem (along with any other configurations made for the Problem).
• Or, vice versa: if you add the Problem to the Work Order, then the Asset will automatically populate along with all of its configurations.

You can only have one Problem associated directly to an Asset. So, if an Asset always has the same Problem (or, if for risk aversion, you always have to rule out a single Problem initially), it would be best to use this field. You may not want to use this field if you do not want Work Orders for this Asset to always have fields populated based on the associated Problem. Instead, we recommend adding Asset Classifications to the Problem, which we will discuss right about now...

To associate a Problem code with an Asset Classification, select the Classifications tab and add the desired Asset Classification there. In this example, we'll add the Spin Bike Classification:

With this in place, we can add a Spin Bike type Asset to a Work Order, and then select the Problem field's dropdown arrow to open the Failures lookup. Selecting the Only Problems for Spin Bike checkbox displays the Problems that can be associated with Spin Bike Assets.

As opposed to using the Asset/Location field, using Classifications lets you have multiple Problems that can be associated with a single Asset. If you need to be able to choose from multiple Problems for an Asset on a Work Order, associate the Problem with a Classification rather than an Asset/Location. You can also add Problem codes to Classifications in the Failures tab of the Classifications module.

You can use the Shop and Repair Center fields to add more Work Order routing configurations to the Problem code. This is a simple way to make sure particular Problems are being addressed by the right personnel.

Once these fields are defined, we can add the Problem to a Work Order, and the Shop and Repair Center fields for that Work Order will automatically populate.

Selecting the the Available for Service Requests checkbox allows people to choose this Problem when they are submitting a service request, thus automatically routing the request based on how you've configured the Problem code in the Main Application (MRO).

Tip: Some organizations make the Problem a required field for service requests, and then make a select handful of Problems available for service requests. This limits the Problems for which people can submit a request and automatically routes these requests based on the Problem chosen.

Now that we know how to configure a Problem code and have talked about what happens when you add a Problem to a Work Order, it's time to tackle how you actually do this.

To add a Problem code to a Work Order, simply click the dropdown arrow for the Problem field on the Work Order Details tab. (Or, if you already know which Problem you want to add, start typing the Problem Name into the field, and the system will validate the chosen code):

Selecting the dropdown arrow opens the Failures lookup. This is where you will choose the Problem code for the Work Order. To do so, select the desired Problem and click the Apply button.

As mentioned above, you can select a Category on the left side of the lookup to display all the Problem codes associated with that Category.

Or--also mentioned above--if you've already added an Asset to the Work Order, you can select the Only Problems for [Classification] checkbox to display Problem codes associated with the Classification for the Asset. In this example, we have added a Spin Bike Asset to the Work Order, so we can choose to display only Problems associated with the Spin Bike Classification.

Once you have selected a Problem and clicked the Apply button, the Problem code will display in the Problem field and any other fields associated with the Problem will automatically populate.

You will notice that only Problem codes can be added to the Details tab of a Work Order. This is because Problem codes can drive Work Order routing (Procedures, auto-assignments, etc.), but Failure Reasons and Solutions cannot. Instead, Failure Reasons and Solutions are meant to be defined in response to Problems, and thus are defined in the process of fulfilling a Work Order. You can add these codes in two places.

• The Tasks>Labor Report sub-tab

  

• The Complete/Close dialog in the Failure Analysis section

  

Using Problem, Failure Reason and Solution codes as intended opens up a treasure trove of data for failure analysis reporting. You can add Failure fields to Work Order and Asset reports as needed, but here are a few reports that our experts see as especially suited to failure analysis.

• Closed Work Order List by Failure
• Mean Time Between Failure

We've mentioned a lot of the uses and benefits of Problem, Failure and Solution codes, but in order to enjoy these benefits, it's important to keep a few parameters in mind:

Protect the Logical Progression of Codes

If you've read everything in this article up to this point (first of all, kudos!), you'll probably have noticed a logical progression for Problem, Failure and Solution codes. If you think of these codes in terms of a maintenance story, it makes a lot of sense. You initiate a Work Order based on a Problem, a Failure Reason defines why the Problem occurred, and a Solution addresses the Failure Reason. So, it works like this: Problem > Failure Reason > Solution.

For example: Problem=Incident Reported > Failure Reason=User Error > Solution=User Error Training

With this in mind, the overarching rule for using these codes is to protect the integrity of this maintenance story, the logical progression from Problem to Failure Reason to Solution.

It is best for Problem codes to be more general and for Failure Reasons to be more specific. Ideally, there would be a handful of specific Failure Reasons that fit logically beneath the umbrella of a more general Problem. Likewise, there should be a handful of Solutions that could logically address the Failure Reason.

Don't Mix Categories on a Work Order

If you have assigned Problem codes to a Category, it is important that you not use Failure Reasons or Solutions that belong to a different Category (I.e., a Category other than the one associated with the Problem) within the same Work Order. Doing so will damage reporting data for failure analysis because the system will not be able to recognize the proper Category for each Work Order.

Because of this, we recommend that you not assign Failure Reasons or Solutions to a Category. This will protect you from adding Failure Reasons or Solutions that belong to a Category different from the Problem code.

We want to make you aware of a few limitations we see in the current functionality of Problem, Failure and Solution codes. We see these limitations as a gap between what we recognize as best practices and the ease with which those best practices can be implemented. For example:

• There are no dependencies imposed by the system to protect the logical connection between codes. We recommend implementing dependencies so that only certain Failure Reasons can be chosen in response to a Problem, and only certain Solutions can be chosen in response to a Failure Reason. Currently you must impose these dependencies manually.
• You have the option to populate the Problem code on a Work Order based on an Asset, but it would be optimal to be able to populate the Problem code based on other fields, especially the Work Order Type field. This option is not currently available.
• It is best practice to not assign a Category to Failure Reasons or Solutions; however, the Category field displays prominently for these codes rather than being hidden like other fields that are only definable for Problem codes. There is also no access rights setting that allows you to make Category a read-only field.