best practices for it processes en

8/12/2019 Best Practices for IT Processes En

1/63

The Saudi e-Government Program (Yesser) has exerted its best effort to achieve the quality, reliability, and accuracy of theinformation contained in this document. Yesser assumes no l iability for inaccurate, or any actions taken in reliance thereon.

Yesser encourages readers/visitors to report suggestions on this document through the Contact Us!.

BEST PRACTICES FOR

ITPROCESSES

Version 1.0Date: 04/06/2007


2/63

Best Practices of IT Processes

e-Government Program (yesser) - 2 -

Table of Contents

1.

Introduction .......................................................................................................................4

1.1. Purpose .......................................................................................................................41.2. Document Structure .....................................................................................................4

2. Enablers for IT Processes ................................................................................................ 62.1. Overview of IT Service Management............................................................................ 62.2. The Concept of Service Oriented IT Departments........................................................ 62.3. Service Offering Requires a Stable IT Infrastructure..................................................... 72.4. Definition of a Process and Alignment Requirements................................................... 82.5. Overview of ITIL Best Practices .................................................................................11

3. Processes Implementation Considerations .................................................................. 153.1. Introduction ................................................................................................................ 153.2. Establish a Baseline for Implementation..................................................................... 153.3. Gap Analysis and Recommendations......................................................................... 153.4. Process Prioritization.................................................................................................. 163.5. Handle Implementation as a Project........................................................................... 173.6. Never underestimate the importance of Communication ............................................ 183.7. Organization Size Considerations .............................................................................. 183.8. General Considerations.............................................................................................. 19

4. Appendix I ITIL Process Assessment Exercise Saudi Governmental ITDepartment Case Study......................................................................................................... 21

4.1. Context ......................................................................................................................214.2. Scope of Assessment................................................................................................. 214.3. Process Maturity Indicators ........................................................................................ 27

5. Appendix II Guideline for IT Processes ...................................................................... 295.1. Introduction ................................................................................................................ 295.2. Incident Management Process...................................................................................295.3. Problem Management Process ..................................................................................375.4. Change Management Process...................................................................................435.5. Release Management Process ..................................................................................485.6. Service Level Management Process .......................................................................... 515.7. Processes Key Performance Indicators (KPIs)........................................................... 55

6. Appendix III Glossary of Terms................................................................................... 59


3/63



List of Tables

Table 1 "ITIL Definitions of Customers & Users ...................................................................... 12Table 2 "Focus of Service Delivery and Service Support Processes....................................... 13Table 3

"General ITIL Readiness Questionnaire..................................................................... 22

Table 4 "Incident Management Process Questionnaire .......................................................... 23Table 5 "Problem Management Process Questionnaire.......................................................... 24Table 6 "Change Management Process Questionnaire .......................................................... 25Table 7 "Release Management Process Questionnaire.......................................................... 26Table 8 "Service Level Management Process Questionnaire.................................................. 27Table 9 "Incident Management Process Activities................................................................... 31Table 10 "Incident Management Relationship with Other Processes ...................................... 34Table 11 "Problem Control Activities....................................................................................... 39Table 12 "Error Control Activities............................................................................................40Table 13 "Proactive Problem Management Activities.............................................................. 41Table 14 "Problem Management Relationship with Other Processes...................................... 41Table 15 "Change Management Process Activities................................................................. 45Table 16 "Change Management Relationship with Other Processes ...................................... 47Table 17 "Release Management Process Activities................................................................ 49Table 18 "Release Management Relationship with Other Processes...................................... 50Table 19 "Service Level Management Process Activities........................................................ 53Table 20 "Service Level Management Relationship with Other Processes ............................. 54Table 21 "Sample ITIL Processes KPIs .................................................................................56Table 22 "Glossary of ITIL Terms ........................................................................................... 59

List of FiguresFigure 1 "Towards a Value Center IT Department ....................................................................7Figure 2 "Service Offering & Infrastructure Stability ..................................................................8Figure 3 "Process Flow and Mapping in Organizational Unit .................................................... 9Figure 4 "Modeling of Generic Process ....................................................................................9Figure 5 "IT Service Management Alignment Pillars ............................................................... 10Figure 6 "Service Delivery Set & Service Support Set ........................................................... 11Figure 7 "Service Delivery & Service Support Domains.......................................................... 12Figure 8 "ITIL Process Priorities in $1 billion-plus Companies ................................................ 17Figure 9 "Sample ITIL Implementation / Enhancement Roadmap........................................... 18Figure 10 "Organization Size Consideration "Conflict Avoiding............................................. 19Figure 11 "ITIL Process Maturity Indicators ............................................................................ 28Figure 12 "Incident Management Process Lifecycle................................................................ 33Figure 13 "Problem Control Activities ..................................................................................... 39Figure 14 "Error Control Activities .......................................................................................... 40Figure 15 "Change Management Process Activities ............................................................... 46Figure 16 "Release Management Process Activities............................................................... 50Figure 17 "Service Level Management Process Activities ...................................................... 54Figure 18 "Service Level Management Relationship with Other Processes ............................ 55


4/63



1. Introduction

This document is a guide to implement a specific set of IT Processes for the IT

departments in the kingdom of Saudi Arabia government. It is a living document, and it willbe further developed and regularly reviewed to ensure that it continues to serve the ITdepartment needs in the government.

1.1. Purpose

The purpose of this document is to suggest guidelines for IT managers in implementing ITProcesses as part of the IT department operational readiness for Service delivery andsupport. The principles and concepts used in this document are to enable IT departmentsto provide proper IT Service Management (ITSM) based on IT Infrastructure Library (ITIL)best practice.

Main audience targeted is the IT managers and middle managers who will be planning theimplementation of IT Processes. Actual implementation needs to be managed under theumbrella of a project and a dedicated project team need to undertake the responsibilitiesof introducing the selected processes to the IT department.

1.2. Document Structure

The structure of this document is designed to ensure the information herein is easilyobtained based on the reader specific interest. This document contains two main sectionsand three appendixes:

1. Enablers for IT Processes: This section provides an overview of the underlyingconcepts that enable for the proper adoption of IT processes within the ITDepartments. This section addresses basic concepts like:

a. Overview of IT Service Management

b. The Concept of Service Oriented IT Departments

c. Requirements for a stable infrastructure to enable proper offering ofrequired services

d. Definition of a Process and Alignment Requirements

e. Overview of ITIL Best Practices

2. Processes Implementation Considerations: This section addresses theunderlying success factors that should be considered in ITIL implementation by theIT Departments

3. Appendixes:

a. In Appendix I, a Saudi Governmental IT Department case study is built andelaborated in relation to ITIL Implementation assessment covering:Context, Assessment Questionnaire, and Maturity Assessment Indicators

b. In Appendix II, a Guideline for IT Processes is presented. The scope of ITProcesses covered in this section cover: Incident Management, Problem


5/63



Management, Change Management, Release Management, and ServiceLevel Management

c. In Appendix III, a glossary of terms for some of the concepts used throughout this guideline


6/63



2. Enablers for IT Processes

2.1. Overview of IT Service Management

A prelude to ITIL Best Practices is to understand the context in which IT ServiceManagement!is generally needed in IT Organizations.

The concept of IT Service Management was introduced to give particular focus on theinternal process needs of IT organizations. In particular, IT Service Management focuseson the relationship that governs the process with quality of IT service (offered by the ITDepartment) in alignment with customer needs / expectations.

