implementation iso 20k in ibm rational composer

7/15/2019 Implementation Iso 20k in Ibm Rational Composer

http://slidepdf.com/reader/full/implementation-iso-20k-in-ibm-rational-composer 1/52

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

} w ¡ ¢ £ ¤ ¥ ¦ § ¨ !"#$%& 1 2 3 4 5 6 7 8 9 @ A CDEFGHIPQRS ` y e |

Implementation ofISO/IEC 20000 Standard

in IBM Rational Method Composer

DIPLOMA THESIS

Tomas 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 Pavlovic, Ph.D.

ii



Acknowledgement

I thank RNDr. Jan Pavlovic, 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 pa-

per describes ITSM and quality of service problems in general and summarizes existing so-

lutions 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

v



Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 General ITSM introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Importance of process tools . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 ITSM frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Information technology infrastructure library (ITIL) . . . . . . . . . . . 42.2.2 Control Objectives for Information and related Technology (COBIT) . 6

2.2.3 Microsoft Operations Framework (MOF) . . . . . . . . . . . . . . . . . 7

2.2.4 Capability Maturity Model Integration (CMMI) . . . . . . . . . . . . . 8

2.2.5 PRojects IN Controlled Environments (PRINCE2) . . . . . . . . . . . . 8

2.2.6 Key ITSM framework characteristics . . . . . . . . . . . . . . . . . . . . 9

2.3 ISO/IEC 20000 and its structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Benefits of ISO/IEC 20000 adoption . . . . . . . . . . . . . . . . . . . . 10

2.3.2 Structure of ISO/IEC 20000 and defined processes . . . . . . . . . . . . 10

2.3.3 ISO/IEC 20000 and ITIL relation . . . . . . . . . . . . . . . . . . . . . . 13

2.3.4 Issues of ISO/IEC 20000 implementing in an organization . . . . . . . 13

3 Solution – ISO/IEC 20000 process model . . . . . . . . . . . . . . . . . . . . . . . . 153.1 Technologies used for ISO/IEC 20000 modelling . . . . . . . . . . . . . . . . . 15

3.1.1 IBM Rational Method Composer and its concepts . . . . . . . . . . . . 15

3.1.2 IBM Rational Team Concert and Jazz Team Server . . . . . . . . . . . . 21

3.2 ISO/IEC 20000 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 ISO/IEC 20000-1 model . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 ISO/IEC 20000-2 model . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Sample utilization – Process incident . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Extending tasks and creating a new one . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Establishing new roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Designing a delivery process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1 Problems encountered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Appendix A – Contents of the attached CD . . . . . . . . . . . . . . . . . . . . . . . . . 36

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

1



Chapter 1

Introduction

The thesis is dedicated to a study of a domain of information technology service manage-

ment (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 first chapter comprises the introduction to the thesis and its structure.

The second chapter analyses the problem of information technology service manage-

ment and corresponding issues of quality assurance. Some of the major process frameworksare presented, especially IT Infrastructure Library (ITIL) and ISO/IEC 20000; differences be-

tween these two are also discussed.

The third chapter covers IBM software platforms for process designing and implemen-

tation – IBM Method Composer and IBM Team Concert. The model of ISO/IEC 20000 pro-

cesses 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 final fifth chapter summarizes the work done with a list of interesting issues, which

I had while elaborating the thesis, including solutions I used.

2



Chapter 2

Problem analysis

2.1 General ITSM introduction

ITSM stands for ”Information Technology Service Management” and represents an inte-

grated approach to govern IT service provision. First of all, I would mention a definition

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 Dictio-

nary of Contemporary English), or ”the particular skills that someone has and can offer to others”

