How To

How To - TM Failure

Contents 

How to read & use the Failure Report Overview? .................................................................................... 3

The Failure report top overview grid .................................................................................................... 3

The Failure report overview top menu bar ........................................................................................... 4

The Failure Report overview section – Failure Reports (Workflow) ..................................................... 5

The Failure Report overview section – Actions .................................................................................... 6

The Failure Report overview section – Jobs ......................................................................................... 6

The Failure Report overview section – Orders ..................................................................................... 6

The Failure Report overview section – Time KPI’s & Last occurrence date .......................................... 7

 How to create a failure report? .......................................................................................................... 7

Enter failure report details. ................................................................................................................... 8

How to add images to a Failure report? ............................................................................................. 17

 How to add a cause analysis to a Failure report? ............................................................................. 18

How to add an immediate cause to a Failure Report? ....................................................................... 18

How to add a system cause to an “Failure Report”? .......................................................................... 19

 Actions .............................................................................................................................................. 20

How to add actions to a Failure report? ............................................................................................. 20

How can a user assigned to an action find it and sign it out?............................................................. 21

How to sign out an action? ................................................................................................................. 22

How to link jobs & job history to actions? .......................................................................................... 24

 How to link jobs to a Failure report? ................................................................................................ 25

How to create an “One-Off job” \ “Corrective action” from a failure report? ................................... 25

How to create an “Service Report” \ “Job History record” from a failure report? ............................. 26

How to link an already scheduled maintenance job to a failure report? ........................................... 27

How to remove a linked job from a failure report? ............................................................................ 28

How to link an existing Job history record to a Failure report? .......................................................... 28

How to link items used to a Failure report? ........................................................................................... 29

How to link orders to a failure report? ................................................................................................... 29

Configure TM Master v2 to use the Failure Module. .............................................................................. 30 Codes. .................................................................................................................................................. 30 The Risk Matrix Codes ......................................................................................................................... 32

How to configure the Risk Matrix? ..................................................................................................... 32

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

Failure number setup .......................................................................................................................... 34

How to configure mandatory fields for Failure Reports? ................................................................... 35

Related additional component information. ...................................................................................... 36

 

                 

How to read & use the Failure Report Overview?

The Failure report overview is found in two module groups in TM Master v2. In the [Fleet] module group, only available in the office system, shows all failures for all vessels in the fleet. The module found under [Inventory] is the module users onboard will use, and it shows only Failures for one vessel at the time. Other than that, both these views will show the same information and have the same functions.

 

The [Failure Reporting] overview is divided into two panes or sections (horizontally). The top section, the overview grid, shows an overview of all failure reports, related actions, maintenance jobs and time calculations. The lower section, the details grid, will list individual failure reports, actions or jobs depending on the selections made in the top section, the overview grid.

The Failure report top overview grid

The overview grid is divided into 6 main vertical sections. Some of these sections are again divided into different single columns representing statuses, entities (such as orders, units or categories) or calculated time KPI’s and dates. Each main section will be discussed later in the document.

The main vertical sections are (in order left to right):

  • Unit (or as we will see later other failure report related attributes)
  • Failure Reports (Workflow)
  • Action Workflow
  • Orders
  • Time KPI’s & Last occurrence date

The rows in the overview are by default listing the units in the fleet (The onboard system will only list the current vessel). Each row will then show Failure report details linked to the unit, named on the row.

The “default” Failure report overview (grouped by unit) 

The Failure report overview top menu bar

In the top menu bar, you will find the following controls, that will affect the details in the overview:

  1.  [New]: This button will create a new Failure Report.

 

  1. Unit Group: This is a selector allowing you to limit the list of failure reports in your overview to only show for units\vessels in certain predefined unit groups. This control is also available in several other of the fleet modules. (not available for the on-board system)   

 

  1. Group: This selector will alter the way the Overview details are groped in the overview. As stated earlier by default the overview is grouped by “unit” \ “vessel” and each row show details linked to the vessel named (in row 1 of the overview). The selector allows users to group the details in the following ways:

 

  1. By “Unit” (default) o By “Discovered During” attribute o By “Failure Mechanism” o By “Failure mode” o By “Cause of Failure” o By “Operation Activity” o By “Project Number” o By “Responsible Department” o By “Failure Effect” o By “System”

 

