The Investigations (HSE) application is used for investigations into safety and environmental related incidents but also for investigations into equipment reliability and quality issues. The application is based on a view of a ticket called PROBLEM.

An investigation is normally created from a defect or an incident, but it can also be created from a service request and from an operator’s log. It will look to prevent or minimise the impact of future similar defects or incidents. How you classify the defect or incident will help you to find similar records and the volume and severity of these records will give an indication as to whether an investigation is warranted.

You can perform root cause failure analysis including FMECA (Failure Mode Effect and Criticality Analyses). You can also record the results of human factor analysis. Some of the data on the investigation record is copied from the incident, for example the sequence of events, and you will need to make sure that after the investigation has been created that it then becomes the master record and the incident record might have a change of status to make it become read-only until the investigation is complete.

Investigations (HSE) is a clone of the Maximo Problems application, a lot of additional functionality has been added. The functionality of the base Problems application is very similar to that described for Service Requests (HSE), a Service Request is another class of ticket. One significant difference with the Problem application over the Service Request is that a problem can have a set of activities that can be used to track progress between multiple parties involved in the investigation.

The additional functionality added to Investigations (HSE) application is as follows:

Investigation Tab

• The statuses of an Investigation are New, Queued, Pending, In Progress, Resolved, Closed. There is an action to view the status and ownership history.
• Investigation Type – This header field is supported with a set of values, Safety, Reliability, and Root Cause Analysis.

User Information section

• Investigation Lead – This fields needs to be a person in an Active state. It is supported with a Select Value and Go To People (HSE). Selecting a person populates the Name.
• Name – This is the display name of the Investigation Lead and it is supported with a Select Value and Go To People (HSE). Selecting a person populates the Investigation Lead.

Investigation Details section

• Incident Type – This field is read-only and is copied from the field marked as Incident Category in the Incidents (HSE) application. The fields which get copied from the Incident use the crossover domain PLUSGINC2TCK.
• External Incident Reference – This field is read-only and is copied from the Incident record using the same crossover domain.
• Knowledge Area – Identifies the area of knowledge capture. It is supported with a set of values, Safety, Integrity, Performance, Turnarounds.
• Strategic – This checkbox is used to indicate that this investigation is significantly important to the Knowledge Area.
• Risk Assessment – Often a Risk Assessment is performed early in the lifecycle of an investigation. When created it can be associated with the investigation. This field is supported with a Select Value and Go To Risk Assessments (HSE).
• Risk Ranking – This field displays the most significant risk ranking from the Risk Assessment.
• Audit – An audit or survey may be required as part of the investigation. When created it can be associated with the investigation. This field is supported with a Select Value and Go To Audit and Survey (HSE).
• Regulation – A regulation at Active state can be associated with the investigation. This field is supported with a Select Value and Go To Regulatory Compliance (HSE).

Sequence of Events Tab

The sequence of event records are copied from the incident when the investigation is created. It is not updated if changes are made to the incident, neither are additional sequence of event records added to the incident.

• The tab header has a repeat from the Investigation tab of the summary and detailed description, internal priority and the name, phone and email address of the person who reported the investigation. If the investigation was created from an incident, then this will be the same details that are on the incident. Below this is a table window for the sequence of events.
• Sequence – a number that starts at 10 with increasing increments of 10 for subsequent rows.
• Date – a date and time when the event in the sequence of events occurred.
• Condition – a field that is supported by the ALN domain PLUSGSOECONDITIONS. which will need to be configured for it to be used.
• Description – a short description of the event.
• Notes – a long description of the event with rich text formatting.
• Witness – A person who is referenced in the People (HSE) application. Selecting a person will complete the name, address, email and phone fields. The field can remain blank if the person is not referenced in Maximo.
• Name – The name of the person who is the witness for the event record.
• Address1, Address2, City, State, Zip – Fields for the witness address.
• E-mail – the email address of the witness.
• Phone – the contact phone number of the witness.

Review Actions Tab

Depending on the type and severity of the investigation there could be a standard set of actions that need to be considered in order to ensure completeness of the investigation. This uses a feature of the HSE product called standard actions which have two supporting applications Standard Actions (HSE) and Standard Action Groups (HSE).

A standard action is used for checklists or a set of review actions requiring a yes or no response. A standard action can require the user to provide a Yes, No, or Not Applicable response, an alphanumeric response, a score, or to mark the action as completed. A standard action can also have multiple review items. Standard actions are grouped together to make it easier to apply to other types of record.

