Service Request Management

Description/Summary

In the Service Request Management all Requests according to a service will be processed. The Service Request Management is monitoring and reporting the agreed Key Performance Indicators (KPI) corresponding to the compliance with customer and management.

The duty of providing information to the user is part of the Service Request Management controls. The most important actor in in the Service Request Management is the function Service Desk. The Service Desk is basically responsible for the Acceptance, Classification and also handling of request. The process Request Fulfillment in ITIL V3 deals with Service Requests and is the corrsponding counterpart to the Service Request Management.

Objectives

The purpose of Service Request Management is to accept and register Service Requests and directly handling them according to the urgency.

The superordinate objective of the Service Request Management is the contentedness of the user.

Roles & Functions

Service Request Management specific roles

Static Process Roles

Service Request Management Process Owner: Initiator of the process, accountable for defining the process strategic goals and allocating all required process resources. See Continual Process Improvement Management for a detailed description of these activities.

Service Request Management Process Manager (Service Request Manager): Manager of the entire process, responsible for its effectiveness and efficiency. Team leader of the function „Service Request Management Team“.

Service Request Management Team: Team associated to the Service Request Management Process.

Senior Management: Senior Management of the IT provider

Dynamic Process Roles

These roles are dynamically created during the Service Request Management Process. See the process-specific or activity-specific rules for details.

Service Request Owner: The attribute in the records contains the value of the Role/Function currently accountable for the Service Request (but NOT for the Service Request Management Process). The Service Request Owner can be changed with the help of a Hierarchical Escalation.

Service Request Agent: The attribute in the records contains the value of the Role/Function currently responsible for either an activity or task within the overall activity of the request. The Service Request Agent can be changed with the help of a Functional Escalation, if permitted by the Rules.

Service Request Requester (SRR): This is the person who triggers a request via a Service Request (SR) form. This can be identical with a service or customer specific role.

Service Specific Roles

Roles depending on the affected service are found in the Service Description. The Service Description, including the service specific roles, is delivered from the Service Portfolio Management.

Example: Service Description

Service Expert/Service Specialist

They can consult at

Classifying Service Requests
Request fulfilment


Service Owner

Customer Specific Roles

Roles depending on the affected customer(s) are found in the Service Level Agreement (SLA). The Service Level Agreement for the customer specific roles is maintained by the Service Level Agreement Management.

Customer(s): Customers of the affected Service with a valid SLA

Information artifacts

This section describes information/data required or recorded by the process. In general, a Process Record (here: the Service Request Record) represents the current progress of a process and will contain all information related to the execution of that process. Additional information items (artifacts), such as the Request for Change (RFC) in the context of Change Management, typically can be realized by considering the information out of one or more (up to all) process records and either filtering, merging, correlating or interpreting these information, sometimes with regard to the context of other data and information sources.

Service Request Record

Definition

The Service Request Record is the record holding any management-relevant information and history of a specific request. On creation, it is based on (filled with) the information provided by users request, selected customer and service.

Unique identifier: Service Request ID (ticket id)
Ticket Owner: Person registering and accepting the request
Ticket Agent: Assigned person currently working on that request
Service Request proposer: Name of the Person triggering the Service Request
Status: Status of the request. Is set when passing a Control Activity
Services: Service(s) affected by this request
Customer: Customer(s) affected by this request
User: User(s) affected by this request
Description: The description of the change including the Change Argument
Resolution Time: The resolution time depends on the priority of the request
Times Request forwarded: Forward-history is saved to the record
Request Working Minutes: Time spend actually working on that request
Triggered RFC UID: The UID of the RFC initialized by the Service Request
Solution Describtion: The describtion of handling the request
Closing Code: Basically standard codes, that are necessary for the reporting and patterns of events
Closing Comment: Additional Information to the closing activity
Additional Remarks: Text for additional information

Service Request Record attributes x activity matrix

For icon descriptions see Record attributes X activities

Key Concepts

Service Request Classification

The Service Request needs to be classified and a resolution date is to be defined. Classification ia a continual process, till the request is fulfiled. The resolution date is to set to a date which assures that the SLA is not infringed.

Service Request Controls

Process

High Level Process Flow Chart

This chart illustrates the Service Request Management process and its activities

Critical Success Factors

Critical Success Factors (CSF):

Obey the process in every case
Continouus review of Serivce Request’s classification respectively the resolution date
Cooperation with the Change Management
No personal union between Service Request- and Change Manager
High ratio of contentedness of the user.
High ratio of fulfiled Service Requests
High ratio of Service Requests with short Reaction- and fulfilment-time

Performance Indicators (KPI)

Details from audit
- on time?
- in budget?
Ratio open/total number of requests
Ratio fulfiled/aborted requests
Causes of the request
Average time of answer, reaction and fulfilment

per service, per user, per customer, per location, per category, …

Process Trigger

Event Trigger

Any Service Request by an user

For more information see the relevant Process Interface Description in the Process Interfaces Overview

Time Trigger

None (Service Request Management is typically event-triggered)

Process Specific Rules

every Service Request triggers the creation of a new Service Request Record.
the Ticket Agent is responsible for documenting each activity in the Service Request Record
the Service Request Owner has to control the Ticket Agent
the Service Request Owner and Ticket Agent can only transfer their duties if the new person or group agrees
the subsequent Service Request Owner or Service Request Agent must then be recorded in the appropriate attribute in the Service Request Record.
the Service Request Owner and Ticket Agent should preferably be a person rather than a group.
refer to the Service Description and Service Level Agreement in order to take service specific and customer specific rules into account

Note: for the different types of rules see Rules.

Process Activities

Service Request Registering

Activity Specific Rules

Service Request proposer is set to the person who triggered the Service Request
Ticket Agent is set „Service Request Management Team“ if there is not a person as ticket agent available
Ticket Owner is set „Service Request Management Team“ if there is not a person as ticket agent available
Service Request Owner is set „Service Request Management Team“ if there is not a person as request owner available
Service Request Description The ticket must contain a meaningful description of the desired request as well as a comprehensible rationale stating the reasons for the request.
Customer is set to „default customer“ if no other customer is known.
User is set to „default user“ if no other user is known.
Request Working Minutes are to increase by the minutes the agent was working on the ticket

Service Request Service Selection

Selecting the service of a request aims to provide the necessary affected service investigation result information for the next subprocess Classification

Activity Specific Rules

Service is set to a service out of the Service Portfolio
Request Working Minutes are to increase by the minutes the agent was working on the ticket
Status is set to „service selected“, if the affected service was identified successfully

Service Request Classification

The classification of a request aims at providing a control factor for the request, which will be used for factual decision making with respect to request scheduling by the resolution date

Activity Specific Rules

Resolution Date is set to the neccessary value (date), so that the SLA is not infringed by delayed fulfilment
Request Working Minutes are to increase by the minutes the agent was working on the ticket

Service Request Handling

In this activity, …

Activity Specific Rules

Ticket Agent is set to current responsible person
Times Request Forwarded is set to the times the ticket was assigned to different ticket agents
Triggered RFC UID is set to the UID of the generated Request for Change – please refer to Change Management
Solution Describtion is to be filled up.
Request Working Minutes are to increase by the minutes the agent was working on the ticket

Service Request Closing

In this activity, the success of an filfiled Service Request is evaluated and the solution is described.

Activity Specific Rules

Closing Comment is to ne set by the Ticket Agent
Closing Code is to ne set by the Ticket Agent
Status of the Service Request instance is closed
at the end of the activity the Ticket Agent is set to Ticket Owner