Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Diplomant: Kateřina Lukavcová Vedoucí diplomové práce: Ing. Tomáš Bruckner, Ph.D Oponent diplomové práce: Ing. Jaroslav Rokyta

Problematika implementace ITSM

školní rok 2007/2008

Poděkování Tímto bych chtěla poděkovat panu Ing. Tomáši Brucknerovi za vedení této práce a cenné rady při jejím vývoji. Touto cestou bych chtěla poděkovat také panu Antonínovi Sládkovi ze společnosti Hewlett-Packard a panu Vladimírovi Váňovi ze společnosti Autocont za jejich konzultace k této problematice a ochotu podělit se o své zkušenosti.

Prohlášení Prohlašuji, že jsem diplomovou práci zpracovala samostatně a že jsem uvedla všechny použité prameny a literaturu, ze kterých jsem čerpala.

V Praze dne ………………………………. podpis


Kateřina Lukavcová

Abstrakt Hlavním cílem této diplomové práce je identifikovat problémy (překážky, slepé uličky) vznikající při praktické implementaci problematiky popsané v knihách ITIL – procesů ITSM. Pro dosažení definovaného cíle bylo třeba prostudovat řadu odborných materiálu, metodik a standardů z oblasti řízení IT služeb (např. ITIL, Cobit, ISO 20000), závěrečná část práce je založena na výsledcích konzultací s odborníky z praxe, které byly vedeny na základě předem zpracovaného dotazníku. Celou práci lze rozdělit na dva logické celky: teoretickou a praktickou část. Struktura teoretické části a obsah jednotlivých kapitol je navržen tak, aby čtenář postupně získával přehled o pozici ITSM/ITIL v oblasti metodik a legislativních norem na úrovni řízení celé organizace. V další části práce je zmapován vztah dvou, v současné době nejvýznamnějších, přístupů k řízení IT služeb: ITSM a IT Governance. V logickém sledu následuje kapitola věnovaná jednotlivým metodikám pro procesní řízení IT služeb. V úvodu praktické části je uvedeno několik základních charakteristik jednotlivých způsobů implementace ITSM (formou interního projektu, ve státním sektoru, z pozice systémového integrátora). Závěrečná část práce je rozdělena do tří celků., které nesou stejné názvy jako hlavní stavební kameny ITSM, jsou to: lidé, nástroje a procesy. Pro každou z těchto oblastí jsem vydefinovala stručný přehled překážek a slepých uliček, se kterými se lze při praktické implementaci ITSM setkat. Hlavním přínosem této práce je právě poslední jmenovaný přehled „slepých uliček“ praktické implementace IT Service managementu. Klíčová slova Corporate Governance , IT Service Management, ITIL, IT Governance, Procesní řízení, IT služby



Abstract

The main objective of this diploma thesis is to identify the problems (restrictions, impasses) which are connected with the practical implementation described in the ITIL publication the processes of ITSM. For achieving these objectives it was necessary to study extensive library of methodologies and standards that are being used in the area of IT service management (i.e. ITIL, CobiT, and ISO 20000). The conclusion is based on the results of consultations with the practicing specialists. The form of these consultations was a questionnaire elaborated in advance. The whole thesis can be separated into two logical units: the theoretical one and the practical one. The structure of theoretical part and the content of individual chapters are designed so that the reader can progressively acquire knowledge about the position of ITSM/ITIL in the area of methodologies and legislative standards intended for operating organization as a whole. In the other part of this thesis the relationship between, actually the most prestigious, two approaches to IT service management: ITSM and IT Governance is described. The chapter presenting other similar methodologies for IT service management follows in logical sequences. The introduction of practical part is dedicated to the basic characteristics of various ways of ITSM implementation (from the position of system integrator, in the form of internal project and in the public sector). The conclusion is divided into three units of the same titles as the main headstones of ITSM, these headstones are: the people, the tools and the processes. For every single unit I have elaborated the summary of the restrictions and the impasses that can appear during practical implementation of ITSM. The main contribution of this diploma thesis is just the last-mentioned, the compilation of summary of impasses related do the practical implementation of IT Service Management. Key words Corporate Governance, IT Service Management, ITIL, IT Governance, Process management, IT services



Obsah

1.

ÚVOD .......................................................................................................................................... 2

2.

TEORETICKÁ ČÁST................................................................................................................ 4 2.1. CORPORATE GOVERNANCE .................................................................................................. 5 2.1.1. SOX 404 a informační technologie................................................................................. 6 2.2. IT GOVERNANCE ................................................................................................................. 7 2.3. IT SERVICE MANAGEMENT (ITSM) ..................................................................................... 9 2.4. ROZDÍL MEZI IT SERVICE MANAGEMENTEM A IT GOVERNANCE ....................................... 10 2.5. ITIL ................................................................................................................................... 13 2.5.1. Historie......................................................................................................................... 13 2.5.1.1. 2.5.1.2. 2.5.1.3.

ITIL verze 1 ..................................................................................................................... 14 ITIL verze 2 ...................................................................................................................... 14 ITIL verze 3 ...................................................................................................................... 16

2.5.2. ISO/IEC 20000:2005.................................................................................................... 18 2.5.3. ITIL a informační bezpečnost....................................................................................... 20 2.5.4. ITIL a procesy ITSM..................................................................................................... 21 2.6. PROCESNÍ ŘÍZENÍ ............................................................................................................... 22 2.7. MODEL PROCESNÍ VYSPĚLOSTI (CMM) ............................................................................. 24 2.8. PROJEKTOVÉ ŘÍZENÍ A IMPLEMENTACE ITSM.................................................................... 26 2.9. DALŠÍ METODIKY PRO ŘÍZENÍ IT SLUŽEB ........................................................................... 28 2.9.1. eTOM (enhanced Telecom Operations Map) ............................................................... 28 2.9.2. HP IT service management reference model................................................................ 29 2.9.3. Microsoft operations framework (MOF) ...................................................................... 29 2.9.4. Další metodiky pro řízení IT služeb – shrnutí............................................................... 30 3.

PRAKTICKÁ ČÁST ................................................................................................................ 31 3.1. IMPLEMENTACE ITSM FORMOU INTERNÍHO PROJEKTU ...................................................... 32 3.2. IMPLEMENTACE ITSM VE STÁTNÍ SPRÁVĚ ......................................................................... 35 3.3. PROBLEMATIKA IMPLEMENTACE ITSM – OBECNĚ ............................................................. 37 3.3.1. Lidé............................................................................................................................... 38 3.3.2. Nástroje ........................................................................................................................ 41 3.3.3. Procesy ......................................................................................................................... 43 3.3.3.1. 3.3.3.2. 3.3.3.3. 3.3.3.4. 3.3.3.5. 3.3.3.6. 3.3.3.7. 3.3.3.8. 3.3.3.9. 3.3.3.10. 3.3.3.11.

Service Desk ..................................................................................................................... 44 Incident Management ....................................................................................................... 46 Problem Management ....................................................................................................... 48 Konfigurační management................................................................................................ 51 Change Management ........................................................................................................ 54 Release Management ........................................................................................................ 56 Service Level Management............................................................................................... 58 Availability Management ................................................................................................. 61 Capacity Management ...................................................................................................... 63 Financial Management IT služeb ...................................................................................... 65 IT Service Continuity Management.................................................................................. 67

4.

ZÁVĚR ...................................................................................................................................... 69

5.

ZDROJE .................................................................................................................................... 72 5.1. 5.2.

ELEKTRONICKÉ ZDROJE ..................................................................................................... 72 LITERATURA ...................................................................................................................... 74

6.

TERMINOLOGICKÝ SLOVNÍK .......................................................................................... 75

7.

PŘÍLOHA 1: PŘEHLED „SLEPÝCH ULIČEK“ IMPLEMENTACE ITSM ................... 78

8.

PŘÍLOHA 2: DOTAZNÍK: PROBLEMATIKA IMPLEMENTACE ITSM...................... 80

1



1. Úvod Nejen ve své diplomové práci, ale i v praxi, do které jsem se rozhodla před dvěmi lety nastoupit, se věnuji problematice spojené s IT Service Management (ITSM). Poprvé jsem se s řízením IT služeb seznámila při svém studiu na Fakultě informatiky a statistiky na Vysoké škole ekonomické v Praze. Myšlenka, řídit IT prostřednictvím a na úrovni služeb mě hned napoprvé zaujala a to především z toho důvodu, že přesně tato úroveň mi přišla jako nejlépe srozumitelná pro zákazníka, který IT služby odebírá a hlavně, který za ně platí. Posléze jsem se tomuto „komunikačnímu nástroji“ rozhodla věnovat i profesně. Po absolvování několika odborných konferencí, přečtení příspěvků v odborných sbornících a především po absolvování prvních projektů implementace procesů ITSM v praxi, jsem došla k závěru, že mezi tím, co je uvedeno v knihách a odborných kurzech a praktickou implementací je značný rozdíl. Tím nechci tvrdit, že by byla teorie ITSM popsána chybně, tato „teorie“ vychází z nejlepších zkušenostech z praxe, tudíž její zavedení by mělo být relativně snadné, ale jak se ukazuje není tomu tak. Existuje celá řada problémů, které je při implementaci ITSM potřeba řešit. V první části mé práce se snažím popsat celý rámec řízení organizace se zaměřením na řízení IT služeb. Uvádím zde ve stručnosti vertikální i horizontální přehled metodik a přístupů k řízení IT. Přičemž středem zájmu zůstává ITSM a má snaha vymezit jeho postavení a vazby na ostatní metodiky a rámce pro řízení IT služeb (eTOM, MOF, referenční model HP IT service management). Jelikož je téma ITSM velice často spojováno s termínem IT Governance, určila jsem si za druhý cíl své práce detailněji vymezit vztah těchto disciplín – popsat jejich zaměření, vzájemné vazby a rozdíly. Do své práce jsem se rozhodla zahrnout i aktuální témata spojená s ITSM a to je uvedení „nové“ verze ITIL Refresh a mezinárodní normy ISO/IEC 20000, ve stručnosti se pokusím popsat obsah uvedených publikací i jejich vazbu na ITIL verze 2. Na základě vysvětlených termínů, principů a vazeb ITSM na ostatní oblasti řízení organizace a metodiky přecházím ve druhé části mé práce k praktickým aspektům implementace ITSM.

2



Ve své práci se pokusím sestavit souhrnný přehled překážek a slepých uliček implementace ITSM. Tohoto cíle bych chtěla dosáhnout prostřednictvím uspořádání konzultací s kolegy z oboru a na základě studia odborné literatury. Zaměřím se jak na různé způsoby implementace ITSM1, tak i na úskalí týkající se jednotlivých stavebních kamenů ITSM, kterými jsou: lidé, nástroje a procesy. V oblasti procesů ITSM bych se ráda dostala až na úroveň konkrétních problémů a slepých uliček při implementaci jednotlivých procesů. Pro upřesnění uvádím přehled cílů , které jsem si stanovila a také zamýšlené způsoby jejich dosažení. #

Definice cíle

Způsob dosažení

Vymezit postavení ITSM mezi ostatními 1

metodikami pro řízení IT služeb (eTOM,

Studium odborné literatury a zvolených

MOF, referenční model HP IT service

metodik pro řízení IT služeb.

management). Zmapovat a popsat vztah ITSM a IT 2

governance, jejich vzájemné vazby a rozdíly. Zmapovat a popsat vazby a rozdíly mezi

3

ITIL verze 2 a aktuálními tématy z oblasti ITSM tj. ISO/IEC 20000 a ITIL Refresh.

Studium odborné literatury a zvolených metodik pro řízení IT služeb. Studium normy ISO/IEC 20000. Účast na kurzu ISO 20000 for Consultants and Internal Auditors.2 Studium odborné literatury a zvolených

Identifikovat problémy (překážky, slepé 4


uličky) vznikající při praktické implementaci problematiky popsané

Konzultace s kolegy z oboru.

v knihách ITIL – procesů ITSM. Účast na odborné konferenci ICTM 2008. Tab. 1 Přehled cílů diplomové práce 1

1

tj. formou interního projektu, implementace ITSM z pozice systémového integrátora pro státní správu 2 Tvůrcem i provozovatelem kurzu je společnost Hewlett-Packard Development Company, L.P.

3



2. Teoretická část

4


2.1.


Corporate governance

Definice Corporate governance podle OECD: „Corporate governance definuje rozdělení práv a povinností mezi jednotlivé role spojené s organizací a jejím fungováním jako jsou např. představenstvo, vedení společnosti, akcionáři a další zainteresované strany. Corporate governance definuje pravidla a postupy pro rozhodování v jednotlivých záležitostech organizace.“ Zdroj: [CISA_manual, str. 72] Definice Corporate Governance: „Corporate governance je sadou postupů, pravidel a nařízení, které ovlivňují to, jakým způsobem, je organizace řízena, spravována a kontrolována. Corporate governance zahrnuje mj. i vazby mezi organizací a okolím, které jí významně ovlivňuje a cíle, ke kterým organizace směřuje. Corporate governance definuje následující role a jejich vazby k organizaci – vlastníky, management,

představenstvo/dozorčí radu, zaměstnance,

dodavatele, zákazníky, banky a jiné věřitele, regulatorní orgány, prostředí a společnost obecně. Hlavním principem corporate governance je definice jednoznačných odpovědností za jednotlivé aktivity v rámci firmy“. Zdroj [1] Zájem o corporate governance významně narostl od roku 2001 a to především díky událostem kolem amerických firem Enron a Worldcom, uvedené firmy dlouhodobě falšovaly své finanční výsledky a v konečném důsledku tím negativně ovlivnily nejen vnímání úrovně správy a řízení velkých společností, důvěryhodnost auditorů (auditorská firma Arthur Andersen dlouhodobě kryla machinace v účetních výkazech firmy Enron), ale v první řadě způsobily pokles důvěry investorů a tím i celosvětový propad finančních trhů. Jako reakci na uvedené události vydala americká vláda v roce 2002 jednu z prvních zákonných úprav corporate governance s názvem Sarbanes-Oxley Act (SOX), který zdůrazňuje význam kontroly výsledků podnikání a kontroly účetních záznamů.

5



2.1.1. SOX 404 a informační technologie „Procesní zpracování finančního reportingu a provádění vnitřních kontrol je u většiny firem závislé na podpoře IS/IT. Proto je nedílnou součástí SOX i část věnovaná opatřením k ošetření rizik spojených s IT – tato část definuje kontrolní mechanizmy, které by měli být uvnitř organizace implementovány, aby byla potenciální rizika zjištěna včas případně zcela eliminována. Definování detailních návodů a procesů pro správu a řízení IS/IT sice přesahují rámec SOX, ale SOX doporučuje pro splnění jeho požadavků použít některého z externích kontrolních rámců pro řízení a správu IT – tedy IT Governance (COSO, Cobit, ITIL)“. Zdroje [2], [3] A právě problematice procesního řízení a s tím spojených procesních rámců pro oblast IT se budu blíže zabývat, jak v teoretické tak v praktické části mé práce.

6


2.2.


IT Governance

Jak již jsem uvedla výše, IT Governance je nedílnou součástí Corporate Governance, přičemž IT Governance zastřešuje veškerou problematiku spojenou s provozováním IT/IS případně s poskytováním IT služeb. Ze strategického úhlu pohledu je úkolem IT Governance řídit aktivity IT v rámci organizace tak, aby byly zajištěny následující cíle: -

„Propojení a sjednocení byznys a IT strategie v rámci společnosti tak, aby byly oboustranně splněny předem definované požadavky a očekávání (tj. odvození IT strategie z jednotlivých cílů definovaných v byznys strategii)

-

Maximální a řízené využití příležitostí, které IT byznysu nabízí

-

Zodpovědné využívání IT zdrojů

-

Řízení rizik spojených s vývojem / pořízením / provozováním IT“ Zdroj [5]

