Configure TM Master v2 to use the Failure Module

Some configuration is required to start using the “Failure Reporting” module to its full potential.

Codes.

The Failure Module uses three different code tables. Code tables are used as the source for the selection boxes in the Failure reporting form. The new code tables are found under [Administration] à [Codes] and they are named:

Discovered during:         The values in this list should reflect when the failure was discovered.  (I.E.: Maintenance and Mobilization or Operation…)
                                       

Incident Cause Type:       The values in this list should reflect the direct cause of failure       ( I.E.: Lack of Maintenance, Human Error or Poor QC by Supplier.)
                                        

Operation activity:         The values in this list should reflect the operational activity the failure occurred.

Failure Mechanism:        Defects in requirements, design, process, quality control, handling or part application, which are the underlying cause or sequence of causes that initiate a process (mechanism) that leads to a failure mode over a certain time. (I.E.  "Fatigue", “Corrosion” or "Fretting corrosion")

Failure mode:               The mode in which one function that the design\component should fulfill, fails. There can be several possible failure modes for each function, but not all will always occur. The specific manner or way by which a failure occurs in terms of failure of the item (being a part or (sub) system) function under investigation; it may generally describe the way the failure occurs. It shall at least clearly describe a (end) failure state of the item (or function in case of a Functional FMEA) under consideration. It is the result of the failure mechanism (cause of the failure mode). I.E; a fully fractured axle, a deformed axle or a fully open or fully closed electrical contact. A failure mode is closely related to what type of component has failed, a printer will have different failure modes than a pump, engine or ROV. So these codes can be linked with “Component” codes. The component type of the failed component will act as a filter only showing failure modes that is tagged with that component type. If a failure mode is left without a component code link, it will show up for all component types.

Failure Effect:            Immediate consequences of a failure on operation.

 

The Risk Matrix Codes

Risk Severity:                    The consequences of a failure mode. Severity considers the worst potential consequence of a failure, determined by the degree of injury, property damage, system damage and/or time lost to repair the failure. It is possible to give each of the severity codes a numerical value. The lowest value = lowest severity. In addition, it is possible to assign a colour code to each code.
I.E.: Low (1), Medium (2), High (3) and Extreme (4).

Risk Probability                The likelihood of the failure occurring. It is possible to give each of the probability codes a numerical value. The lowest value = lowest probability.
In addition, it is possible to assign a colour code to each code.
I.E.: Low (1), Medium (2), High (3) and Extreme (4).

Risk Level                           This is the text that will show up as the Risk level for the various probability and severity intersections in the approval matrix. It is also possible to assign a colour code to each risk level code. This colour code is used when the risk is displayed on the various forms where it appears. In addition, it is possible to tag, the “risk” level code, as “Considered Low”, “Considered Medium” and “Considered High”. This is a way for you to name your “Risk levels” whatever you like and tell the system if it is “low”, “medium” or “high”. This tagging is used to control who can set a Failure status to “Completed”, based on the “Failure report” Risk value.

 

How to configure the Risk Matrix?

The Risk matrix in TM Master is shared among several modules. Observations, Incident reporting, Inspections and Failure reporting. Here is how to configure the matrix. (Once set up it is replicated to all vessels in the system)

• Configure the “risk matrix” codes first (described above)
• Go to [System] – [Settings] – the “Incident settings” tab.
• If the Matrix is empty, click the [Generate Matrix] button

The matrix is generated based upon the “Risk Probability” codes (vertically) and the “Risk Severity” codes (horizontally). Row and column headers are sorted by the codes numerical value and names. It will assign a “risk factor value” to each intersection by multiplying the intersecting “probability values” and “severity values”

 

• Click in each of the intersections, and select the “Risk LEvel” name and colour
• Click [Save]

How to control who can set Failure reports to completed based on the “Risk Value”?

If there is a need to limit who can set a “Failure Report” to status “Completed” (the status just before “Closed”) based on the “Risk value” of the “Failure report”, this is possible, but will require some additional configuration.

Tag the “Risk level” codes

• Click [Administration] à [Codes]
• Select the Code table “Risk Level”
• Double one of the codes, if none exist create some.
• In the field “Consider Risk Level” field, select a tag if the code is to be considered a “low”, “medium” or “high” risk level.
• Do this for all the “Risk Level Codes”.

If the “Risk matrix described in the “How to configure the Risk Matrix” chapter has already been done, there is no need to make any changes to the risk matrix, after tagging the codes. If the mentioned “Risk matrix” has not been configured at all, make sure that it is configured to meet your requirements

User right configuration

There are three user rights found made to allow control on who can set “Failure reports” to status “Completed”, based on the Failure reports “Risk value”. Modify the appropriate  user right groups in your system, and grant them access to the “Risk level” each of the groups should be allowed to set the status to “Completed” for.

• Can Set Low Risk Failures Complete (CanSetLowRiskFailuresComplete)

User will be able to set any failures with a risk level tagged as "Low" as complete. User will not be able to modify "probability" or "severity" after the Failure report has been set to "Processed" status. If the user in addition has the "CanSetAsComplete", this user right has no effect, as it will override this one. Tagging of the risk level is done in the "Risk Level" code table.