(Cambridge Advanced Learner’s 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, admin-

istering hardware to more business-aligned ones, e.g. business process restructuralization.

A quite interesting and embracive definition 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 efficiently 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

benefits gained by the Quality Assurance practice of IT services can be:

• Improving customer’s satisfaction.

• Reducing resources consumption.

• Aligning IT strategy with general business strategy.

• Better understanding of internal operations because of better monitoring and report-ing.

However, a proper implementation of ITSM principles and QMS (Quality Management

Systems) for IT services is difficult 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 provider’s business culture and consequently overall em-

ployee’s conception of service provision needs to be customer-centered. Unless this

3



2. PROBLEM 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 companyneeds a flexible 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 essentialsustainability 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. Benefits 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 dedicatedonly to the domain of IT services, but I also mention some approaches, which are more gen-

eral, 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 devel-

oped in the 1980s by British government’s Central Computer and Telecommunications Agency

(CCTA), at the present time fully integrated into Office of Government Commerce (OCG).

The main reason for its creation was growing dependence of companies on information tech-

nologies and also a shift of IT perspective from just application development to more com-

plex 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 ITIL’s 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

4



2. PROBLEM 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 guid-ance for smaller IT organizations or divisions.

Actual version of ITIL is ITIL V3 released in 2007. It is structured based on a service life-

cycle, 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 five 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 benefits for a customer.

2. taken from http://www.bmc.com/USA/Communities/attachments/BMC BPWP ITIL Version 3 BSM.pdf

5



2. PROBLEM ANALYSIS

Service Design provides guidance on the development and maintenance of information

technology policies, documents, and architectures for the design of IT service solu-

tions. 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 ”excel-

lence”. It embraces many of the disciplines defined within the previous version of ITIL.

[11]

Continual Service Improvement embraces service quality in the context of continual im-

provement, and also deals with the service retirement scenario. [11]

Some of ITIL benefits 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 prac-

tices 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: Define a Strategic IT Plan and Direction,

Define the Information Architecture, Determine Technological Direction, Define the IT

Processes, Organization and Relationships, Manage the IT Investment, Communicate

Management Aims and Direction, Manage IT Human Resources, Manage Quality, As-

sess and Manage IT Risks, Manage Projects.

Acquire and Implement – covers identifying IT requirements, acquiring the technology,

and implementing it within the company’s current business processes. This domainalso 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 Oper-

ation 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 cov-

ers 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 efficient execution of

these IT systems. These support processes include security issues and training. [ 4]

6



2. PROBLEM ANALYSIS

It contains following processes: Define and Manage Service Levels, Manage Third-

party Services, Manage Performance and Capacity, Ensure Continuous Service, Ensure

Systems Security, Identify and Allocate Costs, Educate and Train Users, Manage Ser-

vice Desk and Incidents, Manage the Configuration, Manage Problems, Manage Data,Manage the Physical Environment, Manage Operations.

Monitor and Evaluate – deals with a company’s strategy in assessing the needs of the com-

pany 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 company’s control processes

by internal and external auditors. [4]

It contains following processes: Monitor and Evaluate IT Processes, Monitor and Eval-

uate Internal Control, Ensure Regulatory Compliance, Provide IT Governance.

2.2.3 Microsoft Operations Framework (MOF)

Microsoft Operation Framework (MOF) is another framework designed specifically for the

ITSM domain. MOF 4.0 was created in 2008 to provide guidance across the entire IT lifecycle

[14].

7



2. PROBLEM ANALYSIS

MOF represents a service lifecycle as three phases Plan, Deliver, Operate and one gov-

erning 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 im-

prove 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 pro-

cesses, and provide a point of reference for appraising current processes. [3]

The following table shows five 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 ITSM-

specific methodologies.

2.2.5 PRojects IN Controlled Environments (PRINCE2)

PRINCE2 is a scalable project management method developed by the British Office of Gov-

ernment 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

8



2. PROBLEM 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, flexible 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 Office of Gov-

ernment 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 characteristicsWhile 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 method-

ology that should be considered:

• a certification body or auditor availability, e.g. regionally.

• a fact, if a given framework is specific 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 provider’s organization.

Additionally, I would like to mention an idea, that ”gaining a competitive advantage”should not be considered as a benefit 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 benefit is in taking the framework as a baseline, a spring-

board, 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 do-

main. It was released in December 2005 jointly by the International Organization for Stan-

dardization (ISO) and the International Electrotechnical Commission (IEC). ISO/IEC 20000

9



2. PROBLEM ANALYSIS

is the successor of the British Standard BS 15000, which was developed in the year 2000 to

reflect 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 provider’s organization internal needs. The standard can be usedequally in both ways.

ISO/IEC 20000 consists of two parts: The first part (denoted as ISO/IEC 20000-1: Specifi-

cation) is mostly a description of a set of processes and requirements imposed on them (i.e.

a definition what a given process should encompass). The second part (ISO/IEC 20000-2:

Code of Practice) expands each process from the first part with additional recommendations

based on contemporary ITSM experience.

2.3.1 Benefits of ISO/IEC 20000 adoption

There are several possible benefits 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 modified 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 efficient planning of future service demands.

•

obtaining the ISO/IEC 20000 certification by an auditor demonstrating the serviceprovider’s will and commitment to addressing service quality problems. The certifica-

tion can also be the formal prerequisite for gaining a significant customer or winning

a public selection procedure4.

2.3.2 Structure of ISO/IEC 20000 and defined processes

As stated above, ISO/IEC 20000 is divided into two parts:

ISO/IEC 20000-1: Specification is in fact a set of requirements, which must be fulfilled 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 pro-

cess.. . ”). A service provider adopts ISO/IEC 20000-1 by creating processes satisfy-

