M ASARYK U NIVERSITY FACULTY OF I NFORMATICS

}w!"#$%&123456789@ACDEFGHIPQRS`ye|
D IPLOMA T HESIS

Implementation of ISO/IEC 20000 Standard in IBM Rational Method Composer

Tom as Frais

Brno, autumn 2009

Declaration
Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Advisor: RNDr. Jan Pavlovi c, Ph.D. ii

Acknowledgement
I thank RNDr. Jan Pavlovi c, Ph.D. for kind supervision of my work.

iii

Abstract
The thesis is devoted to the study of the information technology service management (ITSM) discipline and the international standard for IT service provision ISO/IEC 20000. The paper describes ITSM and quality of service problems in general and summarizes existing solutions and frameworks. The main part of the work is development of a process model based on ISO/IEC 20000 in IBM Rational Method Composer. Possible usage of this model and its potential extension are discussed including an illustrating example.

iv

Keywords
ISO/IEC 20000, ITSM, IBM Rational Method Composer, quality of service, process model

Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 General ITSM introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Importance of process tools . . . . . . . . . . . . . . . . . . . . . . . . 2.2 ITSM frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Information technology infrastructure library (ITIL) . . . . . . . . . . 2.2.2 Control Objectives for Information and related Technology (COBIT) 2.2.3 Microsoft Operations Framework (MOF) . . . . . . . . . . . . . . . . 2.2.4 Capability Maturity Model Integration (CMMI) . . . . . . . . . . . . 2.2.5 PRojects IN Controlled Environments (PRINCE2) . . . . . . . . . . . 2.2.6 Key ITSM framework characteristics . . . . . . . . . . . . . . . . . . . 2.3 ISO/IEC 20000 and its structure . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Benets of ISO/IEC 20000 adoption . . . . . . . . . . . . . . . . . . . 2.3.2 Structure of ISO/IEC 20000 and dened processes . . . . . . . . . . . 2.3.3 ISO/IEC 20000 and ITIL relation . . . . . . . . . . . . . . . . . . . . . 2.3.4 Issues of ISO/IEC 20000 implementing in an organization . . . . . . 3 Solution ISO/IEC 20000 process model . . . . . . . . . . . . . . . . . . . . . . . 3.1 Technologies used for ISO/IEC 20000 modelling . . . . . . . . . . . . . . . . 3.1.1 IBM Rational Method Composer and its concepts . . . . . . . . . . . 3.1.2 IBM Rational Team Concert and Jazz Team Server . . . . . . . . . . . 3.2 ISO/IEC 20000 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 ISO/IEC 20000-1 model . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 ISO/IEC 20000-2 model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Sample utilization Process incident . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Extending tasks and creating a new one . . . . . . . . . . . . . . . . . . . . . 4.2 Establishing new roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Designing a delivery process . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Problems encountered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix A Contents of the attached CD . . . . . . . . . . . . . . . . . . . . . . . . Appendix B Work Breakdown Structures of the ISO/IEC 20000 process model . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 3 4 4 4 6 7 8 8 9 9 10 10 13 13 15 15 15 21 22 22 24 27 27 28 29 32 32 34 36 37

Chapter 1

Introduction
The thesis is dedicated to a study of a domain of information technology service management (ITSM), which is a discipline for governing IT service provision to a customer. The primary concern is controlling quality of provided services service assurance intended mainly for greater customer satisfaction. The paper is aimed at one particular ITSM methodology the international standard for IT service provision ISO/IEC 20000. The main part of the work is development of a process model based on ISO/IEC 20000 in IBM Rational Method Composer. The planned application of the model is to illustrate the structure of the standard and emphasize major concepts and elements. Another possible usage is to form a baseline for process design in accordance with ISO/IEC 20000.

1.1

Structure of the thesis

The rst chapter comprises the introduction to the thesis and its structure. The second chapter analyses the problem of information technology service management and corresponding issues of quality assurance. Some of the major process frameworks are presented, especially IT Infrastructure Library (ITIL) and ISO/IEC 20000; differences between these two are also discussed. The third chapter covers IBM software platforms for process designing and implementation IBM Method Composer and IBM Team Concert. The model of ISO/IEC 20000 processes is also described in detail with a discussion of its possible utilizations and extensions. The fourth chapter illustrates one of ways of the potential model usage by extending a small part of it as it could be used in real process environment. This chapter is used as a proof of concept of my modelling approach and the implementation of ISO/IEC 20000 processes. The nal fth chapter summarizes the work done with a list of interesting issues, which I had while elaborating the thesis, including solutions I used.

Chapter 2

Problem analysis
2.1 General ITSM introduction

ITSM stands for Information Technology Service Management and represents an integrated approach to govern IT service provision. First of all, I would mention a denition of the term service. There are many of them, e.g. a particular type of help or work that is provided by a business to customers, but not one that involves producing goods (Longman Dictionary of Contemporary English), or the particular skills that someone has and can offer to others (Cambridge Advanced Learners Dictionary). Abstractly said, a service is a portion of work performed by a service provider on behalf of a service consumer. IT services types can vary from typical ones like developing a piece of software, administering hardware to more business-aligned ones, e.g. business process restructuralization. A quite interesting and embracive denition of ITSM is IT Service Management is the planned and controlled utilization of IT assets (including systems, infrastructure and tools), people and processes to support the operational needs of the business as efciently as possible whilst ensuring that the organisation has the ability to quickly and effectively react to unplanned events, changing circumstances and new business requirements as well as continuously evaluating its processes and performance in order to identify and implement opportunities for improvement. [1] The primary reason for managing IT services is a need for controlling their quality. Main benets gained by the Quality Assurance practice of IT services can be: Improving customers satisfaction. Reducing resources consumption. Aligning IT strategy with general business strategy. Better understanding of internal operations because of better monitoring and reporting.

However, a proper implementation of ITSM principles and QMS (Quality Management Systems) for IT services is difcult because of following reasons: A shared understanding between a service provider and customer of what quality means is necessary. In real scenarios, a set of so-called key performance indicators (KPIs) is established. It needs changes in service providers business culture and consequently overall employees conception of service provision needs to be customer-centered. Unless this 3

2. P ROBLEM ANALYSIS happens in a company, a QMS is considered only as a burden and employees try to evade it. The key for quality control is a concept of process improvement. Therefore a company needs a exible and scalable process environment to be able to utilize quality assurance practices. A central knowledge base and an information repository is required.

2.1.1 Importance of process tools To use a full potential of quality assurance practices and quality management systems, it is necessary to apply an integrated organization-wide solution. This requirement implies that a computer aided approach is vital to achieve essential sustainability and reduction of time and resource consumption. An optimized solution could use a process execution platform to enable quality monitoring, process improvement and also very important post-change reporting. Benets of this dynamical process infrastructure preferred to a static form of only documented practices are analogous to the usage of Web 2.0 technologies instead of a collection of static documents.

2.2

ITSM frameworks

