ITIL® Intermediate RCV Tutorial : Request Fulfillment

6.1 Learning Unit 6

This learning unit looks at how the request fulfillment process contributes to RCV practices. The lifecycle phase emphasized in this unit is service operation. ? A complete overview of the purpose, objectives, scope and importance of request fulfillment as a process, as well as of how request fulfillment may help to establish a self-help service practice within an organization. ? Request fulfillment policies, principles, concepts, activities, methods and techniques are explained in relation to RCV practices. ? The relationship between request fulfillment and release and deployment management is explored, as well as how it differs from incident management. In the next slide we will learn about the purpose and objectives of request fulfilment process.

6.2 Purpose and Objectives of Request Fulfillment

The Purpose of Request Fulfillment would be actively managing the lifecycle of all service requests from the users and the objectives of the Request Fulfillment process To Maintain user and customer satisfaction through efficient and professional handling of all service requests Provide a channel for users to request and receive standard services for which a predefined approval and qualification process exists and to provide information to users and customers about the availability of services and the procedure for obtaining them Other than that objective of the process, it also includes sourcing and delivering the components of requested standard services (e.g., licenses and software media) and to assist with general information, complaints or comments. Let us now look into the scope of this process in the next slide.

6.3 Scope of Request Fulfillment

Request Fulfillment – Scope Now let’s see the scope of the process. The process required to fulfill a request will vary depending upon 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 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. Like any other process RF process is value to the business. Let’s discuss this in the next slide.

6.4 Request Fulfillment- 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 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. In the next slide let us look into the policies of the Request fulfillment.

6.5 Request Fulfillment- Policies ( 1 of 3)

As we have seen every process has its own set of policies. Likewise here we will see the policies stated for Request Fulfillment process. First being the activities used to fulfill a request should follow a predefined process flow(a model) Secondly the ownership of service request should reside with a centralized function Third policy states Service requests that impact CIs should usually be satisfied by implementing a standard change Let’s continue this in the next slide.

6.6 Request Fulfillment- Policies ( 2 of 3)

Fourthly it states that all requests should be logged, controlled, coordinated, promoted and managed throughout their lifecycle via a single system. And All requests should be authorized before their fulfillment activities are undertaken. Let’s look at the other two policies in the next slide.

6.7 Request Fulfillment- Policies ( 3 of 3)

Fulfillment of requests should take place under an agreed set of criteria for determining their priority that is aligned with overall service levels and objectives. This ensures that request fulfillment activities support service levels and objectives by prioritizing those activities based on actual business need. It implies that required service levels and objectives for different types of requests are already understood and agreed to by the business. Clear communication for making requests and determining their status must be in place. This implies that a single point of contact is in place which can be used to request the service and obtain its status. This is often provided by the service desk or through a web-based interface, but could be through an automated request directly into the request fulfillment or procurement system. Next, we will discuss about the principles and key concepts of this process.

6.8 Principles and Basic Concepts

In the next few slides we will go through some of the key words or key concepts of Request Fulfillment process. To begin with, let us understand what is request models. 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. Next key word is Menu Selection. 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.

6.9 Principles and Basic Concepts

Request Status Tracking defines that Requests should be tracked throughout their lifecycle to support proper handling and reporting on the status of requests. Next concept is Prioritizing Requests. All service requests should follow a standard set of criteria for assessing their priority Escalating Requests 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.

6.10 Principles and Basic Concepts

Financial Approval will 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.

6.11 Principles and Basic Concepts

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. 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 other 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. In the last few slides we discussed about the key concepts used in the Request fulfilment process. Let us look at the activities, methods and techniques in the coming slides.

6.12 Process Activities, Methods and Techniques

The different activities of request fulfilment process are Receive request, request logging and validation, request categarization, request review, request authorization, request prioritization, request model execution and request closure. Let us learn about each activity in the next few slides.

6.13 Process Activities, Methods and Techniques

The request fulfillment work begins with 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. The next activity would be Request Logging and Validation..

6.14 Process Activities, Methods and Techniques

During 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. On completion of validation, the request categorization activity begins.

6.15 Process Activities, Methods and Techniques

Under the 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.

6.16 Process Activities, Methods and Techniques

Once the category is set, it is time for setting the 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. On completion of prioritization, the request goes for authorization.

6.17 Process Activities, Methods and Techniques

During 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. The next activity is reviewing the requests.

6.18 Process Activities, Methods and Techniques

Now it is the time for 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. This is followed by request model execution.

6.19 Process Activities, Methods and Techniques

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 minimize the risks for delays or failures as requests are fulfilled. On execution of the request model, the next activity would be to close the requests.

6.20 Process Activities, Methods and Techniques

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. In some instances requests placed to reopen already closed requests. In such cases certain rules need to be placed for reopening them. Let’s look into the Rules of reopening request in the next slide.

