Service Operations

1Introduction 2Serv. Mgmt. 3Principles 4Process 5Activities 6Organization 7Consideration 8Implementation 9Issues AAppendeces

4. Service Operation Processes

4.1EVENT 4.2INCIDENT 4.3REQUEST FULFILLMENT 4.4PROBLEM 4.5 ACCESS 4.6OTHER OPERATIONS

4.3 Request Fulfillment

The term 'Service Request' is used as a generic description for many varying types of demands that are placed upon the IT Department by the users. Many of these are actually small changes - low risk, frequently occurring, low cost, etc. (e.g. a request to change a password, a request to install an additional software application onto a particular workstation, a request to relocate some items of desktop equipment) or maybe just a question requesting information - but their scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident and Change Management processes.

4.3.1 Purpose, Goals and Objectives
Request Fulfillment is the processes of dealing with Service Requests from the users. The objectives of the Request Fulfillment process include:

4.3.2 Scope
The process needed to fulfil a request will vary depending upon exactly what is being requested - but can usually be broken down into a set of activities that have to be performed. Some organizations will be comfortable to let the Service Requests be handled through their Incident Management processes (and tools) - with Service Requests being handled as a particular type of 'incident' (using a high-level categorization system to identify those 'incidents' that are in fact Service Requests). Note, however, that there is a significant difference here - an incident is usually an unplanned event whereas a Service Request is usually something that can and should be planned!

Therefore, in an organization where large numbers of Service Requests have to be handledR, and where the actions to be taken to fulfil those requests are very varied or specialized, it may be appropriate to handle Service Requests as a completely separate work stream - and to record and manage them as a separate record type.

This may be particularly appropriate if the organization has chosen to widen the scope of the Service Desk to expand upon just IT-related issues and use the desk as a focal point for other types or request for service - for example, a request to service a photocopier or even going so far as to include, for example, building management issues, such as a need to replace a light fitment or repair a leak in the plumbing.

4.3.3 Value to Business
The value of Request Fulfillment is to provide quick and effective access to standard services which business staff can use to improve their productivity or the quality of business services and products.

Request Fulfillment effectively reduces the bureaucracy involved in requesting and receiving access to existing or new services, thus also reducing the cost of providing these services. Centralizing fulfillment also increases the level of control over these services. This in turn can help reduce costs through centralized negotiation with suppliers, and can also help to reduce the cost of support.

4.3.4 Policies, Principles and Basic Concepts
Many Service Requests will be frequently recurring, so a predefined process flow (a model) can be devised to include the stages needed to fulfil the request, the individuals or support groups involved, target timescales and escalation paths. Service Requests will usually be satisfied by implementing a Standard Change (see the Service Transition publication for further details on Standard Changes). The ownership of Service Requests resides with the Service Desk, which monitors, escalates, dispatches and often fulfills the user request.

4.3.4.1 Request Models
Some Service Requests will occur frequently and will require handling in a consistent manner in order to meet agreed service levels. To assist this, many organizations will wish to create pre-defined Request Models (which typically include some form of pre-approval by Change Management). This is similar in concept to the idea of Incident Models already described in paragraph 4.2.4.2, but applied to Service Requests.

4.3.5 Process Activities, Methods And Techniques
4.3.5.1 Menu Selection
Request Fulfillment offers great opportunities for self-help practices where users can generate a Service Request using technology that links into Service Management tools. Ideally, users should be offered a 'menu'-type selection via a web interface, so that they can select and input details of Service Requests from a pre-defined list - .appropriate expectations can be set by giving target delivery and/or implementation targets/dates (in line with SLA targets). Where organizations are offering a self-help IT support capability to the users, it would make sense to combine this with a Request Fulfillment system as described.

Specialist web tools to offer this type of 'shopping basket' experience can be used together with interfaces directly to the back-end integrated ITSM tools, or other more general business process automation or Enterprise Resource Planning (ERP) tools that may be used for management of the Request Fulfillment activities.

4.3.5.2 Financial Approval
One important extra step that is likely to be needed when dealing with a service request is that of financial approval. Most requests will have some form of financial implications, regardless of the type of commercial arrangements in place. The cost of fulfilling the request must first be established. It may be possible to agree fixed prices for 'standard' requests - and prior approval for such requests may be given as part of the organization's overall annual financial management. In all other cases, an estimate of the cost must be produced and submitted to the user for financial approval (the user may need to seek approval up their management/financial chain). If approval is given, in addition to fulfilling the request, the process must also include charging (billing or cross-charging) for the work done - if charging is in place.

4.3.5.3 Other Approval
In some cases further approval may be needed - such as compliance-related or wider business approval. Request Fulfillment must have the ability to define and check such approvals where needed.

4.3.5.4 Fulfillment
The actual fulfillment 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 suppliers for fulfillment.

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

4.3.5.5 Closure
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 / Interprocess 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 Fulfillment include:

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

4.3.7 Information Management
Request Fulfillment is dependent on information from the following sources:

4.3.8 Metrics
The metrics needed to judge the effectiveness and efficiency of Request Fulfillment will include the following (each metric will need to be broken down by request type, within the period):

4.3.9 Challenges, Critical Success Factors and Risks
4.3.9.1 Challenges
The following challenges will be faced when introducing Request Fulfillment:

4.3.9.2 Critical Success Factors
Request Fulfillment depends on the following Critical Success Factors:

4.3.9.3 Risks
Risks that may be encountered with Request Fulfillment include:

[To top of Page]


Visit my web site