In this section I list major ITSM frameworks and methodologies. Most of them are dedicated only to the domain of IT services, but I also mention some approaches, which are more general, however they can also be used for service management and quality assurance namely Capability Maturity Model Integration (CMMI) and PRojects IN Controlled Environments (PRINCE2). I omitted ISO/IEC 20000 here completely, as it is described throughout next section.

2.2.1 Information technology infrastructure library (ITIL) Information technology infrastructure library (ITIL) is a collection of best practices developed in the 1980s by British governments Central Computer and Telecommunications Agency (CCTA), at the present time fully integrated into Ofce of Government Commerce (OCG). The main reason for its creation was growing dependence of companies on information technologies and also a shift of IT perspective from just application development to more complex portfolio of services. ITIL therefore offered a framework, on which IT organizations could base their processes. The key ITIL characteristics are [16]: process management, a customer-oriented approach, unambiguous terminology, independence on platform and public domain availability. The initial ITILs versions were structured into separate books, each book covered one consistent topic of interest. The following diagram1 shows a structure of ITIL V2 books:

1. http://www.ibm.com/developerworks/webservices/library/ar-soaitil/itil 1.gif

2. P ROBLEM ANALYSIS

The core two books are Service Delivery and Service Support, which discuss typical ITSM problems. One additional ITIL V2 book exists ITIL Small-Scale Implementation which is guidance for smaller IT organizations or divisions. Actual version of ITIL is ITIL V3 released in 2007. It is structured based on a service lifecycle, unlike previous versions which were more grouped by separate processes. Moreover, ITIL V3 now covers also topics like service design instead of concentrating simply on service provision. An illustration2 of the ITIL V3 service lifecycle:

The ve ITIL V3 core books are (designated by names of service lifecycle phases)[2]: Service Strategy covers an alignment of business with IT and transforms each phase of the service lifecycle into benets for a customer.
2. taken from http://www.bmc.com/USA/Communities/attachments/BMC BPWP ITIL Version 3 BSM.pdf

2. P ROBLEM ANALYSIS Service Design provides guidance on the development and maintenance of information technology policies, documents, and architectures for the design of IT service solutions. This includes a range of models, including outsourcing and insourcing. [11] Service Transition describes the long term change and release management concepts and practices, offering guidance on transition into a business environment. [11] Service Operation explains the activities required to enable day to day operational excellence. It embraces many of the disciplines dened within the previous version of ITIL. [11] Continual Service Improvement embraces service quality in the context of continual improvement, and also deals with the service retirement scenario. [11] Some of ITIL benets mentioned in [16]: Services are more customer-focused and agreements about service quality improve the relationship. Service are better and more clearly described in an appropriate level of detail. The quality, availability, reliability and cost of the services are managed better.

2.2.2 Control Objectives for Information and related Technology (COBIT) The Control Objectives for Information and related Technology (COBIT) is a set of best practices for ITSM created by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI) in 1996. [4] COBIT is divided into four domains [4]: Plan and Organize contains following processes: Dene a Strategic IT Plan and Direction, Dene the Information Architecture, Determine Technological Direction, Dene the IT Processes, Organization and Relationships, Manage the IT Investment, Communicate Management Aims and Direction, Manage IT Human Resources, Manage Quality, Assess and Manage IT Risks, Manage Projects. Acquire and Implement covers identifying IT requirements, acquiring the technology, and implementing it within the companys current business processes. This domain also addresses the development of a maintenance plan that a company should adopt in order to prolong the life of an IT system and its components. [4] It contains following processes: Identify Automated Solutions, Acquire and Maintain Application Software, Acquire and Maintain Technology Infrastructure, Enable Operation and Use, Procure IT Resources, Manage Changes, Install and Accredit Solutions and Changes. Deliver and Support focuses on the delivery aspects of the information technology. It covers areas such as the execution of the applications within the IT system and its results, as well as, the support processes that enable the effective and efcient execution of these IT systems. These support processes include security issues and training. [4] 6

2. P ROBLEM ANALYSIS It contains following processes: Dene and Manage Service Levels, Manage Thirdparty Services, Manage Performance and Capacity, Ensure Continuous Service, Ensure Systems Security, Identify and Allocate Costs, Educate and Train Users, Manage Service Desk and Incidents, Manage the Conguration, Manage Problems, Manage Data, Manage the Physical Environment, Manage Operations. Monitor and Evaluate deals with a companys strategy in assessing the needs of the company and whether or not the current IT system still meets the objectives for which it was designed and the controls necessary to comply with regulatory requirements. Monitoring also covers the issue of an independent assessment of the effectiveness of IT system in its ability to meet business objectives and the companys control processes by internal and external auditors. [4] It contains following processes: Monitor and Evaluate IT Processes, Monitor and Evaluate Internal Control, Ensure Regulatory Compliance, Provide IT Governance. 2.2.3 Microsoft Operations Framework (MOF) Microsoft Operation Framework (MOF) is another framework designed specically for the ITSM domain. MOF 4.0 was created in 2008 to provide guidance across the entire IT lifecycle [14].

2. P ROBLEM ANALYSIS MOF represents a service lifecycle as three phases Plan, Deliver, Operate and one governing Manage layer. [15] 2.2.4 Capability Maturity Model Integration (CMMI) Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. It helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. [3] The following table shows ve maturity levels3 :

CMMI is usable in three different areas [3]: product and service development. service establishment, management, and delivery. product and service acquisition.

For each area, there is a collection of best practices called model. Thus, the CMMI for Services, released in February 2009, is appliable to IT services as another option to the ITSMspecic methodologies. 2.2.5 PRojects IN Controlled Environments (PRINCE2) PRINCE2 is a scalable project management method developed by the British Ofce of Government Commerce (the same organization that created ITIL). PRINCE2 is a general method
3. The table taken from Wikipedia, at: http://upload.wikimedia.org/wikipedia/commons/d/d7/Capability Maturity Model.jpg

2. P ROBLEM ANALYSIS with broad scope of usages. The processes within the technique and relations among them can be illustrated by the following diagram [19]:

Being an adjustable, exible and scalable method, PRINCE2 could be solely used as a base for succesful ITSM solution. Moreover, the new version of PRINCE2 PRINCE2:2009 Refresh was designed to better integrate itself with other methodologies Ofce of Government Commerce, notably ITIL. [19] Therefore it could be possible, for example, to use ITIL as a core ITSM solution and PRINCE2 to manage more complex service deliveries. 2.2.6 Key ITSM framework characteristics While comparing, trying to adopt or choosing which framework to use as a base for process development in an organization, there are several attributes of each framework or methodology that should be considered: a certication body or auditor availability, e.g. regionally. a fact, if a given framework is specic only to ITSM or is determined to be widely used and therefore it could be necessary to adjust it more to an IT related domain. a scale of a framework and / or a size of a service providers organization.

