This is an excerpt, you will find more detailed descriptions in the book.
The primary communication channel between IT and the users is the Service Desk function. When a user contacts Service Desk, in principle the issue can concern anything at all. It might be a question, an order or someone who needs help with an IT service which is not working. That is to say, a request of some kind which has to be dealt with by Service Desk. The Request Fulfilment process exists in order to manage issues which arrive at Service Desk from users.
All issues from users start in the Request Fulfilment process as a service request and are subsequently passed on to other processes if necessary. Service request (or request for service), has become an established generic name which describes orders or enquiries which arrive at Service Desk from users.
For example, a service request can be a user who has a question about how an application is used, a request to have a new application installed, or who wants to order a new telephone or PC.
The purpose of the process is to be responsible for the entire implementation of service requests. This is achieved through:
- Providing a channel where the users can order and obtain IT services, provided that they are available to order and that approval is in place, when required, from whoever is paying.
- Providing information about IT services and how they can be ordered.
- Processing orders for standard services
- Answering questions, receiving complaints and other comments
- Helping the users to access the right function with their issue.
All issues from users start as service requests. The broad definition means that Request Fulfilment often consists of several procedures, depending on what is being requested. Errors in the IT environment that are not known about must be passed on to the Incident Management process and proposals for improvement sent to the concerned function via the Continual Service Improvement process. What subsequently remains and must be completed within the process are support issues and orders.
For support issues it is of great importance that contact paths for escalation are documented for the applications that are part of Service Desk’s responsibility. That way the issue can be rapidly resolved or forwarded to the right support group.
In order to clearly delimit the scope of what can be ordered, each orderable component or IT service must be solidly documented with clear procedures for implementation and any approval necessary.
it is common for Service Desk to provide a web portal where the users can register their orders themselves. The process is subsequently more or less automated. An example is that a user orders an MS Project by entering the details in a web portal. An e-mail is subsequently dispatched to the manager concerned for approval. Once the issue is approved, the application is installed automatically on the user’s computer.
Here it is important that the automated version is retained as a part of the Request Fulfilment process and Service Desk, instead of being managed by another function within the IT department. The danger is that there is a difference between what the web portal provides and what is included in Request Fulfilment, with duplicated documentation, information and statistics as a result.
As everything that is managed within the Request Fulfilment process should be documented in procedures, it is part of the process’s responsibility to provide templates and procedures to establish new, orderable items and services. However, responsibility that the information is entered and is current lies with the service owner for the respective service.
Service request catalogue
A large part of the process’s remit is to manage orders from users. To be able to ensure fast and secure management, all orderable products and services must be documented with procedures which describe content, delivery time, production and any authorization necessary. What such a procedure describes is published for the users by Service Desk as a service request catalogue.
The difference to a service catalogue, which is described in more detail in the Service Catalogue Management chapter, is that the service catalogue sets out IT services which can be purchased by customers, while the service request catalogue sets out products and services which can be ordered by users. One example is the IT service ”workplace”, which is purchased by the business, this can then contain several additional applications which can be ordered individually by the users as a service request.
If what the user wants to order is not in the service request catalogue, the enquiry is managed as a proposal for improvement and is forwarded to the concerned function in the Continual Service Improvement process.