Summary section

• Review Action Summary – A field for providing a short summary (200 characters) of the review actions.
• Total Score – A numeric field for recording the total score from the scoring provided on the review actions. There is no automatic calculation of the total score.

Review Actions table window

The icon at the end of the table window indicates that the standard action has one or more review items.  The user can update the table window directly. The descriptions below are in the order of that displayed in the table window details section.

• Standard Action – This mandatory field has a Select Value and a Go To Standard Actions (HSE). The Standard Action must have been previously defined and be in Active state.
• Description – This read-only field is the description of the Standard Action. It is often written in the form of a question. The long description can be used to provide additional guidance as to the meaning of the standard action.
• Standard Action Group – This read-only field is populated when the Standard Action Group button is used.
• Action By – This field is used to indicate the person who has the action. It is supported with a Select Value and a Go To People (HSE) menu. Selecting a person will blank the Action By Group.
• Action By Group – This field is used to indicate the person group who has the action. It is supported with a Select Value and a Go To Person Group menu. Selecting a person group will blank the Action By field.
• Repeatable – This read-only checkbox displays whether the standard action can be repeated multiple times when it is applied to a record.
• Action Category – This read-only field displays the category of the standard action.
• Review Action – This read-only checkbox indicates whether the standard action is of a review action type.
• Completed – Use the checkbox to indicate when the review action has been completed and the responses, review items and any comments have been added. It will add todays date and time to the Sign Off field.
• Sign Off – This read-only field is marked when the Review Action is completed.
• Comments – This field is used to provide a comment. If required a long description can also be provided.

Responses section

The fields displayed in this section are dependent on the response settings on the associated Standard Action.

• Yes, No, Not Applicable – These three check boxes are displayed if the Yes or No response is selected on the Standard Action. The check boxes act like a radio button only one of them can be checked.
• Alphanumeric – This field is displayed if the Alphanumeric response is selected on the Standard Action. It does not have a lookup.
• Score – This integer field is displayed if the Score response is selected on the Standard Action. It does not have a lookup and it does not increment the total score field. Negatives are allowed.

Review Items section

• This table window will display the Review Items of the associated Standard Action, if any. You cannot add additional review items, only respond to the defined responses and add a short comment. The response types are the same as those described for the standard action above. The scores do not total to the score field on the standard action.

At the bottom of the screen is a button to take the user to the Operational Actions (HSE) application.

Related Records Tab

The related records tab has two additional table windows over that normally displayed on ticket and work order based applications:

• Related Tickets – This shows the initiating or related incidents or service requests
• Related Work Orders – This shows the follow-up actions, changes and work orders.
• Related Operator Log – This shows the initiating or related operator log
• Related Operator Log Entries – This shows the initiating or related log entry

Solution Details Tab

The Solution Details tab has two sub tabs:

• Solution – To be applied these need to be solutions at a state of Active and where the Is Lesson Learned flag is left unchecked.
• Lesson Learned – To be applied these need to be solutions at a state of Active and where the Is Lesson Learned flag is checked.

As a single Enterprise Asset Management system can have a global reach it can take a while for a solution to be approved for use globally. A lesson learned is a knowledge document which is agreed to be useful for others to be aware of but may not have been formally approved locally, regionally or globally. Lessons learned may be created as part of an after-action review as part of continuous improvement initiatives.

Where the Solution Details differ from similar tabs in other ticket-based applications is that there can be multiple Solutions and multiple Lessons Learned. The fields on both tabs are read-only with the exception of:

• Is Default Solution – This field on the Solution tab is used to indicate the main solution for the investigation, if there is one.

The first thing a user will do when making an investigation is to use the action Search Solutions to see if there are existing solutions to apply. If there is no relevant existing Solution or Lesson Learned then from either tab the user can navigate to the Solutions (HSE) application complete a solution record, make it active and then return it or select it from the Solution field. This differs from the Incident (HSE) application where the fields Symptom, Cause and Resolution are enterable, and a solution record can be created from the entries by using the Create Solution action. The Create Solution action is available on Investigations (HSE) but all it will do is create a duplicate of a previously applied solution and hence might be hidden through Signature Security.

At the bottom of each tab is an attachments table window which shows the documents that have been attached to the solution.

Failure Reporting Tab