Additionally, I would like to mention an idea, that gaining a competitive advantage should not be considered as a benet gained by adopting some ITSM framework, because there is no advantage in implementing something regarded as standard [1]. The cited source also states that the real benet is in taking the framework as a baseline, a springboard, on which a service provider can further cultivate and evolve its process environment and corresponding service quality.

2.3

ISO/IEC 20000 and its structure

The ISO/IEC 20000 standard is the international standard for IT service management domain. It was released in December 2005 jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). ISO/IEC 20000 9

2. P ROBLEM ANALYSIS is the successor of the British Standard BS 15000, which was developed in the year 2000 to reect the ITIL methodology and its knowledge and experience. ISO/IEC 20000 is usable for providing IT services both for the explicit external customers, as well as for the service providers organization internal needs. The standard can be used equally in both ways. ISO/IEC 20000 consists of two parts: The rst part (denoted as ISO/IEC 20000-1: Specication) is mostly a description of a set of processes and requirements imposed on them (i.e. a denition what a given process should encompass). The second part (ISO/IEC 20000-2: Code of Practice) expands each process from the rst part with additional recommendations based on contemporary ITSM experience. 2.3.1 Benets of ISO/IEC 20000 adoption There are several possible benets gained by adopting the ISO/IEC 20000 standard: embracing the ITSM domain knowledge and best practices, that the standard contains. better alignment of business and IT strategy; many of the processes take into account the overall business strategy of the service provider. more customer-oriented IT; service delivery processes are managed and modied with regard to customers inputs, responses and reports. better monitoring capabilities used, e.g., to account accurately for resources spend by the IT services provision, or for more efcient planning of future service demands. obtaining the ISO/IEC 20000 certication by an auditor demonstrating the service providers will and commitment to addressing service quality problems. The certication can also be the formal prerequisite for gaining a signicant customer or winning a public selection procedure4 .

2.3.2 Structure of ISO/IEC 20000 and dened processes As stated above, ISO/IEC 20000 is divided into two parts: ISO/IEC 20000-1: Specication is in fact a set of requirements, which must be fullled by a service provider to comply with the standard. This part is mostly written in a form of rules and responsibilities (e.g., a service provider shall. . . or there shall be a process. . . ). A service provider adopts ISO/IEC 20000-1 by creating processes satisfying these obligations and meeting other requirements like the necessity of the integral management system encompassing all service management processes as stated in the chapter 3 (Requirements for a management system) [23]. ISO/IEC 20000-1 is of course the main part against which a service provider is certied, making it an essential document for auditors. ISO/IEC 20000-2: Code of Practice further extends processes dened in the specication by presenting additional recommendations based on best practices and the contemporary
4. E.g., the large public commission (no. 114071-9038) to deliver Information system of basic registers for the Czech Ministry of internal affairs also requires that the contractor is ISO/IEC 20000 certied. [22]

10

2. P ROBLEM ANALYSIS knowledge and experience of the ITSM industry. This part is not considered mandatory in the context of auditing and achieving ISO/IEC 20000 certications, rather suggestive it offers guidance and assistance in managing services using ISO/IEC 20000 processes.5 Both parts have almost identical structure in topics being described (with different content based on the perspective and the scope of each part); therefore I summarize here the general arrangement by introducing each chapter and its purpose. For clarity reasons I also include a tree schema presenting all processes dened in the standard (13 total; numbers in parentheses represent the chapter and clause in which they are described).

1. Scope a short overview of the standards purpose. 2. Terms and denitions a list of rigidly dened technical words and phrases used throughout the text. 3. Requirements for a management system contains specication of documentation, duties of service managers and a section regarding stafng for service roles. These three aspects are considered to be a core for a service management system creating an integral process framework. 4. Planning and implementing service management introduces a concept of service management process lifecycle based on an iterative methodology known as Plan-Do-CheckAct. The following diagram6 illustrates the cycle:

5. The relation between these two parts can be rather elementally demonstrated on the following example: Whereas ISO/IEC 20000-1 states There shall be a process doing. . . , ISO/IEC 20000-2 adds For that process, it is also vital to consider or implement. . . . 6. The schema taken from http://www.bizmanualz.com/articles/images/pdca.jpg.

11

2. P ROBLEM ANALYSIS

The methodology applied on the service management domain represents: Plan service planning. Do service implementation and delivery. Check service monitoring, reporting and analyzing. Act service improvement.

5. Planning and implementing new or changed services describes the importance of an integrated approach to managing changes to services or establishing new ones and depicts a way, how to achieve it. 6. Service delivery process a set of six processes with a quite operational character overseeing the service provision. There are following processes specied: 6.1 Service level management manages a denition, an agreement with a customer and monitoring of a service level (i.e., characteristics7 describing quality of a service at one moment in time). 6.2 Service reporting creates service reports. 6.3 Service continuity and availability management guarantees that a service is operable as stated in a SLA (Service Level Agreement). 6.4 Budgeting and accounting for IT services plans and monitors resource usage spent on the service provision. Note: Charging for services is not mandatory. 6.5 Capacity management guarantees enough resources for the service provision. 6.6 Information security management manages security of IT services including resolution of security incidents. 7. Relationship processes two processes dealing with business partners of a service provider: 7.1 Business relationship management manages an optimal partnership and cooperation between a service provider and its customers service consumers. An investigation of customers business needs is a necessity. 7.2 Supplier management manages a partnership with service providers suppliers both direct and indirect by rigidly dening service terms that a supplier provides. 8. Resolution processes two closely connected processes solving defects, technical errors or mistakes while providing services:
7. sometimes referred to as KPIs Key Performance Indicators

12

2. P ROBLEM ANALYSIS 8.2 Incident Management deals with an incident an event reducing quality of a service or breaking its functions completely and tries to mitigate its effects attempting to do as little disruption of customers business as possible. 8.3 Problem Management examines and reacts to sources and causes of incidents. 9. Control processes two processes, which work as an integral approach for service providers assets management: 9.1 Conguration management provides an unied access to information about service providers properties both material and immaterial (for example patents). 9.2 Change management grants a controlled methods for requesting changes in an organizations assets or infrastructure and approving them. 10. Release process there is only one process in the tenth and nal chapter: 10.1 Release management process a process dealing with a release (a set of related changes grouped together and implemented at once). 2.3.3 ISO/IEC 20000 and ITIL relation Since ISO/IEC 20000 was designed to be closely aligned with ITIL, many of the ITSM topics exist in both documents. However, there are several differences between these two, conceptual and process ones. The main conceptual difference is a fact, that ISO/IEC 20000 (primarily its rst part) is a set of mandatory requirements, whereas ITIL is a collection of advices and best practices. A whitepaper [6] and a website [5] summarize differences between ITIL V3 and ISO/IEC 20000. Some of the key differences mentioned are: ISO/IEC 20000 contains requirements for management responsibilities (in chapter 3), ITIL does not. [5] ISO/IEC 20000 has a more rigidly dened approach to business relationship and supplier management. ISO/IEC 20000 requirements are completely independent of organisational structure or size. A service provider must use the structure that is most appropriate. ITIL includes advice and options for some aspects of organizational structure. [5] Specialist advice is available for small organizations. ISO/IEC 20000-1 includes requirements for budgeting and accounting. Charging is not applicable for some organizations so cannot be included in a specication, where all requirements are compulsory. ITIL includes advice on charging. [5] For a complete list of all differences, please consult the referred materials. 2.3.4 Issues of ISO/IEC 20000 implementing in an organization There are several problems in implementing ISO/IEC 20000 in a company. The most important are: 13