The Overview grouped by “Department” 

 

  1. Submitted: This selector will allow to filter the overview based on the date the failure report was “submitted”. By default, it is set to “show all”. The following options are available.

 

  1. Show all (default) o Submitted within the last 7 days o Submitted within the last 14 days o Submitted within the last 30 days

 

  1. Closed: This selector will allow to filter away old closed or cancelled failure reports. By default, this selector is set to show only failure reports “Closed within the last 30 days”. The following options are available

 

  1. Show all o Closed within the last 7 days o Closed within the last 14 days o Closed within the last 30 days o Closed within this year o Closed within last year

 

  1.  [Refresh]: This will refresh the data in the Failure report overview to reflect the current details in the data base.

 

 

The Failure Report overview section – Failure Reports (Workflow)

This section lists all Failure reports, the different columns within this section represent different workflow statuses a “Failure Report” can have. The following statuses are:

        Failure Report Draft: This column will list all Failure reports created but not yet submitted and given a Failure report number. These can be deleted by the users who have created them and any user with the user right to delete any drafts.

 

        Failure Report Submitted: This column will list all Failure reports that have been submitted and will be processed. The Failure report has been given a “Failure report” number in this state and can no longer be deleted. (but can be cancelled)

 

        Failure Report Processed: This column will list all Failure reports that have been set to “Processed. Processed means that all assessments and actions and jobs have been decided and added to the Failure Report and is now awaiting all the actions and/or jobs to be performed (signed out). The columns list all Failure reports that still have open actions and/or jobs linked to it. Once all actions and/or jobs linked to a Failure Report has been signed out, the Failure report will move to the next column.

 

        Failure Report Ready for Completion: When all actions and \or jobs linked to a Failure Report has been signed out, or if a Failure Report is set to the “Processed” status without any actions or jobs it will show up in this column. Adding a new action or job to the Failure report at this

stage will move it back to the “Processed” status, until the action or job has been signed out.

 

           Failure Report Completed: This status will list all Failure Reports that have been set to

“Completed”. Some might find this status superfluous and not needed, since the next status is “Closed”, however the status does allow an extra review step between, the failure has been completed\resolved and it being closed. There is a function available to control who is able to set a “failure report” to completed, based on the “Failure Risk” value.

 

        Failure Report Closed: This column will list all closed Failure Reports. Once a failure report has been closed it is no longer possible to edit it.

 

        Failure Report Cancelled: This column lists all submitted Failure reports, that have been cancelled.

The Failure Report overview section – Actions

The action section will list all the actions that have been added to the system in relation to any of the findings linked to any of the inspections. The section consists of the following columns

        Draft: This column will list all actions in draft mode (not yet approved)

Draft actions will not be distributed to assigned users before it has been approved.

 

        Open (Due): This column will list all “Due” actions.

 

        Open (Overdue): This column lists all the overdue actions

 

        Closed: This column will list all actions that have been signed out.

 

      Cancelled: Once an action is approved, it is assigned a unique running number. To avoid “losing” running numbers it is not allowed to delete approved actions, they must be cancelled.

 

The Failure Report overview section – Jobs  

        Scheduled corrective jobs: This column will list all jobs linked to any of the actions.

 

      Overdue scheduled corrective jobs: This column lists all the overdue jobs linked to any of the actions.

 

       Signed out corrective jobs: This column will list all job history linked to any of the actions                for corrective jobs that have been signed out.

 

The Failure Report overview section – Orders  

      Orders Linked to Failure Reports: This column will list all orders linked to any of the Failure reports on the row.

 

The Failure Report overview section – Time KPI’s & Last occurrence date

OOP 

Out of Operation: This column will show the sum of all the “out of operation” time for all the failure reports on the row. “Out of operation” relates to the component that has failed

 

TR

Total Time to Repair: This column will show the sum of all the “time to repair” for all the failure reports on the row. Time to repair is the time between repair started and repair completed, and not the man hours spent to repair.

 

MTR 

Mean Time to Repair: This column will show the mean time to repair for all the Failure reports on the row. The value is calculating the average using each of the failure reports “Time to Repair “

 

NPT 

Total Production Down Time: (Non-Production Time) This is the total Non production time caused by the failure on the row.

 

Last 

Date of Latest failure: This is the Failure date of the latest Failure Report in the row. 

 How to create a failure report?

There are two main ways to start the creation of a failure report.  

  1. From the failed component form. 
    1. Click [Inventory] [Components] Double click the component that failed.
    2. Click the “Failure history” tab
    3. Click the [Add Failure Report] button.
    4. The “Failure Report Form” will open
  2. From the failure module. 
    1. Click [Inventory] [Failure Reporting]
    2. Click the [New Failure Report] found on top left hand side of the top menu.
    3. The “Failure Report Form” will open

