Best Practices For IT Processes en

BEST PRACTICES FOR
IT PROCESSES
Version 1.0 Date: 04/06/2007
The Saudi e-Government Program (Yesser) has exerted its best effort to achieve the quality, reliability, and accuracy of the information contained in this document. Yesser assumes no liability 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 of IT Processes
Table of Contents
1. Introduction ....................................................................................................................... 4 1.1. Purpose ....................................................................................................................... 4 1.2. Document Structure ..................................................................................................... 4 2. Enablers for IT Processes ................................................................................................ 6 2.1. Overview of IT Service Management............................................................................ 6 2.2. The Concept of Service Oriented IT Departments ........................................................ 6 2.3. Service Offering Requires a Stable IT Infrastructure..................................................... 7 2.4. Definition of a Process and Alignment Requirements................................................... 8 2.5. Overview of ITIL Best Practices ................................................................................. 11 3. Processes Implementation Considerations .................................................................. 15 3.1. Introduction ................................................................................................................ 15 3.2. Establish a Baseline for Implementation..................................................................... 15 3.3. Gap Analysis and Recommendations......................................................................... 15 3.4. Process Prioritization.................................................................................................. 16 3.5. Handle Implementation as a Project........................................................................... 17 3.6. Never underestimate the importance of Communication ............................................ 18 3.7. Organization Size Considerations .............................................................................. 18 3.8. General Considerations.............................................................................................. 19 4. Appendix I ITIL Process Assessment Exercise Saudi Governmental IT Department Case Study......................................................................................................... 21 4.1. Context ...................................................................................................................... 21 4.2. Scope of Assessment................................................................................................. 21 4.3. Process Maturity Indicators ........................................................................................ 27 5. Appendix II Guideline for IT Processes ...................................................................... 29 5.1. Introduction ................................................................................................................ 29 5.2. Incident Management Process ................................................................................... 29 5.3. Problem Management Process .................................................................................. 37 5.4. Change Management Process ................................................................................... 43 5.5. Release Management Process .................................................................................. 48 5.6. Service Level Management Process .......................................................................... 51 5.7. Processes Key Performance Indicators (KPIs) ........................................................... 55 6. Appendix III Glossary of Terms................................................................................... 59
e-Government Program (yesser)
-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 Figure 18 " Service Level Management Relationship with Other Processes ............................ 55
-3-
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 Processes covered in this section cover: Incident Management, Problem
-4-
Best Practices of IT Processes 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
-5-
2.
2.1.
Enablers for IT Processes

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.
-6-

IT is a #Business Enabler$ IT Manager assumes the role of a CIO (covering company organization, quality, risks management and compliance)
IT as a Service Provider Optimization & Alignment of technologies, organization & processes Continuously showing value of IT to business
Value Center
Service Center
#IT Manager$ type CIO Focus on Technologies
Cost Center
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
-7-
Best Practices of IT Processes 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
Business Service IT Operation IT Infrastructure
IT aligns with Service requirements through processes
Business Expects IT Operation & Infra. to be flexible in providing required services
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)
APPENDIX B: Process Theory and Practice, Book for Service Support (Published 2000), page 271 TSO 2005, All rights reserved
-8-
Best Practices of IT Processes 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
APPENDIX B: Process Theory and Practice, Book for Service Support(Published 2000), page 272 TSO 2005, All rights reserved 3 Ibid., page 273
-9-
Best Practices of IT Processes 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.) 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 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
Process
ITSM Alignment
Organisation
Technology
Figure 5
IT Service Management Alignment Pillars
- 10 -
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 Incident Management Problem Management Configuration Management Change Management Release Management
Operational processes cover Service Support set and consist of:
Service Desk is classified as a function within the ITIL framework and among its activities is the utilization of Incident Management Process.
security
IT Service
Availability Management Capacity Management Financial Management

for IT services
Continuity Management
Release Management
Service Level Management
IT IT Infrastructure Infrastructure
Change Management Configuration Management esk Service D
Incident Management
Problem Management
Figure 6
4
Service Delivery Set & Service Support Set
www.itilsurvival.com (reproduced with permission)
- 11 -
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.
Strategic
Sr. IT Mgt Service Level Management Service Desk IT!
Sr. Mgt
Service Service Delivery Delivery Service Service Support Support
Tactical
Customers
Operational
Users
The Business!
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 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
User 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:
- 12 -
Table 2
Focus of Service Delivery and Service Support Processes
Type Service Delivery
Process Name Service Level Management
Process Focus 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 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 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 Focuses on the unplanned interruptions of the services. Addresses issues of ownership, detection, classification, diagnostic, escalation, and resolution and recovery of the services
IT Service Continuity Management
Availability Management
Service Support
Incident Management
- 13 -
Best Practices of IT Processes Type Process Name Problem Management Process Focus Looks for the root causes for incidents and focuses on reactive, proactive, and reviews of the problems 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) Focuses on controlling and classification of the changes introduced to the IT infrastructure. Addresses concepts like RFC (Request for Change), CAB (Change Advisory Board) Focuses on controlling the changes through planning, testing, and implementation
Configuration Management
Change Management
Release Management
- 14 -
3.
3.1.
Processes Implementation Considerations

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.
- 15 -
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.
IT Asset Management, ITIL, and The CMDB: Paving The Way For BSM, by Robert McNeill and Thomas Mendel, Ph.D. 2005, Forrester Research, Inc.
- 16 -
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.
Ibid., page 5
- 17 -

