THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:

• ✓  Request fulfilment is discussed in terms of its
  • Purpose
  • Objectives
  • Scope
  • Value
  • Policies
  • Principles and basic concepts
  • Process activities, methods, and techniques
  • Triggers, inputs, outputs, and interfaces
  • Critical success factors and key performance indicators
  • Challenges
  • Risks

The service operation process we’ll cover in this chapter is request fulfilment. This is the process for handling requests for standard services, equipment, or information. ITIL uses the expression service request to describe all those repeat, low-risk change/information requests that occur in any environment.

There is no absolute definition as to what will be classed as a request because this may vary from organization to organization. Many may, in fact, be small changes, falling under the definition of standard changes because they require a change to the configuration management system, such as equipment relocation or the installation of additional software. Service requests occur frequently, at a low cost, with an understood low risk. Examples of service requests that are not standard changes could include a password reset or information requests. Service requests are usually handled by a service desk, without a requirement for an RFC to be submitted.

The definition used by ITIL is “a formal request from a user for something to be provided—for example, a request for information or advice, to reset a password or to install a workstation for a new user.”

Service requests relate to small-scale, clearly defined, and low-risk activities, such as the provision of a single workstation or supply of a toner cartridge. An important feature of what ITIL calls service requests is that they represent things that the service provider will be asked for repeatedly. They are all opportunities to provide the user with something they have asked for, and the request fulfilment process is used to handle them.

Many service requests require a change—the installation of a workstation, for example. If you think back to your Foundation studies, you may remember standard changes, which are low-risk, simple, preauthorized changes. The only changes that can be handled by the request fulfilment process are those for which a standard change exists. Be careful here though—not all standard changes are implemented through request fulfilment, and not all service requests involve standard changes. Requests for information or advice also fall within the scope of request fulfilment.

Purpose and Objectives

Request fulfilment is the process responsible for managing the lifecycle of all service requests from the users. The process has five objectives:

• To maintain customer and user satisfaction through efficient and professional handling of all service requests. We’ve learned that ensuring satisfaction involves not only meeting objective targets, but also the human aspects—treating requesters with respect, keeping them informed of progress, and so on.
• To provide a way for the user to make a request. This is normally through a web portal but the service desk could be used.
• To provide a way for users to find out what standard services are available to them and how they can request them. It can be surprising that, particularly in a large organization, users aren’t even aware of everything the service provider can do for them.
• To source and deliver the tangible components of service—hardware, software, licenses, and so on.
• To assist with general information, complaints, or comments. So, the process should not only provide a means to submit a question, it should also ensure that the user gets a satisfactory response.

Request fulfilment provides an efficient way to supply standard equipment to users, once an item has been assessed and accepted as compatible with the infrastructure. The provision of such equipment can be preapproved and handled as a standard change. It can be added as a service within the service catalog, and all future requests of this type can be handled through this process. This encourages the users to request the standard equipment and software because it is the easiest and fastest to obtain. This is beneficial to IT because the equipment has been assessed as supportable and compatible with the infrastructure.

Scope

The scope of request fulfilment will vary from one organization to another; it can include any requests that can be standardized and used where the organization has agreed to use it. Each request should be broken into agreed activities, each with a documented procedure. The procedures are then used to build the request models.

ITIL calls all these service requests; they are all opportunities to provide the user with something they have asked for, such as information, advice, a standard change, or access to an IT service (such as resetting a password or providing standard IT services for a new user), and as mentioned in the introduction to this chapter, the request fulfilment process is used to handle them.

ITIL Service Operation publication suggests that other sorts of requests, such as requests for building maintenance, may be handled together with IT requests. Take a moment to consider the advantages/disadvantages of this approach:

• Similar handling for both
• Expands single point of contact
• De-skills the (usually service desk) job

It will be up to each organization to decide and document which service requests it will handle through the request fulfilment process and which will have to go through other processes, such as business relationship management (BRM) processes for dealing with requests for new or changed services.

Value to the Business

The request fulfilment process benefits the business in a number of ways.

First, it improves the productivity of the business by giving its staff quick and effective access to the services they need to do their jobs. By providing a straightforward means of having its requests fulfilled, business staff can remain productive. Centralization encourages consistency and efficiency. Bureaucracy and delay is reduced, thus reducing the cost of fulfilment. Second, the process provides an efficient way to handle requests, again reducing bureaucracy. A formal process implies the centralization of sourcing and purchasing, enabling the service provider to standardize the hardware and software used, therefore reducing support costs. Central purchasing through approved suppliers can also reduce costs through economies of scale.