6.21 Process Activities, Methods and Techniques

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 beyond certain point a new service request must be raised. Let us look at an exercise in the next slide on request activities.

6.22 Practical Exercise

This is an exercise to help gage your understanding on the request fulfilment activities. Please follow the instructions on the slide to work on this exercise. On completion of this exercise, move to the next slide on RF triggers.

6.23 Request Fulfillment Inputs and Outputs

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. 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 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/updates will also be necessary. In the next slide let us look at the inputs and outputs of this process.

6.24 Request Fulfillment Inputs and Outputs

As we all know every process has its own set of inputs and outputs . Inputs for the process could be Work Requests, Authorization forms, Service Requests, RFCs, Requests from various sources such as phone calls, web interfaces or email and Request for information Outputs 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 and Cancelled Service Requests Let us now look at the interfaces of request fulfillment with other lifecycle stages.

6.25 Request Fulfillment Interfaces with other lifecycle Stages

The primary interfaces with Request Fulfilment lies 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 Fulfilment, Release, Asset and Configuration Management – as some requests will be for the deployment of new or upgraded components that can be automatically deployed.

6.26 Request Fulfillment Interfaces with other lifecycle Stages

Like any other process information management is an intergral part of request fulfilment. Let’s look into the details in the next slide.

6.27 Request Fulfillment Information Management

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 and the date and time when the request was logged. All these information can be found in the closure details. Moving on let us discuss about the Critical success factors and KPIs of the RF process in the next two slides.

6.28 Critical Success Factors (CSF's) and Key Performance Indicators(KPI's)

The following list includes some sample CSFs for Request Fulfillment. Each organization should identify appropriate CSFs based on its objectives for the process. Each sample CSF is followed by a small number if typical KPIs that support the CSF. These KPIs should not be adopted without 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 Let us take one CSF which states that Requests must be fulfilled in an efficient and timely manner that is aligned to agreed service level targets for each types of request. So the supporting KPIs would be The mean elapsed time for handling each type of service request, The number and percentage of service requests completed within agreed target times, Breakdown of service requests at each stage, Percentage of service requests closed by the service desk without reference to other levels of support and Number and percentage of service requests resolved remotely or through automation without the need for a visit . Let us look at couple more in the next slide.

6.29 Critical Success Factors (CSF's) and Key Performance Indicators(KPI's)

The Next CSF states Only authorized requests should be fulfilled. Supporting KPIs could be Percentage of service requests fulfilled that were appropriately authorized, Number of incidents related to security threats from request fulfillment activities. Lastly the CSF that states User satisfaction must be maintained, the supporting KPIS could be: Level of user satisfaction with the handling of service requests, Total number of incidents related to request fulfillment activities and The size of current backlog of outstanding service requests. So far we discussed about the activities, triggers, inputs and outputs, interfaces, information management, CSFs and KPIs, of RF. In the next slide let us look at an exercise.

6.30 Practical Exercise

This is the exercise on issues reported to service desks. To work on this please follow the instructions on the slide. Once done with the exercise, let us move on to discuss about the challenges faced by RF process.

6.31 Request Fulfillment- Challenges

Listed here are some of the common types of challenges that you may encounter. • 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 now proceed to discuss about the risks of the RF process.

6.32 Request Fulfillment - Risks

Some of the common risks you may encounter during request fulfillment are: Poorly defined scope Poorly designed or implemented user interface Badly designed or operated back-end fulfillment processes Being overambitious – don’t try to improve everything at once. Be realistic with timelines and expectations. Not focusing on improving both service and service management processes Not prioritizing improvement projects Lack of making strategic, tactical or operational decisions based on knowledge gained – reports are actually used; people see that the reports are being used Lack of management taking action on recommended service improvement opportunities Lack of meeting with the business to understand new business requirements The communication/awareness campaign for any improvement is lacking, late or missing altogether. Removing testing before implementation or only partially testing With this we have come to end of Module 6 on Request fulfillment. Let us recap on the topics.

6.33 learning Unit Summary

To take up the scenario based quiz, please check out the scenario in the Question handout. Once you have chosen the answer check if the answer is right or wrong on the next slide.As we have come to the end of this module, let’s quickly summarize.

6.35 Scenario

Here is module summary on the topics that we discussed so far: Request Fulfillment is the process of dealing with Service Requests from the users • Some organizations handle Service Requests through their Incident Management processes (and tools); others handle them as a completely separate work stream • Some of the Request Fulfillment process activities, methods, and techniques are Menu Selection, Financial Approval, Other Approval, Fulfillment, and Closure • An Incident is usually an unplanned event whereas a Service Request is usually something that can and should be planned • The “release” can be predefined, built, and tested but only deployed upon request by those who want the “release” • There are many challenges, critical success factors, and risks pertaining to Request Fulfillment Let us now move to the next module on Change Evaluation.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Phone Number*
Job Title*