There are several fields in the Failure Reporting tab and the same ones on the same tab on Work Order Tracking (HSE) application. When an investigation is copied from a work order the failure data is also copied with the exception of the Failure Class, Problem, Cause and Remedy codes (the failure report). The Failure Report is not copied from an Incident when an investigation is created from it. In both cases this could be configured to also copy the failure report fields.

Failure Details section

• Failure Class – The class of the failure, the top level in the failure hierarchy. Supported by a Select Value and Go To Failure Codes.
• Description – The read-only description of the failure class, with supporting long description.
• Remarks – The first remarks made about the failure, often captured by the person who was sent out to evaluate a failure and attempt to return the asset to service. This field has a long description.
• Remarks Date – The date/time when the failure remarks were entered, set automatically by Maximo on typing into the Remarks field.

Component Level Failure Reporting section

Some methods for root cause failure analysis, for example FMECA (Failure Modes, Effects and Criticality Analysis) are dependent on identifying the causes of failure at the component level and the assembly and subassembly to which the component belongs. The Asset records may not have been broken down to this level because maintenance or inspection does not require it. The fields in this section provide the ability to identify the component that failed.

• Subunit/Component Code – A field to indicate the actual component that failed including the subassembly where the component exists. This is a text field of 50 characters there is no lookup.
• Subunit/Component Remarks – A text field of 200 characters to unambiguously describe the component that failed and the sub-assembly to which it belonged.
• Maintainable Item/Part Code – A field to indicate the identity of the main part or subassembly that needed replacing or repair. This might be copied from the actual materials tab on the associated work order. It may be an item that is found in the Item Master (HSE) application. This is a text field of 50 characters, there is no lookup.
• Maintainable Item/Part Remarks – A text field of 200 characters to indicate the part or subassembly that needed replacement or repair. The maintainable item would normally be considered to be at the lowest level in the asset hierarchy. The part would be the identity of an asset’s spare part. If the identities do not exist in Maximo then use this field to describe the asset and its spare part.

ISO 14224 Failure Mechanism section

A failure mode of a component could be quite simple, for example the component failed to open or close. The cause of this failure mode could be varied, for example, corrosion, electrical, etc – this is referred to as the failure mechanism, a type of failure cause. The HSE module provides a two-level hierarchy.

• Failure Mechanism Code – This field is supported by a value list with values from 1 to 6 whose descriptions are Mechanical, Material, Instrument, Electrical, External Influence, Miscellaneous. Changing a value in this field will blank the Failure Mechanism Subdivision Code.
• Failure Mechanism Remarks – A text field of 200 characters to indicate the high-level failure mechanism. This field should be used if 6 – Miscellaneous is chosen for the Failure Mechanism Code.
• Failure Mechanism Subdivision Code – This field is supported by a value list with 38 values, for example 1.0, 1.1, 1.2 – which are all divisions of the Mechanical Failure Mechanism, for example, General – Mechanical, Leakage, Vibration. The value list will only show the subdivision codes for the selected value entered for the Failure Mechanism Code.
• Failure Mechanism Subdivision Remarks – A text field of 200 characters to indicate the failure mechanism at the second level. This field might be used if Miscellaneous is chosen for the Failure Mechanism Code or if one of the general failure mechanism subdivision codes was chosen, 1.0, 2.0, 3.0 etc.

Safety Related System Failures section

These fields are used to indicate safety-related system failures, such as safety-critical or hardware failures. You can specify a reference to an element that is associated with a regulation, such as a performance standard. You can also indicate that the failure requires action to maintain system integrity.

• Safety Failure Category – The category of the failure that is related to safety. This field is supported with a value list with values, Systemic Failure, Random Hardware Failure.
• Hardware Failure Mode – The hardware failure mode (IEC standard 61508). This field is supported with a value list with values, Dangerous Detected Failure, Dangerous Undetected Failure, Safe Detected Failure, Safe Undetected Failure.
• Safety Critical Element Failure – A checkbox to indicate that a safety critical element has failed.
• Safety Critical Element – A reference to an element (equipment or system) for example, pressure safety valve, that is critical to safety and associated with a regulation, for example, emissions of hazardous substances. A failure of a Safety Critical Element could cause or contribute to a major accident or incident. This field is supported with a value list which will need to be set up in order to be used. The ALN Domain is PLUSGSAFETYCRITREF.
• Fail-Fix – A checkbox to indicate that the failure has been found and is now fixed.
• Mitigation Required – A checkbox to indicate whether the failure requires a mitigating action in order to maintain system integrity.
• Common Cause Failure – A checkbox to indicate whether a common cause failure has occurred. Multiple components have failed at the same time due to a set of common causes, for example, extreme ambient temperatures. When this field is checked there will be the expectation that the investigations or work orders would have been related.

