ITIL Intermediate OSA - Request Fulfillment Tutorial

Request Fulfillment

Welcome to lesson 4 ‘Request Fulfillment’ of the ITIL Intermediate OSA Tutorial, which is a part of the ITIL Intermediate OSA Certification Course. This lesson is about Request fulfillment and its features.

Let us begin with the objectives of this lesson.

Objectives

By the end of this ‘Request Fulfillment’ lesson, you will be able to:

• Explain the request fulfillment process and how it contributes to OSA.

• Understand the complete overview of the objectives, scope, and importance of request fulfillment as a process to generate business value.

• Explain the policies, principles, concepts, activities, methods, request models and techniques in relationship to OSA practices and information management.

• Discuss the metrics used in request fulfillment.

Let us learn about the purpose and objective of Request Fulfillment in the next section.

Request Management - Purpose and Objectives

The purpose of Request Fulfillment would be actively managing the lifecycle of all service requests from the users.

The objectives of Request Fulfillment process are:

• to provide a channel for users to request and receive standard services for which a predefined approval and qualification process exists

• to provide information to users and customers about the availability of services and the procedure for obtaining them

• sourcing and delivering the components of requested standard services (e.g., licenses and software media)

• to assist with general information, complaints or comments

Let’s look into the scope of request fulfillment in the next section.

Request Management - Scope

The process needed to fulfill a request will vary depending on exactly what is being requested. In some organizations, the Service Requests will be handled through their Incident Management processes. However, this may not always be appropriate as an Incident is usually an unplanned event whereas a Service Request is usually something that can and should be planned!

It may be appropriate to handle Service Requests as a completely separate work stream, particularly if the organization has chosen to widen the scope of the Service Desk to expand upon the just IT-related issue and use the Service Desk as a focal point for other types of requests for service.

For example, a request to service a photocopier or even going so far as to include, for example, building management issue, such as a need to replace a light fixture or repair a leak in the plumbing.

Next, we will learn how request fulfillment adds value to the business.

Request Management - Value to Business

How does request fulfillment add value to the 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 their 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.

Centralization 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.

Let’s move on to learn about the policies of request fulfillment.

Request Management - Policies

As we have seen every process has its own set of policies. Likewise, let us see the policies stated for Request Fulfillment process:

• The activities used to fulfill a request should follow a predefined process flow (a model)

• The ownership of service request should reside with a centralized function

• Service requests that impact CIs should usually be satisfied by implementing a standard change

• All requests should be logged and should be authorized before their fulfillment

• Fulfillment of requests should take place under an agreed set of criteria and there should be clear communication for making requests and determining the status

In the next slide, we will learn about the key concepts and terms of request fulfillment.

Request Management - Principles and Key Concepts

Let us go through some of the keywords or key concepts of Request Fulfillment process.

To start, let us understand what are request models?

Request Model

Some Service Requests will occur frequently and will require handling consistently in order to meet agreed service levels. To assist this, many organization will wish to create predefined request models( which typically include one or more standard changes in order to complete fulfillment activities). This is similar in concept to the idea of incident models.

Menu Selection

It is basically users being offered a “menu”- type selection via a web-based interface or request portal so that they can select and input details of service requests from a predefined list.

Request Status Tracking

It defines that Requests should be tracked throughout their lifecycle to support proper handling and reporting on the status of requests.

Prioritizing Requests

All service requests should follow a standard set of criteria for assessing their priority

Escalating Requests

It means that in some situations it may be necessary to escalate requests to resolve certain situations or take further actions that are not part of the standard set of fulfillment activities.

Financial Approval

It is the concept of getting approval from the concerned finance. Service requests will often need financial approval. The cost of fulfilling the request must first be established. It may be possible to agree fixed prices for “standard” requests or an estimate of the cost must be produced and submitted to the user for financial approval.

Other Approvals

In certain circumstances, further approval may be required such as compliance-related or wider business approvals. Request Fulfillment must have the ability to define and check such approvals where needed.

Coordination of Fulfillment activities

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. The Service Desk should monitor and chase progress and keep users informed throughout, regardless of the actual fulfillment source.

Closure

When the Service Request has been fulfilled it must be referred back to the Service Desk for closure. The Service Desk should check that user is satisfied with the outcome.

So far, we have learned the cycle of fulfilling the request. Next, we will look into the activities and technology.

Request Fulfillment Process Activities

Let us see different activities of the Request Fulfillment process:

Receiving Request

Fulfillment work on service requests should not begin until a formalized request has been received. Service Requests should mostly come from the service desk, but it is not unusual to have requests that come in from other sources such as RFCs, email, an automated web ordering interface or phone call.

Request Logging and Validation

All service requests must be fully logged and date/time stamped, regardless of whether they are raised through a service desk, RFC, telephone call or email. Requests must also be initially validated. This includes validating the source of the request and that the request is within the scope of the IT services being offered.

Request Categorization

Part of the initial logging must be to allocate suitable request categorization coding so that the exact type of the request is recorded. This will be important later when looking at request types/frequencies to establish trends for use in determining how services are being used, which requests are the most frequently asked for and other ITSM activities.

Request Priority

Another important aspect of logging every request is to agree and allocate an appropriate prioritization code as this will determine how the service request is handled both by support tools and support staff. Request Authorization

No work should take place to fulfill a request until it has been properly authorized. Simple authorizations can take place via service desk alone or as pre-authorized requests based on the request type.