Initiative
Enhancements P1+
Priority P1 P2 P3
Dependencies
Services enhancements
S1 S2 End users service Help Desk empowerment O1 S1,P10,O1,O3,T1, T2
Process enhancements
ITIL processes integration P1 P2 P3 P4 P5 Change , Release and project management Incident and configuration management Configuration and Service level management Incident and problem management Problem and configuration management Desktop management P6 Configuration and change management Root cause analysis P7 P8 Problem management Process outcomes measures Process documentation P9 P10 ITIL documentation quality improvement ITIL documentation customization Rely on others initiatives Rely on other initiatives All All O1, O5 P4, P5, T1 O1, S1, S2, P1, P3, P4, P5, P6, P7, P9 O1, O5, T1 O1, O5, T1, T3 O1, O5, T1 O1, O5, T1, T3 S2, O1, O5, P7, T1 O1, O5, P2, P7, T1
Organizations enhancements
O1 O2 O3 O4 O5 Leadership Awareness Train service Desk Train ETOM_ITIL link Roles restatement O1, P8 O1, S2 O1 P1, P2, P3, P4, P5, P6, P7 All
Technology enhancements
T1 T2 T3 T4 Service Desk tools expansion System & Network events monitor Server management SLA management O1, S2, P1, P2, P3, P4, P5, P6, P7 S2 O1, P6 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
- 18 -
Best Practices of IT Processes 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.
Line managers
Organizational departments
CONFLICT?
Processmanagers
Processes
= 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
- 19 -
Best Practices of IT Processes 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
- 20 -
4.
Appendix I ITIL Process Assessment Exercise Saudi Governmental IT Department Case Study
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.1.
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.
- 21 -
4.2.1. General ITIL Readiness
Table 3
General ITIL Readiness Questionnaire
Assessment Area General ITIL Readiness
Assessment Questions 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 IT-department comprehend how the ITservices 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 management/helpdesk tool? by a service
- 22 -
4.2.2. Incident Management Process

Table 4 Incident Management Process Questionnaire
Assessment Area Incident Management Process
Assessment Questions 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 understood by incident management? and
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 concerning escalated incidents? with information
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?
- 23 -
4.2.3. Problem Management Process

Table 5 Problem Management Process Questionnaire
Assessment Area Problem Management Process
Assessment Questions 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 completeness of all problem records? for the
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?
- 24 -
4.2.4. Change Management Process

Table 6 Change Management Process Questionnaire
Assessment Area Change Management Process
Assessment Questions 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?
- 25 -
4.2.5. Release Management Process

Table 7 Release Management Process Questionnaire
Assessment Area Release Management Process
Assessment Questions 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?
- 26 -
4.2.6. Service Level Management Process

Table 8 Service Level Management Process Questionnaire
Assessment Area Service Level Management Process
Assessment Questions 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.
- 27 -

PROCESS MATURITY ACHIEVEMENT METHOD
CHARACTERISTIC
5 4 3 2 1 0
Optimized
Managed And Measurable
Improved feedback into the Process Measured Process

(Quantitative)
Automation
Process Evolution
Complete control Structures. Performance analysis Policies, procedures & standards defined. Corporate Knowledge
Defined Process Repeatable But Intuitive Initial / Ad Hoc Non Existent
Process defined & Institutionalized

(Quantitative) Process Dependant on Individuals (Intuitive)
Quality People Defined Tasks
Ad Hoc/Chaotic Complete Lack Of Process Values And Awareness
Undefined tasks. Relies on Initiation
No Method
Figure 11
ITIL Process Maturity Indicators
- 28 -
5.
5.1.
Appendix II
Introduction
Guideline for IT Processes
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!. ITIL terminology defines an Incident! as:
- 29 -
Best Practices of IT Processes 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:
CHAPTER 5: INCIDENT MANAGEMENT, Book for Service Support(Published 2000), page 71 TSO 2005, All rights reserved
- 30 -

Table 9 Incident Management Process Activities
Activity Name Incident Detection and Recording (Ideally, incident detection and recording will be done with the help of a tool)
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 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 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
Classification & Initial Support
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.
- 31 -
Best Practices of IT Processes Activity Name Resolution and Recovery Main Activity Tasks / Actions 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.
- 32 -
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:
CHAPTER 5: INCIDENT MANAGEMENT, Book for Service Support(Published 2000), page 73 TSO 2005, All rights reserved
- 33 -