2. P ROBLEM ANALYSIS The standard itself does not contain any information or guidance how to implement it. It is rather a list of requirements (part 1) and a list of process-related recommendations and advices (part 2). Unfortunately, there is no ofcial material like Planning To Implement Service Management is for ITIL. However, some third party books exist, e.g. [7]. There is no distinction in the terms of service providers size, nothing like the SmallScale Implementation for ITIL V2. The standard is quite new (released in December 2005) and therefore there are no many case studies and experience with its implementation.

A quite interesting material [21] exists on a topic of prioritization of ITSM processes, which could be used as a guideline for scheduling ISO/IEC 20000 and deciding, in which order to implement processes. The suggested sequence is as follows: 1. Change management Without change management as a rst step, your ITIL implementation effort may result in the automation of the ability to apologize for downtime, security events and so on. Conguration management Incident management Problem management

2. 3. 4.

This example demonstrates, that guidances for implementing ISO/IEC 20000 (and other ITSM solutions) based on experience can be found and used.

14

Chapter 3

Solution ISO/IEC 20000 process model

This chapter describes one approach to ITSM problems discussed in the previous chapter using a ISO/IEC 20000 standard and its model as a framework for IT service provision in an organization. The rst part of this chapter is dedicated to the technologies used for the modelling; the section regarding the model in detail follows.

3.1

Technologies used for ISO/IEC 20000 modelling

3.1.1 IBM Rational Method Composer and its concepts In this section I describe a tool used for the main part of my work IBM Rational Method Composer, commonly abbreviated as RMC. Rational Method Composer is a complex featurerich process designing platform. However, I depict here only a small subset of its aspects, which were relevant to working out my thesis. For the whole picture of RMC, please refer to [9] or the web site regarding all RMC characteristics at: www-01.ibm.com/software/awdtools/rmc/ The essential concept in Method Composer is the idea of distinction between reusable process assets (called Method content elements) and implementation of these assets specic for one process. This approach is in a certain way similar to the object-oriented programming paradigm, in which classes are general and reusable, whereas instances (objects) are their concrete representations. E.g., if a process designer wants to work with a role software tester, he or she denes a general method content element software tester and then uses a reference to this element in a delivery process. This reference now acts as an instance of the original software tester and all changes to this role in the scope of the delivery process are only local. On the other hand, if the general process element changes, a process designer can instruct RMC to automatically propagate all modications to all instances1 . It is essential to understand the structure of elements used in RMC. The following schema illustrates it with a subsequent description of each element. 2

1. option Default synchronization from method content 2. The primary reason for including this in my thesis is to give a reader a quick overview of basic RMC concepts and ability to use the ISO/IEC 20000 model not only in the form of exported HTML document, but also in the source form in RMC, which is vital for reusing the model and customizing or expanding it for needs of any specic organization.

15

3. S OLUTION ISO/IEC 20000 PROCESS MODEL

Method Library a top-level container for all elements regarding one project or process domain. Method Plug-in a high-level container used for grouping related method content elements and processes. E.g., I dene two method plug-ins in my model, iso20000-1 and iso20000-2 as collections of contents and processes of each part of the standard. Conguration a logical element specic only to publishing documents by RMC. A method conguration denes which corresponding parts of a method library should be published as a single document (like HTML or PDF). E.g., I use congurations iso20000-1 representing only rst part of the standard (i.e. specication) and iso20000, which is a whole standard published together using both method plug-ins. Method Content a container used for related general method content elements, which is structured into a hierarchy of smaller Content Packages. Process a container for both capability patterns and delivery processes described bellow. 16

3. S OLUTION ISO/IEC 20000 PROCESS MODEL Capability Pattern a part of a delivery process, that is general and abstract enough to be used separately in another processes. A capability pattern can act as a template or a framework for more than one process enabling the principle of reusability. Related capability patterns can be grouped together into Process Packages (not shown in the schema). E.g., I dene a PDCA capability pattern, which represents a widely used iterative Plan-Do-Check-Act methodology [17] dened not only in the ISO/IEC 20000 standard. Delivery Process a ow of actions (tasks in RMC) executed by some roles using work products as an input and an output with an optional support in a form of some guidance (dened below). Related delivery processes can be grouped together into Process Packages (not shown in the schema). Content Package a ne-grained level container used for grouping corresponding roles, artifacts, tasks. . . E.g., I dene method content elements of individual ISO/IEC 20000 processes (like Service level management) as separate packages in my model. Standard Category a set of logical containers grouping individual method content elements of one type into one predened group (mainly for overview purposes). This grouping is as follows: A set of Tasks is a Discipline. A set of Work Product is a Domain or a Work Product Kind (more presentation oriented [9]). A set of Roles is a Role Set. A set of Tool Mentors is a Tool.

Custom Category a group of content elements which can be dened by a process designer usually used for lucidity and reporting reasons. One specic and quite important type of a predened custom category is a View, which is a set of related RMC elements that are a base for congurating (in the meaning dened above) and exporting a process model (views are visually presented as tabs on the left of published HTML model web pages improving understandability and structuralization of the model). Role a denition of a set of related skills, competencies, and responsibilities. [9] Task a description of a unit of work assigned to a role that provides a meaningful result. [9] A task is usually divided into Steps atomic amounts of work. Work Product generally an input or an output of a task. Work products are of several types: An Artifact is typically a tangible concrete item or object. E.g., a single document. A Deliverable is a set of artifacts related to each other, usually grouped together to be delivered to internal or external party. E.g., a set of documents can be grouped into deliverable documentation. An Outcome is a state created by execution of a process or a task. E.g., a state in which a service is restored to the agreed service level is an outcome of the task Resolve incident effect in the incident management process. 17

3. S OLUTION ISO/IEC 20000 PROCESS MODEL Guidance an RMC element that adds some supplementary or additional information about one particular element, about a modelled domain as a whole or functions as a guideline for better understanding and using the model. There are many types of a guidance element; I would list some important ones that are also used in my ISO/IEC 20000 model: A Guideline provides an additional detail on how to handle a particular content element. Guidelines most commonly apply to tasks and work products. [9] A Concept outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general topics than Guidelines and span across several work products, tasks, or activities. [9] A Practice presents a proven way or strategy of doing work to achieve a goal that has a positive impact on a work product or process quality. [9] A Term Denition denes a (usually technical) word or a phrase used in a description of a content element or a content element name itself. Term denitions can be used to build up a glossary of terms usable as supporting material to exported documents. A Template species the structure of a work product by providing a predened table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions how the sections and packages are supposed to be used and completed. [9] A Report is a predened template of a result that is generated on the basis of other work products as an output from some form of tool automation. [9]