Traditionally, IT organizations mainly focused on the technology and less on processesthat govern the relationships of the main IT Organizations pillars: People, Process, and

Technology.

As IT Service Management can be classified under the quality awareness domain (otherexamples include: Total Quality Management (TQM), Six Sigma, Business ProcessManagement, and other), many frameworks have been developed to contribute to thediscipline. Among which:

IT Infrastructure Library (ITIL)

Control Objectives for IT and related Technology (COBIT)

Microsoft Operations Framework

Applications Services Library

Other

IT Service Management has been the focus of certain organizations, which have specificfocus to enhance the discipline. This includes organizations like IT Service ManagementForum (itSMF), International Organization for Standardization with Audit Standard ISO20000, and the British Standard Institute with BS15000. Currently, BS15000 is beingphased out to ensure only one standard in IT Service Management Audit and Certification:ISO 20000.

2.2. The Concept of Service Oriented IT Departments

Traditionally, IT Departments within government bodies served as cost centers. Some ITDepartments and due to the need of introducing the concepts of e-services started toadopt a service oriented organizational model to enable for better customer / publicsupport.

Adopting a service-oriented organization entails the transition from a cost center typicalorganization through the concept of Service Centers and ultimately Value Centers. ValueCenters or Business enablers are considered the highest maturity type of IT Organizationsand can be seen extensively in the financial sector as e-services is a big businessrevenue generator.


7/63



Cost Center

#IT Manager$ type CIO

Focus on Technologies

Service Center

Value Center

IT as a Service Provider

Optimization & Alignment oftechnologies, organization &processes

Continuously showing

value of IT to business

IT is a #Business Enabler$

IT Manager assumes the role ofa CIO (covering companyorganization, quality, risksmanagement and compliance)

Based on a clear strategy (derived from Organization Strategy), IT Department is continuously maturing

towards Service Center & Value Center Concepts

Figure 1 Towards a Value Center IT Department

The definition of maturity entails the adoption of the following operational strategic steps:

Adoption of an IT Service Management model (Example: ITIL)

Managed Quality that meets customers expectations

Ability to commit to customers on service levels IT is high up in the organizational chart

Ability to quantify risks and risk mitigation (Quality Assurance) is part of theoperational activities of the IT Department

2.3. Service Offering Requires a Stable IT Infrastructure

The concept of stable IT infrastructure traditionally meant:

Stable / tested technology

Easy access to resources (people and infrastructure)

Availability of the right monitoring tools

Some work procedures and documented roles and responsibilities

The concept of infrastructure stability remained relatively intact as IT usually providedtraditional set of applications that mainly focused on the internal users of the IT Services.This set of applications covered traditional applications like email, HR, accounting, andother systems.

New challenges for IT infrastructure assurance and stability had risen when critical

services mainly related to external customers (the public for example) started demandingbetter commitments, availability, and high flexibility in service offering. The challenge


8/63


9/63



The concept of metrics is defined to control and measure the activities of an effective andefficient process. These metrics are defined based on process goals and realized througha measurable quality parameters and Key Performance Indicators.

Figure 3 Process Flow and Mapping in Organizational Unit2

Figure 4 Modeling of Generic Process3

Systematic adoption of IT Service Management is achieved through applying best practiceframeworks such as ITIL. ITIL concepts focus on the implementation of defined set ofprocesses related to service delivery and service support.

2

APPENDIX B: Process Theory and Practice, Book for Service Support(Published 2000), page 272 TSO 2005, All rights reserved3Ibid., page 273


10/63



There should be a strategy for IT Departments in adopting IT Service Managementframeworks such as ITIL. ITIL (through the processes) works to achieve the goals of ITService Management (aligning process to people and technology to meet service targetsset by the business). As organizational structures and defined roles have to be mappedand aligned to fulfill the outputs of the processes, the strategy of implementing IT ServiceManagement frameworks should cover:

Services Alignment: IT Departments (based on organization and businessstrategy) should work to assess the Scope of Services provided to its customersand users. The scope of services is the main pillar in defining the other servicemanagement pillars. Typically, for any service provided by the IT Department,there are supporting Processes, Organization and people, and the underlyingtechnology

Processes Alignment: Within IT departments, processes are usually defined tofollow business requirements and expectation of the IT. Within the context ofgovernment, IT support and regardless of the current model IT is functioning under(Cost, Service, or Value), the processes must be continuously improved to enable

for meeting service offerings requirements Technology Alignment: IT Departments must work to identify the current set of

technology used by IT and map it to the future and targeted requirements

Organizational Alignment: Within each IT Departments, there are three areas thatneed to be investigated for ITIL alignment:

o Existing IT organizational structure: Up to recent years, IT organizationalstructure was typically oriented about the technologies provided. ServiceOriented structure requires the IT Department to build a structure that isfully aligned with the services provided, team capabilities defined, and ITcapacity requirements (Number of users to support, sites, criticality, etc.)

o

Team Capabilities: Team capabilities should be based on the profile ofservices defined. If the organization is adopting a certain technology(Example: Microsoft Oriented technologies, or SUN oriented, an ERPsolution, etc.) the team capabilities should reflect knowledge and skills inthat area

o Team Capacity: Team Capacity is derived from the type and level ofsupport required. If the IT organization is needed to function at multiplelocations or different work schedules, the team capacity needs to reflectthat

Services

Technology

ITSM

Al ignment

Organisation

Process

Figure 5 IT Service Management Alignment Pillars


11/63



2.5. Overview of ITIL Best Practices

IT Infrastructure Library (ITIL) framework puts IT Service Management concepts inpractice. ITIL was initially developed in the late 1980%s by the UK government and sincethen has been pervasive within IT Organizations across the world. Many organizationsbelieved that by adopting ITIL, a synergy and alignment would be created internally and

externally through interfacing with the Business and Organization goals.

ITIL goal is not to introduce new practices to the IT Department. On the contrary, ITIL bestfit is accomplished through defining a model where process goals, activities, inputs andoutputs can streamline and align the existing operational activities of the IT Department.

Since inception, ITIL development was driven by a quality approach that emphasizes theexpectation needs of the business and the relationship that should govern it. Quality ofService and Customer focus played a major role in defining processes goals and therelated activities.

ITIL consists of two sets of processes: Tactical processes that cover Service Delivery setand consist of:

Service Level Management

Financial Management for IT Services

Capacity Management

IT Service Continuity Management

Availability Management

Operational processes cover Service Support set and consist of:

Incident Management

Problem Management

Configuration Management

Change Management

Release Management

Service Desk is classified as a function within the ITIL framework and among its activitiesis the utilization of Incident Management Process.

Service Level

Management

FinancialManagement

for IT services

Capacity Management

IT Service

ContinuityManagement

IncidentManagement Problem Management

ChangeManagement

ConfigurationManagement

ReleaseManagement

IT

Infrastructure

IT

Infrastructure

IT

Infrastructure

IT

Infrastructure

security

security

ServiceDesk

ServiceDesk

Availability Management

Figure 6

Service Delivery Set & Service Support Set

4

4 www.itilsurvival.com(reproduced with permission)
http://www.itilsurvival.com/http://www.itilsurvival.com/


12/63


13/63



Table 2 Focus of Service Delivery and Service Support Processes

Type Process Name Process Focus

Service Level Management Focuses on two main aspects:Customers and the Service LevelAgreements (SLA)