Table 10 Incident Management Relationship with Other Processes
Process Name Problem Management
Relationship with Incident Management Process 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
- 34 -
Best Practices of IT Processes Process Name Change Management Relationship with Incident Management Process Service Desk / Incident Management should ensure all RFCs, Standard Changes, and nonstandard 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
- 35 -
Best Practices of IT Processes Process Name Configuration Management Relationship with Incident Management Process 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
- 36 -
Best Practices of IT Processes Process Name Service Level Management Relationship with Incident Management Process 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 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 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

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
- 37 -
Best Practices of IT Processes 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

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.
- 38 -

Table 11 Problem Control Activities
Activity Name 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) Problem Classification
Main Activity Tasks / Actions 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
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
CHAPTER 6: PROBLEM MANAGEMENT, Book for Service Support(Published 2000), page 101 TSO 2005, All rights reserved
- 39 -
Table 12
Error Control Activities
Activity Name Error Identification and Recording
Main Activity Tasks / Actions 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 knownerror 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) Record error resolution activities in the Known-error database
Error Resolution Recording 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
CHAPTER 6: PROBLEM MANAGEMENT, Book for Service Support(Published 2000), page 106 TSO 2005, All rights reserved
- 40 -
Table 13
Proactive Problem Management Activities
Activity Name Trend Analysis
Main Activity Tasks / Actions 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 / Network Management tools Vendor literature Attending conferences Analyzing customer surveys The internet, and looking for user groups inputs Introduce necessary metrics and Key Performance Indicators to measure areas related to the volume of incidents, impact on work activities, duration required to solve these incidents, involvement of vendors or thirdparties in solving these incidents Define Reporting procedures and roles to address outcomes of analyzing the metrics Produce weekly reports to capture these metrics Take corrective actions and act upon the reports outcome
Targeting Preventive Action

Problem Management Process has main interactions with other ITIL processes such as: Incident Management Process Change Management Process Configuration Management Process Service Level Management Process (Including Capacity and Availability)

Table 14 Problem Management Relationship with Other Processes
Process Name Incident Management
Relationship with Problem Management Process (As described in Table 10 above)
- 41 -
Best Practices of IT Processes Relationship with Problem Management Process For solutions identified for problems or known errors, Change Management process must be followed through the issuance of RFC and obtaining the approval of CAB Change Management should coordinate with Problem Management in RFC issuance and assessment in relation to problem work arounds and permanent solutions identified. Change Management providing full support to Problem Management on Major Incidents Resolution Change Management involvement of Problem Management in CAB for RFCs related to Problems. Change Management must include all this info in FSC In relation to changes based on Problem Management identified workarounds and permanent solutions, Change Management and Problem Management need to agree on the rollback changes needed if the Changes are not successful Change Management must advise Problem Management workers and specialists on the suitable approach and procedure to follow in handling changes related to Problems earlier identified Problem Management need to report to Configuration Management trend analysis results on CIs reviewed As an outcome of trend analysis and if there is an identified unauthorized change, Problem Management need to report to Change Management and Configuration Management any inconsistency in CI state For certain CIs (Based on classification), provide reports to Problem Management on the number of changes due to faults for certain periods. This will enable Problem Management to carry some trend analysis activities
Process Name Change Management
Configuration Management
- 42 -
Best Practices of IT Processes Relationship with Problem Management Process Problem Management should inform SLM for OLAs breaches with Support Groups Problem Management should inform SLM for needs in improving OLAs Problem Management should provide SLM with historical trends and statistical data to help it analyze quality of service for all IT services provided by IT to its customers Problem Management should inform SLM on Major Incidents to properly assess the impact on the business SLM need to ensure that service requirements and updates on requirements are communicated to Problem Management to reflect the required priority. SLM need to ensure that Problem Management%s inputs/recommendations on vendor services are communicated to them for adherence and implementation. This will not only help to improve their services but also prevent further incidents/problems SLM should ensure that business priority is correctly reflected by the prioritization and category classification process used by Problem Management SLM should provide inputs during problem review meetings from SLM perspective to enable Problem Management improve its process. Based on Service Level targets defined in SLAs, Availability and Capacity Management Processes should be proactively involved in identifying problems and advising Problem Management Process accordingly
5.4.
Change Management Process

In relation to the IT infrastructure, the ability to determine the need to the change versus the impact of the change on the current operation and services provided is a question where IT Departments should be concerned with all the time. Following a best practice in this area might not be as straight as other processes, but ITIL do recommend a practical approach for Change Management and controlling the diverse impact on the infrastructure.
- 43 -
Best Practices of IT Processes Changes arise due to different reasons. Some of the reasons are concerned with rectifying a problem but also due to business or organizational requirements concerned with 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 Change Advisory Board (CAB). The CAB usually meets at predefined short intervals (once a week for example), and review all submitted Request for Changes (RFCs). The CAB need to measure 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, Configuration Process Owner and Manager, Service Level Management Process representative. Nonpermanent members (upon invitation) will constitute of Change Requester (Business side Customers), representative of the IT Operational, and Vendors (if necessary), and Service Desk representative if the change involve an IT Service that is supported by the Service Desk. Some changes will not require a CAB decision to determine and evaluate the change request (example: upgrading a MS Office application or changing an IP address on a Desktop). As a result, Change Management conducts classifications of changes as follows: Standard Changes: When the impact and cost and required resource involvement is known and predetermined, usually the changes will be classified as standard. The standard changes do not require CAB approval, but all standard changes requests and actions must be documented for future reference. Typically, the owner 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 the meeting either permanent or non-permanent. CAB will assess the impact and cost and 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 and are 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 a strict 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 result from carrying the change. Effective Change Management focuses on ability to conduct the changes in a timely and satisfactory manner no matter how high the number of changes is required.
- 44 -
Best Practices of IT Processes The benefits of implementing an effective and efficient Change Management Process will include: Controlled expectations of organizational and business requirements in relation to quality 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. This translates in better and increased user productivity Optimization of IT resources in relation to changes and time required for involvement Business is happy and Customers are satisfied