Request Review

At this stage, the request is reviewed to determine the proper function that will fulfill it. In many cases, the service desk function may perform all needed fulfillment activities. In other cases, the requests may be escalated to other functions that perform specialized activities to fulfill them.

Request Model Execution

As functions undertake activities to fulfill a request, a request model should be used that documents a standard process flow, roles and responsibilities for fulfilling it. This ensures that a repeatable and consistent set of actions are always undertaken for each request type that minimizes the risks for delays or failures as requests are fulfilled.

Request Closure

Once service request activities have been completed, the service desk should be notified of the completion status. The service desk should then check that the request has been fulfilled and that users are satisfied and willing to agree that the request can be closed.

Rules for reopening requests

It is wise to have predefined rules about if and when a closed service request can be reopened. It might make sense, for example, to agree that if the request needs to be reopened but that beyond this point a new service request must be raised.

In the next slide, we will look at Triggers of request fulfillment.

Request Fulfillment Triggers

Most requests will be triggered by either a user calling the Service Desk or a user completing some form of self-help web-based input screen to make their request. Many Service Requests may come via the Service Desk and may be initially handled through the Incident management process.

There is a strong link needed between Request Fulfillment, Release and Configuration Management – as some request will be for the deployment of the new or upgraded component that can be automatically deployed. Upon deployment, the CMS will have to be updated to reflect the change. Where appropriate software license check (or) updates will also be necessary.

Let us know learn about inputs and outputs for request fulfillment process in the next section.

Request Fulfillment Inputs and Outputs

As we all know every process has its own set of inputs and outputs.

Inputs for the Request Fulfillment process could be:

• Work Requests

• Authorization forms

• Service Requests

• RFCs

• Requests from various sources such as phone calls, web interfaces or email

• Request for information

Outputs of the Request Fulfillment process could be:

• Authorized/rejected service requests

• Request fulfillment status reports

• Fulfilled service Requests

• Incidents (rerouted)

• RFCs/Standard Changes

• Asset/ CI updates

• Updated Request records

• Closed Service Requests

• Canceled Service Requests

Next, we will look at the interfaces of request fulfillment.

Request Fulfillment Interfaces

The primary interfaces with Request Fulfillment lie with Service Desk or 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 may vary. A strong link is also needed between Request Fulfillment, Release, Asset and Configuration Management – as some requests will be for the deployment of new or upgraded components that can be automatically deployed.

In the next section, we will learn about information management of request fulfillment.

Request Fulfillment - Information Management

Information is very critical for the functioning of any process/business. Request fulfillment is dependent on information.

The Service Requests will contain information about:

• What service is being requested

• Who requested and authorized the service

• Which process will be used to fulfill the request

• To whom it was assigned to and what action was taken

• The date and time when the request was logged and the last step will be closure.

• In some cases, the Request Fulfillment process will be initiated by an RFC. This is typical where the Service Request relates to a CI.

• The Service Portfolio is 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. Merely managing information will not ensure smooth functioning of the IT service. In addition to this, the process needs to be measurable.

The next slide talks about request fulfillment metrics.

Request Fulfillment - Metrics

Metrics are essential to judge the effectiveness and efficiency of Request Fulfillment. Some of the metrics are:

• Total number of Service Requests (as a control measure)

• Breakdown of service requests at each stage (e.g., logged, WIP, closed, etc.)

• The size of the current backlog of outsourcing Service Requests

• The mean elapsed time for handling each type of Service Request

• The number and percentage of Service Requests completed within agreed target times

• The average cost per type of Service Request

• Level of client satisfaction with the handling of Service Requests (as measured in some form of satisfaction survey).

Let us now look at the challenges of request fulfillment.

Request Fulfillment Challenges

Every process has to overcome its challenges. Here are some of the common types of challenges that you may encounter in accomplishing Request Fulfillment:

• Clearly defining the type of requests that will be handled within the Request Fulfillment process

• Establishing self-help front-end capabilities

• Service Level targets will need to be agreed and communicated for each type of request

• The cost of fulfilling requests must also be agreed

• Agreements will need to be in place for which services will be standardized and who is authorized to request them.

• Information about what requests are available will need to be easily accessible.

• Requests will need to follow a predefined standard fulfillment procedure

• Request Fulfillment has a very high impact on user satisfaction.

Let us also look at the risks of request fulfillment.

Request Fulfillment Risks

Mitigating the risks is one of the most critical success factors for any process implementation. Risks related to Event Management include:

• Poorly defined scope

• Poorly designed or implemented user interfaces

• Badly designed or operated back-end fulfillment processes

• Inadequate monitoring capabilities

Let us look at the Critical Success Factors (CSF) and Key Performance Indicators (KPI) of Request Fulfillment in the next section.

Request Fulfillment CSFs and KPIs

Each organization should identify appropriate CSFs or Critical Success Factors based on its objectives for the process. Each sample CSF is followed by a small number of typical KPIs or Key Performance Indicators that support the CSF.

These KPIs should be adopted with careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances. Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the continual service improvement (CSI) register for evaluation and possible implementation.

The following table lists some CSFs and their corresponding KPI:

Summary

In this lesson, we discussed the Request Fulfillment process along with its policies, principles, concepts, activities, methods, request models and techniques in relationship to OSA practices and information management.

The next lesson talks about Problem Management.