The standardized nature of request fulfilment means that it is an obvious candidate for self-help. Although not essential, automating the process with a self-help front end enables the requester to interface directly with the process and thus speeds up the fulfilment process. Typically, users can access a list of possible requests on a company external website or intranet. This ensures that the user provides all the necessary information and can be informed as to expected lead times (defined in the SLA).

Automation can simplify the logging of requests. It can also automate the fulfilment process, without the intervention of the service desk if there is a direct interface into the necessary systems. An example of such automated fulfilment is when you request and receive a password reset from an Internet shopping site such as Amazon, without any human intervention. Financial approval of requests can also be automated, with the request being sent to the appropriate budget holder for approval or rejection before fulfilment.

Next, we consider the policies, principles, and basic concepts of the request fulfilment process. Let’s start with policies.

Policies

In this section, we’ll consider some of the policies that support effective request fulfilment.

Policy: Process flows should be defined for each service request. The first policy is that a process flow should be defined for the entire lifecycle of each service request. This will ensure that requests are satisfied effectively, efficiently, and consistently. Service designers should include new requirements for standard services in their design efforts.

Policy: Process should be owned by a single function. A second policy is that there should be a single function that owns all service requests. This does not mean that there should be a single function for fulfilling the requests. Rather, the central function will monitor progress of requests and take action should progress be slow. This central function will also provide requesters with updates on progress where appropriate. Often the service desk takes this role.

Policy: Standard change process to be used where a change to a configuration item is involved. Another policy is that if a request involves a change to a configuration item, then it must be implemented by a standard change. In other words, request fulfilment must follow normal change management procedures.

Policy: All service requests to be handled by a single system. The fourth policy is that service requests should be handled by a single system. The parallel here is with incident management and the service desk.

Policy: All service requests to be authorized. Policy five states that all requests must be authorized before they are fulfilled. Many requests incur costs, such as the purchase of hardware or a software license, and those costs must be authorized.

Policy: All service requests to be prioritized according to business criteria. The next policy, policy six, is that the activity needed to fulfil a request must align with the needs and objectives of the business. In other words, each request must be prioritized using business criteria. Here is another parallel with incident management.

Policy: Users must be able to submit requests and obtain updates easily. The last policy that we will discuss is that users must have a clear means of submitting a request and of getting an update on progress. This could be the single point of contact that is provided by the service desk for incidents. For request fulfilment, the point of contact could be the service desk or the web portal.

Principles and Basic Concepts

Many organizations use their existing incident management process (and tools) to handle service requests because key steps are often the same. In each case, the following questions need to be answered:

• Can the service desk deal with this?
• Would this impact negatively on incident handling?
• If not the service desk, who can deal with this?
• What are the timescales/agreed service levels?
• Is the user satisfied?

Process Activities, Methods, and Techniques

Take a look at the process flow shown in Figure 35.1. Although you do not need to know the process flow in detail for the exam, an understanding of what is involved in fulfilling service requests will help you understand its objectives.

First we will look at the process flow and then discuss the high-level activities.

The diagram shows the complete request fulfilment process flow. You can see that it includes logging, categorizing, and prioritizing a request as you would an incident. It also includes some activities that are specific to this process. The request is logged and validated, categorized, and prioritized. Any necessary authorizations are then obtained, and the request is reviewed to ascertain who will fulfil it. The appropriate request model is then executed, and finally, the request is closed, with the requester’s agreement. We’ll look at each of these steps in turn.

Triggers, Inputs, Outputs, and Interfaces

ITIL requires that every process should have a trigger and inputs to and outputs from the process activities. Each process will also have interfaces with a number of other processes.

Critical Success Factors and Key Performance Indicators

There are several possible critical success factors (CFSs) for request fulfilment, each of which will have key performance indicators (KPIs) to show whether the CSF is being achieved. Before we look at the CSFs and KPIs, we should take a minute to understand what these terms mean:

