IT PROCESSES BEST PRACTICES FOR. Version 1.0 Date: 04/06/2007

(1)

The Saudi e-Government Program (Yesser) has exerted its best effort to achieve the quality, reliability, and accuracy of the

B

EST

P

RACTICES FOR

IT

P

ROCESSES

Version 1.0 Date: 04/06/2007

(2)

List of Tables

Table 1 – ITIL Definitions of Customers & Users ... 12

Table 2 – Focus of Service Delivery and Service Support Processes... 13

Table 3 – General ITIL Readiness Questionnaire... 22

Table 4 – Incident Management Process Questionnaire ... 23

Table 5 – Problem Management Process Questionnaire... 24

Table 6 – Change Management Process Questionnaire ... 25

Table 7 – Release Management Process Questionnaire... 26

Table 8 – Service Level Management Process Questionnaire... 27

Table 9 – Incident Management Process Activities... 31

Table 10 – Incident Management Relationship with Other Processes ... 34

Table 11 – Problem Control Activities... 39

Table 12 – Error Control Activities... 40

Table 13 – Proactive Problem Management Activities... 41

Table 14 – Problem Management Relationship with Other Processes... 41

Table 15 – Change Management Process Activities... 45

Table 16 – Change Management Relationship with Other Processes ... 47

Table 17 – Release Management Process Activities... 49

Table 18 – Release Management Relationship with Other Processes... 50

Table 19 – Service Level Management Process Activities... 53

Table 20 – Service Level Management Relationship with Other Processes ... 54

Table 21 – Sample ITIL Processes KPIs ... 56

Table 22 – Glossary of ITIL Terms ... 59

List of Figures

Figure 1 – Towards a Value Center IT Department ... 7

Figure 2 – Service Offering & Infrastructure Stability ... 8

Figure 3 – Process Flow and Mapping in Organizational Unit ... 9

Figure 4 – Modeling of Generic Process ... 9

Figure 5 – IT Service Management Alignment Pillars ... 10

Figure 6 – Service Delivery Set & Service Support Set ... 11

Figure 7 – Service Delivery & Service Support Domains ... 12

Figure 8 – ITIL Process Priorities in $1 billion-plus Companies ... 17

Figure 9 – Sample ITIL Implementation / Enhancement Roadmap... 18

Figure 10 – Organization Size Consideration – Conflict Avoiding ... 19

Figure 11 – ITIL Process Maturity Indicators ... 28

Figure 12 – Incident Management Process Lifecycle... 33

Figure 13 – Problem Control Activities ... 39

Figure 14 – Error Control Activities ... 40

Figure 15 – Change Management Process Activities ... 46

Figure 16 – Release Management Process Activities... 50

Figure 17 – Service Level Management Process Activities ... 54

(4)

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 will be further developed and regularly reviewed to ensure that it continues to serve the IT department needs in the government.

1.1. Purpose

The purpose of this document is to suggest guidelines for IT managers in implementing IT Processes as part of the IT department operational readiness for Service delivery and support. The principles and concepts used in this document are to enable IT departments to 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 the implementation of IT Processes. Actual implementation needs to be managed under the umbrella of a project and a dedicated project team need to undertake the responsibilities of 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 easily obtained based on the reader specific interest. This document contains two main sections and three appendixes:

1. Enablers for IT Processes: This section provides an overview of the underlying concepts that enable for the proper adoption of IT processes within the IT Departments. 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 of required services

d. Definition of a Process and Alignment Requirements e. Overview of ITIL Best Practices

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

3. Appendixes:

a. In Appendix I, a Saudi Governmental IT Department case study is built and elaborated 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 IT

(5)

Management, Change Management, Release Management, and Service Level Management

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

(6)

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 Service

Management” is generally needed in IT Organizations.

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