Pro tuto úroveň řízení IT/IS je dle mého názoru nejvhodnějším rámcem COBIT. Definice IT Governance podle ISACA: „IT Governance je definovaná struktura vztahů a procesů, pomocí kterých lze řídit a kontrolovat organizaci tak, aby IT v maximální míře umožňovalo a podporovalo dosažení podnikatelských cílů. Přidanou hodnotou je redukce a řízení rizik nad procesy v IS. IT Governance ovlivňuje zvýšení efektivity organizace pomocí: -

Zajištění a zabezpečení integrity, bezpečnosti a spolehlivosti strategických a jiných citlivých informací.

-

Ochrany investic do IT a komunikací

-

Nastavení odpovídajícího vedení a řízení informačních aktiv, na nichž přímo závisí úspěch nebo přežití organizace

-

Zvyšování hodnoty podnikatelských procesů pomocí IT (vazba IT na podnikatelské procesy)“ Zdroj [5]

Organizace ISACA se podílí na vývoji rámce pro IT Governance Cobit3.

3

Popis metodiky Cobit přesahuje rámec mé práce více o metodice Cobit je uvedeno např. [4]

7



Pro úroveň taktického a operativního řízení je dle mého názoru jedním z nejvhodnějších a zároveň nejrozšířenějším rámcem ITIL/ITSM. ITIL/ITSM má tu výhodu, že díky jeho celosvětové rozšířenosti byla na jeho základech vytvořena mezinárodní norma pro řízení IT služeb ISO 20000. Po zavedení této normy lze očekávat ještě další rozšíření tohoto rámce pro řízení IT služeb. V současné době se mohou i v České republice nechat organizace certifikovat podle této mezinárodní normy. Více o ISO 20000 viz Kapitola 2.5.2 ISO/IEC 20000. ITIL/ITSM definuje následující cíle řízení IT/IS. -

Poskytovat IT služby, které jsou odvozeny z potřeb organizace

-

Poskytovat nákladově efektivní služby

-

Poskytovat IT služby v požadované kvalitě

Definice IT Governance podle ITIL „IT Governance se zabývá kooperací byznysu a IT managementu. Tato kooperace je stěžejní pro podnikové procesy, které jsou závislé na správném fungování IT. Oblasti zájmu IT Governance -

Sjednocení strategií (podniková versus IT strategie)

-

Řízení změn (change management)

-

Řízení kontinuity byznysu

-

IT Asset Management

-

Řízení zdrojů

-

Řízení znalostí“ Zdroj [5]

ITIL verze 3 lze díky posunu ke strategičtějšímu pojetí řízení IT vnímat též jako rámec pro IT Governance vhodný pro strategické řízení procesů spojených s IT službami. Zatímco ITIL verze 2 byl určen především k taktickému a operativnímu řízení IT. Více viz Kapitola 2.5.1 ITIL – Historie.

8


2.3.


IT Service Management (ITSM)

ITSM je zkratkou pro "IT Service Management” tj. systém pro řízení IT služeb. Definice ITSM dle ISO/IEC 20000 „ITSM (dle ISO/IEC 20000) zahrnuje analýzu, plánování, implementaci a kontrolu procesů spojených s řízením IT služeb poskytovaných prostřednictvím IT infrastruktury.“ Zdroj [ISO 20000_hp, str.2]. Definice ITSM dle ITIL [TO2S_BOVA] „ITSM se zabývá řízením ICT infrastruktury, ovšem nikoliv z hlediska technického, ale z hlediska výstupů (účelu, smyslu existence) této infrastruktury, jimiž je poskytování IT služeb“ [TO2S_BOVA, str. 6] Obsahem ITSM je definice procesů, které by měly být v podniku zavedeny za účelem zajištění trvale kvalitní dodávky IT služeb při vynaložení optimálních nákladů. Výhody implementace: -

„Kontinuální růst kvality poskytovaných služeb

-

Optimalizace nákladů

-

Redukce rizik

-

Zlepšení komunikace v rámci organizace (IT versus ostatní oddělení)

-

Růst produktivity

-

Schopnost přijmout větší množství změn

-

Možnost použití „best practice“

-

Auditovatelnost systému řízení IT služeb

-

Jednotná terminologie“

Zdroje: [6], [ISO_20000_HP, str. 3]

9



2.4. Rozdíl mezi IT Service Managementem a IT Governance

Cílem IT Service managementu (ITSM) je efektivní řízení IT služeb a provozu IT infrastruktury4. Cíle IT Governance se liší v čase – v pohledu současnosti jde o podporu strategických cílu organizace prostřednictvím provozu IT a IT služeb, v pohledu budoucnosti musí být IT v první řadě schopno čelit, stejně jako celá organizace, vývoji a změnám.¨ Na obrázku jsou v grafu zakresleny 2 dimenze: čas a orientace. Z umístění IT Governance je zřetelný důraz na vnější orientaci a zaměření na budoucí rozvoj, zatímco IT Service Management se orientuje na současnost a řízení interního IT a jeho provozu. Zdroj [7], [8].Zdroj: [8]

Obr. 1 IT Governance a ITSM – orientace,[Zdroj 8]

Vztah mezi ITSM a IT Governance může být popsán také tak jak je znázorněno na následujícím obrázku.

4

Pozn. Předpoklady a znalosti, ze kterých vycházím ve své práci jsou založeny na ITIL verze 2, více viz kapitola ITIL - Historie

10



IT Governance řídí strategické pojetí IT služeb a jeho propojení se strategií organizace prostřednictvím definovaných cílů a metrik jejich dosažení a zároveň zajišťuje kontrolu plnění nejen IT cílů, ale i cílů celé organizace prostřednictvím provádění nezávislých kontrol a auditu. IT Service management provádí řízení a kontrolu IT služeb a infrastruktury na každodenní bázi.

Obr. 2 IT Governance a ITSM – vzájemné vazby, Zdroj [8]

Dle mého názoru převládá v současné době mezi organizacemi v České republice spíše zájem o implementaci procesů dle ITIL/ITSM než podle zde zmiňovaného rámce Cobit pro implementaci a audit procesů IT Governance. Usuzuji, že je tomu tak proto, protože iniciativa pro kvalitnější řízení IT služeb a IT infrastruktury zatím stále přichází spíše ze strany IT, řekněme na úrovni řízení provozu IT, než ze strany vedení organizace.

11



Dle mého názoru je to skutečně převážně strana IT, která se snaží najít s ostatními částmi organizace společnou řeč a nastavit průhlednější podmínky poskytování a řízení IT služeb (situace je samozřejmě jiná, pokud se jedná o poskytovatele IT služeb – ten prostřednictvím procesů ITSM zvyšuje kvalitu a spolehlivost poskytovaných služeb vůči externímu zákazníkovi – v jeho případě je ITIL/ITSM přímo podpora jeho "core byznysu" – tedy hlavní podnikatelské činnosti a implementace IT Governance/ITIL je pak čistě strategickým rozhodnutím). Důvodů pro toto řešení je hned několik např. snaha IT „ztratit nálepku“ čistě nákladového oddělení s nejasnými kompetencemi, možnostmi a schopnostmi. Pokud je tento můj předpoklad správný, je logické, že je častěji zastoupen rámec pro taktické a operativní řízení IT služeb ITIL – pokud totiž vychází iniciativa od provozu, poskytuje mu ITIL nejen velice vhodný procesní rámec založený na „best practice“ pro řízení IT procesů a služeb, ale zároveň je i kvalitním komunikačním

nástrojem (např. definice SLA) pro

prosazení vize implementace řízení IT služeb u vedení společnosti. Rostoucí zájem o ITIL/ITSM5 a více či méně zdařilé příklady jeho implementace v českých společnostech byli hlavními důvody, proč jsem se rozhodla ve své práci věnovat právě problematice implementace ISTM.

5

Na rozdíl od ITIL je Cobit prozatím používán především auditory jakožto kontrolní rámec řízení IT služeb. Často se také vyskytuje kombinace obou rámců, tedy ITIL a Cobit, přičemž z ITIL jsou zastoupeny disciplíny z oblastí Service Support a Service Delivery a z Cobit jsou použity kontrolní cíle a metriky pro tyto procesy.

12


2.5.


ITIL

2.5.1. Historie6 ITIL vznikl koncem osmdesátých let minulého století ve Velké Británii.. Řízení informatiky v té době bylo omezeno na správu jednotlivých technologických komponent přidělených do správy určeným IT specialistům, kteří pracovali dalo by se říct, zcela nezávisle na chodu zbylých částí organizace. Ostatní organizační útvary nerozuměly tomu, co vlastně úsek IT dělá – ve většině případů vystupovalo IT oddělení především v roli opraváře počítačů případně správce sítí. Nebyla definovaná odpovědnost za výpadky IT služeb – protože neexistoval přístup, který by definoval závislost mezi komponentami IT infrastruktury a IT službami. Výpadky IT infrastruktury nebyly řešeny systematicky tj. správné fungování IT/IS systémů bylo často závislé na individuálních znalostech a schopnostech jednotlivých IT specialistů – tzn. řešení podobných výpadků záviselo na jednotlivých osobách a jejich přístupu. Kvalita a rychlost zpracování požadavků záviseli na osobních vazbách příp. na umístění uživatele v organizační struktuře, čím vyšší postavení tím rychlejší zpracování požadavku. Náklady na IT byly řízeny maximálně na úrovni nákupu IT komponent a SW vybavení. Přitom stále rostla složitost IT systémů, provázanost jednotlivých systémů a v neposlední řadě i závislost podniku na správně fungujícím podnikovém IT. Reakcí na tuto situaci bylo vydání „1. verze ITIL“ Britská vláda tehdy pověřila vládní organizaci CCTA (Central Computer

and

Telecommunication Agency), aby vytvořila rámec, podle kterého by mohly být nastaveny procesy v organizacích (komerčních i státních), které se zabývají poskytováním IT služeb britské vládě.

6

Informace pro tuto kapitolu jsem čerpala z [9], [TO2S_FOUN]

13



2.5.1.1. ITIL verze 1 7 ITIL (IT Infrastructure Library) neboli „Knihovna IT infrastruktury“. Knihovna z toho důvodu, že ITIL byl a stále je8 soubor knih, které se věnují problematice řízení IT služeb. V prvním vydání obsahoval ITIL celkem 46 svazků, z nichž se každý věnoval jednomu dílčímu aspektu řízení informatiky. Největší nevýhoda tohoto prvního vydání byla scházející větší provázanost jednotlivých částí.

2.5.1.2. ITIL verze 2 Druhá verze ITIL byla vydána společností OGC9 (Office of Government Commerce), která se od té původní liší především v následujícím: Zahrnuje nové poznatky související s rozvojem informatiky (zejména je zohledněn posun od mainframe systémů ke klient-server aplikacím, a rozvoj internetu). Největším úkolem, které muselo OGC zvládnout, byla konsolidace obsahu a jeho přizpůsobení komerčnímu sektoru tak, aby mohl být použit pro nastavení procesů řízení IT služeb v kterékoliv organizaci ať ze státního tak i soukromého sektoru. “Knihovna” ITIL verze 2 obsahuje devět knih: Knihy popisující procesy řízení IT služeb: 1. Service Support10 (Řízení podpory služeb) a. Service desk b. Incident management c. Problem management d. Change management e. Release management 2. Service Delivery (Řízení dodávky služeb) a. Service Level management b. Availability management 7

"Government Information Technology Infrastructure Management Methodology" (GITMM) Je dostupný i v elektronické podobě. 9 Organizace OGC vznikla spojením 3 vládních organizací z nichž jedna byla CCTA. 10 Názvy knih a procesů není zvykem překládat 8

14



c. Capacity management d. Financial management e. IT Service continuity management Provozní příručky: 3. ICT Infrastructure Management (Řízení IT infrastruktury) 4. Security Management (Řízení bezpečnosti) 5. The Business Perspective (Pohled byznysu) 6. Application Management (Řízení aplikací) 7. Software Asset Management (Řízení IT aktiv) Pro plánování a řízení implementace procesů ITSM je určena kniha: 8. Planning to Implement Service Management (Plánování implementace ITSM) Pro implementaci ITSM v menších společnostech je určena kniha: 9. ITIL Small-Scale Implementation (ITIL – implementace v malém rozsahu) Svou práci jsem se rozhodla zpracovat na základě ITIL verze 2. Jedná se o nejrozšířenější a nejpoužívanější verzi ITIL. Přesto se musím alespoň krátce zmínit také o ITIL verze 3 tj. ITIL Refresh.

15



2.5.1.3. ITIL verze 3 ITIL verze 3 byla oficiálně představena 5. června 2007. Nová verze ITIL byla vyvinuta především proto, že přibývalo výhrad k ITIL verze 2. Např. v dokumentu [ICTM_Kufner] je uvedený přehled výhrad vůči 2. verzi ITIL a důvodů pro jeho úpravu a vývoj ITIL verze 3. Ze zde [ICTM_Kufner] uvedených uvádím ve stručnosti jen několik: -

„ITIL není snadné implementovat podle stávajících knih

-

ITIL nemá stanovena měření, metriky

-

Globalizace businessu, vzrůstající závislost na mnoha dodavatelích – různé formy sourcingu a shared services Neschopnost ITIL mapovat podnikové procesy na IT procesy“

-

Zdroj [ICTM_Kufner] Obsah ITIL Refresh “Knihovna” ITIL verze 3 obsahuje pět knih, níže uvádím jejich seznam a stručný přehled jejich obsahu: 1.

Service Strategy (Strategie služeb)

Byznys a IT strategie, typologie přístupu k implementaci na základě odvětví, legislativních požadavků, velikosti firmy

2.

Service Design (Návrh služeb)

Návrh IT služeb a infrastruktury, řízení životního cyklu IT služeb (outsourcing versus insourcing), nákladové modely

3.

Service Transition (Realizace návrhu služeb)

Implementace strategie, plánů služeb do reálného prostředí

Change management

Release management

Modely služeb, kontrolní seznamy pro přebírání služeb do provozu (životní cyklus služby)

4.

5.

Service Operation (Provozování služeb)

Správa IT služeb v rámci provozu, řízení výpadků a poruch

Řízení aplikací

Continual Service Improvement (Kontinuální vývoj služeb)

Faktory (technologie, byznys) určující vývoj služeb

Argumenty pro zavedení ITIL

16



Přesto, že je ITIL v3 zveřejněn již více než rok, není prozatím příliš široce využíván v praxi. Důvodem je pravděpodobně hodně široký záběr těchto publikací, který znesnadňuje rychlou orientaci v popsané problematice. Zatím jsou používány spíše jednotlivé segmenty publikací a novinky týkající se jednotlivých procesů z verze 2. Příklad změn provedených v konfiguračním managementu: Verze 3 doporučuje použití tzv. agregované databáze – tj. opouští se myšlenka držení jediné databáze, ve které jsou uloženy údaje o všech typech konfiguračních položek včetně DSL. Verze 3 připouští logické rozdělení údajů do více databází a jejich následné propojení. ITIL verze 3 zavádí nový pojem SACM (Service Asset and Configuration Management), který popisuje následující aktivity: -

Správa záznamů o všech položkách a jejich vzájemných vazbách v rámci infrastruktury organizace.

-

Identifikace, kontrola a nastavení odpovědností za jednotlivá aktiva IT služeb a konfigurační položky, jejich ochrana a zajištění jejich integrity v rámci celého životního cyklu služby.

-

Správa non-IT aktiv a řízení interních a externích dodavatelských řetězců, v případech, kde vzniká potřeba jednotlivá aktiva řídit a kontrolovat.

Pro řízení rozsáhlých systémů ve velkých organizacích doporučuje ITIL verze 3 použití podpůrných systémů s názvem Configuration Management System (CMS).

17



2.5.2. ISO/IEC 20000:200511 ISO

(the

International

Organization

for

Standardization)

a

IES

