Quick start to creating and managing service requests and work orders

Any user with the service catalog manager role can create SRDs by using the Service-Catalog-Manager-console or the Service Request Designer console. Once the SRD is approved and deployed, a corresponding request becomes available in the online catalog of available requestable services on the Request-Entry-console. The Request Entry console facilitates the management of requests as the requests progress through their life cycle. For information about user roles and features, see Product-overview and Roles-and-permissions-in-BMC-Service-Request-Management.

An SRD expires when it reaches the end effective date. The Service Catalog Manager can re-enable the SRD by resetting the effective dates. When an SRD is in a Closed state, it cannot be deployed and is no longer displayed in the Request Entry console.

Although service requests inherit characteristics from the SRD on which they are based, the service requests go through various states to indicate their position in the life cycle.

The following diagram provides an overview of the process:

To learn more about SRDs and service requests, see Overview-of-service-request-definitions and Overview-of-service-requests.

Process overview for work orders

To learn about work orders, see Overview-of-work-orders.

The following diagram illustrates the work order management process:

Phase 1: Service request creation

When a user creates a service request for the IT department, for example, to fix the user's IT equipment or infrastructure, the 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 requires 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.