Method content variability Method content variability is an another concept in IBM Rational Method Composer used mainly for reusability purposes. Using method content variability a process designer creates an element with an inherited content and relationship with another elements derived from an existing element and then is able to modify, add or expand only characteristics specic to the new element. In [9] there is the following example: The generic Review Record artifact can be used as a base for a more special version of the review record using the Extends variability. There are several types of method content variability (each dening a special relationship among a base element and its derivates) in Method Composer, namely: Contributes A contributing element adds to the base element. The base appears in the published Web site but the contributing element does not. [9] Replaces A replacing element replaces parts of the base element. The replacer appears in the published Web site but the base element does not. [9] Extends Both the base element and its extension coexist in the published material. The extension inherits all attributes and relations of the base, but can also dene new ones or override the existing ones from the base.3
3. This method content variability type is the most similar one to the inheritance dened in object-oriented programming paradigm.

18

3. S OLUTION ISO/IEC 20000 PROCESS MODEL Extends and Replaces This variability type changes only the characteristics in the base, which were overridden in the extending element, leaving the other intact. I use mostly the Extends variability type in my ISO/IEC 20000 model to present and map the relations between the elements required in the specication of ISO/IEC 20000-1 and the consequent recommendations and extensions of these elements described in ISO/IEC 200002. Process elements and their properties Process elements in Rational Method Composer are building blocks of a process at different levels of abstraction. Generally speaking, there is the following hierarchy of process elements: Step Task Descriptor 4 Activity Iteration Phase Process. Each of the process elements above has a set of boolean properties which add another characteristics of the process element. Each following property is applicable for every element with an exception of Event Driven, Ongoing and Repeatable, which can be assigned only to Task Descriptors or Activities: Planned A planned process element is exported to Rational Team Concert. Repeatable A repeatable process element can iterate in a process instead of been executed only once. Multiple Occurrences An element with multiple occurrences property set is allowed to be initialized more than once in a delivery process lifecycle. Ongoing An ongoing process element does not have a predened start or an end of execution, i.e. it is continuous. Event-Driven An event-driven element starts depending on a state of other process elements or on an external event. Optional An optional element can be skipped while executing a process. However, in the element description there should be a condition to do that. IBM Rational Method Composer uses a set of diagrams for process designing. These diagrams are interconnected and synchronized, meaning that a change in one diagram automatically propagates to the others. E.g., adding a task performed by a specic role and using some artifacts to Work Breakdown Structure results into an update of Team Allocation schema and Work Product Usage table. The most important diagram types are (some graphical examples5 included for illustration): Work Breakdown Structure (WBS) A work breakdown structure is a hierarchical breakdown of work, such as activities, tasks, and steps, dening a process. [9] In the screenshot, there is a small portion of the Rational Unied Process WBS; a reader can see the Inception, Elaboration and expanded Construction phases with many activities nested at several abstraction levels and at the lowest level, there are task descriptors like UseCase Design, Subsystem Design. . .
4. A Task Descriptor is a term used for a concrete realization (instance) of a task (general content element) in a process. 5. Screenshots taken from the Rational Unied Process (RUP) methodology packaged within IBM Rational Method Composer default installation.

19

3. S OLUTION ISO/IEC 20000 PROCESS MODEL

Team Allocation An extended WBS with specic performers (roles) explicitly presented in a schema. Work Product Usage An extended WBS with all work products explicitly presented as an input or an output of a process element. Activity Diagram Activity diagrams show the workow of child process elements of a process, an activity, a phase or an iteration. [9] The example illustrates the activity diagram of the Develop Components activity of the Construction phase in the RUP.

20

3. S OLUTION ISO/IEC 20000 PROCESS MODEL 3.1.2 IBM Rational Team Concert and Jazz Team Server IBM Rational Team Concert is a collaborative software development environment enabling developers to collaborate together using integrated planning (with full support for Scrum), source control, work items, build, dashboards, reports and process support. [20] IBM Rational Team Concert is built around the Jazz platform, which is a scalable, extensible team-collaboration platform that integrates tasks across the software lifecycle. The platform also provides useful building blocks and frameworks that facilitate the development of new products and tools. [12] In the context of ITSM and particularly my ISO/IEC 20000 process model, IBM Rational Team Concert is essential software and a piece of process management infrastructure, because it allows the very execution of implemented processes. Its platform is therefore a central aspect of succesful ITSM solution as it makes possible monitoring, reporting, customizing and extending all service quality related processes in the organization, centralized into one tool and accessible for all associated employees enabling cooperation with the option of integration with another (already implemented in a company) tools used for successful information service provision. Although I created a model of ISO/IEC 20000 processes, I didnt export it into the environment of IBM Rational Team Concert, because the model itself reecting the standard is too general to be used directly in a process execution platform. Initially it would be necessary to customize and extend the model in process design software (IBM RMC) in accordance with: existing processes in an organization the business strategy of the organization the size of the IT division and the character of its customers (internal vs. external. . . )

Such implementation extension of the ISO/IEC 20000 model could be afterwards exported and executed as a set of service management processes in a specic organization. A discussion about the issue of ISO/IEC 20000 being too general and of course not ready for immediate execution of the shelf can be also found in the concluding chapter 5, section 5.1 (Problems encountered). IBM Rational Team Concert and Method Composer integration IBM Rational Method Composer and IBM Rational Team Concert can be integrated together to allow processes designed in RMC to be exported into IBM Rational Team Concert and Jazz Server process platform. This connection is vital, because it enables management of process execution, its monitoring and coordination among employees. One drawback of this software integration is that it is still considered beta feature and also requires exact versions of the software [8] IBM Rational Method Composer 7.5ix1 and IBM Rational Team Concert Client 1.0.1 which are not the newest ones.

21

3. S OLUTION ISO/IEC 20000 PROCESS MODEL

3.2

ISO/IEC 20000 model

In this section I describe my ISO/IEC 20000 process model developed in IBM Rational Method Composer. I chose a description from the perspective of the exported HTML version of the model, which I think should suit a reader best. I suggest that a reader follow my explanation by simultaneously browsing the HTML version, which can be found on the attached CD or at http://is.muni.cz/th/140448/ m. Additionally, I put work breakdown structures of delivery processes of the complete ISO/IEC 20000 model in the Appendix B, which could be also helpful for following my description. I created two separate models: ISO/IEC 20000-1: Specication designed after the rst part of the standard and described in following subsection ISO/IEC 20000-1 model. ISO/IEC 20000 a model of both parts of the standard containing the previous model and adding ISO/IEC 20000-2 specic elements. The appended parts are discussed in subsection ISO/IEC 20000-2 model.