ing 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 certified, making it an essential doc-

ument for auditors.

ISO/IEC 20000-2: Code of Practice further extends processes defined in the specification 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 theCzech Ministry of internal affairs also requires that the contractor is ISO/IEC 20000 certified. [ 22]

10



2. PROBLEM ANALYSIS

knowledge and experience of the ITSM industry. This part is not considered ”manda-

tory” in the context of auditing and achieving ISO/IEC 20000 certifications, rather sug-

gestive – 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 con-

tent 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 defined 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 standard’s purpose.

2. Terms and definitions – a list of rigidly defined technical words and phrases used through-

out the text.

3. Requirements for a management system – contains specification of documentation, du-

ties of service managers and a section regarding staffing for service roles. These threeaspects are considered to be a core for a service management system creating an inte-

gral process framework.

4. Planning and implementing service management – introduces a concept of service man-

agement process lifecycle based on an iterative methodology known as Plan-Do-Check-

Act. 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. PROBLEM 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 over-

seeing the service provision. There are following processes specified:

6.1 Service level management – manages a definition, an agreement with a customer

and monitoring of a service level (i.e., characteristics7 describing quality of a ser-

vice at one moment in time).

6.2 Service reporting – creates service reports.

6.3 Service continuity and availability management – guarantees that a service is op-

erable 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 res-

olution 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 coop-

eration between a service provider and its customers – service consumers. An

investigation of customer’s business needs is a necessity.

7.2 Supplier management – manages a partnership with service provider’s suppliers

– both direct and indirect – by rigidly defining service terms that a supplier pro-

vides.

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. PROBLEM 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 customer’s 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 provider’s

assets management:

9.1 Configuration management – provides an unified access to information about ser-

vice provider’s properties – both material and immaterial (for example patents).

9.2 Change management – grants a controlled methods for requesting changes in an

organization’s assets or infrastructure and approving them.

10. Release process – there is only one process in the tenth and final 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, concep-

tual and process ones. The main conceptual difference is a fact, that ISO/IEC 20000 (primar-

ily its first 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/IEC20000. 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 defined approach to business relationship and sup-

plier 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 in-

cludes advice and options for some aspects of organizational structure. [5] Specialistadvice 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 specification, 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 impor-

tant are:

13



2. PROBLEM 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 recommenda-

tions and advices (part 2). Unfortunately, there is no official 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 provider’s size, nothing like the Small-

Scale 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 first step, your ITIL imple-

mentation effort may result in the automation of the ability to apologize for downtime,

security events and so on.”

2. Configuration management

3. Incident management

4. Problem management

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 first 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 feature-

rich 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 specific 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 defines 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 modifications 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 conceptsand 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 anyspecific organization.

15



3. SOLUTION – 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 ele-

ments and processes. E.g., I define two method plug-ins in my model, iso20000-1 andiso20000-2 as collections of contents and processes of each part of the standard.

Configuration – a logical element specific only to publishing documents by RMC. A method

configuration defines which corresponding parts of a method library should be pub-

lished as a single document (like HTML or PDF). E.g., I use configurations iso20000-1

representing only first part of the standard (i.e. specification) 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




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 theschema). E.g., I define a PDCA capability pattern, which represents a widely used it-

erative Plan-Do-Check-Act methodology [17] defined not only in the ISO/IEC 20000

standard.

Delivery Process – a flow 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 guid-

ance (defined below). Related delivery processes can be grouped together into Process

Packages (not shown in the schema).

Content Package – a fine-grained level container used for grouping corresponding roles,

artifacts, tasks.. . E.g., I define method content elements of individual ISO/IEC 20000processes (like Service level management) as separate packages in my model.