Enter failure report details.

The failure report form. 

The Failure Report form has wide array of fields and details that may be used and filled in at any stage of the workflow. Which details should be recorded at what time and in which status? This is very much up to each company using the Failure Reporting module. It is possible to configure which field are considered mandatory before proceeding to the next status, to ensure that the details are recorded when they should.  How to do this is covered in a later chapter.

The next part will address all fields and explain the intention of them. Most of the fields that allow selecting between several options are based on customizable code lists, that a company can populate themselves with the values and options they need to cover their operation. Populating these code lists is discussed in a later chapter. If the values are not from such a code list, this will be mentioned in the description of the field.  

The “Failure Details” section 

This section allows to record key details on the failure itself.

 

Name: Here you can enter a name for the failure. Naming a failure may seem strange but it is meant as a short description for the failure, for easy recognition.

Discovered During: This field will allow to record the circumstance of the discovery of the failure.

Typical values would be (Maintenance, Operation, Operation preparation etc.)

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. 

Failure Mode: The mode in which one function that the design should fulfill, fails. A “Failure mode” is usually an anticipated mode of failure either based on the user manual or based on an analysis (FMEA)  The available options are configurable in a code list, but the codes available here can be linked to one or more “Component type”. As a result, the options available in this list may vary based on what

“component type” the failed component has. IE: A printer may have one set of failure mechanisms such as “Paper Jam”, “Out of Toner”, “Open Paper Drawer”, which will not apply to a failed pump or ROV.

Failure Effect: The Immediate consequences of a failure on operation.

Cause of Failure: What is considered the main cause of failure

Operation Activity: What was the operation taking place when the failure was discovered?

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. (The value selected in this field and in the “probability” field is used to calculate the “Failure report” risk value) 

Probability: The likelihood of the failure occurring. (The value selected in this field and in the “severity” field is used to calculate the “Failure report” risk value) 

Created By: This field is not editable but will record the name of the user creating the failure report, next to this field, the date the failure was created will show.

 

“Assigned to:” section 

This section allows to record who is responsible of the follow-up of this failure report

 

Department: What department should handle this failure report, or at least should handle the failure report in current status 

Crew Type: What “crew type” should handle the failure report or at least should handle the failure report in current status 

Crew: What specific crew member should handle the failure report or at least should handle the failure report in current status. Possible selections are from the “crew list”, or “user list” or “contacts” list

 

“Component Details” Section 

This section deals with the component that has failed and is linked to the failure. If the Failure report was created by the [Create failure] button on the actual component. Details of the component should already be showing in this section.

 

Unit: Shows the name of the unit the failure report applies to. (not directly editable)

Component: This field allows for selection of the failed component. Clicking the […] button will open a component list of all components related to the current unit.

Parent Component: In some cases, the failure occurs on a specific component’s sub component, but as a result the entire component may fail, this field allows for selecting the “parent component” name to indicate that the failure affected the parent component.   

Spare Part:  In cases where its is a “spare part” on a component that fails it is possible to link this spare part to the failure report.

Warranty: In some cases a failure should be covered by a warranty, if so ticking this check box will indicate that in the Failure report.

Warranty date:  Will show the component warranty expiry date. This is information retrieved from the selected component and can’t be edited from the Failure Report form, it must be updated on the component form.

Criticality: Will show the component criticality value.   This is information retrieved from the selected component and can’t be edited from the Failure Report form. it must be updated on the component form.

System: Will show the component “system” tag. This is information retrieved from the selected component and can’t be edited from the Failure Report form. it must be updated on the component form.

Sub System: Will show the component “sub system” tag. This is information retrieved from the selected component and can’t be edited from the Failure Report form. it must be updated on the component form.

Component Type: Will show the component “component type” tag. This is information retrieved from the selected component and can’t be edited from the Failure Report form. it must be updated on the component form.

Owner: Will show the component “Owner” . This is information retrieved from the selected component and can’t be edited from the Failure Report form. it must be updated on the component form.

Department: Will show the responsible “Department” for the component. This is information retrieved from the selected component and can’t be edited from the Failure Report form. it must be updated on the component form.

Current State: This will reflect the selected component “State”, unlike the previous component fields that was not editable from the component form, this will allow users to alter the component “state” “Financial Details” section 

 