Both models description structure is based on their exported HTML versions, specically on the tabs on the left side of HTML pages6 . 3.2.1 ISO/IEC 20000-1 model The structure of ISO/IEC 20000-1 model naturally reects the chapters of the rst part of the standard with small exceptions: I omitted the chapter 2 (Terms and denitions), because there is no interesting structure in the chapter to be modelled, and I used a more general and complex introduction to the standard in the tab ISO/IEC 20000 Overview than there is in the chapter 1 (Scope). The list of all tabs in the ISO/IEC 20000-1: Specication model with a summarizing description follows: ISO/IEC 20000 Overview tab contains an introduction to the standard, a reference to a webpage regarding benets of an ISO/IEC 20000 adoption, a link to a Wikipedia article about ITSM and a description of the structure of the model. Management System (Specication) tab presents a Management role, a deliverable (i.e., a set of artifacts) Documents forming core service management documentation, and a Manage staff delivery process with 3 task descriptors: Dene Roles, Skills, Manage Trainings and Communicate the Importance of Service Management. Planning and Implementing Service Management (Specication) tab illustrates the PDCA (Plan-Do-Check-Act) methodology modelled as a capability pattern with a loop. Service Management Process is a delivery process at a high level of abstraction based on the capability pattern with the following phases: 1. 2. Plan. Do with a task descriptor Implement Service Management Plans.

6. These tabs represent Conguration Views for more information, please refer to the section regarding IBM Rational Method Composer

22

3. S OLUTION ISO/IEC 20000 PROCESS MODEL 3. 4. Check with task descriptors Monitor Service Management Processes, Manage Reviews and Plan Audit. Act with a task descriptor Manage Service Improvements.

Changed or New Services (Specication) tab introduces a Change Management Process addressing modications of service in the current service environment, adding new services as well as terminating current ones. The delivery process contains a task descriptor Manage Resources for the Change Management and for each or new service provides three task descriptors: Accept Changed or New Service, Implement Changed or New Service, and Review Changed or New Service. Service Delivery (Specication) tab contains six delivery processes: Service Level Management consists of three task descriptors Manage Agreements, Monitor Service Levels and Manage SLAs operating with a signicant work product Service Level Agreement. Service Reporting has only one task descriptor Produce Service Report. Service Continuity and Availability Management comprises following task descriptors: Identify Service Continuity and Availability Requirements, Manage Service Continuity and Availability Plans, Review Service Continuity and Availability Plans, Test Service Continuity Plans, and Monitor Availability. Budgeting and Accounting for IT Services contains ve task descriptors: Budget and Account, Assign Costs, Control Finances, Monitor Costs, and Process Financial Predictions. Capacity Management has three task descriptors: Capacity Management, Manage Capacity Requirements, Manage Capacity. Information Security Management introduces the following seven task descriptors: Accept and Propagate Information Security Policy, Manage Security Control Documentation, Fulll Information Security Policy Requirements, Manage Information Security Risks, Manage Access to Systems, Manage Security Incident Procedures, and Review Security Incidents.

Relationship (Specication) tab is a set of two delivery processes: Business Relationship Management contains task descriptors: Document Customers and Stakeholders, Hold Meeting, Respond to Business Change, Process Complain, Manage Service Quality Feedback. Supplier Management contains the following task descriptors: Manage SLAs, Manage Supplier Documentation, Manage Contracts, Manage Contract Violation, Terminate Service, Monitor Supplier Efciency.

Resolution (Specication) tab encompasses two closely related delivery processes: Incident Management contains Resolve Incident Effect, Manage Incident Procedures, Communicate Incident Resolution State, Manage Information Access, Manage Major Incident task descriptors. 23

3. S OLUTION ISO/IEC 20000 PROCESS MODEL Problem Management contains the following task descriptors: Manage Problem Procedures, Manage Preventive Actions, Monitor Problem Resolution, Communicate to Incident Management.

Control (Specication) tab has two processes: Conguration Management uses a central Conguration Management Database and contains task descriptors: Plan Change and Conguration, Create Accounting Interface, Dene Conguration Item Term, Dene Conguration Item Structure, Manage Versioning Procedures, Manage Change Request, Preserve Integrity, Manage Backups, Manage CMDB, Manage Conguration Audit Procedures. Change Management contains task descriptors: Manage Reversal Methodology, Manage Emergency Methodology, Process Change Request, Implement Change and Analyze Change Records.

Release (Specication) tab denes only one delivery process: Release Management contains the following task descriptors: Establish Release Policy, Manage Release Reversal Methodology, Plan Release, Update Conguration Items and Change Records, Manage Emergency Release Methodology, Manage Test Environment, Process Release, and Analyze Release Records.

3.2.2 ISO/IEC 20000-2 model I developed the complete ISO/IEC 20000 model as a superset of the ISO/IEC 20000-1 model. The reason for this approach was that creating isolated ISO/IEC 20000-2 model is not possible, because elements in ISO/IEC 20000-2 reference strongly to ISO/IEC 20000-1 and many are based on them. So I conceptually dene the ISO/IEC 20000-2 model as an extension 7 of ISO/IEC 20000-1, and for the purpose of referencing I also add the previously dened tabs. As a result, there are two tabs for each chapter of the standard in the complete model one for the specication (based on ISO/IEC 20000-1) and the other combining ISO/IEC 20000-1 and ISO/IEC 20000-2 (forming a specied minimum enriched with the Code of Practice). In this section I therefore describe only the new content elements added from ISO/IEC 20000-2, because the baseline remains the same as in the previous model. Reminding Note: There are Work Breakdown Structures of most delivery processes in Appendix B of this paper. The tabs specic to ISO/IEC 20000-2 are: Management System (Code of Practice) tab I added a Senior Owner role functioning through ISO/IEC 20000-2 as a responsible role. The Manage Staff delivery process was expanded by the following task descriptors: Manage Recruitment, Provide Staff Records, and Measure Staff Management Effectivity. Planning and Implementing Service Management (Code of Practice) tab was expanded by adding Service Management Plan and corresponding tasks Plan Service Management, as well as work products Service Management Policy and Service Management Continual Improvement Methodology, and tasks Plan and Implement Monitoring, Measuring, Reviewing and Plan Internal Audit.
7. I use the Extends Method Content Variability type abundantly.

24

3. S OLUTION ISO/IEC 20000 PROCESS MODEL Changed or New Services (Code of Practice) tab I introduced a new task descriptor Plan Changed or New Service to the Change Management Process. Service Delivery (Code of Practice) tab contains following processes: Service Level Management was enriched by a work product Service Level Catalogue. Service Level Agreement was extended, and new task descriptors React To Changes, Provide Information About Customers, Communicate With Relevant Parties were added. Service Reporting I added a reference to new Service Reporting Policy, and information about the Service Report was extended. Service Continuity and Availability Management was enlarged by task descriptors Propagate Continuity Measures and Review Planned System Changes. Budgeting and Accounting for IT Services I added a new Financial Management Policy artifact and a React To Budget Deviation event-driven task descriptor. Capacity Management The task descriptor Manage Capacity now produces a Capacity Utilization Log. Information Security Management was complemented by a new concept Information Security Controls Practice and a task descriptor Manage Information Assets, and Manage Information Security Risks was extended and now references ISO/IEC 20000-2.