Failure Detection and Identification section

These fields are used to specify the method or activity by which failures are discovered, including barrier failures and the type of barrier that failed. A barrier either prevents an action from taking place or protects the system and people from the consequences.

• Detection Method – This is the activity type which discovered the failure. This is supported with a value list with values of Periodic Maintenance, Functional Testing, Inspection, Periodic Condition Monitoring, Continuous Condition Monitoring, Production Interference, Casual Observation, Corrective Maintenance, On Demand, Other.
• Barrier Failure – A field to indicate the barrier that failed. This is supported with a value list with values of Process Containment, Detection System, Emergency Response, Ignition Control, Life Saving, Protection System, Safety Climate, Shutdown System, Structural Integrity.
• Barrier Failure Detection Method – The activity which discovered the barrier failure. This is supported with a value list with values of Audit, Survey, Assurance Activity.

Below this is the standard Failure Codes table window for entering the Problem, Cause and Remedy failure codes.

After Action Review Tab

An After Action Review (AAR) is a structured review or debriefing process for analysing what happened, why it happened, and how it can be done better by the participants and those responsible for the investigation.

User Information section

• AAR Lead and Name – The person who will lead the after action review. This field needs to be a person in Active state. It is supported with a Select Value and Go To People (HSE). Selecting a person populates the Name field. The Name field also has the same Select Value and Go To People (HSE) and when selected will populate the AAR Lead field.
• AAR Facilitator and Name – The person who will facilitate the after action review. This field needs to be a person in Active state. It is supported with a Select Value and Go To People (HSE). Selecting a person populates the Name field. The Name field also has the same Select Value and Go To People (HSE) and when selected will populate the AAR Facilitator field.

AAR Details section

• What should have happened? – A text field (250 characters) for recording what people would have expected to happen in the incident or failure under review.
• What actually happened? – A text field (250 characters) for recording what actually happened in the incident or failure under review.
• Why were there differences? A text field (250 characters) for recording the differences between what should have happened and what actually happened in the incident or failure being reviewed.
• Lessons Learned? – A checkbox to indicate whether there are lessons to be learnt. If so, records should be created in the Lessons Learned sub tab of the Solution Details tab.

Dates section

• AAR Date – The date when the After Action Review meeting took place.
• Initiating Date – The date when the decision was made to have an After Action Review meeting.

References section

• AAR Reference – An external reference for the AAR. If left blank it is assumed the Investigation number is being used as the reference.

Attendees table window

• Attendee – A person who attended the AAR meeting. It needs to be a person who is referenced in the PERSON table. It is supported with a Select Value and Go To People (HSE). Selecting a person displays the other fields held against the person record.
• Name – The display name of the person, a read-only field.
• Person’s LocationA physical place where assets exist and where work can be performed. More – The location where the person normally works, a read-only field.
• Person’s SiteA structural element of a Maximo database that is used for data separation. More – The site where the person normally works, a read-only field.
• Status – The current status of the person, active or inactive, a read-only field.

Analysis Tab

The Analysis tab provides support for analysis into different types of investigations that take place, from a safety incident to a failure of an asset.

Root Cause Failure Analysis (RCFA) is an investigative technique to determine the factors leading to or initiating a failure. There are multiple methods and there are advantages and disadvantages with each, and a site may deploy more than one of these methods. Some common methods include:

• Five Whys – Ask why, then ask why again and keep going until the causes are identified.
• Ishikawa/Fishbone – identifies the categories and the causes and effects from a spine, in diagrammatic form this looks like a fishbone.
• Cause and Effect Analysis or Causal Factor Tree – The causal factors are identified and displayed on a tree so that cause and effect dependencies are then identified.
• FMECA (Failure Modes, Effects and Criticality Analysis) – Identifies the possible failure modes at component level, the effects and the probability of failure in order to identify ways of countering the failure or reducing its frequency. The analysis starts with the most critical equipment and systems.
• Fault or Logic Tree Analysis – A failure is identified, and the failure modes described until the root causes are identified.
• Barrier Analysis – Examines the ways a problem occurred or how it might occur in the future and what could be done to prevent it. Used to analyse safety incidents. So called because a barrier can be put in place along each pathway in order to prevent the problem. Originated to prevent people (targets) from being affected by hazards by placing barriers in their way.
• Change Analysis/Kepner-Tregoe – Compares a situation that does not exhibit a problem with one that does in order to identify differences that explain what happened.
• Pareto Chart – Concerned with the relative frequency of failures in rank order so that process improvements can be made.
• Data Analytics – Transforming and modelling data in order to discover useful information that is not otherwise apparent.

