ITIL Request Fulfillment Workflow - Process Guide

Request Fulfilment (RF)
1
REQUEST FULFILMENT
(RF)
Process guide
Author Name
[E-Mail-Adresse]
2017
text

3
Table of Content
TABLE OF CONTENT.................................................................................................................3
1. INTRODUCTION.................................................................................................................5
2. KEY DEFINITIONS .............................................................................................................6
3. PURPOSE AND OBJECTIVES...............................................................................................8
4. SCOPE................................................................................................................................9
5. POLICIES.........................................................................................................................10
6. TRIGGERS, INPUTS, OUTPUTS.........................................................................................13
7. PROCESS FLOW ...............................................................................................................15
8. ROLES AND RESPONSIBILITIES......................................................................................25
9. RACI MATRIX ..................................................................................................................27
10. CSF AND KPI ..................................................................................................................30
11. ROLE ASSIGNMENT........................................................................................................34
12. SERVICE REQUEST LIST.................................................................................................35
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/itil-request-fulfilment-workflow-process-guide-3022

5
1. Introduction
Service Request is a formal request from a user for something to be provided.
Request fulfilment process enables users to request and receive standard services, to source and deliver
these services, to provide information to users and customers about services, and to assist with general
information, complaints and comments. Their scale and frequent low-risk nature requires this separate
process rather than potentially congesting the normal incident and change management processes. All
requests are logged and tracked, usually via the service desk, and may necessitate an appropriate level
of authorization before fulfilment.
Request fulfilment is:
• A mechanism to handle requests made to IT
• Defines request policies and fulfilment procedures
• Provides end to end request management processes
• Typically represents a significant amount of Service Desk work
• Typically small changes (low risk, frequently occurring, low cost, (such as password reset, request
for software installation, etc.) handled through request fulfilment rather than congesting the Change
Process
• Not one process, but a set of workflows to fulfil requests!

7
Key definitions
Service Desk
A function that provides the vital day-to-day contact point
between customers, users, IT services, and third-party
organizations. The service desk not only coordinates the
incident management process, but also provides an interface
into many other IT processes.
1st
line support
The team that provides the very first line of support for
processing incidents and service requests. The initial support
staff is responsible for trying to resolve incidents at first
contact—by identifying known workarounds, using diagnostic
scripts, or their own knowledge. In many organizations, the
service desk acts as the initial support team.
2nd
line support
Specialist teams that work to resolve incidents and service
requests that initial support cannot resolve themselves. Support
team structures vary between organizations, with some using a
tiered structure (second, third, and so forth), while others use
platform or application-oriented teams (mainframe team,
desktop team, network team, or database team).

9
4. Scope
The process needed to fulfil a request will vary depending upon exactly what is being requested, but can
usually be broken down into a set of activities that have to be performed. For each request, these
activities should be documented in a request model and stored/managed appropriately.
Requests for new or changed service: Organization decides and documents 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/Service portfolio management for dealing with requests for
new or changed services. There will always be grey areas which prevent generic guidance from being
usefully prescribed but in time rules for better classification should become clearer.
Out of scope:
Incidents are not Service Requests: There is a significant difference here – an incident is usually an
unplanned event, whereas a service request is usually something that can and should be planned!
Therefore, in an organization where large numbers of service requests have to be handled, and where
the actions to be taken to fulfil those requests are very varied or specialized, it may be appropriate to
handle service requests as a completely separate work stream – and to record and manage them as a
separate record type..

11
Policies Request Fulfilment Process
Policy 3
Service Requests
and their status
must be timely and
effectively
communicated.
• Clear communication for making requests
and determining their status must be in
place.
• Service Desk (or automated web-based
request interface) is single point of contact
and it is used to request the service and
obtain its status.
Policy 4
Service Requests
must be resolved
within timeframes
acceptable to the
business.
• Fulfilment 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 fulfilment
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.
Policy 5
All requests should
be authorized
before their
fulfilment
• All requests should be authorized before
their fulfilment activities are undertaken.
This ensures that resources are efficiently
used only for authorized requests. This
implies that requests are tied to access
management activities and the information
security policy.
Policy 6
All Service requests
should be stored
and managed in a
single management
system.
• All requests should be logged, controlled,
coordinated, promoted and managed
throughout their lifecycle via a single
system. This supports a consistent and
repeatable approach for handling service
requests and reduces the potential for lost
requests and conflicts that might arise
during handling of requests.

13
6.Triggers, Inputs, Outputs
Triggers, Inputs, Outputs
Triggers
• Service Desk (Common Route)
• Completed a web-based input screen
Inputs
• Work requests
• Authorization forms
• Service requests
• RFCs
• Requests from various sources such as phone calls, web interfaces or
email Request for information
Outputs
• Authorized/rejected service requests
• Request fulfilment status reports
• Fulfilled service requests
• Incidents (rerouted)
• Service Changes (rerouted)

15
7.Process Flow
Following is a Request Fulfilment process generic Workflow. Request Fulfilment models should be used
to describe workflows/steps for particular Service Requests.

17
Process activities
NR. STEP DESCRIPTION ACTIVITIES IN DETAIL
Start
1. Request
submission
User submits
information
related to the
Service Request
User submits request: Service requests are
submitted by:
• user contacting the service desk
• Request for Change (RFC),
• E-mail
• web ordering interface
• phone call.
2. Request
receipt
Request
information is
formally captured
and Request
Fulfilment
process can start.
Request is formally captured: Fulfilment
work on service requests begins when a
formalized request has been received.
Standard forms and records are used as much
as possible to capture request information.
(This way requests can be easier processed,
with minimal need to go back to requesters for
more information.)
Is this a
Service
Request?
Validating that it
is a Service
Request.
Validate Service Request: Potentially user
can call with Incident and Change proposals as
well. Service Desk will make initial routing of
Incidents, Service Requests and Change
proposals to appropriate processes or
functions.
Incident or
Change
proposal?
Routing issues
that are not
Service Requests
to appropriate
processes
Route non-Service Requests to Incident
Management and Service Portfolio
Management: Incidents to Incident
Management process and Change proposals to
Service Portfolio Management.

19
allocating suitable
request
categorization
coding.
exact type of the request is recorded. (This
will be important later when looking at the
request types/frequencies to establish trends
for use in determining how services are
being used, which requests are frequently
asked for, and other IT service management
(ITSM) activities.)
5. Request
prioritization
Allocating
Request priority.
Important aspect of logging every request is to
agree and allocate an appropriate prioritization
code. All service requests follow a standard set
of criteria for assessing their priority, by
considering impact and urgency.
• Prioritize Incident: Select the impact
and urgency of the Request according to
guidelines. This will determine the priority;
Request
evaluation
needed?
• Is Request evaluation needed: Is this a
non-standard request and evaluation of
complexity, resources, time and price is
needed.
o Yes: proceed to Request evaluation
procedure
o No: proceed to step Authorization
needed?
Request
evaluation
Procedure
Performing
request
evaluation
• Perform evaluation of request (complexity,
resources, time and price). This may
include additional conversations with the
person making the request.
Request
Authorization
needed?
Is Request authorization needed? :
• No: Pre-authorized requests: Simple
authorization that take place via the service
desk alone or as pre-authorized requests
based on request type. Proceed to step
Request Review.

21
requisite for
fulfilment and is
returned to
Requestor
7. Request
Review
Determining a
function to fulfil
the request
The request is reviewed to determine the
proper function that will fulfil it.
Route
Request?
Should a request
be routed?
Should a Request be routed?
• No: service desk may perform all
needed fulfilment activities (such as for
a request for information) or there is a
request model for fulfilment of this
request and Service Desk will be
accountable for the fulfilment
• Yes: the request is escalated to the
Request coordinator that coordinates
and is accountable for specialized
fulfilment activities.
Request
Fulfilment
Workflow
Request
coordinator
coordinates
request fulfilment
activities
Request Fulfilment Workflow: Request
coordinator is assigned to manage request
fulfilment across fulfilment groups. The
Fulfilment Group(s) complete tasks to fulfil the
request items. The Request coordinator(s)
assign tasks to specific resources. Once all
fulfilment items are complete, the request is
routed to the Service Desk for confirmation of
fulfilment with the requestor.
Change Management interface: If
Fulfilment activities involve changes to
Configuration Items (CIs) appropriate Change
authorization is required and Change should
additionally be recorded in a Change Record.
8. Request
model
execution
Executing
Request as
Fulfil activities according to the request
model:

23
full historic record at a sufficient level of
detail is complete.
• Validate fulfilment with User: Follow
proper procedures to validate with the User
that the request has in fact been fulfilled;
o If fulfilled, the request will be closed
according to procedures.
o If not fulfilled, Update Request for
Re-Fulfilment: If the user indicates
that the request has not yet been
fulfilled, it must be analyzed what went
wrong (if there was Fulfilment
Coordinator he should do the analysis,
otherwise it is done by Service Desk)
and re-open the request. NOTE: If the
request is in a closed state when the
user indicates it was not fulfilled, a new
request should be opened and
associated to the original request.
• Trigger User Satisfaction Survey: Once
the customer has confirmed fulfilment and
the request is in process of being officially
closed, a customer satisfaction survey is to
be provided to inform future improvement
opportunities.
• If there were issues in request
fulfilment?: If there were issues during
request fulfilment these should be reported
to Request fulfilment Manager so that
preventive action are initiated to prevent
these issues in the future.
• Formal closure: Formally close the service
request record.
If there are associated charges for this request
OR does this request impact monthly billing;
Perform billing if necessary using appropriate
mechanism.
End

25
8.Roles and responsibilities
The following roles have been identified within the Request Fulfilment Process:
Roles and responsibilities
User /Requestor • The individual who is submitting the request
Request Fulfilment
Process Owner
• Owns the process end-to-end, including the RACI, process &
procedural steps, roles & definitions
• Accountable for maturing and evolving the process, based on
monthly/quarterly/yearly review of process KPIs
• Adjusts the process to address performance or changing
business need
Request Manager • Oversee day to day process execution
• Owns the request-specific workflow definitions
Service Desk Manager • Acts as Request Fulfilment Manager
• Manages the Service Desk function, including staffing
management activities
• Provides guidance to Service Desk Analysts
Problem coordinator • Coordinates SMEs

27
9. RACI Matrix
RACI authority matrix is used for indicating roles and responsibilities in relation to processes and
activities. RACI is an acronym for the four main roles of:
• R- Responsible The person or people responsible for correct execution – for getting the job
done
• A - Accountable The role who has ownership of quality and the end result. Only one person can
be accountable for each task
• C - Consulted The people who are consulted and whose opinions are sought. They have
involvement through input of knowledge and information.
• I - Informed The people who are kept up to date on progress. They receive information about
process execution and quality.
RACI Matrix
1st
line support Fulfilment Groups
User/
Request
or
Service
Desk
Analyst
Request
Manager/
Service
Desk
Manager
Fulfilment
Group/
Functional
group
Analyst
Request
Manager/
Request
Coordinat
or
Request
Approvers
( Financial
&
Business)
Request
Fulfilment
process
owner
1. Request
submission
R,A
2. Request
receipt
C R A

29
1st
line support Fulfilment Groups
User/
Request
or
Service
Desk
Analyst
Request
Manager/
Service
Desk
Manager
Fulfilment
Group/
Functional
group
Analyst
Request
Manager/
Request
Coordinat
or
Request
Approvers
( Financial
&
Business)
Request
Fulfilment
process
owner
Ownership,
Monitoring,
Tracking,
Escalation &
Communicatio
n
C,I R A,R C C C I
Process design
and Ownership
C C R C R C A,R

31
Sample: Initial KPIs for Request Fulfilment
RF – KPI -3 The number and percentage
of service requests
completed within agreed
target times
Shows how many service
requests were fulfilled
within agreed timescales.
RF – KPI -4 Number of customer
complaints with Request
fulfilment
Indicates customer
satisfaction with Request
Fulfilment process.
More extensive list of sample CSFs and KPIs for Request Fulfilment is listed below:
Critical Success Factors (CSF) & Key Performance Indicators (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
• 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 (e.g.
logged, work in progress, closed etc.)
• Percentage of service requests closed by the service
desk without reference to other levels of support (often
referred to as ‘first point of contact’)
• Number and percentage of service requests resolved
remotely or through automation, without the need for a
visit
• Total numbers of requests (as a control measure)
• The average cost per type of service request
Only authorized requests
should be fulfilled
• Percentage of service requests fulfilled that were
appropriately authorized

33
Specific procedures
REQUEST FULFILMENT
(RF)
Process guide

35
12. Service Request List
Each Organisation should define a list of its own Service Requests. Following table is a sample list
containing list of requests, target SLA times and references to respective Request fulfilment models.
TBD = “To be defined”
Nr. Request name Request description Target SLA
response/
resolution
time
Request fulfilment
model
(Reference)
1. Request for
reconfiguration
TBD Link to appropriate
Request fulfilment
model
2. Providing installation
software/patch
Request fulfilment
model
3. Installation of
software/patch
Request fulfilment
model
4. Creating
documentation/instructi
ons
Request fulfilment
model
5. Providing
documentation/instructi
ons
Request fulfilment
model
6. Maintenance request TBD Link to appropriate
Request fulfilment
model
7. Training request TBD Link to appropriate
Request fulfilment
model

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

ITIL Request Fulfillment Workflow - Process Guide

Recommended

Recommended

More Related Content

More from Flevy.com Best Practices

More from Flevy.com Best Practices (20)

Recently uploaded

Recently uploaded (20)

ITIL Request Fulfillment Workflow - Process Guide