Below table summarizes the activities of the Change Management Process. It should be noted here that as Change Management tend to be a more mature process in any IT Department due the nature of introducing necessary controls to the infrastructure, ITIL provides a practical approach in defining the process activities.
Table 15
Change Management Process Activities
Activity Name Logging and Filtration of RFCs (This process could be manual through forms submittal via emails or systemized through a workflow tool)
Main Activity Tasks / Actions Ensure completeness of RFCs forms submitted. Information should cover description of the change, impacted infrastructure and business areas, time required to implement the change, availability of back-out plans, resources required to implement the change Based on the completed information, decide if the change is practical to implement as specified (Time window allocated is sufficient, resource requirements are adequate, and impact is assessed right) Give the requester of change the right to discuss and appeal outcome of this activity Assess impact of the change activities on the work activities 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 Categorize the changes based on the priority defined. Categorization can include: Minor Impact Only, Significant Impact, or Major Impact Prepare all information and include it in CAB meeting schedule
Priority Allocation
Categorization
- 45 -
Best Practices of IT Processes Activity Name Assessment Main Activity Tasks / Actions Analyze the RFC in relation to: o o o o Impact identified in relation to work activities Impact on service levels as defined in SLAs Is there an extended impact to other services? Is there an extended impact beyond related Services? (example: service desk, power requirements, etc.) What happens if we do not implement the change? Are cost and resource requirements correct? What are the other RFCs requested? Can it fit in this round of scheduled changes
o o o Approval
Based on the assessment of the RFC and other related criteria defined in the assessment, CAB will decide on the go ahead of implementing the change. If the CAB refused the change, sufficient reasons must be provided to the requester Coordinate with Release Management Process on the change implementation. Release must oversee and align all the building, testing, and implementing of the change Release Management must advise Change Management of the Post Implementation Review (PIR) results including all issues faced during the change, lessons learned, real impact, and measured outcome
Scheduling
Review (PIR)
Change Management Process RFC Logging & Filtering Priority Allocation Categorization Assessment Approval Scheduling Review (PIR) Coordination w/ Release Mgmt. Building Testing Implement
Figure 15
Change Management Process Activities
- 46 -

Change Management Process has main interactions with other ITIL processes such as: Incident Management Process Problem Management Process Configuration Management Process Release Management Process Service Level Management Process

Table 16 Change Management Relationship with Other Processes
Process Name Incident Management Problem Management Configuration Management
Relationship with Change Management Process (As described in Table 10 above) (As described in Table 14 above) To determine proper infrastructure component, Change Management must refer to Configuration Management in the RFC filtering and logging Configuration Management must advise Change Management on the latest status of the infrastructure component and if there are any changes Configuration Management must approve the assessment of the change to the infrastructure component Through Release Management, Configuration Management must ensure that the new attribute to the infrastructure component is up-to-date and reflected in the PIR and CMDB Must work closely with Change Management and coordinate the building, testing, and implementation of the change Must provide Change Management with the PIR report and highlight any implementation issue Must advise Change Management on the work impact of the change as defined in the SLAs Must approve the change impacts as defined in the RFC Change Management must advise if the change implementation has impacted or violated any service levels agreed
Release Management
Service Level Management
- 47 -
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. Release Management is an essential process to Change when the implementation is required. It is also important to Configuration to ensure that the infrastructure components are up-todate and reflect the reality of the situation. Release Management Process also focuses on two essential elements to the IT Infrastructure: Definitive Software Library (DSL) and Definitive Hardware Store (DHS). DSL and DHS are physical repositories that store software and hardware elements necessary for the IT Operation. DHS is less feasible as many of the IT Operations rely on vendors in handling their inventories and spares of hardware. DSL is more controlled and enforced 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 with Change and Configuration Management. The benefits include: Quality of Service assurance to the organization through proper control of software and hardware releases Ensure the quality of the software and hardware used in the live operation of IT infrastructure 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 the Configuration Management Process Control copy and intellectual rights and eliminate infringements Customer surprises are minimized in relation to expected releases of software and hardware under use

Release Management activities rely on authorized RFCs from Change Management and other inputs mainly related to Project Management implementations. The general process activities include:
- 48 -