Project Number: This will allow to link a failure to a “Financial Project”, that has been predefined in [Purchasing] – [Financial Project]

Account number: This field will allow to link the failure to a specific account.

 

“Failure” group 

 

Failure no: Once a Failure Report has been “Submitted”, the report is assigned a number. It will remain empty until the “failure report” is in status “Draft”. The “Failure report” number mask is configured under settings and explained later in this document.

Status: This will reflect the current workflow status of the Failure report.

Risk: Based on the selections made in the Failure report form fields “Severity” and “Probability” the Failure report Risk value will be calculated and shown here. The Risk matrix used is found under the system settings and is described later in this document.

 

 

 

 

 

 

 

 

 

“Date and Time” group 

 

Time of failure: Date of failure occurring or first discovered.

Production stopped: If failure caused production to stop, this is for recording the date and time the production stopped. 

Production restarted: If failure caused the production to stop, this is for recording the date and time production was restarted. 

Repair started: The start date and time for any repair. 

Repair completed: The date and time for when the repair was considered completed. 

Failure resolved: The date and time for when component was ready for going back or back in production 

Non-productive time: These fields show the time between the values entered in the fields "Production stopped" and "Production Re-Started". The tick box, named “Manual”, at the end of this field, will open the fields for manual entry. The fields will then no longer calculate its value, but show the manual added values.

Time to repair: These fields show the time between the values entered in the fields "Repair started" and "Repair completed" The tick box, named “Manual”, at the end of this field, will open the fields for manual entry. The fields will then no longer calculate its values, but show the manual added values.

Man-Hours to repair: These fields show the total amount of man-hours added to jobs, linked to the failure, that have been signed out. The tick box, named “Manual”, at the end of this field, will open the fields for manual entry. The fields will then no longer calculate its values, but show the manual added values.

Out of Operation: These fields show the time between the values entered in the fields "Time of Failure" and "Failure resolved" The tick box, named “Manual”, at the end of this field, will open the fields for manual entry. The fields will then no longer calculate its values, but show the manual added values. 

Sub tab fields  

 

Failure Description: For the general description of the failure that has occurred.

The “Failure Description” field, supports rich text, which means it is possible to use bold, underline, italic and different font types and sizes etc. It does however not support inserting images as part of the text. It is possible to include images in the Failure report, that will appear in the “Failure Report” report (PDF or print). Please see “How to include images to the failure report?” later in this document for more details 

 

 

Images: It is possible to include images in the Failure report, that will appear in the “Failure Report” report (PDF or print). Please see “How to include images to the failure report?” later in this document for more details 

 

 

Comments: The comments sub tab can be used for any additional comments relating to the failure report, that does not “fit” in any of the other fields in this form 

 

Cause analysis: If an extensive cause analysis is need for the failure it is possible to record any number of “immediate” causes and “system causes”. Causes are recorded in a three structure. For more details on how to record causes please refer to the chapter “How to add Causes?” later in this document. 

 

Actions: The action sub tab allows for recording require any actions that are not “jobs” that needs to be performed as part of the failure report. Please refer to how to the chapter “How to add actions to a Failure report?” for more details related to actions.  

 

Jobs: The “Jobs” sub tab will allow adding new one of jobs or linking existing jobs to a failure report

More details on linking jobs to a Failure report can be found in the chapter “How to link jobs?” 

 

Job history: The “Job history” sub tab will list any jobs that have been linked to the failure report and then signed out. It is possible add a service report directly from this view as well as link a failure report to an existing job history record.  For more details on how to link history records to a job please see the chapter “How to link job history to a failure report?” 

 

Items Used: The items used sub tab will list all items used as part of any of the linked jobs sign out. It is not possible to add items directly, it will only include and show items used as part of linked jobs 

 

Orders: This sub tab will list any orders that have been linked to the failure report. More details on how to link an order to a failure report can be found in the chapter “How to link an order to a failure report?” 

 

Messages: This sub tab allows simple messages to be added to the failure report. 

 

Closure comment: This sub tab will enable users to add a closure comment to the Failure report. The field can be edited up until the failure report is closed. A dialog with the current closure comment will be displayed when the failure report is closed, as both a reminder & information 

 

