The Failure Codes application will be found in the Assets module. The application is used for creating both failure codes as well as the failure hierarchy that links the codes together.
A new record is creating a Failure Class the top level of four, with Problem, Cause and Remedy codes occurring below this to create the failure hierarchy. All codes and the hierarchy itself are entered at the organization level. A failure class is often the same as the top level of an asset classification, although the codes might be different, starting out with a one-to-one relationship between the two is common.
After creating a failure class, you enter the set of problem codes that belong to it. The Failure Codes application has two more table windows, for entering the cause codes associated with each problem code, and for entering the remedy codes associated with each cause code.
You do not need to go down to Cause and Remedy levels initially, you might collect this information from remarks that technicians make when they report a failure. Having a complete structure for every failure class for your organization can take some time to compile and make accurate, so you need to consider what is practical. It might be right to build out all levels for some failure classes that represent your critical assets, to leave others at the cause level or problem level and expand on those over time.
You do see repeating patterns in a full failure hierarchy, or a pattern of codes that are very similar to codes found elsewhere. There is an action called Copy Failure Hierarchy which allows you to select one or more problem codes found elsewhere and copy them to the current failure class. This will copy over the problem code, its cause codes, and their remedy codes.
The action Duplicate Failure Code will copy the whole failure class hierarchy to a new failure class that you provide. This action also allows you to modify the Organization which can be used to copy over failure hierarchies from one organization to another.
Failure Reporting occurs on a work order either in the Work Order Tracking or Quick Reporting applications from the Failure Reporting tab. The Failure Class on the work order is derived from the asset or location, if the asset has a failure class this will take priority. You can only enter one failure report for each work order.
In the Failure Reporting tab, you can modify the Failure Class if another failure class is more relevant, if the failure class is empty this is where you would start. After this you use the Select Failure Codes button to select the problem code, then the cause and remedy codes. The dialog only provides the codes that are relevant to what you have already selected.
The Failure Class and Problem Code are in the header of the main Work Order tab, and if a Problem Code had already been selected then when you use the Select Failure Codes button you will start with selecting the cause code. If the existing Problem Code was incorrect, you can delete the record and start afresh.
The other fields that make up the failure report are the Failure Date, the date/time when the failure occurred, a short and long description Remarks field, and the Remark Date, the date/time you made the failure report remark.
There are a couple of settings in the Organizations application that effects failure reporting. In Work Order Options and the dialog for Work Type you can determine whether a Failure Prompt occurs while completing or closing a work order. A warning is displayed if no failure report has been made for the work order if its work type has the Failure Prompt setting.
In Other Organization Options there is a section Display Duplicate Problem Warning with fields for ‘On Asset’ and ‘On Location’. If the combination of Location and Problem Code exists on an open work order then the dialog Duplicate Problem will be displayed, similarly if another open work order exists for the same Asset and Problem Code.
Failure Reporting is possible also on the Incident and Problem applications, where they work the same way as for work orders. On the TICKETS object the cause and remedy codes are stored in persistent fields, FR1CODE and FR2CODE, making it easier to use them in reports. On the WORKORDER object they are unfortunately non-persistent fields, requiring a subquery to be made on the FAILUREREPORT table.