Relationship (Code of Practice) tab with two processes: Business Relationship Management The task descriptors Analyze Customer Complains Records and Measure Customer Satisfaction were added, as well as a Contract Management Guideline. Supplier Management was enriched by a new task descriptor Manage Multiple Suppliers.

Resolution (Code of Practice) tab has two processes: Incident Management introduces a new Establishing Resolution Priorities Practice, Workaround Concept, Knowledge Base and a new role Major Incident Manager. Two task descriptors were appended to the delivery process Assure Customers Business Continuity and Manage Knowledge Base. The Manage Major Incident was extended to reect the new role. Problem Management added following task descriptors: Manage Problem Escalation, Manage Incident and Problem Closure and Manage Problem Reviews.

Control (Code of Practice) tab with two processes: Conguration Management extends the Conguration Item Record artifact and includes task descriptors Manage Conguration Control Security and Manage Conguration Items Identication. Change Management adds the Change Management Scope concept and Propagate Change Schedule and Close and Review Change task descriptors. 25

3. S OLUTION ISO/IEC 20000 PROCESS MODEL Release (Code of Practice) tab with only one process: Release Management introduces a new Release Policy and adds the following task descriptors to the delivery process: Verify and Accept Release, Verify Developed and Acquired Software, Manage Release Documentation, Manage Release Installation and Analyze Post Release Incidents.

Note: The description of the model is not exhaustive, its primary purpose is to be an introductory material as it does not fully cover some topics like work products used by tasks or interdependency of delivery processes. It should be supportive and allow a reader to browse and study the standard with a help of the model.

26

Chapter 4

Sample utilization Process incident

In this chapter I demonstrate how my ISO/IEC 20000 model can be used as a base or a framework for process development in an organization. I illustrate this on the sample implementation of one process of the incident management domain (of the resolution processes as dened in ISO/IEC 20000) the Process incident delivery process implemented in a specic way, which is of course one of many possible solutions; the process developed for a real organization would be a heavily dependant on its size, business needs, customers, an existing process environment and many other circumstances and an overall situation of the company. The example uses IBM Rational Method Composer to further extend and particularize the incident management process model beyond the form dictated by ISO/IEC 20000. I developed a new method plug-in incident management example, alongside existing ones iso20000-1 and iso20000-2, acting as a container for content and process elements of this extension. Also a new conguration incident management example conguration was created solely for publication purposes. The plug-in can be found together with the other Method Composer model sources on the attached CD, where also the published HTML version was exported. I chose the following order of proceeding of this sample model creation: 1. 2. 3. 4. I extended incident management tasks dened in ISO/IEC 20000. I created a new supportive task outside of the scope of ISO/IEC 20000. I established new roles to perform these tasks. I created delivery process with an activity diagram illustrating the workow.

The detailed description of extensions and changes performed in the example follows in the consequent sections of this chapter.

4.1

Extending tasks and creating a new one

There are several tasks in the ISO/IEC 20000 model that I used as the foundation of the Process incident delivery process. I expanded them using the Extends method content variability option existing in Method Composer. I especially added some work products as an input or an output of the tasks, and also dened their steps. The summary of changes I made to the individual tasks: assure customers business continuity I dened following steps of this task: 1. 2. Analyze the current service level. Compare the current service level with the agreed level. 27

4. S AMPLE UTILIZATION P ROCESS INCIDENT 3. 4. 5. Perform technical changes to the infrastructure. Create records about technical changes to the infrastructure. Monitor changes to the current service level.

Also I added service level agreement and current service levels state information as an input, conguration item record as an optional input, and conguration item record and conguration item change record as an output to propagate all changes of the hardware and software infrastructure to the conguration management database and creating a record about them. resolve incident effect I dened following steps: 1. 2. 3. 4. 5. Analyze the current service level. Consult the knowledge base. Perform technical changes to the infrastructure. Create records about technical changes to the infrastructure. Update the knowledge base.

Also I added knowledge base, conguration item record and current service levels as an input; conguration item record as an optional input; and knowledge base, conguration item record and conguration item change record as an output. communicate incident resolution state I left this task in the form dened in the ISO/IEC 20000. manage major incident I added knowledge base as an input, conguration item record as an optional input; and conguration item record, conguration item change record and knowledge base as an output of the task. I did not specify any steps to this task, because the major incident manager is supposed to resolve the situation agilely.

Together with extending the tasks existing in ISO/IEC 20000 model, I created a new task accept incident a starting point of the Process incident delivery process collecting data about an incident from the customer and creating an initial incident record.

4.2

Establishing new roles

I created two new roles (as an extension of the general role Service provider): A help desk operator. An IT specialist. I used the following assignment of roles to tasks: A help desk operator a primary performer of the accept incident and communicate incident resolution state tasks. A customer an additional performer of the accept incident task. An IT specialist a primary performer of the tasks resolve incident effect, assure customers business continuity and manage major incident. 28

4. S AMPLE UTILIZATION P ROCESS INCIDENT An incident manager an extension to Service provider and an additional performer of all tasks in the meaning of a supervising role. An major incident manager a primary performer of the manage major incidents as predened in the ISO/IEC 20000 model.

4.3

Designing a delivery process

Having all the necessary tasks prepared, I designed the Process incident delivery process by creating task descriptors referencing the tasks and considering, which appropriate properties to set. E.g., I set the Planned property for all task descriptors to enable an export of all processes into the IBM Rational Team Concert process environment. The nal WBS1 (exported from IBM Rational Method Composer) of the process is:

1. Work Breakdown Structure showing task descriptors, roles and work products.

29

4. S AMPLE UTILIZATION P ROCESS INCIDENT

Afterwards, I created the following activity diagram for the delivery process:

30

4. S AMPLE UTILIZATION P ROCESS INCIDENT The activity diagram shows the workow. The basic elements of the schema are ve task descriptors. Arrows represent a control ow sequence. The two circles stand for start and termination of the process; the single one is the start and the double circle is the end. The two horizontal bars are so-called fork and join elements representing a split of the workow allowing the parallel execution. The diamond is a if-condition decision the workow course depends on the condition, whether the incident is considered major or not. The lower diamond merges both paths. The nal sample incident management process model is at a such level of detail, that it can be exported from IBM Rational Method Composer and applied or integrated in some process execution platforms (e.g., to the Jazz Team Server introduced in previous chapters). The main benet of using the ISO/IEC 20000 model as a framework for process development specic to needs of some company is the fact that the resulting process is inherently complying with the standard and therefore contains the experience and knowledge of the standard and is also certiable against it. Note: The presented delivery process is quite simple (e.g., it does not propagate the incident to higher levels of support). The main purpose of this demonstration is to illustrate the way how the ISO/IEC 20000 model can be applied and further expanded. The real delivery processes based on the model would certainly be more complex.