How to add images to a Failure report?

  1. Open the Failure Report 
  2. Click the ‘Image” sub tab 
  3. Click [Add Image] 

 

  1. Add an image number, the images will be sorted on this number in the Failure report “report” 
  2. Fill in the Heading, footer and description as you see fit. 
  3. Double click the image pane 
  4. Find the image you wish to add using the browser, select it and click Open 
  5. Click Save and Close 
  6. If you wish to alter the image, right click the image and select “Change Picture” and select another one or select the option “Remove Picture” to remove it. 

 

 How to add a cause analysis to a Failure report?

For some “Failure Reports”, a cause analysis might be required, this “cause-analysis” can be recorded on the “Failure Report” form “Causes” sub tab. The procedure adding causes to “Failure Reports” are the same as for Observations, Inspection findings and Incident Reports.

How to add an immediate cause to a Failure Report?

To be better able to make the correct decision on what to do with a Failure, describing the cause of it is a good starting point. TM Master v2 can record “immediate causes”, and “system causes”. The “immediate cause” would be the most apparent ones. Here is how you record an immediate cause found during the analysis of the finding:

  1. Open the Failure Report in question
  2. Click the “Cause” sub tab.
  3. Click the [Add Immediate Cause] button
  4. Fill in the “immediate Cause” details
    1. Name: Enter a Cause description name
    2. Type: Select a “Cause type” from the “immediate cause” types. Please refer to chapter on cause types for additional details on how to configure them.
    3. Related to: For immediate causes this field will not be available. Please refer to the chapter next chapter on adding “System Causes” for more details on it.
    4. Main Cause: If this is to be considered the main cause for the finding, you can tick this check box. Please note only one cause pr. finding can be considered the main cause for it.  
    5. Cause description: Enter a description of the cause.
  5. The additional fields in the “Cause Categorization” field group, is not possible to alter in this view as it is linked to the “Cause type”, and if alterations are required this must be done in the [Cause type] module

 

 

The Cause detail form 

How to add a system cause to an “Failure Report”?

The chapter above described adding the “Immediate causes” for the Failure Report, which is all well and good. But it is not necessarily that easy to take actions based on the immediate cause description alone. We may need to find and describe the reason behind the immediate cause, and this is what TM Master refers to as “system causes”.   Since the exercise of asking “Why?” to any reason given may end up system causes explaining system causes, it is possible to add any number of system-causes either related to the immediate cause or to another system cause.

The procedure adding a “system cause” is very similar to adding a “immediate cause” Here is how it is done.

  1. Open the “Failure Report” in question.
  2. Click the “Cause” tab
  3. Select a previously added “Immediate cause” or “System cause” in the list of causes
  4. Click the [Add System Cause] button
  5. Fill in the “System Cause” details
    1. Name: Enter a Cause description name
    2. Type: Select a “Cause type” from the “System cause types”. Please refer to chapter on cause types for additional details on how to configure them.
    3. Related to: This shows information on which other cause this “system cause” is directly related / linked to. It can be an “immediate cause” or another “system cause”. It is also possible to change the cause it relates to by clicking the […] button and selecting one of the other causes.
    4. Main Cause: If this is to be considered the main cause for the finding, you can tick this check box. Please note only one cause can be considered the main cause for a failure.  
    5. Cause description: Enter a description of the cause.

You may select one of all your added causes as the “Main Cause” for the Failure report, the main cause will also be available as part of the Failure Report grids and can be used to filter and search on.

 

 Actions

A “Job” should be used to describe the corrective action of a “Failure”, when signed out the job will be linked to the component as “maintenance history”. In some cases, however, the actions needed as part of the corrective or preventive plan does not fit as a “Job”, in those cases “Actions” can be used.

Examples could be “create an order” for something, update a document etc.  

How to add actions to a Failure report?

  1. Open the Failure Report in question.
  2. Click the “Actions” sub tab
  3. Click the [Add action] button.
  4. Fill in the details in the action form. (ref image below)
    1. Name:   This is for a name or short description for the action  
    2. Department: The “Department” that will be responsible for the action. All crew members with a crew type linked to this department will be able to see this action in their personal “Dashboard” if you will as actions assigned to their department.
    3. Crew Type: The assigned crew type that should perform the action, all crew members of this type will be able to see this action in their personal “Dashboard”, as actions assigned to their crew type.
    4. Crew: This will be the specific crew member, user (or contact) that will be responsible for this action. Users or Crew member selected will see this action in their personal “Dashboard” as assigned specifically to him or her.  
    5. Category: Assign a category for this action
    6. Type: Is this considered a “Preventive” or “Corrective” action?
    7. Priority: Assign the appropriate priority  
    8. Deadline: Assign a deadline/ due date for this action.
    9. Action Task: Enter the description for the action to be performed