Standard Category – a set of logical containers grouping individual method content ele-

ments of one type into one predefined 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 defined by a process designer

usually used for lucidity and reporting reasons. One specific and quite important type

of a predefined custom category is a View, which is a set of related RMC elements that

are a base for configurating (in the meaning defined 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 definition 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




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/IEC20000 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 Definition defines a (usually technical) word or a phrase used in a de-scription of a content element or a content element name itself. Term definitions

can be used to build up a glossary of terms usable as supporting material to ex-

ported documents.

• A Template specifies the structure of a work product by providing a predefined

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 predefined 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 specific 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 defining 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 define 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 defined in object-orientedprogramming paradigm.

18




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 specification of ISO/IEC 20000-1 and the

consequent recommendations and extensions of these elements described in ISO/IEC 20000-

2.

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 ele-

ments: 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 ele-

ment 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 predefined start or an end of exe-

cution, i.e. it is continuous.Event-Driven – An event-driven element starts depending on a state of other process ele-

ments 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 au-

tomatically propagates to the others. E.g., adding a task performed by a specific role and

using some artifacts to Work Breakdown Structure results into an update of Team Alloca-

tion 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 break-

down of work, such as activities, tasks, and steps, defining a process. [ 9] In the screen-

shot, there is a small portion of the Rational Unified 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 Use-

Case Design, Subsystem Design. . .

4. A Task Descriptor is a term used for a concrete realization (instance) of a task (general content element) ina process.

5. Screenshots taken from the Rational Unified Process (RUP) methodology packaged within IBM RationalMethod Composer default installation.

19




Team Allocation – An extended WBS with specific 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 workflow of child process elements of a pro-

cess, 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.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, ex-

tensible team-collaboration platform that integrates tasks across the software lifecycle. The

platform also provides useful building blocks and frameworks that facilitate the develop-

ment 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, be-

cause it allows the very execution of implemented processes. Its platform is therefore a cen-

tral aspect of succesful ITSM solution as it makes possible monitoring, reporting, customiz-

ing and extending all service quality related processes in the organization, centralized into

one tool and accessible for all associated employees enabling cooperation with the optionof 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 didn’t export it into the envi-

ronment of IBM Rational Team Concert, because the model itself reflecting 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 soft-

ware (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 specific 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 togetherto 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.5ifix1

and IBM Rational Team Concert Client 1.0.1 – which are not the newest ones.

21




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 ver-sion 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/fi m. Additionally, I put work breakdown struc-

tures 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: Specification – designed after the first part of the standard and de-

scribed in following subsection ISO/IEC 20000-1 model.

•

ISO/IEC 20000 – a model of both parts of the standard containing the previous modeland adding ISO/IEC 20000-2 specific elements. The appended parts are discussed in

subsection ISO/IEC 20000-2 model.

Both models description structure is based on their exported HTML versions, specifically

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 reflects the chapters of the first part of

the standard with small exceptions: I omitted the chapter 2 (Terms and definitions), 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: Specification model with

a summarizing description follows:

ISO/IEC 20000 Overview tab – contains an introduction to the standard, a reference to a web-

page regarding benefits 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 (Specification) 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: Define Roles, Skills, Manage Train-

ings and Communicate the Importance of Service Management.

Planning and Implementing Service Management (Specification) tab – illustrates the PDCA

(Plan-Do-Check-Act) methodology modelled as a capability pattern with a loop. Ser-

vice Management Process is a delivery process at a high level of abstraction based on the

capability pattern with the following phases:

1. Plan.

2. Do with a task descriptor Implement Service Management Plans.

6. These tabs represent Configuration Views – for more information, please refer to the section regarding IBMRational Method Composer

22




3. Check with task descriptors Monitor Service Management Processes, Manage Reviews

and Plan Audit.

4. Act with a task descriptor Manage Service Improvements.

Changed or New Services (Specification) tab – introduces a Change Management Process ad-

dressing modifications of service in the current service environment, adding new ser-

vices as well as terminating current ones. The delivery process contains a task descrip-

tor 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 (Specification) tab – contains six delivery processes:

• Service Level Management consists of three task descriptors Manage Agreements,

Monitor Service Levels and Manage SLAs operating with a significant work product– Service Level Agreement.

• Service Reporting has only one task descriptor Produce Service Report.

• Service Continuity and Availability Management comprises following task de-

scriptors: 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 five 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 descrip-

tors: Accept and Propagate Information Security Policy, Manage Security Control Docu-

mentation, Fulfill Information Security Policy Requirements, Manage Information Secu-

rity Risks, Manage Access to Systems, Manage Security Incident Procedures,and Review

Security Incidents.

Relationship (Specification) tab – is a set of two delivery processes:

• Business Relationship Management contains task descriptors: Document Cus-tomers and Stakeholders, Hold Meeting, Respond to Business Change, Process Complain,

Manage Service Quality Feedback .

• Supplier Management contains the following task descriptors: Manage SLAs, Man-

age Supplier Documentation, Manage Contracts, Manage Contract Violation, Terminate

Service, Monitor Supplier Efficiency.

Resolution (Specification) 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 In-

cident task descriptors.

23




• Problem Management contains the following task descriptors: Manage Problem

Procedures, Manage Preventive Actions, Monitor Problem Resolution, Communicate to

Incident Management.

Control (Specification) tab – has two processes:

• Configuration Management uses a central Configuration Management Database and

contains task descriptors: Plan Change and Configuration, Create Accounting Inter-

face, Define Configuration Item Term, Define Configuration Item Structure, Manage

Versioning Procedures, Manage Change Request, Preserve Integrity, Manage Backups,

Manage CMDB, Manage Configuration Audit Procedures.

• Change Management contains task descriptors: Manage Reversal Methodology, Man-

age Emergency Methodology, Process Change Request, Implement Change and Analyze

Change Records.

Release (Specification) tab – defines only one delivery process:

• Release Management contains the following task descriptors: Establish Release

Policy, Manage Release Reversal Methodology, Plan Release, Update Configuration Items

and Change Records, Manage Emergency Release Methodology, Manage Test Environ-

ment, 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 possi-

ble, because elements in ISO/IEC 20000-2 reference strongly to ISO/IEC 20000-1 and manyare based on them. So I conceptually define 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 defined tabs.

As a result, there are two tabs for each chapter of the standard in the complete model – one

for the specification (based on ISO/IEC 20000-1) and the other combining ISO/IEC 20000-1

and ISO/IEC 20000-2 (forming a specified 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 specific to ISO/IEC 20000-2 are:

Management System (Code of Practice) tab –Iaddeda 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 Mea-

sure 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, Review-

ing and Plan Internal Audit.

7. I use the Extends Method Content Variability type abundantly.

24




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 Cat-

alogue. 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 infor-

mation about the Service Report was extended.

• Service Continuity and Availability Management was enlarged by task descrip-

tors Propagate Continuity Measures and Review Planned System Changes.

•

Budgeting and Accounting for IT Services I added a new Financial ManagementPolicy artifact and a React To Budget Deviation event-driven task descriptor.

• Capacity Management The task descriptor Manage Capacity now produces a Ca-

pacity Utilization Log.

• Information Security Management was complemented by a new concept Infor-

mation 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 Com- plains 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 Customer’s Busi-

ness Continuity and Manage Knowledge Base. The Manage Major Incident was ex-tended to reflect the new role.

• Problem Management added following task descriptors: Manage Problem Escala-

tion, Manage Incident and Problem Closure and Manage Problem Reviews.

Control (Code of Practice) tab – with two processes:

• Configuration Management extends the Configuration Item Record artifact and in-

cludes task descriptors Manage Configuration Control Security and Manage Configu-

ration Items Identification.

• Change Management adds the Change Management Scope concept and Propagate

Change Schedule and Close and Review Change task descriptors.

25




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 frame-

work for process development in an organization. I illustrate this on the sample implemen-

tation of one process of the incident management domain (of the resolution processes as

defined in ISO/IEC 20000) – the Process incident delivery process – implemented in a specific

way, which is of course one of many possible solutions; the process developed for a real or-

ganization 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 particular-

ize 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 configuration incident management example configuration 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. I extended incident management tasks defined in ISO/IEC 20000.

2. I created a new supportive task outside of the scope of ISO/IEC 20000.

3. I established new roles to perform these tasks.

4. I created delivery process with an activity diagram illustrating the workflow.

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 Pro-

cess 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 defined their steps. The summary of changes I made to the

individual tasks:

• assure customers business continuity – I defined following steps of this task:

1. Analyze the current service level.

2. Compare the current service level with the agreed level.

27



4. SAMPLE UTILIZATION – PROCESS INCIDENT

3. Perform technical changes to the infrastructure.

4. Create records about technical changes to the infrastructure.

5. Monitor changes to the current service level.Also I added service level agreement and current service levels state information as an

input, configuration item record as an optional input, and configuration item record and

configuration item change record as an output to propagate all changes of the hardware

and software infrastructure to the configuration management database and creating

a record about them.

• resolve incident effect – I defined following steps:

1. Analyze the current service level.

2. Consult the knowledge base.

3. Perform technical changes to the infrastructure.

4. Create records about technical changes to the infrastructure.

5. Update the knowledge base.

Also I added knowledge base, configuration item record and current service levels as an in-

put; configuration item record as an optional input; and knowledge base, configuration item record

and configuration item change record as an output.

• communicate incident resolution state – I left this task in the form defined in the

ISO/IEC 20000.

• manage major incident – I added knowledge base as an input, configuration item recordas an optional input; and configuration item record, configuration 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




• 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 aspredefined 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 proper-

ties 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 final WBS1 (ex-

ported from IBM Rational Method Composer) of the process is:

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

29




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

30




The activity diagram shows the workflow. The basic elements of the schema are five task

descriptors. Arrows represent a control flow sequence. The two circles stand for start and ter-

mination 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 workflowallowing the parallel execution. The diamond is a ”if-condition” decision – the workflow

course depends on the condition, whether the incident is considered major or not. The lower

diamond merges both paths.

The final 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 benefit of using the ISO/IEC 20000 model as a framework for process develop-

ment specific 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 certifiable against it.

Note: The presented delivery process is quite simple (e.g., it does not propagate the in-

cident 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 first 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 reflecting 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 organization’s 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 plat-

form 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, espe-

cially related to my ISO/IEC 20000 model:

•

IBM Rational Method Composer is a tool suitable for designing processes. My assign-ment 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 fulfills 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 define or contain many service manage-

ment 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 spec-

ified and there is no ”workflow” or an activity diagram. This means that the model is

32



5. CONCLUSION

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 provider’s 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 fits 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 V3’s 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/Guest-

Writer/ITIL/?DI=571307. 10 January 2010.

[6] J. Dugmore and S. Taylor. ITIL V3 and ISO/IEC 20000. http://www.best-management-

practice.com/gempdf/ITIL and ISO 20000 March08.pdf.

[7] Van Haren. Implementing ISO/IEC 20000 Certification: The Roadmap . Van Haren

Publishing, 2008.

[8] Peter Haumer. How to document your team’s 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] Official 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 vyklad norem ISO 20000, 2008. studijnı material k predmetu FI:PA088

Systemy integrovaneho 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] Office of Government Commerce. Introduction to ITIL. The Stationery Office, 2007.

34



BIBLIOGRAPHY

[17] Wikipedia article about PDCA methodology.

http://en.wikipedia.org/wiki/PDCA. 18 September 2009.

[18] Official PRINCE2 website. http://www.ogc.gov.uk/methods prince 2 overview.asp.Office of Government Commerce, UK; 13 July 2009.

[19] Wikipedia article about PRINCE. http://en.wikipedia.org/wiki/PRINCE. 15 Decem-

ber 2009.

[20] Rational Team Concert website. http://jazz.net/projects/rational-team-concert/.

10 January 2010.

[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] Zadavacı dokumentace verejne zakazky 114071-9038 – Informacnı system verejnych

registru. http://www.mvcr.cz/soubor/informacni-system-zakladnich-registru-

implementace-informacniho-systemu.aspx. Ministerstvo vnitra CR, 31 August 2009.

[23] Cesky normalizacnı institut. CSN ISO/IEC 20000-1, 2006. Informacnı technologie –

Management sluzeb – Cast 1: Specifikace.

[24] Cesky normalizacnı institut. CSN ISO/IEC 20000-2, 2007. Informacnı technologie –

Management sluzeb – Cast 2: Soubor postupu.

35



Appendix A – Contents of the attached CD

The following files 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 first 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 files can be also obtained at: http://is.muni.cz/th/140448/fi m

36



Appendix B – Work Breakdown Structures of the ISO/IEC 20000 pro-

cess model

37



APPENDIX B – WBS OF THE ISO/IEC 20000 PROCESS MODEL

38




39




40




41




42




43




44




45




46