Table 17 Release Management Process Activities
Activity Name Planning
Main Activity Tasks / Actions Develop a high-level plan or release schedule for the updates to the IT infrastructure Communicate with Customers and users to set the right expectations (activity handled with the help of Service Desk) Plan Resource involvement in the release activities Ensure cost justification for the release implementation Ensure availability of back-out plans before commencing with the implementation Test the back-out plans along with the Acceptance activity Estimate vendor involvement in the activity if needed Ensure there is a proper design and build for the updated software or hardware release Ensure all resources readiness to enable for the design and build activities Ensure that the design and build activities are according to the predefined Release Plans Coordinate involvement of business and IT staff for the release update acceptance test Ensure a controlled test environment for the carrying the release acceptance Conduct Back-out testing Conduct integrity checks as part of the acceptance criteria Inform Change Management proactively on the status of the release acceptance exercise Reschedule with Change Management if the release is rejected Build a detailed Rollout Plan covering the procedures and infrastructure components and all related scheduling (time and resource) Communicate the relevant details to the customers and end users and clearly indicate impacts to their work activities (if any) Ensure Procurement of necessary items for the new releases
Design & Build Acceptance Rollout Planning
- 49 -
Best Practices of IT Processes Activity Name Communication Main Activity Tasks / Actions Plan a Communication plan and communicate it to the relevant stakeholders Ensure right levels of expectations and scenarios are addressed in the communication plan Use means such as meetings and training to disseminate the planned implementation activities and related information Conduct the installations of the release as per the predefined Rollout Plan Ensure metrics are measured to measure the success of the implementation Provide Change Management Process with an update on the implementation through the PIR report Ensure an update to the Configuration Management Database Provide a list of lessons learned and any known-errors identified through out the release process
Distribution and Install
Release Management Process Planning Design & Build Acceptance Rollout Planning Communication Distribution & Install
Figure 16
Release Management Process Activities

Release Management Process has main interactions with other ITIL processes such as: Change Management Process Configuration Management Process
Below table provides a summary of the required interactions and relationships:

Table 18 Release Management Relationship with Other Processes
- 50 -
Best Practices of IT Processes Process Name Change Management Configuration Management Relationship with Release Management Process (As described in Table 16 above) Ensure that similar information related to DSL and DHS is captured in the Configuration Management database (CMDB) Ensure that infrastructure components information are up-to-date in CMDB and reflects the changes carried
5.6.
Service Level Management Process

Service Level Management serves as the bridge between customer and business requirements and IT Departments. Without Service Level Management, IT would have difficulty to define and optimize what is considered as a proper service level that meets the business expectations. Service Level Management at the same time will work to set proper expectations of the current infrastructure performance abilities to the business and help the business take crucial decisions such as capital investments required or outsourcing options available. Service Level Management will work to formalize the relationships with the customer, IT, and vendors through multiple forms of Service Level Agreements. The term Service Level Agreements refers to three type of agreements: Service Level Agreement (SLA): A formal agreement signed between the business (Customer) and IT in which all expectations to service levels are defined in term of: service priority to the business, service availability requirements, optimized capacity needs, Disaster recovery options for the service (if required), and incident and problem resolution windows tolerated Operational Level Agreement (OLA): A formal agreement signed within the IT infrastructure and among the various groups that will ensure a proper quality of service. A typical OLA will be signed between the Service Desk and Incident Management Support Groups (example: Network Operations) to define the response and resolution times to opened and assigned incident tickets Underpinning Contracts (UCs): UCs take a very formal and legal approach as it is usually signed between the IT and third parties (outside vendors). It would be a different form of an SLA where the IT plays the role of the business or Customer
Ideally, UCs serve as a baseline where OLAs and SLAs will be defined. If an UC is signed with the vendor and defines a response time of x minutes, IT Department would not be able to offer the business or other IT entities a commitment of response time that is less than x + y, where y is a factor defined in relation to many criteria such as resource availability and geographical location.
- 51 -
5.6.2. Benefits of Service Level Management Process Implementation

As a business interacting process, Service Level Management benefits can be substantiated through financial savings. As expectations are defined by the business, IT Departments will work on improving the service quality and reduction in service interruptions and failure. Other list of benefits include: IT will work to design its services according to business expectations and less based on infrastructure capabilities IT Roles and operation will be optimized to focus on areas considered important to the business Customer will receive a clear indication on what is expected from the business to ensure proper service quality (required investments to provide the requested quality of service) Continuous IT alignment to optimize services based on customer feedback and inputs Better understanding of what type of engagement needs to be defined with the vendors and enable for proactive engagement to define what is considered as acceptable quality of service by the Customer

Service Level Management process activities are proactive and enables for continuous improvement of service quality based on real measurements. The process activities are grouped into four main areas: Establish the Service Level Management function Define and Implement the SLAs Manage the process Conduct Periodic Reviews
The table below further elaborates on the activities main areas.
- 52 -