(International

Electrotechnical Commision) vytvořili mezinárodní normu pro standardizaci procesního řízení poskytování IT služeb ISO 20000. Standard ISO/IEC 20000:2005 byl vyvinut na základě britské normy pro řízení IT služeb 2000: BS 15000-1:2000. ISO/IEC 20000:2005 je mezinárodní standard pro zavedení a správu integrovaného a efektivního procesu řízení poskytování IT služeb. ISO/IEC 20000:2005 část 1 definuje požadavky, které musí organizace splňovat, pokud chce splnit podmínky pro mezinárodní certifikaci kvality poskytování a řízení IT služeb. ISO/IEC 20000:2005 část 2 obsahuje doporučení a způsoby implementace jednotlivých požadavků definovaných v části 1. Část 2 se svým obsahem velmi podobá ITIL a je založená na best practice popsaných v ITIL. V roce 2006 vznikla i česká verze této normy, její označení je ČSN ISO/IEC 20000. Rozdělení procesů ITSM podle ISO 20000 je následující12: Service Delivery Processes (Procesy dodávky služeb): -

Capacity management (Management kapacit)

-

Service Continuity and availability management (Management kontinuity a dostupnosti služeb)

-

Service Level management (Management úrovně služeb))

-

Service reporting (Výkazy o službách - není součástí ITIL)

-

Information Security Management (Management bezpečnosti informací - není součástí ITIL)

-

Budgeting and accounting for IT services (Rozpočtování a účtování pro IT služby ITIL navíc obsahuje sub-proces IT – charging)

11

Informace pro tuto kapitolu jsem čerpala z [ISO_20000_HP], [ISO_20000_1], [ISO_20000_2] V závorkách uvádím český překlad názvů procesů podle ČSN ISO/IEC 20000, překládat anglické termíny v oblasti IT není v běžné praxi zvykem z toho důvodu, že české výrazy jsou často zavádějící, proto jsem se rozhodla uvést obě jazykové verze 12

18



Control processes (Řídící procesy): -

Konfigurační management (Management konfigurací)

-

Change management (Management změn)

Release processes (Proces uvolnění): -

Release management (Management uvolnění)

Resolution processes (Procesy řešení): -

Incident management (Management incidentů)

-

Problem management (Management problémů)

Relationship processes (Procesy řízení vztahů) -

Business Relationship Management

(Management vztahů s byznysem - není

součástí ITIL) -

Supplier Management (Management vztahů s dodavateli - není součástí ITIL)

Více o ISO/IEC 20000 viz [ISO_20000_HP], [ISO_20000_1], [ISO_20000_2]. Schéma procesů ITSM podle ISO 20000 Část 1

Obr. 3 ISO 20000 - Procesy ITSM, Zdroj [ISO_20000_1],

19



2.5.3. ITIL a informační bezpečnost Informační bezpečnost je v ITIL řešena prostřednictvím procesu IT Service Continuity management. Součástí tohoto procesu je provedení analýzy dopadu, analýzy rizik a sestavení plánu

kontinuity včetně

protiopatření vedoucích k minimalizaci výskytu jednotlivých

hrozeb a rizik. Norma ISO/IEC 20000:2005 – Part 1 definuje následující požadavky na řízení informační bezpečnosti: -

„Implementovat požadavky vyplívající z bezpečnostní politiky

-

Řídit rizika na úrovni přístupu ke službám a systémům

-

Dokumentovat bezpečnostní kontroly a jejich výsledky (měly by být vztaženy na konkrétní riziko, obsahovat popis provádění kontrol apod.)

-

Ohodnocovat změny z pohledu bezpečnosti před jejich nasazením

-

Definovat bezpečnostní požadavky pro případ vstupu externích osob do prostor společnosti

-

Řídit bezpečnostní incidenty“

Zdroje: [ISO_20000_HP], [ISO_20000_1], [ISO_20000_2]. Norma ISO/IEC 20000:2005 doporučuje

pro zavedení procesu řízení informační

bezpečnosti použít normu ISO/IEC 17799, Information technology – security techniques – code of practice. Norma ISO/IEC 20000:2005 – Part 2 doporučuje následující kroky při zavádění procesu pro řízení bezpečnosti: -

„Identifikovat a klasifikovat IT aktiva z pohledu bezpečnostních rizik o

Vytvořit přehled informačních aktiv, potřebných pro poskytování služeb

o

Provést klasifikaci informačních aktiv z pohledu jejich kritičnosti pro poskytované IT služby a potřebnou úroveň jejich ochrany, nominovat vlastníky jednotlivých aktiv

o

Definovat osoby odpovědné za ochranu jednotlivých aktiv

-

Posouzení bezpečnostních rizik

-

Určit hrozby pro informační aktiva

-

Definovat požadavky na bezpečnost v souvislosti s dostupností informací

-

Definovat kontroly a kontrolní mechanizmy

20

Problematika implementace ITSM -


Provádět záznamy o stavu a vývoji informační bezpečnosti v organizaci“ Zdroj: [ISO_20000_HP], [ISO_20000_2].

2.5.4. ITIL a procesy ITSM Jak již jsem uvedla dříve ITSM je rámcem pro taktické a operativní řízení IT služeb. Úroveň operativního řízení je zpracována v publikaci Service Support. Souhrnným cílem těchto operativních procesů13 je dennodenní podpora uživatelů užívajících IT služby. Na úrovni taktického řízení převládají procesy14 pro dlouhodobější plánování – tyto procesy jsou popsány v knize Service Delivery. Souhrnným cílem těchto procesů je budování vztahu se zákazníky a dosažení jejich dlouhodobé spokojenosti. Dále Kapitola 3. Praktická část uvádím detailní popis jednotlivých procesů, u každého procesu uvádím jeho základní charakteristiky tj. cíl procesu, vstupy a výstupy, přehled hlavních aktivit, součástí každé kapitoly je i přehled nejčastějších problémů a slepých uliček, do kterých se lze při implementaci jednotlivých procesů dostat.

13 14

Incident, problem, change a release management Service Level, Availability, Capacity, Financial a IT Service Continuity management

21


2.6.


Procesní řízení15

Jednou z hlavních charakteristik ITSM je procesně orientovaný přístup k řízení IT služeb. Procesní řízení je založeno na definici a postupu řešení jednotlivých aktivit organizace (v tomto případě aktivit spojených s IT službami) podle procesů tj. logického sledu činností, prostřednictvím kterých dochází k transformaci vstupu na výstup. Činnosti jsou realizovány stanovenými rolemi, pro než je dodržování definovaných procesů – posloupnosti činností závazné. Ve většině případů jsou role nezávislé na hierarchické organizaci podniku a procházejí tzv. napříč podnikem – tj. na jednom procesu se účastní osoby z různých oddělení.

Obr. 4 Procesní řízení

Každá role je přidělena fyzické osobě v organizační struktuře, přičemž jedna role může být přidělena více osobám, jedna osoba může zastávat více rolí a to v jednom a více procesech. Jednou z nejdůležitějších rolí v procesním řízení je tzv. vlastník procesu, který je zodpovědný za kvalitu nastavení i provádění procesu a jeho neustálé zlepšování. Dodržování definovaných procesů a efektivita jejich provádění musí být měřitelná.

15

Informace pro tuto kapitolu jsem čerpala z [TO2S_FOUN]

22



Tzn. součástí návrhu procesu je i vymezení parametrů a metrik pro měření kvality a výkonnosti procesu. Výsledky měření procesu následně slouží jako podklady pro jeho další vývoj a zlepšování (více viz následující kapitola 2.7).

Konflikt procesního a hierarchického řízení Hierarchické řízení organizace (tj. řízení založené na rozdělení osob podle specializací např. účetní, IT, ekonomické oddělení) je v českých firmách velmi rozšířené. Přechod k procesnímu řízení případně kombinace hierarchického a procesního způsobu řízení sebou přináší řadu problémů a konfliktů na úrovni zdrojů – zaměstnanci mají definované povinnosti, mnohdy odlišné, vyplývající jak z hierarchického tak z procesního řízení. Priority a způsob řešení podobných konfliktů by mělo být stanoveno na úrovni strategického vedení organizace ještě před tím, než dojde k implementaci procesního řízení ať už pro potřeby implementace ITSM nebo procesního řízení obecně.

23


2.7.


Model procesní vyspělosti (CMM)16

Již v předchozí kapitole jsem zmiňovala nutnost definice parametrů a metrik pro jednotlivé procesy případně i na úrovni jednotlivých činností procesu. Evidence záznamů a jejich analýza může posléze sloužit k dalšímu vývoji procesu, k jeho zefektivnění. Metodika CMM (neboli model procesní vyspělosti procesu) představuje rámec, který definuje 5 úrovní vyspělosti procesu založených právě na těchto drobných změnách vycházejících z opakovaného měření procesu. Tento rámec a v něm definované úrovně vyspělosti procesů slouží k lepší orientaci v této problematice a zároveň napomáhá při definici priorit vývoje. „Úroveň vyspělosti = vymezený soubor charakteristických znaků, stanovený a přijímaný jako srovnávací základna pro hodnocení dosaženého daného stupně procesní vyspělosti. Každá úroveň představuje výchozí stav pro další průběžné zlepšování. Dosažení vyšší z vrstev vyšší úrovně znamená uplatnění určitých zásad ve fungování procesů organizace, jejichž výsledkem je procesní způsobilost a vyspělost organizace.“.Zdroj [11] Primární procesní změny, které se odehrávají na každé úrovni, vysvětlují následující charakteristiky pěti úrovní vyspělosti: 1. Výchozí (Ad – hoc)

Procesy nejsou zdokumentovány, dynamicky se mění, často jsou řízeny chaoticky a ad-hoc, nejsou definovány žádné kontrolní mechanizmy a vše je řešeno v reaktivním módu v závislosti na požadavcích uživatelů nebo potřebách systému. Jde o nestabilní a chaotické prostředí. 2. Opakovatelná (Repetable) Některé procesy jsou popsány a jsou opakovatelné – jejich provedení vede obvykle ke shodným a konzistentním výsledkům. Procesy nelze aplikovat obecně (např. na všechny projekty). Dodržuje se určitá procesní kázeň, nezbytná pro úspěšné opakovaní základních procesů.

16

Informace pro tuto kapitolu jsem čerpala z [11], [12]

24



3. Definovaná (Defined) Část procesů je zdokumentována a probíhá u nich i určité zlepšování a vývoj. Procesy se dodržují a je snaha o udržení výkonnosti procesů v rámci organizace. V případě potřeby slouží existující procesy jako podklad pro definici procesů v oblastech, kde vznikne aktuální poptávka po zavedení procesů. 4. Řízená (Managed) Je zavedený systém metrik, provádí se měření jejich výkonnosti a vedení společnosti může efektivně kontrolovat a řídit reálně nastavené procesy (např. Proces vývoje SW). V některých případech může dojít k úpravě procesu pro specifické potřeby projektu – tato změna procesu nezpůsobí ve srovnání se standardně prováděnými procesy žádnou měřitelnou ztrátu. 5. Optimalizovaná (Optimized) Díky záznamům z měření provozu a výkonu procesů je možné provádět kontinuální zlepšování procesů jak na inkrementální tak na inovativní bázi založené na technologickém vývoji a změnách.

Obr. 5 Stupně procesní vyspělosti (CMM), Zdroj [11]

25


2.8.


Projektové řízení a implementace ITSM

Tuto kapitolu jsem se rozhodla do své práce zařadit, přestože by se mohlo zdát, že ITIL nemá s projektovým řízením nic společného17. Domnívám se, že projektové řízení a ITIL spolu velice úzce souvisí 1. Implementace procesů ITIL/ITSM musí být řízena projektově 2. Některé procesy ITSM mají přímou vazbu na výstupy projektového řízení

Ad 1. Zásady implementace procesů ITSM „Implementace disciplín ITSM je celopodnikovým projektem strategického významu. Základní projektové etapy jsou čtyři a jsou realizovány v tomto pořadí: 1. Získání znalostí o ITIL, které se týká: -

Manažerů a všech zástupců klíčových procesních rolí

-

Členů implementačního týmu

2. Zhodnocení současné situace -

Popis současného stavu

-

Identifikace oblastí, které jsou již pokryty

3. Naplánování způsobu dosažení cílového stavu -

Vytvoření projektového plánu

4. Realizace plánů -

Realizace samotné implementace

-

Ověření, že bylo dosaženo cíle

V průběhu celého projektu je žádoucí realizovat tzv. "Awareness kampaň", což je v podstatě nástroj řízení úrovně očekávání všech zainteresovaných stran.“ Zdroj [13] Při realizaci projektu je nutné udržet v rovnováze trojimperativ "lidé - procesy - nástroje": (více viz Praktická část)

17

Na rozdíl od rámce Cobit, který definuje procesy a kontrolní cíle i pro projektové řízení.

26



Ad 2. Procesy ITIL a projektové řízení Procesy Change a Release management mají velice úzké vazby na projektové řízení. Change management zaštiťuje plánování změn a jejich nasazení do produkčního prostředí tzn. realizaci jednotlivých dílčích plnění v rámci projektového řízení, podílí se na úvodní analýze

a

zajišťuje

koordinaci

a

nutnou

součinnost ostatních

procesů

ITSM.

Tzn. v největší míře se podílí na počátečních fázích projektu, spojených s plánováním, v průběhu projektu je odpovědný za řízení životního cyklu změny, schvaluje předání výstupů do produkčního prostředí. Release management je odpovědný za to, že nasazení všech změn do produkčního prostředí bude řízeno a organizováno efektivně, a to po nákladové i organizační stránce. V rámci projektového řízení zastřešuje jeho závěrečnou fázi, která se zabývá předáváním výstupů projektu do provozu. Ve společnosti, kde pracuji, máme stanoveny následující fáze vývoje IT projektu: 1. Pre-sales o

Poptávka

o

Nabídka

o

Příprava podkladů pro vývoj

2. Build (Vývoj) o

Vývoj

o

Zátěžové testování

o

Zpracování dokumentace

3. Transfer to operation (Předání do provozu) o

Testování (provozní, technické, uživatelské, výkonnostní testy)

o

Kontrola dokumentace

o

RTP (Release to production)

4. Run (Provoz a podpora) o

Incident management

o

Problem management

o

Change management

o

Release management

o

Configuration management

27


2.9.


Další metodiky pro řízení IT služeb

Některé firmy vyvinuly na základě ITIL své vlastní procesně zaměřené metodiky řízení IT služeb provozovaných na technologiích těchto firem, např.:

2.9.1. eTOM (enhanced Telecom Operations Map) „Rámec definující byznys procesy pro poskytovatele telekomunikačních služeb. Definuje strukturu, procesy, vazby, role a odpovědnosti, požadavky na systémová řešení, jejich architekturu, technologii a implementaci. eTOM se skládá ze tří hlavních procesních oblastí: -

Strategie, infrastruktura a produkty - zahrnuje plánování a řízení životního cyklu

-

Provoz – zahrnuje základní procesy pro řízení provozu

-

Podnikové řízení – procesy pro podporu řízení organizace“

Zdroj: [ICTM_Hospes], Více informací např. [14]

Obr. 6 Model eTOM, Zdroj [ICTM_Hospes]

28



2.9.2. HP IT service management reference model Metodologie vyvinutá firmou Hewlett-Packard (HP), která se skládá z 5 hlavních částí: -

„Propojení organizace a IT (Business-Technology Alignment) Definice strategie pro IT infrastrukturu a související portfolio IT služeb zaměřená na růst přidané hodnoty ze strany IT pro organizaci.

-

Návrh a řízení IT služeb (Service Design & Management providing) Detailní specifikace IT služeb s důrazem na vyváženost kvality IT služeb a nákladů na služby.

-

Vývoj a distribuce IT služeb (Service Development & Deployment) Detailní specifikace IT služeb s důrazem na vyváženost kvality IT služeb a nákladů na služby.

-

Provoz služeb (Service Operations) Operativní provoz a monitoring IT služeb. Zpracování požadavků zákazníka, udržovaná stanovených úrovní služeb s důrazem na růst spokojenost zákazníka.

