Information Management

Closure

Fulfilment

The actual fulfilment activity will depend upon the nature of the Service Request. Some simpler requests may be completed by the Service Desk, acting as first-line support, while others will have to be forwarded to specialist groups and/or supplier s for fulfilment.

Some organizations may have specialist fulfilment groups (to ‘pick, pack and dispatch’) – or may have outsourced some fulfilment activities to a third-party supplier(s). The Service Desk should monitor and chase progress and keep user s informed throughout, regardless of the actual fulfilment source.

When the Service Request has been fulfilled it must be referred back to the Service Desk for closure. The Service Desk should go through the same closure process as described earlier in paragraph 4.2.5.9 – checking that the user is satisfied with the outcome.

4.3.6 Triggers, input and output/inter-process interfaces

Most requests will be triggered through either a user calling the Service Desk or a user completing some form of self-help web-based input screen to make their request. The latter will often involve a selection from a portfolio of available request types.The primary interfaces with Request Fulfilment include:

• Service Desk/ Incident Management: Many Service Requests may come in via the Service Desk and may be initially handled through the Incident Management process. Some organizations may choose that all requests are handled via this route – but others may choose to have a separate process, for reasons already discussed earlier in this chapter.
• A strong link is also needed between Request Fulfilment, Release, Asset and Configuration Management – as some requests will be for the deployment of new or upgraded component s that can be automatically deployed. In such cases the ‘release’ can be pre-defined, built and tested but only deployed upon request by those who want the ‘release’. Upon deployment, the CMS will have to be updated to reflect the change. Where appropriate, software licence checks/updates will also be necessary.

Where appropriate, it will be necessary to relate IT-related Service Requests to any incident s or problem s that have initiated the need for the request (as would be the case for any other type of change).

Request Fulfilment is dependent on information from the following sources:

• The Service Requests will contain information about:
• What service is being requested
• Who requested and authorized the service
• Which process will be used to fulfil the request
• To whom it was assigned to and what action was taken
• The date and time when the request was logged as well as the date and time of all actions taken
• Closure details.
• Requests for Change: In some cases the Request Fulfilment process will be initiated by an RFC. This is typical where the Service Request relates to a CI
• The Service Portfolio, to enable the scope of agreed Service Request to be identified
• Security Policies will prescribe any controls to be executed or adhered to when providing the service, e.g. ensuring that the requester is authorized to access the service, or that the software is licensed.

Дата добавления: 2014-12-23