The Analysis Tab has four sub tabs:

RCFA Sub Tab

• Root Cause Identified – A check box to indicate that the root cause has been identified.
• Mandatory – A check box to indicate whether the initiating event requires a root cause failure analysis. When checked the Required By field becomes mandatory.
• RCFA Lead – A person who is referenced in the PERSON table at a state of Active. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Name field.
• Name – The display name of the RCFA Lead. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the RCFA Lead field.
• Target Completion Date – The target completion date for the root cause failure analysis.
• Actual Completion Date – The actual completion date of the root cause failure analysis.
• Required By – The source of the requirement to have a root cause failure analysis performed. This field is supported by a value list with values of External, Internal. The field is read-only but becomes mandatory when the Mandatory field is checked.
• Analysis Type – The RCFA method to be used. Supported with a value list with values of Five Whys Method, List of Causes Method, Ishikawa Method.
• Approved – A check box to indicate that the root cause failure analysis has been approved. When selected it fills the Approval Date.
• Approved By – Field is read-only until the Approved check box is checked when it becomes mandatory. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Name field below it. The Approved By has to be a person at Active state. It also has to be a person who is marked as being Authorized for RCFA Approval in the People (HSE) application – Details tab.

• Name – Field is read-only until the Approved check box is checked when it becomes mandatory. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Approved By field. The selected person has to be at Active state. It also has to be a person who is marked as being Authorized for RCFA Approval in the People (HSE) application – Details tab.
• Approval Date – A read-only field that is filled when the Approved check box is checked.

RCFA Results table window

• Cause – A reference for the cause of the incident or failure being investigated. This field is the most likely to be used for ordering in the table window, unless another field is added through configuration. Once entered and saved it becomes read-only.
• Description – The description of the cause of the incident or failure under investigation. This field has a long description.
• Cause Type – The type of cause is supported with a value list with values of Basic, Immediate, Primary, Root, Secondary, Systemic.
• Cause Priority – The priority assigned to address the cause. This field is supported with a value list that will need to be configured to be used, Numeric Domain PLUSGCAUSEPRIORITY.
• Solution – An existing solution that can be used to mitigate this cause. There is a Select Value and Go To Solutions (HSE). The solution must be in Active state. It can be marked as a Lesson Learned.
• Evidence – The evidence gathered that led to the cause. This field has a long description.
• Cause Agreed – A checkbox that is checked when someone has reviewed and agreed the cause. When checked the Cause Agreed by field becomes mandatory.
• Cause Agreed By – The person who agreed the cause. This field is read-only until the Cause Agreed checkbox is checked at which time it becomes mandatory. The field has a Select Value and Go To People (HSE).
• Action Required – A checkbox to indicate that the cause needs one or more actions.
• Cause Owner – The person who is responsible for addressing the actions originating from the cause. The field has a Select Value and Go To People (HSE).
• Improvement Required – A checkbox to indicate that one or more improvements were created to mitigate the cause of failure. An Improvement is created using the action Create Improvement and the Related Records tab shows the improvement created. A Site must be entered on the main Investigation tab in order to create the improvement, it is because an improvement is a class of work order and the Site field is part of the unique key.

Cause Analysis Sub Tab

Causes table window

• Line Number – An integer field that automatically increments by one when a row is inserted.
• Why – A question such as – why did the gas leak occur? The response is entered in the Cause field. This field can have a long description.
• Cause – The answer to the “Why” question, the cause, can lead to another question. This field can have a long description.
• Related Line Number – This is the line number of a previous question which immediately led to this “Why” question being asked.
• Is a Root Cause – A checkbox to indicate that the corresponding cause is a root cause. There can be multiple root causes.

FMECA Sub Tab

This tab is used to identify new failure modes arising as a result of an investigation. The Failure Analysis tab in Assets (HSE) and Locations (HSE) can be used to conduct a full FMECA.

