A preventive maintenance plan (PM plan) consists of planned maintenance actions. Each maintenance action is generated into work orders. A PM plan can be established for any equipment or linear asset object. Each PM action contains information about under what condition a work order should be generated (based on calendar, event and/or condition), what type of competency is required for the task, what material is required for the task, etc. The PM Plan can be modified at any time in order to optimize the plan, based on analysis of past maintenance actions such as historical work orders. Changes in the maintenance plan will affect the Purchase Requisitions generated from the Scheduled Task (Create purchase demands for PM Actions) and may result in being automatically removed or being marked as unnecessary lines.
The length of the PM plan, i.e., the number of planned maintenance actions generated in the PM plan, depends on the life span of the PM Action revision (PM action revision). For more information about valid PM Action revisions, please refer to the following online help document: PM Actions.
A PM Action revision can be connected to a Generated Work Time Calendar defined in IFS/Application Services. This feature helps to make sure that the planned dates of the generated PM plan lines will always fall on a working day. A PM plan is generated based on intervals, and therefore, the planned date of a PM plan line could fall on a weekend or some other holiday. Connecting a calendar prevents this from happening. When each PM plan line is generated, the planned date of that line is checked against the dates in the connected calendar, and if the date is not found, the closest working day that is next in line is selected as the planned date.
Inventory Part Demand Published check box will be checked if any inventory parts has been defined for an Active PM action in the maintenance plan lines up to the least value of either the Valid To date, PM Plan Horizon or date depicted by addition of days in PM Inventory Part Demand Horizon on Site/Maintenance tab to the system date from the Valid From date of the PM action or system date.
A maintenance performed on an equipment based on a calendar schedule. In other words, time is the maintenance trigger for this type of maintenance. The calendar trigger consists of a start time and an interval. A PM plan is then created with dates for each future generation.
If the PM action is set to Performed Date Based - Yes, the maintenance plan is to be adjusted in time, based on the actual completion date of the last work task that was generated from the PM action. However, when you run a PM Action with Performed Date Based = 'Yes', only one Work Order will be allowed to be generated at a time.
A maintenance triggered based on the actual condition of an equipment. To determine the condition of an object, readings must be done and the object parameter's measurements must be reported.
If any cumulative condition is registered, one condition line is shown on the Maintenance Plan tab even before any measurement is registered. When two or more accumulated measurements are registered, it generates a condition-based forecast plan. Here, the Due (planned) Dates will be predicted under the assumption of linear use of equipment, while Planned Values will be calculated based on either;
However, the Due (planned) dates will be predicted under the assumption of linear use of equipment.
Here, the Planned Values will be calculated by adding the maintenance interval to the measurement at maintenance (latest measurement at the time the last work task is completed).
For example;
Here, the Planned Values will be calculated based on a predicted value at maintenance. There are two formulas to predict the Value at Maintenance.
Formula 1 - If the work finish date is between two measurements, the estimated value at maintenance will be derived using interpolation.
Formula 2 - If the work finish date falls before/ after all measurements recorded, the estimated value at maintenance will be derived based on the "Running Average".
Note: The Running Average is calculated based on the average usage per day under the assumption of linear use of the equipment object.
The Planned Values will be calculated based on above formulas only when accumulated condition-based PM action is set to Performed Value Based = Yes. User has the option of choosing which method to use to get the Value at Maintenance, through the Condition Forecast Configuration in the PM action/General tab. The DEFAULT value will be set as (a) Last Measurement at Maintenance.
For PM Actions, it is also possible to distribute jobs and work lists, registered on the PM Action/Jobs and Templates and PM Action/Work List tabs, to all occurrences in the PM plan. This feature is available on all PM actions.
If the checkbox is enabled, the distribution will take place when the PM plan is created for the first time, or when it is re-generated due to the changes in the calendar parameter, jobs, or work lists. Once distributed, the jobs and work lists can be scheduled on the PM plan level, i.e., for a single occurrence in the PM plan.
The details that can be planned are the date and time at which the job and work list is to start and the employee in-charge of the job and work list.
Employee signatures refer to the signature of the employee who is responsible for executing the PM action, jobs, and work list.
These signatures are inherited in levels. The levels can be broken down as follows, where Level 1 is at the top of the hierarchy. (The tabs are located in both the PM Action windows, unless mentioned otherwise):
The signatures entered at the top level will be inherited by the levels below, but not vice versa.
The inheritance of employee signatures works in the following manner. When a signature is changed at the top level, the system will replace all occurrences of that signature with the new one. Note: Signatures are replaced but not updated. Updating signatures at the top level would result in losing all the employee signatures previously planned at the levels below. Replacement of signatures prevents losing such information.
For example, consider five employees with the following signatures: ALAIN, BRIAN, DAMON, JEFF, and MARK. A PM action with four PM plan lines: PMP1, PMP2, PMP3, and PMP4. The PM action has a job and a related work list connected to it (which is distributed to the four PM Plan lines). The table below illustrates how the different signatures are inherited.
| Level Changed | Change Performed | L1 | L2 | L3 | PMP1 | PMP2 | PMP3 | PMP4 | Explanation | ||||
| L4 | L5 | L4 | L5 | L4 | L5 | L4 | L5 | ||||||
| L4 | Enter ALAIN | — | — | — | A* | A | — | — | — | — | — | — | L4 and L5 applies to a single PM plan line. In this case, the change is made on PMP1. L5 inherits the signature from L4. |
| L4 | ALAIN --> BRIAN | — | — | — | B | B | — | — | — | — | — | — | All occurrences of ALAIN is replaced with BRIAN. |
| L5 | BRIAN --> DAMON | — | — | — | B | D | — | — | — | — | — | — | Only the signature at L5 is changed. |
| L4 | BRIAN --> MARK | — | — | — | M | D | — | — | — | — | — | — | Change is not inherited to L5 because no occurrences of BRIAN could be found below L4. |
| L3 | Enter ALAIN | — | — | A | M | D | A | A | A | A | A | A | ALAIN is inherited by all PM plan lines (L4 and L5) except for the first line where signatures have previously been defined. |
| L5 | ALAIN --> JEFF | — | — | A | M | D | A | J | A | A | A | A | Change is made on PMP2 and takes place only at L5. |
| L3 | ALAIN --> BRIAN | — | — | B | M | D | B | J | B | B | B | B | BRIAN is inherited by all levels which previously had ALAIN. |
| L3 | Remove BRIAN | — | — | — | M | D | — | J | — | — | — | — | All occurrences of BRIAN is removed. |
| L2 | Enter ALAIN | — | A | A | M | D | A | J | A | A | A | A | ALAIN is inherited by L3, L4, and L5. A change to the signature will also be inherited in the same way. |
| L1 | Enter BRIAN | B | A | A | M | D | A | J | A | A | A | A | BRIAN is not inherited by any of the other levels because signatures have been previously defined on these levels. |
| L1 | Remove ALAIN | B | — | — | M | D | — | J | — | — | — | — | All occurrences of ALAIN is removed. BRIAN is still not inherited by the other levels even though the levels do not contain any signatures. This is because there are no occurrences to replace. The same applies to all other levels. In order to overcome this obstacle, BRIAN should be removed from L1 as shown below. |
| L1 | Remove BRIAN | — | — | — | M | D | — | J | — | — | — | — | All occurrences of BRIAN is removed |
| L1 | Enter BRIAN again | B | B | B | M | D | B | J | B | B | B | B | BRIAN is inherited by all the levels where a signature was not present. |
* A - ALAIN, B - BRIAN, D - DAMON, J - JEFF, M - MARK
A Grouped PM Action with several Work List lines will be generated into a Work Order with Work Tasks. There can also be several grouped PM Actions included into same Work Order with Work Tasks. And there can be instances where these work tasks have connected work task steps. When the work order work tasks or work task steps statuses change, it will also have an influence in how the status against the Maintenance Plan line will be adjusted on PM side. The below columns on the Maintenance Plan window reflect the Work task or task step statuses against each maintenance plan line;
| Last Work Task Completed | This checkbox will be set if the last Work Task that
origin from the PM is set to status Work Done. Note: When updating the Actual Finish Date of the last Work Task of the latest Work Order, the Last Work Task Completion Date in the respective PM Maintenance plan line will also be updated. A journal note will be created on respective PM Actions to record such modifications. |
| Last Work Task Completion Date | The date on which the last Work Task that origin from the PM is set to status Work Done. |
| Last Work Task Step Completed | This checkbox will be set if the last Work Task step on the PM is set to status Done. |
| Last Work Task Step Completion Date | The date on which the last Work Task Step is set to
status Done.
Note: When the system parameter DEF_TASK_STEP_STATUS = "Done", the work task steps will be created in status "Done". Then this date will be updated only when the work task is set to status Work Done. |
When several PM actions are merged into task steps within same task, the last work task and last work task step dates will be set on the Maintenance Plan lines for all PM actions included in the merge.
If PM action has Performed Date Based or Performed Value Based option ON, the Maintenance Plan for coming occurrences will be adjusted based on the date on which the last work task is set to Work Done.