There are two ways in which maintenance orders are created; a planned maintenance event generates the maintenance order via a pending task or the maintenance order is created manually. With the manual creation of maintenance orders it is possible to plan a maintenance visit ahead of time. The planners of the visit can then create the maintenance order for the visit at any time prior to the actual visit occurring and can add and remove tasks (i.e., pending tasks, convenience tasks) from the work package as the needs and requirements for the visit are established.
When distributing tasks you can create a package of tasks to be distributed to a maintenance order for execution at a workshop. In this work package (maintenance order) you can only distribute tasks for the same top serial or a serial in its structure. The tasks on the maintenance order will be distributed with the same planned start and finish dates and with the same distribution type.
When the maintenance order is distributed with the distribution type Simplified Work Order, all tasks connected to the maintenance order should be followed up on the maintenance order in IFS/Vehicle Information Management (IFS/VIM). When the distribution type Work Order is used to distribute the maintenance order, all tasks connected to the order will be created as a separate work order in IFS/Work Order Management and must be processed there. When the distribution type Execution Logic Structure is used, a work order structure will be created in IFS/Work Order Management based on the Execution Logic Structure (ELS) created for the maintenance order.
For information on how to process a work order in IFS/Work Order Management, refer to Work Order. For information on work order distribution and handling in IFS/VIM, refer to Work Orders for VIM Serials.
The following is a summary of the main actions that can be performed on a maintenance order:
The following table shows a description of each status on the maintenance order:
Status | Description |
New | The initial status used to represent an available maintenance slot. When a maintenance order is created manually, it will automatically receive this status. In this status the maintenance order must contain, at the least, the workshop ID and planned start and end dates. |
Initial Scope Definition | The status used when defining the scope of the maintenance order, i.e., in terms of identifying the tasks to be included. |
Under Preparation | The status in which operations can be connected to tasks and Execution Logic Structure (ELS) structures are created. |
Released | The status during which work orders for tasks with distribution types Work Order and Execution Logic Structure are created. |
Started | This status is used to indicate that work has started on the maintenance order. |
Work Done | This status is used to indicate that all connected tasks are in either the Work Done or Finished status. When the maintenance order is in this status, sign off activities can be performed. |
Finished | This status is used to indicate that the maintenance order has been signed off and is finished. |
Cancelled | When a maintenance order is cancelled, all connected tasks must be cancelled as well. This status is used when the maintenance order is no longer applicable. |
The following is a status diagram of the maintenance order:
The following table shows a description of each status on a task (either a pending task or a convenience task):
Status | Description |
New | The initial status used to represent an existing task that is not yet planned to be executed. |
Planned in Scope | In this status the task has been planned on a maintenance order, but no work order has yet been created. |
Incomplete | In this status the task has been planned on a maintenance order, but no operations have been defined for the task. |
Under Preparation | In this status operations have been connected to tasks on the maintenance order. |
Released | Depending on the distribution type selected, work orders will be created with connected operations, materials, etc. when the task is released. |
Started | This status is used to indicate that work has started on at least one of the connected operations. |
Work Done | This status is used to indicate that all operations have reached the Work Done status or a higher status. Sign off can be performed on tasks in this status. Note: It is possible to reopen a maintenance task if, for instance, unplanned work is required and you need to add more operations to the task. When reopened, the task is set to the Started status. |
Finished | This status is used to indicate that the task has been signed off and is finished. When the task reaches this status, it will be transferred to the serial order history. |
Cancelled | When a task is cancelled, the status of the task will be changed to New and it will be disconnected from the current maintenance order. |
The following is a status diagram of the task:
A maintenance order can be created weeks or even months ahead of time. The maintenance order can be created manually in an initial state to represent an available maintenance slot without any tasks yet being identified. In this initial state the maintenance order can be created with just the workshop and planned start and finish dates. As you continue with the planning of the order, you can add and remove tasks from the work scope as the needs and requirements for the visit are established. When the scope is defined and ready for execution, the maintenance order can be released. At this time, a snapshot of the maintenance order can be taken to retain as a reference in terms of the initial request for the maintenance visit versus the final request.
You can assign additional tasks to the ongoing work scope. If tasks that do not have defined operations exist, you must connect valid instructions to these tasks. For instance, if non routines have been discovered or condition measurements have been performed on an ongoing work scope, tasks may have been generated without any predefined operations. For such tasks, operations must be defined before you can proceed with the task.
When you are completing a maintenance order, you have the option of defining additional task information directly on the maintenance order. Furthermore, if sign off requirements have been defined on the maintenance order, sign off must be performed before completing the maintenance order.
When a maintenance order has being signed off and set to the Finished status, the maintenance order becomes historical and is transferred to the maintenance order history. The following information is retained on the historical maintenance order:
General information on the maintenance order, e.g., the distribution type used to distribute the order, the workshop at which the work is to be performed, the grouping ID used to generate Execution Logic Structures, and if the maintenance order was cancelled, the cause for canceling.
Information on the tasks that were executed or cancelled on the maintenance order.
Information on any non routine work that was discovered during execution of the scheduled maintenance and reported on the maintenance order.
Information on any sign off requirements defined on the maintenance order.
Information on any snapshots taken of the maintenance order at various stages.
Journal entries generated when key actions were performed on the maintenance order.
The snapshots of a maintenance order will contain information of the maintenance scope throughout the planning stages up until execution. There are no restriction on when or how many snapshots can be taken. A snapshot can be taken, for instance, when releasing the maintenance order once the scope is defined and ready for execution. This snapshot can then be used as a reference in terms of the initial request for the maintenance visit as opposed to the final request.
The snapshot will contain all tasks included on the maintenance order as well as all instructions (task cards) connected to each task.
The maintenance order journal is used to retain information on key changes to a maintenance order. The following changes on a maintenance order lead to the automatic creation of a journal entry:
Entries created for the above-mentioned changes are sorted into three valid journal categories: Info, Task Removed and Changed Grouping ID. Additional information on the journal entry is displayed in the journal text for each record. Journal entries will be generated when the following changes take place:
The content of the journal entries differs depending on the cause for their generation. They are as follows: