Service Request Management

The purpose of Service Request Management is to handle frequent low cost, low risk service requests which ensures that incident and change management processes are not swarmed with these issues and can focus on high impact, high cost issues. Examples of Service Requests are password reset, request for additional telephony  or request for information "How Do I..." type of calls.

Exclusions in Service Request

• Incidents (break/fix) are not handled in this process. Incidents are service interruption therefore require high priority to restore the service within designated Service Level Targets. Incidents are attended to in accordance with the Incident Management process.
• Changes to system resulting from Problem Management effort are not handled in this process. Problem Management requires resolution to on-going problems which is part of Business As Usual (BAU) and does not require service request to be initiated.

A Service Request Management Process activity should atleast cover the following :

1. Service Request Management
1.1 High level Overview

• Purpose and Objective
• Scope
• Value to business / Benefits of Request Management ( cost effectiveness , customer satisfaction, Corporate governance)
• Service Request Policies such as Service Request that occurs frequently shall require predefined request model with complete workflow or work instructions in  order to give consistent level of service.

2. Detail the Process activity or Service Request Management Life cycle contains the following :

• SR Logging
• SR Validation
• SR Authorization
• SR Execution
• SR Review
• SR Closure

* The process activity may defer based on the organisation input and policy.

3.The following information needs to be streamlined before drafting the process.