Table 19 Service Level Management Process Activities
Activity Name Establish the SLM Function
Main Activity Tasks / Actions Plan the creation of the function as part of the IT organization structure. Ensure that the SLM Manager occupies a rank where direct reporting is established with the CIO or IT Director / Manager Define the associated roles and responsibilities of the SLM Manager function Create necessary awareness in the organization on the role of SLM Define requirements for building a Service Catalog Draft an initial SLA Identity required support tools that enable for service monitoring Define required service priorities in relation to Incident Management Process Produce a Service Catalog of IT Services provided to the organization Manage and communicate service expectations to all stakeholders Review currently signed UCs, OLAs, and SLAs Draft the SLAs and ensure buy-in from all parties involved. Ensure the parties are involved in the definition of the SLA Define the reporting procedures required and ensure it is included in the SLAs Communicate the SLA expectations to organization and start the monitoring process the whole
Define and Implement the SLAs Manage the Process Conduct Periodic Reviews
Review necessary metrics and service targets that enable for monitoring of Service Levels and achievements Produce necessary reports that capture the impact of the SLA on the service quality and business expectations Conduct necessary service review meetings with the customers to discuss achievements and issues Review the SLAs to reflect expectations and requirements business changing
Establish procedures to define periodic of the SLAs and the process
- 53 -
Figure 17
Service Level Management Process Activities 11

Service Level Management interacts almost with every other process in the ITIL domain. The ultimate objective for Service Level Management is to be able to capture the various requirements in the form of Service Level Agreements. Below table provides a summary of the required interactions and relationships:
Table 20 Service Level Management Relationship with Other Processes
Process Name Incident Management Problem Management Change Management Configuration Management
Relationship with Service Level Management Process (As described in Table 10 above) (As described in Table 14 above) (As described in Table 16 above) CMDB holds all related information of SLAs IT Service Catalog defines the relationships between configuration items (infrastructure components) as defined in the CMDB. Any updates to the IT Service Catalog should be reflected in the CMDB Define the capacity thresholds that adhere to service levels and quality of service expectations
Capacity Management
11
CHAPTER 4: SERVICE LEVEL MANAGEMENT, Book for Service Delivery (Published 2000) TSO 2005, All rights reserved
- 54 -
Best Practices of IT Processes Relationship with Service Level Management Process Translate availability requirements into financial costs as required by the Service Level Management process
Process Name Financial Management
Figure 18
Service Level Management Relationship with Other Processes
5.7.
Processes Key Performance Indicators (KPIs)
The below table provides a list of generic KPIs to be considered by the IT Managers to measure the success of ITIL processes operation. Actual development of relevant KPIs will focus on the services provided and expected performance of the related process. KPIs have to generally follow the SMART context, where: Simple Measurable Achievable Realistic Time related
A SMART KPI example is: Achieve 5% reduction in all incidents reported to the Service Desk in the coming 3 months period!.
- 55 -

