Request Fulfilment and Service Requests

The Generic Service Request process provided with Service Desk delivers a number of options for usage. Most of this process is driven from the values set on the Service that you select, so make sure that you correctly define your Services. One way to do this is to define a Service Lifecycle process for the life of your Services, and to ensure that the correct values are considered and reviewed before a Service is published. As a part of this process, add an appropriate Service Description that is appropriate to display both to analysts and to end-users. You could use TWO fields: one for an IT description and one for a Business description, and design your Windows and views so that analysts see both the IT and the Business description in the analyst interfaces, and the end-user sees only the Business description in Self Service. You can also include in this field instructions for how to access the service once it has been fulfilled.

For more information about the Generic Service Request process, see Request Management: Generic Service Request.

When you are planning how to distribute and publish services, remember that the Service Catalog Administration component enables you to specify exactly which users, groups, and roles a Service is published to. This controls who can see the Service in the Catalog, but does not define whether or not the Service can be delivered to them: this is defined by the underlying process. For example, a member of the Design department may be able to request Technical Drawing software, but that person's manager may reject the request because the department does not have enough budget, or because that person has not yet been trained. Similarly, the license/stock team may pause or reject the request because there are insufficient licenses or because an additional purchase is required. This is all controlled through the Request process, so it is important to understand – and evolve – the behavior that your business requires.

You could choose to isolate Service Requests from the rest of the Service Desk, leaving Request Management operating separately from everything else. However, a bigger benefit comes from carefully ensuring that the Request is fully integrated with the entire ITSM activity view. For example, from Request processes you could:

• display a tab of all outstanding Incidents, Problems and Changes for the Requestor
• display a tab of all Events and availability information for the selected Service
• create new Incidents, Problems, Changes or other processes as actions in the Request process at the appropriate point.
  A simple solution for this would be to add manual Create Change actions at various Request statuses. However, a better approach is to add an automatic Create Change action to your Request process at the place that a Change is required. For example, a Request for Access to a new virtual environment may require a confirmation that the current capacity of that platform can accommodate the additional usage. If more capacity is needed, then a Change is raised to request expansion of that platform. It is important that the Request is not fulfilled until that Change is complete. You can use Process Designer to design your processes in this way.

Tool integration for automated software deployment

Service Desk integrates with Ivanti Endpoint Manager (LDMS) through Ivanti Process Manager (LPM) to provide automatic request fulfillment. The automation platform provided with Service Desk contains automation processes that respond to Requests at a specific status, and then select from the Request the relevant software package, the target computer and other supporting information, before passing that information to Endpoint Manager for automatic deployment. When the software has been deployed successfully, LPM passes the result to Service Desk and the Request is updated. The Software Request process included with Service Desk provides the basis for this integration.

For more information about the Software Request process, see Request Management: Software Request.

From a service-centric perspective you may also want to consider the Release of the Service itself. This transition into Operational status is driven by the Service lifecycle, but remember that you can modify the default queries in the Service Catalog component to restrict the Services that appear to be only those that are at a Released or Live status. This prevents users from requesting Services that are not yet available.