• Who will handle the request first – Service Desk Analyst ?
• Who are the specialist team ( refer to Organisation Chart)
• How the customer will be notified once the request is fulfilled (  Email or Phone) ?
• What are the SLAs for each type of request (Generic, Deployment , Purchasing etc)
• What are the service being offered to end user ? This information is populated in Service Catalogue.
• Request Models based on Systems ( E.g Generic Request , Access to Systems, Request for procurement such as additional telephony system.
• Who can authorized the service ( The requester can be anyone who require the services. Certain Request such as Purchase of new laptops will incur financial  obligations thus require approval 2 level approvals. It could be the reporting manager and next is commercial or financial manager. The level of  authorization depends on the governance model the organisation is adopting.
• How the SR will flow from one group to another group that require specialist activity.The request can be worked upon by Service Desk or assigned to specialist group e.g Network Engineer.
• Requests for Change: In some cases the Service Request process will be initiated with RFC. This is typical where the Service Request relates to a CI that require changes such as new software installation.
• Refer to any security policies which will prescribe any controls to be executed or adhered to when providing the service, e.g. ensuring that the requester is authorized to receive the service. As an example, not every user can request or entitled for a Blackberry phone.
• What are the status used throughout the life cycle of each service request record ? E.g. from from New till Closed, the record could go through phase as "Work In Progress" or "Suspended".
• Work out the SLA and ways to stop the SLA clock from ticking if the circumstances or situation is outside from Service Desk control such as Waiting for user to revert back with further information, lack of information, delay in receiving approval since the line Manager is away on vacation leave or waiting quote from supplier. 

4. Service Request Triggering point , Inputs to the process and Outputs

5. RACI Chart (Service Desk, Service Request Analyst or Service Request Administrator, Service      
    Request Manager and Requester ). Who is accountable for process (Populate this in table format with    
    example).

6. Reporting Metrics :

• Metrics
• CSFs – Critical Success Factors and KPIs
• Future of Service Request Management (overcoming challenges). This can be identified by performing trending or analysis on CSFs. E.g users are often raise service request for break fix issues. This could boil down to lack of knowledge and ability to differentiate between Incident and Service Request.

What is Service Management Policy ?

Service Management Policy defines how Service Management will be implemented and managed within the organisation or department. ISO/IEC 20000 is used as a guideline for the development and implementation of the required SMS (Service Management System). The process depends significantly on ITIL best practices which has expanded superlatively from its early days to Internationally recognized specification.

Service Management Process is divided into :

Resolution Process

• Incident
• Service Request
• Problem Management 
• Includes Service Knowledge Management System

Control Process

• Change Management
• Release and Deployment Management
• Configuration Management

Service Delivery Process

• Service Level Management
• Service Reporting
• Service Continuity and Availability Management
• Capacity Management
• Information Security Management

Relationship Process

• Business Relationship Management
• Supplier Management

Some organisation may include other process that are specific to the department such as Pre- Sales or procurement process.

In the policy document, list of supported systems is also defined that is scoped for support and maintain. Management representatives consist of Process Owner, Manager or Process Analyst is defined. Their roles includes identification, documentation and fulfillment of service requirements, improvement of the individual process, Integration with other process and compliance with statutory, regulatory such as SOX and TD requirements.

Next section should cover governance of process operated by external entities. Usually this is managed through Service Level Management process using Underpinning Contract or agreements. The accountability of the process should remain with Owner instead of supplier.

Apart from Supplier governance, each process will have responsibility associated with it and summarized in RACI table. RACI stands for Responsible, Accountable, Consulted or Informed hence RACI. This is communicated and discussed with everyone to ensure awareness and accept the responsibilities.

Finally a section on how the process documents are organised and controlled for projects, transmittal and correspondences.

What is Service Management Plan ?

Service Management Plan describe how Service Management System will be implemented across the
organisation. Service Management System (SMS) are aligned with the framework in the ITSM standard ISO/IEC 20000-2011. Processes created in the SMS initiatives ensure the achievement of the Service Management objectives. Policy for specific process such as Incident Management Process shall have separate policy and applying the same with the remaining of the process. In a nutshell, together with the Service Management Plan you should also develop Service Management Policy which will act as a overarching document that describe how the SMS will perform. The Service Management Plan describes how a operation team will implement SMS.

The following detail shall be covered in Service Management Plan Framework :

• Process Integration - One of the strength ITIL has is uses the output of one process and becomes input to another. A good example is Configuration Management, this process glues almost all the resolution processes and integrates with each other. As an example, The affected CI in Incident provides data for Problem Management which is to identify the root cause. Draw a map or tables which shows the interfaces.
• Functions - People involved to operate and execute the process.
• Service Management Objectives - Objective the management is trying to achieve at the end of  the ITSM implementation. 
• Scope of Operations - Describing operational support systems and coverage. 
• Location where the Operation will be taking place. Most organisation have a centralized location but some depending on the delivery method may have another location for DR and contingency purpose.
• Operation hours
• Escalation details
• Support model
• Service Performance measures and targets
• Process to be implemented or executed - Define the processes that will be implemented such as Resolution , Service delivery and Control related. Explain briefly the function of each process and how it helps the organisation in achieving the target. Individual process shall have a separate document number or title which is worth mentioning in this section.
• Explain the Roles and Responsibility briefly. Segregate it with be functional and process roles. As an example the Team Lead of a department may also be the Process Management for Incident Management or Service Delivery Manager is also the Service Level and Service Catalogue Manager. Support the Roles and Responsibility with Organisation Chart. Don't limit the roles within the organisation but try to explore if there are any interface with Supplier Organisation. As an example, Hardware breakfix for servers located in remote area might be covered with IBM. So add them in the Roles and Responsibility as resolver. Map the roles against each process. As an example Incident Management Process has the following roles :

> Process Owner
> Process Manager
> Major Incident Manager
> Problem Manager
> Resolver : System Engineer
> Service Desk Agents
  > Service Desk Manager
> Service Level Manager

• Infrastructure Management tools - Explain the tools used to support the operations such as remote logging tools ( SSH or Putty), service desk tools, monitoring tools, element management tools or any network management tools for IP addresss. 
• Stage of implementation - Explain briefly on the execution each of this phases will work. For obvious reason, it would be good to start with prototype the process, build the process, implement the process and finally process tuning.
• Finally for the benefit of others and completeness of the plan, attach a project plan depicting the start and finish of tasks and milestones.

How to Calculate Server Availability ?

One of the challenges Service Level Manager face is calculating Server Availability.

Let’s take example of Server ABC which is scoped to be available on 24x5. This gives 20 working calendar days with unplanned outage for 20 hours and 15mins due to UPS failure.
Thus the calculation will be :
Total Outages in a month 20 Hours 15 Mins 0 Secs ( convert the mins into hours , 15/60 = 0.25)
Total hours in scope = 24x7x20days = 3360 hours
Availability = Time Server online / Total hours in scope * 100%
= 3360 – 20.25 / 3360 *100%
= 3339.75 / 3360 *100%
=99.39 %
So availability for Server ABC is = 99.39%