The remaining fields can’t be altered in this form and serve only as additional information:

  1. Due Status: All actions are considered “Due”, until they are considered “Overdue”
  2. Done Status: When a user starts signing out the action, he/she may indicate their progress as percent done, and it will show in this field.
  3. Unit: Is of course the unit/vessel the action is to be performed, which will of course be the same unit that has performed the inspection.
  4. Source type: Actions can so far be linked to either “Failure Reports”, “Inspections”, “Incidents” or “Observations”. This field will show which of the four the action stems from.
  5. Source: Will show the number for the exact “Failure Report”, “inspection”,

“Observation” or “Incident, that this action stems from. The […] button at the end will open the source Failure report, Incident, Inspection or Observation.

  1. The Action form also has a document tab, so if any additional document or files are relevant to the action, this can be attached here.
  2. By clicking the [Send notification] button in the top of the action form will allow you to send an email with the action details to whoever you require to notify. (This function does require TM Master v2 to be configured to connect to a mail server, if it should send external emails, otherwise it will only be sent as an internal TM Master email.  

 

Action form

How can a user assigned to an action find it and sign it out?

Once an action has been assigned to a user, the user will need to find the action with the system in order to read it and sign it out. As mentioned in item 6. In the last chapter the action form has a [Send Notification] function, which allows for email notification to the assigned users. Users can also find the actions assigned to them using the “Personal Dashboard” found under the [My place] module. Here is how it works:

 

The “My place” Overview (Dashboard) 

  1. Click [“User Name” place] [Overview]  

The section shows each individual user’s name in the module group name.

 

  1. On the Right-hand side in the lower part of the overview the “Action” section can be found.

 

  1. The actions assigned are listed in 4 different groups as can be seen below, the number on the far right indicates the number of actions found within that group. By clicking any of these groups (click the text) a list of the actions within that group will appear below in the form. By clicking the main heading “Actions” all the actions will be listed.

 

  1. In the list section that appear, you will in the belonging menu find the [Action Done] button to start signing the action out. Users can also double click the actions directly in the grid to open them for details. The [Action Done] button can also be found in the action detail form.   
  2. In the same menu the [Send Notification] button can also be found and used to notify when action has been done etc.

How to sign out an action?

Once an action has been performed, the action can be signed out, and this is the procedure on how to do it. There is no requirement from the system side that all fields need to be used and is up to each company’s internal procedure and guidelines. This procedure will describe all fields.

  1. Double click the action that is to be signed out.
  2. If this action will result in a “Corrective action” added to the TM Master Maintenance module it is possible to add this job from the action form. This can be done on the “Job & Job History” tab. For more details, please see the chapter: How to link jobs & job history to actions?  
  3. Click the [Action Done] button found in the top of the “Action” form.

 

  1. Done Status: If the job doing the action has not been completed, this can be indicated by setting a percent done value.
  2. Done by: This is should be the user/crew/contact that has actually done the action, by default this is set to the user signing the action out. But by clicking the […] button at the end of the field you can select a different user/crew/contact.
  3. Done Date: Should be the date the action was performed, by default it is set to today’s date but can be set to any previous dates if required.
  4. Signed out by: Will always be the user signing the action out.  

(The user who will at the end click on the [Sign out button]) 

  1. Signed Out date: This will reflect the date when the action is Signed out.

The date the [Signe Out] button was pressed.

  1. Action Taken: Here a short description of the action is added.

 

  1. If the Action is not completed, it is possible to [Save] the current entry and continue the sign out procedure later. Any previous saved information will appear the next time a user clicks the [Action Done] button for this action. This also allows companies to quality assure the action sign out descriptions prior to sign out. This can be done by only given a limited number of people the user right to “actually” sign out the action, but regular user can still fill in the “Action done” details, set it to 100% Done, and the manager can then review the information, and then sign it out if accepted.
  2. To Sign out the action click the [Sign Out] button
  3. Confirm the sign out.

 

How to link jobs & job history to actions?

Some “Actions” created based on observations, Incidents or Inspection findings will also result as a corrective action being added as a Job in the system. By linking the Job to the action, it is possible to keep track of these jobs within the Observation, Incident or Inspection module depending on the source of the action. They will be shown in the top overview grid in these modules in the section “Jobs”. This is the procedure to link a job or a job history record to an action.

  1. Open the action in question
  2. Click the “Job & Job history” tab.

 

  1. This view is divided into two sections “Jobs” on top and “job history” below.
  2. From here you can perform the following actions:
    1.  Create a new “One Off” job which will be linked to the action 
      1. Click the [Create One Off job] button
      2. Select the component you wish to add the One Off job for
      3. Fill in the One Off job details
    2.  Link to an existing job from the due list (One off and regular scheduled jobs)
      1. Click [Link to existing job] button
      2. Select job from the due list dialog
      3. Click [Link Selected]
    3. Remove an already linked job or job history.
      1. Select the job you wish to remove the link to ii. Click the [Delete link to job] button

iii. This will not delete the job in the due list, only the jobs link to the action.

  1.  Add (Create) a “Service Report” if the job has already been done. 
    1. Click the [Create Service Report] button
    2. Select the component you wish to add the service report for. iii. Fill in the Service Report details
  2. Link an existing job history record to the action
    1. Click the [Link to existing job history record]
    2. Select the job history record you wish to link. (By default the list will only consist of the last 100 history records, by altering the filter in the grid menu additional records can be selected)
    3. Click [OK]  
  3.  Remove link between action an job history
    1. Select re job history records you wish to unlink
    2. Click the [Remove link to job history] (Please note this does not delete the job history record it simply remove the link between the action and the job history.)

 

  1. The “One off jobs” and “Service Reports” are created as normal maintenance jobs and service reports, the details on the procedure for this can be found in the TM Master User manual.

 

 How to link jobs to a Failure report?

Usually a corrective action is done after a component has failed, this might be done by the crew discovering the failed component, or it might be handed over to someone else. Either way a record for a corrective action to correct the failure can be linked to the failure report. The procedure of adding a “One-Off Job” or a “Service report” to a failure is done exactly as it is done on the component form and is described in the basic TM Master v2 Manual. So this manual will not go into all details related to creating a “One-Off” job.

How to create an “One-Off job” \ “Corrective action” from a failure report?

  1. Open the Failure report in question.
  2. Click either:
    1. The  [Create One-Off Job] button in the top menu of the Failure report form.
    2. The  [Create One-Off Job] button on the “Jobs” sub tab on the Failure Form.
  3. Enter the required job information according to your company procedures.

(For more details on how to define a job please refer to the general TM Master v2 user manual)

  1. Click [Save and Close]
  2. The “One-Off Job” has now been linked to the “failure report”. This One-Off Job will appear in the “Due” list and behave just like any other “One-Off Jobs” in the system. In addition, the job will also show up in the “Failure Report” overview in the “Jobs” section.
  3. When the job is signed out, the job history will be linked to the failure report and can be found on the “Job history” sub tab, in the “Failure Report” form.

How to create an “Service Report” \ “Job History record” from a failure report?

If the corrective action was performed immediately after the failure occurred, before any “One-Off Job” was created, there is usually no need to define a “One-Off Job” and then signing that job out. Instead a “Service Report” can be created, which basically is creating a “job history record”, linked to the failed component.

  1. Open the Failure report in question.
  2. Click Either:
    1. The  [Create Service Report] button in the top menu of the failure report
    2. The  [Create Service Report] button in the “Jobs” sub tab menu.
    3. The  [Create Service Report] button in the “Job history” sub tab menu.

A Component picker list will show up, allowing the user to specify what component the job was done one. The selected “Failed Component” is preselected, but in some cases, it might be required to link the record to one of the sub components or the parent component of the failed one.

 

       

  1. Select the Component where the work was done.
  2. Click [OK]
  3. Enter the job details in the form that pops up. This is the “Job Sign out” form, and you can fill in all the required details of what was done, including items used, attached documents etc

       

  1. When done click the [Sign Out] or [Save] button

Please be aware: that since what is done here is creating a “job history” record directly it will not show up in the “jobs” sub tab list, but directly in the “job history” grid. This is mentioned since it might cause confusion if the [Add service report] button found in the “Jobs” sub tab menu bar is used.

 

How to link an already scheduled maintenance job to a failure report?

In some cases, it might be required to link an existing scheduled job or One-Off job to the failure. IE: If the One-Off job was created outside the failure report or a regular maintenance job was used to correct the “failure” or part of the failure.

  1. Open the Failure report in question.
  2. Click either:
    1. The  [Link Component Job] button in the top menu of the Failure report form.
    2. The  [Link Component Job] button on the “Jobs” sub tab on the Failure Form.
  3. The “Due list” picker for the unit (vessel) for which the failure report has been created.
  4. You can use the “due list” filters to locate the job. If job is not due yet, tick the all jobs tick box, as this will list all jobs not just the ones that are due.

 

The “Due list” picker

  1. Select the job or jobs you wish to link to the “Failure Report”
  2. Click the [Link Selected] button.

How to remove a linked job from a failure report?

If a job has been linked to a failure report in error, and there is a need to remove the link to the job again the following procedure may be used. Keep in mind this procedure will only, remove the link between the failure report and the job. It will not remove\delete the job itself from the system.

  1. Open the Failure report in question.
  2. Click the “Jobs” sub tab.
  3. Select the “Job” or “Jobs” to be removed
  4. Click the  [Remove Link to job] button.
  5. The link to the job is now removed.

Please be aware that the  [Delete the selected item] button, also found in the “Jobs” sub tab menu bar, will delete the actual job, and not just the link between them as the button described above. The user will, however require the user right to delete jobs from the system to be able to do so.

 

How to link an existing Job history record to a Failure report?

There might be cases where a job that was related to the failure was signed out prior to being linked to the failure report, so it might be required to link an existing job history record to a failure report.

  1. Open the Failure report in question.
  2. Click Either:
    1. The  [Link job history] button in the top of the “Failure Report” form
    2. The  [Link job history] button on the “Job History” sub tab, menu bar.
  3. A list of the “Last 100” job history record will pop up. If the required job history record is not among the last 100, select a different range in the drop down in the menu that says “Last 100 post” by default.
  4. Select the job history record or records you wish to link, and click [OK]
  5. If you select a record that is not linked to the “Failed Component” you will be notified and asked to confirm that you wish to link the selected job history record to the failure report.

How to link items used to a Failure report?

It is not possible to link Items used directly to the failure report, it needs to be done as part of a job sign out or when creating a “Service report”. When signing out a job (or creating a service report), it is possible to record the items used as part of the job on the “Sign out job” form, items tab. Any items that is recorded as part of the “job history” record linked to a failure report will show up in the items used list.

How to link orders to a failure report?

If something needs to be ordered as part of a “failure report” it is possible to link orders to the failure report. Linked orders will show up on the Failure reports “Orders” sub tab as well as in the “Failure report” overview. Here is how to link an order to a failure report.

  1. Open the order in question.
  2. Click the “Failure” sub tab on the Order head form.
  3. Click the […] button in the “Failure report” field

A list of all Failure reports related to the unit\vessel the order belong to will pop up

 

  1. Select the “Failure report” you wish to link the order to.
  2. Click [OK]

A column is available in the “order grids” showing the “Failure report” and order has been linked to. This column is available in the “Order overview” grids as well as in the order grid found in the “Failure Report overview”   

 

How to  

 

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…

Cause of failure: 

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)

