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.
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.
You too can join the high earners’ club. Enroll in our ITIL OSA Course and earn more today.
The purpose of Request Fulfillment would be actively managing the lifecycle of all service requests from the users.
The objectives of the 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
To source and deliver 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.
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.
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.
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 section, we will learn about the key concepts and terms of request fulfillment.
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.
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. These trends are used in determining how services are being used, which requests are the most frequently asked for and other ITSM activities.
What are you waiting for? Interested in taking up an ITIL Intermediate OSA Course? Check out our Course Preview!
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.
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, and 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 now learn about inputs and outputs for request fulfillment process in the next section.
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.
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.
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 section talks about 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.
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.
Mitigating the risks is one of the most critical success factors for any process implementation. Risks related to request fulfillment 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.
Nervous about your interview? Enroll in our ITIL OSA Course and walk into your next interview with confidence.
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:
CSF |
KPI |
Requests must be fulfilled in an efficient and timely manner that is aligned to agreed service level targets for each type of request |
|
Only authorized requests should be fulfilled |
|
User satisfaction must be maintained |
|
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.
A Simplilearn representative will get back to you in one business day.