ITIL Intermediate OSA - Request Fulfillment Tutorial

4.1 Request Fulfillment

Hello and welcome back! This is module 4 on ITIL 2011 Intermediate OSA module preparation online course by Simplilearn. This module is about Request fulfillment. Let us move to the next slide and look at the topics that we will learn under this module. Please note, like any other module at the end of the session you will have to take up a quiz.

4.2 Request Fulfillment

Agenda In this module we will be covering information of Request fulfillment which will consist of its purpose, scope, objective, scope, and value to business, policies, principles and key concepts, other approvals, request fulfillment, triggers, inputs and outputs, challenges and risks. Let us quickly move on to learn about the purpose and objective of Request Fulfillment.

4.3 Request Management - Purpose and Objectives

Request Fulfillment - Purpose and Objectives First we will look into the purpose of Request fulfillment. 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 is to 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 those objectives of the process 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’s look into the scope of request fulfillment.

4.4 Request Management - Scope

Request Fulfillment – Scope Now let us learn about the scope of the Request Fulfillment process. The process needed 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. Next, we will learn how request fulfillment adds value to the business?

4.5 Request Management - Value to Business

Request Fulfillment – 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.

4.6 Request Management - Policies

Request Fulfillment – Policies 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 Fourthly it states that all requests should be logged and should be authorized before their fulfillment Lastly 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.

4.7 Request Management - Principles and Key Concepts

Request Fulfillment – Principles and Key Concepts In this slide we will go through some of the key words or key concepts of Request Fulfillment process. To start, let us understand what are 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. 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 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. Financial Approval 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. 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. So far, we have learnt the cycle of fulfilling the request, next we will look into the activities and technology.

4.8 Request Fulfillment - Process Activities

Request Fulfillment – Process Activities, Methods and Techniques In this slide we will see different activities of the process. It starts 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. After this Request Logging and Validation happens. 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. After the validation is done comes the Request Categorization activity. 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. Once the categorization is complete, 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. The next step is 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. Now it is the time for Request Review. At this stage the request us 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. 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. 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. 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.

4.9 Request Fulfillment - Triggers

Request Fulfillment – Triggers 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 (or) updates will also be necessary. Let us know learn about inputs and outputs for request fulfillment process.

4.10 Request Fulfillment - Inputs and Outputs

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. Next we will look at the interfaces of request fulfillment.

4.11 Request Fulfillment - Interfaces

Request Fulfillment – Interfaces The primary interfaces with Request Fulfillment 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 Fulfillment, Release, Asset and Configuration Management – as some requests will be for the deployment of new or upgraded components that can be automatically deployed. Moving on like incident management, we will learn about information management of request fulfillment

4.12 Request Fulfillment - Information Management

Request Fulfillment – Information Management Information is very critical for functioning of any process/business. Request fulfillment is dependent on information. The sources for information are: 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 and the last step will be closure(see closure details on slide no 103). Requests for Change: 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 measure. The next slide talks about request fulfillment metrics.

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

4.14 Request Fulfillment - Challenges

Request Fulfillment - Challenges In the last slide we learnt that for effective and efficient functioning of the process, measurement of performance is very essential. Similarly the process has to overcome its challenges. 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 also look at the risks of request fulfillment.

  • 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*