-

Poskytování IT služeb (Service Delivery Assurance) Řízení smluvních vztahů, distribuce informací a koordinace aktivit vyplývajících ze smluvních závazků.“ Zdroj [15]

2.9.3. Microsoft operations framework (MOF) Metodologie vyvinutá firmou Microsoft založená na ITIL. MOF poskytuje technické návody pro provozování systémů založených na MS produktech a technologiích. Podle MS je MOF základem pro poskytování služeb souvisejících s podporu provozu IT systémů. Zdroj [16], [17] „MOF obsahuje následující části: -

Procesní model

Procesní model MOF popisuje aktivity provozu IT, které jsou potřeba pro řízení a podporu IT služeb. MOF je rozdělen na 4 kvadranty a 20 funkcí řízení služeb. -

Model spolupráce (Team model)

Model spolupráce obsahuje popis jednotlivých rolí a jejich aktivit v rámci poskytování IT služeb a je určen pro podporu řízení lidských zdrojů. -

Model pro řízení rizik

Popis procesu řízení rizik včetně sady postupů a pravidel pro řízení rizik.“ Zdroj [17]

29



2.9.4. Další metodiky pro řízení IT služeb – shrnutí Uvedené metodiky jsou přímo závislé na podpůrných nástrojích firem, které je vyvinuly. Jednoznačnou výhodou ITIL je jeho nástrojová nezávislost, široká dostupnost (public domain) a typická – původní terminologie.

30



3. Praktická část

31


3.1.


Implementace ITSM formou interního projektu

Implementace ITSM formou interního projektu je dle mého názoru a zkušenosti velmi specifické a řekla bych zrádné řešení. Největším problémem v případech, kdy se vedení společnosti rozhodne pro implementaci ITSM vlastními silami, je nutná participace specialistů na analýze a návrhu řešení. Na implementaci ITSM vlastními silami tj. formou interního projektu je pohlíženo stejně jako na většinu interních projektů, tj. jako na časově a zdrojově nákladnou záležitost, která navíc zatěžuje již tak velmi vytížené specialisty, kteří by se měli v první řadě podílet na realizaci externích projektů a podpoře provozu. Pokud pak navíc v období implementace přijde externí projekt, který vyžaduje účast těchto specialistů, je implementace ITSM často pozastavena. Společnost musí v první řadě poskytovat kvalitní služby externím zákazníkům, rozvoj „interních záležitostí a procesů“ je až na druhém místě. Dodržet plánovaný harmonogram projektu implementace je v takových případech téměř nemožné. Zvláštní kapitolu pak tvoří nástrojové pokrytí procesů, velké problémy v oblasti očekávání vedení společnosti může způsobit, pokud jsou náklady na podpůrné nástroje a čas potřebný na implementaci definovány až v průběhu projektu. Častou reakcí je buď snaha o minimalizaci nákladů na podpůrné nástroje a udržování několika souborů v některém z běžně dostupných tabulkových nebo databázových editorů, nebo odsunutí pořízení „drahého“ podpůrného nástroje na neurčito, nejčastější je kombinace obou uvedených řešení. Naopak, v případě, kdy si organizace najme na implementaci ITSM externí konzultanty, je s jejich časem nakládáno jako se vzácným a drahým zdrojem. tzn. je mnohem větší pravděpodobnost, že zaměstnanci (specialisté), kteří budou zapojeni do analýzy a návrhu procesů na schůzky s těmito externisty přijdou a navíc připraveni. Protože paradoxně čas, který věnuje schůzkám s konzultanty sice organizaci nic nevydělává, naopak je pro organizaci drahý a díky tomu je s ním i tak nakládáno. Stejně tak, pokud externí firma v rámci analýzy doporučí některý z podpůrných nástrojů, má takové doporučení mnohem větší váhu, než pokud je doporučeno interními konzultanty.

32



Pravdou je, že součástí výběrových řízení na dodávku konzultačních služeb v oblasti ITSM je i definice podpůrných nástrojů včetně ceny řešeni – i tato skutečnost pomáhá mnohem lépe řídit očekávání vedení společnosti i všech zúčastněných. Ve společnosti, kde pracuji, jsme se přibližně před rokem pokoušeli o implementaci procesů ITSM. Tato společnost se specializuje na poskytování služeb ICT korporátní klientele a zákazníkům z oblasti státní a veřejné správy. Služby, které naše společnost poskytuje, je možné rozdělit do dvou hlavních oblastí. První zahrnuje služby komplexního outsourcingu IT infrastruktury, druhá sdružuje služby ICT, provoz infrastruktury, hosting, housing, řízené ICT služby a konzultace v oblasti ITSM. Teoretický je organizace podobného typu prototypem společnosti, která by měla mít implementaci některého z rámců pro řízení IT služeb pevně zakotvenou ve své strategii a její realizace by měla mít vysokou prioritu, vzhledem k tomu, že core byznys společnosti je především poskytování IT služeb externím zákazníkům v rámci rozsáhlých projektů. Zázemí v podobě fungujících procesů řízení IT služeb by zprůhlednil a zjednodušil nastavení a řízení vztahů se zákazníky, řízení poskytovaných služeb a projektové řízení ve společnosti vůbec. Cílem interního projektu implementace procesů ITSM bylo mj. dosažení certifikace ISO 20000 v termínu červen 2008. Projekt byl bohužel po 3 měsících ukončen, protože zpoždění oproti harmonogramu bylo takové, že termín certifikace nebylo reálné zvládnout. Hlavní příčiny tohoto neúspěchu, které se mi podařilo identifikovat byly následující: -

Nedostatečná podpora vedení společnosti

-

Nejasně definované priority a alokované kapacity na projektu a na aktivitách vyplývajících z liniové pozice specialistů (především budoucích vlastníků procesů)

-

Nedostatečná komunikace mezi vedením projektu a vedením společnost (v oblasti očekávání, eskalací, v problematických oblastech a rozhodování)

-

Neexistence podpůrného nástroje a příliš dlouhé a bezvýsledné rozhodování při výběru nástroje

-

Nedostatečná zkušenost konzultantů s projektem podobného rozsahu a typu

-

Snaha vedení projektu zatajit vedení společnosti narůstající zpoždění projektu

33



Výše uvedené příčiny vedly k tomu, že byl interní projekt pozastaven. V současné době se opět otevírá možnost pokračovat v implementaci procesů ITSM. Byla provedena následující protiopatření: realizace bude zahájena až po výběru komplexního podpůrného nástroje, aby jeho vybíráním nebylo negativně ovlivněno trvání projektu. Na projektu by měli participovat externí konzultanti. Vedení společnosti je zahrnuto do řídících struktur projektu.

34


3.2.


Implementace ITSM ve státní správě

Státní správa je velice specifická svým způsobem fungování, organizací, řízením rozpočtu a rozvoje, což nemalou mírou ovlivňuje i oblast IT. Níže uvádím některá specifika státní a veřejné správy: -

Plánování rozpočtu v ročních intervalech

-

Vývoj a implementace nových řešení je většinou důsledkem nějaké legislativní úpravy (novela zákona, vyhlášky, požadavky EU) tzn. řešení musí být připraveno v den účinnosti vyhlášky/zákona

-

Výběrové řízení pro jednotlivá řešení se řídí zákonem o veřejných zakázkách (Předpis č. 137/2006 Sb., zdroj: SBÍRKA ZÁKONŮ)

-

Rozdělení odpovědnosti mezi více osob/odborů

-

Nízká motivace vedoucích a projektových pracovníků zastupujících státní správu

-

Relativně nestabilní prostředí (časté výměny na vedoucích pozicích apod. )

-

Dlouhodobé plánování – jen v horizontu čtyřletých cyklů (volební období)

-

Změna vlády přináší nové koncepce, cíle, záměry často i změnu dodavatelů

-

Primárním cílem byla a stále je automatizace práce úředníků (snižování počtu zaměstnanců)

-

Nárůst outsourcovaných řešení

-

Současným trendem je systémová integrace a rostoucí vliv pozic systémových integrátorů, kteří přebírají zodpovědnost za řízení jednotlivých dodavatelů

-

„Neexistence metodiky projektového řízení pro státní správu

-

Nejasně definovaná struktura řízení a pravomocí v rámci projektu, příčinou jsou kompetenční spory a zdržení projektu způsobená odkládáním zásadních rozhodnutí v rámci projektu a schvalování návrhů řešení.

-

Ze strany odběratele se zájem obvykle omezuje na připomínkování dílčích výstupů projektů nebo návrhů řešení. Pasivní přístup k analýze problému a návrhu řešení.“Zdroj[18]

-

Trend: zaměření na procesy, sdílení dat, plnění požadavků v oblasti reportingu a statistik pro EU, e-komunikace s veřejností

„Všechna uvedená specifika kladou zvláštní požadavky na dodavatele, na způsob nastavení komunikace, volbu metodiky pro projektové řízení a přístup vůči zákazníkům ze státní správy obecně.“ Zdroj [18]

35



Společnost, ve které pracuji vystupuje v pozici systémového integrátora pro množství zákazníků z oblasti státní správy – pro jednoho z těchto zákazníků jsme řešili právě implementaci procesů ITSM. Pro upřesnění musím dodat, že procesy měly být řešeny na úrovni systémového integrátora především pro účely řízení dodavatelů a jimi poskytovaných služeb, kde zákazník vystupoval jen v roli schvalovatele (jak výstupů projektu implementace ITSM, tak i výstupů samotných procesů v provozní fázi projektu). Předpokládám, že popsaný způsob řešení je v prostředí státní a veřejné zprávy běžný a jediný relativně realizovatelný. Jeden z problému, které bylo v tomto projektu potřeba řešit byla skutečnost, že jednotliví dodavatelé měli podepsané smlouvy přímo se zákazníkem a tudíž víceméně neměli důvod akceptovat a dodržovat námi navržené procesy a pravidla. Postupně se podařilo v rámci smluv o systémové integraci zpracovat smlouvy na úrovni SLA i mezi systémovým integrátorem a těmito dodavateli – na úrovni procesu incident management. Bez tohoto kroku by implementace procesů ITSM nebyla realizovatelná. Obecně je v případě řízení IT na úrovni služeb nejdůležitější vydefinovat pro všechny vazby, mezi subjekty, které se mohou vzájemně ovlivňovat a mají vliv na kvalitu společně poskytovaných služeb, smluvní dohody o úrovni poskytovaných služeb právě na rozhraní mezi jednotlivými organizacemi. Dalším krokem je řízení definovaných vztahů takovým způsobem, aby byl maximalizován užitek a přínos pro zákazníka. Velmi charakteristické, jak vyplívá z úvodního souhrnu specifik, je v oblasti státní správy, plánování rozpočtu v ročních intervalech s tím, že je velice striktně oddělen rozpočet pro rozvoj a provoz systému. To zásadním způsobem ovlivňuje především proces change managementu, kde je potřeba rozlišovat mezi požadavky na změnu, které lze realizovat v rámci aktuálního rozpočtu tj. provozu systému a které je potřeba pouze předat zákazníkovy ke zpracování formou rozvojového plánu pro příští období. Problematické jsou v tomto ohledu nejrůznější legislativní úpravy, které se objevují v průběhu roku a vyžadují úpravu některého procesu či systému. V rozpočtu je samozřejmě pro takové případy vymezena rezerva, ale řízení jejího čerpaní není jednoduché.

36


3.3.


Problematika implementace ITSM – obecně

V této části se budu věnovat praktickým aspektům implementace procesů ITSM v prostředí českých organizací. Podklady pro tuto část mé práce jsem získala na základě provedených pohovorů se 2 odborníky z praxe a ze svých vlastních zkušeností z projektů implementace ITSM procesů. Pohovory jsem vedla na základě předem připraveného dotazníku (viz Příloha 2) Problematiku implementace ITSM disciplín jsem v dotazníku rozdělila do následujících částí: 1. Lidé 2. Nástroje 3. Procesy Tyto oblasti jsem zvolila z toho důvodu, že se jedná o oblasti, které by měly být při implementaci ITSM procesů ve středu zájmu a to nejen s důrazem na vysokou kvalitu implementace jednotlivých částí, ale především na jejich vzájemnou integraci a vyváženost.

37



3.3.1. Lidé18 Tato oblast zahrnuje veškeré aspekty, které by měly být vzaty v úvahu z hlediska personálního zajištění procesů ITSM. Bohužel se na tuto součást implementace ITSM a s tím souvisejících změn dost často zapomíná. Většinou se klade důraz na nastavení procesů v horším případě na nástroj a zapomíná se, že velmi významnou součástí této skládanky jsou i lidé, kteří tyto procesy a nástroje budou vykonávat a používat. Implementaci ITSM přináší mnoho změn do pracovní náplně zúčastněných osob. (např. „Zákazníci“ IT

podle nových pravidel nesmí kontaktovat přímo svého oblíbeného

specialistu, ale musí vše hlásit na (pro ně pouze mezistupeň) Service Desk, kde jim nejsou schopni vždy okamžitě pomoci.) Specialisté mohou mít pocit, že je ohrožena jejich pozice tím, že jsou v rámci řešení incidentů nuceni předávat své znalosti i nižším úrovním podpory. Často jsem se také setkala s tím, že zavádění procesů ITSM bylo techniky nazýváno „byrokratizací IT“. Zvláštní pozornost je potřeba také věnovat řízená znalostí napříč dodavatelskými řetězci (více viz Kapitola 3.3.3.3 Problem management). Největší mezery jsou při analýze současného stavu procesů obvykle v oblasti dokumentace. Např. součástí dodávky každé aplikace by měly dle mého názoru být: -

Administrátorská příručka

-

Instalační příručka (obsahující i popis navrácení systému do původního stavu tzv. back-out plán)

-

Uživatelská příručka

S prvními dvěma uvedenými jsem se však v praxi setkala jen zřídkakdy. Kromě zmiňovaných specialistů a zákazníků procesů ITSM, je zde také samotný top management, který musíme být schopni přesvědčit o nezbytnosti a jednoznačných a nezpochybnitelných přínosech implementace ITSM.

18

Informace pro tuto kapitolu jsem čerpala z vlastních zkušeností a [ICTM_Bělina]

38



Silná a vytrvalá podpora top managementu je klíčovým faktorem úspěchu při implementaci ITSM. Vzhledem k relativně vysokým nárokům na zdroje, v průběhu implementace ITSM je dobré rozdělit etapy implementace na několik menších celků, které přinesou jasně viditelné výstupy a přínosy – tak lze udržet jak pozornost a podporu top managementu, tak i všech zúčastněných. Norma ISO/IEC 2000019 definuje následující oblasti, které by měly být v průběhu implementace a provozu ITSM v oblasti lidských zdrojů pokryty: -

Vymezení zásadních rolí v jednotlivých procesech a jejich kompetencí

-

Definice odpovědností zúčastněných stran (managementu, zákazníka, poskytovatele, dodavatelů) o

Vlastník procesu

o

Specialista procesu

o

Vlastník služby

o

Apod.

-

Stanovit osobnostní a kvalifikační požadavky na jednotlivé role

-

Povědomí zúčastněných osob o významu jejich role pro dosažení definovaných cílu

-

Udržování nutné úrovně vzdělávání a znalostí v této oblasti

-

Plánování lidských zdrojů

K dalším oblastem, kterým by měla být věnována v této oblasti pozornost patří podle [ICTM_Bělina] např.: -

V rámci možností zajistit soulad mezi liniovou a procesní náplní práce.

-

Monitorovat a řídit a řešit případné problémy v oblasti kapacity lidských zdrojů (více viz Kapitola 3.3.3.9 Capacity management)

-

Příprava a realizace vzdělávacího programu v oblasti ITSM (technici, vlastníci procesu, operátoři Service Desku, specialisté)

-

o

Vzdělávání – teoretické školení v oblasti ITSM

o

Zaškolení – příprava na výkon role (seznámení s procesy a nástroji)

