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. A maintenance action can be a separate PM action or a route PM action. 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 PMA revision (PM action revision). For more information about valid PMA revisions, please refer to the following online help document: PM Actions.
A PMA 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.
For Separate PM Actions, it is also possible to distribute jobs and operations, registered on the Separate PM Action/Jobs and Separate PM Action/Operations tabs, to all occurrences in the PM plan. This feature is controlled by the system parameter PM_PLAN_OPERATION that can be set to TRUE or FALSE in IFS/Application Services.
If the parameter is set to TRUE, 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 operations. Once distributed, the jobs and operations 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 operation is to start and the employee in-charge of the job and operation.
Scheduling on the PM plan level is not allowed if the parameter is set to FALSE.
Employee signatures refer to the signature of the employee who is responsible for executing the PM action, jobs, and operation.
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 Separate PM Action and d d Route PM Action windows, unless mentioned otherwise):
The signatures entered at the top level will be inherited by the levels below, but not vice versa. Note: The final two levels are only applicable if the PM_PLAN_OPERATION system parameter is set to TRUE.
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 operation 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