31

Chapter 5

Conclusion
The thesis studied the rst international standard for IT service management (ITSM) ISO/IEC 20000. The paper introduced a general concept of ITSM and corresponding quality assurance (QA) in a service domain with examples of existing ITSM frameworks. The importance of using dynamic processing platform instead of a collection of static method documentation for a succesful QA solution was emphasised. Based on this fact, the main intent of the thesis was to develop a process model reecting best practices contained in ISO/IEC 20000. The IBM Rational Method Composer a process design software was chosen as an appropriate tool. The resulting process model has two primary usages: The published version in HTML is suitable for reading and browsing. It shows the structure and depicts important concepts and elements of the standard. It could be used as a supplemental material during an analysis or a study of ISO/IEC 20000. The model itself can be further extended and customized for organizations needs in Method Composer. A resulting process collection would inherently contain knowledge and experience of ISO/IEC 20000 and could be deployed onto some processing platform for direct execution.

The second usage was also demonstrated on a sample practical implementation of one process of the incident management domain serving as a proof of concept of my submitted model.

5.1

Problems encountered

In the end, I would like to list some interesting problems I had working out the thesis, especially related to my ISO/IEC 20000 model: IBM Rational Method Composer is a tool suitable for designing processes. My assignment was to create a model of ISO/IEC 20000, which is in fact a set of requirements posed on processes. However, requirements cannot be properly described in RMC. Therefore I developed a minimal process model, that fullls the requirements. The change is more conceptual than factual instead of stating There should be a process, that. . . (a requirement), I describe a process, that. . . . There is a problem developing a process model that is general and based on ISO/IEC 20000, because the standard itself does not dene or contain many service management roles, lacks an exact order in which tasks should be performed and so on. The implication of this is that many of the processes in my model are not real processes in the general sense, because there are many processes without performing role specied and there is no workow or an activity diagram. This means that the model is 32

5. C ONCLUSION not suitable for direct exportation to some process execution environment (e.g., IBM Rational Team Concert), rather it should be conceived as a process framework, that needs a customization based on service providers conditions. The general problem with modelling anything is that a modeller has to determine and choose an appropriate level of abstraction, on which the model represents the reality. I tried to use a such level that ts the initial purpose of the thesis to create a model showing the structure and main concepts of the standard ISO/IEC 20000.

33

Bibliography
[1] R. Addy. Effective IT Service Management. Springer, 2007. [2] How to develop, implement and enforce ITIL V3s best practices, 2008. Art of Service. [3] Capability Maturity Model Integration (CMMI) website. http://www.sei.cmu.edu/cmmi/. Software Engineering Institute, Carnegie Mellon; 10 January 2010. [4] Wikipedia article about COBIT. http://en.wikipedia.org/wiki/COBIT. 25 July 2009. [5] J. Dugmore and A. Holt. ISO/IEC 20000 and ITIL The Difference Explained. http://www.best-management-practice.com/Knowledge-Centre/GuestWriter/ITIL/?DI=571307. 10 January 2010. [6] J. Dugmore and S. Taylor. ITIL V3 and ISO/IEC 20000. http://www.best-managementpractice.com/gempdf/ITIL and ISO 20000 March08.pdf. [7] Van Haren. Implementing ISO/IEC 20000 Certication: The Roadmap. Van Haren Publishing, 2008. [8] Peter Haumer. How to document your teams processes for IBM Rational Team Concert using IBM Rational Method Composer. http://www.ibm.com/developerworks/edu/dw-r-methods-team-concert.html. IBM developerWorks, 24 December 2008. [9] IBM Corporation. IBM Rational Method Composer Help, 2008. version 7.5.0. [10] IBM Corporation. IBM Rational Team Concert Help, 2008. version 1.0.1. [11] Ofcial ITIL website. http://www.itil.co.uk/. 18 March 2009. [12] Jazz Team Server website. http://jazz.net/projects/jazz-foundation/. 10 January 2010. [13] Komentovany norem ISO 20000, 2008. studijn materi al k p redm etu FI:PA088 vyklad Syst emy integrovan eho managementu. [14] Microsoft operations framework website. http://technet.microsoft.com/en-us/solutionaccelerators/dd320379.aspx. 10 January 2010. [15] Wikipedia article about Microsoft Operations Framework. http://en.wikipedia.org/wiki/Microsoft Operations Framework. 12 November 2008. [16] Ofce of Government Commerce. Introduction to ITIL. The Stationery Ofce, 2007. 34

B IBLIOGRAPHY [17] Wikipedia article about PDCA methodology. http://en.wikipedia.org/wiki/PDCA. 18 September 2009. [18] Ofcial PRINCE2 website. http://www.ogc.gov.uk/methods prince 2 overview.asp. Ofce of Government Commerce, UK; 13 July 2009. [19] Wikipedia article about PRINCE. http://en.wikipedia.org/wiki/PRINCE. 15 December 2009. [20] Rational Team Concert website. 10 January 2010. http://jazz.net/projects/rational-team-concert/.

[21] George Spafford. Making the case for ITSM in a down economy. http://searchdatacenter.techtarget.com/tip/0,289483,sid80 gci1360887,00.html. 10 January 2010. [22] Zad avac dokumentace ve rejn e zak azky 114071-9038 Informa cn syst em ve rejnych registru. http://www.mvcr.cz/soubor/informacni-system-zakladnich-registru 31 August 2009. implementace-informacniho-systemu.aspx. Ministerstvo vnitra CR, [23] Cesk y cn institut. CSN ISO/IEC 20000-1, 2006. Informa cn technologie normaliza ast 1: Specikace. Management slu zeb C [24] Cesk y cn institut. CSN ISO/IEC 20000-2, 2007. Informa cn technologie normaliza ast 2: Soubor postupu. Management slu zeb C

35

Appendix A Contents of the attached CD

The following les are included on the CD attached to the paper version of this thesis: RMC sources.zip A method library for IBM Rational Method Composer containing the ISO/IEC 20000 process model (including example from the chapter 4). iso20000-1 html.zip The rst part of the model based on ISO/IEC 20000-1 published as HTML. iso20000 html.zip The entire model based on ISO/IEC 20000 published as HTML. incident management example html.zip An example of the model usage discussed in the chapter 4 published as HTML. dp.pdf A PDF version of this report. dp src.zip LaTeX sources (including images) used for publishing the thesis.

Note: The les can be also obtained at: http://is.muni.cz/th/140448/ m

36

Appendix B Work Breakdown Structures of the ISO/IEC 20000 process model

37

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

38

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

39

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

40

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

41

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

42

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

43

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

44

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

45

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

46

A PPENDIX B WBS OF THE ISO/IEC 20000 PROCESS MODEL

47