o

Informační kampaň – příprava na nové povinnosti, na změny, řízení očekávání

Příprava detailního popisu náplně práce jednotlivých rolí a jejich včasnou komunikaci vůči zástupcům role

19

Zdroje [ISO_20000_1], [ISO_20000_2]

39

Problematika implementace ITSM -


Zahrnout ty, kteří se budou procesů bezprostředně účastnit nejen do analýzy současného stavu procesů, ale konzultovat s nimi i návrh řešení procesů – Toto řešení je sice velice náročné na zdroje, ale

přispívá jednak k osobní zainteresovanosti zúčastněných v

plánovaných změnách a minimalizuje se tak pravděpodobnost konfliktu při nasazování změny do provozu.

40



3.3.2. Nástroje Implementace ITSM bez adekvátních podpůrných nástrojů je téměř nemožná – především ve velkých organizacích. Stavebním kamenem mnoha ITSM disciplín je databáze a v ní spravovaná data - záznamy. Největší přínos při implementaci ITSM získáme při integrací jednotlivých disciplín – a tedy i nástrojů, které dané procesy podporují. Použití nástroje umožní centralizaci klíčových procesů a automatizaci ITSM procesů. Data získaná z těchto nástrojů mohou být dále analyzována a mohou posloužit k identifikaci trendů v jednotlivých oblastech a případné implementaci preventivních opatření. Podpůrný softwarový nástroj by měl zvýšit efektivitu, výkonnost IT a kvalitu práce s informacemi tak, aby byla odstraněna slabá místa mj. v místech vazeb mezi jednotlivými procesy. Dlouhodobým cílem implementace podpůrného nástroje je snížení nákladů na provoz IT služeb a zvýšení produktivity a tím i kvality poskytovaných služeb. Best practice při výběru podpůrného nástroje: 1. Přesně specifikovat požadavky při výběru nástroje Příklad požadavků na podpůrný nástroj: o

Nástroj podporuje vybrané/všechny ITIL procesy včetně jejich monitoringu

o

Nástroj obsahuje potřebná rozhraní pro ostatní systémy/procesy (HR, finance, vývoj) pro další integraci a vývoj

o

Odpovídá požadavkům na strukturu, způsob zpracování a integraci dat

o

Splňuje mezinárodní standardy

o

Příjemné a srozumitelné uživatelské rozhraní

o

Řešení na architektuře klient-server

o

Možnost konverze stávajících dat do nového nástroje

o

Vyhovující způsob zálohování, kontroly a řízení bezpečnosti dat

o

Klade přijatelné nároky na znalosti uživatelů

41



2. Vypočítat celkové reálné náklady na podpůrný nástroj

Příklad jednotlivých složek nákladů na podpůrný nástroj: o

SW/HW – pořizovací náklady a instalace

o

Licence, školení, vývoj a customizace

o

Konzultace

o

Smlouva o podpoře

3. Nástroj musí podporovat fungování procesu, nepřizpůsobovat proces nástroji. 4. Preferovat plně integrovaná řešení, která podporují více ITSM procesů – pokud to není možné požadovat alespoň snadnou integrovatelnost jednotlivých řešení. 5. Platforma, na které je nástroj provozován by měla být v souladu s IT strategií 6. Cena nástroje splňuje podmínky určené v rozpočtu projektu 7. Zjistit „kreditabilitu“ dodavatele – jeho minulý i plánovaný vývoj, počet provedených instalací nástroje a spokojenost stávajících zákazníku s produktem i s podporou ze strany dodavatele. 8. Požadovat demonstraci fungování nástroje – ideálně v podobě návštěvy u některého referenčního zákazníka tohoto dodavatele 9. Zahrnout do výběru nástroje všechny relevantní pracovníky 10. Ověřit naplnění všech uvedených požadavků

42



3.3.3. Procesy Správně řízená implementace procesů ITSM by měla dle [ITIL_SS] dodržovat následující pravidla: 1. Výběr a postup realizace procesů provádět podle principu ‘quick wins’, tzn. v první fázi projektu implementace procesů ITSM vybrat takové procesy, které budou mít pro organizaci největší a nejviditelnější přínos 2. Postupovat od jednodušších procesů ke složitějším, projekt rozdělit do menších celků a implementovat je postupně 3. Zahrnout do projektu implementace ITSM zákazníka i dodavatele IT služeb Aspekty ovlivňující způsob implementace: 1. Velikost organizace 2. Úroveň znalostí IT personálu a uživatelů, 3. Úroveň procesního řízení v organizaci 4. Úroveň závislosti byznysu na IT 5. Podniková kultura Analýza a následující návrh procesů ITSM by měl obsahovat následující údaje20: 1. Vstupy a výstupy procesu (tzn. co může být vstupem do procesu a jak má vypadat výstup procesu) 2. Atributy prvků procesu a popis jejich životního cyklu (např. požadavek na změnu, incident, problém apod.) 3. Aktivity příp. sub-aktivity procesu 4. Definice rolí a jejich odpovědnosti, kvalifikační předpoklady 5. Eskalační a komunikační pravidla 6. Metriky výkonnosti procesu 7. Vazby na ostatní procesy V následující části uvádím jednotlivé procesy ITSM (Service Support, Service Delivery) včetně jejich stručné charakteristiky (tj. popisu vstupů, výstupů, hlavních aktivit procesu a přehledu nejčastějších překážek/slepých uliček při jejich praktické implementaci). Souhrnný přehled všech slepých uliček uvádím v Příloze 1.

20

Informace pro tuto kapitolu jsem čerpala z vlastních zkušeností a [ICTM_Skála]

43



3.3.3.1. Service Desk Service desk se liší od ostatních disciplín ITSM tím, že se nejedná o proces, ale o funkci – service desk plní funkci jediného místa kontaktu pro zákazníky/uživatele, kde mohou hlásit problémy, stížnosti či otázky spojené s IT službami. Jako takový představuje Service desk 1.úroveň podpory uživatelů systémů. Kromě toho představuje Service desk rozhraní pro veškeré procesy organizace, tak aby mohly být integrovány s procesy ITSM. K těmto integračním aktivitám patří např. -

Zaznamenávání požadavků na změnu od uživatelů,

-

evidování a poskytování informací o smlouvách o podpoře, dostupných SW licencích apod.

-

poskytování informací o SLA a jejich parametrech,

-

poskytování údajů konfiguračního managementu.

Ve většině případů patří k aktivitám Service desku také informování uživatelů o plánovaných odstávkách systému, v případě výpadku systému nebo části infrastruktury distribuuje Service desk informace dle předem stanovených pravidel (většinou formou komunikační matice) Primárním úkolem Service desku je záznam a prvotní zpracování incidentu a jeho přidělení na určenou řešitelskou skupinu. V některých případech je funkce service desku rozšířena i o řešení definovaných typů incidentů. Čím více incidentů se podaří odstranit již na této, první úrovni podpory, tím méně jsou zatěžováni specialisté na vyšších úrovních podpory a tím je i celý proces zpracování incidentů nákladově efektivnější.

44



Nejčastější problémy a slepé uličky: 1. Naučit zákazníka/uživatele komunikovat s poskytovatelem IT/IT oddělením jen přes Service Desk tj. eliminovat případy, kdy uživatel kontaktuje přímo specialistu – úzce souvisí s potřebou získat si důvěru uživatele a přesvědčit ho o tom, že Service Desk jeho požadavek zpracuje rychle a bezchybně. 2. Optimální nastavení kontrolních mechanizmů pro zákazníka tj. poskytnout zákazníkovi/uživateli IT služeb přehled o tom, jak Service Desk pracuje, jakým způsobem zpracovává jednotlivé druhy incidentů (např. zajistit přístup zákazníka do podpůrného nástroje Service Desku, aby mohl sledovat vývoj řešení incidentu, který zadal) 3. Vysoká fluktuace zaměstnanců (operátorů service desku) Operátor Service desku – charakteristika: -

Komunikativnost, ochota

-

Přiměřená úroveň odborných znalostí

-

Problematické je dlouhodobě udržet vysokou motivaci operátorů, příčiny: o

Každodenní kontakt se zákazníkem (problematičtí a nepříjemní uživatelé)

o

Rutinní náplň práce

o

Zpravidla relativně nízké platové ohodnocení

o

Nejasná možnost dalšího rozvoje

4. Podpůrný nástroj a jeho optimalizace Důraz na provedení řádné analýzy pro potřeby customizace nástroje, účast zástupců všech zainteresovaných stran, kontrola plnění zadání definovaného v analýze při následné implementaci. (viz Kapitola 3.3.2 Nástroje) Podpůrný nástroj hraje na úrovni Service desku příp. incident managementu zásadní roli – každá nevhodně naimplementovaná funkcionalita vede ke zdržení práce operátorů a často i k vytváření a udržování množství externích souborů v tabulkových editorech. Hrozí tak nekonzistence a ztráta dat, které by se daly použít např. pro analýzy trendu.

45



3.3.3.2. Incident Management Hlavním cílem procesu incident management je co nejrychlejší obnova dodávky služby po jejím výpadku a minimalizování dopadů výpadku na chod organizace. Vstupy

-

Výstupy 21

Údaje o incidentu získané od uživatele, dohledových nástrojů nebo dodavatele

-

Informace o konfiguračních položkách ze CMDB

-

Informace o podobných incidentech z KB

-

Řešení dílčí části incidentu

-

Výsledek požadavku na změnu, který

-

Komunikace se zákazníkem

-

Informace managementu (reporty)

-

Požadavek na změnu

-

Záznam problému

-

Vyřešený a uzavřený incident

vznikl na základně incidentu Tab. 2 Incident Management – Vstupy a výstupy

Incident Management – přehled hlavních aktivit 1. Záznam a popis incidentu 2. Klasifikace incidentu (určení kategorie, dopadu, naléhavosti apod) 3. Přidělení incidentu řešitelské skupině 4. Šetření a diagnóza 5. Řešení incidentu 6. Informování Service desku o vyřešení incidentu 7. Ověření a akceptace vyřešení incidentu u uživatele 8. Uzavření incidentu 9. Řešení krizových situací, monitoring a eskalace incidentu 10. Informování o změnách dostupnosti služby 11. Řízení průběhu procesu a reporting Tab. 3 Incident management - Přehled aktivit

21

Incident je definován jako jakákoliv událost, která není součástí standardního provozu služby a která

způsobí, nebo může způsobit, přerušení nebo snížení kvality dodávané služby.

46



Nejčastější problémy a slepé uličky: 1. Přístup uživatelů přímo do podpůrného nástroje Incident managementu a nastavení jednoznačných pravidel pro objektivní určení priority incidentu (tj. dopadu a naléhavosti). Prioritu a tím také způsob a rychlost řešení incidentu stanovuje operátor Service desku v součinnosti s uživatelem. V případě, že uživatel zadává incident prostřednictvím podpůrného nástroje (tj. bez přímého kontaktu s operátorem, má většinou tendenci nastavit vyšší než reálnou prioritu, v domnění, že tak řešení incidentu urychlí). To má negativní dopady jak na kapacitní vytížení specialistů tak na kvalitu zpracování ostatních incidentů. Proto je potřeba stanovit pro prioritizaci incidentů jasná pravidla a zajistit jejich dodržování i pro případ, že uživatel definuje prioritu incidentu sám. Osvědčeným řešením je nastavení role tzv. klíčových uživatelů, kdy jsou skupiny uživatelů zaštiťovány jedním klíčovým uživatelem (jinak také super uživatel). Řadoví uživatelé jsou v takovém případě povinni hlásit své požadavky klíčovému uživateli, který buď problém sám odstraní, anebo požadavek předá na Service desk. Řadoví uživatelé nemají právo kontaktovat Service desk přímo – v případě, že tak udělají, je zpracování jejich požadavku zpoplatněno. 2. Životní cyklus incidentu – uzavření incidentu až po akceptaci řešení uživatelem V případě, že je proces nastaven tak, že incident smí být uzavřen až ve chvíli, kdy proběhne akceptace jeho řešení uživatelem, dochází často k překroční parametrů SLA. Uživatel totiž není motivován uzavřít incident ihned jak obdrží informace o jeho vyřešení, pro něj je důležité, že je služba obnovena. Proto je lepší měřit dobu zpracování incidentu, jako dobu do jeho vyřešení (viz tabulka aktivit 1.-6.), nikoliv do akceptace zákazníkem a uzavření (viz tabulka aktivit 1.-8.). Případnou neakceptaci řešení ze strany zákazníka lze řešit definováním procesu reklamací (např. po odmítnutí řešení zákazníkem se založí nový incident, který bude obsahovat vazbu na původní incident)

47



3.3.3.3. Problem Management Cílem procesu problem management je: -

Minimalizovat nepříznivý dopad incidentů a problémů na provoz IT služeb (tzn. na zákazníky a uživatele)

-

Zajišťuje prevenci opakovaného výskytu incidentů souvisejících se stejnou chybou tím, že zjišťuje a následně odstraňuje příčinu těchto incidentů.

Problem management odpovídá za řízení životního cyklu problémů a za správu databáze známých chyb. Problem management svou činností zajišťuje stabilitu infrastruktury. Vstupy -

Výstupy

Podrobnosti o incidentech z procesu incident management

-

Známé chyby

Podrobnosti o konfiguračních

-

Požadavky na změnu / předem schválená změna

položkách ze CMDB -

Způsob řešení incidentů nalezený

-

Aktualizace záznamů o problémech

v procesu incident management

-

Uzavřené problémy

Informace o změnách z procesu change

-

Informace managementu (reporty)

management Tab. 4 Problem Management – Vstupy a výstupy

Problem Management – přehled hlavních aktivit 12. Identifikace a klasifikace problému 13. Analýza a návrh řešení problému 14. Implementace řešení (Change management) 15. Záznam známé chyby 16. Uzavření záznamu Problému 17. Řízení životního cyklu a reporting procesu Tab. 5 Problem management - Přehled aktivit

Za účelem dosažení uvedeného cíle, problem management hledá příčinu vzniku jednotlivých incidentů a poté iniciuje potřebná protiopatření vedoucí k redukci nebo odstranění příčiny a tím i problému. Proces problem management má reaktivní i proaktivní podobu. Reaktivně reaguje na opakující se incidenty tím, že se hledá jejich příčinu. Proaktivně je zaměřen na identifikaci základních příčin incidentů ještě před tím, než se tyto incidenty zopakují.

48



Nejčastější problémy a slepé uličky: 1. Nastavení smlouvy se zákazníkem versus očekávání a motivace poskytovatele IT služeb Při nastavování parametrů SLA by měla být vzata v úvahu charakteristika poskytovaných služeb a potřeby zákazníka. V případě problem managementu jde o základní dva přístupy: 1. Poskytovatel IT služeb bude placen za počet zpracovaných incidentů za dané období. (Platí především pro provoz Service Desku) 2. Poskytovatel služeb bude placen fixní/paušální částkou za provoz IT služeb. Ad 1. Poskytovatel nemá žádnou motivaci provádět aktivity vedoucí k eliminaci příčin incidentů. Pokud by snížil počet incidentů, snížil by tak i svůj příjem. Pro tyto případy je dobré nastavit ve smlouvě pravidlo pro odměňování v případě proaktivního vývoje kvality služeb. Ad 2. Motivace poskytovatele IT služeb je vysoká. Tím, že provádí problem management proaktivně udržuje vysokou kvalitu služeb a zároveň tím chrání i vlastní IT infrastrukturu tím, že eliminuje případné problémy již v počátku. 2. Řízení problem managementu dodavatelů Ve smlouvě s dodavateli by mělo být podchyceno, jakým způsobem bude řízen problem management v rámci dodavatelského řetězce. Problémy, které souvisí se službami, na jejichž dodávce se podílí i jiné organizace musí být řešeny napříč dodavatelskými organizacemi, aby bylo jejich řešení, co nejtransparentnější. Příklad: Service desk zaznamená incident spojený s funkčností aplikace, kterou dodává dodavatel XY, Service desk správně identifikuje řešitelskou skupinu a předá incident k vyřešení dodavateli. Dodavatel incident vyřeší a informuje o vyřešení Service Desk. V případě, že do řešení incidentu nepopíše způsob řešení incidentu (work-around), ztrácí se tím cenná informace pro případ, že by se incident opakoval. V případě, že se jednalo o incident, jehož příčinu je potřeba odstranit, zpracuje dodavatel tuto informaci prostřednictvím change managementu.