Table 21 Sample ITIL Processes KPIs 12
Type Service Delivery
Sample KPIs The percentage of Underpinning contracts and OLAs in place that are supporting Service Level Agreements. Meetings held (on time) to review performance Costs of decreasing. Service Delivery
Financial Management for IT Services
The percentage of targets relating to Service delivery being met. The number of Service breaches recorded Improvements in salient points from Customer feedback forms Reduced frequency and severity of Changes required to the Accounting and Budgeting systems. All IT costs are accounted for. Reduced frequency and severity of Changes made to the Charging algorithms (where appropriate). Number of Incidents logged relating to Capacity issues. The average cost per capacity issue What is the client perspective with relation to Capacity of IT Services? Identification of Risks " in scope Identification of Risks " out of scope Meetings held (on time) to review performance Costs of Service Continuity process decreasing vs. level of expected service. Number of tests carried out as part of the ITSCM process
Capacity Management
IT Service Continuity Management
12
The presented KPIs are selected from The Art of Service Pty Ltd processes kit with due copyrights
- 56 -
Best Practices of IT Processes Type Process Name Availability Management Service Support Incident Management Sample KPIs The average cost per availability issues What is the client perspective with relation to Availability of IT Services Number of Availability management meetings. Increased Learning and growth. The percentage of incidents handled within the agreed Service Level Agreements for that type of incident or CI. The average cost per incident Percentage of incidents resolved at first line support that have been agreed to be resolved via an SLA. Percentage of Incidents resolved without on-site contact Percentage of incidents assigned more than 2 times. Number of Problems raised Number of Problems identified as Known Errors Number of Known Errors that can be removed Number of Known Errors that have been removed Number of Problems and Known Errors identified due to proactive activities. Incident count related to problems and known errors made in previous period.
Problem Management
- 57 -
Best Practices of IT Processes Type Process Name Configuration Management Sample KPIs Breaches to Service Level Agreement that occur as a result of poor or missing information from the closely linked Service Support functions (Configuration, Release, Problem and Service Desk). The number of times that a change results in increased incidents and problems. The number of times that a change was not completed due to insufficient or incorrect information supplied from the CMDB. Absolute value count on the amount of times the CMDB is found to be in error. Number of RFC%s raised Successful changes made Number of Changes rejected Number of Changes reversed (indicating the reason why). Source of change requests (e.g. Problem Management, business requests, training improvements, etc.) Incident count related to changes made in previous period Number of Releases Scheduled Successful releases implemented Number of releases rejected or failed Number of releases backed out (indicating the reason why). Reason for the release (e.g. Problem Management, business requests, training improvements, etc.)
Change Management
Release Management
- 58 -
6.
Appendix III
Glossary of Terms
The following glossary of terms is directly extracted from ITIL Book for IT Service Support from OGC13.
Table 22
Glossary of ITIL Terms
Availability
Build
Category Change
Change Advisory Board
Change authority
Change control
Change document Change history Change log
Change Management
Ability of a component or service to perform its required function at a stated instant or over a stated period of time. It is usually expressed as the availability ratio, i.e. the proportion of time that the service is actually available for use by the Customers within the agreed service hours. The final stage in producing a usable configuration. The process involves taking one of more input Configuration Items and processing them (building them) to create one or more output Configuration Items e.g. software compile and load. Classification of a group of Configuration Items, Change documents or Problems. The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. A group of people who can give expert advice to Change Management on the implementation of Changes. This Board is likely to be made up of representatives from all areas within IT and representatives from business units. A group that is given the authority to approve Change, e.g. by a project board. Sometimes referred to as the Configuration Board. The procedure to ensure that all Changes are controlled, including the submission, analysis, decision making, approval, implementation and post implementation of the Change. Request for Change, Change control form, Change order, Change record. Auditable information that records, for example, what was done, when it was done, by whom and why. A log of Requests for Change raised during a project, showing information on each Change, its evaluation, what decisions have been made and its current status, e.g. raised, reviewed, approved, implemented, or closed. Process of controlling Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption.
13
APPENDIX A: List of Acronyms and Glossary Terms, Book for Service Support(Published 2000) TSO 2005, All rights reserved
- 59 -
Best Practices of IT Processes Change record A record containing details of which CIs are affected by an authorized Change (planned or implemented), and how. Classification Process of formally grouping Configuration Items by type, e.g. software, hardware, documentation, environment, application. Process of formally identifying Changes by type e.g. project scope Change request, validation Change request, infrastructure Change request. Process of formally identifying Incidents, Problems and Known Errors by origin, symptoms and cause. Closure When the Customer is satisfied that an incident has been resolved. Computer Aided A software tool for programmers. It provides help in the Systems Engineering planning, analysis, design and documentation of computer software. Configuration baseline Configuration of a product or system established at a specific point in time, which captures both the structure and details of that product or system, and enables that product or system to be rebuilt at a later date. A snapshot or a position which is recorded. Although the position may be updated later, the baseline remains unchanged and available as a reference of the original state and as a comparison against the current position (PRINCE2). Configuration control Activities comprising the control of Changes to Configuration Items after formally establishing its configuration documents. It includes the evaluation, coordination, approval or rejection of Changes. The implementation of Changes includes changes, deviations and waivers that impact on the configuration. Configuration documentation Documents that define requirements, system design, build, production, and verification for a Configuration Item. Configuration identification Activities that determine the product structure, the selection of Configuration Items, and the documentation of the Configuration Item's physical and functional characteristics, including interfaces and subsequent Changes. It includes the allocation of identification characters or numbers to the Configuration Items and their documents. It also includes the unique numbering of configuration control forms associated with Changes and Problems. Configuration item (CI) Component of an infrastructure - or an item, such as a Request for Change, associated with an infrastructure that is (or is to be) under the control of Configuration Management. CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component. Configuration Management The process of identifying and defining Configuration
- 60 -
Best Practices of IT Processes Items in a system, recording and reporting the status of Configuration Items and Requests for Change, and verifying the completeness and correctness of Configuration Items. Configuration Management A software product providing automatic support for tool Change, Configuration or version control. Configuration Management A database that contains all relevant details of each CI Database (CMDB) and details of the important relationships between CIs. Configuration Management Document setting out the organization and procedures plan for the Configuration Management of a specific product, project, system, support group or service. Configuration structure A hierarchy of all the CIs that comprise a configuration. Customer Recipient of a service; usually the Customer management has responsibility for the cost of the service, either directly through charging or indirectly in terms of demonstrable business need. Definitive Software Library The library in which the definitive authorized versions of (DSL) all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or filestores. They should be separate from development and test filestore areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. a fireproof safe. Only authorized software should be accepted into the DSL, strictly controlled by Change and Release Management. The DSL exists not directly because of the needs of the Configuration Management process, but as a common base for the Release Management and Configuration Management processes. Delta Release A Delta, or partial, Release is one that includes only those CIs within the Release unit that have actually changed or are new since the last full or Delta Release. For example, if the Release unit is the program, a Delta Release contains only those modules that have changed, or are new, since the last full release of the program or the last Delta Release of certain modules. See also 'Full Release'. End-User See 'User'. Environment A collection of hardware, software, network communications and procedures that work together to provide a discrete type of computer service. There may be one or more environments on a physical platform e.g. test, production. An environment has unique features and characteristics that dictate how they are administered in similar, yet diverse, manners. Expert User See 'Super User'. Forward Schedule of Changes A schedule that contains details of all the Changes approved for implementation and their proposed implementation dates. It should be agreed with the Customers and the business, Service Level
- 61 -
Best Practices of IT Processes Management, the Service Desk and Availability Management. Once agreed, the Service Desk should communicate to the User community at large any planned additional downtime arising from implementing the Changes, using the most effective methods available. All components of the Release unit that are built, tested, distributed and implemented together. See also 'Delta Release'. Measure of the business criticality of an Incident. Often equal to the extent to which an Incident leads to distortion of agreed or expected service levels. Any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service. Physical or functional interaction at the boundary between Configuration Items. An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a Change. A series of states connected by allowable transitions. The life cycle represents an approval process for Configuration Items, Problem Reports and Change documents. Alternative title for the BSI publication A Code of Practice for IT Service Management. The standard UK government method for project management. Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency. Unknown underlying cause of one or more Incidents. A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal. The process of planning and regulating, with the objective of performing a process in an effective and efficient way. A collection of new and/or changed CIs which are tested and introduced into the live environment together. Form, or screen, used to record details of a request for a Change to any CI within an infrastructure or to procedures and items associated with the infrastructure. Action that will resolve an Incident. This may be a Workaround. A set of responsibilities, activities and authorizations. A written agreement between a service provider and Customer(s) that documents agreed service levels for a service. Every Incident not being a failure in the IT Infrastructure.
Full Release
Impact
Incident
Interface Known Error
Life-cycle
PD0005 PRINCE2 Priority Problem Process
Process Control
Release Request for Change (RFC)
Resolution Role Service Level Agreement
Service Request
- 62 -
Best Practices of IT Processes Software Configuration Item As 'Configuration Item', excluding hardware and (SCI) services. Software Environment Software used to support the application, such as operating system, database management system, development tools, compilers, and application software. Software Library A controlled collection of SCIs designated to keep those with like status and type together and segregated from unlike, to aid in development, operation and maintenance. Super User In some organizations it is common to use 'expert' Users (commonly known as Super, or Expert, Users) to deal with first-line support problems and queries . This is typically in specific application areas, or geographical locations, where there is not the requirement for full-time support staff. This valuable resource needs, however, to be carefully coordinated and utilized. System An integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. Urgency Measure of the business criticality of an Incident or Problem based on the impact and on the business needs of the Customer. User The person who uses the services on a day-to-day basis. Version An identified instance of a Configuration Item within a product breakdown structure or configuration structure for the purpose of tracking and auditing change history. Also used for software Configuration Items to define a specific identification released in development for drafting, review or modification, test or production. Version Identifier A version number; version date; or version date and time stamp. Work-around Method of avoiding an Incident or Problem, either from a temporary fix or from a technique that means the Customer is not reliant on a particular aspect of a service that is known to have a problem.
- 63 -