Customers focus in term ofcommunication and managingexpectations while SLAs on thenegotiation, agreement, and review

Financial Management for ITServices

Focuses on three aspects: Budgeting,Accounting, and Charging.

Budgeting focus covers defining the

budgeting items and setting the targets.Accounting is related to cost in term ofelements (HW/SW, People, etc.),categories (Capex / Opex, Direct /Indirect, etc.), and models (Customerand Service)

Charging focuses on the chargingpolicies defined by the business and it isusually outside the scope ofgovernmental IT Departments

Capacity Management Focuses on IT Infrastructure Capacity

planning covering dimensions ofbusiness, service, and resource. Mainactivities cover modeling andinfrastructure resource sizing

IT Service Continuity Management Considered as part of BusinessContinuity and Disaster RecoveryPlanning. Focuses on the unexpectedissues arising due to IT resourcesunavailability. Takes into considerationrisk management and testing of theplans

ServiceDelivery

Availability Management Focuses on the expected issues that canpotentially arise from IT resourcesunavailability. Addresses riskmanagement and mitigation andintroduces concepts related toavailability, reliability, maintainability,serviceability, and security of the ITinfrastructure

ServiceSupport

Incident Management Focuses on the unplanned interruptionsof the services. Addresses issues ofownership, detection, classification,

diagnostic, escalation, and resolutionand recovery of the services


14/63



Type Process Name Process Focus

Problem Management Looks for the root causes for incidentsand focuses on reactive, proactive, andreviews of the problems

Configuration Management Focuses on the components of theinfrastructure and the relationship thatgoverns them. Has specific conceptsrelated to storing of software (DSL "Definitive Software Library) andhardware (DHS "Definitive HardwareStore)

Change Management Focuses on controlling and classificationof the changes introduced to the ITinfrastructure. Addresses concepts likeRFC (Request for Change), CAB

(Change Advisory Board)Release Management Focuses on controlling the changes

through planning, testing, andimplementation


15/63



3. Processes ImplementationConsiderations

3.1. Introduction

The considerations proposed in this section take into account the type of governmentalorganization entities the IT Department is functioning in. IT should be noted that theunderlying success factors in ITIL implementation does not differ by the type oforganization IT Departments functions under. The considerations below need to beadopted in order to ensure ITIL projects implementation success.

3.2. Establish a Baseline for Implementation

Before commencing with the plan to implement ITIL best practice framework in the ITDepartment, it is necessary to establish a documented baseline of:

All identified services. IT Department will need to conduct a strategic exercise withthe Management of the governmental organization in which the result will be toidentify and define the services that is required to be offered. Cost ofimplementation should be weighed against defined benefits. It should be notedthat Service chargeability is the only dimension of the exercise that will not berelevant to the overwhelming majority of IT Departments in the government ofSaudi Arabia

Assessment of all processes maturity that are considered for implementation

All work procedures followed in the IT Department

Roles and responsibilities of the staff working in the IT Department

Assess if organizational structure changes are required. Two functional entities willbe a must if the full scale implementation will take place: Service Desk Functionand Service Level Management Group

Assessment findings of staff readiness in term of capability and capacity

Identified required tools that can help in the automation of ITIL processes

3.3. Gap Analysis and Recommendations

It is definite that the base lining exercise will identify gaps that need to be addressedbefore commencing with the ITIL implementation. These gaps should be handled in theform of recommendations and must be implemented separately. Sometimes, therecommendation implementation will be considered as a transitional phase of the ITILimplementation, and many successful implementations depend on the outcome of thisintermediary phase.


16/63



3.4. Process Prioritization

Upon closing the identified gaps from the base lining exercise, there will be a prioritizationexercise related to the processes that need to be implemented first. The prioritizationexercise will focus on aspects such:

IT Department readiness as a result of gap closure phase The dimension of complexity of service offering tightened to the comprehensive

implementation of processes can create a complex project to implement. Hence,we need to be realistic in defining the real requirement to implement the neededscope of processes

Never undermine the issues related to Management of Change. As it is the humannature to resist changes, there will be always the burden of introducing thechanges at the right pace and speed

In term of process prioritization, ITIL best practice framework highlights certainconsiderations for the IT Departments such as:

We can always start with Service Level Management as it really defines the depthall other processes will need to consider

Service Desk Function and Incident Management Process go hand-in-hand

Change, Configuration, and Release Management can follow

Problem Management Process is recommended to be implemented only afterIncident Management Process reaches a certain maturity. Due to the conflictingnature of Problem Management and Desk and Incident Management, the processshould not be governed by the same functional entity

Service Delivery Processes (other than Service Level Management) can beimplemented after Service Support Processes. However, the part related to

defining acceptable capacities and availability has to be undertaken by ServiceLevel Management

In a published whitepaper by Forrester Research in October 20055, 19 IT Managers at $ 1billion-plus companies indicated that Incident Management, Change Management, andService Level Management fall in the top 5 priority ITIL processes in term of importanceand need to their operation. Additionally and within the top five ranks, other processesincluded Configuration Management and Availability Management.

5IT Asset Management, ITIL, and The CMDB: Paving The Way For BSM, by Robert McNeill and Thomas

Mendel, Ph.D. 2005, Forrester Research, Inc.


17/63



Figure 8 ITIL Process Priorities in $1 billion-plus Companies6

It should be emphasized that the priority of the processes to be implemented does not relyon the type of organization IT Departments functions under. The priority of processimplementation relay on the maturity and readiness of the IT Department to adopt theassessed process.

3.5. Handle Implementation as a Project

The implementation of ITIL processes (either one or more) must be handled as a project.All aspects related to the project must be addressed and covering developing a businesscase, Detailed Project Plan, Detailed Communication Plan, allocate dedicated resourcesto the project, and requesting clear milestones and achievements. The concept of QuickWins must also be identified and defined at this stage. Quick wins are all improvementsthat are perceived and acknowledged by the customer during the early phases of the ITILimplementation. To the ITIL implementation team, quick wins are all milestones that canhelp in achieving preset goals during the early implementation project.

A clear implementation roadmap must be developed and approved by the organizationmanagement and not only IT management. The defined roadmap need to take intoconsideration the four areas of IT Service Management Alignment: Service, Process,

Organization, and Technology. Below figure represents a sample roadmap.

6Ibid., page 5


18/63



Initia-tive

PriorityEnhancements

P1+ P1 P2 P3

Dependencies

Services enhancements

S1 End users service O1

S2 Help Desk empowerment S1,P10,O1,O3,T1,T2

Process enhancements

ITIL pro cesses integrat ion

P1 Change , Release and project management O1, O5, T1, T3

P2 Incident and configuration management O1, O5, T1

P3Configuration and Service level

managementO1, O5, T1, T3

P4 Incident and problem management S2, O1, O5, P7, T1

P5 Problem and configuration management O1, O5, P2, P7, T1

Desktop management

P6 Configuration and change management O1, O5, T1

Root cause analysis

P7 Problem management O1, O5 P4, P5, T1

P8 Process outcomes measures O1, S1, S2, P1, P3,P4, P5, P6, P7, P9

Process documentation

P9 ITIL documentation quality improvement Rely on others initiatives All

P10 ITIL documentation customization Rely on other initiatives All

Organizations enhancements

O1 Leadership All

O2 Awareness O1, P8

O3 Train service Desk O1, S2

