Annex 5
Reach Ops Governance Manual
UNRWA - REACH Ops Governance
REACH Service Operation
Capgemini Italia S.p.A.
2/6/2015
REACH Project: Operations Governance Manual
Document Identification
Author
Document Location (repository/path/name)
Capgemini
Version
Status
Date
V2.0
Draft
06/Feb/2015
Reference
Stable Phase
Revision History
Applies to Rev.
-
Date
Author
Capgemini
V0
8/Aug/2014
Capgemini
V1.0
30/Sept/2014
Capgemini
V2.0
06/Feb/2015
Capgemini
Change Description
DRAFT
Operations Governance Manual related to the
processes, rules and organization set for the
Interim Phase.
Operations Governance Manual related to the
processes, rules and organization set for the
Hypercare Phase focused on the Incident and
Problem Management.
Operations Governance Manual related to the
processes, rules and organization set for the Stable
Phase focused on ITIL overall processes in scope.
References/Direct Sources
Date
27th May 2014
Author
ERP transition Board MoM
15th July 2014
ERP transition Board MoM
1st September 2014
ERP transition Board MoM
15th December 2014
11th August 2014
CGI
ICTO
29th January 2015
ERP transition Board Mo
Reference
Kick off Meeting
UNRWA 270514 ERP Operation Readiness MoM v1 4.doc
Service Catalogue and Functional Organization
UNRWA - Meeting 150714 ERP Operation Readiness
MoM Final. doc
Functional Organization Sizing Rules
UNRWA -Meeting 01092014 ERP Operation Readiness
MoM -v1.0.doc
REACH Ops Functional Group ToRs
SDE Technical Documentation v1.7.doc
Reach Ops Organization – Staff review
UNRWA - Ops Staffing Review Meeting 29Jan2015 MoM v1.0 draft
pag. 2 of 69
REACH Project: Operations Governance Manual
REACH OPS GOVERNANCE MANUAL.............................................................................................................. 1
1
INTRODUCTION ..................................................................................................................................... 7
1.1
REACH PROJECT OVERVIEW ...................................................................................................................... 7
1.1.1 Purpose of this document ............................................................................................................... 7
1.1.2 Scope and target audience ............................................................................................................. 7
2
REACH SERVICE OPERATION OVERVIEW ............................................................................................... 8
2.1
SERVICE SCOPE AND DESCRIPTION ............................................................................................................... 9
2.2
SERVICES ACTIVATED DURING INTERIM HELP PHASE ...................................................................................... 11
2.2.1 Point of Contact, Classification and Escalation Points ................................................................. 12
2.3
SERVICES ACTIVATED DURING HYPERCARE PHASE ......................................................................................... 13
2.3.1 Service Desk TO BE model strategy modifications ........................................................................ 13
2.3.2 Point of Contact, Classification and Escalation Points ................................................................. 14
2.3.2.1
2.3.2.2
2.4
3
Incident categorization and Escalation Matrix .................................................................................... 15
Service Request categorization and Escalation Matrix ........................................................................ 16
SERVICES ACTIVATED DURING STABLE PHASE ............................................................................................. 17
REACH SERVICE OPERATION GOVERNANCE (TO BE ADVISED AT LATER DATE) ................................... 17
3.1
SERVICE DELIVERY APPROACH ................................................................................................................... 17
3.2
REACH SERVICE FUNCTIONAL ORGANIZATION ............................................................................................ 18
3.3
SERVICE DELIVERY ORGANIZATION (TO BE ADVISED AT LATER DATE) ................................................................ 19
3.3.1 Roles and responsibilities ............................................................................................................. 19
3.3.2 Meetings and Communication mechanisms ................................................................................ 20
4
PROCESS AND SERVICE DEFINITION .................................................................................................... 22
4.1
SERVICE DESIGN .................................................................................................................................... 22
4.1.1 Service Level Management ........................................................................................................... 22
4.1.1.1
4.1.1.2
4.1.1.3
Process Overview ................................................................................................................................ 22
Process Roles and Responsibilities ...................................................................................................... 23
Service Level Process Flow .................................................................................................................. 24
4.2
SERVICE TRANSITION .............................................................................................................................. 29
4.2.1 Change Management ................................................................................................................... 29
4.2.1.1
4.2.1.2
4.2.1.3
4.2.2
Process Overview ................................................................................................................................ 29
Process Roles and Responsibilities ...................................................................................................... 31
Change Process Flow ........................................................................................................................... 32
Release and Deployment Management ....................................................................................... 36
4.2.2.1
4.2.2.2
4.2.2.3
Process Overview ................................................................................................................................ 36
Process Roles and Responsibilities ...................................................................................................... 38
Release & Deployment Process Flow .................................................................................................. 39
4.3
SERVICE OPERATION............................................................................................................................... 43
4.3.1 Incident Management .................................................................................................................. 43
4.3.1.1
4.3.1.2
4.3.1.3
4.3.2
Process Overview ................................................................................................................................ 43
Process Roles and Responsibilities ...................................................................................................... 44
Incident Process Flow .......................................................................................................................... 46
Problem Management.................................................................................................................. 50
4.3.2.1
Process Overview ................................................................................................................................ 50
pag. 3 of 69
REACH Project: Operations Governance Manual
4.3.2.2
4.3.2.3
4.3.3
Request Fulfillment ....................................................................................................................... 56
4.3.3.1
4.3.3.2
4.3.3.3
4.3.4
Process Roles and Responsibilities ...................................................................................................... 51
Problem Process Flow ......................................................................................................................... 52
Process Overview ................................................................................................................................ 56
Process roles and responsibilities ........................................................................................................ 57
Request Fulfillment Process flow ........................................................................................................ 58
Access Management .................................................................................................................... 60
4.3.4.1
4.3.4.2
4.3.4.3
Process Overview ................................................................................................................................ 60
Process roles and responsibilities ........................................................................................................ 61
Access Process Flow ............................................................................................................................ 62
4.4
CONTINUAL SERVICE IMPROVEMENT ......................................................................................................... 64
4.4.1 Service Reporting .......................................................................................................................... 64
4.4.1.1
4.4.1.2
4.4.1.3
Process Overview ................................................................................................................................ 64
Process roles and responsibilities ........................................................................................................ 66
Service Reporting flow ........................................................................................................................ 67
pag. 4 of 69
REACH Project: Operations Governance Manual
List of Pictures
PICTURE 1 OPERATIONS SUPPORT MODEL INTRODUCTION - APPROACH ............................................................................... 8
PICTURE 2 ITIL PROCESSES IN SCOPE ........................................................................................................................... 10
PICTURE 3 SERVICE CATALOGUE ................................................................................................................................. 11
PICTURE 4 SERVICE DELIVERY MODEL .......................................................................................................................... 18
PICTURE 5 SERVICE ORGANIZATION ............................................................................................................................ 19
PICTURE 6 HIERARCHICAL ESCALATION LEVELS .............................................................................................................. 21
PICTURE 7 SLA MANAGEMENT PROCESS FLOW ............................................................................................................ 24
PICTURE 8 CHANGE MANAGEMENT PROCESS FLOW ....................................................................................................... 33
PICTURE 9 CHANGE MANAGEMENT STATUS WORKFLOW ................................................................................................ 33
PICTURE 10 RELEASE AND DEPLOYMENT PROCESS FLOW ................................................................................................ 40
PICTURE 11 RELEASE AND DEPLOYMENT STATUS WORKFLOW .......................................................................................... 40
PICTURE 12 INCIDENT MANAGEMENT PROCESS FLOW ................................................................................................... 46
PICTURE 13 INCIDENT MANAGEMENT STATUS WORKFLOW ............................................................................................. 46
PICTURE 14 PROBLEM MANAGEMENT PROCESS FLOW ................................................................................................... 52
PICTURE 15 PROBLEM STATUS WORKFLOW .................................................................................................................. 53
PICTURE 16 REQUEST FULFILLMENT PROCESS FLOW ...................................................................................................... 58
PICTURE 17 REQUEST FULFILLMENT STATUS WORKFLOW ................................................................................................ 58
PICTURE 18 ACCESS MANAGEMENT PROCESS FLOW ...................................................................................................... 62
PICTURE 19 ACCESS MANAGEMENT STATUS WORKFLOW ................................................................................................ 62
PICTURE 20 SERVICE REPORTING PROCESS FLOW........................................................................................................... 67
PICTURE 21 REPORTING STATUS WORKFLOW ............................................................................................................... 68
pag. 5 of 69
REACH Project: Operations Governance Manual
List of Tables
TABLE 1 SERVICE LEVEL MANAGEMENT ROLES AND RESPONSIBILITIES ............................................................................... 24
TABLE 2 SERVICE LEVEL PROCESS STEPS AND RACI MATRIX............................................................................................. 25
TABLE 3 INCIDENT AND PROBLEM MANAGEMENT SLA ................................................................................................... 26
TABLE 4 PROBLEM MANAGEMENT SLA ....................................................................................................................... 27
TABLE 5 QUALITY OF THE WORK ................................................................................................................................. 27
TABLE 6 RESPONSE TIME .......................................................................................................................................... 28
TABLE 7 SERVICE LEVEL STEPS AND DESCRIPTION .......................................................................................................... 29
TABLE 8 CHANGE STATUS LIST AND DESCRIPTION ........................................................................................................... 34
TABLE 9 CHANGE MANAGEMENT STEPS LIST AND RACI MATRIX ...................................................................................... 35
TABLE 10 CHANGE ROLES AND RESPONSIBILITIES .......................................................................................................... 36
TABLE 11 RELEASE AND DEPLOYMENT STEPS AND RACI MATRIX...................................................................................... 39
TABLE 12 RELEASE AND DEPLOYMENT STATUS LIST ........................................................................................................ 41
TABLE 13 RELEASE AND DEPLOYMENT PROCESS STEPS AND RACI MATRIX ......................................................................... 42
TABLE 14 RELEASE PROCESS STEPS AND DESCRIPTION .................................................................................................... 43
TABLE 15 INCIDENT ROLES AND RESPONSIBILITIES ......................................................................................................... 46
TABLE 16 INCIDENT STATUS LIST ................................................................................................................................ 47
TABLE 17 TYPE TICKET ............................................................................................................................................. 47
TABLE 18 PRIORITY MATRIX ...................................................................................................................................... 48
TABLE 19 INCIDENT PROCESS STEPS AND RACI MATRIX ................................................................................................. 49
TABLE 20 INCIDENT MANAGEMENT PROCESS STEPS ....................................................................................................... 49
TABLE 21 PROBLEM MANAGEMENT ROLES AND RESPONSIBILITIES ................................................................................... 52
TABLE 22 PROBLEM STATUS LIST ................................................................................................................................ 53
TABLE 23 PROBLEM PROCESS STEPS AND RACI MATRIX................................................................................................. 54
TABLE 24 PROBLEM MANAGEMENT PROCESS STEP DESCRIPTION ..................................................................................... 55
TABLE 25 REQUEST FULFILLMENT ROLES AND RESPONSIBILITIES ....................................................................................... 58
TABLE 26 REQUEST FULFILLMENT STATUS LIST .............................................................................................................. 59
TABLE 27 REQUEST FULFILLMENT PROCESS STEPS AND RACI MATRIX............................................................................... 59
TABLE 28 REQUEST FULFILLMENT PROCESS STEP DESCRIPTION ......................................................................................... 60
TABLE 29 ACCESS PROCESS ROLES AND RESPONSIBILITIES ................................................................................................ 61
TABLE 30 ACCESS MANAGEMENT STATUS LIST .............................................................................................................. 63
TABLE 31 ACCESS MANAGEMENT PROCESS STEPS AND RACI MATRIX ............................................................................... 63
TABLE 32 ACCESS MANAGEMENT PROCESS STEP DESCRIPTION......................................................................................... 64
TABLE 33 REPORTING ROLES AND RESPONSIBILITIES ....................................................................................................... 67
TABLE 34 REPORTING STATUS LIST ............................................................................................................................. 68
TABLE 35 SERVICE REPORTING STEP AND RACI MATRIX ................................................................................................. 69
TABLE 36 SERVICE REPORTING PROCESS STEPS AND DESCRIPTION ..................................................................................... 69
pag. 6 of 69
REACH Project: Operations Governance Manual
1 Introduction
1.1 REACH Project overview
UNRWA (the United Nations Relief and Works Agency for Palestine Refugees in the Near East)
provides assistance, protection and advocacy for some 5 million registered Palestine refugees in
Jordan, Lebanon, Syria, Gaza and West Bank.
The Agency’s services encompass education, health care, social safety-net, camp infrastructure and
improvement, community support, microfinance and emergency response, including intimes of
armed conflict. UNRWA (www.unrwa.org) is funded almost entirely by voluntary contributions from
UN member states.
UNRWA has identified, as one of its key levers of change, the implementation of an ERP platform for
supporting the goals of its Organizational Development plan. In this endeavour the Agency, after a
careful evaluation of the possible options, decided to explore a partnership with the WFP to benefit
from their experience in the implementation and operations of a successful, SAP - based, ERP. This
planned partnership is an opportunity for both risk mitigation and cost saving.
The main objectives of UNRWA’s ERP Project are summarized below:
Replacing the Agency’s legacy ERP system, which will have no technical support after 2014;
Improving the Agency’s monitoring and oversight capabilities;
Supporting management and programming reforms under the Sustaining Change and
related initiatives.
One of the work packages of the project is the Production Support Readiness that has the
objective of supporting UNRWA in setting up the organisation and processes to successfully
transition the project into full operational modality.
1.1.1 Purpose of this document
The purpose of the document is to describe the process and service definition in scope for the ERP
Operation Service needed to support UNRWA in setting up the organisation and processes to
successfully transition the project into full operational modality.
1.1.2 Scope and target audience
The scope of the document is to describe the processes and basic services derived from the
Information Technology Infrastructure Library (ITIL) standard and UNRWA ERP Service Operation
model. The operation model outlines a service lifecycle approach to IT operations in supporting the
business. That model has been adopted as a standard for IT service management as a way to
effectively control and manage service delivery.
pag. 7 of 69
REACH Project: Operations Governance Manual
2 REACH Service Operation overview
The main objectives of Production Support Readiness work package is to support UNRWA in
setting up the organisation and processes to successfully transition the ERP project into full
operational modality.
To gain this objectives, a step by step approach has been adopted: the so called CORE
APPROACH: starting from the design and set up of the core set of ITIL processes jointly with the
related organizational aspects, that approach aims at managing the transition into operation of the
ERP project and, at the same time, at activating rules and tools to effectively control and manage
service delivery
Picture 1 Operations Support Model introduction - approach
The main purposes of Phase1 are:
to set up a first set of governance rules;
to establish a formal tracking process;
to support system to manage all service requests;
to support Incidents and problem calls;
to manage Change management and release management processes;
to define and manage SLA/KPI.
From the strategic point of view the CORE APPROACH plans to use separate Service Desk for ERP
services as a starting point; at the same time that approach considers that ultimately single Incident
Process Management will be adopted and a single tool will eventually be deployed across all
UNRWA IT support functions.
The main advantages related to this approach are:
to introduce the new model using the ERP service as a forerunner minimizing the impact on
the existing SD and on the services supported by it;
to move towards a formalizing ITIL model in an incremental and run-oriented manner;
pag. 8 of 69
REACH Project: Operations Governance Manual
to allow for a quick way of addressing high number of Incidents during the initial Go-live ERP
support while minimising the number of Escalation points and layers involved;
to minimize the impact on trainees;
to approach the transition in an incremental way, by implementing ITIL processes as
recommended by the ITIL best practice starting from the core processes (e.g.: Incident).
The organization structure is split into 4 levels, as showed in the following picture, and will be
detailed in the next chapters. The meaning of each level is:
LO -Business Process Focused (UNRWA business ERP key users – embedded);
L1 - Ticket Focused (Service Desk level – Basic support);
L2 - Functional Domain Focused (UNRWA internal technical and functional support groups);
L3 - Applications/Packages/Infrastructure Focused (Internal or external service support
groups).
2.1 Service scope and description
The CORE APPROACH applied to the UNRWA context permits to identify a core set of the ITIL
processes, in particular the group strictly related to the Service Operation stage, as showed in the
following picture.
pag. 9 of 69
REACH Project: Operations Governance Manual
Service Transition (Build):
Service Strategy:
(1)
Financial Management
(2)
(3)
Service Portf olio Management
Demand Management
Service Design:
(1)
Service Catalogue Management
(2)
(3)
(4)
(5)
(6)
Service Level Management
Capacity Management
Availability Management
IT Service Continuity Management
Inf ormation Security ;Management
(7)
Supplier Management
7-Step Improvement Process
(2)
(3)
Service Measurement
Service Reporting
Change Management
(2)
(3)
(4)
(5)
(6)
Service Asset and Conf iguration Management
Release and Deploy Management
Service Validation and Testing
Evaluation
Knowledge Management
(7)
Transition Planning and Support
Service Operation (Run):
Continual Service Improvement:
(1)
(1)
(1)
Incident Management
(2)
(3)
(4)
(5)
Request Fulfilment
Problem Management
Access Management
Event Management
Service Operation Functions
Legenda
Process name
In scope
Process name
Out of scope
Service Desk Function
Technical Management Function
Application Management Function
IT Operations Management Function
Picture 2 ITIL Processes in scope
In order to prepare UNRWA to introduce the new expanded ERP service desk and set up the new
model of operation, 3 phases have been identified:
INTERIM HELP, covering all the activities before the Cut Over of the SAP ERP Service;
HYPERCARE, covering from the Cut Over to the end of warranty period of the ERP SAP
Service (including the Go-Live);
STABLE, from the end of warranty period on.
The following table shows the order of the in-scope processes implementation to be taken during the
different phases of transition.
Phases
INTERIM HELP
Process
Incident Management
(Basic);
Service Level
management (CORE
concepts related to
KPI/SLA definition and
to set up key
governance
mechanism);
HyperCare
Incident
Management
(Complete);
Problem
Management;
Request Fulfilment ;
Service Governance
(Basic);
Service reporting
(Basic - CORE
concepts related to
KPI/SLA definition
and to set up key
governance
mechanism).
Stable
Service
Governance;
Service Level
management
(Complete);
Release
Management;
Change
Management ;
Access
Management;
Service Reporting
(Complete).
The definition and design of each process is strictly related to the ERP Service Catalogue and to the
Functional Organization identified, in terms of structure and key information of each function
included in the model, and it will be enriched from Interim to Stable phase.
pag. 10 of 69
REACH Project: Operations Governance Manual
The following picture shows the complete list of Services in-scope, pointing out the phase of the
transition plan within with each service will be activated.
Picture 3 Service Catalogue
2.2 Services activated during Interim Help phase
The following picture represents the main information of the service that has already been activated
during the Interim Help phase.
pag. 11 of 69
REACH Project: Operations Governance Manual
Interim Help Phase: main information
End Users
E-mail
Phone call
Service Categorization
FUNCTIONAL
ESCALATION
yes
SAP APP
FUNCTIONAL
ESCALATION
CITRIX SAP
VPN SAP
2nd Level Functional Units
CGI 3rd Level Technical Team
Mr Nicola
Larocchia
ERP Operation Support Model - meeting | July /2014
Copyright © Capgemini 2012. All Rights Reserved
1
During the Interim Phase, a list of Services has been activated for each Level:
LEVEL
SERVICE
Service Desk – Call Centre for all Services
Security Roles Management
Citrix Access
VPN Access
SAP CGI Basis
Citrix Contracts
1
2
3
2.2.1 Point of Contact, Classification and Escalation Points
A list of Escalation Points will underline that some teams will perform different tasks depending on
the Service considered and the documentation available during this phase.
Service
SAP
Application
Category
SAP
Application
SAP
(everything
technical)
uPerform and
Moodle
application
issues
Escalation point
ERP Functional
Stream Leads
CGI team
FICTO team
Enterprise Team
ERP training
team
Kind of Request
Documentation
Application functionality or
data query
Problems, new users, DRAFT SAP user
permissions, profiles
password
instructions
Local PC and Network
uPerfom
Installation Guide
International MPLS
Anything else (Problems,
new users, permissions,
pag. 12 of 69
REACH Project: Operations Governance Manual
Service
Category
JIRA
Application
Citrix SAP
VPN SAP
Citrix
Infrastructure
Citrix Telecom
Citrix
(everything
else)
Escalation point
Chris Ham
Jeong (ISD
team)
Julien (ERP
Test Team)
FICTO team
Enterprise Team
CGI Team
VPN SW
ERP
Building
local IT support
Anas
VPN
(everything
else)
Valencia team
(Roberto
Santamaria)
Kind of Request
profiles)
Technical server issues
Documentation
JIRA Application issues
(App
problems,
new
users,
permissions,
profiles)
Local PC and Network
DRAFT
Citrix
Installation
International MPLS
Instructions
Anything else (Problems, PENDING Citrix
new users, permissions,
user mgmt
profiles)
VPN SW installation
UNRWA
VPN
User Manual
VPN
software
All other issues
available
with
ERP building local
IT support Anas
2.3 Services activated during HyperCare phase
This section includes the description of the ticket categorization, the escalation matrix and all the
other details needed from HyperCare phase.
2.3.1 Service Desk TO BE model strategy modifications
At the end of the INTERIM HELP phase there has been a a variations from the previous adopted
Core Approach (it is based on an incremental approach that plans to use separate Service Desk for
ERP services, SAP dedicated, towards the Global SD Approach (it assumes the adoption of a
single Service Desk function shared between all IT groups able to force the use of a single Incident
Process Management and of a single tool for each service support group).
pag. 13 of 69
REACH Project: Operations Governance Manual
The description of the process in scope, currently implemented into the SDExpress tool, is
included in the SDE Technical Documentation v1 7.doc provided by ICTO.
2.3.2 Point of Contact, Classification and Escalation Points
The following section shows the categorization which will be used by Service Desk to identify and
categorize the Incident or/and Service Request a customer is experiencing. The escalation matrix
represents, for each service, the entry point of the flow and subsequent levels for managing it.
pag. 14 of 69
REACH Project: Operations Governance Manual
2.3.2.1 Incident categorization and Escalation Matrix
1st Level
2nd Level
3rd Level
4th Level
Account Administration
Account Admin - Domain/Active Directory
Voice Mail
Applications-General
Adobe Acrobat
Other Applications
How to
MS Visio
General Issues
How to
Applications-Enterprise
BMC Serivce Desk
Access Issue
General Issue
Ramco applications
FMS
HRM/ Payroll
PIMS
Travel Management System (TMS)
.................................................
REACH Apps
SAP FIN
SAP SCM
Barcoding App
SAP PSM
SAP HR
eTM App
Nakisa App
ePer App
ORIS App
Corporate Apps
Uperform App
Moodle App
Confluence App
Jira App
ARIS App
Integration Apps
WSO2 App
DWH Apps
SAP BI/BO
Applications-JFO
..........................
The following is the escalation matrix, included in the SDExpress tool, and related to the incident
management of the REACH-related services category.
pag. 15 of 69
REACH Project: Operations Governance Manual
SAP FIN
SAP SCM
Barcoding
SAP PSM
SAP HR
eT M
Nakisa
ePer
ORIS
Uperform
Moodle
Confluence
Jira
Jira
WSO2
SAP BI/BO
HQA Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
JFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
SFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
WBFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
LFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
GFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
HQA L1 App Support
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
SFO L1 App Support
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
LFO L1 App Support
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
WBFO L1 App Support
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
HQG L1 App Support
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
2nd Level
2nd Level
2nd Level
2nd Level
2nd Level
2nd Level
2nd Level
Group vs. Category Escalation Matrix
HQA FirstLine
JFO L1 App Support
SCM Apps team
HR Apps team
FIN Apps Team
2nd Level
PSM Apps Team
2nd Level
Integration Apps team
2nd Level
DWH Apps Team
2nd Level
Corporate App Team
2nd Level
2nd Level
2nd Level
2nd Level
2nd Level
Enterprise Infrastructure
.........................
Vendors
2.3.2.2 Service Request categorization and Escalation Matrix
Service category Name
FIN Access request
FIN reset password
HR Access request
HR reset password
PSM Access request
PSM reset password
SCM Access request
SCM reset password
Uperform Request
Moodle Request
Confluence Request
Jira Request
ARIS Request
WSO2 Request
SAP BI/BO Request
Type
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
The following is the escalation matrix, included in the SDExpress tool, and related to the Service
Request management of the REACH-related services category.
pag. 16 of 69
REACH Project: Operations Governance Manual
FIN Access
request
FIN
Modify/reset
password
HR Access
request
HQA Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
JFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
SFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
WBFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
LFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
GFO Helpdesk
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
Group vs.
Category
Escalation Matrix
HR
PSM
SCM
Modify/reset PSM Access Modify/reset SCM Access Modify/reset
password
request
password
request
password
Uperform
Request
Moodle
Request
Confluence
Request
WSO2
Request
SAP BI/BO
Request
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
1st Level
Jira Request ARIS Request
HQA FirstLine
HQA L1 App
Support
JFO L1 App
Support
SFO L1 App
Support
LFO L1 App
Support
WBFO L1 App
Support
HQG L1 App
Support
SCM Apps team
2nd Level
HR Apps team
FIN Apps Team
PSM Apps Team
2nd Level
2nd Level
2nd Level
Integration Apps
team
DWH Apps Team
2nd Level
2nd Level
Corporate App
Team
2nd Level
2nd Level
2nd Level
2nd Level
2nd Level
.......
Vendors
2.4 Services activated during STABLE phase
The services which will be activated during this phase are the same of the HyperCare one.
As a result of the decision to adopt the current UNRWA Service Desk tool, SDExpress, is that all the
information currently present in the above instrument will be adopted as workflows, configurations
and so on.
The processes described in §4 refer to the TO BE scenario which will be taken into consideration by
STABLE phase onwards.
3
REACH Service Operation Governance (To be advised at later date)
The REACH Service Operation’s governance model is supported by a structure of governance
boards which have clear attendees, objectives, accountabilities and frequency. By integrating IT
governance with IT service management (ITIL® v3) it will be possible to deliver a lifecycle approach
to service management which significantly increases the likelihood of successful service integration.
The phasing approach will move through simplification and improvement of operations, processes
and technology and into evolution of the services through continuous improvement, lean techniques
and other transformation projects. The structure of service delivery organization may change as a
result of these phases, and other boards may be required periodically, but the governance model will
always remain constant.
The service management team will develop, implement and maintain the policies, processes,
procedures and Work Instructions based on the strategies handed down from the IT governance and
operational boards. They will be communicated via a service assurance function so that they are
applied to all IT services being delivered. The performance of the delivery organizations will be
periodically monitored, reporting back to the business.
3.1 Service delivery approach
The purpose of this service is to support process of managing Problems and Incidents from their
detection through final resolution. It encompasses the registration, analysis, recovery, resolution and
tracking of faults, Problems or Incidents occurring in the supported services. In this way, the
pag. 17 of 69
REACH Project: Operations Governance Manual
disruption of service(s) is limited as much as possible. In any case service must guarantee the
Service Level Agreements (SLA).
All requests, enquiries and issues are dispatched by End users to the Service Desk Unit and entered
into the Service Desk Tool. The Service Desk actively monitors these calls and their status.
If call are in the scope of the service and End-user was not provided with a suitable and well
documented solution, Service Desk shall take in charge calls and solve it. They also analyze all
handled calls to investigate trends, re-occurring Incidents and Incidents requiring a more structural
solution (Problem Management).
The picture below summarizes the service delivery model overview and how processes are covered
by each level included in the service organization:
Service Delivery Model
User Community
0
Change Requests
1
Incident Management
PowerUsers
Release Management
Service Desk Unit
– 1st Level Support –
Service Request
Governance & Service
Management
Governance Operations
2
Application Management
– 2nd Level Support –
Service Management
Incident Management
Incident/Problem
Resolution
3
Service Reporting
SAP Basis
SLA Management
Escalation Management
Change Requests
Release Management
Application Management
- 3rd Level Support –
Problem Resolution
SAP basis
Infrastructure & 3rd Party Management
Picture 4 Service delivery model
3.2 REACH Service Functional organization
The proposed model shows different Units for each level:
pag. 18 of 69
REACH Project: Operations Governance Manual
The key information regarding each Unit belonging to each level are listed in the table below.
LEVEL
Unit
0
1
Key activities in charge
Embedded Power Users
Business Support Functions
Service Desk Unit – It will embrace Service
Desk Team and a 1st Level Apps Support Team
Operating as SPOC (Single point of contact) basically in
charge of the first line support and of collecting issues
and requests on all services related subjects. It is a
central call-tracking organization and it can be viewed as
the central service hub for the management of all service
issues.
Apps Escalation Support Unit, composed of
SAP Groups referring to FIN, SCM, PSM and
HR groups;
Technical 2nd Level support Unit;
RAMCO Support Unit
Contractual Outsourcing (ISD Infrastructure,
Third Party Technical Contracts, Third Party
ERP Apps Contracts)
2
3
Each Functional Group will offer the 2nd level support for
managing/resolving Ticket related to its peculiar stream.
Units belonging to this level are dedicated to application
maintenance activities.
3.3 Service Delivery Organization (To be advised at later date)
The Service Delivery Model is governed by a structured methodology based on ITIL framework and
able to provide the processes and the procedures in order to guarantee a proper service delivery. At
the same time the service level approach on which it is based permits to identify the responsibility for
each level, manage the dependencies and clearly define the points of interaction either for resolving
issues than for monitoring the quality of services delivered.
Executive Service
Management
Service Manager
Service Desk Unit
1
Technical 2nd Lev Support
Unit
RAMCO Support Unit
Apps Escalation Support Unit
HR Apps
SAP HR
SAP SCM
SAP PSM
SCM Apps
SAP FIN
PSM Apps
FIN Apps
DWH Apps
Integration
Apps
Corporate
Apps
Ramco
Apps
2
IntegrationDWH
SAP CGI Basis
UNGSC
Hosting
Citrix
WAN
RAMCO Services
DB-SysAdmin
Ramco
3
Technical Services
ISD Services
REACH Apps Services
Picture 5 Service Organization
3.3.1 Roles and responsibilities
The table below summarizes the key tasks group which will be executed by each role.
Role
Duties and Responsibilities
Service Manager
Ensures that service levels are met with regards to
pag. 19 of 69
REACH Project: Operations Governance Manual
Role
Duties and Responsibilities
recording and closure of incidents. Provide mentoring
and coaching to support staff, which will include
technical trouble shooting.
Manages and supervises the work and daily
performance of the staff responsible for the delivery of
ICT services
Sets objectives, review performance and develop the
skills of directly supervised staff ensuring that
appropriate training and development plans are
formulated and provide coaching particularly in relation
to operational management techniques.
Service Desk Team Member
The main duties of this roles, belonging to the Service Desk
Unit, are:
Operating as SPOC (Single point of contact) in charge
of implementing the ITIL in-scope Processes
Ticket opening and closure
Ticket chasing and routing to internal/external Unit;
Execute the Level 2 escalation ;
User Support (How to....): respond to all user calls in a
customer-focused and timely manner
Communicate solutions to End Users
Application Support Technician Team
The main duties of this roles, belonging to the Service Desk
Unit, are:
Incident Resolution;
First level Root cause analysis;
Escalate and route unresolved call tickets as incidents
to relevant support teams;
Interface processing errors monitoring;
Quality assurance management;
Backlog analysis and performance check
Role assignment;
User master record creation;
User management on standard roles
Apps Escalation Support Unit
Technical 2nd Level Support Unit
SAP functional stream modules business analysis
support;
Performing functional configuration, testing and
maintenance tasks;
Root cause analysis, error diagnosis and error handling;
Master data coherence check;
Providing training and document maintenance;
In charge of problem and change management
lifecycle;
Execute trouble prevention and escalation to the next
functional level;
Manage Security ticket (Missing authorization,
segregation , ecc);
Customization management of controlling and business
area, derivation rules
Performing functional configuration, testing and
maintenance tasks;
Monitoring activities;
Root cause analysis, error diagnosis and error handling;
Providing training and document maintenance;
In charge of problem and change management
lifecycle;
Execute trouble prevention and escalation to the next
functional level
3.3.2 Meetings and Communication mechanisms
The aim of Service Governance is to bring together both service recipient and service provider to
jointly manage the service. Establishing the governance model early in transition is a critical success
pag. 20 of 69
REACH Project: Operations Governance Manual
factor for outsourced partnerships because it provides a formal structure to facilitate the generation
of policies that will govern the way services are delivered. It also establishes a joint decision-making
authority when it is most needed.
In order to facilitate the right interfaces between both parties in the relationship, the set-up of the IT
governance model at the outset of the relationship needs to be hierarchical with different forums
responsible for varying levels of authority.
Timelines are usually based on established service levels. The thresholds are built in order to allow
management enough time to respond to a potential breach. Automatic and manual escalation
activities will include notifications to analysts and management when predefined thresholds are in
danger of being breached. The hierarchic escalation levels can be summarised as follows:
ESCALATION
Management Committee
EXECUTIVE
SERVICE
MANAGEMENT
UNRWA
Provider
Contract Manager (*)
Delivery Manager
Service Manager
Account Manager
Programme Manager
Service Executive
(Quarterly)
•
•
•
•
•
Contract Management
Monitoring Service Delivery
Change Control
KPI’s and progress management
Resolving Escalated Issues
(*) On Demand
(Plus Other as Appropriate)
OPERATIONAL
Service
Management
Service Management
Provider
UNRWA
Service Manager
(Montly)
Service Manager
(Plus Other as Appropriate)
•
•
•
•
•
•
Tracking day to day service
Tracking SLAs, quality, audits, etc
Change request
Workload planning
Recomanding new proposal
Report to Executive Service
Management
Picture 6 Hierarchical Escalation Levels
Governance Board
Description
Frequency
Management
Committee
Responsible for setting the overall strategy Quarterly
and direction for the service. This board
would meet regularly (maybe every quarter)
to review supplier performance and service
improvement proposals, and give guidance
on future business plans that may impact IT
Services
Service Management
Committee
Responsible for implementing the strategy Monthly
and ensuring effective performance of the
ongoing service. This board would conduct
the monthly Service Review Meetings with
service providers. It is responsible for the day
to day management of projects and service.
Managers at this level would be involved in
overseeing both day to day and weekly
governance meetings.
pag. 21 of 69
REACH Project: Operations Governance Manual
4 Process and Service definition
4.1 Service Design
The objective of Service Design is to provide guidance for designing and developing of services and
service management processes, and to cover design principles and methods for converting strategic
objectives into portfolios of services and service assets.
4.1.1 Service Level Management
4.1.1.1 Process Overview
Service Level Management maintains and improves IT service quality, through a constant cycle of
agreeing, monitoring and reporting upon IT service achievements and instigation of actions to
eradicate poor service – in line with business or cost justification.
4.1.1.1.1 Objectives
The objectives of Service Level Management are the following:
to ensure that all operational services and its performance are measured in a consistent,
professional manner throughout the IT organization, and that the services and the reports
produced meet the needs of the business and Business Users;
to define the process required to agree required Service Level Targets and monitor and review
performance against the agreed targets.
4.1.1.1.2 Scope
Service Level Management is responsible for ensuring that all IT Service Management Processes,
Operational Level Agreements, and Inter-Company Agreements are appropriate for the agreed
Service Level Targets. SLM monitors and reports on Service Levels, and holds regular Customer
reviews. Individual Service Levels are defined for new and existing Services as part of the Project
Delivery process, governed by Service Design and Introduction.
4.1.1.1.3 Inputs and Outputs
The list below summarizes the inputs of the process:
Contract that describes the required Service Levels and the existing Service Level
Framework;
Business Requirements;
Service Level Requirements as described within the Requirements Catalogue;
New or changes to existing Services introduced via the Service Design and Introduction
Process;
Transition Due Diligence findings;
IT Service Catalogue;
Project Definition Package;
Project Viability Report.
The outputs of the process are:
Operational Level Agreements;
Inter-Company Agreements;
Service Review Minutes & Actions;
pag. 22 of 69
REACH Project: Operations Governance Manual
CSI Opportunities;
Service Exception Reports.
4.1.1.1.4 Process key Concepts
Service Level Target (SLT)
A SLT is a commitment that is documented in the contract. Service Level Targets are needed to
ensure that the IT Service design is fit for purpose.
Service Level Agreement (SLA)
A SLA is an agreement between the Solution Provider and UNRWA. The SLA describes the IT
Service, documents Service Level Targets and specifies the responsibilities of the IT Service
Provider and UNRWA. The Service Level Agreement is described within the contract.
Operational Level Agreement (OLA)
OLA is an Agreement between the Solution Provider and another part of the same Organisation. The
OLA defines the Services to be provided and the responsibilities of both parties.
Service catalogue
Service level management must ensure that a service catalogue is produced, maintained and
contains accurate information on all operational services and those ready for deployment. A service
catalogue is a written statement of all current and available IT services, default levels and options.
UC (Underpinning Contract)
A written agreement with an external IT supplier.
4.1.1.2 Process Roles and Responsibilities
The responsibilities described below are in the context of Service Level Management and are not
exhaustive.
Role
Duties and Responsibilities
Service Level Manager
Internally within IT, establish and maintain strong
working relationships with Senior Sponsors, Department
Heads, Process Owners ( Change Manager, Incident
Manager, Problem Manager, etc…)
Externally outside of IT, establish and maintain strong
working relationship with business unit directors and
managers. May also be responsible for relationships
with Supplier Management
Establish a Service Review process; planning,
organizing and facilitating recurring meetings
Carries out regular audit of ICT Application Systems
and provides necessary information to the ICT Service
catalogue manager keeping the ICT Service Catalogues
up to date.
Participate fully within the negotiation of agreement and
maintenance SLAs.
Manages, maintains, Negotiates, agrees OLAs within
ICT technical teams in conjunction with line
management
Analyses and reviews actual service performance
against SLAs, OLAs and KPIs for service areas under
scope
Initiates and co-ordinates actions to maintain or improve
service levels
Act as a co-ordination point for any temporary changes
to service levels
Act as a single point of contact for the ICT departments
in relation to Service Level Management
Act as a key member of staff in SLA negotiation efforts
pag. 23 of 69
REACH Project: Operations Governance Manual
Role
Duties and Responsibilities
Service Manager
SLA Reporting Manager
Ensures that service levels are met with regards to
recording and closure of incidents. Provide mentoring
and coaching to support staff, which will include
technical trouble shooting.
Manages and supervises the work and daily
performance of the staff responsible for the delivery of
ICT services
Sets objectives, review performance and develop the
skills of directly supervised staff ensuring that
appropriate training and development plans are
formulated and provide coaching particularly in relation
to operational management techniques.
Provides and develops regular reports Service Level
Reports on service performance and achievement to the
Application systems and Workflow Manager.
Reviews SLA targets and metrics where necessary
Reviews OLA targets and metrics where necessary
Reviews third party underpinning agreements where
necessary
Identifies appropriate actions to maintain or improve
service levels
Manage and maintain the catalogue description of
existing services offered by ICT
Table 1 Service Level Management Roles and Responsibilities
4.1.1.3 Service Level Process Flow
4.1.1.3.1 Service Level Management Process flow
Picture 7 Sla Management Process Flow
Process Step
RACI
pag. 24 of 69
REACH Project: Operations Governance Manual
Responsible
Accountable
1. Produce Service Catalogue
SLA Reporting
Manager
Service Level
Manager
2. Review existing Agreement
SLA Reporting
Manager
Service Level
Manager
3. Plan SLA Structure
SLA Reporting
Manager
Service Level
Manager
4. Review Viability Report
SLA Reporting
Manager
Service Level
Manager
5. Define Service Level
Requirements and Draft SLA
SLA Reporting
Manager
Service Level
Manager
6. Design SLRs
SLA Reporting
Manager
Service Level
Manager
7. Design OLA/UC requirements
SLA Reporting
Manager
Service Level
Manager
8. Design Service Meaurement &
Reporting
SLA Reporting
Manager
Service Level
Manager
9. Negotiate Agreement
Service Level
Manager
10. Publish Final SLA and
Update Service Catalogue
SLA Reporting
Manager
Service Level
Manager
11. Monitor Performance
SLA Reporting
Manager
Service Level
Manager
12. Generate exption reports
SLA Reporting
Manager
Service Level
Manager
13. Conduct Service Review
Meetings
Service Level
Manager
Consulted
Informed
Service Manager
Service Manager
Service Manager
Service Manager
Service Manager
Table 2 Service Level Process steps and RACI Matrix
4.1.1.3.2 Service Level Management: SLA definition
During the Service Delivery and Management phase the Service Provider, according with the
Service deal agreed, assumes the full responsibility for the management of the services, processes
and applications and will deliver the agreed SLAs.
pag. 25 of 69
REACH Project: Operations Governance Manual
To ensure proper SLA measurement by UNRWA it is mandatory to preliminary adopt a dedicated
tool able to track the ticket life cycle, the status changes as well to monitor the response time of the
Service Provider application maintenance team. Usually SLAs is only applied when the ticket
monitoring tool became available and, during the first three/five months after the release in
production of the Ticketing System, no penalties are applied. This initial “grace period” generally
permits a proper test and stabilization of the tool itself but also of the service organization (both of
UNRWA and of the Service Provider) in terms of resources, sizing, competencies and procedures.
On the base for the SLA definition there are two main information:
Service Baseline Scope: describe the list of services and objects under the scope of the SLA;
the baseline includes the list of applications on which the Service Provider is in charge to
execute the following list of services:
o Corrective Maintenance: it includes detection, root-cause analysis, bug-fix isolation and
repair of incidents in the Application; Incident includes the occurrence/ manifestation of
an error in the Application, which causes it to no longer function in the manner recorded
in the functional description of the processes and data in the Functional design or
Technical Design. This maintenance involves correction of Bugs\Defects encountered
by applications Users in their day to day operations.
o Preventive Maintenance: This concerns the prevention in a structural manner of possible
future problems in the Application. Regular checks of the Application, trend analysis of
Incidents, monitoring and tuning of databases and guarding against possible limitations
in the operational Application environment (for example Infrastructure) are part of the
Preventive Maintenance. It is directed towards the removal of known errors before they
are raised and cause problems in the application. This can also include
upgrades/enhancement package configurations, customization, interface, reports.
o Perfective Maintenance: Activities for increasing the quality of the application, without
having consequences for the functional specifications or scope of the application. It
includes all interventions directed to improve technical efficiency.
Priority Criteria: The goal is to execute services incidents on a priority basis. In general, issues
with high business impact are resolved prior to issues with little or no business impact following
a Definition of Priority. The criteria used to working tickets is basically driven by Priority and for
each activities type is defined a range period for the Service Provider reaction. The opening
criteria is the “First Reaction” that correspond to the taking in charge of the ticket after the
opening.
4.1.1.3.3 SLAs for Incident and Problem
Priority
Duration until first reaction (IRT)
Duration until service end
(MPT)
1- Critical
1h
4h
2- High
2h
8h
3 – Medium
8h (1d)
16h(2d)
4 - Low
40h(5d)
80h(10d)
Table 3 Incident and Problem Management SLA
pag. 26 of 69
REACH Project: Operations Governance Manual
More indicative for the service quality is the elapsed time between the opening of the incident and
one of the main activities listed in the following matrix:
Priority
Root Cause identification
Incident/Problem resolution
1- Critical
≤ 1 day
≤ 1 day
2- High
≤ 2 day
≤ 2 day
3 – Medium
≤ 10 days
≤ 10 days
4 - Low
≤ 20 days
≤ 20 days
Table 4 Problem Management SLA
4.1.1.3.4 Proposed major KPIs
In below table are described the main KPIs useful to monitor the service quality performance,
grouped by categories and per each one a brief definition has been provided together with the
corresponding unit of measure.
Category
Quality
of
the work
Process
KPI
Definition
CROSS
Number of tickets – total
Number of ticket opened
timeframe (with status)
CROSS
Number of ticket by Priority and
Functional area
Number of ticket opened by Priority
and functional area in a timeframe
(with status)
Num
CROSS
Number of incidents/problems fixed
Number of Incidents/pre-approved
changes and problems fixed in a
timeframe
Num
Change
Process
Number of Changes (total)
Number of tickets
Changes (with status)
Num
Change
Process
Number of open Changes
Number
status)
CROSS
Reopening of the same ticket
Rework rate
%
CROSS
Incidents/problems
resolution rate
Rate
of
Incidents/pre-approved
changes and problems resolved by
the support at the first time opening
%
Incident
Process
Incidents defined as problems
Rate of incidents transformed in
problems
%
first
time
of
Unit
open
opened
Changes
in
a
for
(with
Num
Num
Table 5 Quality of the work
Category
Process
KPI
Definition
Unit
CROSS
Average time of Incidents/problems
resolution
Average time between the occurrence
of an Incidents/pre-approved changes
and problems and its resolution
Time
CROSS
Average time of Incidents/problems
resolution by Priority and Functional
area
Average time between the occurrence
of an Incidents/pre-approved changes
and problems and its resolution
grouped by Priority and Functional
Time
Response
Time
pag. 27 of 69
REACH Project: Operations Governance Manual
Category
Process
KPI
Definition
Unit
area
Change
Process
Average
time
of
Change
implementation by Category and
Functional area
Avarage
time
of
Change
implementation by Category and
Functional area (development acivity)
Time
Incident
Process
Average Incident initial response
time
The average time between the
detection of an incident and the first
action taken to repair the incident
Time
Table 6 Response time
4.1.1.3.5 Service Level Management Process steps
Process Step
Step description
1. Produce Service Catalogue
This step involves identifying a complete list of the services
to be delivered. All IT services are identified and categorized.
Individual components of IT services and the work required
to support them are understood and documented. Costs of
each service are identified and documented. Service level
bounds for each service are identified. In the plan phase an
integral part is a review of the current as-is capability within
the organisation, and historical performance against existing
SLAs. The information is gathered and published in a single
document The Service Catalogue.
At this step existing agreement will be analyzed an reviewed
At this step will be determined SLA Type, what can be
measured and reported on, and will be agreed on structure.
The SLA will be documented using the Service Catalogue
This step takes place during the viability and definition stages
of a Project to introduce a new or amended Service into
production. It requests to gain understanding and document
high level Client requirements.
At this step for the every Service is defined the required
Service Levels and Service Level Targets. SLA Draft is
produced.
At this step the initial SLRs captured in the "Define Service
Level Requirements" are analyzed and discussed among all
stakeholders ensuring they meet business requirements
Using the refined Service Level Requirements as a guide the
step works to define Operational Level Agreements (OLAs) is
performed in conjunction with all the service providers
supporting the IT service. The service providers can be from
internal or external organizations.
Where the Service Level Requirements indicate either a
change to the Service Level Targets for an existing Service,
or a new Service, it is necessary to raise the appropriate
Change to ensure the new targets can be measured and
reported via the Service Measurement & Reporting process.
This step covers the work of drafting and refining SLAs,
ensuring they meet business requirements and gaining
agreement from all parties involved. This means meeting
with the stakeholders to finalize contents of the SLS and the
service level targets, if required meeting with the supplier to
negotiate difference. After the agreement is reached the
agreement to be signed.
Once all parties have agreed, the SLA is published, a start
date determined and the affected operational teams notified.
Service Catalogue has to be updated.
At this step
Monitor the actual performance against the SLA
2. Review existing Agreement
3. Plan SLA Structure
4. Review Viability Report
5. Define Service Level Requirements and Draft SLA
6. Design SLRs
7. Design OLA/UC requirements
8. Design Service Meaurement & Reporting
9. Negotiate Agreement
10. Publish Final SLA and Update Service Catalogue
11. Monitor Performance
pag. 28 of 69
REACH Project: Operations Governance Manual
Process Step
Step description
12. Generate exption reports
13. Conduct Service Review Meetings
Produce operational reports daily and aggregate
results
At this Step
Generate exception reports on threatened or missed
service levels
Distribute reports to all stakeholders prior to the SLA
review
Resolve questions or disagreements prior to the SLA
review meeting determined and the affected
operational teams notified.
Prepare the agenda and send to attendees one week
prior to the meeting
Review actions and minutes from previous SLA Review
Review the service achievement in the last period
Preview any issues for the coming period
Review Forward Schedule of Change or Change
calendar
Document actions for the Customer and or the provider
as appropriate to improve weak areas
Review and re-agree different service targets if
required
Document and distribute the minutes
Store minutes on shared portal
Table 7 Service Level Steps and Description
4.2 Service Transition
The main goal of Service Transition is to align the new or changed service with the organizational
requirements and organizational operations. Service Transition includes the management and
coordination of the processes, systems and functions to package, build, test and deploy a release
into production and establish the service specified in the customer and stakeholder requirements.
4.2.1 Change Management
The Change Management lifecycle is designed to prevent unauthorized Changes being promoted
into the live environment, thereby endangering the service being provided.
4.2.1.1 Process Overview
Change Management processes ensure that standardized methods and procedures are used for an
efficient and prompt handling of all issues (corrective maintenance and minor evolutions) involving
changes, in order to minimize change-related problems.
4.2.1.1.1 Objectives
The process aims at ensuring that standardized methods and procedures are used for efficient and
prompt handling of all changes, in order to minimize the impact of change-related Incidents upon
service quality, and consequently improve the day-to-day operations of the organization.
4.2.1.1.2 Scope
This process covers all IT Changes that are to be made to the Live (Production) environment or
services. It must be able to execute change with minimal cost and minimal risk of business
disruption. IT must also be able to keep its infrastructure and services well-aligned with changing
business goals and priorities.
pag. 29 of 69
REACH Project: Operations Governance Manual
4.2.1.1.3 Inputs and Outputs
A Request for Change (RFC) is raised as a result of the identification of a ‘need for change’. RFCs
can come from any part of the organization and from any party contracted to provide services to that
organization. All RFC need an appropriate sponsorship and authorization.
A need for change will arise from a variety of reasons:
Proactively, e.g. seeking business benefits such as reducing costs or improving services or
increasing the ease and effectiveness of support. These requests may be in the form of a
proposal;
Reactively as a means of resolving errors and adapting to changing circumstances, e.g.
legislative or regulatory requirements.
The outputs of the Change Management Process are:
Appropriately prepared and sanctioned responses to a proposal on RFC;
Appropriate evidence of decisions regarding the approval of a Change Requests (CR);
Linked to successfully implemented changes which have met or exceeded all the expected
success criteria. In addition these changes have been implemented with no or minimal
unplanned disruptions to live/production environment;
Failed changes with an associated analysis of the reasons for the failure;
Partially successful changes providing an agreed partial service to the customer and an
associated Action Plan to address the identified issues;
Cancelled Changes;
Updates to associated information systems, e.g.: Configuration Management System
(CMS);
Updates to processes, e.g.: Problem Management and Incident Management;
Agreed reporting.
4.2.1.1.4 Process key Concepts
Change: a change is defined as “any addition, modification, movement, or deletion that impacts the
IT infrastructure or IT services”. This includes all Configuration Items (CI) defined as in scope.
Post Implementation Review: the Post Implementation Review is carried out for some defined
changes as detailed in the Change policy. The review should be carried out to confirm that the
change has met its objectives; the Requester and stakeholders are satisfied with the results; there
have been no unexpected side-effects. Lessons learnt are fed back into future changes.
Change Management must review new/changed services after a predefined period has elapsed.
The purpose of the PIR review is to establish that:
Change had the desired effect and met its objectives;
Users are satisfied with the results;
Resources used to implement that change were the same as planned;
Change is implemented on time and cost-compliant.
Where a change has not achieved its objectives, the review will establish what follow-up action is
required, which could involve raising a revised RFC. If the review is satisfactory or the original
change is abandoned – e.g. the circumstances that required the change or no longer current and the
requirements disappeared, RFC can then be formally closed in the logging system.
pag. 30 of 69
REACH Project: Operations Governance Manual
4.2.1.2 Process Roles and Responsibilities
The descriptions below are phrased as though there is a single individual responsible for and
executing each role. In practice some individuals may carry out a number of roles and equally some
of the roles may be carried out by more than one individual.
Role
Functional Unit
Functional Group
Responsibilities
SCM Apps team
HR Apps team
Apps Escalation
Support Unit
FIN Apps team
PSM Apps team
Change
Handler
Technical 2nd
Level Support Unit
DWH Services
Integration Services
Corporate Services
Change
Manager
pag. 31 of 69
Creating and recording RFCs;
Closing RFCs;
Performing UAT jointly with/on behalf of End-users
Validating Requests For Change (RFC);
Building Changes into Forward Schedule of
Change;
Risk Assessment of resolution activities and
implementation plans;
Manages this process on a day-to-day basis and is
responsible for authorizing all Changes. The
Change Manager may also own the process within
the organization;
Ensuring the agreed Requests For Change (RFC)
are entered correctly on the Change Control
System;
Ensuring RFCs are allocated an appropriate priority
in collaboration with the Requester;
Rejecting impractical RFCs;
Organizing Change Advisory Board (CAB)
meetings, ensuring agenda and papers are issued
to participants in good time;
Chairing CAB meeting;
Acting as the Change Approver for changes that are
not referred to the CAB;
Reviewing, monitoring and communicating the
progress and final outcome of Changes to all
relevant parties;
Communicating with the Change Calendar;
Ensuring a back-out plan is in evidence and has
been considered within the overall implementation
plan to minimize impact to service availability;
Arbitrating all Change queries;
Making the final decisions on authorization;
Ensuring that full approval is granted prior to
implementing Changes;
Ensuring documentation is completed and updated
(e.g. Assure risk and impact has been assessed and
REACH Project: Operations Governance Manual
Role
Functional Unit
Functional Group
Responsibilities
entered on the RFC;
Confirming that full technical details have been
entered on the RFC, assuring justification for
Change is evident and that affected system(s) are
stated;
Chairing Post Implementation Review meetings
managing any follow-up actions;
Identifying
improvements
to
the
Change
Management process;
Defining, documenting and ensuring adherence to
Change Policies
Providing accurate Major Change historical data;
Managing Effort Estimation;
Impact Analysis;
Circulating RFCs to CAB whenever the impact effort
is accepted and the solution review is required.
Supporting the authorization of changes and assisting
Change Management in the assessment and prioritization
of changes.
CAB
Project Team
Configuration
Manager
Executing the effort estimation, impact analysis,
requirement analysis;
Interfacing with the Change Handler;
Writing and making test case;
Developing change, system and integration test;
Writing technical documents, papers, delivery;
Making the assessment of change releases;
Delivering change details in order to appropriately
plan the release.
The Configuration Manager should be consulted and
informed at key points of several process steps
throughout the process.
The responsibilities of the configuration manager are:
To ensure that the Configuration Management
Database (CMDB) is accurate to allow the Problem
Management investigation to correctly associate
Problem and Known Error records with correct
Configuration Items (CIs) to facilitate the
investigation and analysis of business impact;
Consulted from Recording to Scheduling of Change
Management process; and during developing and
testing, implementing and reviewing CRs;
Informed during Implement;
To assist the Problem Manager (and/or Problem
investigation) in identifying the correct CIs within the
scope of the Problem investigation.
4.2.1.3 Change Process Flow
The Change Management lifecycle is designed to prevent unauthorized Changes being promoted
into the live environment, thereby endangering the service being provided.
pag. 32 of 69
REACH Project: Operations Governance Manual
4.2.1.3.1 Change Management Process Flow
Picture 8 Change Management Process flow
4.2.1.3.2 Change Management Status workflow
Other Process
Level 2 Unit
Groups
Raise CR
Workflow for
Urgent RFC
In Progress
Filtered
Record
Closed
Rejected
Review
Effort Estimation
CAB
Authorization
Approval
Built
Planned
Scheduled
Development
Implemented
Level 3
Support
Pending Test
Final Step
OnGoing Step
Picture 9 Change Management Status workflow
Below the list of the Status
Status
RECORD
Description
Status set when "a need for change" has been identified and RFC is
raised , the request must be recorded basing on the nature and origin of
the request.
pag. 33 of 69
User Group
L2
REACH Project: Operations Governance Manual
Status
IN PROGRESS
FILTERED
EFFORT ESTIMATION
REJECTED
APPROVAL
Description
User Group
This status set when:
- category and impact are determined in order to prioritize the change;
- a complete assessment of risk of the change is determined
Status set when the submitted changes need to be analyzed in order
to accept them and if accepted assign the change for further action.
Status set whenever the RFC has been accepted. Every activities
required is documented and it is available a detailed assessment and
technical proposal for the solution with a complete impact analysis
before proceeding to approval .
Status set when the RFC is rejected
L2
L2/L3
L3
L2
Status set after Effort Estimation and Impact analysis are available
for the approvation in order to initiate the building and testing of the
change.
L2/L3
BUILT
Status set when Changes are approved and ready for being built
L3
PLANNED
Status set when Changes are approved and ready for being tested
L3
SCHEDULED
Status set when Changes are scheduled
L3
DEVELOPMENT
Status set when change can be developed and tested
L3
AUTHORIZATION
Status referring to the activity of GO/No-GO
L2/L3
IMPLEMENTED
REVIEW
CLOSED
PENDING TEST
The implementation of the scheduled change into the production
environment
Status set when review is carried out to confirm that Change
successfully eliminated the known error
Status set when closing Change document and all actions are
completed
Status set whenever a change has to be tested from Service
Validation & Testing Process
L3
L2
L2
L2/L3
Table 8 Change Status list and description
Below the steps list and RACI Matrix.
Process Steps
Responsible
Accountable
Consulted
Informed
Change Hander
Change Manager
Configuration
Manager
CAB/End-user
2.Initial Change
Categorization &
Prioritization
Project Team
Change Manager
Configuration
Manager
CAB
3. Initial Risk assessment
of change
Project Team
Configuration
Manager
CAB
Change Manager
4.1 Filter Impractical
Requests
Project Team
CAB
Change Manager
Configuration
Manager
5.1 Effort Estimation &
Impact Analysis
Project Team
CAB
Change Manager
Configuration
Manager
5.2 RFC Rejected
Project Team
CAB
Change Manager
Configuration
Manager
6. CR Approval
Project Team
CAB
Configuration
Manager
Change Manager
7.1 Build Change
Project Team
CAB
Configuration
Manager
Change Manager
1. Change Recording
pag. 34 of 69
REACH Project: Operations Governance Manual
8. Test Change
Project Team
CAB
Configuration
Manager
Change Manager
9. Schedule Change
Project Team
CAB
Configuration
Manager
Change Manager
10.1 Develop & Test
change
Project Team
Change Manager
Configuration
Manager
CAB
CAB
Change Manager
Project Team
Configuration
Manager
12.1 Implement Change
Project Team
CAB
Configuration
Manager
Change Manager
13. RFC Review
Project Team
Change Manager
Configuration
Manager
CAB
14. RFC Closure
Project Handler
Change Manager
CAB
Configuration
Manager
/
Service Validation
6 Testing Manager
11. Obtain Authorization to
implement
Service Validation &
Testing
Change Manager
Table 9 Change Management steps list and RACI Matrix
4.2.1.3.3 Change Management Process Steps
Process Steps
Step Description
1. Change Recording
The step is concerned with the creation and recording of all Request
for Change (RFCs) basing on the nature and origin of the request .
The step provides details of the activities required to assess the initial
category assignment and potential impact and urgency of the change.
This is then used in order to determine how to prioritize the change.
An Initial Risk assessment is produced in order to establishing the
appropriate level of change authority and relevant areas of interest:
Who raised the Change;
What is the reason for the Change;
What is the return required from this Change;
What are the risks involved in the Change;
What resources are required to deliver the Change;
Who is the responsible for the build, test and
implementation of the Change
Anytime the RFC Analysis is considered as urgent, the flow will follow
a peculiar procedure not in scope.
Impractical Requests are filtered, at this step it can be rejected, if
accepted assign the Change for further action
After RFCs have been accepted, the step executes a complete
analysis of the solution designed in terms of effort requirements,
impact, assessment of risk and business continuity benefits of
implementing it, etc.
At this step RFC could be rejected.
The step documents activities required to obtain approval from all
relevant parties, both internal and business, in order to initiate the
building and testing of the change based upon the completed and
approved Request for Change (RFC).
2.Initial Change Categorization & Prioritization
3. Initial Risk assessment of change
4.1 Filter Impractical Requests
5.1 Effort Estimation & Impact Analysis
6. CR Approval
7.1 Build Change
This step documents the activities involved in the build of the change
prior to seeking approval to implement.
8. Test Change
9. Schedule Change
The step defines an official Test list for User Acceptance Test (UAT)
As a result of this step for approved Changes will be planned the
implementation dates and will be decided if a Service Validation and
Testing are needed.
After scheduling Change, if building and testing have been identified
and do not require the involvement of Service validation and testing
process, then Change will be developed and tested.
Once Change has been developed and tested, an authorization to
implement Change will determine the GO/No-GO decision.
At this stage the Change can be implemented into the production
environment.
10.1 Develop & Test change
11. Obtain Authorization to implement
12.1 Implement Change
pag. 35 of 69
REACH Project: Operations Governance Manual
Process Steps
Step Description
13. RFC Review
A Post-implementation review is carried out to confirm that the
Change successfully eliminated the known error. In other words RFC
has been correctly implemented and there is a review post
implemented.
Once the review has been undertaken RFC can be closed.
14. RFC Closure
Table 10 Change Roles and Responsibilities
4.2.2 Release and Deployment Management
4.2.2.1 Process Overview
Release and Deployment Management is responsible for planning, scheduling and controlling the
movement of releases to test, pre-production and production environments. The primary objective is
to organize the timely implementation of infrastructure changes in such a manner as to mitigate risks
to the live production environment and ensure the business value of the delivered release. This
involves synchronizing the functions, visibility and priorities of several IT operations, to upgrade or
update the infrastructure in a satisfactory manner from the business’s point of view .
4.2.2.1.1 Objectives
The main objective of the Release and Deployment Management process is to ensure
there are clear and comprehensive release and deployment plans enabling UNRWA to
align its activities with these plans,
the integrity of constructed release package;
that all release package can be tracked, installed, verified, uninstalled or backed out if
necessary;
the required skills and knowledge is transferred to support team, customers, end users,
suppliers and any other relevant stakeholders;
there is minimal unpredicted impact on the production services, customers and service
operations
4.2.2.1.2 Scope
The scope of Release and Deployment Management includes processes, systems and functions in
order to package, build, test and deploy a release into production and establish the specified service
in the Service Design package before the final handover to service operations.
4.2.2.1.3 Inputs and Outputs
The list below summarizes the inputs of the process;
Authorized Request for Change (RFC)
Service Packages
Service Design Package
Service Acceptance Criteria
Service Management policies and standards
Build Models and plans
Exit and entry criteria for each stage of release and deployment
The list below summarizes the outputs of the process:
Release and Deployment plans
Update RFCs for any required activities
Successful deployment
pag. 36 of 69
REACH Project: Operations Governance Manual
Review of deployment process and input into any Change Post Implementation Review
Organization and management of early life support
Knowledge transfer so End User can use the service and Knowledge articles
Update proposals to processes procedures
Continual Improvement proposals: SLAs, OLAs, UCs
Agreed reporting
Updated Service Catalogue reflecting any new or modified service S
killed and knowledgeable support staff
Service Transition Report
4.2.2.1.4 Process key Concepts
Release: A release is a collection of authorized changes to an IT service, a collection of hardware,
software, documentation, processes or other component required to implement one or more
approved changes to IT services. The contents of each release are managed, tested and deployed
as a single entity.
Release Unit: A ‘release unit’ describes the portion of a service or IT infrastructure that is normally
released together according to the organization’s release policy. The unit may vary, depending on
the type(s) or item(s) of service asset or service component as software and hardware. The general
objective is to decide the most appropriate release-unit level for each service asset or component.
Release Packages: A release package may be a single release unit or a structured set of release
units included the associated user or support documentation that is required. To formulate a
complete Release Package is needed to consider factors as the modularity of the components, the
amount of changes occurring and resource required.
The type of impact that the business wants from the release is a strong driver of how the release will
package changes together for deployment.
A single Release can deliver:
Change to a Single CI
Change to multiple CIs
CI ha modifications
CI is all new
Delta
Full
Package
Package
Release Type
Typical Impact
Implemented deliverables
Major
Minor
Emergency
Provide new functions
Correct Known Problems
Fix urgent unexpected problems
Full or Package
Delta or Package
Delta
Release Policy: A set of rules for deploying releases into the live operational environment, defining
different approaches for releases depending on their urgency and impact that includes:
•
Unique identification, numbering and naming conventions for each release type and
expected frequency;
•
Roles and responsibilities;
•
How the configuration baseline for the release is captured and verified against the actual
release contents;
•
Criteria and authority for acceptance of the release.
Test Policy: This policy defines the approach for testing the release builds into the live operational
environment identifying different approaches depending on urgency and impact.
Deployment Plan: A deployment plan normally consists of the following sections:
pag. 37 of 69
REACH Project: Operations Governance Manual
The scope of the release and a general overview of the capabilities to be deployed
The timing and dependencies for deploying components to various nodes
The risks or issues associated with the release based on a risk assessment
The customer organization, stakeholders, and end user community that will be impacted by the
release
The person or persons who have the authority to approve the release as "ready for production"
The development team members responsible for delivering the release package to the
Deployment Manager, along with contact information
The approach for transitioning the release package to the Deployment Engineer, including
appropriate communications protocols and escalation procedures
The success criteria for this deployment; in other words, how will the Deployment Engineer know
that the release is successful so it can report success
4.2.2.2 Process Roles and Responsibilities
Role
Functional Unit
Apps Escalation
Support Unit
Functional Group
Responsibilities
SCM Apps team
HR Apps team
FIN Apps team
PSM Apps team
•
•
Selecting the content of Release
Designing the content of Release;
•
Dealing with the final physical delivery of
Release
Package
schedule
and
implementation;
DWH Services
•
Completing outcome details on the
appropriate Change Control system/Tool in
an accurate and timely manner;
Integration Services
•
Providing technical and application guidance
and supporting throughout the release
process;
•
Providing feedback on the effectiveness of
the release;
•
Develop blackout plan A rollback might be
needed for a variety of reasons, including
corruption of the production code base,
inoperable components, an unplanned
undesirable effect of the release on other
production systems, an unhappy customer
•
Provide support from deployment to final
acceptance;
Ensure appropriate support documentation is
available;
Assist the Service Desk with providing
support as required and monitor incidents
and problems;
Be involved with Problem Management
during the release and deployment;
Be involved with final transition of the service
into operation;
Provide performance reporting of the service;
Undertake risk assessment of the service
based on performance
Deployment
Support Team
Technical 2nd Level
Support Unit
Corporate Services
•
•
•
•
•
•
Service Manager
pag. 38 of 69
•
Recording metrics for deployment to ensure
within agreed Service Level Agreements
(SLAs).
•
Interfacing with the service provider for
asking the reporting within SLAs;
•
Managing the relationship and the agreement
with third parties;
•
Recruiting and training authorization;
•
Defining and redefining
the organization
REACH Project: Operations Governance Manual
Role
Functional Unit
Functional Group
Responsibilities
staffing and sizing;
Release
&Deployment
Manager
•
Negotiating with service provider for quality
improvement
or
changing
to
the
deal/contract;
•
Ensuring the quality of the services provided;
•
Ensuring the financial aspects of the service
delivery;
•
Chairing the Service Review meeting;
•
Presenting and agreeing the Service Report
•
Monitoring and controlling Operations in
order to detect each change in state affecting
the routine operations.
•
Manage a support team that performs most
of the day-to-day work
•
Assist the Program Manager and the
development team members in planning each
release
•
Ensure that the organization's release
controls are documented and well understood
by development Teams and Program Support
Teams
•
Ensuring changes have been fully tested and
ready for implementation;
•
Ensure
that
the
architecture
and
infrastructure on which the application will be
deployed are robust and stable
•
Ensure that a detailed deployment plan has
been documented along with a backout plan
should anything go wrong during deployment
•
Coordinate with the Marketing Department
and the program to ensure that sanctioned
communications to all stakeholders have
been properly prepared and reviewed
•
Ensure the product has been correctly and
completely integrated across the program
•
Validate that the product has been correctly
packaged before deployment and ensure that
all release controls have been satisfied
•
Work with IT Operations to deploy the
product successfully
•
Release the pre-planned communications
about the product to all stakeholders
•
Conduct a release retrospective with all the
development team members that participated
in the program to improve the release
process and increase program productivity
and product quality
Table 11 Release and Deployment steps and RACI Matrix
4.2.2.3 Release & Deployment Process Flow
4.2.2.3.1 Release and Deployment Management Process Flow
pag. 39 of 69
REACH Project: Operations Governance Manual
Level 2
Level 3
Pending Test
Raise request for Transition
Planning
1. Planning
Building
Preparation
In Progress
2. Preparation
3. Build and
Test Planning
Other Process
4 .Build and
Test
Service Validation
& Testing
No
UAT Ok?
Yes
No
Deployment Ok?
Plan
Implementation
Ok?
Yes
Building
5.1 Plan and
Prepare for
Deployment
No
Yes
Verified
Deploy
7.1 Verify
6.1 Deployment
Closed
8. Review and
Closure
Picture 10 Release and Deployment Process flow
4.2.2.3.2 Release and Deployment Process Status workflow
Raise Request
for Transition
Other Process
Planning
Preparation
Closed
Level 2 Unit
Groups
In Progress
Deploy
Verified
Building
Level 3
Support
Service Validation and
Testing
Pending Test
Final Step
OnGoing Step
Picture 11 Release and Deployment Status workflow
The table below contains the status list and the related description.
Status
Planning
Preparation
Description
Status set when "a need for transition" has been identified and the request
must be analyzed and planned
This status set after the transition was planned it must to be prepared for the
next steps.
pag. 40 of 69
User Group
L2
L2
REACH Project: Operations Governance Manual
Status
Description
User Group
In Progress
Status set when develop:
- Build and Test plans
L2
Building
Status set when develop:
- Build and Test
- Plan and prepare for Deployment
L3
Deploy
Status set during the actual implementation
L2
Verified
Status set after the implementation to verify if every thing went as planned
L2
CLOSED
Status set when review was made and all actions are completed
L2
PENDING TEST
Status set whenever a change has to be tested from Service Validation &
Testing Process
L3
Table 12 Release and Deployment Status list
RACI
Process Step
Responsible
Accountable
Consulted
1. Release Planning
Deployment Team
Release and
Deployment Manager
Service Manager
2. Preparation
Deployment Team
Release and
Deployment Manager
Service Manager
3. Build and test planning
Deployment Team
Release and
Deployment Manager
4. Build and test
Deployment Team
Release and
Deployment Manager
5.1 Plan and prepare for
Deployment
Deployment Team
Release and
Deployment Manager
6.1 Deployment
Deployment Team
Release and
Deployment Manager
7.1 Verify
Deployment team/
Release and
Deployment Manager
pag. 41 of 69
Informed
Service Manager
REACH Project: Operations Governance Manual
RACI
Process Step
8.Review and Closure
Responsible
Accountable
Deployment team
Release and
Deployment Manager
Consulted
Informed
Service Manager
Table 13 Release and Deployment Process steps and RACI Matrix
4.2.2.3.3 Release and Deployment Process Steps
Process Step
1. Release Planning
2. Preparation
3. Build and test planning
4. Build and Test
5.1 Plan and prepare for Deployment
Step Description
During this step will be identified the services, IT
infrastructure, the systems and the environments needed to
support the transition, the transition milestones, the handover
and delivery dates will be defined and document too.
The plans should include:
Scope and content of the release
The risk assessment for the release
Affected stakeholders
Teams responsible for the release
Communication strategy to be used during the
release and deployment process
the acceptance criteria that exist for the release
and when authorization points will verify a pass or
fail
During this step will be:
identified the activities and the tasks to be
performed
defined all staffing resource, budgets, and time
scales needed for transition
identified issues and risks to be managed
defined any lead times needed and associated
contingency plans
At this step the priorities, the requirements and the approach
will be determined and communicate to the stakeholders in
order to produce the deployments appropriately.
At this step the activities that occur here are:
Developing build plans based on the Service
Design Package and defining any environment
requirements.
Scheduling the resources and time required to
setup the environments
Testing the build and compilation procedures
Scheduling the build and compilation activities
Assigning resources, roles and responsibilities for
any key activities
Defining the environments that may be utilized
during this period
During the build and test step will be needed to manage
Build, test and packaging environments
Compilation and packaging tools
Configuration of the releases themselves as
Version Control, documentation templates for
testing and validation, Access rights and security
procedures.
At this stage the focus is to prepare the organization and
people for organizational change and to refine and
deployment plans that have been documented. These plans
should include guidance regarding:
Risk mitigation plans
Disposal and retirement plans
pag. 42 of 69
REACH Project: Operations Governance Manual
Process Step
6. 1 Deployment
7. 1 Verify
8.Review and Closure
Step Description
The logistics for delivery
Knowledge transfer
Mobilizing users to be ready to use the service
Mobilizing the support staff for service readiness
During the actual implementation itself, the activities
performed can be grouped under the following tasks:
Transfer financial assets
Transfer
changes
required
to
business/organization
Deploy processes and materials
Deploy Service Management Capability
Transfer service
Deploy service
Decommissioning and service retirement
Remove redundant assets
Verification should ensure that:
The service/release components are in place by
means of a configuration audit
Documentation has been updated accordingly
Roles and responsibilities have been correctly
assigned
The measurement and reporting systems are
established to measure performance of the service
The review seeks to ensure that all requirements for the
release have been met and to identify and potential
improvements that can be made
Table 14 Release Process Steps and Description
4.3 Service Operation
The scope of Service Operation is to coordinate and carry out the activities and processes required
to deliver and manage services at agreed levels to business users.. In addition, Service Operation is
responsible for ongoing management of the technology that is used to deliver and support services.
4.3.1 Incident Management
4.3.1.1 Process Overview
Incident Management is part of the ITIL v3 Service Operations publication. The Incident is defined as
“any event which is not part of the standard operation of a service and which causes, or may cause
an interruption to, or a reduction in the quality of that service.” .
4.3.1.1.1 Objectives
The primary Objective of Incident Management is to restore normal service operation as quickly as
possible and minimize the adverse impact on business operations. It implies that the best possible
levels of service quality and availability must be maintained within Service Level Agreement (SLAs)
limits.
4.3.1.1.2 Scope
Incident Management only handles events which interrupt or could interrupt services.
This process covers any Incident, external or internal, which impacts directly or indirectly on the
services provided within the agreed Service Level Agreement, as the following ones:
pag. 43 of 69
REACH Project: Operations Governance Manual
Ownership, progress monitoring of all Incidents until a solution, work-around or other area of
responsibility have been found;
Incidents being constantly re-assigned and Incidents being investigated by multiple
Resolver-groups;
Monitoring the effectiveness of the Incident Management activities (e.g. identify areas where
Incidents are continually at risk of SLA breach);
Identifying all Incidents that meet Change Management, Problem Management and of the
associated process;
Providing of Incident handling statistics and quality metrics (e.g. breach Incidents, missassigned Incidents etc.) in line with Service Level Agreement requirements and for
management and Business Users;
A completed customer satisfaction survey.
4.3.1.1.3 Inputs and Outputs
Inputs that are key to the process:
Incidents: When a disruption in service is detected or pre-emanated the Incident details are
received by the Service Desk from the Business Users or service support functions;
Service Requests: Service Requests are requests from Business Users for standardized
access services, information and advice. Service Requests also cover comments and
complaints;
Automatic Monitoring Alerts: covered by the Event Management Process and by the
continuous observation of Configuration Items (CIs) and IT Services
Change Management inputs: "Rejected" or "Cancelled" or "Partial Service Provision"
Change requests.
Problem Management inputs: “logging” and “closure of Known Error and “closure” of a
Problem.
The Incident Management process is concerned with restoration of normal service and as such
creates the following outputs:
Restored Service: the main goal and output of this process is a restored service operating
within Service Level Agreements (SLAs);
Incident Record: it details the Incident attributes and the steps taken for resolution.
Accurate reporting against the information in these records will enable preventative actions
to take place where Configuration Items are regularly disrupted;
Incident Database: tool containing details of an Incident, and which records new/updating
old Incidents documenting Incident lifecycle;
End-User Communication: The Customer is kept informed at all times throughout the life
of an incident, and final closure of the incident is agreed to ensure satisfaction.
4.3.1.1.4 Process Key Concepts
SD Tool and functionalities: to support the management and tracking of the Incident. It helps
capture standard information about Incidents that could be essential for resolving them. Moreover it
underlines an Incident history, the activities performed to resolve them, its categories and diagnostic
scripts.
Incident Database: it provides information to diagnose what went wrong, particularly including
Incident number; date and time of logging; the description of the Incident; the name of the person
recording the Incident; the Incident closure details and the impact of the Incident.
Service Catalogue: catalogue of services in scope pointing out the phase of the transition plan
within with each service will be activated.
4.3.1.2 Process Roles and Responsibilities
Below the table will report the list of roles, the functional groups and their responsibilities.
pag. 44 of 69
REACH Project: Operations Governance Manual
Role
Functional Unit
Functional Group
Responsibilities
End User
Incident Handler
Service Desk Unit
Service Desk Team
L1 Application Support
Group of Technicians
Incident
Lev_2
Handler
Apps Escalation
Support Unit
Technical 2nd Level
Support Unit
SCM Apps team
HR Apps team
FIN Apps team
PSM Apps team
DWH Services
Integration Services
Corporate Services
Incident Manager
Service Manager
pag. 45 of 69
Making the UAT before closing the Incident
Management Process;
Providing support for the Incident diagnosis if
the information about the Incident isn’t
sufficient for the resolution;
SPOC
Ticket Opening and Closure;
Responding and updating to all End-User calls
in a customer-focused and timely manner;
Closing Incidents in accordance with the
engagement requirements;
Categorizing Incidents;
Prioritizing Incidents
Carrying out Investigation & Diagnosis for
technically resolving Incident;
Determining appropriate Group to route
Incidents for resolution;
Providing the Resolution of Incident if the
solution is known
Restoring the service in accordance to the
Service Level Agreement (SLA) and updating
the Incident record in an accurate and timely
manner;
Carrying out Application Resolution
Incident Resolution and Problem Management
Lifecycle;
Change Management Lifecycle;
Documentation and knowledge management
maintenance;
Delivering Training materials and ERP Training
courses to Business End-users;
Trouble Prevention;
Executing horizontal and vertical Ticket
Escalation to Level 3.
Business Process Support.
Undertaking the management of Incidents,
ensuring all Incidents are correctly logged,
progressed, updated and authorized;
Reviewing circumstances leading to the
potential End-user dissatisfaction;
Re-Opening Incidents if needed;
Providing statistical information to support the
Service Level Agreement on a required basis;
Identifying improvements to the Incident
Management process;
Resolving conflicts within the Team;
People Mgmt and aligning skills with expertise;
Defining/verifying the suitability of ticket
assignment dynamics based on human
resources skills and their effort.
Supervising the overall Process activities
Interfacing with the service provider for asking
the reporting within SLAs;
Managing the relationship and the agreement
with third parties;
Recruiting and training authorization;
Defining and redefining the organization
staffing and sizing;
Negotiating with service provider for quality
improvement or changing to the deal/contract;
Ensuring the quality of the services provided;
Ensuring the financial aspects of the service
delivery;
Chairing the Service Review meeting;
Presenting and agreeing the Service Report
Monitoring and controlling Operations in order
REACH Project: Operations Governance Manual
Role
Functional Unit
Functional Group
Responsibilities
to detect each change in state affecting the
routine operations.
Table 15 Incident Roles and Responsibilities
4.3.1.3 Incident Process Flow
4.3.1.3.1 Incident Management Process Flow
USERS /
PowerUsers
Raise Incident
End-User
input
Event
Mgmt
Open
Open
1.Log New
Ticket/Update old
Tickets
2. Check and
confirm
Classification
Level
3
Level 2
Level 1
In Progress
Escalated
5. Diagnosis
9. Investigation &
Diagnosis
Incident
Database
Wait_Cust_feedback
Yes
No
Request
Fulfillment
No
Yes
Service
Request ?
Incident?
Cust Feedback
needed?
In Progress
6.1 Check for
feedback
Known
Solution?
No
4. Determine
appropriate
Resolver L1
Feedback
Received?
No
Yes
Yes
3.2. Incident
Rejected
Other Knowledge
neededNo
?
Open
No
No
Yes
Pending PM
Email_received
Problem
Management
Rejected
Yes
Change
needed?
Yes
Pending CR
11.2.1 CM Process
Mgmt
7.1 UpdateTicket
No
3.1 Set Incident
info (Priority,
Category,..)
Yes
Known
Solution ?
No
In Progress
Closed
Solution_provided
Solution_provided
13. Closure
Incident
10.KEDB Updating
8.1 Resolution &
Recovery
8.2 Determine
appropriate Group
and Assign
Resolved
Change
Management
11.1 Provide
Resolution
Picture 12 Incident Management Process Flow
4.3.1.3.2 Incident Management Status workflow and Categorization
Below the Incident Management Status workflow and the ticket type and priority values.
Picture 13 Incident Management status workflow
pag. 46 of 69
REACH Project: Operations Governance Manual
Table 16 Incident Status List
Category
Service Type
Service
REACH Apps
SAP FIN
SAP SCM
Barcoding App
SAP PSM
SAP HR
eTM App
Nakisa App
ePer App
ORIS App
Corporate Apps
Uperform App
Moodle App
Confluence App
Jira App
ARIS App
Integration Apps
WSO2
Applications-Enterprise
DWH Apps
Table 17 Type Ticket
pag. 47 of 69
SAP BI/BO
REACH Project: Operations Governance Manual
PRIORITY MATRIX
Priority ID Impact ID
Urgency ID
1
High
High
2
High
Medium
3
Medium
Medium
4
Medium
Low
Description
The highest priority level is used to identify an Incident with blocking impact for the end users,
when no workaround are applicable to guarantee the service continuity. Incidents with Priority 1
are considered as CRITICAL priority.
Incident with blocking impact is classified with Priority 2 when affect multiple end users or a single
VIP user, but the service continuity can be guarantee by a workaround.
Incident with Priority 3 is not related to standard operation of a service and causes, or may cause, an
interruption to or a reduction in the quality of service. Commonly known as MEDIUM or Normal
priority.
Incident that affects any system or environment that not compromise the performance of any main
service. An incident that affects a single user or any standard service request falls under this
category.
Table 18 Priority Matrix
Below the Incident Management Process Steps with RACI matrix.
RACI
Process Step
Responsible
Accountable
Consulted
1. Log New Ticket and
Update old Tickets
Incident Handler
Incident Manager
Service Manager
2. Check and confirm
Classification
Incident Handler
Incident Manager
Service Manager
3.1 Set Incident Info
(Priority, Category, ...)
Incident Handler
Incident Manager
Service Manager
3.2 Incident Rejected
Incident Handler
Incident Manager
Service Manager
4. Determine appropriate
Resolver L1
Incident Handler
Incident Manager
Service Manager
5. Diagnosis
Incident Handler
Incident Manager
Service Manager
6.1 Check for feedback
Incident Handler
Incident Manager
End User/Service
Manager
7.1 Update Ticket
Incident Handler
Incident Manager
Service Manager
8.1 Resolution and
Recovery
Incident Handler
Incident Manager
Service Manager
8.2 Determine
appropriate Resolver
Group and assign
Incident Handler
Incident Manager
Service Manager
10. KEDB Updating
Incident Handler
Incident Manager
Service Manager
13. Incident Closure
Incident Handler
Incident Manager
Service Manager
9. Investigation &
Diagnosis
Incident Handler Lev_2
Incident Manager
Service Manager
11.1 Provide Resolution
Incident Handler Lev_2
Incident Manager
Service Manager
Problem Management
Incident Handler Lev_2
Incident Manager
Service Manager
11.2.1 CM Process Mgmt Incident Handler Lev_2
Incident Manager
Change Management
Incident Manager
/
pag. 48 of 69
Informed
End User
End User
End User
Problem Manager
Change Manager
REACH Project: Operations Governance Manual
Table 19 Incident Process Steps and RACI Matrix
4.3.1.3.3 Incident Management Process Steps
Process Step
Step Description
1. Log New Ticket and Update old Tickets
Tickets are created and recorded in an Incident Database.
Incidents logged will include all information needed to
manage it, be updated and maintained throughout the
lifecycle of Incident.
Once opened, Ticket will be checked in order to understand if
it is related to an Incident, a Non-Incident or a Request. If it is
a Request it is then sent to Request Fulfillment Process and
goes out from Incident Management process.
After Ticket is classified as Incident, information about priority
and category is collected and then sent to the next step for
determining the correct group to analyze and resolve the
Incident.
Ticket cancelled or without chance to be reopened is directly
rejected.
Categorizing Ticket to enable a smooth and correct
Horizontal Escalation, routing Ticket to 1st Level of Analysis.
Ticket is diagnosed by the appropriate Resolver group in
order to ensure a high level of first call resolution and
closure.
Whenever needed in diagnosing Ticket, End-user could be
involved because his feedback may be considered crucial for
the Diagnosis.
Ticket could be updated with additional information provided
by End-user feedback.
When no customer feedback is needed and a known solution
is found, Ticket resolution will be implemented in order to
restore normal service operations.
When a known solution has not been found, a Vertical
Escalation of Ticket will be triggered so that a 2nd Level
appropriate Group will diagnose Ticket Incident in order to
resolve it .
When Solution is known, Ticket will be provided with
resolution and recovery, Known Error Database will record
all details of Ticket Incident, when outage happened and
what was done to resolve it.
After KEDB has been updated, Incident has been definitely
closed and no further action can be taken.
Ticket escalated is sent to a 2nd Level appropriate Group who
will carry out an investigation and diagnosis for finally
resolving Ticket Incident.
2nd Level appropriate Group to whom Ticket has been sent
will provide a deeply investigation and diagnosis of Ticket
with the aim of finding out if there is a known solution or not.
2nd Level appropriate Group found that the occurrence of
many Incidents has no known solution so the Group must
find out the underlying cause of one or more Incidents.
When Investigation & Diagnosis establishes a Change which
is needed, Ticket will encompass CM Process Mgmt.
3rd Level of Support triggered when change is required.
2. Check and confirm Classification
3.1 Set Incident Info (Priority, Category, ...)
3.2 Incident Rejected
4. Determine appropriate Resolver L1
5. Diagnosis
6.1 Check for feedback
7.1 Update Ticket
8.1 Resolution and Recovery
8.2 Determine appropriate Resolver Group and assign
10. KEDB Updating
13. Incident Closure
9. Investigation & Diagnosis
11.1 Provide Resolution
Problem Management
11.2.1 CM Process Mgmt
Change Management
Table 20 Incident Management Process steps
pag. 49 of 69
REACH Project: Operations Governance Manual
4.3.2 Problem Management
4.3.2.1 Process Overview
The section’s purpose is to define the process required to reduce the adverse impact of Incidents
and problems that are caused by errors within the IT infrastructure, and to prevent the recurrence of
Incidents related to these errors. Problems are generally defined as unknown causes of several
Incidents: a problem is the result of many Incidents that are related in some manner. Therefore a
problem is identified as a condition that is a result of several Incidents that exhibit common
symptoms.
4.3.2.1.1 Objectives
The objective of Problem Management is:
to minimize both the number and the severity of Incidents and potential Problems to the
business. In other words, to minimize the adverse impact of Incidents and Problems on the
business that are caused by errors within the IT Service, and to prevent the recurrence of
Incidents related to these errors. In order to achieve this goal, Problem Management seeks
to get to the root cause of Incidents and then initiate actions to improve or correct the
situation;
to support Incident Management via inputs from trend analysis of Incidents, identifying
recurring Incidents and responding to major Incidents. Whereas Incident Management is
focused on getting the End User back up and running as soon as possible (resolving that
occurrence of the Incident), Problem Management focuses on identifying and resolving the
underlying root cause of the Incidents.
4.3.2.1.2 Scope
This process covers any Incident, which impacts directly or indirectly on the services provided within
the agreed Service Level Agreement.
Part of the Problem Management process is to ensure that information concerning Problems and
Known Errors discovered during the course of a Problem or Known Error investigation is made
available to the service delivery organization
4.3.2.1.3 Inputs and Outputs
The following defined the primary inputs are:
Incident details from Incident mgmt;
Configuration details from the configuration management DB;
Details about changes made to the affected equipment;
Any defined workaround.
The following defined the primary Outputs are:
Known errors;
Requests for change;
Updated problem record (including a solution/workarounds);
Closed problem records for resolved Problems;
Knowledge base content to use in Incident mgmt;
Management information through reports.
pag. 50 of 69
REACH Project: Operations Governance Manual
4.3.2.1.4 Process key Concepts
Problem/error closure
Once a workaround - has been established, either by logging a temporary workaround/ known error
in the known error database or a permanent solution via a request for change, a problem can be
closed. In the case of a permanent Solution to a Problem, the Problem record is not usually closed
until the Request for Change (RFC) has been implemented. If the RFC is refused the Problem
Record is updated or even closed.
KEDB: Known Error Database providing information about workarounds, which help speed up the
Incident resolution step of the process. The Database stores the Known Error Records containing
details about previously resolved Incidents and providing a detailed workarounds or resolution for
the Incident so that any similar one can be quickly diagnosed or resolved in the future.
Solution
The successful diagnosis of a “root cause” results in changing the Problem to a Known Error and
suggests a workaround. The Problem Handler browsing through these known error
records/workarounds helps in resolving Incidents and in lowering the Incident Resolution time.
4.3.2.2 Process Roles and Responsibilities
Role
Functional Unit
Apps Escalation
Support Unit
Functional Group
Responsibilities
SCM Apps team
HR Apps team
FIN Apps team
PSM Apps team
Problem
Handler
Technical 2nd
Level Support Unit
DWH Services
Integration Services
Corporate Services
Problem
Manager
pag. 51 of 69
Carrying out First Level Root Cause Analysis;
Coordinating the implementation of Problem / Known
Error resolution;
Investigation and Diagnosis recording all information
in the KEDB;
Raising a Known Error;
Developing and documenting Workarounds for
Problems;
Developing the resolution for the assigned functional
area;
Recording up-to-date information regarding Known
Errors;
Developing and documenting permanent resolutions
to Problems / Known Errors;
Making the Problem Manager aware on technical
resolution progress;
Coordinating the implementation of Problem / Known
Error resolutions;
Providing notification of Problem Workarounds or
Known Error solutions for awareness;
Giving support in Problem reviews;
Determining appropriate Group to route Problems for
resolution
Undertaking the management of Incidents, ensuring
all Incidents are correctly logged, progressed,
updated and authorized;
Reviewing circumstances leading to the potential
End-user dissatisfaction;
Re-Opening Incidents if needed;
Providing statistical information to support the
Service Level Agreement on a required basis;
Identifying improvements to the Incident
Management process;
Resolving conflicts within the Team;
People Mgmt and aligning skills with expertise;
Defining/verifying the suitability of ticket assignment
dynamics based on human resources skills and their
effort.
Supervising the overall Process activities
REACH Project: Operations Governance Manual
Role
Functional Unit
Functional Group
Responsibilities
Service
Manager
Table 21 Problem Management Roles and Responsibilities
4.3.2.3 Problem Process Flow
4.3.2.3.1 Problem Management Process Flow
Picture 14 Problem Management Process Flow
pag. 52 of 69
Interfacing with the service provider for asking the
reporting within SLAs;
Managing the relationship and the agreement with
third parties;
Recruiting and training authorization;
Defining and redefining the organization staffing and
sizing;
Negotiating with service provider for quality
improvement or changing to the deal/contract;
Ensuring the quality of the services provided;
Ensuring the financial aspects of the service delivery;
Chairing the Service Review meeting;
Presenting and agreeing the Service Report
Monitoring and controlling Operations in order to
detect each change in state affecting the routine
operations.
REACH Project: Operations Governance Manual
4.3.2.3.2 Problem Management Status workflow and Process Steps
Picture 15 Problem Status workflow
Table 22 Problem Status list
RACI
Process Step
Responsible
Accountable
1. Problem Creation
Problem Handler
Problem
Manager
Service Manager
2. Review/Fill Problem details
Problem Handler
Problem
Manager
Service Manager
3. Determine appropriate L2
Resolver Group
Problem Handler
Problem
Manager
Service Manager
pag. 53 of 69
Consulted
Informed
REACH Project: Operations Governance Manual
RACI
Process Step
Responsible
Accountable
4. Problem Investigation &
Diagnosis
Problem Handler
Problem
Manager
Service Manager
5.1 Workaround Investigation
Problem Handler
Problem
Manager
Service Manager
6.1 Prepare Workaround
Problem Handler
Problem
Manager
Service Manager
5.2.1 Known Error
Identification & Investigation
Problem Handler
Problem
Manager
Service Manager
7.1 Known Error
Classification & Assessment
Problem Handler
Problem
Manager
Service Manager
8. Known Error resolution
Problem Handler
Problem
Manager
Service Manager
6.2 Escalate to 3rd Level
Support
Problem Handler
Problem
Manager
Level 3
Problem
Manager
Service Manager
5.2.2 Provide Workaround
Problem Handler
Problem
Manager
Service Manager
10. KEDB Updating
Problem Handler
Problem
Manager
Service Manager
11. Problem Closure
Problem Handler
Problem
Manager
Service Manager
9. Provide Solution
Consulted
Informed
Service
Manager, L3
Incident
Manager
Table 23 Problem Process Steps and RACI Matrix
4.3.2.3.3 Problem Management Process Steps
Process Step
Step description
1. Problem Creation
Problems are created and recorded after Incident
Management Process or Service Desk team raised an issue.
The Problem will be reviewed in order to get all information
needed to manage it.
Categorizing Problem to enable a smooth and correct
Horizontal Escalation, routing Problem to an appropriate L2
Resolver Group.
Problem is investigated and diagnosed by assigned Resolver
Group; each wrong group to which Problem is assigned
entails a necessary come back to the step 3.
When after investigating and diagnosing Problem it comes
out that no workaround exists it must be created.
After a Workaround is identified, the solution of the Problem
must be prepared to be subsequently implemented.
Resolution of the Problem needs of carrying out a RC
Analysis. That analysis will permit to detect the root cause of
the problem before identifying the known Error.
After RC has been identified, as well as the known error, the
nature of error must be fully understood before start focusing
2. Review/Fill Problem details
3. Determine appropriate L2 Resolver Group
4. Problem Investigation & Diagnosis
5.1 Workaround Investigation
6.1 Prepare Workaround
5.2.1 Known Error Identification & Investigation
7.1 Known Error Classification & Assessment
pag. 54 of 69
REACH Project: Operations Governance Manual
Process Step
Step description
on solution.
After known error is classified and assessed, next step is to
find a solution that finally fix the issue.
When the RC has not been identified or a workaround or a
solution was not found, Problem needs to be escalated to 3rd
Level of support.
When 3rd Level of Support to which Problem has been
escalated, will provide Solution.
A workaround is identified and prepared so it can be
implemented and the issue will be resolved.
Every time a new workaround or a new solution is identified
the Known Error DB will be updated.
The Problem is closed if the Investigation of the issue is
complete and or a fix solution or a workaround is provided.
The Problem is closed also when the identified solution is
waited from Change Management Process.
8. Known Error resolution
6.2 Escalate to 3rd Level Support
9. Provide Solution
5.2.2 Provide Workaround
10. KEDB Updating
11. Problem Closure
Table 24 Problem Management Process Step description
pag. 55 of 69
REACH Project: Operations Governance Manual
4.3.3 Request Fulfillment
4.3.3.1 Process Overview
A Service Request is a generic term used for many varying types of demand placed upon IT by
Users. Many of these are actually small changes – low risk, frequently occurring, low cost (e.g a
password reset, a Request to install a software package, Request for information). Such is the
volume and low risk nature of these Requests, that rather than directly congest Incident and Change
Management, they both will be better handled as a part of a separate process i.e. via Service
Request Management as a mechanism for managing these end-to-end.
4.3.3.1.1 Objectives
The Request Fulfilment purpose is to enable Service Requesters, via a single point of contact
(SPOC), to request standard services which should be managed efficiently and effectively, through
authorization of the Request to its completion, giving the best possible service to the End-User. So
the objectives include:
providing a channel for standard services;
providing information on the availability of services;
to source and deliver standard service components;
providing general information about the services available, timescales for fulfilment and the
conditions of the SLA for that service
4.3.3.1.2 Scope
This process covers all types of Service Requests where services are provided by Service Provider
to UNRWA and defined in the Service Request Catalogue, which details a list of Standard Requests
that are available to End-users
This process also covers Request for Information (RFI), in other words Requests which will be
logged in exactly the same way. RFI is where an End-user desires to get information e.g. “how do
I..?” These are typically IT related. As a matter of fact, only requests to which End-users are entitled
will be displayed to them.
4.3.3.1.3 Inputs and Outputs
The list below summarizes the Inputs of the process:
Service Request Information: Detailed information is required to record the Standard Service
Request. This information will typically includes details of the Request, description, who raised it,
Requester contact details, service category and type of Request, expected delivery time etc.
Authorisation Information: Authorisation Information needed for the Standard Service Request.
Not all requests require authorisation.
Cost Code details: Cost Codes details are need for some Standard Service Requests e.g.
Telephony handset, Remote Access tokens.
User Information: Basic information on the End-user which the Standard Service Request is being
requested for.
The list below summarizes the Outputs of the process:
Delivered Service: The main goal and output from this process is to deliver the services requested
by the Service Requester, as specified in the service catalogue. The service or solution may be
delivered by a range of Resolver groups depending on the Request type.
Examples of such services are:
•
New password;
pag. 56 of 69
REACH Project: Operations Governance Manual
•
New or replaced hardware or software;
•
New telephone handset;
•
New service component or element of service is deployed.
The process will also provide a check that the service delivered meets the Service Requesters
requirements.
Rejected Request: Standard or Non-Standard Service Request that is not approved will be rejected.
The process will provide information about the rejection to the Service Requester. This may be for
business or financial reasons.
4.3.3.1.4 Process key Concepts
Service Request Catalogue: The Service Request Catalogue is a list of pre-agreed IT Services
with corresponding Standard Service Requests. These are available for the End user (Service
Requester) to select from a Service Request portal.
New services or requests for additions or Changes to the Service Request Catalogue shall be
managed using Change Management process. Changes will be subject to business, technical and
commercial impact assessment.
Standard Service Request: A Standard Service Request can be for information, or advice, or for
Access to an IT Service. For example to reset a password, or to provide standard IT Services for a
new User. Standard Service Requests are usually handled by a Service Desk, and do not require an
RFC to be submitted
Non-Standard Service Request: A Non-Standard Service Request are handled by 2nd/3rd Level of
Support.
4.3.3.2 Process roles and responsibilities
The roles within this process are listed below.
Role
Functional
Unit
Functional Group
Service Requester
Service Desk Team
Request Handler
Request
Manager
Service Desk
Unit
L1 Application Support
Group of Technicians
Responsibilities
He is the End-user submitting service request from the
Service Request Catalogue, in charge of:
Raising and Submission of the Service
Request;
Provision of the information required for the
Service Request, including authorization and
any related order information.
Role played by 1st Level of Support, in charge of:
Logging and managing service requests;
Tracking the request;
Ensuring that each Service Request is
accurately logged and that all the requisite
information is included;
Making sure that each Service Request is
accurately logged when Service Requester
raise the Request;
Ensuring that the Request is complete,
accurate and includes all the required
information and approvals;
Making sure Standard Service Requests are
executed on time.
He is in charge of providing a level of service
commensurate with SLAs, as well as:
Validating Categorization and Prioritization of
request;
Validating the review of request;
Validating the appropriate group for the
review and rejection of request;
Approving request fulfillment;
Approving service request closure.
pag. 57 of 69
REACH Project: Operations Governance Manual
Table 25 Request Fulfillment Roles and responsibilities
4.3.3.3 Request Fulfillment Process flow
Request fulfilment or Service Request Process
4.3.3.3.1 Request Fulfillment Process Flow
Picture 16 Request Fulfillment Process flow
4.3.3.3.2 Service Request Management Status workflow and Process Steps
Raise Request
End User
Open
Rejected
Closed
Level 1
In Progress
Other Unit
Groups
Escalated
Final Step
Picture 17 Request Fulfillment status workflow
pag. 58 of 69
On Going Step
REACH Project: Operations Governance Manual
Table 26 Request Fulfillment Status list
RACI
Process Step
Responsible
Accountable
Consulted
Informed
1. Request logging
Request Handler
Request
Manager
Request Manager
Service Requester
2.1 Categorization &
Prioritization
Request Handler
Request
Manager
Request Manager
Service Requester
3.1 Request Review
Request Handler
Request
Manager
Service
Requester
/
3.2 Determine appropriate
group to review the
Request
Request Handler
Request
Manager
Request Manager
Service Requester
5. Non- Standard Request
Review
Request Handler
Request
Manager
Service
Requester
/
4.1 Request Rejection
Request Handler
Request
Manager
Request Manager
Service Requester
4.2 Fulfill Service Request
Request Handler
Request
Manager
Request Manager
Request Manager
6. Close Service Request
Procedure
Request Handler
Request
Manager
Request Manager
Service Requester
Table 27 Request Fulfillment Process Steps and RACI Matrix
4.3.3.3.3 Request Fulfillment Process steps
Process Step
Step Description
1. Request Logging
For the successfully log of the request like complaints or
requests for a documentation, all necessary information and
requirements must be described by SPOC (Point of Contact
with the End-User). Service Requests concern every generic
description for many varying types of low-risk demand which
pag. 59 of 69
REACH Project: Operations Governance Manual
Process Step
Step Description
do not represent a disruption to agreed Service.
Service Requests Service request will be stored in the
Service Request Catalogue (SRC) in which services are
predefined so that End-users can efficiently select the most
appropriate in order to receive assistance (password reset,
equipment addition, replacements).
When after categorizing and prioritizing, the Request is
considered as standard, it will then be reviewed before being
approved and authorized.
When after categorizing and prioritizing, the request is
considered as non-standard, an appropriate group will be
assigned to carry out escalation for a review of that nonstandard request.
Once Escalated, non-standard request will be deeply
reviewed before being sent again to Level 1 for approval.
Review of a standard or non-standard request is normally
required for approval. When Service request does not reach
the approval, it will be directly rejected.
Service Requests which have been approved, will be
completed for closing the service request procedure.
Service Request has been fulfilled. Procedure will be closed.
2.1 Categorization & Prioritization
3.1 Request Review
3.2 Determine appropriate group to review the request
5.Non-standard Request Review
4.1 Request rejection
4.2 Fulfill Service Request
6. Close Service Request Procedure
Table 28 Request Fulfillment Process step description
4.3.4 Access Management
4.3.4.1 Process Overview
The section purpose is to define the process required for allowing users to make use of IT Services
by granting them the right to use a service while at the same time preventing access to nonauthorized users.
4.3.4.1.1 Objective
The objective is to provide rights for End-Users to be able to access a service or group of services
while preventing access to non-authorized users.
4.3.4.1.2 Scope
This process covers the execution of both availability and information security management,
enabling UNRWA to manage confidentiality, availability and integrity of data and intellectual
property.
Access Management Process ensures that End-users are given the right to use a service, but it is
not ensured that this access is available at all agreed times.
4.3.4.1.3 Inputs/Outputs
The list below summarizes the Inputs of the process:
Security policies and guidelines: document defining how a company plans to protect the
company’s physical and information technology (IT) assets. It is often considered to be a “living
document”, meaning that the document is continuously updated as technology and employee
requirements change. A company’s security policy may include an acceptable use policy, a
description of how the company plans to educate its employees about protecting the company’s
assets, an explanation of how security measurements will be carried out and enforced, and a
procedure for evaluating the effectiveness of the security policy to ensure that necessary corrections
will be made. Security policy also defines the rights that should be available to an individual.
pag. 60 of 69
REACH Project: Operations Governance Manual
The list below summarizes the Outputs of the process:
Updated security access: when an End-user changes roles or Identity Status (retirement,
disciplinary actions, dismissals);
Security reports: provide access records to assist corporate investigations into user activity.
4.3.4.1.4 Process key Concepts
Access: it refers to the level and extent of a service’s functionality or data that a user is entitled to
use;
Identity: it refers to the information about End-user distinguishing them as individual and which
verifies their status within the organization. By definition, the identity of an End-user is unique to that
user.
Rights: it refers to the actual setting whereby a user is provided access to a service. As example,
typical rights/levels of access include read, write, execute, change, delete.
4.3.4.2
Role
Process roles and responsibilities
Functional
Unit
Functional Group
Responsibilities
End User
Service Desk Team
Access
Handler
Service Desk
Unit
L1 Application Support Group
of Technicians
Access
Manager
Service
Manager
End-User will request the access to a service.
Role played by 1st Level of Support, in charge of:
•
Logging the Request;
•
Review End-user access requests;
•
Verifying the End-user’s rights to access;
•
Adding, modifying or changing access and
entitlements;
•
Monitoring Users access requests
•
Managing the Access for End-users;
•
Managing the Identity of End-Users;
•
Providing executive Policy compliance;
•
Interfacing with CAB in assessing and managing of
the process improvement cycle;
In charge of the overall design, implementation and
management of access operations, in particular:
•
Approving or denying the feasibility of access;
•
Approving, adding, modifying or changing access
and entitlements;
•
Ensuring that Access Management records are
recorded and managed according to the agreed
procedures
•
Interfacing with the service provider for asking the
reporting within SLAs;
•
Managing the relationship and the agreement with
third parties;
•
Recruiting and training authorization;
•
Defining and redefining the organization staffing and
sizing
Table 29 Access Process roles and responsibilities
pag. 61 of 69
REACH Project: Operations Governance Manual
4.3.4.3 Access Process Flow
4.3.4.3.1 Access Management Process Flow
Level 1
USERS
End User
Request
Level 2 / Level 3
Open
In Progress
Rejected
1.Request
Logging
2.Verify rights
of Access
2.2 Request
Rejected
No
Yes
Rights
Grant?
No
Feasible?
In Progress
2.1 Verify
Request of
Access
Yes
In Progress
Yes
4. Continuous
Tracking and
Monitoring
Yes
Provide
rights and
Identity?
Standard
?
Configuration
Management
No
In Progress
Escalated
2.1.1 Initial Check
of rights & Identity
compliance
2.1.2 Feasibility
Analysis
Change
Management
Request
Fulfillment
No
In Progress
Closed
3. Review
Executive Policy
Compliance
5.Secure
Identity &
Access
Picture 18 Access Management Process Flow
4.3.4.3.2 Access Management Status workflow
Raise Request
End User
Closed
Open
In Progress
Level1
Rejected
Level 2 Unit
Groups
Escalated
Level 3
Support
Final Step
Picture 19 Access Management status workflow
pag. 62 of 69
On Going Step
REACH Project: Operations Governance Manual
Table 30 Access Management status list
RACI
Process Step
Responsible
Accountable
Consulted
Informed
1. Request Logging
Access Handler
Access Manager
Service Manager
End-User
2. Verify Rights of Access
Access Handler
Access Manager
Service Manager
/
2.1 Verify Request of
access
Access Handler
Access Manager
Service Manager
/
2.2 Request Rejected
Access Handler
Access Manager
Service Manager
End-User
2.1.1 Initial Check of
Rights & Identity
compliance
Access Handler
Access Manager
Service Manager
End-User
2.1.2 Feasibility Analysis
Access Handler
Access Manager
Service Manager
3. Review Executive
Policy Compliance
Access Handler
Access Manager
Service Manager
4. Continuous Tracking
& Monitoring
Access Handler
Access Manager
Service Manager
/
5. Secure Identity and
Access
Access Handler
Access Manager
Service Manager
End-User
Table 31 Access Management Process steps and RACI Matrix
4.3.4.3.3 Access Management Process steps
Process Step
Step Description
1.Request Logging
The initial step includes formally logging new Access
requests. For the successfully log of requests, all necessary
information, requirements will be documented as part of the
Service Catalogue.
The step verifies the rights and entitlement of the requestor
and if these have changed. It will be verified if End-user
requesting access has legitimate requirement for that
service.
The step verifies the request of acces itself. Whether the
verification is negative, the request must be rejected.
2. Verify Rights of Access
2.1 Verify Request of Access
pag. 63 of 69
REACH Project: Operations Governance Manual
Process Step
Step Description
When the End-user is provided with a username and
password, that represents a proof that the person is a
legitimate End-user
After verifying rights and request of access, it occurs that
requests modified or faulty will be rejected/removed so the
request is not granted the rights to access
In some cases tighter restrictions could be put in place, as
the time/level of reduction access when:
•
End-user role has changed;
•
No access is required.
When request is standard, a very first check on compliance
to the executive policy will be carried out in order to assign
appropriate rights and identity to End-User.
When request is non-standard, it will need to be escalated for
a deeper analysis before its potential closure.
After a first check of Rights and Identity it comes out that the
request is not compliant to the executive policy, so the
request will be reviewed before providing rights and identity.
Once End-user is provided with both rights and identity, all
information referred to rights grant will continuously be
tracked and monitored.
End-user is entitled to access a certain level of a service
functionality/data.
2.2 Request rejected
2.1.1 Initial Check of Rights & Identity compliance
2.1.2 Feasibility Analysis
3. Review Executive Policy compliance
4. Continuous Tracking & Monitoring
5. Secure Identity & Access
Table 32 Access Management Process step description
4.4 Continual Service Improvement
The purpose, goals and objective of the Continual Service Improvement (CSI) are:
Continually align IT service to changing business needs;
Identify and implement improvements throughout the service lifecycle;
Determine what to measure, why to measure it and define successful outcomes;
Implement processes with clearly defined goals, objectives and measures;
Review service level achievement results
Ensure quality management methods are used
4.4.1 Service Reporting
Reporting Management deals with any kind of Reporting of IT infrastructure and services ensuring
that the contracted service level targets can be monitored, measured and reported within appropriate
timescales.
A well-defined and controlled process leads to the effective handling of these reports.
4.4.1.1 Process Overview
Service Reporting establishes standardized procedures for the handling of IT-related Reporting
requests and to facilitate the processing, scheduling, coordination, documentation and improvement
of all reports on IT services and infrastructure.
4.4.1.1.1 Objectives
The objective of the Service Reporting is to present reports which depict adherence to SLAs in an
actionable approach. The scope of Service Reporting is to ensure the accurate reporting of Services
and service components within Service Provider’s contracted service. The purpose of the Service
Reporting process is to:
pag. 64 of 69
REACH Project: Operations Governance Manual
Develop a Service measurement framework defining what is to be measured e.g. Services,
Service components and Service Management processes;
Develop a reporting framework defining target audiences, report types, calculation basis,
schedules, report access and media;
Manage the development, release and ongoing production of scheduled and On-Demand
reports;
Evaluate the End-User business requirements as identified by Service Level Management
(SLM) and to convert these requirements into meaningful reports;
Provide reports that allow each Business Unit to manage their operation;
Provide a view for both SLA Compliance reporting and Operational Reporting;
Provide reporting of data that is relevant and meaningful in the context of SLAs and
contracts;
Ensure that agreed reporting policies and rules are applied;
Ensure that reports are unambiguous and presented in a style and language that is
understood by the Business.
4.4.1.1.2 Scope
The scope of Service Reporting is to ensure the accurate reporting of Services and service
components within Service Provider’s contracted service
4.4.1.1.3 Inputs and Outputs
The following defined the primary Inputs to the Service Reporting process:
Request for Change (RFC): to implement a new report and supporting measurement and/or
monitoring capability;
Requirement: a defined requirement for scheduled production of a report;
On-Demand request: for a report via the Service Request Management process;
SLAs, Service Catalogue and contract(s) detail the measurements and associated
targets/thresholds that must be reported on;
The Report Catalogue details those reports that have been developed and implemented;
The list below summarizes the possible Outputs of the process:
Deployed Reports - Once the reporting requirements have been agreed and the report
specified, the appropriate reporting is developed. After successful UAT, the report is then
deployed into the live environment for final testing by the Report Requester;
Published scheduled and On-Demand reports;
Reports Catalogue – created and/or updated dependent upon process step;
Training - as part of this process, End users will be trained to use the appropriate reporting
application;
4.4.1.1.4 Process key Concepts
Service Reporting provides UNRWA and Business Users with visibility and control over Service and
process performance. It looks to implement a defined reporting framework to ensure that the
contracted service level targets can be monitored, measured and reported within appropriate
timescales.
pag. 65 of 69
REACH Project: Operations Governance Manual
4.4.1.2 Process roles and responsibilities
The descriptions below are phrased as though there is a single individual responsible for carrying
out the role. In practice some individuals may carry out a number of roles and equally some of the
roles may be carried out by more than one individual.
Role
Report Requester
Reporting Analyst
Report Developer
Responsibilities
Raising the RFC for the report production. This includes
collating the high level business requirements;
Liaising with the Reporting Analyst to ensure that the
business requirements are fully understood and
documented;
Reviewing the specification identifying any changes and
providing sign-off;
Conducting User Acceptance Testing (UAT)
providing sign-off if appropriate;
Testing report(s) once deployed into production
and
The Reporting Analyst is responsible for establishing a detailed
understanding of the requirements and then converting the
requirements into specifications for the planning, design,
development, communication and review of each report.
Moreover:
Providing detailed specifications from which the reports
can be developed;
Collating scheduled report data from various sources;
Production of scheduled report and initial QA;
Publishing of scheduled reports according to the criteria
defined in the Report Catalogue.
Assessing whether some or all of the business
requirements can be fulfilled via existing reports;
Advising the Report Requester (or relevant user
community) if the requested information currently exists
and where it can be obtained. Drafting the Business
Requirements Document and obtaining Report Requestor
agreement;
Drafting detailed specifications which will become the
basis for the proposal to the Business User and obtaining
agreement from the Report Developer and Report
Requester;
Collaborating with Report Developer to identify data and
tools required to facilitate report(s);
Liaising with stakeholders including Change Management
during Approval phase;
Creating and
documentation.
maintaining
associated
end
user
The Report Developer constructs the report from the detailed
specifications. Responsibilities include:
Analyzing and understanding the Draft Specification;
Identifying new reporting requirements arising from a
transition. As part of the transition, the requirements are
gathered by the Reporting Analyst in conjunction with the
Report Requester (typically working on behalf of the
client).
Working with the Reporting Analyst to create detailed
Specification;
Supporting the Reporting Analyst in gaining approval for
detailed Specification;
Coding, testing and deploying report;
Creating
and
documentation
pag. 66 of 69
maintaining
associated
technical
REACH Project: Operations Governance Manual
Role
Responsibilities
Service Level Manager
The Service Level Manager for the overall end-to-end Service
reporting against Service Levels, as well as for the delivery of the
Service to Report Requester. Specific responsibilities relating are
described below:
Owning the Reporting process including the Report
Catalogue
Investigating data issues with scheduled reports;
Conducting reviews of contractual service level reports
prior to publication;
Contributing to the review of contractual service reports
prior to publication;
Contributing to the review of the overall Service
Measurement & Reporting process and frameworks and
discussing potential changes and improvements with
UNRWA
Contributing to the review of the overall Service
Reporting process and frameworks in relation to the
existing and possible changes/improvements to the
measurement capability
Table 33 Reporting Roles and responsibilities
4.4.1.3 Service Reporting flow
4.4.1.3.1 Service Reporting Process flow
Picture 20 Service Reporting process flow
pag. 67 of 69
REACH Project: Operations Governance Manual
4.4.1.3.2 Reporting Management Status workflow and Process Steps
Picture 21 Reporting Status workflow
Table 34 Reporting Status list
RACI
Process Step
Responsible
Accountable
1. Request Report
Analysis
Reporting Analyst
Service Level
Manager
2.1 Rejected
Report Analyst
Service Level
Manager
2.2 Report Plan
Reporting Analyst
Service Level
Manager
pag. 68 of 69
Consulted
Informed
Report
Requester
Report Requester
Report
Developer
Report Requester
REACH Project: Operations Governance Manual
RACI
Process Step
Responsible
3. Report Design
4.1 Report Development
Reporting Analyst
Accountable
Consulted
Informed
Service Level
Manager
Report
Developer
Report Developer
Service Level
Manager
Report Developer
Reporting
Analyst
Report Requester
4.2 Redefined
Report Developer
Service Level
Manager
Reporting
Analyst
Report Requester
5.Report Communication
Report Developer
Service Level
Manager
Reporting
Analyst
Report Requester
Reporting
Analyst
/
6. Report Review
Report Developer
Service Level
Manager
6.1 Sheduled Report
Production
Report Developer
Service Level
Manager
Reporting
Analyst
/
6.2 on-Demand Report
Production
Report Developer
Service Level
Manager
Reporting
Analyst
/
7. Report Closure
Report Requester
Service Level
Manager
Reporting
Analyst
Report Requester
8. Report publishing
Report Requester
Service Level
Manager
Reporting
Analyst
Report Requester
Table 35 Service Reporting step and RACI Matrix
4.4.1.3.3 Service Reporting Process Steps
Process Step
Step description
1.Request Report Analysis
Reporting Management is triggered every time a request for
reporting is received from one of the various processes or
from a requester. The first analysis consists in verifying
whether the report exists and if it is the case that request can
be approved or dismissed.
When a new report or a change an old report has not been
accepted it will be rejected.
In this step the report is planned, goals and objectives are
defined, scope is determined, the report type is identified.
Moreover the identified requirements are extracted and
categorized and documented, and it will be addressed in the
report.
Once the report is planned, it is then designed: is it needful to
specify measures, metrics, data sources, audience and
review related schedule,
At this step the structure of the report is finalized
At this step the report not approved has to be redefined
At this step communication methods and target audience
(access level) will be established.
All Report fields should be checked and approved.
The report will be scheduled as in the Request.
The report will be generated on demand.
The generated report is formally closed.
The report is made available for the target audience.
2.1 Rejected
2.2 Report Plan
3. Report Design
4.1 Report Development
4.2 Redefined
5.Report Communication
6. Report Review
6.1 Scheduled Report Production
6.2 on-Demand Report Production
7. Report Closure
8. Report publishing
Table 36 Service Reporting process steps and description
pag. 69 of 69
