Learning about Work Order Management
Work orders are created to fulfill service requests, similar to the other fulfillment requests. They can be created as related records for an incident to request action that contributes to incident resolution, for the modification of a configuration item, or to correct a known error, which is created while doing a problem investigation. You can assign work orders to different support groups.
The following video (02:23) provides an overview of work order management.
Process overview
The following diagram illustrates the work order management process:
Phase 1: Service request creation
When a service request has been created by a user and the request is about a break-fix situation, then control is handed over to the incident management process.
The control is handed over to the change management process if:
- The service request causes a service to become unavailable or degraded during service hours
- The functionality of a service has become different
- The CMDB to require an update
In all other cases, the service request moves to Phase 2.
Phase 2: Service request fulfillment by using work orders
If the service request was created by a service catalog template containing the fulfillment workflow for implementing the service request, one or more work orders are created automatically and auto-assigned to the applicable support group.
If work orders are not automatically assigned to the applicable support group, or if the work order was created manually, the service desk analyst or specialist reviews the work orders that were created by the template and determines if additional tasks are required. If required, additional tasks are created and linked to the request.
Next, the service desk analyst or specialist determines which of the created work orders can be completed without involving others and assigns these work orders to self.
For each remaining work order, the service desk analyst or specialist determines who is the most appropriate team member to complete the work order, or lets the system auto-assign the work order to other people.
Work orders that should be completed by other service desk analysts or specialists are assigned to the following team members:
- The most appropriate team member in the same group as the service desk analyst or specialist handling the request
- The request manager of the target support group, if the most appropriate specialist is in another group
When assigning the work order as part of an entire request fulfillment workflow, the order in which these should be completed is considered. This ensures only those work orders are assigned that do not require other tasks to be completed first.
Phase 3: Service Request Closure
The service desk analyst or specialist responsible for handling the request completes the work order assigned to self. When required, additional tasks are created and assigned.
When all work orders are completed successfully, the service request is completed.
Work order lifecyle
The status of a work order indicates the current position of the record in its life cycle. You can configure the application to send out notifications during status transitions to alert users that certain events have occurred.
The following video (02:27) provides an overview of work order lifecycle.
Status values for work order
The following table describes the different status values in the work order lifecycle. When you change the status of a work order, you can include a status reason. Status reasons are available for some work order statuses, but not all.
Status | Description | Status reason | Select this status reason when... |
|---|---|---|---|
| Assigned | Initial status, or user saves a draft of the work order | Initial Status | you create a work order (default assignment value for new work orders) |
Awaiting Request Assignee | the Request Assignee is still to be assigned | ||
Pending | The following descriptions can apply:
| Client Hold | the client has asked the service desk to temporarily stop working on the work order |
| Client Additional Information Requested | the client needs to provide some information before the work order can be moved to the next status | ||
| Client Action Required | the client must take some action before the work order request can be moved to the next status | ||
| Support Contact Hold | the agent assigned to the incident request is currently working on other work orders or is awaiting response from someone in a second or third tier support group | ||
| Local Site Action Required | you are waiting for some type of action to be taken at the location where the work order was created | ||
| Purchase Order Approval | a purchase that requires approval is needed to move the work order to the next status. | ||
| Supplier Delivery | you are awaiting the delivery of a good or service from a supplier before the work order can be moved to the next status. | ||
| Third Party Vendor Action Reqd | you are waiting from action from a third-party vendor before the work order can be moved to the next status | ||
| Infrastructure Change | the work order cannot move to the next status until an infrastructure change occurs | ||
Waiting Approval | If work order approvals have been implemented, this status indicates that the work order has been submitted and is pending for approval. Note: Work order approvals are not implemented out of the box. | Not applicable | |
Planning | A work order is created, but no work has started. | Work not started | |
In Progress | The work order is being implemented. | Not applicable | |
Rejected | If work order approvals have been implemented, this status indicates that the approver has rejected the work order. Note: Work order approvals are not implemented out of the box. | Not applicable | |
Cancelled | The service request associated with this work order was cancelled, or the work order was cancelled. | Cancelled by Requester | the service request was canceled by the requester. |
| Cancelled by Support | |||
| Completed | When the last task on a work order is closed, the status of the work order is automatically set to Completed. | Successful | all tasks are set to Closed with the reason as Successful |
| Successful with Issues | one of the tasks is set to Closed but is not successful | ||
Closed | The following descriptions can apply:
Note: Users with one of the following permissions can modify a closed work order:
| Customer Close | when the customer has no issues and the work order is closed |
System Close | when the service request has been in Completed status for 15 days, the system closes the work order | ||
| System Close with Issues | when the service request is in Completed status but with some issues |
Work order lifecycle examples
The following diagrams show examples of status transitions in the work order life cycle.
Note
The Waiting Approval and Rejected statuses shown in the following examples are provided with the product, but no approval process is implemented out of the box. If necessary, you can create your own custom approval process and integrate it with the Work Order Management application.
The following example illustrates status transitions for the Assigned, Pending, and Waiting Approval states.
The following example illustrates status transitions for the Planning and In Progress states.
Note
If a service request consists of a single work order, moving the work order from a status of Completed back to In Progress does not result in the status of the Request also being reset to In Progress. When the work order's status progresses, errors result.
Testing your knowledge
Check your knowledge. See if you can answer each question. Click the questions to view the answer.
Do you want to learn more?
Learn what information you can record for work orders in Overview of information displayed on a ticket in Smart IT.
When you're ready to get started, see Creating work orders.
To know more about work order roles and permissions, see Work order roles and permissions.
Comments
Log in or register to comment.