Traditionally, IT organizations mainly focused on the technology and less on processes that 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 (other examples include: Total Quality Management (TQM), Six Sigma, Business Process Management, and other), many frameworks have been developed to contribute to the discipline. 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 specific focus to enhance the discipline. This includes organizations like IT Service Management Forum (itSMF), International Organization for Standardization with Audit Standard ISO 20000, and the British Standard Institute with BS15000. Currently, BS15000 is being phased 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 IT Departments and due to the need of introducing the concepts of e-services started to adopt a service oriented organizational model to enable for better customer / public support.

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

(7)

Cost Center ü«IT Manager» type CIO üFocus on Technologies

Service Center

Value Center üIT as a Service Provider

üOptimization & Alignment of technologies, organization & processes

üContinuously showing value of IT to business

ü IT is a «Business Enabler» ü IT Manager assumes the role of a CIO (covering company organization, quality, risks management 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 the operational 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 provided traditional 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, and other systems.

New challenges for IT infrastructure assurance and stability had risen when critical services mainly related to external customers (the public for example) started demanding better commitments, availability, and high flexibility in service offering. The challenge

(8)

became even bigger when these critical services started contributing heavily to the organizations revenue.

IT Service Management came to address these service expectations in areas related to: § Service Level Commitments through agreed Service Level Agreements (SLAs) § Capacity and Availability Planning to optimize the resources and ensures

maximum availability of services to customers and users

§ Proper control of changes to the IT infrastructure including impact analysis, cost, and roll-back or back-outs

§ Commitments on service interruption windows based on the service criticality and priority of the service

Eventually, IT Departments (being IT Service Providers) started recognizing that part of the IT infrastructure stability, there should be a set of processes and procedures. When implemented, these processes and procedures opened the door for providing flexibility and extendibility in service offering.

Business Defines Service Requirements IT Infrastructure IT Infrastructure IT Operation IT Operation Service Service Business Business Business Expects IT Operation & Infra. to be flexible in providing

required services

IT aligns with Service requirements through

processes

IT Defines Infrastructure Stability based on Service

Offering Flexibility

Figure 2 – Service Offering & Infrastructure Stability

2.4. Definition of a Process and Alignment Requirements

ITIL Best Practice Defines a process as:

“a connected series of actions, activities, changes etc, performed by agents with the intent of satisfying a purpose or achieving a goal.”1

Process nature entails a cross-functional (organizational units) flow where the roles and resources engage in the process activities to satisfy a predefined output.

Once the inputs are identified and the outputs are predetermined, there should be a process control mechanism to achieve:

§ An effective process (process is consistent, can be repeated, measured, and managed)

§ An efficient process (process activities can be conducted with minimal efforts)

1

(9)

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

Figure 3 – Process Flow and Mapping in Organizational Unit 2

Figure 4 – Modeling of Generic Process 3

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

2

3

(10)

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

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

§ Processes Alignment: Within IT departments, processes are usually defined to follow business requirements and expectation of the IT. Within the context of government, 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 that need to be investigated for ITIL alignment:

o Existing IT organizational structure: Up to recent years, IT organizational structure was typically oriented about the technologies provided. Service Oriented structure requires the IT Department to build a structure that is fully aligned with the services provided, team capabilities defined, and IT capacity requirements (Number of users to support, sites, criticality, etc.) o Team Capabilities: Team capabilities should be based on the profile of

services defined. If the organization is adopting a certain technology (Example: Microsoft Oriented technologies, or SUN oriented, an ERP solution, etc.) the team capabilities should reflect knowledge and skills in that area

o Team Capacity: Team Capacity is derived from the type and level of support required. If the IT organization is needed to function at multiple locations or different work schedules, the team capacity needs to reflect that Services Technology

ITSM

Alignment

Organisation Process

(11)

2.5. Overview of ITIL Best Practices

IT Infrastructure Library (ITIL) framework puts IT Service Management concepts in practice. ITIL was initially developed in the late 1980’s by the UK government and since then has been pervasive within IT Organizations across the world. Many organizations believed 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 best fit is accomplished through defining a model where process goals, activities, inputs and outputs can streamline and align the existing operational activities of the IT Department. Since inception, ITIL development was driven by a quality approach that emphasizes the expectation needs of the business and the relationship that should govern it. Quality of Service and Customer focus played a major role in defining processes goals and the related activities.

ITIL consists of two sets of processes: Tactical processes that cover Service Delivery set and 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 activities is the utilization of Incident Management Process.

Service Level Management Financial Management for IT services Capacity Management IT Service Continuity Management Incident

Management Problem Management

Change Management Configuration Management Release Management IT Infrastructure IT Infrastructure IT Infrastructure IT Infrastructure sec ur ity sec ur ity Service Desk Service Desk Availability Management

Figure 6 – Service Delivery Set & Service Support Set 4

4

(12)

In principle, Service Support processes are concerned with the day-to-day operational support activities, while Service Delivery processes cover the tactical and planning aspect of the IT Operation. “IT” “The Business” Users Service Desk Customers Service Level Management Operational Tactical Sr. IT Mgt Sr. Mgt

Strategic Delivery_Delivery_DeliveryService Service Service Service Delivery Service Service Delivery Delivery Service Support Service Service Support Support Service Support Service Service Support Support

Figure 7 – Service Delivery & Service Support Domains

It is worth noting that ITIL does distinguish between the terms “Users” and “Customers”. Customers from ITIL point-of-view are the people who define, approve, and pay for the IT services, while Users are the people who use the service in their daily work activities. Customers are usually interfacing with Service Level Management while Users interface

with Service Desk. Below table provides the difference of “Customers” & “Users” notions

from ITIL point-of-view.

Table 1 – ITIL Definitions of Customers & Users

Customer User

Customer is the organization party who will define the scope of the service and the expected service levels. Customer will also be the party responsible for the cost of the service

Users are the persons who will use the service on daily basis

Below table provides the focus of each of Service Delivery and Service Support Processes:

(13)

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 Level Agreements (SLA)

Customers focus in term of communication and managing expectations while SLAs on the negotiation, agreement, and review Financial Management for IT

Services

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 of elements (HW/SW, People, etc.), categories (Capex / Opex, Direct / Indirect, etc.), and models (Customer and Service)

Charging focuses on the charging policies defined by the business and it is usually outside the scope of

governmental IT Departments

Capacity Management Focuses on IT Infrastructure Capacity

planning covering dimensions of business, service, and resource. Main activities cover modeling and

infrastructure resource sizing

IT Service Continuity Management Considered as part of Business

Continuity and Disaster Recovery Planning. Focuses on the unexpected issues arising due to IT resources unavailability. Takes into consideration risk management and testing of the plans

Service Delivery

Availability Management Focuses on the expected issues that can

potentially arise from IT resources unavailability. Addresses risk management and mitigation and introduces concepts related to availability, reliability, maintainability, serviceability, and security of the IT infrastructure

Service Support

Incident Management Focuses on the unplanned interruptions

of the services. Addresses issues of ownership, detection, classification, diagnostic, escalation, and resolution and recovery of the services

(14)

Type Process Name Process Focus

Problem Management Looks for the root causes for incidents

and focuses on reactive, proactive, and reviews of the problems

Configuration Management Focuses on the components of the

infrastructure and the relationship that governs them. Has specific concepts related to storing of software (DSL – Definitive Software Library) and hardware (DHS – Definitive Hardware Store)

Change Management Focuses on controlling and classification

of the changes introduced to the IT infrastructure. Addresses concepts like RFC (Request for Change), CAB (Change Advisory Board)

Release Management Focuses on controlling the changes

through planning, testing, and implementation

(15)

3. Processes Implementation

Considerations

3.1. Introduction

The considerations proposed in this section take into account the type of governmental organization entities the IT Department is functioning in. IT should be noted that the underlying success factors in ITIL implementation does not differ by the type of organization IT Departments functions under. The considerations below need to be adopted 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 IT Department, it is necessary to establish a documented baseline of:

§ All identified services. IT Department will need to conduct a strategic exercise with the Management of the governmental organization in which the result will be to identify and define the services that is required to be offered. Cost of implementation should be weighed against defined benefits. It should be noted that Service chargeability is the only dimension of the exercise that will not be relevant to the overwhelming majority of IT Departments in the government of Saudi 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 will be a must if the full scale implementation will take place: Service Desk Function and 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 addressed before commencing with the ITIL implementation. These gaps should be handled in the form of recommendations and must be implemented separately. Sometimes, the recommendation implementation will be considered as a transitional phase of the ITIL implementation, and many successful implementations depend on the outcome of this intermediary phase.

(16)

3.4. Process Prioritization

Upon closing the identified gaps from the base lining exercise, there will be a prioritization exercise related to the processes that need to be implemented first. The prioritization exercise 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 needed scope of processes

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

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

§ We can always start with Service Level Management as it really defines the depth all 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 after Incident Management Process reaches a certain maturity. Due to the conflicting nature of Problem Management and Desk and Incident Management, the process should not be governed by the same functional entity

§ Service Delivery Processes (other than Service Level Management) can be implemented after Service Support Processes. However, the part related to defining acceptable capacities and availability has to be undertaken by Service Level Management

In a published whitepaper by Forrester Research in October 20055, 19 IT Managers at $ 1

billion-plus companies indicated that Incident Management, Change Management, and Service Level Management fall in the top 5 priority ITIL processes in term of importance and need to their operation. Additionally and within the top five ranks, other processes included Configuration Management and Availability Management.

5

(17)

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 rely on the type of organization IT Departments functions under. The priority of process implementation relay on the maturity and readiness of the IT Department to adopt the assessed 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 business case, Detailed Project Plan, Detailed Communication Plan, allocate dedicated resources to the project, and requesting clear milestones and achievements. The concept of Quick Wins must also be identified and defined at this stage. Quick wins are all improvements that are perceived and acknowledged by the customer during the early phases of the ITIL implementation. To the ITIL implementation team, quick wins are all milestones that can help in achieving preset goals during the early implementation project.

A clear implementation roadmap must be developed and approved by the organization management and not only IT management. The defined roadmap need to take into consideration the four areas of IT Service Management Alignment: Service, Process, Organization, and Technology. Below figure represents a sample roadmap.

6

(18)

Initia-tive Enhancements Priority

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 processes integration

P1 Change , Release and project management _{O1, O5, T1, T3}

P2 Incident and configuration management O1, O5, T1

P3 Configuration and Service level

management O1, 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

T3 Server management O1, P6

T4 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 in Telecom 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 the right people throughout the project implementation. Proper buy-in and commitments to the goals of the project has to be ensured continuously.

The success of ITIL Projects implementation will depend on the people dimension and their 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 the implementation will never by realized.

3.7. Organization Size Considerations

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

(19)

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

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

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

Organizational departments

P

ro

c

es

s

es

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 IT management 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 and should 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 if

the implementation timeline is realistic and can be achieved with the defined timeframe

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

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

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

7. IT Managers should ensure that the proper authorities are given to the process owners 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 current successful practices of the IT Department

(20)

9. Does the IT Department Operation rely on any outsourcing activities? If yes, the third party must be included in the activities related to the implementation and they need 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. Send

the staff to seminars and conferences that increase their appreciation of becoming part of a service culture that focuses on customer satisfaction

11. 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 to process activities. If this dimension is missed, functional responsibilities will always take precedence. Hence, proper accountability metrics are to be introduced to all levels of process roles and responsibilities

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

(21)

4. Appendix I – ITIL Process Assessment

Exercise – Saudi Governmental IT

Department Case Study

4.1. Context

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

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

§ Measure the IT Department interest and reaction to the concept of implementing ITIL Processes

§ Identify pain areas that raise challenges to the IT Department in their daily operation 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 not luxuries that can be done without

§ Address global cultural concerns that will raise challenges to successful implementation 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 are designed as such that the first three questions carry the highest weight (mandatory to have) in order to realize or satisfy the required maturity.

(22)

4.2.1. General ITIL Readiness

Table 3 – General ITIL Readiness Questionnaire

Assessment Area Assessment Questions

General ITIL Readiness

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

§ Do you provide management with information

concerning operational performance (including

analyses) of the different processes?

§ Are there standard reports regularly produced (operational reports, KPI's and service performance)? § Does the department comprehend how the

IT-services add to the business?

§ Has the purpose and benefits of the different processes been advertised within the organization? § Is the IT-staff trained on ITIL, standards and all related

procedures?

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

§ Are all links between the processes identified and operational? (E.g. information between processes which is exchanged, procedures, involvement)

§ Are your processes supported by a service management/helpdesk tool?

(23)

4.2.2. Incident Management Process

Table 4 – Incident Management Process Questionnaire

Incident Management Process

§ Are incident records maintained for all reported incidents?

§ Are all incidents managed in conformance with the procedures documented in SLAs?

§ Is there a procedure for classifying incidents, with a detailed set of classification, prioritization and impact codes?

§ Is there a procedure for assigning, monitoring and communicating the progress of incidents?

§ Does incident management provide the Service Desk or Customer/User with progress updates on the status of incidents?

§ Is there a procedure for the closure of incidents? § Does incident management match incidents against

the problem and known error database?

§ Are Service Level Agreements available and understood by incident management?

§ Are requests for changes produced, if necessary, for incident resolution?

§ Are resolved and closed incident records updated and clearly communicated to the Service Desk, customers and other parties?

§ Do you provide management with information concerning escalated incidents?

§ Have the interfaces between the Service Desk and

incident management been defined and

communicated?

§ Does incident management exchange information with Problem Management concerning related problems and / or known errors?

(24)

4.2.3. Problem Management Process

Table 5 – Problem Management Process Questionnaire

Problem Management Process

§ Is there a procedure for problem management? (Concerning analyzing significant, recurring and unresolved incidents and identifying underlying problems, classification of potential problems, in terms of category, urgency, priority and impact and assigned for investigation?)

§ Are at least some problem management activities

established in the organization, e.g. problem

determination, problem analysis, problem resolution? § Have responsibilities for various problem management

activities been assigned?

§ Is the nature of the problem always documented as part of the problem record?

§ Is Problem Management responsible for the completeness of all problem records?

§ Are the standards and other quality criteria made explicit and applied to problem management activities? § Does Problem Management provide management with information concerning recurring problems of a particular type or with an individual item?

(25)

4.2.4. Change Management Process

Table 6 – Change Management Process Questionnaire

Change Management Process

§ Are at least some change management activities established in the organization, e.g. logging of change requests, change assessments, change planning, change implementation reviews?

§ Have responsibilities for various change management activities been assigned?

§ Are the procedures for initiating change always adhered to?

§ Is there a procedure for approving, verifying and scheduling changes?

§ Are all changes initiated through the agreed change management channels, for example a Change Advisory Board?

§ Are changes planned and prioritized, centrally or by common agreement?

§ Are formal change records maintained?

§ Is a change schedule of approved changes routinely issued?

§ Are there standards and other quality criteria for the documentation of change made explicit and applied? § Does Change Management provide pertinent

information concerning the change schedule?

§ Does Change Management exchange information with Configuration Management regarding change progress and change closure?

(26)

4.2.5. Release Management Process

Table 7 – Release Management Process Questionnaire

Release Management Process

§ Are explicit guidelines available on how to manage

release configurations, naming and numbering

conventions and changes to them?

§ Does Release Management verify information concerning the release? (Like number of major and minor releases within a given period, number of new, changed and deleted objects introduced by each release, the number of problems in the live environment attributable to new releases)

§ Are at least some release management activities established within the organization, e.g. procedures for the release and distribution of software?

§ Have roles and responsibilities for various release management activities been assigned between operational groups and development teams?

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

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

§ Are there formal procedures available for release acceptance testing?

§ Are all CI's within a release traceable, secure and do procedures ensure that only correct, authorized and tested versions are installed?

§ Are plans produced for each Release?

§ Are back-out plans produced for each Release?

§ Are test plans, acceptance criteria and test results produced for each Release?

§ Is there a library containing master copies of all controlled software within the organization?

§ Are the standards and other quality criteria for release management made explicit and applied?

§ Does Release Management exchange information with Change Management concerning change records for any new / changed CIs?

(27)

4.2.6. Service Level Management Process

Table 8 – Service Level Management Process Questionnaire

Service Level Management Process

§ Do you check with the customer if the activities performed by the IT department adequately support their business needs?

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

§ Are you actively monitoring trends in customer satisfaction?

§ Are you feeding customer survey information into the service 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 management activities been assigned?

§ Has a catalogue of existing services been compiled? § Are there mechanisms for monitoring and reviewing

existing service levels?

§ Do you compare service provision with the agreed service levels?

§ Are the standards and other quality criteria for SLM documented?

§ Do you provide management with information concerning trends in service level breaches?

4.3. Process Maturity Indicators

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

(28)

Automation

Complete control Structures. Performance analysis

Policies, procedures & standards defined. Corporate Knowledge Quality People Defined Tasks Undefined tasks. Relies on Initiation Improved feedback

into the Process Measured Process

(Quantitative)

Process defined & Institutionalized (Quantitative) Process Dependant on Individuals (Intuitive) Ad Hoc/Chaotic

Optimized

Managed And Measurable

Defined

Process

Initial /

Ad Hoc

Repeatable

But

Intuitive

P

ro

c

e

s

E

v

o

lu

ti

on

P

ro

c

e

s

E

v

o

lu

ti

on

PROCESS MATURITY CHARACTERISTIC ACHIEVEMENT METHOD

5

4

3

1

2 No Method

Complete Lack Of Process Values And Awareness

Non

Existent

0

(29)

5. Appendix II – Guideline for IT Processes

5.1. Introduction

In this section, the guideline addresses a selected set of ITIL processes to be considered for implementation by IT Departments in the Government of Saudi Arabia. The set of ITIL processes 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 the following 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 best practices. The objective is to give a practical dimension for the IT Manager when considering 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 success is 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 need to be aware (through the structure of the Service Desk or IT Helpdesk function) on the issue. In the usual scenario, the user will contact the Service Desk to report the issues he has.

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

(30)

“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.”7

The term “Incident” also encompasses certain requests for services or adding additional

service (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 performing “work” activities (There is a specialized group who will handle the user reported incident effectively and efficiently)

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

§ Users of IT set expectations for the right service levels needed (A proactive way for IT to determine the service level agreements that will be defined with other entities including the Customers of the service and all IT providers of the service) For providers of IT Services, Incident Management Process gives them the following advantages:

§ A mechanism to control Users and Customers satisfaction by providing a systematic way of handling the reported incidents (IT will usually assign a ticket number and provide regular updates on the status of the incident resolution activities)

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

§ Ensures a better control of the expected performance of the infrastructure. Incident Management will be a control mechanism that enable for effectively optimization of the 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 customer interacting as much as IT interacting. The generic process activities are defined as follows:

7

(31)

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 the Incident Management Process Tool. Thresholds will be defined on the monitoring tools to trigger and identify an incident before and when it happens.

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

Incident Detection and Recording

(Ideally, incident

detection and recording will be done with the help 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 the symptoms reported

§ Map the reported information and symptoms to the right infrastructure component

§ Ability to identify the right support group or team will be assigned to solve

Classification & Initial Support

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

§ Determine if the identified component details (as described by the User) are accurate as per the Configuration Management Database or the available definition of the component

§ Ability to match the incident with previously similar solved incidents through referencing to Problem and Known errors databases. This activity will enable to identify any work around or solution that can be used to solve the incident

§ Conduct initial support activities to apply the solution or work-around if available (if the Service Desk is classified as a Skilled Service Desk) or assign the ticket to the proper support group who can attempt to solve the incident

Investigation and Diagnosis

Investigation and diagnosis activities focus on assessing the incident details as identified and recorded by the previous steps in the process. Accuracy of information will be determined in this step.

(32)

Activity Name Main Activity Tasks / Actions Resolution and

Recovery

Resolution and Recovery activities either:

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

§ Raise a Request for Change (to Change Management Process) to apply the identified solution to solve the incident

Incident Closure Incident closure activities concerned with:

§ Customer / User confirmation that the incident has been resolved and normal work activities are restored

§ Ensuring that the incident ticket (record) is updated correctly with the closure information such as the type of solution applied, the effort put or time spent to solve the incident, and the support group details

It should be noted here that incident closure should be a “restricted” activity. Restricted in relation to ability of the support group or service desk to close the incident without proper approvals of the incident originator (user or customer). Only the incident originator is the one who should be allowed to close the ticket.

Ownership, Monitoring, Tracking, and

Communication

This activity plays the role of Quality Control of the other process activities described above. The main actions in this activity focus on:

§ Monitoring the incident in term of current status and adherence to service levels

§ Escalate the incidents if needed (if service level breaches exists – example: support group exceeded allowed time to solve 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 the Service 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)

Figure 12 – Incident Management Process Lifecycle8

5.2.4. Relationship with Other Processes

Incident Management Process and related activities of the Service Desk Function have main interactions with four other ITIL processes:

§ Problem Management Process § Change Management Process § Configuration Management Process § Service Level Management Process

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

8

(34)

Table 10 – Incident Management Relationship with Other Processes

Process Name Relationship with Incident Management Process

Problem Management § Service Desk / Incident Management relies

heavily on Problem and Known-Error Database controlled by Problem Management

§ Service Desk / Incident Management work to escalate major incidents that cannot be addressed or fall outside their scope § Service Desk / Incident Management must

ensure a proper record and information to enable Problem Management to conduct trend analysis activities

§ Problem Management ensures proper access to the Problem and Known-Error Database

§ Problem Management provides Incident Management with permanent solutions § Problem Management advise Incident

Management to close related incident tickets that was identified and grouped with similar underlying cause of error

(35)

Change Management § Service Desk / Incident Management should

ensure all RFCs, Standard Changes, and non-standard changes routed through Helpdesk follows the Change Management process § Helpdesk should communicate to the customer

service interruptions based on the Forward Schedule of Changes (FSC)

§ Based on the available list of changes (standard and non-standard) Service Desk to report back to Change Management the impact of Changes carried through customer feedback (related incidents opened)

§ Helpdesk should report to Change Management incidents 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 be managed thru Helpdesk

§ Service Desk needs to manage Standard Changes directly

§ Change Management must update the Helpdesk with the status for RFCs status: Completed, in progress, unsuccessful, rollback, etc.

§ The Scheduled Forward Schedule of Changes (FSC) provided by CAB must be communicated and shared. The objective is to enable the Helpdesk to respond properly to customer queries related to service disruption resulting from scheduled changes

(36)

Configuration Management § Service Desk / Incident Management should

ensure incident tickets are logged accurately against the right CIs. This will ensure that trend analysis activities (Problem Management) and Change Management address CI changes based on these incidents

§ To help identify unauthorized changes, Service Desk / Incident Management need to identify and report to Change Management and

Configuration Management any inconsistency in CI description based on the inputs provided related to incidents

§ To enable Service Desk to give correct classification and prioritization of incidents reported, CIs description must be mapped directly to the CMDB.

§ To enable Service Desk to better manage changes (Standard and non-Standard, mapping of CIs is required)

§ To enable Service Desk to report unauthorized changes, mapping of CIs is required

(37)

Service Level Management § Service Desk and Incident Management need to

provide SLM with OLA requirements for process activities involving 2nd and 3rd line of Support § Incident Management need to provide SLM with

pre-agreed reports related to Service Level Breaches (SLA violations)

§ Service Level Management need to provide Service Desk / Incident Management with an IT Service Catalog in which:

o Business inputs are provided for services description, functions and systems attached to services, service impact, expected service levels, SLAs, and costing

o SLM need to advise Incident

Management on each service priority provided in the IT Service Catalog. The breakdown of priority should be based on Service functionalities. Example: ICMS billing functionality, Email Send functionality, etc. This will enable Service Desk to tie the service to the right

response and resolution times o SLM need to update Incident

Management with SLA changes that impacts service priority

§ SLM must build OLAs based on inputs from Service Desk and Incident Management for process related activities that involves outside parties (Example: Support Groups, vendors (UCs))

5.3. Problem Management Process

5.3.1. Introduction to the Process

Other to the incidents that are caused by the user lack of training or knowledge (which should be identified through trend analysis activities by the Service Desk Function and provided to management by a report), there are incidents that are caused by a common cause or error in the infrastructure.

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

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

(38)

solved through the Incident Management Process. The major incidents usually will have the criteria of impacting a number of users or carry an adverse impact on the work activities beyond a single user. Proactive Problem Management works to control the occurrence 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 extended maturity level that Incident Management Process will have high difficulty to reach. Similar to Incident Management Process, the benefits of Problem Management Process can be seen at both sides of the organization (Users of the IT Services and Providers of the IT Services (IT Department)). Major benefits achieved include:

§ Better perception of the IT as a service provider due to ability to control the number 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 and providing access to tools such as Known Error and Problem Database and Knowledge Bases

5.3.3. General Process Activities

Problem Management Process has three sets of activities within its scope of work. These three sets are classified in relation to the reactive mode and proactive mode. The reactive mode 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 Management Process, the process will aim at identifying if the problem reported is a known-error. If it is an unknown-error, then what is called Problem Control activities take over and the Problem Management Process will work to analyze the problem and identify the root cause of it until it becomes a known-error. A known-error will be classified as problem that can be solved either through a work-around or a permanent solution and the Error Control activities will take over. Hence, distinctively, Reactive mode constitutes of: Problem Control and Error Control.

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

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

(39)

Table 11 – Problem Control Activities

Problem Identification and Recording

(In addition to Problem Management Process, this step can be performed by

processes like Capacity Management,

Availability

Management, and of course Incident Management)

Analyze the escalated incident:

§ Query Known-Error database to find a match for the reported problem, if not successful

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

§ Open a new problem record and record the details based on the incident description and related support activities conducted thus far

§ allocate the problem to problem management team

Problem Classification Similar steps to Incident classification and covers aspects and

information related to: § categorization

§ Prioritization (Identifying impact and urgency) Problem Investigation

and Diagnosis

Similar steps to incident investigation and covers aspects and information related to assessing the details and Accuracy of information reported in problem identification and recording and classification

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

Figure 13 – Problem Control Activities 9

9

(40)

Table 12 – Error Control Activities

Error Identification and Recording

§ Known Error is confirmed to the status of the identified problem root-case infrastructure component

Error Assessment § Conduct initial assessment on how to resolve the

known-error

§ Conduct Error Resolution Impact Analysis with the help of specialist groups

§ Identify if the error resolution requires a Request for Change to be raised (RFC)

Error Resolution Recording

§ Record error resolution activities in the Known-error database

Error Closure Upon implementation of the error resolution activities, the

following 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 Activities 10

10

IT PROCESSES BEST PRACTICES FOR. Version 1.0 Date: 04/06/2007

B

EST

P

RACTICES FOR

IT

P

ROCESSES

Table of Contents

List of Tables

List of Figures

1. Introduction

1.1.

Purpose

1.2.

Document Structure

2. Enablers for IT Processes

2.1.

Overview of IT Service Management

2.2.

The Concept of Service Oriented IT Departments

2.3.

Service Offering Requires a Stable IT Infrastructure

2.4.

Definition of a Process and Alignment Requirements

ITSM

Alignment

2.5.

Overview of ITIL Best Practices

3. Processes Implementation

Considerations

3.1.

Introduction

3.2.

Establish a Baseline for Implementation

3.3.

Gap Analysis and Recommendations

3.4.

Process Prioritization

3.5.

Handle Implementation as a Project

3.6.

Never underestimate the importance of Communication

3.7.

Organization Size Considerations

Organizational departments

P

ro

c

es

s

es

CONFLICT?

3.8.

General Considerations