49



Tato vazba incident – problem – změna, by měla být zaznamenána, aby nedocházelo ke ztrátě informací a prodlužování doby řešení odstranění příčiny opakujících se incidentů (viz další „slepá ulička“). 3. Nastavení vazeb mezi: incident – problem – change management Související záznamy by se při přechodu mezi jednotlivými procesy neměly ztrácet. Dle mého názoru by to měl být Service desk, kdo udržuje záznamy jak o původních incidentech, tak o incidentech, které byly předány do řešení Problem managementu tj. problémech, následně známých chybách

22

a posléze i požadavcích na změnu, které vznikly na základě Známé

chyby. Přestože formálně je za správu databáze chyb odpovědný problem management, operativní správu by měl zajišťovat Service desk. 4. Problem management versus zákazník Zákazník obvykle není do procesu problem management zahrnut – výstupy problem managementu může sledovat jen prostřednictvím rostoucí kvality služeb případně v podobě reportů z procesu.

22

Tj. problémech, u kterých byla objevena příčina

50



3.3.3.4. Konfigurační management Cílem procesu Konfigurační management je: -

Definice osob zodpovědných za jednotlivá IT aktiva a poskytované služby

-

Poskytovat přesné informace ostatním procesům řízení služeb

-

Verifikovat záznamy v konfigurační databázi oproti skutečnosti a provádět nápravy zjištěných odchylek

Konfigurační management definuje a udržuje logický model stavebních – konfiguračních prvků infrastruktury a služeb prostřednictvím identifikace, kontroly, udržování a verifikace jednotlivých konfiguračních položek a jejich vzájemných vazeb. Vstupy -

Výstupy

Uživatelská, provozní, technická a administrátorská dokumentace

-

Informace o stavebních prvcích

-

Konfigurační databáze

-

Strukturované informace o jednotlivých konfiguračních

infrastruktury a jejich vzájemných

položkách a jejich vzájemných

vazbách -

Informace o službách (SLA, katalog služeb)

vazbách -

Reporting

Tab. 6 Konfigurační Management – Vstupy a výstupy

Konfigurační Management – přehled hlavních aktivit 1. Analýza a návrh procesu 2. Identifikace konfiguračních položek 3. Operativní řízení CMDB / konfiguračních položek 4. Revize stavu CMDB 5. Řízení životního cyklu KP a reporting procesu Tab. 7 Konfigurační management - Přehled aktivit

51



Nejčastější problémy a slepé uličky: 1. Konfigurační management silná závislost na change management Implementovat konfigurační management nemá příliš smysl, pokud není definováno, jakým způsobem budou informace, které spravuje, aktualizovány. Jaké budou vazby mezi změnami v poskytovaných službách nebo komponentách infrastruktury, promítnuty do modelu konfiguračních položek v CMDB a nebude navržen životní cyklus konfigurační položky (např. registrováno, schváleno, implementováno, vyřazeno apod.). Proces správy CMDB by měl být z velké části automatizovaný tj. využívat údajů z monitorovacích nástrojů.. Správu CMDB by měl provádět ten, kdo vlastní příp. spravuje většinu konfiguračních položek. 2. Návrh CMDB – různé úhly pohledu versus náklady Návrhu obsahu a struktury CMDB by se měli účastnit všichni, kteří budou CMDB nějakým způsobem používat. Příklady skupiny uživatelů CMDB: -

Zástupci ostatních procesů ITSM (vlastníci, výkonné role) o

Service desk, Incident a problem management

o

Change a release management

o

Service level management

o

Availability, IT Service continuity a Capacity management

o

Financial management

-

Technici

-

Konzultanti

-

Vedení společnosti

-

Ostatní (např. vedení provozu IT, projektový a servisní manažeři, aplikační management apod.)

Výsledné řešení by mělo být přijatelné pro většinu zúčastněných a musí být nákladově efektivní – čím detailnější struktura CMDB, tím dražší je její implementace a provoz,

52



proto by měl být zvážen i skutečný význam a přinos jednotlivých typů konfiguračních položek a jejich atributů, které se mají v CMDB udržovat. 3. Implementace CMDB – správné načasování Analýza i následná implementace je velmi náročná a komplikovaná, při správné implementaci je odměnou vysoká přidaná hodnota. Důležité je dobré načasování implementace procesu (nepatří mezi quick wins – přínosy jsou znatelné až po delším čase po implementaci).

53



3.3.3.5. Change Management Cílem procesu change management je: -

zajištění hladké a nákladově efektivní implementace schválených změn

-

řízení celého životního cyklu požadavku na změnu, jeho definice, schvalování, koordinace jednotlivých stran, které se podílejí na vývoji a implementaci změny

-

minimalizace vzniku incidentů vyplývajících z neohlášených a neřízených změn v aplikacích a IT infrastruktuře.

Change management zajišťuje a řídí i změny v rámci ostatních procesů ITSM. Vstupy

Výstupy -

Plán změn (Forward Schedule of Changes) a ostávek

-

Informace o změně konfigurační položky v CMDB

-

Návrh/požadavek na změnu (v

-

aplikaci/infrastruktuře)

Informace o zdroji financování/nákladech na realizaci změny

-

Údaje o stávajících službách

-

Informace o změně/vytvoření služby

-

Údaje o konfiguračních položkách

-

Informace o uzavření a důvodu uzavření požadavku na změnu

-

Reporting

-

Aktualizovaný obsah vstupu/výstupu/aktivit/záznamu ostatních ITSM procesu

Tab. 8 Change Management – Vstupy a výstupy

Change Management – přehled hlavních aktivit 1. Identifikace požadavku na změnu 2. Zpracování požadavku na změnu 3. Realizace změny 4. Uzavření požadavku na změnu 5. Řízení průběhu procesu a reporting Tab. 9 Change management - Přehled aktivit

54



Nejčastější problémy a slepé uličky: 1. Interní versus externí change management Při implementaci change managementu je potřeba zvážit odlišnosti interního a externího change managementu. Jiná pravidla je potřeba nastavit pro úroveň IT služeb, která je spravována interně a jiná pro externí systémy. Jedná se o proces, který má ochraňovat infrastrukturu IT služeb proti neschváleným tím pádem neoprávněným zásahům, pro dodavatele by měl být nastavený systém sankcí pro případ, že nedodrží pravidla definovaná procesem. V případě, že jsou definována pravidla pro „Předem schválené změny“ – tj. změny, u kterých platí jen oznamovací povinnost o jejich implementaci, je potřeba tato pravidla a typy změn, které lze provádět mimo schvalovací proces CAB, přesně vymezit, aby nemohlo být tohoto sub-procesu zneužíváno k implementaci ostatních změn. 2. Frekvence jednání CAB (Change Advisory Board) Pravidla a frekvence jednání CAB – neměla by být příliš často, protože jednání CAB je velmi nákladné, ale zároveň nesmí absence jednání CAB brzdit efektivní nasazování změn. Doporučená frekvence změn ve společnosti zabývající se poskytováním IT služeb je 2krát měsíčně s možností svolat v případě potřeby CAB dříve.

55



3.3.3.6. Release Management Cílem procesu release management je: -

Plánovat a dohlížet na implementaci softwaru a souvisejícího hardwaru do testovacího a produkčního prostředí organizace

-

Zabezpečit, že změny hardwaru a softwaru jsou bezpečné a identifikovatelné a je jasně definovaný sled činností, požadavky na součinnost a hlavně odpovědnosti za jednotlivé činnosti

-

Zabezpečit, že jsou do produkčního prostředí instalovány pouze správné, schválené a otestované verze hardwaru a softwaru

-

Komunikovat a řídit očekávání zákazníků během přípravy nových Release a následně i během samotné implementace

-

Plánovat přesný obsah jednotlivých Release a jejich nasazení ve spolupráci s Change Managementem

-

Realizovat implementaci nových Release a souvisejícího hardwaru do produkčního prostředí za využití kontrolních mechanismů Configuration Managementu a Change Managementu

Proces release management je odpovědný za to, že nasazení všech změn do produkčního prostředí bude řízeno a organizováno efektivně, a to po nákladové i organizační stránce. Vstupy

Výstupy -

Komponenty nasazené do produkčního prostředí

-

Technologické a vývojové standardy

-

Informace o konfiguračních položkách

-

Známé chyby

ze CMDB

-

Report o průběhu a výsledku release

Schválené změny

-

Záznamy z monitoringu

-

Reporty

-

Tab. 10 Release Management – Vstupy a výstupy

56



Release Management – přehled hlavních aktivit 1. Plánování a iniciace release 2. Zhodnocení a schválení rozsahu release 3. Rozhodnutí o skupině specialistů 4. Vývoj release 5. Testování release 6. Příprava plánu implementace Release (dokument Release to production - RTP) 7. Schválení plánu implementace Release 8. Informování uživatelů o release 9. Nasazení do produkčního prostředí 10. Ukončení implementace release 11. Řízení průběhu procesu a reporting Tab. 11 Release management - Přehled aktivit

Nejčastější problémy a slepé uličky: 1. Nastavení rozhraní konfiguračního a release managementu Nastavení rozhraní mezi procesem Release a Konfigurační management tj. způsob a pravidla pro předání realizovaných změn do CMDB, v případě, že CMDB vlastní zákazník nebo dodavatel. V případě, že CMDB nevlastní přímo poskytovatel služeb lze provádění aktualizace záznamů v CMDB poskytovat jako službu, prostřednictvím automatizovaného nástroje. 2. Dodržování procesu (testování, příprava RTP apod.) Největším problémem IT projektů i provozu je: naučit a udržet IT personál dodržovat stanovené postupy a pravidla. Pomoci v tomto ohledu mohou předdefinované formuláře, které kromě jiného obsahují „checklist“ aktivit, které mají být v rámci jednotlivých fází procesu/projektu vykonány (např. příprava dokumentace, školení, příprava testovacích scénářů, testování apod.) – součástí takového formuláře je i část definující odpovědnosti za vykonání jednotlivých aktivit a položka pro akceptaci splnění včetně podpisu. Takto jednoznačné a jmenovité určení odpovědných osob zpravidla pomáhá redukovat počet přestupků oproti nastavenému procesu na minimum.

57



3.3.3.7. Service Level Management Cílem procesu service level management je: -

Zajistit kvalitní a seriozní vztah mezi poskytovatelem IT služeb a zákazníkem

-

Nastavit dostatečné pokrytí podpory IT služeb

-

Nastavit, udržovat a zlepšovat kvalitu IT služeb: o

Nastavením cílů, které je možné měřit

o

Vyhodnocováním dosažených výsledků, ve smyslu kvality IT služeb, a na jejich základě podněcovat k aktivitám vedoucím k odstranění nepřijatelných úrovní IT služeb

Service Level management zajišťuje na každodenní bázi sledování úrovně a nákladovou efektivitu služeb, plnění parametrů definovaných v SLA a v součinnosti s ostatními procesy zajišťuje řešení nedostatečné úrovně služeb. Service Level management zajišťuje komunikaci mezi stranou poskytovatele IT služeb a zákazníkem – zajišťuje jednání uvedených stran o poskytovaných IT službách (na základě Katalogu služeb) a o jejich úrovni (parametry SLA). Vstupy

Výstupy

-

Vybrané stávající nepopsané služby

-

Požadavky zákazníka

-

SLA

-

Smlouvy

-

Katalog služeb

-

SLA

-

Revidovaná SLA a podpůrné systémy

-

Informace o technologii

-

Revidovaný SLM proces

-

Výstupy dohledových nástrojů

-

Požadavky na změny

-

Reporty z ostatních procesů

-

Reporting

-

Podniková a informační strategie

Tab. 12 Service Level Management – Vstupy a výstupy

58



Service Level Management – přehled hlavních aktivit 1. Příprava katalogu IT služeb 2. Příprava návrhu SLA 3. Vyjednávání a tvorba SLA 4. Monitoring SLA 5. Reporting SLA 6. Správa katalogu služeb a SLA 7. Revize SLA a podpůrných smluv 8. Revize SLM procesu 9. Monitoring a reporting procesu Tab. 13 Service Level management - Přehled aktivit

Nejčastější problémy a slepé uličky: 1. Priorita incidentu versus SLA V případě, že probíhá výběr podpůrného nástroje pro proces incident management, měl by být brán v úvahu i způsob kategorizace incidentů dle SLA a vazba na další parametry uvedené v SLA (např. doba na odstranění incidentu podle jednotlivých kategorií apod). Nástroj by měl umožnit rozdělení na incidenty, které jsou řízeny podle SLA a které nikoliv. V případě, že se incident týká služby, která je ošetřena v SLA, měl by automaticky určit dobu řešení uvedenou SLA. 2. Řízení požadavků zákazníka prostřednictvím SLA Návrh SLA by měl být sestaven na straně poskytovatele IT služeb. Při vyjednávání úrovně jednotlivých SLA parametrů by měl mít zástupce poskytovatele IT služeb připraveny informace v podobě vývoje nákladů23 v závislosti na výši garantované dostupnosti služeb. Zákazník by si měl být vědom, jak důležité je správně vybalancovat úroveň dostupnosti služeb a náklady na její dosažení.

23

Např. náklady na lidské zdroje, prostory, související jednorázové investice, know-how, technologie, marže a krytí rizika v případě rozsáhlého výpadku

59



V případě, že je služba závislá na součinnosti subdodavatelů, měli by být také přizvání k sestavování SLA se zákazníkem. 3. Přístup k IT službám přes webový portál versus nastavení SLA V případě, že jsou IT služby (např. přístupy do jednotlivých aplikací) řešeny prostřednictvím webového portálu, mělo by být se zákazníkem vydefinováno jakým způsobem se bude počítat dostupnost služeb běžících za portálem v případě výpadku portálu. (Pozn. V případě, že webový portál nebude dostupný, nebude dostupná ani žádná služba, která je jeho prostřednictvím poskytována.)

60



3.3.3.8. Availability Management Hlavním cílem procesu Availability Management je optimalizovat schopnost IT infrastruktury, služeb a dodavatelských organizací dodávat nákladově efektivní a trvale stabilní úroveň dostupnosti, která umožní odběrateli služeb naplnit cíle svých činností. Sekundárními cíli jsou: -

sledovat, měřit a vyhodnocovat stávající úroveň dostupnosti služeb

-

zajistit identifikaci a nápravu slabých míst v infrastruktuře, která způsobují snižování nebo riziko snižování dostupnosti služeb

-

snížit frekvenci a délku trvání incidentů.

Availability management řídí veškeré aktivity, které mohou mít dopad na dostupnost IT služeb tj. mj. školení uživatelů, řízení znalostí, definice postupů a pravidel, výběr podpůrných nástrojů. Vstupy -

Požadavky zákazníka na dostupnost IT služeb

-

-

-

-

Definované cílové hodnoty pro

Požadavky na dostupnost, spolehlivost

dostupnost, spolehlivost a

a udržovatelnost komponent IT

udržovatelnost pro komponenty

infrastruktury -

Výstupy

-

Podklady pro plánování a řízení dostupnosti

Ohodnocení IS služeb z hlediska jejich kritičnosti pro zákazníka

-

Vyjádření k Incidentu/Problému

Informace o konfiguraci a způsobu

-


monitoringu jednotlivých komponent

-

Plán vývoje dostupnosti služeb

IT infrastruktury

-

Reporty a monitoring

SLA / katalog služeb

Tab. 14 Availability Management – Vstupy a výstupy