• A critical success factor, or CSF, is a high-level statement of what a process must achieve if it is to be judged a success. Normally, a process would have only three or four CSFs. A CSF cannot be measured directly; that’s what key performance indicators are for.
• A key performance indicator, or KPI, is a metric that measures some aspect of a CSF. Each CSF will have three or four associated KPIs.

Here are some examples of CSFs and KPIs for request fulfilment:

• Critical success factor: “Requests must be fulfilled in an efficient and timely manner that is aligned to agreed service level targets for each type of request.”

  Possible associated KPIs for this CSF are as follows:

  • The mean elapsed time for handling each type of service request

  • The number and percentage of service requests completed within agreed target times

    The first KPI relates to the requirement to fulfil requests in a timely manner and the second to meeting agreed targets. You may be able to think of other KPIs.

• Critical success factor: “Only authorized requests should be fulfilled.”

  This could be measured by the following KPIs:

  • The percentage of service requests fulfilled that were appropriately authorized
  • The number of incidents related to security threats from request fulfilment activities
• Critical success factor: “User satisfaction must be maintained.”

  The following examples would be relevant KPIs for this CSF:

  • The level of user satisfaction with the handling of service requests (as measured in some form of satisfaction survey)
  • The total number of incidents related to request fulfilment activities
  • The size of current backlog of outstanding service requests

Challenges

There are some common challenges encountered when implementing and running a request fulfilment process:

• Ensuring that the scope of the process is clearly defined by documenting the type of requests that will or will not be handled by this process and which requests need to go to change management.
• Providing an effective portal that will encourage users to submit requests there rather than calling the service desk. Clear targets must be agreed with the business for each type of request. These targets will be documented in the service level agreement.
• Reaching agreement with the business on where, when, and how authorization should be sought. It’s important to adhere to normal budgetary controls in place within the organization.
• Agreeing on the costs for fulfilling requests, specifying whether they are to be recharged, and ensuring that service requests do not violate the information security policy.
• Providing the required level of information regarding the types of available requests in an easily accessible format, usually as part of the service catalog.
• Providing a documented request model with a predefined process flow for each of the services being requested to ensure that all requests follow a predefined standard fulfilment procedure.
• Making sure all service requests made through the web portal are processed in a timely manner to ensure customer satisfaction. Regular customer satisfaction surveys should be carried out.

Risks

There are five common risks faced by the request fulfilment process:

• A poorly defined or communicated scope will mean that users and IT staff will be unclear as to what the process will and won’t handle.
• A poorly defined or implemented web portal will not be used. Users will continue to call the service desk and a major benefit of the process will be lost.
• Poorly designed or insufficiently resourced back-office fulfilment activities will mean that the process will not operate effectively or efficiently. Targets will not be met, backlogs will build up, and customer satisfaction will plummet.
• Inadequate monitoring capability will prevent metrics from being gathered, and as a result, performance won’t be managed.
• Users may be reluctant to use a web-based tool if it is a new concept to the organization.

Summary

This chapter explored the next process in the service operation stage, request fulfilment. We discussed the key ITIL concepts of service requests and how the request fulfilment process can save time and money in expediting simple user requirements.

We examined the process in depth, covering its purpose, objectives, scope, and value. We considered its policies, principles, activities, and basic concepts and how its success might be measured. We also discussed what factors might work against a successful implementation.

Exam Essentials

Understand the purpose, objectives, and scope of request fulfilment. Request fulfilment provides an efficient means of delivering services to customers, with low-risk requests and a defined fulfilment process. It can include IT and non-IT requests and be accessed through a self-help web portal.

Know how request fulfilment benefits the customer and the IT department. It provides the customer with an easy, efficient means of requesting services and enables the requests to be fulfilled by service desk and second-line staff with minimum bureaucracy.

Understand the use of request models. Because requests have a predefined fulfilment process, they are very well suited to the use of request models, which can be programmed into the service management toolset.

Understand the need for technical and financial approval. Although some requests are preauthorized, there may be occasions when authorizations are required. The usual corporate financial controls still apply, so the budget holder may need to approve, for example, the purchase of equipment. Technical authorization may be necessary as a confirmation that the request is compatible with the user’s existing equipment.

Understand the use of a web portal and menu selection in implementing an efficient user interface. Request fulfilment can be greatly enhanced by providing the equivalent of an online shop, complete with “Add to Cart” facility. Users are familiar with this approach through Internet shopping, and it reduces the need for data entry at the service desk.