O4 Train ETOM_ITIL link O1

O5 Roles restatement P1, P2, P3, P4, P5,P6, P7

Technology enhancements

T1 Service Desk tools expansion O1, S2, P1, P2, P3,P4, P5, P6, P7

T2 System & Network events monitor S2

T3Server management

O1, P6T4 SLA management O1, S1

Figure 9 Sample ITIL Implementation / Enhancement Roadmap

Note: eTOM is the enhancement Telecom Operation Map and it is the framework used inTelecom operators to align their operational and organizational activities.

3.6. Never underestimate the importance of Communication

ITIL Projects can only succeed if only it is properly and continuously communicated to theright people throughout the project implementation. Proper buy-in and commitments to thegoals of the project has to be ensured continuously.

The success of ITIL Projects implementation will depend on the people dimension andtheir acceptance of following the defined processes. A process can be perfect on paper,and an advanced tool can be selected, but if there is no people buy-in, the success of theimplementation will never by realized.

3.7. Organization Size Considerations

The overall organization size will add to the complexity of the implementation. Forexample, if the organization is dispersed over various geographical locations, the


19/63



complexity of implementation will increase in term of coordinating activities and assessingnecessary workloads.

In large organizations, the dimension of process role specialization will be needed tocreate central accountability. If the size is small, process roles can be shared within oneperson or more.

Many large organizations consider the aspect of creating a function processes unit thathas dedicated process owners and managers. This aspect should be considered to avoidconflict of interest in relation to functional duties vs. process duties.

Organizational departments

Processes

Line managers

Process-

managers

CONFLICT?

= process steps

Figure 10 Organization Size Consideration Conflict Avoiding

3.8. General Considerations

Other general considerations for ITIL Implementation that require the attention of the ITmanagement include:

1. Organization Management must be fully committed to the success of this project.Their important and commitment in all the phases of the project is needed andshould never be taken for granted

2. Proper funding to the project is allocated from day one of the implementation

3. When defining the implementation timeline, IT Managers should pause and think ifthe implementation timeline is realistic and can be achieved with the definedtimeframe

4. Introduce the role of Service Management Champion who will drive theimplementation

5. Right and realistic expectation of results should be recognized. Over expectationscan cause a loss of interest after the initial hype

6. The implementation project should be dealt with as a strategic project. Tactical oroperational issues related to the implementation should never overshadow thestrategic direction of the project

7. IT Managers should ensure that the proper authorities are given to the processowners and managers who will take over process operation

8. IT Department should never let go any processes and procedures that are working

for them. ITIL serves as a framework that can be easily adopted to the currentsuccessful practices of the IT Department


20/63



9. Does the IT Department Operation rely on any outsourcing activities? If yes, thethird party must be included in the activities related to the implementation and theyneed to ensure their adherence to the adoption of the implemented processes

10. Work hard to change the mentality of IT staff to become Customer oriented. Sendthe staff to seminars and conferences that increase their appreciation of becoming

part of a service culture that focuses on customer satisfaction11. ITIL training is recommended to all staff who will play a defined role in the

processes implemented

12. Roles and Job descriptions must be modified to include objectives related toprocess activities. If this dimension is missed, functional responsibilities will alwaystake precedence. Hence, proper accountability metrics are to be introduced to alllevels of process roles and responsibilities

13. Continuous alignment of organization management of the progress of theimplementation. IT Departments should not be shy to continuously report progress.This will create a culture of anticipation in the whole organization


21/63



4. Appendix I ITIL Process AssessmentExercise Saudi Governmental IT

Department Case Study

4.1. Context

As described in Section 3 above, one very important aspect of ITIL implementation is toconduct a process assessment exercise as part of the base-lining activities. This exerciseis needed to capture information about the status of processes currently adopted by the ITDepartments operation.

As such, an ITIL process maturity assessment exercise with a Saudi governmental ITDepartment took place to:

Measure the IT Department interest and reaction to the concept of implementingITIL Processes

Identify pain areas that raise challenges to the IT Department in their dailyoperation and can be addressed through implementing ITIL processes

Show the value that ITIL implementation can bring to the IT Department

Emphasize that the concepts of ITIL adoptions and Service Management are notluxuries that can be done without

Address global cultural concerns that will raise challenges to successfulimplementation of ITIL processes

4.2. Scope of Assessment

The assessment covered the following areas:

General questions related to the readiness of ITIL implementation

Incident Management Process

Problem Management Process

Change Management Process

Release Management Process Service Management Process

It should be noted that the questions are designed to be answered in a Yes / No format.Each of the questions has a certain weight assigned to it. The below questionnaires aredesigned as such that the first three questions carry the highest weight (mandatory tohave) in order to realize or satisfy the required maturity.


22/63



4.2.1. General ITIL Readiness

Table 3

General ITIL Readiness Questionnaire

Assessment Area Assessment Questions

General ITILReadiness

Is the business committed to the use of ITIL (meaningthe business is aware of the added value and theycommit to it by e.g. freeing up resources)?

Do you provide management with informationconcerning operational performance (includinganalyses) of the different processes?

Are there standard reports regularly produced