61



Availability – přehled hlavních aktivit 1. Sběr požadavků na dostupnost 2. Analýza požadavků na dostupnost 3. Monitoring a měření dostupnosti 4. Řízení výpadků dostupnosti 5. Zlepšování dostupnosti 6. Řízení průběhu procesu a reporting Tab. 15 Availability management - Přehled aktivit

Nejčastější problémy a slepé uličky: 1. Výpočet dostupnosti – rozdíl v dostupnosti IT služby a IT komponent Současné monitorovací nástroje umožňují sledovat jak dostupnost jednotlivých stavebních prvků infrastruktury tak i dostupnost na úrovni služeb a aplikací. Odběratele IT služeb by měla zajímat jen dostupnost příp. nedostupnost jednotlivých IT služeb. Dostupnost příp. nedostupnost jednotlivých komponent IT služeb je důležitá pro poskytovatele služeb, umožňuje mu včas přijímat ochranná opatření proti rozsáhlejšímu výpadku způsobeném např. opakovaným přetěžováním některých komponent z důvodu výpadku jiných. Proto by se měl lišit i obsah reportů z availability managementu pro zákazníka a pro poskytovale IT služeb.

62



3.3.3.9. Capacity Management Hlavním cílem procesu Capacity management je zajistit, aby stávající a budoucí kapacita a výkonnost IT systémů splňovala požadavky zákazníka a byla zajištěna nákladově efektivním způsobem. Součástí procesu Capacity management je plánování a řízení kapacity ICT infrastruktury a služeb takovým způsobem, aby bylo dosahováno úrovní definovaných v SLA a zajistila se tak minimalizace možnosti vzniku krizových situací v dodávce IT systémů a služeb. Je důležité, aby byl Capacity management blízce propojen s podnikovou strategií a plánováním. Na druhou stranu, capacity management poskytuje informace o vývoji využití kapacit , výkonnosti infrastruktury, trendech v oblasti IT/IS a poskytuje tak podklady pro strategické řízení a plánování spojené s poskytováním IT služeb. Vstupy -

Požadavky zákazníka

-

SLA

-

Smlouvy

-


-

Informace o incidentech a problémech

-

informace z dohledových nástrojů týkajících se vytížení konkrétních komponent IT infrastruktury

-

plány rozvoje funkcionalit jednotlivých systémů, které byly, jsou nebo budu

Výstupy

-

Informace o kapacitách

-

Podklady pro plánování a řízení kapacit

-

Vyjádření k Incidentu/Problému

-


-

Kapacitní plán

realizovány a mají dopad do kapacit spojených s poskytováním IT služeb -

plány využití jednotlivých systémů

Tab. 16 Capacity Management – Vstupy a výstupy

63



Capacity Management – přehled hlavních aktivit 1. Sběr kapacitních dat 2. Analýza kapacit 3. Optimalizace kapacit 4. Plánování a implementace kapacit 5. Řízení průběhu procesu a reporting Tab. 17 Capacity management - Přehled aktivit

Nejčastější problémy a slepé uličky: 1. Řízení kapacit lidských zdrojů Při plánování Capacity managementu je často opomíjeno plánování kapacit lidských zdrojů, které se podílejí na poskytování IT služeb. Součástí kapacitního plánu by měl být kromě plánu vývoje kapacit IT infrastruktury i přehled plánovaných aktivit, jejich pracnosti a zdrojového krytí. 2. Sběr kapacitních dat? Neprovádíme. Při počáteční analýze procesu a určování zdrojů dat souvisejících s vytížením a kapacitami zdrojů IT služeb je dobré komunikovat především se specialisty za jednotlivé oblasti (správci sítí, databází, aplikací apod.), protože jen oni mají přesný přehled o tom, jaká data a z kterých nástrojů je možné získat. Zástupci vedoucích rolí v provozu IT většinou nemají přesný přehled o tom, jaké informace lze získat z jednotlivých monitorovacích a dohledových nástrojů. 3. Řízení kapacit – náklady na změny Poskytovatel IT služeb doporučuje úpravy/změny kapacit prostřednictvím požadavku na změnu (tj. proces change management), ve kterém by měly být definovány důvody změny (např. provedené analýzy trendu a jejich závěry), náklady na změnu a zároveň i rizika spojená s neprovedením změny.

64



3.3.3.10. Financial Management IT služeb Cílem procesu Finanční management je: -

Poskytovat nákladově optimální správcovství IT majetku a zdrojů v rámci poskytování IT služeb

Financial Management se skládá ze tří hlavních procesů: řízení rozpočtu (budgeting), zúčtování IT služeb (IT accounting) a řízení nákladů/zpoplatňování (charging). Řízení rozpočtu (budgeting) – je proces, který se zabývá predikcí a posléze i kontrolou čerpání rozpočtu. Součástí procesu je I vyjednávání výše rozpočtu. Zúčtování IT služeb (IT Accounting) -

sada procesů, které definují zodpovědnosti za řízení

nákladů na IT služby a způsob jejich rozdělení – umožňuje definovat náklady na zákazníka, službu a na jednotlivé aktivity. Součástí procesu je i vedení účetní evidence všech nákladů vynaložených za provoz IT služeb, nákladové analýzy (ROI apod.), zjišťuje náklady na změnu. Řízení nákladů/zpoplatňování (charging) – sada procesů, které umožňují IT úseku fungovat jako obchodní a nikoliv jako nákladová jednotka. Zajišťují, že zákazníkům jsou účtovány Vstupy

Výstupy

-

SLA

-


-

Smlouvy

-

Požadavek na změnu – informace o

-

Informace o čerpání rozpočtu

nákladech na změnu

-

Detailní analýza nákladů

-

-

Eskalace (v případě přečerpání rozpočtu)

Plánovaný rozpočet

Tab. 18 Financial Management – Vstupy a výstupy

65



Financial Management – přehled hlavních aktivit 1. Plánování rozpočtu pro IT služby 2. Evidence nákladů 3. Porovnání reálných nákladů s plánovaným rozpočtem 4. Výpočet nákladů na služby a na změny služeb 5. Výpočet návratnosti investic 6. Účtování služeb 7. Procesní zpracování faktur 8. Monitoring a reporting procesu Tab. 19 Financial management - Přehled aktivit

Nejčastější problémy a slepé uličky: 1. Oceňování služeb Provedení nákladové analýzy a následného nacenění služeb a jejich komponent je zdrojově velmi náročné, proto je dobré zvážit, které služby je potřeba ocenit a úroveň detailu rozpadu nákladů. Vycházet lze například z Katalogu služeb, ve kterém by měl být uvedený souhrnný přehled poskytovaných služeb i souvisejících parametrů. Informace o nákladech – jejich tvorbě a vývoji by měl financial management získávat od capacity a availability managementu. Po úvodním provedení nacenění služeb je provoz procesu úzce spojen s change managementem a service level managementem. 2. Interní účtování služeb Zavedení interního účtování IT služeb tj. zpoplatnění služeb pro uživatele v rámci jedné organizace se ukázalo ve většině případů jako neefektivní. Náklady na IT služby byly velmi vysoké a IT oddělení tím sice ztratilo pozici „nákladového střediska“ a získalo vlastní příjmy, ale zároveň se proces poskytování služeb velmi zkomplikoval jak na úrovni jednotlivých uživatelů, tak i na úrovni oddělení. Relativně efektivním řešením je rozdělení služeb na standardní a nadstandardní, přičemž zpoplatněny jsou jen služby z kategorie nadstandardní a jejich přidělení jednotlivým uživatelům schvaluje vedoucí oddělení příp. nákladového střediska.

66



3.3.3.11. IT Service Continuity Management Hlavním cílem procesu IT Service Continuity Management je zajistit obnovu funkčnosti ICT infrastruktury po vážném (rozsáhlém) výpadku24, a to v požadovaných a schválených mezích. Účinný proces řízení kontinuity služeb minimalizuje pravděpodobnost výskytu vážného výpadku dostupnosti IT služeb a jeho důsledků pro klíčové funkce organizace Proces se v případě, kdy nastane havarijní situace stává řídícím procesem, který se aktivně zabývá obnovením provozu systému a poskytovaných služeb. Součástí procesu je i sestavení Plánu kontinuity služeb, což je dokument popisující postup obnovy systému po rozsáhlém výpadku. Vstupy -

-

Výstupy

Požadavky zákazníka na dostupnost IT služeb

-

Analýza dopadu

Ohodnocení IS služeb z hlediska jejich

-

Analýza rizik

kritičnosti pro zákazníka

-

Podklady pro plánování a řízení kontinuity služeb

Informace o konfiguraci a způsobu monitoringu jednotlivých komponent

-

Plán kontinuity IT služeb

IT infrastruktury

-

Reporty a monitoring

SLA / katalog služeb

Tab. 20 IT Service Continuity Management – Vstupy a výstupy

IT Service Continuity Management – přehled hlavních aktivit 1. Iniciace podnikové strategie kontinuity (BCM) 2. Analýza požadavků a strategie 3. Analýza dopadu, ohodnocení rizik, stanovení strategie 4. Příprava plánu kontinuity a zavádění protiopatření 5. Vzdělávání zúčastněných stran 6. Testování plánu 7. Řízení rozsáhlého výpadku/havarijního stavu 24

Provozuschopnost a dostupnost služeb infrastruktury a jejích jednotlivých komponent, narušenou menšími výpadky se zabývají procesy Incident a Availability management.

67



IT Service Continuity Management – přehled hlavních aktivit 8. Revize a audit 9. Reporting Tab. 21 IT Service Continuity management - Přehled aktivit

Nejčastější problémy a slepé uličky: 1. Závislost na Business kontinuity managementu (BCM) IT Service continuity management by měl být vyvíjen na základě požadavků definovaných v BCM (tj. strategický dokument popisující způsob zachování kontinuity činností celé organizace). V případě, že v organizaci BCM není zaveden, je proces a požadavky na dlouhodobý vývoj a stav dostupnosti IT služeb řízen procesem Service Level Management. V takovém případě by SLA mělo obsahovat nejen parametry týkající se dostupnosti služby, ale také kritičnosti a významu služby pro zákazníka (vyplývá z analýzy dopadu). 2.

Testování Plánu kontinuity

Rozhodnutí o provedení testů plánu kontinuity by mělo provést vedení společnosti. Poskytovatel IT služeb by se měl v každém případě pokusit prosadit jeho realizaci. V případě, že testování nebude schváleno (např. z důvodu vysokých nákladů, rizika, odporu zákazníka k dobrovolnému omezení dostupnosti služeb), mělo by být toto rozhodnutí provedeno na strategické úrovni a zaznamenáno. V případě potřeby by měla být přijata vhodná protiopatření proti možným ztrátám způsobeným výpadkem např.

pojištění,

smlouvy s partnery o poskytnutí podpory v případě rozsáhlého výpadku apod..

68



4. Závěr Problematika řízení IT služeb je a pravděpodobně i v budoucnu bude aktuálním tématem nejen pro společnosti poskytující IT služby, ale i pro ty, pro které nepředstavuje IT zdroj výdělku, ale „jen“ podporu a způsob realizace byznys procesů a souvisejících cílů. Procesy ITSM poskytují oběma stranám tj. poskytovatelům i odběratelům IT služeb komunikační prostředek, kontrolní a řídící mechanizmus pro oblast IT a díky vývoji normy ISO/IEC 20000 i určitou garanci kvality IT služeb. V poslední době se právě v oblasti ITSM objevilo mnoho novinek (ITIL Refresh, ISO/IEC 20000) a s nimi i nových otázek a oblastí, na které je potřeba hledat odpovědi, poznávat je a řešit. Kromě zmiňovaných novinek je zde i celá řada již existujících oblastí, které se při implementaci procesů ITSM ukazují zpravidla jako problematické nebo komplikované ve svém řešení a zaměstnávají tak konzultanty a specialisty na tuto oblast v mnoha společnostech nejen v České republice ale i ve světě. Cílem mé práce bylo blíže představit problematiku ITSM včetně jejího začlenění do systému řízení současných společností, zmapovat její postavení ve srovnání s ostatními přístupy k řízení IT služeb a v neposlední řadě i vydefinovat a popsat problematické oblasti, tzv. „slepé uličky“ implementace procesů ITSM.

69



V následující tabulce uvádím přehled cílů, které jsem si v úvodu mé práce stanovila, nyní i s popisem jejich naplnění. #

Definice cíle

Způsob dosažení

Vymezit postavení ITSM mezi ostatními 1

metodikami pro řízení IT služeb (eTOM,


MOF, referenční model HP IT service


management). Zmapovat a popsat vztah ITSM a IT 2

governance, jejich vzájemné vazby a rozdíly.

3

4

Studium odborné literatury a zvolených metodik pro řízení IT služeb.

Zmapovat a popsat vazby a rozdíly mezi

Studium normy ISO/IEC 20000.

ITIL verze 2 a aktuálními tématy z oblasti

Účast na kurzu ISO 20000 for Consultants

ITSM tj. ISO/IEC 20000 a ITIL Refresh.

and Internal Auditors.25

Identifikovat problémy (překážky, slepé


uličky) vznikající při praktické


implementaci problematiky popsané

Konzultace s odborníky z praxe.

v knihách ITIL – procesů ITSM.

Účast na odborné konferenci ICTM 2008.

Tab. 22 Přehled cílů diplomové práce

Ad 1.

Jednotlivé rámce pro řízení IT služeb jsem ve své práci ve stručnosti popsala, definuji jejich původ a uvádím souhrn nejvýraznějších rozdílů oproti ITSM/ITIL. Součástí této části je i popis vazeb těchto metodik na ITSM/ITIL. Kapitola 2.9

Ad 2.

Vazby, rozdíly a vzájemné postavení IT Governance a ITSM popisuji detailně v Kapitole 2.4

Ad 3.

Základní popis normy ISO/IEC 20000, včetně jeho vazeb na procesy ITSM popisuji v Kapitole 2.5.2. V Kapitole 2.5.2 popisuji příčiny, které vedly ke vzniku ITIL v3, zároveň zde uvádím i základní rozdíly oproti ITIL verze 2.

Ad 4.

Identifikaci problémů (překážky, slepé uličky) vznikajících při praktické implementaci procesů ITSM jsem si stanovila jako svůj hlavní cíl – proto jsem této otázce věnovala největší část své práce. Kapitoly 3.1. až 3.3.

25

Tvůrcem i provozovatelem kurzu je společnost Hewlett-Packard Development Company, L.P.

70



Výsledkem mé práce je zjištění, že pro efektivní řízení IT služeb je nejvhodnější přístup založený na integraci všech tří hlavních stavebních kamenů ITSM, kterými jsou lidé, nástroje a procesy při současném respektování významu a potřeby odlišného přístupu ke každé z uvedených částí. Zároveň je dobré přizpůsobit svůj přístup i očekávání způsobu implementace ITSM (formou interního/externího projektu) a prostředí (komerční versus veřejný sektor). Přínosem mé práce by mohl být sestavený přehled slepých uliček (viz Příloha 1), překážek a možných přístupů k implementace ITSM. I přes veškerou mou snahu, jsem si vědoma toho, že tento přehled není kompletní a věřím, že se již v příštích dnech v praxi setkám s překážkou, kterou bych do své práce měla také zařadit.

71



5. Zdroje 5.1.

Elektronické zdroje

[1]

Wikipedia, the free encyclopedia [online], 2008: Corporate Governance, Wikimedia Foundation, last modif. on 21 June [cit. 22.7.08]. Dostupný z www:

[2]

Wikipedia, the free encyclopedia [online], 2008: Sarbanes-Oxley_Act, Wikimedia Foundation, last modif. on 21 June [cit. 22.7.08]. Dostupný z www:

[3]

Wikipedia, the free encyclopedia [online], 2008: SOX 404 and information technology, Wikimedia Foundation, last modif. on 21 June [cit. 22.7.08]. Dostupný z www:

