Reach Ops Governance Manual



Annex 593853046164519050635Reach Ops Governance ManualUNRWA - REACH Ops GovernanceREACH Service OperationCapgemini Italia S.p.A.2/6/2015Document IdentificationAuthorDocument Location (repository/path/name)CapgeminiVersionStatusDateReferenceV2.0Draft06/Feb/2015Stable PhaseRevision HistoryApplies to Rev.DateAuthorChange Description-CapgeminiDRAFTV08/Aug/2014CapgeminiOperations Governance Manual related to the processes, rules and organization set for the Interim Phase.V1.030/Sept/2014CapgeminiOperations Governance Manual related to the processes, rules and organization set for the Hypercare Phase focused on the Incident and Problem Management.V2.006/Feb/2015CapgeminiOperations Governance Manual related to the processes, rules and organization set for the Stable Phase focused on ITIL overall processes in scope.References/Direct SourcesDateAuthorReference27th May 2014ERP transition Board - MoMKick off Meeting UNRWA 270514 ERP Operation Readiness MoM v1 4.doc15th July 2014ERP transition Board - MoMService Catalogue and Functional Organization UNRWA - Meeting 150714 ERP Operation Readiness MoM Final. doc1st September 2014ERP transition Board - MoMFunctional Organization Sizing RulesUNRWA -Meeting 01092014 ERP Operation Readiness MoM -v1.0.doc15th December 2014CGIREACH Ops Functional Group ToRs11th August 2014ICTOSDE Technical Documentation v1.7.doc29th January 2015ERP transition Board - MoReach Ops Organization – Staff reviewUNRWA - Ops Staffing Review Meeting 29Jan2015 - MoM v1.0 draft TOC \o "1-4" \h \z \u Reach Ops Governance Manual PAGEREF _Toc411265787 \h 11Introduction PAGEREF _Toc411265788 \h 71.1REACH Project overview PAGEREF _Toc411265789 \h 71.1.1Purpose of this document PAGEREF _Toc411265790 \h 71.1.2Scope and target audience PAGEREF _Toc411265791 \h 72REACH Service Operation overview PAGEREF _Toc411265792 \h 82.1Service scope and description PAGEREF _Toc411265793 \h 92.2Services activated during Interim Help phase PAGEREF _Toc411265794 \h 112.2.1Point of Contact, Classification and Escalation Points PAGEREF _Toc411265795 \h 122.3Services activated during HyperCare phase PAGEREF _Toc411265796 \h 132.3.1Service Desk TO BE model strategy modifications PAGEREF _Toc411265797 \h 132.3.2Point of Contact, Classification and Escalation Points PAGEREF _Toc411265798 \h 142.3.2.1Incident categorization and Escalation Matrix PAGEREF _Toc411265799 \h 152.3.2.2Service Request categorization and Escalation Matrix PAGEREF _Toc411265800 \h 162.4Services activated during STABLE phase PAGEREF _Toc411265801 \h 173REACH Service Operation Governance (to be advised at later date) PAGEREF _Toc411265802 \h 173.1Service delivery approach PAGEREF _Toc411265803 \h 173.2REACH Service Functional organization PAGEREF _Toc411265804 \h 183.3Service Delivery Organization (to be advised at later date) PAGEREF _Toc411265805 \h 193.3.1Roles and responsibilities PAGEREF _Toc411265806 \h 193.3.2Meetings and Communication mechanisms PAGEREF _Toc411265807 \h 204Process and Service definition PAGEREF _Toc411265808 \h 224.1Service Design PAGEREF _Toc411265809 \h 224.1.1Service Level Management PAGEREF _Toc411265810 \h 224.1.1.1Process Overview PAGEREF _Toc411265811 \h 224.1.1.2Process Roles and Responsibilities PAGEREF _Toc411265812 \h 234.1.1.3Service Level Process Flow PAGEREF _Toc411265813 \h 244.2Service Transition PAGEREF _Toc411265814 \h 294.2.1Change Management PAGEREF _Toc411265815 \h 294.2.1.1Process Overview PAGEREF _Toc411265816 \h 294.2.1.2Process Roles and Responsibilities PAGEREF _Toc411265817 \h 314.2.1.3Change Process Flow PAGEREF _Toc411265818 \h 324.2.2Release and Deployment Management PAGEREF _Toc411265819 \h 364.2.2.1Process Overview PAGEREF _Toc411265820 \h 364.2.2.2Process Roles and Responsibilities PAGEREF _Toc411265821 \h 384.2.2.3Release & Deployment Process Flow PAGEREF _Toc411265822 \h 394.3Service Operation PAGEREF _Toc411265823 \h 434.3.1Incident Management PAGEREF _Toc411265824 \h 434.3.1.1Process Overview PAGEREF _Toc411265825 \h 434.3.1.2Process Roles and Responsibilities PAGEREF _Toc411265826 \h 444.3.1.3Incident Process Flow PAGEREF _Toc411265827 \h 464.3.2Problem Management PAGEREF _Toc411265828 \h 504.3.2.1Process Overview PAGEREF _Toc411265829 \h 504.3.2.2Process Roles and Responsibilities PAGEREF _Toc411265830 \h 514.3.2.3Problem Process Flow PAGEREF _Toc411265831 \h 524.3.3Request Fulfillment PAGEREF _Toc411265832 \h 564.3.3.1Process Overview PAGEREF _Toc411265833 \h 564.3.3.2Process roles and responsibilities PAGEREF _Toc411265834 \h 574.3.3.3Request Fulfillment Process flow PAGEREF _Toc411265835 \h 584.3.4Access Management PAGEREF _Toc411265836 \h 604.3.4.1Process Overview PAGEREF _Toc411265837 \h 604.3.4.2Process roles and responsibilities PAGEREF _Toc411265838 \h 614.3.4.3Access Process Flow PAGEREF _Toc411265839 \h 624.4Continual Service Improvement PAGEREF _Toc411265840 \h 644.4.1Service Reporting PAGEREF _Toc411265841 \h 644.4.1.1Process Overview PAGEREF _Toc411265842 \h 644.4.1.2Process roles and responsibilities PAGEREF _Toc411265843 \h 664.4.1.3Service Reporting flow PAGEREF _Toc411265844 \h 67List of Pictures TOC \h \z \c "Picture" Picture 1 Operations Support Model introduction - approach PAGEREF _Toc411265845 \h 8Picture 2 ITIL Processes in scope PAGEREF _Toc411265846 \h 10Picture 3 Service Catalogue PAGEREF _Toc411265847 \h 11Picture 4 Service delivery model PAGEREF _Toc411265848 \h 18Picture 5 Service Organization PAGEREF _Toc411265849 \h 19Picture 6 Hierarchical Escalation Levels PAGEREF _Toc411265850 \h 21Picture 7 Sla Management Process Flow PAGEREF _Toc411265851 \h 24Picture 8 Change Management Process flow PAGEREF _Toc411265852 \h 33Picture 9 Change Management Status workflow PAGEREF _Toc411265853 \h 33Picture 10 Release and Deployment Process flow PAGEREF _Toc411265854 \h 40Picture 11 Release and Deployment Status workflow PAGEREF _Toc411265855 \h 40Picture 12 Incident Management Process Flow PAGEREF _Toc411265856 \h 46Picture 13 Incident Management status workflow PAGEREF _Toc411265857 \h 46Picture 14 Problem Management Process Flow PAGEREF _Toc411265858 \h 52Picture 15 Problem Status workflow PAGEREF _Toc411265859 \h 53Picture 16 Request Fulfillment Process flow PAGEREF _Toc411265860 \h 58Picture 17 Request Fulfillment status workflow PAGEREF _Toc411265861 \h 58Picture 18 Access Management Process Flow PAGEREF _Toc411265862 \h 62Picture 19 Access Management status workflow PAGEREF _Toc411265863 \h 62Picture 20 Service Reporting process flow PAGEREF _Toc411265864 \h 67Picture 21 Reporting Status workflow PAGEREF _Toc411265865 \h 68List of Tables TOC \h \z \c "Table" Table 1 Service Level Management Roles and Responsibilities PAGEREF _Toc411265866 \h 24Table 2 Service Level Process steps and RACI Matrix PAGEREF _Toc411265867 \h 25Table 3 Incident and Problem Management SLA PAGEREF _Toc411265868 \h 26Table 4 Problem Management SLA PAGEREF _Toc411265869 \h 27Table 5 Quality of the work PAGEREF _Toc411265870 \h 27Table 6 Response time PAGEREF _Toc411265871 \h 28Table 7 Service Level Steps and Description PAGEREF _Toc411265872 \h 29Table 8 Change Status list and description PAGEREF _Toc411265873 \h 34Table 9 Change Management steps list and RACI Matrix PAGEREF _Toc411265874 \h 35Table 10 Change Roles and Responsibilities PAGEREF _Toc411265875 \h 36Table 11 Release and Deployment steps and RACI Matrix PAGEREF _Toc411265876 \h 39Table 12 Release and Deployment Status list PAGEREF _Toc411265877 \h 41Table 13 Release and Deployment Process steps and RACI Matrix PAGEREF _Toc411265878 \h 42Table 14 Release Process Steps and Description PAGEREF _Toc411265879 \h 43Table 15 Incident Roles and Responsibilities PAGEREF _Toc411265880 \h 46Table 16 Incident Status List PAGEREF _Toc411265881 \h 47Table 17 Type Ticket PAGEREF _Toc411265882 \h 47Table 18 Priority Matrix PAGEREF _Toc411265883 \h 48Table 19 Incident Process Steps and RACI Matrix PAGEREF _Toc411265884 \h 49Table 20 Incident Management Process steps PAGEREF _Toc411265885 \h 49Table 21 Problem Management Roles and Responsibilities PAGEREF _Toc411265886 \h 52Table 22 Problem Status list PAGEREF _Toc411265887 \h 53Table 23 Problem Process Steps and RACI Matrix PAGEREF _Toc411265888 \h 54Table 24 Problem Management Process Step description PAGEREF _Toc411265889 \h 55Table 25 Request Fulfillment Roles and responsibilities PAGEREF _Toc411265890 \h 58Table 26 Request Fulfillment Status list PAGEREF _Toc411265891 \h 59Table 27 Request Fulfillment Process Steps and RACI Matrix PAGEREF _Toc411265892 \h 59Table 28 Request Fulfillment Process step description PAGEREF _Toc411265893 \h 60Table 29 Access Process roles and responsibilities PAGEREF _Toc411265894 \h 61Table 30 Access Management status list PAGEREF _Toc411265895 \h 63Table 31 Access Management Process steps and RACI Matrix PAGEREF _Toc411265896 \h 63Table 32 Access Management Process step description PAGEREF _Toc411265897 \h 64Table 33 Reporting Roles and responsibilities PAGEREF _Toc411265898 \h 67Table 34 Reporting Status list PAGEREF _Toc411265899 \h 68Table 35 Service Reporting step and RACI Matrix PAGEREF _Toc411265900 \h 69Table 36 Service Reporting process steps and description PAGEREF _Toc411265901 \h 69IntroductionREACH Project overviewUNRWA (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 () 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.Purpose of this documentThe 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.Scope and target audienceThe 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. 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 SEQ Picture \* ARABIC 1 Operations Support Model introduction - approachThe 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; 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).Service scope and descriptionThe 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.Picture SEQ Picture \* ARABIC 2 ITIL Processes in scopeIn 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.PhasesINTERIM HELPHyperCareStableProcessIncident Management (Basic);Service Level management (CORE concepts related to KPI/SLA definition and to set up key governance mechanism);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).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.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 SEQ Picture \* ARABIC 3 Service CatalogueServices activated during Interim Help phaseThe following picture represents the main information of the service that has already been activated during the Interim Help phase.During the Interim Phase, a list of Services has been activated for each Level:LEVELSERVICE1Service Desk – Call Centre for all ServicesSecurity Roles Management2Citrix AccessVPN Access3SAP CGI BasisCitrix ContractsPoint of Contact, Classification and Escalation PointsA 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.ServiceCategoryEscalation pointKind of RequestDocumentationSAP ApplicationSAP ApplicationERP Functional Stream LeadsApplication functionality or data queryDRAFT SAP user password instructionsuPerfom Installation GuideSAP (everything technical)CGI teamProblems, new users, permissions, profilesuPerform and Moodle application issuesFICTO teamLocal PC and NetworkEnterprise TeamInternational MPLSERP training teamAnything else (Problems, new users, permissions, profiles)JIRA ApplicationChris Ham Jeong (ISD team)Technical server issuesJulien (ERP Test Team)JIRA Application issues (App problems, new users, permissions, profiles)Citrix SAPCitrix InfrastructureFICTO teamLocal PC and NetworkDRAFT Citrix Installation InstructionsPENDING Citrix user mgmtCitrix TelecomEnterprise TeamInternational MPLSCitrix (everything else)CGI TeamAnything else (Problems, new users, permissions, profiles)VPN SAPVPN SWERP Building local IT support AnasVPN SW installationUNRWA VPN User ManualVPN software available with ERP building local IT support AnasVPN (everything else)Valencia team (Roberto Santamaria)All other issuesServices activated during HyperCare phaseThis section includes the description of the ticket categorization, the escalation matrix and all the other details needed from HyperCare phase.Service Desk TO BE model strategy modificationsAt 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).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. Point of Contact, Classification and Escalation PointsThe 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.Incident categorization and Escalation MatrixThe following is the escalation matrix, included in the SDExpress tool, and related to the incident management of the REACH-related services category.Service Request categorization and Escalation MatrixThe following is the escalation matrix, included in the SDExpress tool, and related to the Service Request management of the REACH-related services category.Services activated during STABLE phaseThe 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.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. Service delivery approachThe 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 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:Picture SEQ Picture \* ARABIC 4 Service delivery modelREACH Service Functional organizationThe proposed model shows different Units for each level:The key information regarding each Unit belonging to each level are listed in the table below.LEVELUnitKey activities in charge0Embedded Power Users Business Support Functions1Service Desk Unit – It will embrace Service Desk Team and a 1st Level Apps Support TeamOperating 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.2Apps Escalation Support Unit, composed of SAP Groups referring to FIN, SCM, PSM and HR groups;Technical 2nd Level support Unit; RAMCO Support UnitEach Functional Group will offer the 2nd level support for managing/resolving Ticket related to its peculiar stream.3Contractual Outsourcing (ISD Infrastructure, Third Party Technical Contracts, Third Party ERP Apps Contracts)Units belonging to this level are dedicated to application maintenance activities.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. Picture SEQ Picture \* ARABIC 5 Service OrganizationRoles and responsibilities The table below summarizes the key tasks group which will be executed by each role.RoleDuties and ResponsibilitiesService ManagerEnsures 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 servicesSets 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 MemberThe 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 closureTicket 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 mannerCommunicate solutions to End UsersApplication Support Technician TeamThe 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 checkRole assignment;User master record creation;User management on standard rolesApps Escalation Support UnitSAP 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 rulesTechnical 2nd Level Support UnitPerforming 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 levelMeetings 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 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:Picture SEQ Picture \* ARABIC 6 Hierarchical Escalation LevelsGovernance BoardDescriptionFrequencyManagement CommitteeResponsible for setting the overall strategy 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 QuarterlyService Management Committee Responsible for implementing the strategy 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. MonthlyProcess and Service definitionService 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.Service Level ManagementProcess OverviewService 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.ObjectivesThe 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.ScopeService 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. Inputs and OutputsThe 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;CSI Opportunities;Service Exception Reports.Process key ConceptsService 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.Process Roles and ResponsibilitiesThe responsibilities described below are in the context of Service Level Management and are not exhaustive.RoleDuties and ResponsibilitiesService Level ManagerInternally 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 ManagementEstablish a Service Review process; planning, organizing and facilitating recurring meetingsCarries 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 managementAnalyses 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 Service ManagerEnsures 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 servicesSets 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. SLA Reporting ManagerProvides 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 SEQ Table \* ARABIC 1 Service Level Management Roles and ResponsibilitiesService Level Process FlowService Level Management Process flowPicture SEQ Picture \* ARABIC 7 Sla Management Process FlowProcess StepRACIResponsibleAccountableConsultedInformed1. Produce Service CatalogueSLA Reporting ManagerService Level Manager?Service Manager2. Review existing AgreementSLA Reporting ManagerService Level Manager?3. Plan SLA StructureSLA Reporting ManagerService Level Manager??4. Review Viability ReportSLA Reporting ManagerService Level Manager??5. Define Service Level Requirements and Draft SLASLA Reporting ManagerService Level Manager?Service Manager6. Design SLRsSLA Reporting ManagerService Level Manager??7. Design OLA/UC requirementsSLA Reporting ManagerService Level Manager??8. Design Service Meaurement & ReportingSLA Reporting ManagerService Level Manager??9. Negotiate AgreementService Level Manager??Service Manager10. Publish Final SLA and Update Service CatalogueSLA Reporting ManagerService Level Manager?Service Manager11. Monitor PerformanceSLA Reporting ManagerService Level Manager??12. Generate exption reportsSLA Reporting ManagerService Level Manager??13. Conduct Service Review MeetingsService Level Manager??Service ManagerTable SEQ Table \* ARABIC 2 Service Level Process steps and RACI MatrixService Level Management: SLA definitionDuring 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.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: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.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.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. SLAs for Incident and ProblemPriority 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 SEQ Table \* ARABIC 3 Incident and Problem Management SLAMore 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 SEQ Table \* ARABIC 4 Problem Management SLAProposed major KPIsIn 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 Process KPI Definition Unit Quality of the work CROSS Number of tickets – total Number of ticket opened in a timeframe (with status) Num 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 opened for Changes (with status) Num Change Process Number of open Changes Number of open Changes (with status) Num CROSS Reopening of the same ticket Rework rate % CROSS Incidents/problems first time 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 % Table SEQ Table \* ARABIC 5 Quality of the workCategory Process KPI Definition Unit Response Time 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 area Time 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 SEQ Table \* ARABIC 6 Response timeService Level Management Process stepsProcess StepStep description1. Produce Service CatalogueThis 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.2. Review existing AgreementAt this step existing agreement will be analyzed an reviewed3. Plan SLA StructureAt 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 Catalogue4. Review Viability ReportThis 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. 5. Define Service Level Requirements and Draft SLAAt this step for the every Service is defined the required Service Levels and Service Level Targets. SLA Draft is produced.6. Design SLRsAt this step the initial SLRs captured in the "Define Service Level Requirements" are analyzed and discussed among all stakeholders ensuring they meet business requirements7. Design OLA/UC requirementsUsing 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.8. Design Service Meaurement & ReportingWhere 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.9. Negotiate AgreementThis 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.10. Publish Final SLA and Update Service CatalogueOnce all parties have agreed, the SLA is published, a start date determined and the affected operational teams notified. Service Catalogue has to be updated.11. Monitor PerformanceAt this stepMonitor the actual performance against the SLAProduce operational reports daily and aggregate results12. Generate exption reportsAt this StepGenerate exception reports on threatened or missed service levelsDistribute reports to all stakeholders prior to the SLA reviewResolve questions or disagreements prior to the SLA review meeting determined and the affected operational teams notified.13. Conduct Service Review MeetingsPrepare the agenda and send to attendees one week prior to the meetingReview actions and minutes from previous SLA ReviewReview the service achievement in the last periodPreview any issues for the coming periodReview Forward Schedule of Change or Change calendarDocument actions for the Customer and or the provider as appropriate to improve weak areasReview and re-agree different service targets if requiredDocument and distribute the minutesStore minutes on shared portalTable SEQ Table \* ARABIC 7 Service Level Steps and DescriptionService TransitionThe 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.Change Management The Change Management lifecycle is designed to prevent unauthorized Changes being promoted into the live environment, thereby endangering the service being provided.Process OverviewChange 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.ObjectivesThe 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. ScopeThis 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.Inputs and OutputsA 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.Process key ConceptsChange: 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.Process Roles and ResponsibilitiesThe 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.RoleFunctional UnitFunctional GroupResponsibilitiesChange HandlerApps Escalation Support UnitSCM Apps teamCreating and recording RFCs;Closing RFCs;Performing UAT jointly with/on behalf of End-usersHR Apps teamFIN Apps teamPSM Apps teamTechnical 2nd Level Support UnitDWH ServicesIntegration ServicesCorporate ServicesChange ManagerValidating 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 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 PoliciesProviding 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.CABSupporting the authorization of changes and assisting Change Management in the assessment and prioritization of changes.Project TeamExecuting 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.Configuration ManagerThe 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.Change Process FlowThe Change Management lifecycle is designed to prevent unauthorized Changes being promoted into the live environment, thereby endangering the service being provided. Change Management Process FlowPicture SEQ Picture \* ARABIC 8 Change Management Process flowChange Management Status workflowPicture SEQ Picture \* ARABIC 9 Change Management Status workflowBelow the list of the StatusStatus Description User Group RECORDStatus 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.L2IN PROGRESSThis status set when:- category and impact are determined in order to prioritize the change;- a complete assessment of risk of the change is determinedL2FILTEREDStatus set when the submitted changes need to be analyzed in order to accept them and if accepted assign the change for further action. L2/L3EFFORT ESTIMATIONStatus 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 .L3REJECTEDStatus set when the RFC is rejectedL2APPROVALStatus set after Effort Estimation and Impact analysis are available for the approvation in order to initiate the building and testing of the change.L2/L3BUILTStatus set when Changes are approved and ready for being builtL3PLANNEDStatus set when Changes are approved and ready for being testedL3SCHEDULEDStatus set when Changes are scheduledL3DEVELOPMENTStatus set when change can be developed and testedL3AUTHORIZATIONStatus referring to the activity of GO/No-GO L2/L3IMPLEMENTEDThe implementation of the scheduled change into the production environment L3REVIEWStatus set when review is carried out to confirm that Change successfully eliminated the known errorL2CLOSEDStatus set when closing Change document and all actions are completedL2PENDING TESTStatus set whenever a change has to be tested from Service Validation & Testing ProcessL2/L3Table SEQ Table \* ARABIC 8 Change Status list and descriptionBelow the steps list and RACI Matrix.Process StepsResponsibleAccountableConsultedInformed1. Change RecordingChange HanderChange ManagerConfiguration ManagerCAB/End-user2.Initial Change Categorization & PrioritizationProject TeamChange ManagerConfiguration ManagerCAB3. Initial Risk assessment of changeProject TeamConfiguration ManagerCABChange Manager4.1 Filter Impractical RequestsProject TeamCABChange ManagerConfiguration Manager5.1 Effort Estimation & Impact AnalysisProject TeamCABChange ManagerConfiguration Manager5.2 RFC RejectedProject TeamCABChange ManagerConfiguration Manager6. CR ApprovalProject TeamCABConfiguration ManagerChange Manager7.1 Build ChangeProject TeamCABConfiguration ManagerChange Manager8. Test ChangeProject TeamCABConfiguration ManagerChange Manager9. Schedule ChangeProject TeamCABConfiguration ManagerChange Manager10.1 Develop & Test changeProject TeamChange ManagerConfiguration ManagerCAB11. Obtain Authorization to implementCABChange ManagerProject TeamConfiguration Manager12.1 Implement ChangeProject TeamCABConfiguration ManagerChange Manager13. RFC ReviewProject TeamChange ManagerConfiguration ManagerCAB14. RFC ClosureProject HandlerChange ManagerCABConfiguration ManagerService Validation & Testing/Service Validation 6 Testing Manager?Change ManagerTable SEQ Table \* ARABIC 9 Change Management steps list and RACI MatrixChange Management Process StepsProcess StepsStep Description1. Change RecordingThe step is concerned with the creation and recording of all Request for Change (RFCs) basing on the nature and origin of the request.2.Initial Change Categorization & PrioritizationThe 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.3. Initial Risk assessment of changeAn 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 ChangeAnytime the RFC Analysis is considered as urgent, the flow will follow a peculiar procedure not in scope.4.1 Filter Impractical RequestsImpractical Requests are filtered, at this step it can be rejected, if accepted assign the Change for further action5.1 Effort Estimation & Impact AnalysisAfter 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.6. CR ApprovalThe 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).7.1 Build ChangeThis step documents the activities involved in the build of the change prior to seeking approval to implement.8. Test ChangeThe step defines an official Test list for User Acceptance Test (UAT)9. Schedule ChangeAs 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.10.1 Develop & Test changeAfter 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.11. Obtain Authorization to implementOnce Change has been developed and tested, an authorization to implement Change will determine the GO/No-GO decision.12.1 Implement ChangeAt this stage the Change can be implemented into the production environment.13. RFC ReviewA 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.14. RFC ClosureOnce the review has been undertaken RFC can be closed.Table SEQ Table \* ARABIC 10 Change Roles and ResponsibilitiesRelease and Deployment Management Process OverviewRelease 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.ObjectivesThe main objective of the Release and Deployment Management process is to ensurethere 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 operationsScopeThe 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.Inputs and OutputsThe list below summarizes the inputs of the process;Authorized Request for Change (RFC)Service PackagesService Design PackageService Acceptance CriteriaService Management policies and standardsBuild Models and plansExit and entry criteria for each stage of release and deploymentThe list below summarizes the outputs of the process:Release and Deployment plansUpdate RFCs for any required activitiesSuccessful deploymentReview of deployment process and input into any Change Post Implementation ReviewOrganization and management of early life supportKnowledge transfer so End User can use the service and Knowledge articlesUpdate proposals to processes proceduresContinual Improvement proposals: SLAs, OLAs, UCsAgreed reportingUpdated Service Catalogue reflecting any new or modified service Skilled and knowledgeable support staffService Transition ReportProcess key ConceptsRelease: 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 CIChange to multiple CIsCI ha modificationsDeltaPackageCI is all newFullPackageRelease TypeTypical ImpactImplemented deliverablesMajorProvide new functionsFull or PackageMinorCorrect Known ProblemsDelta or PackageEmergencyFix urgent unexpected problemsDeltaRelease 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: 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 Process Roles and Responsibilities RoleFunctional UnitFunctional GroupResponsibilities Deployment Support TeamApps Escalation Support UnitSCM Apps teamSelecting the content of Release Designing the content of Release;Dealing with the final physical delivery of Release Package schedule and implementation; Completing outcome details on the appropriate Change Control system/Tool in an accurate and timely manner;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 customerProvide 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 Recording metrics for deployment to ensure within agreed Service Level Agreements (SLAs).HR Apps teamFIN Apps teamPSM Apps teamTechnical 2nd Level Support UnitDWH ServicesIntegration ServicesCorporate ServicesService ManagerInterfacing 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 ReportMonitoring and controlling Operations in order to detect each change in state affecting the routine operations.Release &Deployment ManagerManage 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 SEQ Table \* ARABIC 11 Release and Deployment steps and RACI MatrixRelease & Deployment Process FlowRelease and Deployment Management Process FlowPicture SEQ Picture \* ARABIC 10 Release and Deployment Process flowRelease and Deployment Process Status workflowPicture SEQ Picture \* ARABIC 11 Release and Deployment Status workflowThe table below contains the status list and the related description.Status Description User Group PlanningStatus set when "a need for transition" has been identified and the request must be analyzed and plannedL2PreparationThis status set after the transition was planned it must to be prepared for the next steps.L2In ProgressStatus set when develop:- Build and Test plansL2BuildingStatus set when develop:- Build and Test- Plan and prepare for DeploymentL3DeployStatus set during the actual implementationL2VerifiedStatus set after the implementation to verify if every thing went as plannedL2CLOSEDStatus set when review was made and all actions are completedL2PENDING TESTStatus set whenever a change has to be tested from Service Validation & Testing ProcessL3Table SEQ Table \* ARABIC 12 Release and Deployment Status listProcess StepRACIResponsibleAccountableConsultedInformed1. Release PlanningDeployment TeamRelease and Deployment ManagerService Manager?2. PreparationDeployment TeamRelease and Deployment ManagerService Manager?3. Build and test planningDeployment TeamRelease and Deployment Manager??4. Build and testDeployment TeamRelease and Deployment Manager??5.1 Plan and prepare for DeploymentDeployment TeamRelease and Deployment Manager?Service Manager6.1 DeploymentDeployment TeamRelease and Deployment Manager??7.1 VerifyDeployment team/Release and Deployment Manager??8.Review and ClosureDeployment teamRelease and Deployment Manager?Service ManagerTable SEQ Table \* ARABIC 13 Release and Deployment Process steps and RACI MatrixRelease and Deployment Process StepsProcess StepStep Description1. Release PlanningDuring 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 releaseThe risk assessment for the releaseAffected stakeholdersTeams responsible for the releaseCommunication strategy to be used during the release and deployment processthe acceptance criteria that exist for the release and when authorization points will verify a pass or fail2. PreparationDuring this step will be:identified the activities and the tasks to be performeddefined all staffing resource, budgets, and time scales needed for transitionidentified issues and risks to be manageddefined any lead times needed and associated contingency plansAt this step the priorities, the requirements and the approach will be determined and communicate to the stakeholders in order to produce the deployments appropriately.3. Build and test planningAt 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 environmentsTesting the build and compilation proceduresScheduling the build and compilation activitiesAssigning resources, roles and responsibilities for any key activitiesDefining the environments that may be utilized during this period4. Build and TestDuring the build and test step will be needed to manageBuild, test and packaging environmentsCompilation and packaging toolsConfiguration of the releases themselves as Version Control, documentation templates for testing and validation, Access rights and security procedures.5.1 Plan and prepare for DeploymentAt 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 plansDisposal and retirement plansThe logistics for deliveryKnowledge transferMobilizing users to be ready to use the serviceMobilizing the support staff for service readiness 6. 1 DeploymentDuring the actual implementation itself, the activities performed can be grouped under the following tasks:Transfer financial assetsTransfer changes required to business/organizationDeploy processes and materialsDeploy Service Management CapabilityTransfer serviceDeploy serviceDecommissioning and service retirementRemove redundant assets7. 1 VerifyVerification should ensure that:The service/release components are in place by means of a configuration auditDocumentation has been updated accordinglyRoles and responsibilities have been correctly assignedThe measurement and reporting systems are established to measure performance of the service8.Review and ClosureThe review seeks to ensure that all requirements for the release have been met and to identify and potential improvements that can be madeTable SEQ Table \* ARABIC 14 Release Process Steps and DescriptionService OperationThe 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.Incident ManagementProcess OverviewIncident 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.” . ObjectivesThe 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.ScopeIncident 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: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, miss-assigned Incidents etc.) in line with Service Level Agreement requirements and for management and Business Users;A completed customer satisfaction survey.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 ServicesChange 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.Process Key ConceptsSD 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.Process Roles and ResponsibilitiesBelow the table will report the list of roles, the functional groups and their responsibilities.RoleFunctional UnitFunctional GroupResponsibilitiesEnd UserMaking 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;Incident HandlerService Desk UnitService Desk TeamSPOCTicket 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 IncidentsCarrying out Investigation & Diagnosis for technically resolving Incident; Determining appropriate Group to route Incidents for resolution; Providing the Resolution of Incident if the solution is knownRestoring the service in accordance to the Service Level Agreement (SLA) and updating the Incident record in an accurate and timely manner;Carrying out Application ResolutionL1 Application Support Group of TechniciansIncident Handler Lev_2Apps Escalation Support UnitSCM Apps teamIncident 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.HR Apps teamFIN Apps teamPSM Apps teamTechnical 2nd Level Support UnitDWH ServicesIntegration ServicesCorporate ServicesIncident ManagerUndertaking 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 activitiesService ManagerInterfacing 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 ReportMonitoring and controlling Operations in order to detect each change in state affecting the routine operations. Table SEQ Table \* ARABIC 15 Incident Roles and ResponsibilitiesIncident Process FlowIncident Management Process FlowPicture SEQ Picture \* ARABIC 12 Incident Management Process FlowIncident Management Status workflow and CategorizationBelow the Incident Management Status workflow and the ticket type and priority values.Picture SEQ Picture \* ARABIC 13 Incident Management status workflowTable SEQ Table \* ARABIC 16 Incident Status ListCategoryService TypeServiceApplications-EnterpriseREACH AppsSAP FINSAP SCMBarcoding AppSAP PSMSAP HReTM AppNakisa AppePer AppORIS AppCorporate AppsUperform AppMoodle AppConfluence AppJira AppARIS AppIntegration AppsWSO2DWH AppsSAP BI/BOTable SEQ Table \* ARABIC 17 Type TicketTable SEQ Table \* ARABIC 18 Priority MatrixBelow the Incident Management Process Steps with RACI matrix.Process StepRACIResponsibleAccountableConsultedInformed1. Log New Ticket and Update old TicketsIncident HandlerIncident ManagerService ManagerEnd User2. Check and confirm ClassificationIncident HandlerIncident ManagerService Manager?3.1 Set Incident Info (Priority, Category, ...)Incident HandlerIncident ManagerService Manager?3.2 Incident RejectedIncident HandlerIncident ManagerService ManagerEnd User4. Determine appropriate Resolver L1Incident HandlerIncident ManagerService Manager?5. DiagnosisIncident HandlerIncident ManagerService Manager?6.1 Check for feedbackIncident HandlerIncident ManagerEnd User/Service Manager?7.1 Update TicketIncident HandlerIncident ManagerService Manager?8.1 Resolution and RecoveryIncident HandlerIncident ManagerService Manager?8.2 Determine appropriate Resolver Group and assignIncident HandlerIncident ManagerService Manager?10. KEDB UpdatingIncident HandlerIncident ManagerService Manager?13. Incident ClosureIncident HandlerIncident ManagerService ManagerEnd User9. Investigation & DiagnosisIncident Handler Lev_2Incident ManagerService Manager?11.1 Provide ResolutionIncident Handler Lev_2Incident ManagerService Manager?Problem ManagementIncident Handler Lev_2Incident ManagerService ManagerProblem Manager11.2.1 CM Process MgmtIncident Handler Lev_2Incident Manager??Change Management/Incident Manager?Change ManagerTable SEQ Table \* ARABIC 19 Incident Process Steps and RACI MatrixIncident Management Process StepsProcess StepStep Description1. Log New Ticket and Update old TicketsTickets 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.2. Check and confirm ClassificationOnce 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.3.1 Set Incident Info (Priority, Category, ...)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.3.2 Incident RejectedTicket cancelled or without chance to be reopened is directly rejected.4. Determine appropriate Resolver L1Categorizing Ticket to enable a smooth and correct Horizontal Escalation, routing Ticket to 1st Level of Analysis.5. DiagnosisTicket is diagnosed by the appropriate Resolver group in order to ensure a high level of first call resolution and closure.6.1 Check for feedbackWhenever needed in diagnosing Ticket, End-user could be involved because his feedback may be considered crucial for the Diagnosis.7.1 Update TicketTicket could be updated with additional information provided by End-user feedback.8.1 Resolution and RecoveryWhen no customer feedback is needed and a known solution is found, Ticket resolution will be implemented in order to restore normal service operations.8.2 Determine appropriate Resolver Group and assignWhen 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 .10. KEDB UpdatingWhen 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.13. Incident ClosureAfter KEDB has been updated, Incident has been definitely closed and no further action can be taken.9. Investigation & DiagnosisTicket escalated is sent to a 2nd Level appropriate Group who will carry out an investigation and diagnosis for finally resolving Ticket Incident.11.1 Provide Resolution2nd 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.Problem Management2nd 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.11.2.1 CM Process MgmtWhen Investigation & Diagnosis establishes a Change which is needed, Ticket will encompass CM Process Mgmt.Change Management3rd Level of Support triggered when change is required.Table SEQ Table \* ARABIC 20 Incident Management Process stepsProblem Management Process OverviewThe 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.ObjectivesThe 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.ScopeThis 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 organizationInputs 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.Process key ConceptsProblem/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.Process Roles and Responsibilities RoleFunctional UnitFunctional GroupResponsibilitiesProblem HandlerApps Escalation Support UnitSCM Apps teamCarrying 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 resolutionHR Apps teamFIN Apps teamPSM Apps teamTechnical 2nd Level Support UnitDWH ServicesIntegration ServicesCorporate ServicesProblem ManagerUndertaking 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 Service ManagerInterfacing 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 ReportMonitoring and controlling Operations in order to detect each change in state affecting the routine operations. Table SEQ Table \* ARABIC 21 Problem Management Roles and ResponsibilitiesProblem Process FlowProblem Management Process Flow Picture SEQ Picture \* ARABIC 14 Problem Management Process FlowProblem Management Status workflow and Process StepsPicture SEQ Picture \* ARABIC 15 Problem Status workflowTable 22 Problem Status listProcess StepRACIResponsibleAccountableConsultedInformed1. Problem CreationProblem HandlerProblem ManagerService Manager?2. Review/Fill Problem detailsProblem HandlerProblem ManagerService Manager?3. Determine appropriate L2 Resolver GroupProblem HandlerProblem ManagerService Manager?4. Problem Investigation & DiagnosisProblem HandlerProblem ManagerService Manager?5.1 Workaround InvestigationProblem HandlerProblem ManagerService Manager?6.1 Prepare WorkaroundProblem HandlerProblem ManagerService Manager?5.2.1 Known Error Identification & Investigation Problem HandlerProblem ManagerService Manager?7.1 Known Error Classification & AssessmentProblem HandlerProblem ManagerService Manager?8. Known Error resolutionProblem HandlerProblem ManagerService Manager?6.2 Escalate to 3rd Level SupportProblem HandlerProblem Manager?Service Manager, L39. Provide Solution Level 3Problem ManagerService Manager?5.2.2 Provide Workaround Problem HandlerProblem ManagerService Manager?10. KEDB UpdatingProblem HandlerProblem ManagerService Manager?11. Problem ClosureProblem HandlerProblem ManagerService ManagerIncident ManagerTable SEQ Table \* ARABIC 23 Problem Process Steps and RACI MatrixProblem Management Process StepsProcess StepStep description1. Problem CreationProblems are created and recorded after Incident Management Process or Service Desk team raised an issue.2. Review/Fill Problem detailsThe Problem will be reviewed in order to get all information needed to manage it. 3. Determine appropriate L2 Resolver GroupCategorizing Problem to enable a smooth and correct Horizontal Escalation, routing Problem to an appropriate L2 Resolver Group.4. Problem Investigation & DiagnosisProblem 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.5.1 Workaround InvestigationWhen after investigating and diagnosing Problem it comes out that no workaround exists it must be created.6.1 Prepare WorkaroundAfter a Workaround is identified, the solution of the Problem must be prepared to be subsequently implemented.5.2.1 Known Error Identification & InvestigationResolution 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.7.1 Known Error Classification & AssessmentAfter RC has been identified, as well as the known error, the nature of error must be fully understood before start focusing on solution.8. Known Error resolutionAfter known error is classified and assessed, next step is to find a solution that finally fix the issue. 6.2 Escalate to 3rd Level SupportWhen 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.9. Provide SolutionWhen 3rd Level of Support to which Problem has been escalated, will provide Solution.5.2.2 Provide WorkaroundA workaround is identified and prepared so it can be implemented and the issue will be resolved.10. KEDB UpdatingEvery time a new workaround or a new solution is identified the Known Error DB will be updated.11. Problem ClosureThe 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.Table SEQ Table \* ARABIC 24 Problem Management Process Step descriptionRequest Fulfillment Process OverviewA 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.ObjectivesThe 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 serviceScopeThis 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-usersThis 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.Inputs and OutputsThe 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;?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. Process key ConceptsService 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.Process roles and responsibilitiesThe roles within this process are listed below.RoleFunctional UnitFunctional GroupResponsibilitiesService RequesterHe 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.Request HandlerService Desk UnitService Desk TeamRole 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.L1 Application Support Group of TechniciansRequest ManagerHe 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.Table SEQ Table \* ARABIC 25 Request Fulfillment Roles and responsibilitiesRequest Fulfillment Process flowRequest fulfilment or Service Request Process Request Fulfillment Process FlowPicture SEQ Picture \* ARABIC 16 Request Fulfillment Process flowService Request Management Status workflow and Process StepsPicture SEQ Picture \* ARABIC 17 Request Fulfillment status workflowTable SEQ Table \* ARABIC 26 Request Fulfillment Status listProcess StepRACIResponsibleAccountableConsultedInformed1. Request loggingRequest HandlerRequest ManagerRequest ManagerService Requester2.1 Categorization & PrioritizationRequest HandlerRequest ManagerRequest ManagerService Requester3.1 Request Review Request HandlerRequest ManagerService Requester/3.2 Determine appropriate group to review the RequestRequest HandlerRequest ManagerRequest ManagerService Requester5. Non- Standard Request ReviewRequest HandlerRequest ManagerService Requester/4.1 Request RejectionRequest HandlerRequest ManagerRequest ManagerService Requester4.2 Fulfill Service RequestRequest HandlerRequest ManagerRequest ManagerRequest Manager6. Close Service Request ProcedureRequest HandlerRequest ManagerRequest ManagerService RequesterTable SEQ Table \* ARABIC 27 Request Fulfillment Process Steps and RACI MatrixRequest Fulfillment Process stepsProcess StepStep Description1. Request LoggingFor 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 do not represent a disruption to agreed Service.2.1 Categorization & PrioritizationService 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).3.1 Request ReviewWhen after categorizing and prioritizing, the Request is considered as standard, it will then be reviewed before being approved and authorized.3.2 Determine appropriate group to review the requestWhen 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 non-standard request.5.Non-standard Request ReviewOnce Escalated, non-standard request will be deeply reviewed before being sent again to Level 1 for approval.4.1 Request rejectionReview 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.4.2 Fulfill Service RequestService Requests which have been approved, will be completed for closing the service request procedure.6. Close Service Request ProcedureService Request has been fulfilled. Procedure will be closed.Table SEQ Table \* ARABIC 28 Request Fulfillment Process step descriptionAccess Management Process OverviewThe 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 non-authorized users.ObjectiveThe 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.ScopeThis 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.Inputs/OutputsThe 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.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.Process key ConceptsAccess: 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. Process roles and responsibilitiesRoleFunctional UnitFunctional GroupResponsibilitiesEnd UserEnd-User will request the access to a service.Access HandlerService Desk UnitService Desk TeamRole 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 requestsManaging 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;L1 Application Support Group of TechniciansAccess ManagerIn 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 proceduresService ManagerInterfacing 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 sizingTable SEQ Table \* ARABIC 29 Access Process roles and responsibilitiesAccess Process FlowAccess Management Process FlowPicture SEQ Picture \* ARABIC 18 Access Management Process FlowAccess Management Status workflowPicture SEQ Picture \* ARABIC 19 Access Management status workflowTable SEQ Table \* ARABIC 30 Access Management status listProcess StepRACIResponsibleAccountableConsultedInformed1. Request Logging Access HandlerAccess ManagerService ManagerEnd-User2. Verify Rights of AccessAccess HandlerAccess ManagerService Manager/2.1 Verify Request of access Access HandlerAccess ManagerService Manager/2.2 Request RejectedAccess HandlerAccess ManagerService ManagerEnd-User2.1.1 Initial Check of Rights & Identity complianceAccess HandlerAccess ManagerService ManagerEnd-User2.1.2 Feasibility AnalysisAccess HandlerAccess ManagerService Manager?3. Review Executive Policy ComplianceAccess HandlerAccess ManagerService Manager?4. Continuous Tracking & MonitoringAccess HandlerAccess ManagerService Manager/5. Secure Identity and AccessAccess HandlerAccess ManagerService ManagerEnd-UserTable SEQ Table \* ARABIC 31 Access Management Process steps and RACI MatrixAccess Management Process stepsProcess StepStep Description1.Request LoggingThe 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.2. Verify Rights of AccessThe 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.2.1 Verify Request of AccessThe step verifies the request of acces itself. Whether the verification is negative, the request must be rejected.When the End-user is provided with a username and password, that represents a proof that the person is a legitimate End-user2.2 Request rejectedAfter 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 accessIn 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.2.1.1 Initial Check of Rights & Identity complianceWhen 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.2.1.2 Feasibility AnalysisWhen request is non-standard, it will need to be escalated for a deeper analysis before its potential closure.3. Review Executive Policy complianceAfter 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.4. Continuous Tracking & MonitoringOnce End-user is provided with both rights and identity, all information referred to rights grant will continuously be tracked and monitored.5. Secure Identity & AccessEnd-user is entitled to access a certain level of a service functionality/data.Table SEQ Table \* ARABIC 32 Access Management Process step descriptionContinual Service ImprovementThe 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 resultsEnsure quality management methods are usedService ReportingReporting 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. Process OverviewService 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.ObjectivesThe 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: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.ScopeThe scope of Service Reporting is to ensure the accurate reporting of Services and service components within Service Provider’s contracted serviceInputs and OutputsThe 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;Process key ConceptsService 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. Process roles and responsibilitiesThe 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. RoleResponsibilitiesReport RequesterRaising 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) and providing sign-off if appropriate;Testing report(s) once deployed into productionReporting AnalystThe 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 maintaining associated end user documentation.Report DeveloperThe 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 maintaining associated technical documentationService Level ManagerThe 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 CatalogueInvestigating 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 UNRWAContributing to the review of the overall Service Reporting process and frameworks in relation to the existing and possible changes/improvements to the measurement capabilityTable SEQ Table \* ARABIC 33 Reporting Roles and responsibilitiesService Reporting flowService Reporting Process flowPicture SEQ Picture \* ARABIC 20 Service Reporting process flowReporting Management Status workflow and Process StepsPicture 21 Reporting Status workflowTable 34 Reporting Status listProcess StepRACIResponsibleAccountableConsultedInformed1. Request Report AnalysisReporting Analyst Service Level ManagerReport Requester?2.1 RejectedReport AnalystService Level ManagerReport Requester2.2 Report PlanReporting AnalystService Level ManagerReport DeveloperReport Requester3. Report DesignReporting AnalystService Level ManagerReport Developer?Report Developer4.1 Report DevelopmentReport DeveloperService Level ManagerReporting AnalystReport Requester4.2 RedefinedReport DeveloperService Level ManagerReporting AnalystReport Requester5.Report CommunicationReport Developer Service Level Manager Reporting Analyst?Report Requester6. Report ReviewReport Developer Service Level Manager Reporting Analyst/6.1 Sheduled Report ProductionReport DeveloperService Level Manager Reporting Analyst/6.2 on-Demand Report ProductionReport DeveloperService Level Manager Reporting Analyst/7. Report ClosureReport Requester Service Level Manager Reporting Analyst?Report Requester 8. Report publishingReport Requester Service Level Manager ?Reporting Analyst?Report Requester Table SEQ Table \* ARABIC 35 Service Reporting step and RACI MatrixService Reporting Process StepsProcess StepStep description1.Request Report AnalysisReporting 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.2.1 RejectedWhen a new report or a change an old report has not been accepted it will be rejected.2.2 Report PlanIn 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.3. Report DesignOnce the report is planned, it is then designed: is it needful to specify measures, metrics, data sources, audience and review related schedule, 4.1 Report DevelopmentAt this step the structure of the report is finalized4.2 RedefinedAt this step the report not approved has to be redefined5.Report CommunicationAt this step communication methods and target audience (access level) will be established.6. Report ReviewAll Report fields should be checked and approved.6.1 Scheduled Report ProductionThe report will be scheduled as in the Request. 6.2 on-Demand Report ProductionThe report will be generated on demand.7. Report ClosureThe generated report is formally closed.8. Report publishingThe report is made available for the target audience.Table SEQ Table \* ARABIC 36 Service Reporting process steps and description ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download