• Failure Mode Number – An integer field that automatically increments by one when a row is inserted.
• Failure Mode – A mandatory field (25 characters) for identifying the failure mode. There is no value list.
• Description – The description of the failure mode. This field can have a long description.
• Associated Function – The function associated with the failure mode. This field has a value list with values of Control Function, Monitoring Function, Plant Protection Function.
• Failure Mode Effect – The effect of the failure mode (100 characters).
• Criticality – The criticality of the failure mode. This field has a value list with values of High, Medium, Low.
• Recommendation – The recommended actions (if any) (100 characters).
• Action By – The person responsible for the recommended actions resulting from this failure mode. The field has a Select Value and Go To People (HSE).

Human Factors Sub Tab

This tab is used to analyse human factors, subdividing by category and sub category, to investigate safety observations reported on an incident.

Human Factors Details section

• Mandatory – A check box to indicate whether the initiating event requires a human factors analysis. When checked the Required By field becomes mandatory.
• Required By – The source of the need for a human factors analysis. This field is supported with a value list with values of Internal Regulation, External Regulation. The field is read-only but becomes mandatory when the Mandatory field is checked.
• Human Factors Lead – A person who is referenced in the PERSON table at a state of Active. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Name field.
• Name – The display name of the Human Factors Lead. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Human Factors Lead field.
• Target Completion – The target completion date for the human factors analysis.
• Actual Completion – The actual completion date of the human factors analysis.
• Approved – A check box to indicate that the human factors analysis has been approved. When selected it fills the Approval date.
• Approved By – Field is read-only until the Approved check box is checked when it becomes mandatory. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Name field below it. The Approved By has to be a person at Active state. It also has to be a person who is marked as being Authorized for Approval of Human Factors Analyses in the People (HSE) application – Details tab

• Name – Field is read-only until the Approved check box is checked when it becomes mandatory. The field is supported with a Select Value and Go To People (HSE). When selecting a person, it fills the Approved By field. The selected person has to be at Active state. It also has to be a person who is marked as being Authorized for Approval of Human Factors Analyses in the People (HSE) application – Details tab.
• Approval – A read-only field that is filled when the Approved check box is checked, but it is then enterable, and the date can be modified.

Human Factors Results table window

The Human Factors Results table window has three fields with value lists where the definition of the Human Factor, its Category and Sub Categories are defined using the action Add/Modify Human Factors Categories.

• Human Factor – The human factor has a value list with values of Organizational Failures, Preconditions for Unsafe Actions, Unsafe Act, Unsafe Supervision. It is a mandatory field. Entering a value will make the Category field enterable. Changing a value will blank the Category and Sub Category fields and make them read-only.
• Category – The category has a value list with values that are dependent on the Human Factor selected, it will be read-only until a Human Factor has been selected. For Organizational Failures they are Operational Process, Organizational Climate, Resource Management. It is a mandatory field. Changing this field will blank the Subcategory field.
• Subcategory – The subcategory of the human factor that may have contributed to the root cause of the incident or accident, for example adverse physiological state. It is a mandatory field which will remain read-only until a Human Factor and Category have been entered.
• Description – This field allows additional information to be added. There is also a long description field with rich text formatting.
• Action Required – This checkbox indicates whether further action is required. These can be entered in the Review Actions tab or by using the Create Action action. When using the Create Action action the new action can be seen in the Related Work Orders table window on the Related Records tab.
• Improvement Required – This checkbox indicates whether an Improvement is required. An Improvement record can be created using the action Create Improvement and then it can be found in the Related Work Orders table window on the Related Records tab. A Site must be entered on the main Investigation tab in order to create the improvement, it is because an improvement is a class of work order and the Site field is part of the unique key.

Actions

Create

Follow-up tickets and work orders or other types of records can be created from the investigation:

• Service Request
• Incident
• Investigation
• MOC Request (Management of Change)
• MOC
• Work Order
• Improvement
• Action
• Risk Assessment
• Solution
• Communication

Add/Modify Human Factors Categories

This dialog box is used for inserting, updating or deleting human factors, their categories and subcategories. This create a 3-level hierarchy, all fields are mandatory.

Crossover Domains

There are three crossover domains worth noting:

• PLUSGINC2TCK – Is used to copy additional fields from an Incident or Defect to an Investigation
• PLUSGOPLOG2INVESTI – Is used to copy additional fields from a Shift Log to an Investigation
• PLUSGSR2INVESTI – Is used to copy additional fields from a Service Request to an Investigation