[4]

ISACA [online], USA, 2008: [cit.. 22.7.08]. Dostupný z www: < http://www.isaca.org>

[5]

ITIL: IT Governance [online], ITIL, 2008: IT Governance [cit.. 22.7.08]. Dostupný z www: < http://www.itil.cz/index.php?id=917>

[6]

ITIL: ITIL [online], ITIL, 2008: ITIL - Důvody pro zavedení [cit. 22.7.08]. Dostupný z www: < http://www.itil.cz/index.php?id=988>

[7]

Bill Powell: IT Governance Important For ITSM Implementations, June 20, 2005, Jupitermedia Corporation [online], 2008: [cit.. 22.7.08]. Dostupný z www: < http://www.itsmwatch.com/itil/article.php/3514011>

[8]

Mathias Sallé: IT Service Management and IT Governance: Review, HewlettPackard, 2004 [online], [cit.. 22.7.08]. Dostupný z www: < http://www.hpl.hp.com/techreports/2004/HPL-2004-98.pdf>

[9]

Wikipedia, the free encyclopedia [online], 2008: ITIL History, Wikimedia Foundation, last modif. on 22 June [cit. 22.7.08]. Dostupný z www: < http://en.wikipedia.org/wiki/ITIL#ITIL_History>

[10]

ITIL: Procesní řízení [online], ITIL, 2008: Procesní řízení, [cit.22.7.08]. Dostupný z www: < http://www.itil.cz/index.php?id=914>

[11]

ITIL: Procesní řízení - CMM [online], ITIL, 2008: CMM – model procesní vyspělosti organizace [cit.. 22.7.08]. Dostupný z www: < http://www.itil.cz/index.php?id=956>

[12]

Wikipedia, the free encyclopedia [online], 2008: Capability Maturity Model, Wikimedia Foundation, last modif. on 21 June [cit. 22.7.08]. Dostupný z www: < http://en.wikipedia.org/wiki/Capability_Maturity_Model>

72



[13]

ITIL: ITIL [online], ITIL, 2008: Implementace ITIL [cit.. 22.7.08]. Dostupný z www: < http://www.itil.cz/index.php?id=990>

[14]

TMForum, the free encyclopedia [online], 2008: Business Process Framework (aka eTOM), [cit. 22.7.08]. Dostupný z www: < http://www.tmforum.org/browse.aspx?catID=1647>

[15]

Hewlett-Packard Development Company, L.P., Service Management- Services Service Management Reference Model, [online], 2008, [cit. 22.7.08]. Dostupný z www:

[16]

Microsoft Corporation, What Is the Microsoft Operations Framework?, , [online], 2008, [cit. 22.7.08]. Dostupný z www: < http://msdn.microsoft.com/en-us/library/ms959769.aspx>

[17]

Wikipedia, the free encyclopedia [online], 2008: Microsoft Operations Framework, Wikimedia Foundation, last modif. on 12 May [cit. 22.7.08]. Dostupný z www: < http://en.wikipedia.org/wiki/Microsoft_Operations_Framework>

[18]

Khudhur, P: IT ve státní správě , [online], IDG Czech, 2008, [cit. 22.7.08]. Dostupný z www: < http://www.businessworld.cz/bw-id/IT_ve_statni_sprave_0711_BW>

73


5.2.


Literatura

[CISA_manual]

ISACA: CISA Review Manual 2008 English Edition, USA, 2007, ISBN 978-1-933284-93-4

[ISO_20000_1]

ISO/IEC 2005: ISO/IEC 20000-1 Information technology – service management Part 1: Specification, 2005, Geneva

[ISO_20000_2]

ISO/IEC 2005: ISO/IEC 20000-2 Information technology – service management Part 2: Code of practice, 2005, Geneva

[ISO_20000_HP]

Materiály Hewlett-Packard ke kurzu ISO 20000 for Consultants and Internal Auditors

[TO2S_BOVA]

Materiály TO2S26, spol. s r.o. ke kurzu ITIL – Basic overview

[TO2S_FOUN]

Materiály TO2S, spol. s r.o. ke kurzu ITIL – Foundation

[ICTM_Kufner]

Kufner, V.: ITIL Refresh – co se chystá?, sborník konference ICTM 2007, 2007, Praha, TO2S, FEL ČVUT,: ISBN 80-0103700-3

[ICTM_Hospes]

Hospes, J.: Pohled na ICT procesy z úhlu telekomunikačních společností a jejich standardů - eTOM, sborník konference ICTM 2008, 2008, Praha, TO2S, FEL ČVUT, ISBN: 978-8001-04070-6

[ICTM_Bělina]

Bělina, R.: Implementace procesů ITIL z pohledu motivace lidí, sborník konference ICTM 2008, 2008, Praha, TO2S, FEL ČVUT, ISBN: 978-80-01-04070-6

[ICTM_Skála]

Skála, J.: Aspekty integrace procesů, lidí a nástrojů, sborník konference ICTM 2008, 2008, Praha, TO2S, FEL ČVUT, ISBN: 978-80-01-04070-6

[ITIL_SS]

OGC: Service Support, TSO, 6. vydání, 2002, ISBN 0-11330015-8

[ITIL_SD]

OGC: Service Delivery, TSO, 3. vydání, 2002, ISBN 0-11330017-4

26

Telefónica O2 Services

74



6. Terminologický slovník Termín

Zkratka

Význam

Availability Management

AM

Capacity Management Configuration (konfigurační) Management

CaM

Control Objectives for Information and related Technology Corporate Governance

Cobit

Řízení dostupnosti - proces odpovídá za dosažení odpovídající úrovně služeb. Zahrnuje měření a monitorování dostupnosti služeb, porovnávání hodnot s SLA a spuštění kroků vedoucích k žádoucímu stavu. Řízení kapacit - proces odpovídá za zajištění dostatečné kapacity infrastruktury. Řízení konfigurací - poskytuje logický model infrastruktury a služeb pomocí identifikace, řízení, správy a verifikace všech konfiguračních položek, které jsou součástí poskytovaných služeb. Všeobecně přijímaný standard pro správné postupy řízení, kontroly a auditu informačních technologií.

Databáze změn

-

Databáze znalostí/známých chyb Doba řešení incidentu Dopad incidentu

KB

Úložiště záznamů o incidentech a jejich řešeních (workarounds)

-

Čas od převzetí Incidentu řešitelskou skupinou do finálního nebo dočasného vyřešení daného incidentu. Rozsah dopadu na uživatelskou skupinu, které se daný požadavek týká. Eskalace je mechanismus, který pomáhá včasnému řešení incidentů. Tento mechanismus se může vyskytnout v průběhu celého procesu. Řízení financí - proces odpovídá za řízení rozpočtů a nákladů na služby, vyhodnocování návratnosti investic. Projednává, schvaluje a vyhodnocuje navrhované změny, jejichž rozsah vyžaduje schválení z technologického a finančního hlediska. Řízení změn - proces zodpovídající za efektivní a rychlé vyřízení požadovaných změn v poskytovaných službách. Účelem je minimalizovat počet incidentů vznikajících jako důsledek implementace neautorizovaných změn.

CoM

-

-

Eskalace

-

Financial Management Change Advisory Board

FM

Change Management

CHM

CAB

Corporate governance definuje rozdělení práv a povinností mezi jednotlivé role spojené s organizací a jejím fungováním jako jsou např. představenstvo, vedení společnosti, akcionáři a další zainteresované strany. Corporate governance definuje pravidla a postupy pro rozhodování v jednotlivých záležitostech organizace. Zdroj: [CISA_manual, str. 72] Evidence změnových požadavků a průběhu jejich realizace.

75



Termín

Zkratka

Význam

Incident

-

Incident Management

IM

Information Technology Infrastructure Library Infrastruktura

ITIL

Jakákoliv událost, která není součástí standardního provozu služby a která způsobí, nebo může způsobit, přerušení nebo snížení kvality dodávané služby. Řízení incidentů - proces zajišťující co nejrychlejší obnovení dodávky služby a minimalizaci dopadů výpadků služeb. ITIL (IT Infrastructure Library) neboli „Knihovna IT infrastruktury“. Obsahuje best practice pro řízení IT služeb.

ISO/IEC 20000 IT Governance

-

IT Service Continuity Management IT služba (IT Service) Katalog služeb

ITSCM

Konfigurační databáze

CMDB

Konfigurační položka

CI

Naléhavost incidentu Plán dostupnosti

-

Plán kapacity

-

Plán kontinuity

-

Plán změn Forward Schedule of Changes

FSC

Požadavky na změnu Problém

RfC/PZ

Identifikovatelná komponenta infrastruktury, která je součástí poskytovaných služeb a je účelné ji samostatně spravovat a řídit. (Hardware, software, lokality, dokumentace…) Jaký vliv má rychlost řešení daného požadavku na normální funkčnost ovlivněné skupiny či jednotlivce. Evidence požadavků na dostupnost v rámci rozvojových smluv a požadavků na změnu vedoucích k zajištění nebo zlepšení dostupnosti služeb. Evidence požadavků na kapacity v rámci rozvojových smluv a požadavků na změnu vedoucích k zajištění nebo zlepšení kapacity služeb. Plán akcí pro případ globálního výpadku nebo katastrofy (krizový plán) Časový plán implementace změn. Zobrazuje data nasazení jednotlivých změn do produkčního prostředí. Vypracovává se vždy na jeden měsíc dopředu a aktualizuje se jednou týdně. Požadavky na nové služby nebo na změny stávající služby.

-

Neznámá příčina jednoho nebo více incidentů

-

-

Zahrnuje serverovou a napájecí infrastrukturu, komunikační infrastrukturu, další hardware včetně konfigurace a prostupů, aplikace. Norma pro řízení kvality IT služeb IT Governance je definovaná struktura vztahů a procesů, pomocí kterých lze řídit a kontrolovat organizaci tak, aby IT v maximální míře umožňovalo a podporovalo dosažení podnikatelských cílů. Zdroj [5] Řízení kontinuity služeb - hlavním cílem je zajištění obnovy funkčnosti služeb po rozsáhlém výpadku v požadovaných a schválených mezích. jeden nebo více IT systémů umožňujících naplnění a podporu realizace podnikového procesu Databáze, která obsahuje informace o poskytovaných službách a SLA parametrech jednotlivých služeb. Databáze obsahující informace o jednotlivých konfiguračních položkách, které jsou součástí poskytování IT služeb a o vazbách mezi těmito položkami..

76



Termín

Zkratka

Význam

Problem Management

PM

Release Management Release To Production Plan

RM

Service Desk

SD

Service Level Agreement

SLA

Řízení problémů - proces zajišťující původních příčin incidentů. Iniciuje zajištění oprav chyb v infrastruktuře a aplikacích. Řízení release - proces zajišťující úspěšnou distribuci a nasazení změn do infrastruktury a aplikací. Plán implementace změněné/nové služby do produkčního prostředí. Obsahuje detailní harmonogram aktivit a odpovědnosti za jejich provedení včetně plánu na vrácení konfigurační položky/služby do stavu před započetím implementace (back-out plan) Kontaktní místo pro příjem požadavků a incidentů. Zajišťuje průběžnou informovanost uživatelů o stavu vyřizování jimi nahlášených incidentů a servisních požadavků, informuje o plánovaných odstávkách systémů, o změnách. Psaná dohoda mezi zákazníkem (= odběratelem IT služeb) a poskytovatelem IT služeb o tom, jaké služby a v jaké úrovni kvality budou poskytovány; obsahuje kvantitativní metriky, podle nichž je měřena kvalita poskytovaných služeb.

Service Level Management

SLM

Work-around

-

Změna

-

Známá chyba

KE

RTP

Řízení úrovně služeb - zabývá se plánováním, koordinací, navrhováním, uzavíráním, monitorováním a vyhodnocováním smluv o poskytování servisní podpory. Jeho cílem je řídit a zlepšovat kvalitu poskytovaných služeb. Způsob ošetření incidentu - neřeší kořenovou příčinu incidentu. Proces přechodu z jednoho definovaného stavu do druhého - jedná se o změnu jakékoliv konfigurační položky, nebo služby problém, u kterého byla zjištěna základní příčina a bylo nalezeno její ošetření (work-around)

77



7. Příloha 1: Přehled „slepých uliček“ implementace ITSM Název procesu

Problémy, překážky a slepé uličky

Service Desk

1. Naučit zákazníka/uživatele komunikovat s poskytovatelem IT/IT oddělením jen přes Service Desk 2. Optimální nastavení kontrolních mechanizmů pro zákazníka 3. Vysoká fluktuace zaměstnanců (operátorů service desku) 4. Podpůrný nástroj a jeho optimalizace

Incident management

5. Přístup uživatelů přímo do podpůrného nástroje Incident managementu a nastavení jednoznačných pravidel pro objektivní určení priority incidentu (tj. dopadu a naléhavosti). 6. Životní cyklus incidentu – uzavření incidentu až po akceptaci řešení uživatelem

Problem management

7. Nastavení smlouvy se zákazníkem versus očekávání a motivace poskytovatele IT služeb 8. Řízení problem managementu dodavatelů 9. Nastavení vazeb mezi: incident – problem – change management 10. Problem management versus zákazník

Konfigurační management

11. Konfigurační management - silná závislost na change management 12. Návrh CMDB – různé úhly pohledu versus náklady 13. Implementace CMDB – správné načasování

Change

14. Interní versus externí change management

management

15. Frekvence jednání CAB (Change Advisory Board)

Release management

16. Nastavení rozhraní konfiguračního a release managementu

Service Level

17. Priorita incidentu versus SLA

management

18. Řízení požadavků zákazníka prostřednictvím SLA 19. Přístup k IT službám přes webový portál versus nastavení SLA

Availability management

20. Výpočet dostupnosti – rozdíl v dostupnosti IT služby a IT komponent

78

Problematika implementace ITSM Název procesu

Problémy, překážky a slepé uličky

Capacity

21. Řízení kapacit lidských zdrojů

management

22. Sběr kapacitních dat? Neprovádíme.


23. Řízení kapacit – náklady na změny Financial

24. Oceňování služeb

management

25. Interní účtování služeb

IT Service

26. Závislost na Business kontinuity managementu (BCM)

Continuity management

27. Testování Plánu kontinuity

79



8. Příloha 2: Dotazník: Problematika implementace ITSM

80



Problematika implementace ITSM - dotazník Dotazovaný:

Datum:

Tento dotazník byl vypracován výhradně pro účely zpracování diplomové práce na téma „Problematika implementace ITSM“. Získané informace nejsou určeny pro komerční využití. 1. LIDÉ Způsob obsazování klíčových rolí ITSM a využití/řízení jejich kapacit.

Školení (nejen klíčových IT zaměstnanců) – rozsah, specializace, aktualizace, proces nástupu nových zaměstnanců.

Způsob zajištění dlouhodobé podpory managementu.

Poznámky:

81



2. NÁSTROJE Výběrové řízení jediný dodavatel/různí dodavatelé. Problematika integrace nástrojů (data, reporty).

Sdílení dat/řízení přístupů k datům/správa CMDB, K/E DB se zákazníkem (business, externí zákazník).

Struktura CMDB - SW,HW, dokumentace, lidé, lokality, komunikace (+ míra detailu) x služby?

Pravidla pro tvorbu, řízení, sdílení záznamů a reportů.

Poznámky:

82



3. PROCESY Integrace procesů se zákazníkem (PM, ConfigM, CHM, RM, SLM, AM, CM, itSCM, FM).

Problematika implementace Service Desk.

Problematika implementace Configuration management.

Problematika implementace Incident management.

Problematika implementace Problem management.

Problematika implementace Change management.

Problematika implementace Release management.

Problematika implementace Service level management.

83



Problematika implementace Availability management.

Problematika implementace Capacity management.

Problematika implementace Financial management IT services.

Problematika implementace IT services continuity management.

Poznámky:

84

Vysoká škola ekonomická v Praze

Recommend Documents