(operational reports, KPI's and service performance)?

Does the IT-department comprehend how the IT-services add to the business?

Has the purpose and benefits of the differentprocesses been advertised within the organization?

Is the IT-staff trained on ITIL, standards and all relatedprocedures?

Do your regularly organize meetings concerning thecontent of the processes (per process)?

Are all links between the processes identified andoperational? (E.g. information between processeswhich is exchanged, procedures, involvement)

Are your processes supported by a servicemanagement/helpdesk tool?


23/63



4.2.2. Incident Management Process

Table 4 Incident Management Process Questionnaire


IncidentManagementProcess

Are incident records maintained for all reportedincidents?

Are all incidents managed in conformance with theprocedures documented in SLAs?

Is there a procedure for classifying incidents, with adetailed set of classification, prioritization and impactcodes?

Is there a procedure for assigning, monitoring and

communicating the progress of incidents?

Does incident management provide the Service Deskor Customer/User with progress updates on the statusof incidents?

Is there a procedure for the closure of incidents?

Does incident management match incidents againstthe problem and known error database?

Are Service Level Agreements available andunderstood by incident management?

Are requests for changes produced, if necessary, forincident resolution?

Are resolved and closed incident records updated andclearly communicated to the Service Desk, customersand other parties?

Do you provide management with informationconcerning escalated incidents?

Have the interfaces between the Service Desk andincident management been defined andcommunicated?

Does incident management exchange information withProblem Management concerning related problemsand / or known errors?


24/63



4.2.3. Problem Management Process

Table 5 Problem Management Process Questionnaire


ProblemManagementProcess

Is there a procedure for problem management?(Concerning analyzing significant, recurring andunresolved incidents and identifying underlyingproblems, classification of potential problems, in termsof category, urgency, priority and impact and assignedfor investigation?)

Are at least some problem management activitiesestablished in the organization, e.g. problemdetermination, problem analysis, problem resolution?

Have responsibilities for various problem managementactivities been assigned?

Is the nature of the problem always documented aspart of the problem record?

Is Problem Management responsible for thecompleteness of all problem records?

Are the standards and other quality criteria madeexplicit and applied to problem management activities?

Does Problem Management provide management with

information concerning recurring problems of aparticular type or with an individual item?


25/63



4.2.4. Change Management Process

Table 6 Change Management Process Questionnaire


ChangeManagementProcess

Are at least some change management activitiesestablished in the organization, e.g. logging of changerequests, change assessments, change planning,change implementation reviews?

Have responsibilities for various change managementactivities been assigned?

Are the procedures for initiating change alwaysadhered to?

Is there a procedure for approving, verifying andscheduling changes?

Are all changes initiated through the agreed changemanagement channels, for example a ChangeAdvisory Board?

Are changes planned and prioritized, centrally or bycommon agreement?

Are formal change records maintained?

Is a change schedule of approved changes routinelyissued?

Are there standards and other quality criteria for thedocumentation of change made explicit and applied?

Does Change Management provide pertinentinformation concerning the change schedule?

Does Change Management exchange information withConfiguration Management regarding change progressand change closure?


26/63



4.2.5. Release Management Process

Table 7 Release Management Process Questionnaire


ReleaseManagementProcess

Are explicit guidelines available on how to managerelease configurations, naming and numberingconventions and changes to them?

Does Release Management verify informationconcerning the release? (Like number of major andminor releases within a given period, number of new,changed and deleted objects introduced by eachrelease, the number of problems in the liveenvironment attributable to new releases)

Are at least some release management activitiesestablished within the organization, e.g. procedures forthe release and distribution of software?

Have roles and responsibilities for various releasemanagement activities been assigned betweenoperational groups and development teams?

Are there operational procedures for defining,designing, building and rolling out a release to theorganization?

Are there formal procedures for purchasing, installing,moving and controlling software and hardwareassociated with a particular release?

Are there formal procedures available for releaseacceptance testing?

Are all CI's within a release traceable, secure and doprocedures ensure that only correct, authorized andtested versions are installed?

Are plans produced for each Release?

Are back-out plans produced for each Release?

Are test plans, acceptance criteria and test resultsproduced for each Release?

Is there a library containing master copies of allcontrolled software within the organization?

Are the standards and other quality criteria for releasemanagement made explicit and applied?

Does Release Management exchange information withChange Management concerning change records forany new / changed CIs?


27/63



4.2.6. Service Level Management Process

Table 8 Service Level Management Process Questionnaire


Service LevelManagementProcess

Do you check with the customer if the activitiesperformed by the IT department adequately supporttheir business needs?

Do you check with the customer that they are happywith the services provided?

Are you actively monitoring trends in customersatisfaction?

Are you feeding customer survey information into theservice improvement agenda?

Are you monitoring the customer's value perception of

the services provided to them?

Are at least some service level management (SLM)activities established within the organization, e.g.service definition, negotiation of SLA's etc?

Have responsibilities for service level managementactivities been assigned?

Has a catalogue of existing services been compiled?

Are there mechanisms for monitoring and reviewingexisting service levels?

Do you compare service provision with the agreedservice levels?

Are the standards and other quality criteria for SLMdocumented?

Do you provide management with informationconcerning trends in service level breaches?

4.3. Process Maturity Indicators

Any ITIL process maturity measurement exercise will use a process maturity indicatorsusually ranging from zero to five. Zero indicated a non existent process maturity, while fiveis the highest process maturity that is fully optimized and aligned with the business andservice requirements. Below figure provides a visual elaboration of the Process MaturityIndicators.


28/63



Automation

Complete controlStructures.

Performance analysis

Policies, procedures& standards defined.Corporate Knowledge

Quality PeopleDefined Tasks

Undefined tasks.Relies on Initiation

Improved feedbackinto the Process

Measured Process(Quantitative)

Process defined &Institutionalized

(Quantitative)

Process Dependanton Individuals

(Intuitive)

Ad Hoc/Chaotic

Optimized

ManagedAnd

Measurable

DefinedProcess

Initial /Ad Hoc

RepeatableBut

Intuitive

Process

Evolution

Process

Evolution

PROCESSMATURITY

CHARACTERISTICACHIEVEMENT

METHOD

5

4

3

1

2

No MethodComplete Lack

Of Process ValuesAnd Awareness

NonExistent

0

Figure 11 ITIL Process Maturity Indicators


29/63



5. Appendix II Guideline for IT Processes

5.1. IntroductionIn this section, the guideline addresses a selected set of ITIL processes to be consideredfor implementation by IT Departments in the Government of Saudi Arabia. The set of ITILprocesses covered in this guideline include:

a. Incident Management

a. Problem Management

b. Change Management

c. Release Management

d. Service Level Management

For each of the selected processes above, the guideline will focus on addressing thefollowing areas:

a. Introduction to the Process

b. Benefits of Implementing the IT Process

c. General Process activities to be followed

d. Relationship with other Processes

The objective of this section is not to repeat the processes theory as defined by ITIL bestpractices. The objective is to give a practical dimension for the IT Manager whenconsidering an implementation of the process. Descriptions tend to be less complex and

more practical than the defined theory.

At the end of this section, sample KPIs to measure each of the above processes successis presented for IT Managers consideration.

5.2. Incident Management Process

5.2.1. Introduction to the Process

Within the expected service window and in the event that the user is not able to access

the service (example: system is down, forgot the password, etc.), the IT Department needto be aware (through the structure of the Service Desk or IT Helpdesk function) on theissue. In the usual scenario, the user will contact the Service Desk to report the issues hehas.

The Service Desk will then follow a predefined set of activities with the objective of solvingthe service interruption or degrade in the quality of the service. These predefined activitiesare grouped and structured under the Incident Management Process!.

ITIL terminology defines an Incident!as:


30/63



any event which is not part of the standard operation of a service and whichcauses, or may cause, an interruption to, or a reduction in, the quality of thatservice.!

7

The term Incident!also encompasses certain requests for services or adding additionalservice (example: Request to assign an IP address to one workstation). This is due to the

similar nature of approach in handling such requests.

5.2.2. Benefits of Incident Management Process Implementation

Implementing Incident Management Process will extend benefits to the entire organization(users of IT and providers of IT). For the users of IT, the benefits include:

Minimize impact of the service interruption or degrade of service on performingwork!activities (There is a specialized group who will handle the user reportedincident effectively and efficiently)

Indirectly, users of IT report to IT Department trends in service quality issues (ITwill analyze required enhancements to the service through systems and

infrastructure enhancements)

Users of IT set expectations for the right service levels needed (A proactive wayfor IT to determine the service level agreements that will be defined with otherentities including the Customers of the service and all IT providers of the service)

For providers of IT Services, Incident Management Process gives them the followingadvantages:

A mechanism to control Users and Customers satisfaction by providing asystematic way of handling the reported incidents (IT will usually assign a ticketnumber and provide regular updates on the status of the incident resolutionactivities)

Ideal mechanism to align the operational support activities of IT department(staffing, resource utilization, monitoring, and performance measurement) to meetcustomer expectations (In combination with Service Desk Function, IncidentManagement Process enables IT to become more customer focused)

Ensures a better control of the expected performance of the infrastructure. IncidentManagement will be a control mechanism that enable for effectively optimization ofthe IT infrastructure through identification of needed areas of improvement

5.2.3. General Process Activities

Incident Management Process is considered as the bridge between users and IT (Ideally,through Service Desk Function). The processes activities are designed to be customerinteracting as much as IT interacting. The generic process activities are defined asfollows:

7

CHAPTER 5: INCIDENT MANAGEMENT, Book for Service Support(Published 2000), page 71 TSO2005, All rights reserved


31/63



Table 9 Incident Management Process Activities

Activity Name Main Activity Tasks / Actions

Proactive is achieved through infrastructure (systems,network, and elements) monitoring tool integration with theIncident Management Process Tool. Thresholds will bedefined on the monitoring tools to trigger and identify anincident before and when it happens.

Reactive is achieved through user or customer communicationwith the Service Desk and reporting an incident (service issueor service request). Currently, there are different methods ofcommunication with the Service Desk and include: email,intranet forms, telephone, and fax.

Incident Detection andRecording

(Ideally, incidentdetection and recordingwill be done with thehelp of a tool)

Incident recording entails:

Collecting all relevant information related to the user who

is reporting the incident

Collecting descriptive information (user perception) of thesymptoms reported

Map the reported information and symptoms to the rightinfrastructure component

Ability to identify the right support group or team will beassigned to solve

Classification & InitialSupport

Ability to decide the priority of solving the incident (priorityis defined as the measured impact on the work activities(business) multiplied by the urgency of resolving theincident)

Determine if the identified component details (as describedby the User) are accurate as per the ConfigurationManagement Database or the available definition of thecomponent

Ability to match the incident with previously similar solvedincidents through referencing to Problem and Knownerrors databases. This activity will enable to identify anywork around or solution that can be used to solve theincident

Conduct initial support activities to apply the solution orwork-around if available (if the Service Desk is classifiedas a Skilled Service Desk) or assign the ticket to theproper support group who can attempt to solve the incident

Investigation andDiagnosis

Investigation and diagnosis activities focus on assessing theincident details as identified and recorded by the previoussteps in the process. Accuracy of information will bedetermined in this step.


32/63




Resolution andRecovery

Resolution and Recovery activities either:

Apply the identified solutions or work-around as identifiedby the support group, or

Raise a Request for Change (to Change ManagementProcess) to apply the identified solution to solve theincident

Incident Closure Incident closure activities concerned with:

Customer / User confirmation that the incident has beenresolved and normal work activities are restored

Ensuring that the incident ticket (record) is updatedcorrectly with the closure information such as the type ofsolution applied, the effort put or time spent to solve theincident, and the support group details

It should be noted here that incident closure should be arestricted! activity. Restricted in relation to ability of thesupport group or service desk to close the incident withoutproper approvals of the incident originator (user or customer).Only the incident originator is the one who should be allowedto close the ticket.

Ownership, Monitoring,Tracking, andCommunication

This activity plays the role of Quality Control of the otherprocess activities described above. The main actions in thisactivity focus on:

Monitoring the incident in term of current status andadherence to service levels

Escalate the incidents if needed (if service level breachesexists "example: support group exceeded allowed time tosolve the incident as defined in the SLA)

Proactively inform the user about the status of his incident

Ownership of the incidents is always maintained within theService Desk. As a result, the responsibility of monitoring,tracking, and communication also falls in the Service Desk.With the help of tools, this process activity is usually

automated to a high degree.


33/63



Figure 12 Incident Management Process Lifecycle8

5.2.4. Relationship with Other ProcessesIncident Management Process and related activities of the Service Desk Function havemain interactions with four other ITIL processes:



Configuration Management Process

Service Level Management Process

Below tables provide a summary of the required interactions and relationships:

8CHAPTER 5: INCIDENT MANAGEMENT, Book for Service Support(Published 2000), page 73 TSO

2005, All rights reserved


34/63



Table 10 Incident Management Relationship with Other Processes

Process Name Relationship with Incident Management Process

Problem Management Service Desk / Incident Management reliesheavily on Problem and Known-Error Databasecontrolled by Problem Management

Service Desk / Incident Management work toescalate major incidents that cannot beaddressed or fall outside their scope

Service Desk / Incident Management mustensure a proper record and information toenable Problem Management to conduct trendanalysis activities

Problem Management ensures proper access tothe Problem and Known-Error Database

Problem Management provides IncidentManagement with permanent solutions

Problem Management advise IncidentManagement to close related incident ticketsthat was identified and grouped with similarunderlying cause of error


35/63




Change Management Service Desk / Incident Management shouldensure all RFCs, Standard Changes, and non-standard changes routed through Helpdeskfollows the Change Management process

Helpdesk should communicate to the customerservice interruptions based on the ForwardSchedule of Changes (FSC)

Based on the available list of changes (standardand non-standard) Service Desk to report backto Change Management the impact of Changescarried through customer feedback (relatedincidents opened)

Helpdesk should report to Change Managementincidents due to unauthorized changes to the

infrastructure All RFCs raised by the organization must be

routed via the Helpdesk

All Non-Standard Changes need to bemanaged thru Helpdesk

Service Desk needs to manage StandardChanges directly

Change Management must update theHelpdesk with the status for RFCs status:Completed, in progress, unsuccessful, rollback,

etc. The Scheduled Forward Schedule of Changes

(FSC) provided by CAB must be communicatedand shared. The objective is to enable theHelpdesk to respond properly to customerqueries related to service disruption resultingfrom scheduled changes


36/63




Configuration Management Service Desk / Incident Management shouldensure incident tickets are logged accuratelyagainst the right CIs. This will ensure that trendanalysis activities (Problem Management) and

Change Management address CI changesbased on these incidents

To help identify unauthorized changes, ServiceDesk / Incident Management need to identifyand report to Change Management andConfiguration Management any inconsistency inCI description based on the inputs providedrelated to incidents

To enable Service Desk to give correctclassification and prioritization of incidentsreported, CIs description must be mappeddirectly to the CMDB.

To enable Service Desk to better managechanges (Standard and non-Standard, mappingof CIs is required)

To enable Service Desk to report unauthorizedchanges, mapping of CIs is required


37/63




Service Level Management Service Desk and Incident Management need toprovide SLM with OLA requirements for processactivities involving 2nd and 3rd line of Support

Incident Management need to provide SLM withpre-agreed reports related to Service Level

Breaches (SLA violations)

Service Level Management need to provideService Desk / Incident Management with an ITService Catalog in which:

o Business inputs are provided forservices description, functions andsystems attached to services, serviceimpact, expected service levels, SLAs,and costing

o SLM need to advise IncidentManagement on each service priorityprovided in the IT Service Catalog. Thebreakdown of priority should be basedon Service functionalities. Example:ICMS billing functionality, Email Sendfunctionality, etc. This will enable ServiceDesk to tie the service to the rightresponse and resolution times

o SLM need to update IncidentManagement with SLA changes that

impacts service priority

SLM must build OLAs based on inputs fromService Desk and Incident Management forprocess related activities that involves outsideparties (Example: Support Groups, vendors(UCs))

5.3. Problem Management Process


Other to the incidents that are caused by the user lack of training or knowledge (whichshould be identified through trend analysis activities by the Service Desk Function andprovided to management by a report), there are incidents that are caused by a commoncause or error in the infrastructure.

Problem Management Process is concerned with identifying and solving the root cause ofthese incidents that are impacting the work activities of a certain group or sometimes theentire organization.

In addressing this situation, Problem Management Process relies on two aspects: Areactive aspect and a proactive aspect. The reactive aspects focuses on incidentsescalated through the Incident Management Process for major incidents that could not be


38/63



solved through the Incident Management Process. The major incidents usually will havethe criteria of impacting a number of users or carry an adverse impact on the workactivities beyond a single user. Proactive Problem Management works to control theoccurrence of incidents before they impact the organization and work activities.

5.3.2. Benefits of Problem Management Process Implementation

Adopting a Problem Management Process will give the entire organization an extendedmaturity level that Incident Management Process will have high difficulty to reach. Similarto Incident Management Process, the benefits of Problem Management Process can beseen at both sides of the organization (Users of the IT Services and Providers of the ITServices (IT Department)). Major benefits achieved include:

Better perception of the IT as a service provider due to ability to control thenumber of incident volumes either by reactive activities or the proactive ones

Release pressure on the Service Desk and hence can focus more on the image of

IT and not be consumed with fire-fighting and solving incidents

Provide other processes with permanent solutions (not work-arounds) and hence,the incidents will stop of recurring

Contribute to better learning of the IT staff through building the knowledge andproviding access to tools such as Known Error and Problem Database andKnowledge Bases


Problem Management Process has three sets of activities within its scope of work. Thesethree sets are classified in relation to the reactive mode and proactive mode. The reactivemode consists of two of these sets, while the proactive mode has one set of activities.

Within the reactive mode and when incidents are escalated to Problem ManagementProcess, the process will aim at identifying if the problem reported is a known-error. If it isan unknown-error, then what is called Problem Control activities take over and theProblem Management Process will work to analyze the problem and identify the rootcause of it until it becomes a known-error. A known-error will be classified as problem thatcan be solved either through a work-around or a permanent solution and the Error Controlactivities will take over. Hence, distinctively, Reactive mode constitutes of: ProblemControl and Error Control.

Proactive Problem Management activities are one set that focus on solving or addressingthe problems before incidents occur.

Below tables provides a general description of Problem Control, Error Control, andProactive Problem Management activities.


39/63



Table 11 Problem Control Activities


Problem Identificationand Recording

(In addition to ProblemManagement Process,this step can beperformed byprocesses like CapacityManagement,AvailabilityManagement, and ofcourse IncidentManagement)

Analyze the escalated incident:

Query Known-Error database to find a match for thereported problem, if not successful

Query the Problem database to find a match for thereported problem, if not successful

Open a new problem record and record the details basedon the incident description and related support activitiesconducted thus far

allocate the problem to problem management team

Problem Classification Similar steps to Incident classification and covers aspects andinformation related to:

categorization

Prioritization (Identifying impact and urgency)

Problem Investigationand Diagnosis

Similar steps to incident investigation and covers aspects andinformation related to assessing the details and Accuracy ofinformation reported in problem identification and recordingand classification

The output at this stage will be when the root-cause of the problem is identified and eithera work-around or a permanent solution is ready to be implemented.

Figure 13 Problem Control Activities9

9

CHAPTER 6: PROBLEM MANAGEMENT, Book for Service Support(Published 2000), page 101 TSO2005, All rights reserved


40/63



Table 12 Error Control Activities


Error Identification andRecording

Known Error is confirmed to the status of the identifiedproblem root-case infrastructure component

Error Assessment Conduct initial assessment on how to resolve the known-error

Conduct Error Resolution Impact Analysis with the help ofspecialist groups

Identify if the error resolution requires a Request forChange to be raised (RFC)

Error ResolutionRecording

Record error resolution activities in the Known-errordatabase

Error Closure Upon implementation of the error resolution activities, thefollowing must be updated:

Known-error record in Known-error Database

Problem Record in Problem Database

Related incidents in the Incident Management tool

Figure 14 Error Control Activities10

10 CHAPTER 6: PROBLEM MANAGEMENT, Book for Service Support(Published 2000), page 106

TSO 2005, All rights reserved


41/63



Table 13 Proactive Problem Management Activities


Trend Analysis Procedures to conduct continuous activities in relation to:

analysis of incidents and problem records

Analysis of incidents and problem categorization

Analysis of reports generated by Systems / NetworkManagement tools

Vendor literature

Attending conferences

Analyzing customer surveys

The internet, and looking for user groups inputsTargeting PreventiveAction

Introduce necessary metrics and Key PerformanceIndicators to measure areas related to the volume ofincidents, impact on work activities, duration required tosolve these incidents, involvement of vendors or third-parties in solving these incidents

Define Reporting procedures and roles to addressoutcomes of analyzing the metrics

Produce weekly reports to capture these metrics

Take corrective actions and act upon the reports outcome

5.3.4. Relationship with Other Processes

Problem Management Process has main interactions with other ITIL processes such as:




Service Level Management Process (Including Capacity and Availability)


Table 14 Problem Management Relationship with Other Processes

Process NameRelationship with Problem Management

Process

Incident Management (As described in Table 10 above)


42/63




Process

Change Management For solutions identified for problems or knownerrors, Change Management process must befollowed through the issuance of RFC and

obtaining the approval of CAB

Change Management should coordinate withProblem Management in RFC issuance andassessment in relation to problem work aroundsand permanent solutions identified.

Change Management providing full support toProblem Management on Major IncidentsResolution

Change Management involvement of ProblemManagement in CAB for RFCs related to

Problems. Change Management must includeall this info in FSC

In relation to changes based on ProblemManagement identified workarounds andpermanent solutions, Change Management andProblem Management need to agree on therollback changes needed if the Changes are notsuccessful

Change Management must advise ProblemManagement workers and specialists on thesuitable approach and procedure to follow in

handling changes related to Problems earlieridentified

Configuration Management Problem Management need to report toConfiguration Management trend analysisresults on CIs reviewed

As an outcome of trend analysis and if there isan identified unauthorized change, ProblemManagement need to report to ChangeManagement and Configuration Managementany inconsistency in CI state

For certain CIs (Based on classification),provide reports to Problem Management on the

number of changes due to faults for certainperiods. This will enable Problem Managementto carry some trend analysis activities


43/63




Process

Service Level Management Problem Management should inform SLM forOLAs breaches with Support Groups

Problem Management should inform SLM forneeds in improving OLAs

Problem Management should provide SLM withhistorical trends and statistical data to help itanalyze quality of service for all IT servicesprovided by IT to its customers

Problem Management should inform SLM onMajor Incidents to properly assess the impact onthe business

SLM need to ensure that service requirementsand updates on requirements arecommunicated to Problem Management toreflect the required priority.

SLM need to ensure that ProblemManagement%s inputs/recommendations onvendor services are communicated to them foradherence and implementation. This will notonly help to improve their services but alsoprevent further incidents/problems

SLM should ensure that business priority iscorrectly reflected by the prioritization and

category classification process used by ProblemManagement

SLM should provide inputs during problemreview meetings from SLM perspective toenable Problem Management improve itsprocess.

Based on Service Level targets defined in SLAs,Availability and Capacity ManagementProcesses should be proactively involved inidentifying problems and advising ProblemManagement Process accordingly

5.4. Change Management Process


In relation to the IT infrastructure, the ability to determine the need to the change versusthe impact of the change on the current operation and services provided is a questionwhere IT Departments should be concerned with all the time. Following a best practice inthis area might not be as straight as other processes, but ITIL do recommend a practicalapproach for Change Management and controlling the diverse impact on the

infrastructure.


44/63



Changes arise due to different reasons. Some of the reasons are concerned withrectifying a problem but also due to business or organizational requirements concernedwith enhancing the quality of the current services or introducing new ones.

Assessment of the changes requested needs to cover various angles such as:

Risk Assessment on Business Continuity

Change impact on current operation

Resource requirements

Change approval cycle

Change Management is covers all aspects of IT infrastructure. This includes all hardware,all software (OS & applications), and all related documentation.

Change Management has a decision authority invested in what is called a ChangeAdvisory Board (CAB). The CAB usually meets at predefined short intervals (once a weekfor example), and review all submitted Request for Changes (RFCs). The CAB need tomeasure aspects related to the impact, cost, and resource requirements of the change.

CAB members will usually constitute of permanent and non-permanent members.Permanent members will include the Change Process Owner and Manager, ConfigurationProcess Owner and Manager, Service Level Management Process representative. Non-permanent members (upon invitation) will constitute of Change Requester (Business sideCustomers), representative of the IT Operational, and Vendors (if necessary), and ServiceDesk representative if the change involve an IT Service that is supported by the ServiceDesk.

Some changes will not require a CAB decision to determine and evaluate the changerequest (example: upgrading a MS Office application or changing an IP address on aDesktop). As a result, Change Management conducts classifications of changes asfollows:

Standard Changes: When the impact and cost and required resource involvementis known and predetermined, usually the changes will be classified as standard.The standard changes do not require CAB approval, but all standard changesrequests and actions must be documented for future reference. Typically, theowner of implementing the standard changes is the Service Desk Function

Non-Standard Changes: The Non-standard changes require CAB involvement.CAB will additionally invite the different stakeholders involved in the change to themeeting either permanent or non-permanent. CAB will assess the impact and costand check for change requirements such as implementation plans and back-out(roll-back) plans

Urgent Changes: Urgent Changes is a subcategory of Non-Standard changes andare changes that cannot wait for the standard cycle of change approval. Usually,IT will define a procedure to follow for urgent changes and will clearly require astrict documentation of the request and the implementation activities

5.4.2. Benefits of Change Management Process Implementation

Change Management Process should strive to become an efficient and effective process.Efficient Change Management will ensure proper decisions are made and no errors resultfrom carrying the change. Effective Change Management focuses on ability to conduct thechanges in a timely and satisfactory manner no matter how high the number of changes is

required.


45/63



The benefits of implementing an effective and efficient Change Management Process willinclude:

Controlled expectations of organizational and business requirements in relation toquality of service, associated risks, and cost control of changes

Alignment of expectations related to Service Level Management and SLAs

adherence

Better Service Availability as a result of effective change management. Thistranslates in better and increased user productivity

Optimization of IT resources in relation to changes and time required forinvolvement

Business is happy and Customers are satisfied


Below table summarizes the activities of the Change Management Process. It should benoted here that as Change Management tend to be a more mature process in any ITDepartment due the nature of introducing necessary controls to the infrastructure, ITILprovides a practical approach in defining the process activities.

Table 15 Change Management Process Activities


Logging and Filtration

of RFCs(This process could bemanual through formssubmittal via emails orsystemized through aworkflow tool)

Ensure completeness of RFCs forms submitted.

Information should cover description of the change,impacted infrastructure and business areas, time requiredto implement the change, availability of back-out plans,resources required to implement the change

Based on the completed information, decide if the changeis practical to implement as specified (Time windowallocated is sufficient, resource requirements areadequate, and impact is assessed right)

Give the requester of change the right to discuss andappeal outcome of this activity

Priority Allocation Assess impact of the change activities on the workactivities and the urgency required to implement the

change

Based on the assessment assign a priority to the change.Priorities to include: Immediate, High, Medium, and Low

Categorization Categorize the changes based on the priority defined.Categorization can include: Minor Impact Only, SignificantImpact, or Major Impact

Prepare all information and include it in CAB meetingschedule


46/63




Assessment Analyze the RFC in relation to:

o Impact identified in relation to work activities

o Impact on service levels as defined in SLAs

o Is there an extended impact to other services?

o Is there an extended impact beyond relatedServices? (example: service desk, powerrequirements, etc.)

o What happens if we do not implement the change?

o Are cost and resource requirements correct?

o What are the other RFCs requested? Can it fit inthis round of scheduled changes

Approval Based on the assessment of the RFC and other related

criteria defined in the assessment, CAB will decide on thego ahead of implementing the change. If the CAB refusedthe change, sufficient reasons must be provided to therequester

Scheduling Coordinate with Release Management Process on thechange implementation. Release must oversee and alignall the building, testing, and implementing of the change

Review (PIR) Release Management must advise Change Managementof the Post Implementation Review (PIR) results includingall issues faced during the change, lessons learned, real

impact, and measured outcome

Logging & FilteringRFC

Building

Priority Allocation

Categorization

Approval

Scheduling

Coordination

w/ ReleaseMgmt.

Assessment

Testing

Implement

Review (PIR)

Change ManagementProcess

Figure 15 Change Management Process Activities


47/63



5.4.4. Relationship with Other Processes

Change Management Process has main interactions with other ITIL processes such as:




Release Management Process

Service Level Management Process


Table 16 Change Management Relationship with Other Processes

Process Name Relationship with Change Management Process

Incident Management (As described in Table 10 above)

Problem Management (As described in Table 14 above)

Configuration Management To determine proper infrastructure component,Change Management must refer toConfiguration Management in the RFC filteringand logging

Configuration Management must advise ChangeManagement on the latest status of theinfrastructure component and if there are anychanges

Configuration Management must approve theassessment of the change to the infrastructurecomponent

Through Release Management, ConfigurationManagement must ensure that the new attributeto the infrastructure component is up-to-dateand reflected in the PIR and CMDB

Release Management Must work closely with Change Managementand coordinate the building, testing, andimplementation of the change

Must provide Change Management with the PIRreport and highlight any implementation issue

Service Level Management Must advise Change Management on the workimpact of the change as defined in the SLAs

Must approve the change impacts as defined inthe RFC

Change Management must advise if the changeimplementation has impacted or violated anyservice levels agreed


48/63



5.5. Release Management Process


Release Management Process plays a significant role in conjunction of and in relation to

two other ITIL Processes: Change Management and Configuration Management. ReleaseManagement is an essential process to Change when the implementation is required. It isalso important to Configuration to ensure that the infrastructure components are up-to-date and reflect the reality of the situation.

Release Management Process also focuses on two essential elements to the ITInfrastructure: Definitive Software Library (DSL) and Definitive Hardware Store (DHS).DSL and DHS are physical repositories that store software and hardware elementsnecessary for the IT Operation. DHS is less feasible as many of the IT Operations rely onvendors in handling their inventories and spares of hardware. DSL is more controlled andenforced due to mainly local rules and regulations related to copy and intellectual rights.

5.5.2. Benefits of Release Management Process Implementation

The benefits of Release Management can be obtained only with proper coordination withChange and Configuration Management. The benefits include:

Quality of Service assurance to the organization through proper control of softwareand hardware releases

Ensure the quality of the software and hardware used in the live operation of ITinfrastructure

Providing the organization with a stable testing environment through proper

controls

Optimizing IT resource involvement in software and hardware releases

Maintains a clear and traceable record of changes to the live environment

Help Change Management process to become efficient and effective process

Ensure accuracy of infrastructure components and their configuration for theConfiguration Management Process

Control copy and intellectual rights and eliminate infringements

Customer surprises are minimized in relation to expected releases of software andhardware under use


Release Management activities rely on authorized RFCs from Change Management andother inputs mainly related to Project Management implementations. The general processactivities include:


49/63



Table 17 Release

best practices for it processes en

Documents