• Can Set Medium Risk Failures Complete (CanSetMediumRiskFailuresComplete)

User will be able to set any failures with a risk level tagged as "Medium" as complete. User will not be able to modify "probability" or "severity" after the Failure report has been set to "Processed" status. If the user in addition has the "CanSetAsComplete", this user right has no effect, as it will override this one. Tagging of the risk level is done in the "Risk Level" code table.

• Can Set High Risk Failures Complete (CanSetHighRiskFailuresComplete)

User will be able to set any failures with a risk level tagged as "High" as complete. User will not be able to modify "probability" or "severity" after the Failure report has been set to "Processed" status. If the user in addition has the "CanSetAsComplete", this user right has no effect, as it will override this one. Tagging of the risk level is done in the "Risk Level" code table.

As mentioned in the user right description, if the user group configured has access to the “CanSetAsComplete”, the members of that user group will still be able to set the “Failure report” status to “Complete” regardless of any changes made to the above described user rights.

Please note: If a user only has access to “CanSetHighRiskFailuresComplete”, the user can only close “High” risk Failure reports, and not “Medium” or “Low”, if the user should be allowed closing these the user will also need access to the “low” and “medium” user right. Each of the user rights only grants access to set Failures, of the specified “Risk level” to Complete.

Failure number setup

Each failure is given a unique number, similar to the order number in TM Master v2. The procedure to configure the “Failure Report” number is also very similar to how it’s done for the order number.
Please be aware that the number must be configured for each individual installation.

To configure the Failure Report number, do the following:

• Start and log on TM Master v2 with an admin enabled account.

Click [System] à [Settings] à “Number formats” tab à “Failure Report No Format”

• Select which data field that should be used to identify which vessel the failure report is created for. You can use the “Ship Code, or “Ship Alternative Code” or create a custom value.
• Select the number of digits of the Year to be used (YY or YYYY)
• Enter the minimum of numbers the failure report running number should display. If for example 4 digits are entered the first failure report number will be “0001”
• If desirable a free text can also be included in the Failure Report number. This will make it easier to distinguish what the number refers to compared to other similar numbers (PO no, Voyage no etc.) For example: “FAIL”
• Select the elements desired to be a part of the “Failure Report” number in the list on the left-hand side and click the [à] arrow button to push it into the right-hand side list.

Please note that a separator (“-“ dash or “/” slash) is required between each element  for the number configuration to be accepted.

• You can move the selected elements up and down in the right-hand list. An example of how the number format will look like is shown below the boxes. If the example is displayed in red, you have not separated one or more of the elements with one of the available separators.
• We recommend you, to use a configuration that is sortable.  For example: FAIL-BOU-2013-0001 ([Free text] – [Unit Code] – [Year] – [Running number]).
• Once the configuration is to your liking, click [Save].

How to configure mandatory fields for Failure Reports?

To ensure that all the Failure Report Form fields that your company finds important to be populated, are populated by the users involved in the “Failure Report” process, it is possible to select what fields should be mandatory. Some details may not be available at certain stages in the processes, so it is possible to mark the fields as mandatory in relation to the Failure Report workflow.

Here is how it is done.

Click [System] à [Settings] à “Mandatory fields” tab – “Failure reporting fields” sub tab

 

• Each row in this grid represent a specific field in the “Failure Report form”, and the field name is shown in the column “Field”
• The other columns (submitted, Processed, Completed and Closed) represent the 4 statuses a “Failure report” can have (Draft status is excluded)
• Ticking any if the check boxes in a certain “Status column” will make that field mandatory, in order for the user to move the “Failure Report” from a previous status to the status for that column.

Example: If the field “Name” is ticked in the column “Submitted”, the system will make sure the “name” field is populated before changing the status to “Submitted”. A check is performed when user click the [Submit] button, and will prompt the user to enter a value in the “Name” field.

Related additional component information.

When creating a failure report for a specific component, some of the details for the component is included automatically in the failure report. This information can be important later on during analysis of your reported failures. We recommend you, to take the time to add this information for the components you will monitor with the Failure Report module, but it is not required. The component details can be found by double clicking a component in the [Component] module. The fields that are transferred to the failure report are as follows.

Warranty expiry date:  This is the warranty expiry date for the component. 
(Click the “Inst.Spec.” tab, found in the component detail form, to set the warranty expiry date.)

Component system:  What part of the system
The values available in this dropdown can be edited in the under [Administration] à [Codes] à “Component system” code table.

Component Sub system: What sub function does the component have
The values available in this dropdown can be edited in the under [Administration] à [Codes] à “Component Subsystem” code table.

Owner: Who is the owner of the failed component.

Ownership type:  This reflects the manner of ownership to the component. For example: “Leased, “Rented”, “Borrowed”, “Owned by contractor” etc. The values available in this dropdown can be edited in the under [Administration] à [Codes] à “Owner type” code table.

Department: Which department has the maintenance responsibility for the component?