1. Configure the “risk matrix” codes first (described above) 2. Go to [System] – [Settings] – the “Incident settings” tab.

  1. If the Matrix is empty, click the [Generate Matrix] button
  2. 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”

 

  1. Click in each of the intersections, and select the “Risk LEvel” name and colour  
  2. 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 

  1. Click [Administration] [Codes]
  2. Select the Code table “Risk Level”
  3. Double one of the codes, if none exist create some.
  4. In the field “Consider Risk Level” field, select a tag if the code is to be considered a “low”, “medium” or “high” risk level.
  5. 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:

  1. Start and log on TM Master v2 with an admin enabled account.
  2. Click [System] [Settings] “Number formats” tab “Failure Report No Format”

 

The “Failure Report No Format” form.

  1. 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.
  2. Select the number of digits of the Year to be used (YY or YYYY)
  3. 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”  
  4. 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”
  5. Select the elements desired to be a part of the “Failure Report” number in the list on the lefthand 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.

  1. 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.   
  2. We recommend you, to use a configuration that is sortable.  For example: FAIL-BOU-2013-0001 ([Free text] – [Unit Code] – [Year] – [Running number]).
  3. 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.

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

 

  1. Each row in this grid represent a specific field in the “Failure Report form”, and the field name is shown in the column “Field”
  2. The other columns (submitted, Processed, Completed and Closed) represent the 4 statuses a “Failure report” can have (Draft status is excluded)
  3. 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?

 

 

 

  

   

 

 


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article