Best Practices For IT Processes en

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Best Practices For IT Processes en

Hochgeladen von

Copyright:

Verfügbare Formate

BEST PRACTICES FOR

Version 1.0 Date: 04/06/2007

Best Practices of IT Processes

e-Government Program (yesser)

Best Practices of IT Processes

e-Government Program (yesser)

Best Practices of IT Processes

e-Government Program (yesser)

e-Government Program (yesser)

Best Practices of IT Processes

Enablers for IT Processes

The Concept of Service Oriented IT Departments

e-Government Program (yesser)

Best Practices of IT Processes

Towards a Value Center IT Department

Service Offering Requires a Stable IT Infrastructure

e-Government Program (yesser)

Business Defines Service Requirements

Business Service IT Operation IT Infrastructure

IT aligns with Service requirements through processes

Business Expects IT Operation & Infra. to be flexible in providing required services

IT Defines Infrastructure Stability based on Service Offering Flexibility

Service Offering & Infrastructure Stability

Definition of a Process and Alignment Requirements

e-Government Program (yesser)

Process Flow and Mapping in Organizational Unit 2

Modeling of Generic Process 3

e-Government Program (yesser)

IT Service Management Alignment Pillars

e-Government Program (yesser)

Best Practices of IT Processes

Overview of ITIL Best Practices

Operational processes cover Service Support set and consist of:

Availability Management Capacity Management Financial Management

Service Level Management

Change Management Configuration Management esk Service D

Service Delivery Set & Service Support Set

www.itilsurvival.com (reproduced with permission)

e-Government Program (yesser)

Best Practices of IT Processes

Sr. IT Mgt Service Level Management Service Desk IT!

Service Service Delivery Delivery Service Service Support Support

Service Delivery & Service Support Domains

ITIL Definitions of Customers & Users

e-Government Program (yesser)

Best Practices of IT Processes

Focus of Service Delivery and Service Support Processes

Type Service Delivery

Process Name Service Level Management

Financial Management for IT Services

IT Service Continuity Management

e-Government Program (yesser)

e-Government Program (yesser)

Best Practices of IT Processes

Processes Implementation Considerations

Establish a Baseline for Implementation

Gap Analysis and Recommendations

e-Government Program (yesser)

Best Practices of IT Processes

e-Government Program (yesser)

Best Practices of IT Processes

ITIL Process Priorities in $1 billion-plus Companies6

Handle Implementation as a Project