Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Bakalářská práce

ITIL, COBIT, ISO a jejich využití Aleš Erban

Vedoucí práce: Ing. Pavel Náplava

15. května 2012

Prohlášení Prohlašuji, že jsem tuto práci vytvořil samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některý zákonů (autorský zákon), nemám závažný důvod proti užití tohoto školního díla a k užití uděluji svolení.

V Praze dne 15. května 2012

..................... 5

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Aleš Erban. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Aleš Erban. ITIL, COBIT, ISO a jejich využití: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract The objective of this work is to familiarize the reader with an idea of IT Governance and its link to enterprise strategy, to introduce the most used methodologies and standards, that have been developed in order to support and implement IT Governance in organizations and thereafter to compare these methodologies and standards and to determine, which are better suited for what purpose and context. Concerned are ITIL, CobiT and ISO 20000 methodologies mainly. Afterwards, there is a case study – implementation of processes of ITIL methodology for a firm, that is a provider of IT and telco technologies. It’s objective is to familiarize the reader with process of analyses and design of processes, which are in compliance with chosen methodology and meet needs of the firm simultaneously. Keywords IT Governance, IT strategy, ITIL, CobiT, ISO 20000, case study, process, Service Portfolio Management, Transition Planning and Support

Abstrakt Cílem této práce je seznámit čtenáře s myšlenkou IT Governance a její návazností na podnikovou strategii, představit nejpoužívanější metodiky a standardy, které byly vytvořeny za účelem podpory a implementace IT Governance v organizacích a následně tyto metodiky a standardy porovnat a určit, která se lépe hodí pro jaký účel a kontext. Jedná se zejména o metodiky ITIL, CobiT a ISO 20000. Následně je v práci případová studie – implementace procesů metodiky ITIL pro firmu, která je dodavatelem IT a telco technologií. Jejím cílem je seznámit čtenáře s procesem analýzy a návrhu procesů, které jsou v souladu se zvolenou metodikou a zároveň vyhovují potřebám dané firmy. 7

Klíčová slova IT Governance, IT strategie, ITIL, CobiT, ISO 20000, případová studie, proces, Service Portfolio Management, Transition Planning and Support

8

Obsah Úvod

15

I teoretický úvod do problematiky

17

1 Rozvoj podnikové informatiky a jejího řízení

19

2 Úvod do strategie moderních podniků 21 2.1 Podnik v informační době . . . . . . . . . . . . . . . . . . . . . 21 2.2 Podniková strategie . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Role IT v podnikové strategii . . . . . . . . . . . . . . . . . . . 24 3 IT Governance 3.1 Hlavní úkoly IT Governance: . . . . . 3.2 Stručně k historii IT Governance . . . 3.3 IT Governance v kontextu vrcholového 3.4 důvody pro zavedení IT Governance .

. . . . . . . . . . . . . . . . . . řízení podniků . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

29 30 31 32 33

4 Metodiky a standardy pro podporu IT Governance 37 4.1 ITIL (IT Infrastructure Library) . . . . . . . . . . . . . . . . . 38 4.2 úvod do ISO 20000 . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3 Úvod do CobiT (Control Objectives for Information and related Technology) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4 Srovnání metodik . . . . . . . . . . . . . . . . . . . . . . . . . . 68

II praktická ukázka aplikace vybraného standardu

73

5 Případová studie – implementace metodiky ITIL 5.1 Popis firmy . . . . . . . . . . . . . . . . . . . . . . 5.2 Výběr procesů ITILu . . . . . . . . . . . . . . . . . 5.3 Implementace ITIL procesů . . . . . . . . . . . . . 5.4 Metriky implementace ITIL procesů . . . . . . . . 5.5 Náklady na zavedení ITIL procesů . . . . . . . . .

77 77 80 84 97 106

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9

5.6

Shrnutí průběhu implementace metodiky ITIL

. . . . . . . . . 110

III

113

Závěr

115

Literatura

117

A Seznam použitých zkratek

121

B Obsah přiloženého CD

123

10

Seznam obrázků 2.1

Návaznost strategií . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.1 3.2

pilíře IT Governance [9] . . . . . . . . . . . . . . . . . . . . . . . . PDCA cyklus se vstupy a výstupy [29] . . . . . . . . . . . . . . . .

31 35

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

lidé-nástroje-procesy . . . . . . . . schéma ITIL v2 [14] . . . . . . . . ITIL v2 a organizační úrovně . . . schéma ITIL v3 [35] . . . . . . . . životní cyklus služeb dle ITILu [35] ITIL v3 knihy a procesy [31] . . . Procesní struktura ISO 20000 [29] Vztah ITIL a ISO 20000 [21] . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

40 42 43 46 47 58 62 69

5.1 5.2 5.3 5.4 5.5 5.6

struktura ukázkového dodavatele IT služeb Fáze životního cyklu služby [1] . . . . . . . Procesy v rámci struktury firmy . . . . . . Průběh komunikace na projektu . . . . . . Organizace na projektu . . . . . . . . . . . Project Monitoring . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

79 82 83 93 94 96

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

11

Seznam tabulek 4.1

ITIL vs. CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 5.2 5.3 5.4 5.5 5.6

Náklady na implementaci procesů + SW nástrojů . . . . . Součinnost (náklady na vlastní zdroje zákazníka): . . . . Náklady na školení zaměstnanců - vnitřní náklady . . . . Náklady na školení zaměstnanců - náklady na konzultanta Náklady na údržbu . . . . . . . . . . . . . . . . . . . . . . Celkové náklady . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

70 107 107 108 108 109 109

13

Úvod Tato bakalářská práce se zaměřuje na řízení podnikové informatiky, tedy podnikových informačních systémů a informačních a komunikačních technologií (dále IT), a standardů v této oblasti. Zadání práce zní takto: Definujte pojem IT Governance, nastudujte a porovnejte podpůrné normy a standardy pro její podporu. Např. ITIL, Cobit, ISO atd. Aplikujte vybraný standard pro IT Governance na příkladu externího dodavatele ICT služeb telekomunikačním operátorům. Na konzultacích se zástupci dodavatele vytipujte vhodné procesy a pro ně proveďte detailní analýzu a návrh nasazení, včetně vyčíslení přínosů a nákladů. Práci jsem rozdělil na dvě části – teoretický úvod do problematiky a praktickou ukázku aplikace vybraného standardu. Než jsem mohl aplikovat daný standard, bylo nutné nastudovat mnoho zdrojů a seznámit se s kontextem, který v tomto případě znamená seznámit se nejen se zásadami řízení IT v podnicích, myšlenkami IT Governance a podpůrnými metodikami, ale i s teorií strategického řízení podniků. Bez znalosti tohoto rozsáhlého kontextu není možné správně uvažovat a vypracovat práci na toto téma. Mojí motivací vypracovat práci právě na toto téma bylo navíc naučit se pracovat nejenom deterministicky, tj. vypracovat studii pouze na základě určitých faktů, ale naučit se i umět přemýšlet v širším kontextu, tj. vzít do úvah i právě onu strategickou stránku věci. Proto je práce a zejména její teoretická část poměrně rozsáhlá. První, úvodní kapitola uvede čtenáře do problematiky podnikové informatiky a jejího řízení z historického hlediska. Důvod proč jsem tuto kapitolu do práce zařadil je, aby si čtenář uvědomil, o jak mladý obor se jedná, a proč zde před nějakými třiceti lety nic podobného nebylo. Cílem druhé kapitoly této práce je uvést čtenáře do problematiky strategického řízení podniků obecně. Cílem třetí kapitoly je seznámit čtenáře s myšlenkami IT Governance a její návazností na podnikovou strategii. Cílem čtvrté kapitoly je představit nejpoužívanější metodiky a standardy, které byly vytvořeny za účelem podpory a implementace IT Governance v organizacích a následně tyto metodiky a standardy porovnat a určit, která se lépe hodí pro jaký účel a kontext. Jedná se zejména o metodiky ITIL, CobiT a ISO 20000. 15

Úvod Cílem páté kapitoly je vypracování případová studie – implementace procesů metodiky ITIL pro firmu, která je dodavatelem IT a telco technologií. Tato kapitola má seznámit čtenáře s procesem analýzy a návrhu procesů, které jsou v souladu se zvolenou metodikou a zároveň vyhovují potřebám dané firmy. V kapitole nejdříve popíši ukázkovou firmu, pro kterou jsem případovou studii vypracoval, poté vysvětlím a popíši jaké procesy jsem pro implementaci vybral a proč, následně definuji a navrhnu vybrané procesy a na závěr určím metriky a vyčíslím náklady, které implementace vybraných procesů představuje. V práci používám původní anglické termíny (zejména u názvů procesů), protože jsou podle mého názoru srozumitelnější a jednoznačnější. Navíc se jedná o ustálenou terminologii, která se již běžně používá. Český překlad by v mnoha případech pouze komplikoval komunikaci.

16

Část I

teoretický úvod do problematiky

17

KAPITOLA

Rozvoj podnikové informatiky a jejího řízení V této kapitole si řekneme jak se vyvíjela podniková informatika v průběhu minulých padesáti let (dříve se o něčem podobném ani nemluvilo) a proč se stává její řízení samostatným oborem, který stále nabírá na důležitosti. Řízení podnikové informatiky nabývá v současné době stále většího významu s tím, jak se informační a komunikační technologie stávají integrální součástí všech obchodních, výrobních, finančních a dalších procesů podniku. Z hlediska historického se jedná o poměrně mladý obor: (použitá literatura [4]) Okolo 70. let minulého století organizace využívaly počítače na podporu činností, které se daly snadno automatizovat, například výpočet mezd nebo evidence skladových zásob. Vznikly tak první aplikace, které byly izolované, tedy navzájem nepropojené. Data byla součástí programu (jeho kódu), a tak každá změna struktury těchto dat znamenala nutnost opakování překladu programu. Tím narůstaly náklady jak na vývoj, tak na údržbu programů. V organizaci byl nějaký programátor-analytik, který zajišťoval jak zpracování požadavků na aplikaci a její vývoj, tak i vlastní zpracování programu na počítači. Nebyl tedy oddělen vývoj a provoz aplikací. Koncem 70. let a počátkem let 80. minulého století se oblast podnikového IT zaměřila na vzájemné propojení aplikací pro jednotlivé podnikové útvary, např. finanční útvar a podobně. Cílem bylo, aby si aplikace dokázaly předávat data. Například aplikace pro výpočet mezd musela být schopna využít informací z aplikace pro sledování přítomnosti zaměstnanců. V podnicích, které využívaly aplikace ve větším rozsahu došlo k oddělení vývoje a provozu aplikací. Další posun byl na počátku 90. let. Oblast podnikového IT se zaměřila na komplexní a integrovanou podporu činností organizace. Začaly vznikat ERP 19

1

1. Rozvoj podnikové informatiky a jejího řízení (Enterprise Resource Planning) systémy a další aplikační systémy, které na ně mohly navazovat. Vznikali specializovaní výrobci takzvaného typového aplikačního software (TASW), což je software vytvořený univerzálně pro co nejvíce zákazníků – není tedy vytvářen na míru konkrétnímu zákazníkovi. Vznikaly také firmy, které TASW instalovaly u zákazníků a přizpůsobovaly jej nárokům a specifickým podmínkám daného podniku. S nasazováním ERP systémů organizace přecházely z funkčně orientovaného řízení na procesně orientované řízení. Zatímco dodavatelé TASW se zabývali tím, jak navrhnout funkcionalitu a architekturu ERP, jak jej implementovat v daných podnicích a jak jej integrovat s dalšími aplikacemi, podniky řešily, jak definovat a optimalizovat procesy, jak je podpořit pomocí aplikačního softwaru, jak efektivně provozovat a udržovat IT, či jak vyhodnocovat a řídit návratnost finančních prostředků vložených do vývoje a provozu informačního systému. Poslední etapa, jenž započala po přelomu tisíciletí, se vyznačuje překročením hranice podniku ve využívání IT. Vznikly nové typy aplikací jako EDI, CRM nebo SCM, které podporují vzájemnou komunikaci a spolupráci podniků mezi sebou, podniků a zákazníků, či podniků a státní správy (podpora řešení sociálního a zdravotního pojištění, daní, cla atd.). Hlavními problémy této etapy je zejména, jak umožnit propojení a vzájemnou komunikaci informačních systémů několika podniků, jak při tom ale zajistit dostatečnou bezpečnost a spolehlivost těchto IS, jak podpořit kvalitu a včasnost vzájemných dodávek business aplikacemi. IT se stává již velmi komplexní a strategicky kritickou záležitostí v rámci podniků. Zatímco v nějakých 70. letech se o řízení IT vůbec nemluvilo, dnes tato problematika svojí významností převyšuje původně základní a nejvýznamnější činnosti – analýzu, návrh a programování. Dá se říci, že spousty organizací je na svém IT existenčně závislá (banky, pojišťovny, telekomunikační společnosti,..). V takovém podniku nemůže být řízení IT náhodné a živelné. Jako metodická podpora budování systému řízení IT bylo postupně vyvíjeno velké množství metodik, např. ITIL, CobiT, ISO20000 a další.

20

KAPITOLA

Úvod do strategie moderních podniků 2.1

Podnik v informační době

(použitá literatura: [22]) V informační společnosti a globalizující ekonomice se vytvářejí nové vztahy mezi podniky. Díky rozvoji v oboru informačních a komunikačních technologií a informačních systémů výrazně zesílili vztahy mezi podniky a jejich dodavateli, partnery a zejména pak jejich zákazníky. Manažeři podniků musí zajistit koordinaci celé partnerské sítě, která musí dodat sjednané produkty a služby tak, jakoby se jednalo o jeden podnik, navíc v odpovídajícím objemu, kvalitě a v dohodnutém termínu. Takovéto síťové prostředí umožňuje efektivněji a rychleji potřebné informace sdílet a vytvářet znalostně orientované konkurenční výhody. Zaměstnanci podniku pracují díky IT mnohem efektivněji a rychleji a to i přes rostoucí objemy dat se kterými musí pracovat. Velmi se snížily režijní náklady na transakce mezi podniky, zejména díky elektronické výměně dat a dokumentů. Do hodnoty podniku se, mimo jiné, promítá to, jestli a jak dobře má navrženy a popsány procesy a jakým způsobem se podnikové procesy realizují a zlepšují. Podniky musí být schopny operovat ve složitějším prostředí a kromě krátkodobých efektů (typických pro 90. léta) musí být podniky zaměřeny i na dlouhodobé efekty a na schopnost přizpůsobit se. Řízení podniků se postupem času přesunulo od výrobní strategie k prodejní strategii a v poslední době se velice orientuje na finanční ukazatele se sílícím důrazem na přidanou hodnotu, zisk a návratnost investovaných prostředků, zejména kapitálu. Jde zejména o ukazatele jako NPV (Net Present Value), EVA (Economic Value Added) a, pro oblast IT služeb nejdůležitější, ROI (Return on Investment). Roste důležitost pozice manažera informatiky (CIO), který je stale více sou21

2

2. Úvod do strategie moderních podniků částí nejužšího managementu firem. Pokud se manažer informatiky neúčastní jednání, na kterých jsou vrcholovým vedením podniku přijímána strategická rozhodnutí, je více než pravděpodobné, že nebude dosaženo dostatečného zajištění optimálního souladu mezi rozvojem podniku a rozvojem jeho IT. Současný management podniků směřuje k: • dosažení výhody na trhu a orientaci na zákazníky • využívání informací jako jeden z nejcennějších zdrojů, které podnik vlastní • orientaci na procesy v podniku, na jejich racionalizaci a eliminaci těch, které nepřinášejí hodnoty • schopnost podniku adekvátně reagovat na měnící se vnější podmínky Aby podnik dokázal v informační době těchto bodů dosáhnout, musí patřičně a efektivně využívat služeb a nástrojů, které mu nabízí podniková informatika. Podniková informatika svou bohatě rozvinutou aplikační a technologickou infrastrukturou nabízí nové možnosti pro rozvoj vazeb podniku s jeho okolím, s externími partnery, jako jsou aplikace pro řízení vztahů se zákazníky - CRM, aplikace elektronického podnikání, řízení dodavatelských řetězců SCM a další. Celý tento potenciál mění průběh mezipodnikových kooperací a vytváří i novou podporu pro přístup k řízení vůbec - manažerské aplikace, datové sklady, dolování dat aj. Vytváří tak nové prostředí pro analytické a rozhodovací aktivity managementu a mění jejich procedury. Dále rozhodujícím způsobem ovlivňuje úroveň klíčových charakteristik podniku - flexibilitu výkonu, bezpečnost dat, dobu odezvy, možnost sledování důležitých požadavků ve firmě on-line. Podniky se v nastávajícím informačním věku stávají závislými na kvalitním řízení podnikové informatiky a musí proto ve své strategii tomuto faktu věnovat patřičnou pozornost.

2.2

Podniková strategie

(použitá literatura: [33]) Každá firma, společnost, či jiná organizace byla založena za jistým účelem. Zakladatel firmy měl nějakou vizi a posláním této firmy je tuto vizi naplnit. Důležité je, aby firma věděla nejen kde se na své cestě nachází, kam chce jít, ale také, jak se k cíli dostat a co pro to musí udělat. Zároveň je třeba sledovat konkurenci, vývoj trhu a celkový vývoj prostředí kolem firmy. Správně zvolené strategické cíle a cesty k jejich naplnění vycházející ze současné situace a možností firmy jsou předmětem strategického managementu. Po konci 2. světové války nebyl trh přesycen a jeho vývoj probíhal pomaleji a firmám stačilo pouze operativní řízení. Dnes se však firmy nacházejí v 22

2.2. Podniková strategie prostředí, které se neustále mění, což přestavuje hrozby, ale i potencionální příležitosti k získání komparativní výhody v hospodářské soutěži. A právě získání komparativní výhody je podstatou strategického řízení. Jde o dlouhodobé a koncepční řízení, které se týká prací a rozhodnutí, které patří z hlediska firmy k nejdůležitějším. Strategické řízení se uskutečňuje prostřednictvím tvorby a realizace dílčích strategických rozhodnutí. Ty mohou mít formu záměru určujícího vývoj firmy, nebo formu metod, nástrojů a opatření, jejichž prostřednictvím je určen chod firmy. Tvorba a formulace strategie Na základě výsledků strategické situační analýzy management firmy ví, jaké jsou kritické faktory úspěchu v daném odvětví, zná specifické přednosti vlastního podniku a také má potřebné informace o konkurenci. Nyní se tedy může pustit do formulace a tvorby strategie. Výsledky strategické situační analýzy se projeví v určení podnikové vize, v rámci které management vymezuje směřování podniku a jeho pozice v budoucnosti. Vize je základem pro určení strategických cílů podniku, což jsou budoucí stavy, kterých chce vrcholový management dosáhnout. Cíle by měly odpovídat SMART definici, což znamená, že musí stimulovat k dosažení co nejlepších výsledků (Stimulating), jejich dosažení musí být měřitelné (Measurable), musí být přijatelné pro ty, kdo je budou plnit (Acceptable), musí být reálné a dosažitelné (Realistic) a musí být vymezené časově (Timed). Cíle musí být samozřejmě jasně specifikovány, aby nedocházelo k případným nedorozuměním. při tvorbě strategie se doporučuje tento postup: 1. Stanovení cíle a vymezení jeho kritérií. 2. Analýza firmy, jejích objektivních vlastností a možností. Poznání silných a slabých stránek firmy a způsobů jejich ovlivňování. 3. Analýza okolí firmy (vývoj oboru, trhu a makroprostředí). Vyvození rizik a příležitostí, které z analýzy okolí pro firmu plynou. 4. Tvorba strategie s využitím poznaných vlastností firmy a jejího okolí. Vymezení metod a nástrojů k dosahování dlouhodobých cílů firmy. 5. Rozpracování strategie do taktiky firmy. 6. Prognóza vývoje. 7. Implementace strategie, kontrola jejího uplatňování a její korekce dle průběhu. [18] 23

2. Úvod do strategie moderních podniků

2.3

Role IT v podnikové strategii

Moderní management přikládá firemním informacím a jejich řízení velký význam. Jde o to aby řízení IT bylo nedílnou součástí celkového řízení firmy a plnilo správně a efektivně své poslání a úkoly. Při správném řízení a využívání může IT představovat strategickou zbraň, prostředek pro získávání strategických informací z oblasti vývoje nových výrobků a služeb, nových trhů, způsobů organizace a řízení, komunikace a vytváření distribučních kanálů se zákazníky a dodavateli, prostředek zvyšování produktivity, efektivnosti, kvality, flexibility výroby a služeb. Vzhledem ke globalizaci a zvyšující se dynamice trhů, zkracování inovačních cyklů, zvyšování intenzity konkurenčního boje, dynamiky a komplexnosti vnitropodnikových procesů a rozhodování je IT zcela nezbytné. Stále více rozhoduje o podnikatelském úspěchu a stává se jeho kritickým faktorem. [17] Informatika již není klasickou službou v pojetí minulých výpočetních středisek, či správců sítí. V dnešní době jde o takové funkce informatiky, které jsou integrální součástí strategických, řídících, obchodních, provozních a dalších procesů ve firmě. Integrace informačních technologií do systému řízení se stále více prohlubuje, a to již při řízení procesů ve firmě, při řízení projektů, řízení dokumentů, řízení výroby, atd. Řízení informatiky tak musí být nedílnou součástí řízení firmy a názory, že informatici nemají mluvit do podnikového řízení, dnes již můžeme chápat jako představy minulého století. [22] Strategie budování IT musí být sladěna se strategickými cíli firmy. Nelze ji vytvářet izolovaně. Musí vycházet ze znalosti a pochopení potřeb všech oblastí řízení firmy, musí respektovat postavení firmy, včetně informačních a kooperačních vztahů firmy s externími partnery a způsobů jejich realizace. Musí respektovat i stav personálních zdrojů a jejich kvalifikační úroveň. [22] Se stále většími nároky na řízení informatiky ve firmě a nutností jejich sladění se strategií a systémem řízení firmy se stává stále více nezbytné, aby IT management opustil platformu středního managementu a naopak, aby se zapojil do vrcholového vedení firmy. V informatice již nelze akceptovat zahleděnost jen do rozvoje technologií. Informatici musí dobře znát firemní procesy a musí spolupracovat na strategických záměrech systému řízení firmy, na inovaci firemních procesů a jejich začlenění do informačního systému firmy, na řízení projektů ve firmě, při restrukturalizaci firmy, na budování systému jakosti ve firmě, musí podporovat oběh dokumentů ve firmě (a jsme zpět u nutnosti znalosti firemních procesů). [22] Problém, před kterým stojí dnešní IT manažeři je, že i přes zvyšování výkonů a snižování jednotkových nákladů na IT, zejména hardware, jsou náklady na IT velmi vysoké, což vede k obtížnému hájení investovaných prostředků. Kvůli rychlému technologickému pokroku se stále více odhalují tradiční slabiny managementu ve vztahu k využívání IT, mezi něž především patří: • Používání IT nevhodným způsobem, absence dlouhodobých přístupů k 24

2.3. Role IT v podnikové strategii rozhodování o rozvoji dané oblasti v celkovém kontextu strategického řízení.

• Chybějící zájem a podpora top-managementu v průběhu realizace projektů v dané oblasti, problémy v komunikaci se specialisty.

• Neujasněný způsob řízení IT, kdy je při svém rozhodování management veden snahou ušetřit. Preferuje například zavedení především ekonomické části ERP systému bez ohledu na dosažení plánovaného ekonomického přínosu nebo inovaci podnikových procesů. Nikdo není zodpovědný za vazbu na podnikové cíle a strategii.

• Malá angažovanost přímých uživatelů, nevyužívání příležitostí/možností.

• Malá pozornost faktorům z oblasti "lidského chování".

[17] V důsledku toho roste zodpovědnost manažerů za využívání IT jako příležitosti pro konkurenční výhodu a za eliminaci hrozeb a rizik s využíváním IT spojených. IT musí být efektivně řízeno na všech úrovních - strategické, taktické i operativní. Někteří odborníci odhadují, že rozhodování uskutečňovaná na strategické úrovni řízení ovlivňují úspěšnost podnikání až z 80%. Toto číslo je však velmi diskutabilní, neboť samozřejmě záleží na tom, o jaké podnikání se jedná, v jakém prostředí a v jaké situaci je uskutečňováno. Platí však, že strategické řízení ovlivňuje úspěšnost firmy často více, ať už v negativním, či v pozitivním smyslu, než taktické a operativní řízení. A to platí i pro oblast IT. Proto by strategickému řízení IT, jehož nejdůležitějším úkolem je formulace a realizace IT strategie, měla být věnována náležitá pozornost. [17] Strategie je obecně chápána jako množina strategických cílů a způsobů jejich realizace. Při postupném přenosu strategických cílů do nižších úrovní je uplatňován princip MBO (Management by Objectives), což znamená, že každá úroveň strategického řízení musí při formulaci svých strategických cílů vycházet ze strategických cílů nadřazené vrstvy strategického řízení a snažit se maximálně přispět k jejich naplnění. Strategie IT je zde zařazena do nejnižší (nikoliv podle významu a důležitosti!!) úrovně, tzv. funkčního strategického řízení, což znamená , že navazuje na nadřazenou business strategii (viz následující obrázek). [16] 25

2. Úvod do strategie moderních podniků

Obrázek 2.1: Návaznost strategií Při rozhodování o budoucích IT technologiích by měly dostávat nejvyšší prioritu ty technologie, které nejvíce přispějí k naplnění strategických cílů vytyčených v business strategii, posílí konkurenční pozici firmy, upevní její postavení vůči konkurentům, dodavatelům i zákazníkům a eliminují hrozby, které by se přitom mohly naplnit. IT strategie se nicméně liší od ostatních funkčních strategií tím, že musí podporovat jak nadřazenou obchodní strategii, tak i ostatní funkční strategie a měla by s nimi být provázána tak, aby oblast IT maximálně podporovala naplnění strategických cílů souvisejících funkčních strategií. V návrhu IT strategie by měly být zformulovány strategické cíle a vytyčeny cesty jejich realizace pro následující aspekty: • rozvojové záměry a cíle oblasti IT • koncepce a filozofie IT • finance • materiál • lidské zdroje • systém řízení rozvoje • organizace a řízení informačních procesů • řízení jakosti IT • bezpečnost a ochrana v IT • strategické návaznosti 26

2.3. Role IT v podnikové strategii [17] Během vývoje podnikové informatiky se neustálé hledají efektivní postupy a nástroje řízení rozvoje a provozu IT. Od prvního desetiletí tohoto tisíciletí se pozornost věnuje zejména řízení rozvoje a provozu komplexního a integrovaného informačního systému podniku, životnímu cyklu IT služeb, řízení outsourcingu a systematickému řízení IT procesů. Začalo se mluvit o metodách IT Governance. [5]

27

KAPITOLA

IT Governance IT Governance je disciplína, která se zabývá strategickým řízením IT v rámci organizace. Předmětem jejího zájmu je strategické, taktické a v konečném důsledku i operativní řízení služeb IT. IT Governance pomáhá sladit IT a business strategii a pomáhá transformovat business strategii a její cíle do konkrétních strategických cílů a plánů IT. Jde o systém pro řízení, kontrolu a monitoring IT, který pomáhá realizovat hodnotu IT a řídit IT rizika. Disciplína IT Governance se zaměřuje zejména na tato témata: • jak řídit vztah podnikové informatiky a byznysu • na jakých principech má být řízení podnikové informatiky postaveno • jaká je vhodná organizační struktura IT oddělení/útvaru • jak řídit IT služby, IT procesy a IT zdroje • jak řídit IT po ekonomické stránce • jak zainteresovat interní uživatele a IT dodavatele na efektivnosti IT • jak řídit rizika související s rozvojem a provozem IT • kdo má v podniku rozhodovat o prioritách rozvoje IT, IT architektuře a standardech • jak IT služby a zdroje sourcovat 29

3

3. IT Governance

3.1

Hlavní úkoly IT Governance:

• Sladit a synchronizovat strategie v rámci podniku: Jde zejména o to, aby byly investice do IT v souladu s podnikovou strategií a s podnikovými cíli.

• Generovat hodnoty pro business: IT musí vytvářet pro business přidanou hodnotu a to realizací slíbených přínosů k dané strategii podniku s důrazem na optimalizaci nákladů a vytváření hodnot, které může odvětví IT poskytnout.

• Řídit IT zdroje: Je potřeba řídit investice do IT a řídit kritické IT zdroje, jako jsou aplikace, informace, infrastruktura a lidské zdroje.

• Řídit rizika: Abychom mohli měřit, řídit a případně akceptovat rizika, stejně tak jako reportovat rizika v oblasti IT, musíme pro to zavést nějaký závazný rámec.

• Měřit výkonnost IT: Jde o sledování implementace IT projektů, o kontrolu využívaní zdrojů, IT procesů a dodávky IT služeb. Velmi častou metodou je IT Balanced Scorecard, pomocí které lze sledovat, ve kterých oblastech a jakým způsobem IT přispívá k plnění business cílů. Tato metoda kombinuje kvalitativní i kvantitativní ukazatele měření výkonnosti.1

[9]

1

30

Poznámka: IT Balanced Scorecard je v v jiném pojetí uveden v ITILu [23].

3.2. Stručně k historii IT Governance

Obrázek 3.1: pilíře IT Governance [9]

3.2

Stručně k historii IT Governance

(použitá literatura: [10]) Významnými milníky pro rozvoj disciplíny IT Governance jsou dokumenty Sarbanes Oxley a Basel II (druhá Basilejská smlouva). Zákon Sarbanes-Oxley (SOX) je od roku 2002 jedním z nejvlivnějších a nejkontroverznějších zákonů upravujících firemní prostředí v novodobé americké historii - zabývá se transparentností a přesností účetnictví a finančních výkazů, zpřísněním interních kontrolních systémů a odhalením a přísným postihem hospodářské kriminality. Americký Kongres zákon vytvořil jako reakci na pád společností Enron a WorldCom, za účelem vytvoření prostředí, ve kterém se finanční problémy firmy odhalí ještě v jejich zárodku, tedy dříve než se vyvinou ve velké skandalizující podvody, které pak nepříznivě ovlivňují rozsáhlejší ekonomické prostředí. Cílem bylo zvýšit důvěru investorů v publikované výsledky firem obchodovaných na americké burze. Tento dokument (zvláště část 404) se také týká operativních procesů souvisejících s řízením IT (např. na úrovni change managementu). Basel II je norma, kde jsou doporučení pro bankovní právo a regulace Basilejské komise pro bankovní dohled. Norma má značné dopady na řízení informatiky bank a na jejich informační systémy. Tato norma se týká pouze řízení informatiky finančních institucí. Podněty pro zpracování norem pro taktické a strategické řízení IT přišli až s událostmi v Austrálii v roce 2000, kde se podobně jako v Americe zhroutilo několik významných firem. V roce 2005 australská vláda zveřejnila normu AS8015 (Australian Standard for Corporate Governance of IT). Tato norma se jako první zabývala pravidly v oblasti řízení a správy IT jakožto strategicky 31

3. IT Governance významného aspektu celého podnikání. Krátce na to následoval vznik dalších norem pro IT Governance, jako například již zmiňovaný CobiT. Rostoucí význam informací, znalostí, ale i dalších nehmotných aktiv společností (např. lidský kapitál, obchodní značka) způsobil, že význam IT a IT Governance výrazně rostl, neboť mnoho z těchto aktiv je úzce spojeno právě s fungováním IT firmy. Vedení firmy, akcionáři, investoři, vlastníci i společnost samotná se začali v důsledku tohoto vývoje o oblast IT zajímat. Rostoucí vliv nehmotných aktiv samozřejmě vyvolává potřeby tato aktiva řídit a kontrolovat. Například pro oblast finančních aktiv organizace existují systémy kontrol a kontrolních mechanizmů, díky kterým je možné zjistit, v jaké finanční situaci se organizace nachází. Otázkou je, zdali je něco takového možné i v oblasti nehmotných aktiv a s nimi související IT oblastí. A právě IT Governance se snaží na tuto otázku odpovědět a nabídnout případné řešení.

3.3

IT Governance v kontextu vrcholového řízení podniků

Ačkoli jednotlivé aktivity IT Governance procházejí napříč všemi úrovněmi managementu, IT Governance je zodpovědností výkonného managementu společnosti. Vzhledem k důležitosti IT ve společnosti a specifickému charakteru tohoto odvětví je nutná velmi těsná spolupráce mezi vedením společnosti a oddělením IT, respektive poskytovatelem IT řešení a služeb. Strategie podniku, za kterou je zodpovědné vedení společnosti, by měla správně nastavit způsob spolupráce businessu a IT. Základem úspěchu a efektivní kooperace mezi stranou businessu a IT jsou tato základní pravidla: • vedení podniku by se mělo aktivně účastnit jednání o IT strategii podniku • Ředitel společnosti (CEO) by měl umožnit implementaci IT strategie podporováním provedení potřebných změn • Ředitel IT (CIO) ve společnosti musí být orientovaný i na business a nejen na IT, aby byl schopen zprostředkovat propojení a komunikaci mezi IT a businessem [19] CEO společnosti by měl propojit strategii podniku s IT strategií tak, aby byli navzájem kompatibilní. Měl by také zařídit, aby o těchto strategiích byli informováni manažeři na všech úrovních řízení organizace. Úkolem CEO je také definovat a podporovat roli CIO. 32

3.4. důvody pro zavedení IT Governance Hlavním úkolem CIO je přesvědčit výkonné vedení společnosti o významu a přínosu IT pro společnost a o nákladech spojených s poskytováním jednotlivých služeb. CIO seznamuje vedení s možnostmi IT, ale i jeho omezeními a s riziky s IT spojenými. Zaručuje, aby hodnota IT pro organizaci byla maximální. Výkonné vedení by mělo rozumět možnostem IT v rámci společnosti. Vždyť řídí a definuje požadavky businessu na IT, tedy vystupuje v roli zákazníka IT, a alokuje zdroje společnosti potřebné pro zajištění efektivní IT Governance. Je důležité jasně a jednoznačně definovat jednotlivé role a jejich zodpovědnosti v rámci IT managementu. To rovněž patří mezi základní úkoly vedení a vrcholového managementu společnosti. Je také důležité, aby tyto role byli srozumitelné pro všechny členy organizace.

3.4

důvody pro zavedení IT Governance

(použitá literatura: [11]) • IT je významným kritickým faktorem úspěchu pro dosažení podnikové strategie • IT je prvek, který umožňuje růst a vývoj podniku • IT musí splňovat stále rostoucí nároky v oblasti regulací, povinné správy a ochrany IT aktiv V posledních letech došlo k výraznému nárůstu regulací souvisejících s informacemi a informačními a komunikačními technologiemi. Zvýšily se např. nároky na způsob a dobu uchování dat, způsob zpracování a zacházení s důvěrnými a osobními daty, vzrostly i požadavky na vnitropodnikové kontroly a řízení podnikových rizik. ( Např. Zákon č. 101/2000 Sb., o ochraně osobních údajů, Zákon 227/2000 Sb., o elektronickém podpisu, Zákon 365/2000 Sb., o informačních systémech veřejné správy, ISO/IEC 17799: 2005, Soubor postupů pro řízení bezpečnosti informací, SOX, Basel II a další) Velké množství organizací se zabývá plánováním a implementací krizové strategie, neboť mnoho podniků zbankrotuje do jednoho roku po vážném a rozsáhlém výpadku IT systémů. S větší závislostí podniku na IT se toto riziko zvyšuje a tyto podniky se musí důkladněji zabývat krizovým řízením IT služeb. Nejnovějším trendem v řízení IT projektů a IT služeb je zavedení specifického strategického plánování a organizování investic do IT služeb tak, aby implementace a provoz těchto služeb byl nákladově efektivní a vedl k naplnění očekávání a potřeb businessu. Investice provedené do IT služeb musí přinášet businessu požadovanou přidanou hodnotu v podobě podpory business procesů a umožňovat tak dosažení business cílů. Nejlépe management podniku splní všechny uvedené požadavky právě implementací principů a myšlenek IT Governance. Jak toho docílí? Jak již bylo 33

3. IT Governance řečeno, na IT Governance se zaměřuje celá řada metodik a standardů. Tyto metodiky a standardy pomáhají prosadit myšlenku IT Governance v praxi. Některé standardy se soustřeďují na dílčí cíle IT Governance, jiné na IT Governance v celém svém rozsahu, a některé jej svým záběrem převyšují. Každá metodika, či standard obsahuje jednak množinu procesů, které je třeba implementovat, aby bylo dosaženo daného cíle, a jednak systém neustálého zlepšování. IT Governance je totiž nepřetržitý a stále se opakující proces. Většinou se využívá tzv. Demingova cyklu – PDCA (Plan-Do-Check-Act). Jedná se o metodu postupného zlepšování služeb, procesů, ale také dat, aplikací, či dalších produktů, probíhající formou opakovaného provádění čtyř základních činností:

Plan (plánuj) - P: cyklus začíná získáváním informací a popisem řešeného problému, které slouží pro připravení plánu. Plán by měl obsahovat jednotlivé činnosti, které je třeba udělat k odstranění problému.

Do (dělej) – D: po vypracování plánu je dalším krokem zavedení popsaných činností.

Check (kontroluj) – C: následuje sledování dosažených výsledků a jejich porovnání s plánem. Jedná se tedy o kontrolu, zda je původní problém skutečně řešen.

Act (jednej) – A: dojde-li k situaci, že se výsledek liší od očekávání a problém není vyřešen, hledá se příčina problému. Poté se příčina odstraní. Je-li také problém úspěšně odstraněn, je třeba všechny potřebné změny zavést do procesů nebo systému a následně se přesvědčit, zda jsou změny řádně uplatňovány.

[28] PDCA cyklus a jeho obvyklé vstupy a výstupy ukazuje následující obrázek. 34

3.4. důvody pro zavedení IT Governance

Obrázek 3.2: PDCA cyklus se vstupy a výstupy [29]

35

KAPITOLA

Metodiky a standardy pro podporu IT Governance Standardů a metodik pro řízení služeb podnikové informatiky jsou spousty. Mezi známější patří například: ISO 38500:2008 , která se zaměřuje na řízení IT z pohledu direktorů firem (majitelé, ředitelé, akcionáři,..). [8] ISO 27001:2006 , která se zabývá řízením rizik a bezpečnosti informací. [6] Val IT , která se zaměřuje na hodnocení investic do IT. [5] ISO 9001:2009 , která se zabývá managementem kvality (jakosti). Je to příklad standardu, který jde svým obsahem za hranice IT Governance, neboť jej může využít jak servisní, tak i výrobní, obchodní, či poradenská společnost, ale i o instituce veřejné správy, zdravotnická zařízení, vzdělávací instituce a mnoho dalších. [7] Celosvětově nerozšířenější jsou zejména metodiky a praktiky ITIL, CobiT a také ISO/IEC 20000, na které se podíváme a následně porovnáme. Nejprve bych se však chtěl pro zajímavost zmínit ještě o metodice, která je vyvíjena v české republice od počátku 90. let. Jde o metodiku MMDIS (Multidimensional Management and Development of Information System). Tato metodika je zaměřena na vývoj, údržbu a provoz komplexního a integrovaného informačního systému podniku tak, aby optimálně využíval potenciálu dostupných informačních technologií a informatických služeb k podpoře podnikových cílů. Základním principem této metodiky při návrhu informačního systému je zohlednění všech faktorů (MMDIS je nazývá dimenzemi), které ovlivňují návrh, zavedení, používání i dalšího rozvoje IT. Je to tedy metodika globálního pohledu na informační systém při jeho vývoji. Tato metodika se 37

4

4. Metodiky a standardy pro podporu IT Governance dá použít jak pro vývoj IS „na zelené louce“, tak i pro rozvoj již existujících systémů. Metodika MMDIS je založena na jedenácti principech a šesti propojených konceptuálních modelech. [4] Nyní se již pojďme podívat na tři nejznámější a nejpoužívanější standardy a rámce pro řízení podnikové informatiky – ITIL, CobiT a ISO 20000. Začnu ITILem, na který se podíváme poměrně detailně, aby měl čtenář lepší představu, co taková metodika IT Governance je. Podíváme se na jednotlivé procesy, o kterých si řekneme k čemu jsou, co řeší a podobně. Cílem pojednání o jednotlivých procesech ITILu také je, aby čtenář poté v praktické ukázce na konci této práce věděl, které procesy a proč jsem vybral. Praktická ukázka bude totiž zaměřena právě na implementaci právě procesů ITILu. ISO 20000 a CobiT do úrovně jednotlivých procesů rozebírat nebudu, neboť většina procesů jsou i v ITILu, pouze z jiného pohledu. Nakonec si tyto metodiky a standardy srovnáme a řekneme si k čemu je která vhodná.

4.1

ITIL (IT Infrastructure Library)

ITIL je sada publikací a veřejně dostupný, rozsáhlý, konzistentní a procesně orientovaný rámec, který popisuje nejlepší praktiky (best practice) řízení IT služeb. Tento rámec poskytuje praktiky pro zvládnutí IT v organizaci, pojednává komplexně o službách a zaměřuje se na neustálé a pravidelné měření a zlepšování dodávaných IT služeb, a to jak z pohledu IT oddělení, respektive poskytovatele IT řešení, tak z podhledu businessu, tedy vlastního managementu firmy, respektive zákazníka. Právě díky svému zaměření na business i technický personál je ITIL nejúspěšnějším standardem řízení IT služeb, a proto jsem se rozhodl zaměřit tuto práci právě na něj. ITIL je také systém školení a certifikací jednotlivců. Na rozdíl od ISO 20000 lze certifikovat pouze jednotlivce, nikoli tedy organizace. ITIL je vlastněn úřadem ve Spojeném království – OGC (Office of Government Commerce), který byl založen za účelem získání vyšší hodnoty z výdajů ve státní správě. Tento úřad svou činností pomáhá vládním úřadům řídit projekty, nákup a podobně. Vydavatelem ITILu je TSO (The Stationery Office). [4] Podle ITILu je základním principem podpory IT služeb zavedení procesů a jejich prostřednictvím řízení aktivit při podpoře těchto IT služeb. Jakákoli činnost s IT službami a jakýkoliv zásah do provozu IT služeb při poskytování služeb se musí provádět v rámci nějakého z procesů. Je třeba dbát na cíl daného procesu a pečlivě průběh procesu dokumentovat pro účely jeho zlepšování. Každý z procesů musí mít definovaného vlastníka. Tento vlastník je za proces přímo zodpovědný, tedy za jeho definici, jeho zavedení, někdy i za jeho vlastní průběh a v neposlední řadě za měření výkonnostních metrik. [34] Mezi zásady ITILu patří, že implementace IT service managementu musí být celopodnikovým projektem strategického významu. Rozhodnutí o implementaci musí být tedy učiněno nejvyšším vedením organizace, které poté musí 38

4.1. ITIL (IT Infrastructure Library) tento projekt viditelně podporovat. Základní etapy při implementaci ITILu: (použitá literatura: [13])

1. Získání znalostí o ITILu u lidí, kterých se projekt implementace týká:

• manažerů a klíčových zaměstnanců podniku • členů implementačního týmu

2. Zhodnocení současné situace:

• popis současného stavu • identifikace problematických oblastí

3. Plánování a následné dosažení cílového stavu:

• naplánování projektu • uskutečnění implementace

4. Ověření, že cíle bylo skutečně dosaženo

Během projektu implementace je ITILem doporučeno realizovat tzv. "Awareness kampaň", což je v podstatě nástroj, pomocí kterého lze řídit úroveň očekávání všech zainteresovaných osob. Pro úspěch implementace je to velmi důležité, neboť pokud jsou očekávání příliš vysoká, budou všichni výsledkem zklamáni. A to i v případě, že by se mohlo zdát, že projekt skončil relativně dobře. Při realizaci projektu implementace je také důležité udržet v rovnováze trojúhelník "LIDÉ – PROCESY – NÁSTROJE". To znamená, že implementace procesů ITILu není pouze definování samotných procesů, ale i definování klíčových rolí a v neposlední řadě určení a nasazení podpůrných nástrojů (neplatí, že nástroji musí být software, i když ve většině případů to tak je). 39

4. Metodiky a standardy pro podporu IT Governance

Obrázek 4.1: lidé-nástroje-procesy

Je velmi důležité, aby byli lidé podílející se na projektu důkladně vyškoleni a znali nástroje (např. software) a navržené procesy. Procesy musí být zdokumentovány a implementovány (např. pracovní postupy, náplně práce jednotlivých rolí, organizační směrnice atd.).

4.1.1

Historie a vývoj ITILu

(použitá literatura: [4]) ITIL se vyvíjí již desítky let. V osmdesátých letech řešily organizace celého světa problém se závislostí na IT technologiích. Z toho vyplýval růst požadavků na kvalitu IT služeb. Situace byla neudržitelná, a tak britská vláda oslovila úřad CCTA (Central Computer and Telecommunications Agency), aby vypracoval rámec pro řízení IT a efektivní nakládání se zdroji IT v britském vládním sektoru. Úřad měl vytvořit jakousi příručku, podle které by organizace (vládní i soukromé), které se účastní na dodávkách IT služeb pro britskou vládu, musely závazně postupovat. Výsledný rámec se jmenoval Government Information Technology Infrastructure Management (GITIMM) a byl zaměřen na oblast dodávky a podpory služeb IT. V Roce 1989 se jednalo se o čtyřicet šest publikací, které se začaly vydávat pod názvem ITIL. V devadesátých letech vzniklo OGC sloučením tří britských vládních agentur včetně CCTA a stalo se autoritou pro další vývoj a publikování dalších publikací ITILu. V devadesátých letech také vzniklo itSMF (IT Service Management Forum), které se stalo mezinárodní komunitou profesionálů a odborné veřejnosti z oblasti ITSM (IT Service Management) a ITIL. Rámec ITIL se stal velmi úspěšným i v komerčních organizacích ve světě. Začaly se již také vydávat první certifikáty odborné způsobilosti pro oblast ITSM podle ITILu. 40

4.1. ITIL (IT Infrastructure Library) Po přelomu století bylo oněch 46 publikací přepracováno a rozšířeno. Hlavní změnou byla koncentrace do rozsáhlejších a ucelenějších publikací. Vznikl ITIL verze 2, jehož základem jsou knihy Service Support a Service Delivery (tzv. modrá a červená kniha), které obsahují většinu z původních čtyřiceti šesti publikací a v podstatě definují ITSM. V rámci těchto publikací je text členěn podle procesů, které při řízení IT podniku probíhají. ITIL verze 2 se stala velmi rozšířenou prakticky po celém světě, určila obecnou předlohu pro řízení podnikového IT a stala se mezinárodním standardem v oblasti ITSM. V listopadu 2004 zahájilo OGC práce již na třetí aktualizaci knihovny ITIL. V dubnu 2005 vydalo OGC dokument ITIL Refresh, který obsahoval vymezení aktualizovaného rámce včetně jeho klíčových znaků. V srpnu 2005 OGC zveřejnilo podrobnosti o podobě ITIL verze 3. V roce 2007 byl oficiálně vydán ITIL verze 3. Tato verze je ještě konzistentnější než ta druhá. Byly odstraněny vnitřní rozpory verze 2, které vznikly tím, že na různých kapitolách pracovali různí autoři, aniž by se nějak koordinovali. Byla předělána struktura, a to podle životního cyklu IT služeb, nikoli podle IT procesů, jak tomu bylo v předchozích verzích, a několik procesů přibylo.

4.1.2

ITIL verze 2

(použitá literatura: [4], [34]) Je nutno poznamenat, že druhá verze ITILu nebyla tou třetí zcela vytlačena. ITIL verze 2 je v praxi stále dost rozšířen a mnoho organizací jej stále používá a je pro ně dostačující. Proto se o této verzi zmíníme, abychom získali přehled o základních charakteristikách této verze. Jádro druhé verze ITILu tvoří osm publikací. Nejdůležitější jsou Service Delivery a Service Support. Jednotlivé publikace verze 2 se většinou věnují popisu IT procesů a jsou podle IT procesů strukturovány. ITIL verze 2 tvoří tyto publikace: • Service Support • Service Delivery • IT Infrastructure Management • Application Management • The Business Perspective • Planning to Implement Service Management • Security Management • Software Asset Management 41

4. Metodiky a standardy pro podporu IT Governance Následující schéma ukazuje vzájemné vztahy publikací ITILu verze 2 a navíc ukazuje vztah jednotlivých publikací k business procesům a IT infrastruktuře:

Obrázek 4.2: schéma ITIL v2 [14] Každá organizace má tři hlavní úrovně manažerského řízení: • Úroveň operativního (nebo také provozního) řízení Zde jsou procesy každodenního a rutinního provozu. Procesy této úrovně v oblasti IT jsou popsány v knize Service Support. Cílem těchto procesů je každodenní podpora uživatelů IT služeb. • Úroveň taktického řízení Zde jsou procesy střednědobého plánování. Procesy této úrovně v oblasti IT jsou popsány v knize Service Delivery. Cílem těchto procesů je budovat vztahy se zákazníky a snažit se dosáhnout jejich dlouhodobé spokojenosti s poskytováním IT služeb. • Úroveň strategického řízení 42

4.1. ITIL (IT Infrastructure Library) Zde jsou procesy dlouhodobého plánování a plánování hlavních směrů rozvoje organizace. Jedním ze strategických rozhodnutí je, jestli bude organizace implementovat procesy IT service managementu. Následující schéma ukazuje vztah knih Service Support a Service Delivery k výše popsaným úrovním řízení organizace:

Obrázek 4.3: ITIL v2 a organizační úrovně Nyní se podíváme na vybrané publikace druhé verze ITILu a řekneme si k čemu slouží a jaké jsou v ní popsané procesy. 4.1.2.1

Service Support

Tato kniha popisuje tyto operativní procesy: • Service Desk (funkce) • Configuration management • Incident Management • Problem Management • Change Management • Release Management Kniha také popisuje vztahy mezi těmito procesy a procesy z ostatních oblastí. Kniha je také příručkou, jak přistoupit k použití ITILu, jak řídit zavádění procesního řízení IT služeb, a popisuje kulturní aspekty řízení IT, možnosti použití softwaru pro řízení služeb atd. Základní myšlenkou knihy Service Support je oddělení těch činností podpory služeb, které se týkají obnovy narušeného, ale již sjednaného žádoucího stavu (jde zejména o procesy Incident Management a Problem Management) a řešení požadavků na změnu sjednaného stavu nebo jeho úpravy (zejména proces Change Management). 43

4. Metodiky a standardy pro podporu IT Governance 4.1.2.2

Service Delivery

Tato kniha popisuje tyto taktické procesy: • Service Level Management • Capacity Management • Availability Management • IT Service Continuity Management • Finantial Management for IT Services Nyní se podíváme ve stručnosti na ostatní publikace ITILu Verze 2: 4.1.2.3

IT Infrastructure Management

V této knize ITIL poskytuje doporučení, jak řídit životní cyklus služeb IT infrastruktury od identifikace požadavků, přes design a plánování služby, nasazení, instalaci a testování, až po provozování a následnou údržbu služby. Tento cyklus je popsán prostřednictvím těchto procesů: • Design and Planning • Deployment • Operations • Technical Support Proces Design and Planning poskytuje rámec pro zajištění IT služby do té fáze, že je připravena k instalaci a nasazení. Proces Deployment řeší instalaci a zavádění IT služby a její testování s cílem co nejméně narušit provoz (Operations) a podnikové procesy. Proces Operations se zabývá aktivitami a metrikami, které jsou nutné k tomu, aby byli zajištěny IT služby v úrovni, deklarované v SLA. Proces Technical Support řeší rozvoj znalostí pro ohodnocení, podporu a testování všech současných a budoucích řešení IT infrastruktury. 4.1.2.4

Security Management

Tato kniha se zabývá tím, jak řídit a měřit bezpečnost IT a jak zavádět procesy řízení bezpečnosti. Nutno podotknout, že tato kniha se příliš neujala, neboť její obsah nebyl vůči specifickým bezpečnostním normám dostatečně konkrétní. 44

4.1. ITIL (IT Infrastructure Library) 4.1.2.5

Application Management

Kniha Application Management se zabývá zejména životním cyklem aplikací. Popisuje role, funkce, metriky a metody řízení vývoje aplikací. Zabývá se budováním aplikací od sběru požadavků přes návrh aplikace až po její vydání. Kniha rovněž popisuje základy řízení hodnoty informačního systému pro business (Business - IS Alignment). Zabývá se také strategií řízení dodávky softwarových řešení. 4.1.2.6

Planning to Implement Service Management

Tato publikace popisuje různé aspekty zavádění ITILu a jeho procesů do organizace. Popisuje vize, měření zralosti procesů, nutnost plánování, benchmarking, potřebu školení a další praktiky týkající se zejména zavádění procesů z publikací Service Support a Service Delivery. Jsou zde také příklady popisující zkušenosti z praxe. 4.1.2.7

Business Perspective Vol. 1 – The IS View on Delivering Services to the Business a Business Perspective Vol. 2 – The Business View on Successfull IT Delivery

Tyto dvě publikace řeší vztah businessu a řízení podnikové informatiky. První oddíl (Vol. 1) se na věc dívá očima osob, zodpovědných za řízení podnikové informatiky. Druhý oddíl (Vol. 2) se na věc dívá opačně, tedy očima vrcholového managementu. Tato kniha je jako jediná kniha ITILu verze 2 určena přímo vrcholovým manažerům organizace. 4.1.2.8

Software Asset Management

Tato kniha se zabývá prostředky a činnostmi, které jsou potřeba pro řízení a ochranu softwarových aktiv podniku během jejich celého životního cyklu.

4.1.3

ITIL verze 3

(použitá literatura: [34], [4], [32], [35], [26], [24], [27], [25], [23]) V roce 2007 bylo vydáno 5 knih ITIL verze 3, které v roce 2011 prošli aktualizací. Knihy byli sepsány a vydány najednou a tvoří tedy, na rozdíl od druhé verze, konzistentní celek. Jádro ITILu verze tři tvoří těchto pět knih: • Service Strategy [26] • Service Design [24] • Service Transition [27] 45

4. Metodiky a standardy pro podporu IT Governance • Service Operation [25] • Continual Service Improvement [23] Jedna kniha byla doplněna jako přehledová publikace: • Official Introduction to the ITIL Service Lifecycle [34] Následující schéma ITILu verze 3 ukazuje využití principu PDCA cyklu při neustálém zlepšování kvality služeb:

Obrázek 4.4: schéma ITIL v3 [35] Nyní se podíváme na jednotlivé publikace třetí verze ITILu a na jednotlivé procesy, které tyto knihy definují. Pro lepší představu čtenáře o návaznosti 46

4.1. ITIL (IT Infrastructure Library) knih, ukazuje následující obrázek pohled ITILu na životní cyklus služeb. Je v něm dobře patrné, která kniha navazuje na kterou a co je zhruba jejich obsahem. Obrázek ukazuje datové a procesní toky mezi jednotlivými částmi životního cyklu služeb.

Obrázek 4.5: životní cyklus služeb dle ITILu [35]

4.1.3.1

Service Strategy

Jedná se o ústřední knihu ITILu, která poskytuje praktický rámec, který přináší principy a návody k návrhu, vývoji a implementaci řízení služeb, a to jak z pohledu organizačního, tak i jako zdroje strategické výhody, která zajistí podniku schopnosti k transformaci zdrojů do služeb, přinášejících businessu hodnotu. Publikace obsahuje definice služeb, popisuje IT strategii a plánování přidané hodnoty. Obsahuje také definice typů poskytovatelů služeb a obchodních strategií. Dále obsahuje témata jako finanční řízení služeb, řízení portfolia 47

4. Metodiky a standardy pro podporu IT Governance služeb, strategický pohled na životní cyklus služby, rozvoj organizace a další. Publikace také vysvětluje, jaké jsou důvody pro zavádění principu řízení služeb s ohledem na business zákazníka, a popisuje vztah mezi strategií a tématy z ostatních knih ITILu. ITIL prosazuje jednu zásadní myšlenku: Strategie jakéhokoli poskytovatele služeb musí být založena na poznání toho, že zákazník nekupuje produkty, ale uspokojení konkrétních potřeb. Z tohoto důvodu je publikace Service Strategy opravdovým jádrem životního cyklu ITIL V3 a je na ni kladen významný důraz. Zaměřuje se na návody všem poskytovatelům služeb IT a jejich zákazníkům, jak provozovat a dlouhodobě udržet jasnou strategii služeb právě v souladu s výše zmíněnou myšlenkou. V knize jde především o následující: • jaké služby by měly být nabízeny • komu mají být služby nabízeny • jak zákazník a zainteresované strany budou vnímat a měřit přidanou hodnotu, a jak bude tato hodnota vytvářena • jak rozhodovat o zdrojích služeb s ohledem na využití různých typů poskytovatelů služeb • jak bude dosaženo průzračnosti a kontroly vytváření hodnot prostřednictvím správy financí • jak robustní obchodní případy vytvořit pro zajištění strategických investic do IT služeb a do schopnosti správy služeb • jak optimalizovat celkové portfolio služeb s ohledem na dostupnost zdrojů pro dosažení maximálního efektu • jak měřit výkonnost služeb Kniha definuje tři základní typy poskytovatelů služeb: • TYP 1: existuje v rámci organizace výlučně pro dodávku služby pro jeden specifický podnikový útvar • TYP 2: poskytuje služby více podnikovým útvarům v téže organizaci • TYP 3: operuje jako externí poskytovatel služeb pro více externích zákazníků Procesy, které jsou součástí knihy Service Strategy jsou tyto: 48

4.1. ITIL (IT Infrastructure Library) 4.1.3.1.1 Financial Management Financial Management je proces, který zprostředkovává oceňování a finanční vyčíslení hodnoty služeb IT, hodnoty aktiv potřebných pro poskytování těchto služeb a ohodnocení provozních prognóz. Proces řeší také tvorbu a sledování rozpočtu IT útvaru, evidenci nákladů za IT služby a vyhodnocování návratnosti investic do IT služeb. Výstupem procesu jsou podklady pro sestavování rozpočtu na IT služby a jejich ceník. 4.1.3.1.2 Service Portfolio Management Proces Service Portfolio Management se zabývá definováním služeb, zajištěním obchodních případů, analýzou portfolia IT služeb, maximalizací hodnoty portfolia IT služeb a sladěním, prioritizací a vyvážením dodávky a poptávky po IT službách. Dále proaktivně spravuje investice v průběhu životního cyklu služeb, a to včetně těch služeb, které jsou ve fázi koncepce, návrhu a přechodu, stejně jako ’živých’ služeb definovaných v různých katalozích služeb a služeb vyřazených. 4.1.3.1.3 Demand Management Účelem Procesu Demand Management je porozumět zákazníkovým požadavkům na služby, ovlivňovat je a zajišťovat kapacitu pro naplnění těchto požadavků. Kromě jiného se v procesu provádí analýza charakteru obchodní činnosti a uživatelských profilů. 4.1.3.2

Service Design

Úkolem této knihy je poskytnout rámec pro návrh a rozvoj služeb a procesů řízení těchto služeb. Kniha obsahuje principy a metody pro transformaci strategických cílů do portfolia služeb a aktiv. Není soustředěna pouzena na služby nové, ale obsahuje i procesy změn a procesy průběžného zlepšování služeb stávajících. Tyto procesy jsou důležité pro udržení nebo zvýšení úrovně služeb, jejich přidané hodnoty pro zákazníka a také i jejich soulad s právními normami a standardy. V knize jsou také popsány vybrané činnosti řízení požadavků. V knize jde především o: • návrh nových služeb • změny ve stávajících službách • návrh systémů a nástrojů řízení služeb (katalog služeb, řízení konfigurací služeb,...) • návrh technologické architektury • návrh potřebných procesů • vytvoření a zavedení metod měření a metrik pro jednotlivé služby Procesy, které jsou součástí knihy Service Design jsou tyto: 49

4. Metodiky a standardy pro podporu IT Governance 4.1.3.2.1 Service Catalogue Management Proces Service Catalogue Management se zabývá tvorbou systému pro katalog služeb. Ten poskytuje jediný zdroj ucelených a konzistentních informací o všech sjednaných službách a jejich seznam. Účelem procesu je, aby tento seznam služeb byl dostupný pro všechny oprávněné osoby. 4.1.3.2.2 Service Level Management Účelem procesu je zajistit úroveň kvality IT služeb. Zabývá se plánováním, koordinací, navrhováním, uzavíráním, monitorováním, vyhodnocováním a dokumentováním smluv se zástupci zákaznické organizace a jinými dodavateli. Úroveň kvality služeb je se zákazníkem sjednávána v dokumentech nazvaných SLA (Service Level Agreement), ve kterých jsou veškeré informace o službách, včetně jejich parametrů. Smlouvy s dodavateli se sjednávají prostřednictvím dokumentů nazvaných UC (Underpinning Contract) a s vnitřními dodavateli prostřednictvím dokumentů nazvaných OLA (Operational Level Agreement). Důvod, proč zde zmiňuji názvy těchto dokumentů je, že se tyto názvy běžně v IT používají. Účelem procesu také je následně sledovat schopnosti poskytovatele dodat sjednané služby. 4.1.3.2.3 Capacity Management Účelem procesu Capacity Management je poskytnout správu všech záležitostí souvisejících s kapacitou a výkonností vztažených jak ke službám, tak ke zdrojům, a přizpůsobit kapacitu IT infrastruktury schváleným požadavkům businessu. Základním kamenem procesu je informační systém správy kapacit (Capacity Management Information System – CMIS). Informace obsažené v CMIS jsou ukládány a analyzovány všemi subprocesy Capacity Managementu za účelem tvorby technických reportů a hlášení pro management. 4.1.3.2.4 Availability Management Proces zodpovídá za zajištění chodu IT infrastruktury, dosažení úrovně služeb, která odpovídá požadavkům byznysu, a zejména za zajištění toho, aby veškeré systémy byly stále, v přijatelných nákladech, dostupné uživatelům a uspokojily jejich požadavky. V procesu je třeba sledovat, měřit a monitorovat skutečné a potenciální možnosti systémů (včetně jejich nákladů), porovnávat tyto hodnoty s požadavky businessu na jejich dostupnost a v případě nesouladu buď projednat a případně upravit požadavky vzhledem k možnostem a k ceně, anebo upravit dostupnost systému (což znamená rovněž změnu ve zmíněném dokumentu SLA – mění se úroveň služby, v tomto případě její dostupnost). 4.1.3.2.5 IT Service Continuity Management Účelem procesu IT Service Continuity Management je řídit rizika, která by mohla mít vážný dopad na IT služby. Proces má zajistit, že je poskytovatel služeb schopen neustále poskytnout dohodnutou úroveň služeb tím, že redukuje rizika na minimum, minimalizuje jejich dopady a plánuje případné zotavení v předstihu. Toho je v 50

4.1. ITIL (IT Infrastructure Library) procesu dosaženo, mimo jiné, pravidelným prováděním analýzy dopadů rizik na business. Cílem procesu také je, aby byl v případě výpadku provoz veškerých součástí IT infrastruktury obnoven v požadovaném a sjednaném čase, a aby nebyla ovlivněna kontinuita businessu. Předchozí procesy knihy byly různým způsobem vyjádřeny i v ITIL verze 2. Přibyly však následující procesy Information Security Management a Supplier Management. 4.1.3.2.6 Information Security Management Proces Information Security Management má zajistit, že bezpečnost informací je efektivně spravována ve všech službách a v činnostech správy služeb. Má zajistit, aby byly informace zobrazeny nebo odkryty pouze tomu, kdo k tomu má práva. Má také zabránit neautorizovaným změnám. 4.1.3.2.7 Supplier Management Účelem procesu Supplier Management je získat od dodavatelů hodnotu za peníze (value for money) a zajistit, aby dodavatelé plnili cíle dohodnuté v kontraktech a dohodách při zachování všech termínů a podmínek. Hlavním zdrojem informací o dodavatelích a kontraktech je databáze dodavatelů a kontraktů, která by měla obsahovat veškeré informace, nutné pro správu dodavatelů, kontraktů a s nimi spojených služeb. V knize je také část Implementing Service Design, která popisuje postupy při zavádění procesů a způsob měření zralosti procesů a IT sledované organizace. 4.1.3.3

Service Transition

Kniha obsahuje rady a postupy pro efektivní instalaci a nasazení služeb, definovaných v rámci Service Strategy a realizovaných v rámci Service Design. Obsahuje také rámec pro řízení změn za současného snížení rizik výpadků a poruch IT služeb během jejich přechodu k zákazníkovi a řízení konfigurací jednotlivých služeb. Procesy, které jsou součástí knihy Service Design jsou tyto: 4.1.3.3.1 Transition Planning and Support Součástí procesu Transiton Planning and Support jsou činnosti spojené s plánováním a koordinací vhodných kapacit a zdrojů za účelem uvedení a testování nové nebo změněné služby do provozu. Proces také řeší identifikaci, správu a kontrolu rizik a reportování a komunikaci v průběhu přechodu služeb. 4.1.3.3.2 Change Management Change Management je proces, který používá standardizované metody a procedury k tomu, aby dosáhl efektivního a rychlého vyřízení změn v IT infrastruktuře. Úkolem tohoto procesu je, aby 51

4. Metodiky a standardy pro podporu IT Governance minimalizoval vznik incidentů, které mohou vzniknout kvůli změně v IT infrastruktuře. Veškeré změny by měli být prováděny na základě zdokumentovaných požadavků – RFC (Request for Change). Před provedením jakékoli, byť malé změny je potřeba zvážit dopad takové změny na IT infrastrukturu. Ta totiž může být velmi rozsáhlá a i malá změna může zapříčinit, že dojde k incidentu v jiných částech infrastruktury, než ve které došlo ke změně (typicky u informačních systémů). Provádění jakékoli změny je navíc třeba důkladně dokumentovat, jinak by mohla být omezena schopnost IT v budoucnu řídit (opět se jedná zejména o změny v informačním systému) a zvýšila by se složitost hledání příčin výpadků. Pokud nebudou změny dokumentovány, bude navíc podnik závislí na konkrétních osobách, které změny prováděli. Proces rovněž řeší autorizaci, prioritizaci, plánování, testování a následné hodnocení dopadů změn. To se týká i změn provedených za účelem nápravy incidentu nebo odstranění příčin incidentu. 4.1.3.3.3 Service Asset and Configuration Management Proces poskytuje logický model IT infrastruktury a všech jejích aktiv a služeb pomocí identifikace, řízení, správy a verifikace všech konfiguračních položek, které jsou implementovány. Proces také zodpovídá za sledování stavu informačního systému. Veškerá dokumentace incidentů, problémů, požadavků na změny a zejména dokumentace zdrojů IT infrastruktury, tedy použitý software a hardware, pracovníci, odpovědní uživatelé a dalších tzv. konfiguračních položek (Configuration Item) by měla být vedena v konfigurační databázi CMDB (Configuration Management Database). Pro software a media, které nelze měnit (například jsou autorsky nebo licenčně chráněny) by měla být k dispozici knihovna DML (Definitive Media Library). Další zodpovědností procesu Service Asset and Configuration Management je zajistit shodu obsahu konfigurační databáze a skutečného stavu IT infrastruktury. 4.1.3.3.4 Release and Deployment Management Proces Release and Deployment Management se zabývá testováním a uváděním do provozu nových nebo aktualizovaných služeb tak, aby byly vhodně dodány zákazníkovi a aby nebyl ohrožen jeho business, ani provoz dalších služeb. Proces zajišťuje, že technické i organizační aspekty uvádění služeb do provozu budou v souladu. To mimo jiné znamená, že veškeré změny, prováděné do provozu IT, musí být prováděny tak, aby co nejméně omezovaly uživatele a nenarušovaly kontinuitu businessu zákazníka. 4.1.3.3.5 Service Validation and Testing V procesu Service validation and testing se plánují a provádějí testy, které mají ověřit, že nová nebo změněná služba poskytuje zákazníkovi plánovanou hodnotu v rámci definovaných parametrů. Dále se v procesu identifikují chyby, problémy a rizika týkající se změn služby. 52

4.1. ITIL (IT Infrastructure Library) 4.1.3.3.6 Evaluation Proces Evaluation se zabývá tím, jak hodnotit, zda jsou předpokládané parametry služby v souladu s očekáváním zákazníka a zda jsou aktuální hodnoty služby v souladu s plánovanými hodnotami. Výstupy procesu jsou vstupem pro proces Change Management. 4.1.3.3.7 Knowledge Management Proces Knowledge Management řeší jak zajistit zaznamenání, přenos a správnou komunikaci znalostí během změn služeb. Tento proces je založen na systému řízení znalostí o službách – SKMS (Service Knowledge Management System). SKMS je vlastně rozšířením výše zmíněným CMS. 4.1.3.4

Service Operation

Tato kniha se zabývá operativními procesy při poskytování služeb. Kniha poskytuje rady a postupy pro řízení služeb v produkčním prostředí a pro dosažení výkonné a účinné dodávky IT služeb a jejich podpory. Vedle procesů kniha popisuje i řadu činností spíše technologického charakteru, které je nutné při provozu IT služeb provádět. Ty ITIL nazývá funkcemi. Procesy, které jsou součástí knihy Service Operation jsou tyto: 4.1.3.4.1 Event Management Proces Event Management sleduje všechny události, které se dějí v IT infrastruktuře, a snaží se detekovat a upozornit na výjimečné stavy. 4.1.3.4.2 Incident Management Proces Incident Management zajišťuje co nejrychlejší obnovení dodávky IT služeb a minimalizaci následků výpadku IT služeb na business. Pracovníci v průběhu tohoto procesu identifikují a odstraňují nestandardní stav (incident) IT infrastruktury co nejrychleji. Využívají přitom dočasná řešení – tzv. Workaround. 4.1.3.4.3 Problem Management Problem Management je proces, který má za úkol analyzovat původní příčiny incidentů. Proces poté iniciuje zajištění oprav chyb v IT infrastruktuře. Problem Management má také za úkol prevenci dalších problémů. Incident Management a Problem Management jsou procesy, které běží souběžně nebo po sobě (první proces Incident Management). Zatímco během Incident Managementu tedy běží práce na obnově standardního stavu IT infrastruktury, během procesu Problem Management se pracovníci snaží identifikovat příčiny (Root Causes) problémů, kvůli nimž incident vznikl. Výsledkem procesu by mělo být odstranění příčiny, vytvořena taková opatření, která vzniku této příčiny zabrání, nebo alespoň vytvoření postupu pro rychlé vyřešení incidentu, který se může opakovat. Proces Problem Management však kromě okamžité reakce, tedy při vzniku incidentů, může 53

4. Metodiky a standardy pro podporu IT Governance probíhat neustále a pracovat na neustálém zlepšování IT služeb. Zjednodušeně řečeno: Při řešení nestandardních situací, jako výpadek, porucha, chyba a dalších nestandardních situacích a při činnostech na následné obnově žádoucího stavu IT infrastruktury je třeba naplnit dva cíle: 1. je potřeba co nejrychleji obnovit normální stav, aby nestandardní stav neměl negativní dopad na business (incident management) 2. je potřeba zajistit, aby se problém již neopakoval, tedy opravit příčinu nestandardního stavu, nebo alespoň zajistit, aby byl příště nestandardní stav odstraněn snadněji a rychleji (problem management) 4.1.3.4.4 Request Management Request Management je proces zajišťující vyřizování požadavků uživatelů na služby. 4.1.3.4.5 Access Management Access Management je proces, který zajišťuje užití služby autorizovaným uživatelům a zabránění užití služby uživatelům neautorizovaným. Dále kniha popisuje následující funkce: 4.1.3.4.6 Service Desk Účelem funkce Service Desk je poskytnout uživateli informačního systému kontaktní místo pro adresování jeho požadavků. Jsou zde v různé formě přijímány požadavky uživatelů na změny IS, případně je možné zde ohlásit incident, získat informace, požádat o školení, a další. Service Desk zajišťuje každodenní kontakt s uživateli (zákazníky), ale i s třetími stranami (dodavateli). Service Desk je jakési rozhraní mezi uživateli (ať už interními nebo externími) a dodavatelem služeb, a tedy tohoto dodavatele reprezentuje. Měl by být řízen s ohledem na jeho důležitost, kterou má z pohledu vnímání informatiky u uživatelů. ITIL popisuje, jak vytvořit a provozovat Service Desk jako efektivní komunikační kanál mezi uživatelem a poskytovatelem IT služeb. Toto jsou specifické odpovědnosti Service Desk: • zaznamenávat veškeré incidenty a požadavky, kategorizovat je a prioritizovat je • v případě problémů provádět jejich diagnózu a přezkoumání v první linii • spravovat životní cyklus incidentů a požadavků a uzavírat poté, co je uživatel spokojen • průběžné informovat uživatele o stavu služeb, incidentů a požadavků. Kniha Service Operation definuje tyto způsoby jak strukturovat a organizovat Service Desk: 54

4.1. ITIL (IT Infrastructure Library) • lokální service desk: je fyzicky blízko uživatelům • centralizovaný service desk: více oddělení sdílí jeden service desk • virtuální service desk: service desk se nachází na více stanovištích, ale uživateli se jeví jako jediný • nepřetržitý provoz (Follow the Sun): v různých časových zónách jsou service desky, které zajišťují nepřetržitý provoz směrováním volání na to stanoviště, které je aktivní 4.1.3.4.7 Technical Management Funkce Technical Management pomáhá plánovat, implementovat a udržovat stabilní technickou infrastrukturu a zajišťovat, aby byly k dispozici požadované zdroje a odbornosti pro návrh, sestavení, přechod a provoz služeb IT a podpůrné technologie. 4.1.3.4.8 Application Management Funkce Application Management zahrnuje veškerý personál poskytující technickou odbornost a správu aplikací. Má tedy velmi podobnou roli jako Technical Management, s tím rozdílem, že je zaměřena na softwarové aplikace. 4.1.3.4.9 IT Operation Management Funkce IT Operations Management má na starost síťové prostředí a správu datových center. Kniha dále obsahuje operativní činnosti procesů z ostatních fazí životního cyklu služby: • Change Management (Service Transition) • Capacity Management (Service Design) • Availability Management (Service Design) • Financial Managementu (Service Strategy) • Knowledge Management (Service Transition) • IT Service Continuity Managementu (Service Design) • Service Reporting (Continual Service Improvement) • Service Measurement (Continual Service Improvement) 55

4. Metodiky a standardy pro podporu IT Governance 4.1.3.5

Continual Service Improvement

Kniha se zabývá nástroji a prostředky pro zajišťování souladu IT služeb s potřebami businessu a vytvářením a udržováním přidané hodnoty IT služeb pro zákazníka, a to neustálím zlepšováním a zkvalitňováním služeb a zvyšováním efektivity jejich provozu během jejich celého životního cyklu. Kombinuje přitom principy, praktiky a metody řízení kvality a Change Managementu. Publikace také popisuje Sevice Gap model, ve kterém identifikuje šestnáct možných nedorozumění, které vznikají pohledem na služby z různých perspektiv. Základem kontinuálního zlepšování služeb je dle ITILu Demingův cyklus PDCA (Plan-Do-Check-Act). Kniha se dále zabývá návratností investic do IT, hodnotou těchto investic a také pohledem businessu na zlepšování služeb. Popisuje proces Service Level Management z pohledu neustálého zlepšování. Procesy knihy Continual Service Improvement jsou tyto: 4.1.3.5.1 7 Step Improvement Process Tento proces zlepšování v 7 krocích zahrnuje kroky potřebné pro sběr smysluplných dat, analýzu těchto dat kvůli identifikaci trendů a problémů, prezentaci informací managementu za účelem prioritizace a schválení implementace zlepšení. 7 kroků zlepšování: • Krok 1 – Definice toho, co by se mělo měřit • Krok 2 – Definice toho, co je možné měřit Měla by se provést diferenční analýza (gap analysis) mezi tím, co je aktuálně měřeno nebo může být měřeno. Rozdíly a důsledky by se měly reportovat IT managementu, případně zákazníkům. • Krok 3 – Monitorování a sběr dat • Krok 4 – Zpracování dat Syrová data jsou zpracována do požadovaného formátu • Krok 5 – Analýza dat Analýza dat transformuje informace do znalostí o událostech, které na organizaci dopadají. To znamená, že jakmile jsou data zpracována do informací, výsledky lze analyzovat a odpovědět na otázky jako: – Dosahujeme cilů? – Jsou zřejmé nějaké trendy? – Jsou nutné nápravné akce? 56

4.1. ITIL (IT Infrastructure Library) • Krok 6 – Prezentace a využití nabytých znalostí

Získané znalosti se mohou nyní prezentovat ve formátu, jemuž lze snadno porozumět a jenž umožní příjemcům těchto informací učinit strategická, taktická a provozní rozhodnutí.

• Krok 7 – Implementace nápravných akcí

4.1.3.5.2 Service Measurement Proces Service Measurement je základním předpokladem schopnosti spravovat služby a procesy a vykazovat hodnoty businessu. Proces je podporou pro předchozí proces zlepšování v 7 krocích.

4.1.3.5.3 Service Reporting Proces Service Reporting slouží pro tvorbu výkazů. IT sbírá a monitoruje významné množství dat při denních dodávkách služeb businessu, avšak jen malá část z toho je pro business opravdu zajímavá a důležitá. Nestačí prezentovat výkazy popisující soulad s SLA a další detaily. IT musí vybudovat akční přístup k vykazování, tj. co se stalo, co IT udělalo, jak IT zajistí, že se to nebude opakovat znovu, a jak IT pracuje na celkovém zlepšení dodávky služeb. Následující schéma zobrazuje jednotlivé fáze životního cyklu IT služby (knihy) a procesy které obsahují: 57

4. Metodiky a standardy pro podporu IT Governance

58 Obrázek 4.6: ITIL v3 knihy a procesy [31]

4.1. ITIL (IT Infrastructure Library)

4.1.4

Srovnání ITIL v2 vs. ITIL v3

(literatura: [4], [15]) Při detailním srovnání dvou verzí ITILu jsem zjistil, že všechny hlavní procesy verze 2 jsou zachyceny i ve verzi 3, byť z jiného pohledu. Ve verzi 2 jsou knihy Service Delivery a Service Support strukturovány procesně, ostatních šest knih však ne. Většina nových procesů ITILu verze 3 v těchto šesti knihách ITILu verze 2 je, avšak protože nejsou strukturovány procesně, je výtěžnost informací z těchto knih poněkud problematická. Navíc některé procesy ITILu verze 3 byli vytvořeny dekompozicí procesů (zjednodušením a rozložením do více procesů) z předchozí verze knihovny, a proto verze 3 nabízí procesním specialistům a architektům detailnější pohled na strukturu a pochopitelnější obsah a rozsah popsaných procesů. Knihy verze 2 byly vydávány postupně a na jednotlivých knihách nebo kapitolách pracovali různí autoři, zkušení v řízení IT služeb. Protože se ale autoři nekoordinovali vedlo to k určité nekonzistenci. Například co jeden autor doporučil, druhý třeba nedoporučil, či zamítl. Doporučení v různých knihách nebo kapitolách mohou tedy být v určitém rozporu. Na druhou stranu to nutí čtenáře ke kritickému přístupu a přemýšlení, místo aby slepě přejímal doporučení. Základem obou verzí ITILu je procesní přístup k řízení IT služeb. Třetí verze se však na rozdíl od té druhé odklonila od striktně procesního řízení podnikové informatiky a zaměřila se více na řízení životního cyklu služeb, podle kterého jsou jednotlivé knihy také strukturovány, a na řízení IT služeb s ohledem na jejich hodnotu pro zákazníka. Při návrhu služby je tedy nejdůležitějším úkolem zjistit, jakou hodnotu by měla tato služba pro zákazníka a jakou jeho potřebu by měla naplnit. IT služba totiž vždy uspokojuje nějakou potřebu zákazníka, bez čehož by zákazník nebyl schopen dosáhnout svých cílů. Zde je velmi dobře patrný rozdíl v pojetí řízení IT služeb mezi ITIL verzí 2 a verzí 3. Ve verzi 2 byly procesy popsány samostatně a až poté, ve speciálních kapitolách, byly popsány návaznosti mezi nimi. Ve verzi 3 jsou procesy uspořádány dle životního cyklu služby. Znamená to, že popis některých procesů se může objevit ve více kapitolách nebo knihách. V praxi se totiž ukázalo, že jakkoli důsledné soustředění se na implementaci sofistikovaného, procesně řízeného IT prostředí, v němž jsou služby poskytovány (což je princip ITIL verze 2), často nepřinese potřebnou hodnotu pro zákazníka, neboť se vytratí hlavní cíl – dodat zákazníkovi služby a hodnoty, které mu umožní dosáhnout požadovaných výsledků. Je potřeba zdůraznit, že třetí verze nepopírá žádný z aspektů systému řízení IT služeb, který vymezila verze druhá. Pouze k nim přidává nový prvek – řízení hodnoty služby pro zákazníka a to ve všech fázích životního cyklu služby. Navíc většina principů a zásad, které jsou přítomny ve verzi 3, jsou přítomny i ve verzi 2, jsou však zasazeny do jiného, lépe uchopitelného kontextu. 59

4. Metodiky a standardy pro podporu IT Governance

4.2

úvod do ISO 20000

(literatura: [4], [29], [5]) Norma ISO 20000 je součástí rodiny mezinárodních standardů vydávaných mezinárodní organizací pro standardizaci ISO (International Organization for Standardization). Tato norma je standardem pro systém řízení IT služeb a technologií. Je velmi inspirována ITILem a její autoři dokonce pocházejí z organizací, které se přímo podílí na vývoji ITILu. S výjimkou malých firem se tato norma zaměřuje na poskytovatele IT služeb pro všechny velikosti podniku a všechna odvětví. Předmětem normy jsou požadavky, které jsou kladeny na poskytovatele služeb a které se týkají dodávky služeb v kvalitě přijatelné pro zákazníky. Norma se mimo jiné zabývá odpovědnostmi managementu, požadavky na dokumentaci řízení informatiky, odbornou způsobilostí zaměstnanců a jejich školením. Zabývá se také metodikou zlepšováním kvality procesů a neustálého zlepšování služeb IT, a to podle dříve zmíněného Demingova PDCA cyklu.

4.2.1

Historie ISO 20000:

Od konce osmdesátých let pracoval institut BSI (British standard institution) na sbírce praktik řízení služeb. V roce 1995 tento institut vydal sbírku nazvanou DISC PD 0005:1995. Tu poté v roce 1998 přepracoval na DISC PD 0005:1998, která se skládala ze 13-ti procesů, které v podstatě tvořily dnešní normu ISO 20000. V roce 2000 institut BSI vydal další verzi jejich sbírky, ze které udělal standard. Jmenoval se BS15000 a byl vytvořen tak, aby byl ve shodě s ITILem verze 2. Postupem času se tento standard vylepšoval. V roce 2005 na základě tohoto standardu vytvořila organizace ISO standard ISO 20000, který měl nahradit BS15000. Od té doby se ISO 20000 neustále vylepšuje a "synchronizuje"s ITILem. [29]

4.2.2

Struktura ISO 20000:

Norma se skládá ze dvou částí: • ISO/IEC 20000-1:2005 Information technology – Service management – Part 1: Specification (specifikace řízení IT služeb) • ISO/IEC 20000-2:2005 Information technology – Service management – Part 2: Code of Practice (praktická doporučení) V první části jsou definovány povinnosti a požadavky, které musí organizace splňovat, jestliže chce splnit podmínky pro mezinárodní certifikaci kvality poskytování a řízení IT služeb. V druhé části potom nalezneme doporučení, 60

4.2. úvod do ISO 20000 které pomáhají při praktické implementaci normy a splnění požadavků uvedených v části první. Základní schéma struktury normy: 1. Předmět normy V této části je definován účel, rozsah a možnosti použití této normy. 2. Termíny a definice Tato část definuje 15 pojmů, které pocházejí z terminologie ITILu. Táto část není povinná, takže organizace může používat vlastní terminologii, důležitý je hlavně obsah. 3. Požadavky na systém managementu Část definuje odpovědnosti vrcholového managementu řízení kvality služeb v organizaci, definuje požadavky na dokumentaci, přidělování kompetencí a povinnost systematických školení personálu. 4. Plánování a implementace managementu služeb V této části je definován systém kontinuálního zlepšování metodou PDCA. 5. Plánování a implementace nových nebo změněných služeb Zde jsou definovány požadavky na plánování a posuzování nákladů, dopadů a rizik změn. 6. 6. Procesy dodávky služeb Norma definuje procesy, které pokrývají taktické plánovaní řízení služeb: • Service level management (management úrovně služeb) • Service reporting (výkazy o službách) • Service continuity management (management kontinuity a dostupnosti služeb) • Budgeting and accounting for IT services (rozpočtování a účtování pro IT služby) • Capacity management (management kapacit) • Information security management (management bezpečnosti informací) Všechny tyto procesy jsou dobře známé z rámce ITIL. 7. Procesy vztahů Zde jsou definovány procesy, které jsou ITILem trochu zanedbávané. Jsou to: • Business relations management (řízení vztahů s businesem) 61

4. Metodiky a standardy pro podporu IT Governance • Suplier relations managemet (Řízení vztahů s dodavateli) 8. Procesy řešení problému a obnovy Zde norma definuje dobře známé procesy z ITILu, které zabezpečují operativu řízení služeb: • Incident management (management incidentů) • Problem management (management problémů) 9. Řídící procesy Norma zde definuje v praxi často používané procesy z ITILu, jejichž úlohou je informační podpora, zabezpečení a kontrola všech změn: • Configuration management (management konfigurací) • Change management (management změn) 10. Uvolňování služeb Definuje požadavky na proces, který reálně a fyzicky vykonává, implementuje a nasazuje změny související s nasazováním služeb: • Release management (management uvolnění služeb) Procesní struktura se tedy skládá ze čtyř procesních oblastí a jednou kontrolní oblastí, což zobrazuje následující schéma:

Obrázek 4.7: Procesní struktura ISO 20000 [29] 62

4.3. Úvod do CobiT (Control Objectives for Information and related Technology) Tato norma převzala a mírně přestrukturovala procesy uvedené v knihách ITIL verze 2 Service Support a Service Delivery a doplnila je o procesy řízení vztahů a bezpečnosti. Jinak lze říci, že je tato norma plně v souladu s ITIL verze 2 i verze 3.

4.3

Úvod do CobiT (Control Objectives for Information and related Technology)

(literatura: [4], [5]) Zřejmě druhým nejrozšířenějším standardem IT Governance je procesní rámec CobiT. Tento standard vyvinula a publikovala nezisková a nezávislá organizace ISACA. Při jeho tvorbě ISACA využila mezinárodní standardy a nejlepší zkušenosti pro řízení a audit v oblasti informačních technologií. CobiT byl vyvinut jako všeobecně přijímaný standard pro správné postupy řízení, kontroly a auditu IT. Tento procesní rámec se zabývá zejména IT procesy, modely vyspělosti procesů (maturity model) a manažerskými postupy (management guidelines) včetně aktivit, zodpovědností a pravomocí. CobiT je výrazně orientován na business, ale také popisuje osvědčené přístupy v IT. Řízení a správa podniku, jako systém, kterým je organizace vedena a kontrolována (Enterprise Governance) a řízení a správa podnikové informatiky, jako systém, kterým je IT v organizaci vedeno a kontrolováno (IT Governance), jsou dle CobiTu vzájemně podmíněné systémy, závislé jeden na druhém.

4.3.1

Historie CobiTu:

Poprvé ISACA publikovala procesní rámec CobiT v roce 1996. Toto první vydání zahrnovalo pouze rámec (framework) pro řízení podnikové informatiky. Ve druhém vydání v roce 1998 přibyly auditní postupy (audit guidelines), sada implementačních nástrojů (implementation toolset) a IT procesy a jejich detailní cíle (control objectives). V roce 2000 vyšlo třetí vydání, ve kterém přibyly manažerské postupy (management guidelines) a byl inovován rámec pro řízení podnikové informatiky. V roce 2000 také přešel CobiT od ISACA pod křídla ITGI (IT Governance Institute), který byl založen v roce 1998. ITGI je organizace, která se zaměřuje na pomoc organizacím s úspěšným řízením IT. V roce 2003 byl CobiT poprvé zpřístupněn on-line (on-line verze). V roce 2005 byla vydána čtvrtá verze, která byla v roce 2007 revidována na verzi 4.1.

4.3.2

struktura CobiTu

CobiT je procesní rámec – je tedy strukturován dle procesů. Dělí řízení podnikové informatiky na čtyři domény, v nichž definuje celkem třicet čtyři IT procesů. Pro každý z těchto procesů CobiT navrhuje kritéria, podle kterých je možné měřit výkonnost těchto procesů a měřit rizika, která jsou s nimi spojena. CobiT je kontrolní rámec - veškeré postupy, procedury, pravidla a organizační 63

4. Metodiky a standardy pro podporu IT Governance struktura jsou definovány tak, aby zaručovaly, že budou dosaženy podnikové cíle a že bude minimalizována pravděpodobnost jejich ohrožení. Toho CobiT dosahuje tím, že definuje pro všech třicet čtyři procesů kontrolní cíle, které obsahují množinu požadavků na daný proces. Na jejich základě je poté možné určit stupeň vyspělosti procesu, pro který se využije zmíněný model vyspělosti procesů. Tento model definuje následující stupně vyspělosti procesu: Stupeň 0- Neexistující proces: Daný proces není vůbec definován a není ani prováděn nahodile. Stupeň 1 - Neuspořádaný, Ad Hoc proces: Proces není definován, ale je prováděn nahodile. Takový proces je zcela závislý na jedinci a jeho výstupy se různí případ od případu. Stupeň 2 – Opakovatelný, ale intuitivní proces: Proces není definován, ale některé postupy jsou prováděny podobně. Jejich provedení však stále závisí na jedincích. Stupeň 3 Definovaný proces: Jednotlivé postupy byly standardizovány, dokumentovány a lidé, kterých se proces týká, byly proškoleni. Stupeň 4 Řízený a měřitelný proces: Management monitoruje proces a měří efektivitu jednotlivých aktivit v procesu. Procesy jsou neustále vylepšovány a přizpůsobovány. Stupeň 5 Optimalizovaný proces: Proces je dlouhodobě optimalizován na základě výsledků monitorování a měření. Jsou využívány informační technologie pro automatizaci pracovních a informačních toků tak, aby byl proces efektivnější a jeho výstupy kvalitnější. [2] CobiT se zaměřuje na uživatele, manažery a auditory. Manažerům CobiT umožňuje nalézt rovnováhu mezi investicemi, rizikem a řízením IT a auditorům CobiT nabízí nástroje, které mohou použít při návrhu interních kontrol a optimalizací. Cílovou skupinou CobiTu jsou především pracovníci na strategické a taktické úrovni řízení organizace. Napomáhá však také zvýšit relevanci a spolehlivost informací. Proto ho ocení také pracovníci, kteří poskytují služby v oblasti řízení kvality, kontroly a správy IT. CobiT lze v praxi využít jako pomůcku pro zavádění podnikových procesů a pro optimalizaci těchto procesů, lze jej použít jako nástroj sladění vizí a cílů podniku a IT. Velmi často se však používá jako nástroj auditu podnikové informatiky. Procesy CobiTu totiž je možné bez problému sladit a propojit s procesy z jiných osvědčených praktik, jako například ITIL. CobiT obsahuje návod na provádění auditu (IT assurence guide nebo také Audit guidelines). Pokud chce organizace deklarovat schodu se SOX (Sarbanes-Oxley Act), při návrhu procesů a auditu vychází z rámce CobiT. 64

4.3. Úvod do CobiT (Control Objectives for Information and related Technology) 4.3.2.1

Čtyři domény CobiTu

CobiT zahrnuje čtyři procesní domény, tedy čtyři oblasti procesního řízení podnikové informatiky. Jsou to tyto: • Plan and Organize (plánování a organizace) • Acquire and Implement (pořízení a implementace) • Deliver and Support (dodávka služeb a podpora) • Monitor and Evaluate (Monitorování a hodnocení) V nich CobiT definuje celkem třicet čtyři procesů. Pro každý proces jsou definovány: 1. obsah a cíl 2. dílčí kontrolní cíle 3. typické aktivity a role 4. vstupy a výstupy 5. kritéria pro model vyspělosti 6. způsob měření 7. způsob auditu Cobit rovněž obsahuje referenční procesní model jednotlivých domén. My se nyní na jednotlivé procesní domény podíváme. 4.3.2.1.1 Plan and Organize (plánování a organizace) V této doméně jde o úroveň strategického a taktického plánování a organizování IT. Jde také o řízení přidané hodnoty IT pro business. Doména se zaměřuje na co možná nejlepší způsob, jak využít informací a informačních technologií tak, aby organizace dosáhla svých cílů. Zaměřuje se rovněž na Organizační stránku IT. V této oblasti CobiT řeší otázky jako: • Jsou business a IT strategie ve vzájemném souladu? • Využívá organizace zdroje IT optimálně? • Jsou zmapována a řízena všechna rizika s IT spojena? • Jsou jasně definované cíle IT projektů a jsou tyto cíle všeobecně známé? • Odpovídá kvalita informačních systémů potřebám byznysu? 65

4. Metodiky a standardy pro podporu IT Governance Procesy domény: • Define a strategic IT Plan (definování strategie IT služeb) • Define the information architecture (definování informační architektury) • Determine technological direction (určení technologického směru) • Define the IT processes, organisation and relationships (definování IT procesů, organizace a vztahů) • Manage the IT investment (řízení IT investic) • Communicate management aims and direction (komunikace manažerských cílů a směrování) • Manage IT human resources (řízení lidských zdrojů v IT) • Manage quality (řízení jakosti) • Assess and manage IT risk (hodnocení a řízení IT rizik) • Manage projects (řízení projektů) 4.3.2.1.2 Acquire and Implement (pořízení a implementace) Doména se zabývá tím, jak nalézt vhodné IT řešení, ať už získané vlastními silami, nebo z vnějších zdrojů, pro realizaci IT strategie, která vznikla v předchozí doméně. Zabývá se implementací a integrací řešení se stávajícími systémy a procesy. Dále se doména pořízení a implementace zabývá sběrem IT požadavků, plánováním vývoje a údržby IT systému tak, aby společnost prodloužila životnost tohoto systému a jeho komponent. Je zde zahrnuto potřebné řízení změn v nových i stávajících systémech. V této oblasti CobiT řeší otázky jako: • Splní plánovaný IT projekt očekávaní a požadavky businessu? • Bude nový projekt dokončen v plánovaném čase? • Bude dodržen rozpočet projektu? • Bude nový systém pracovat po implementaci správně? • Neohrozí plánované změny fungování současných podnikových procesů? Procesy domény: • Indentify automated solutions (identifikace automatizovaných řešení) • Acquire and maintain application software (pořízení a údržba aplikačního software) 66

4.3. Úvod do CobiT (Control Objectives for Information and related Technology) • Acquire and maintain technology infrastructure (pořízení a údržba technologické infrastruktury) • Enable operation and use (umožnění operativity a používání) • Procure IT resources (zajištění IT zdrojů) • Manage changes (řízení změn) • Install and accredit solutions and changes (instalace a schvalování řešení a změn) 4.3.2.1.3 Delivery and Support (dodávka služeb a podpora) Doména řeší specifika dodávky informačních technologií a služeb. Zabývá se jak oblastí provozu aplikací v rámci IT systému, tak i podpůrnými procesy (například bezpečnost a školení), které umožňují efektivně a účelně tento systém používat. Doména se zaměřuje na řízení IT služeb, na jejich poskytování, na řízení bezpečnosti a kontinuity služeb, jejich podporu, dále na správu dat a potřebné infrastruktury. V této oblasti CobiT řeší otázky jako: • Jsou IT služby poskytovány v souladu s prioritami a potřebami businessu? • Jsou IT služby nákladově optimální? • Byli splněny všechny požadavky na důvěryhodnost, integritu a dostupnost IT služeb? Procesy domény: • Define and manage service levels (definovaní a řízení úrovně služeb) • Manage third-party services (řízení služeb třetích stran) • Manage performance and capacity (řízení výkonnosti a kapacity) • Ensure continuous service (zajištění kontinuity služeb) • Ensure systems security (zajištění bezpečnosti systémů) • Identify and allocate costs (identifikace nákladů a alokace financí) • Educate and train users (školení a trénování uživatelů) • Manage service desk and incidents (řízení service desku a incidentů) • Manage the configuration (řízení konfigurací) • Manage problems (řízení problémů) 67

4. Metodiky a standardy pro podporu IT Governance • Manage data (řízení dat) • Manage the physical environment (řízení fyzického prostředí) • Manage Operations (řízení provozu) 4.3.2.1.4 Monitor and Evaluate (monitorování a hodnocení) Doména se zabývá tím, jak ověřit, zdali jsou současné IT systémy stále ještě v souladu s cíli organizace. Poskytuje nezávislý pohled na efektivitu systému a míru naplnění požadavků businessu při plánování kontrolních kritérií interního a externího auditu společnosti. Všechny IT procesy je potřeba neustále pravidelně monitorovat a vyhodnocovat. Je tedy nutné kontrolovat jejich výstupy, zdali jsou v požadované kvalitě a zda splňují definovaná kontrolní kritéria. V této oblasti CobiT řeší otázky jako: • Je výkonnost IT pravidelně měřena tak, aby se případné problémy odchytily a řešily dřív, než skutečně nastanou? • Je systém interních kontrol efektivní a úplný? • Jsou měřeny a reportovány všechna rizika, kontroly a výkonnost? Procesy domény: • Monitor and evaluate IT performance (monitorování a ohodnocování výkonnosti IT) • Monitor and evaluate internal control (monitorování a ohodnocování vnitřní kontroly) • Ensure compliance with external requirements (zajištění shody s externími požadavky) • Provide IT Governance (poskytování IT Governance)

4.4 4.4.1

Srovnání metodik Srovnání ITIL vs. ISO 20000

(použitá literatura: [4], [5]) ITIL a ISO 20000 jsou si velmi blízký. ISO 20000 z ITILu vychází a ve svých doporučeních se na něj odkazuje. ISO 20000 popisuje „co“ musí organizace splňovat s odkazem na knihovnu ITIL, která říká „jak“ toho dosáhnout. ISO 20000 je v podstatě standard, ve kterém jsou shrnuty základní postupy ITILu do standardizovaných kritérií, podle kterých lze úroveň služby plánovat, zavádět, a také posuzovat, srovnávat, případně i certifikovat. První publikace ISO 20000 specifikuje požadavky, které musí být splněny, aby 68

4.4. Srovnání metodik mohla být daná organizace certifikována. Druhá publikace obsahuje rady a návody pro management organizace a odkazuje se na ITIL. ITIL obsahuje "best practice"rady a návody pro IT management organizace, respektive providera IT služeb a přesněji definuje a popisuje procesy. ISO 20000 tedy v podstatě není přímo metodika, ale standard, který slouží k certifikaci organizací. Vztah ITILu a ISO 20000 ukazuje následující diagram:

Obrázek 4.8: Vztah ITIL a ISO 20000 [21] Rozdílem mezi ITILem a normou ISO 20000 je také fakt, že pokud chce být organizace certifikována dle ISO 20000, musí zavést všechny procesy uvedené v první části normy, kdežto v ITILu se organizace může inspirovat a zavést pouze některé vybrané části. Dle ISO lze certifikovat organizaci jako celek, zatímco podle ITIL jsou certifikováni výhradně jednotlivci.

4.4.2

Srovnání ITIL vs. CobiT

(použitá literatura: [4], [5], [12]) CobiT je metodika pro řízení IT z pozice top-managementu, zatímco ITIL je nástrojem IT managementu neboli řízení IT z pozice CIO. CobiT prezentuje činnost IT vůči okolí, které nemá znalosti o IT. Záběr metodiky COBIT je tedy širší než záběr ITILu: například ITIL neobsahuje oblast řízení lidských zdrojů, zatímco COBIT ano. ITIL a CobiT se navzájem nevylučují, ale doplňují - existují podniky, které deklarují, že mají zavedeny procesy ITSM podle ITILu, jakož i podle CobiTu 69

4. Metodiky a standardy pro podporu IT Governance => procesy ITILu jsou pak většinou používány pro operativní a taktické řízení, zatímco CobiT je používán jako nástroj strategického řízení a auditu. ITIL je totiž s procesy podle CobiTu kompatibilní - jednotlivé procesy i dílčí kontrolní cíle CobiTu lze přehledně mapovat na jednotlivé procesy, resp. aktivity ITILu. Na úrovni procesů však toto mapování není ve vztahu 1:1, ani 1:n, avšak m:n, což tedy znamená, že jisté množině procesů v CobiTu odpovídá jistá množina procesů v ITILu. CobiT je zaměřen na měření výkonnosti – podporuje rozhodování o způsobu měření a kontrolování podnikového IT. Právě to je výhoda CobiTu oproti ITILu, který se principům auditu příliš nevěnuje. CobiT má oproti ITILu jednu zdánlivou výhodu, a to tu, že všechny publikace CobiTu, kromě jediné, jsou k dispozici volně ke stažení na internetu (6 ze 7 publikací COBIT je zcela zdarma), zatímco publikace ITIL se musí kupovat (a na tuzemské poměry nejsou zrovna nejlevnější). Tato výhoda je ale opravdu jen zdánlivá, protože CobiT, na rozdíl od ITILu, nevzešel z praxe, ale je produktem několika profesionálních auditorských společností, což je na jazyku a srozumitelnosti CobiTu podstatně znatelné. Takže implementace procesů CobiTu je oproti ITILu mnohem složitější, a procesy CobiT jsou pro lidi z IT praxe podstatně méně "čitelné"než jasné a přehledné procesy ITILu. V následující tabulce je uveden přehled rozdílů COBIT a ITIL podle vybraných kritérií:

obsah popis procesů cílové pracovní pozice implementace dostupnost

CobiT všechny aspekty IT managementu pouze identifikace procesů a vymezení jejich cílů auditoři a vrcholový manažeři z vně IT oddělení komplikovaná, nutné vymyslet konkrétní procesy 6 ze 7 publikací jsou zdarma ke stažení z internetu

ITIL pouze management IT služeb a IT infrastruktura obsahuje komplexní rámec pro definici procesů a mnoho příkladů IT manažeři a ostatní IT odborníci relativně jednoduchá, rámec procesů je dán k dispozici pouze placené knihy a HTML verze na cd

Tabulka 4.1: ITIL vs. CobiT Na závěr bych rád zdůraznil, že využití a zavedení metodologií typu ITIL, COBIT apod. je pouze prvním krokem k optimalizaci správy a řízení informačních a telekomunikačních technologií. Podstatnou podmínkou úspěchu využívání těchto metodik je jejich správné přizpůsobení pro konkrétní prostředí (jak jsem sám zjistil - viz následující kapitola) a následně důsledné dodržování a kontrola zavedených procesů. Pokud jsou i tyto aspekty implementace 70

4.4. Srovnání metodik metodik úspěšně aplikovány, umožní to nejen ještě více zefektivnit využívání stávajících technologií a zdrojů, ale při spolupráci se zákazníky také dosáhnout významných úspor, zvýšení spolehlivosti a v neposlední řadě také flexibility celého systému řízení IT.

71

Část II

praktická ukázka aplikace vybraného standardu

73

4.4. Srovnání metodik Nyní následuje případová studie, ve které si ukážeme praktickou ukázku návrhu procesů metodiky ITIL. ITIL jsem si pro ukázku zvolil, neboť je světově nejrozšířenější. Navíc je zaměřen přímo na procesy IT oddělení a poskytovatelů IT služeb, kdežto, jak z výše uvedeného vyplývá, CobiT a ISO 20000 jsou spíše pro vrcholový management firem. Případová studie je obecně analýza nějakého jevu a jeho vlivu na okolí 2 . Cílem této případové studie je tedy analýza nasazení vybraných procesů metodiky ITIL, kterou dělám pro firmu zabývající se tvorbou IT a telco řešení. Za vliv na své okolí považujme v tomto kontextu zejména přínosy a náklady, které budou analyzovány na konci této studie. Zmíněná firma se zajímá o možnosti optimalizace svých procesů. Vzhledem k tomu, že se jedná o dodavatele IT řešení (i když se zaměřením na telco), ITIL může být ideálním řešením.

2

definice autora

75

KAPITOLA

Případová studie – implementace metodiky ITIL 5.1

Popis firmy

Tato případová studie se zaměřuje na firmu, která podniká v tvorbě ICT řešení, se zaměřením na operátory pevných i mobilních telekomunikačních sítí. Má mnohaleté zkušenosti ve spolupráci s předními ruskými i světovými společnostmi. Firma nabízí řešení, která dokáží plně pokrýt potřeby zákazníků, zefektivnit jejich aktivity a optimalizovat jejich business procesy. Firma zaměstnává přibližně tisíc zaměstnanců převážně v Rusku a v české republice. Vzhledem k tomu, že si zástupce firmy, se kterým budu konzultovat, nepřál zveřejnit žádné informace, budu dále tuto firmu nazývat ukázkovým dodavatelem. Mezi hlavní produkty a služby, které tato společnost nabízí patří: • hardware • služby pro telco operátory • analýza a návrh telco sítí (ICT infrastruktura, komunikační síť) • systémy pro řízení sítí • systémy pro podporu obchodních operací • fakturační systémy • systémy pro řízení vztahů s partnery a zákazníky 77

5

5. Případová studie – implementace metodiky ITIL • systémy pro řízení provozu • datové sklady • informační systémy • ERP (Enterprise Resource Planning) • CRM (Customer Relation Management) • BI (Business Intelligence) • EAM (Enterprise Asset Management) • EPM (Enterprise Performance Management) • ECM (Enterprise Content Management) • ERM (Enterprise Risk Management) • systémy pro řízení profitability • systémy pro strategické plánování • systémy pro finanční řízení • portálová a integrační řešení • podpora nabízených produktů s služeb

Nyní se podíváme strukturu této firmy. Ta je zobrazena na následujícím obrázku. 78

5.1. Popis firmy

Obrázek 5.1: struktura ukázkového dodavatele IT služeb Jak je vidět na obrázku, firma je rozdělena na šest hlavních oddělení. Tyto oddělení mají dále pododdělení. Například v oddělení Services (služby) vidíme pododdělení IT, správy (administration), financí a lidských zdrojů (Human Resources). Pro nás je důležitých zbylých pět oddělení. Na ty se podíváme podrobněji, abychom si ukázali, jak tato firma funguje z hlediska businessu. Oddělení Sales and KAM (Key Account Management) má na starosti vyhledání nových zákazníků, péči o stávající zákazníky a tvorbu obchodních případů. To znamená, že propagují firmu navenek, konzultují se zákazníky nabízené služby a produkty a předkládají podmínky a parametry poskytovaných služeb, produktů a servisní podpory. Oddělení vývoje (Development dept.) tvoří dvě pododdělení. První se zabývá návrhem a vývojem hardwaru a tvorbou nízkoúrovňového softwaru (firmware). Výstupem jsou výrobní dokumentace, které se předají oddělení výroby (Production dept.), aby daný hardware, dle potřeby, vyrobilo. Druhé pododdělení se zabývá tvorbou aplikačního softwaru, návrhem a tvorbou informačních 79

5. Případová studie – implementace metodiky ITIL systémů. Oddělení přechodu a integrace služeb (Service transition and integration dept.) má za úkol nasadit dané služby u určitého zákazníka a integrovat je do jeho ICT prostředí. Oddělení řízení služeb a technické podpory (Service management and technical support dept.) se skládá ze dvou pododdělení. Prvním je pododdělení technické podpory (Technical support) a má za úkol podporu a údržbu nasazených služeb. Plní funkci service desku a řeší incidenty a úpravy služeb u zákazníka. Druhým je pododdělení řízení služeb (Service management), které má za úkol řízení portfolia služeb nabízených konkrétním zákazníkům.

5.2

Výběr procesů ITILu

Než jsem mohl začít s implementací ITILu v této firmě, bylo nutné vybrat vhodné procesy a konzultovat je s někým z firmy. S někým, kdo ve firmě pracuje dostatečnou dobu, a tedy firmu dobře zná. Zároveň by měl být na dostatečně vysoké pozici, aby jím poskytnuté konzultace byly skutečně relevantní potřebám firmy. Jako konzultant byl vybrán zaměstnanec na pozici Network Solutions Department Director, který firmu velice dobře zná, neboť v ní pracuje již více než 15 let. Na svoji současnou pozici se vypracoval přes pozice: Programmer, Head of software development, Development department Director a Deputy of Network Solutions Director. Při konzultacích jsme probrali jednotlivé procesy ITILu a diskutovali jejich případný přínos pro firmu. Prošli jsme jednotlivá oddělení a zaměřili se na problémy a možná zlepšení, která by se v nich pomocí těchto procesů dala udělat. Konzultant zmínil zejména dvě potřeby, které by ITIL mohl vyřešit: 1. Nasazení služeb k zákazníkům je vedeno projektovými manažery, kteří ale vedou a plánují projekty zcela podle svého uvážení. To s sebou nese samozřejmě mnoho problémů, jako třeba fakt, že není zajištěna dostatečná komunikace s vedením firmy jak při plánování, tak při průběhu projektů, a mnoho dalších. Konzultant zmínil potřebu sjednocení procesu vedení a plánování těchto projektů. 2. Konzultant zmínil potřebu jasného definování procesu pro optimalizaci portfolia služeb pro jednotlivé zákazníky. Firma má katalog služeb, ze kterého si zákazníci mohou vybrat služby. Každý zákazník má však specifické požadavky na služby, někteří dokonce chtějí služby, které v katalogu nejsou. Tvorba nových služeb a úpravy ve službách jsou velmi nákladná záležitost. Proto by bylo dobré definovat proces, který by na základě analýzy požadavků zákazníka, jeho IT strategie a finančních možností vybral služby, které zákazník skutečně využije a přitom se tyto služby vyplatí dodavateli poskytovat. 80

5.2. Výběr procesů ITILu V ITILu odpovídají požadavkům konzultanta následující procesy: 1. Service Portfolio Management 2. Transition Planning and Support Podíváme se kam procesy patří, nejdříve z hlediska životního cyklu služby a kategorie (viz dále), a poté z hlediska struktury firmy. Typické fáze životního cyklu služby jsou následující [1]: 1. Requirements Je shromažďována a dokumentována množina požadavků na novou službu, či změnu ve službě existující od zákazníka. 2. Defined Požadavky jsou zpracovávány a tvoří se obchodní případ. 3. Analyzed Jednotlivé služby a jejich obchodní případy jsou ohodnocovány, analyzovány a prioritizovány. 4. Approved Jednotlivé služby jsou schvalovány. 5. Chartered Dochází k alokaci zdrojů. 6. Designed Služba a její komponenty jsou navrhovány. 7. Developed Služba a její komponenty jsou vyvíjeny. 8. Built Vyvinutá služba a její komponenty služby jsou sestavovány, kompilovány atd. dle typu služby. 9. Tested Služba a její komponenty jsou testovány. 10. Released Služba a její komponenty jsou nasazovány u zákazníka. 11. Operational Služba je v provozu. 81

5. Případová studie – implementace metodiky ITIL 12. Retire Služba byla odstavena. ITIL dělí služby do tří kategorií, dle toho, ve které fázi životního cyklu se nacházejí [26]: • Service Pipeline – Do této kategorie patří služby navrhované (v konceptuální fázi) a ve vývoji. • Service Catalogue – Do této kategorie patří služby aktuálně používané. Já je budu nazývat existující. • Retired Service – V této kategorii jsou služby vyřazené. Následují obrázek přiřazuje knihy ITILu jednotlivým fázím:

Obrázek 5.2: Fáze životního cyklu služby [1] Proces Service Portfolio Management souvisí s fázemi Defined, Analyzed, Approved a Chartered, proces Transition Planning and Support souvisí s fázemi Built, Tested a Released.

82

5.2. Výběr procesů ITILu Následující obrázek ukazuje vybrané procesy a oddělení, pro které jsou primárně určeny. Žlutě je označeno oddělení, se kterým souvisí proces Service Portfolio Management, modře pak oddělení, se kterým souvisí proces Transition Planning and Support.:

Obrázek 5.3: Procesy v rámci struktury firmy

Z obrázku je také vidět, že použití ITILu je v této studii zaměřeno na externího poskytovatele služeb, nikoli vlastní ICT oddělení firmy. Typický zákazník firmy je totiž telekomunikační společnost, která má svoje IT, ale vzhledem ke komplexnosti služeb, které IT oddělení musí společnosti dodávat, outsourcují větší část ICT dodavatelům. Tyto společnosti potřebují zejména vytvářet a spravovat telekomunikační sítě, informační systémy a další služby. ICT Governance zde tedy není pouze uvnitř zákaznických společností, ale je delegován i na našeho ukázkového poskytovatele ICT služeb. Jak je řečeno v kapitole ITIL verze 3, ITIL rozlišuje tři kategorie poskytovatelů ICT služeb: 83

5. Případová studie – implementace metodiky ITIL 1. Interní poskytovatel služeb: existuje v rámci organizace výlučně pro dodávku služeb pro jeden specifický podnikový útvar 2. Sdílený poskytovatel služeb: poskytuje služby více podnikovým útvarům v téže organizaci 3. Externí poskytovatel služeb: operuje jako externí poskytovatel služeb pro více zákazníků V rámci dělení dle ITILu by tedy tento poskytovatel služeb patřil do třetí kategorie.

5.3

Implementace ITIL procesů

Implementace procesu dle ITILu se skládá ze dvou, případně tří hlavních částí: 1. definice a přiřazení rolí dle ITILu pracovníkům 2. definice procesu 3. výběr a implementace podpůrné aplikace (pokud je potřeba) Procesy budu definovat a modelovat pomocí notace BPMN (Business process modeling notation). BPMN představuje současný standard pro modelování podnikových procesů. Jeho správu a další vývoj zajišťuje skupina Object managment Group (OMG), tvůrce řady důležitých modelovacích standardů, mezi které patří např. UML (Unified Modeling Language).

5.3.1

Proces Service Porfolio Management

Z pohledu procesu Service Portfolio Management, ukázková firma však není typický zástupce třetí kategorie. Typický externí poskytovatel služeb sleduje a analyzuje celkový trh se službami a snaží se nabízet takové portfolio služeb, o které bude na trhu co největší zájem (tj. pro co nejvíce zákazníků). V takovém případě se myšlenka IT Governance vytrácí, neboť spolupráce businessu a poskytovatele je mnohem menší než u prvních dvou typů poskytovatelů. Ukázková firma je však specifická v tom, že pro každého zákazníka optimalizuje portfolio na míru. Z hlediska SPM to znamená, že bude potřeba mnohem užší spolupráce se zákazníkem při řízení portfolia nabízených služeb a že bude portfolio řízeno pro každého zákazníka zvlášť. Cílem procesu Service Portfolio Management je zajistit, že poskytovatel má pro každého zákazníka ten správný mix služeb, který poskytne tomuto zákazníkovi maximální hodnotu při přiměřené investici. Proces se zabývá tím, jak by se portfolio poskytovaných služeb mělo vyvíjet do budoucna. Proces Service Portfolio Management má čtyři fáze [26]: 84

5.3. Implementace ITIL procesů Define: Na počátku procesu je potřeba shromáždit informace o všech existujících službách, stejně jako o všech službách v pipeline. Dále se shromáždí informace o nově požadovaných službách a požadovaných změnách ve stávajících službách. Pro každou položku se vytvoří, případně aktualizuje obchodní případ (business case). Obchodní případ je dokument, který slouží jako odůvodnění pro investování prostředků do dané služby. Hodnotí se v něm potencionální přínosy služby a zdroje potřebné pro poskytnutí a údržbu této služby. Výstupem této fáze tedy je, že máme validní informace a obchodní případy pro všechny služby, které by zákazník využíval, kdyby zdroje byly neomezené. Analyze: V této fázi dochází k vytvoření strategického záměru. To znamená, že se portfolio analyzuje. Aktivity v tomto procesu výstižně určí následující otázky: • Jaké jsou dlouhodobé cíle nás jako poskytovatele služeb danému zákazníkovi? • Které z definovaných (předchozí proces) služeb jsou potřeba, aby bylo cílů dosaženo? • Jaké zdroje jsou potřeba pro nasazení daných služeb? Jinými slovy, v tomto procesu se snažíme maximalizovat hodnotu portfolia a prioritizovat ho. Abychom mohli na zmíněné otázky odpovědět, musí být do procesu zapojeni vrcholový manažeři. Právě vrcholový manažeři jsou ti, kdo limitují zdroje. Proto musí znát nejen rizika daných služeb, ale i dopad služeb na chod firmy a další souvislosti. Díky tomu, že budou rozumět všem těmto vztahům, mohou učinit validní investiční rozhodnutí. Kvůli limitovaným zdrojům je potřeba portfolio optimalizovat. Důvod je jasný. Není možné například investovat veškeré zdroje do nových služeb. Kdyby se neinvestovalo do rozvoje a údržby stávajících služeb, staly by se tyto služby neefektivní a možná i nepoužitelné. Investice do služeb ITIL [26] dělí na tři základní kategorie, do kterých se rozdělí všechny definované služby: • RTB (Run The Business): Zde jsou investice, které se týkají udržení provozuschopnosti služeb. • GTB (Grow The Business): Zde jsou investice, jejichž účelem je rozšířit, či nějakým způsobem vylepšit stávající služby v organizaci. • TTB (Transform The Business): V této kategorii jsou investice do zcela nových, dosud nevyužívaných služeb. Tyto kategorie jsou dále členěny na podkategorie podle alokace rozpočtu: 85

5. Případová studie – implementace metodiky ITIL • RTB: – Core: Část rozpočtu věnovaná údržbě kritických služeb. – Non-discretinary: Část rozpočtu věnovaná údržbě ostatních, existujících služeb. • GTB: – Discretionary: Část rozpočtu věnovaná vylepšení stávajících služeb. – Growth: Část rozpočtu věnovaná rozšíření stávajících služeb. • TTB: – Venture (v překladu podstoupení rizika): Je to část rozpočtu, která je alokována na rozšíření portfolia služeb, tj. vytvoření zcela nových služeb. Proto se kategorie jmenuje Venture – investujeme do úplně nové věci - podstupujeme největší riziko. Po rozdělení služeb se portfolio analyzuje a vyberou se služby a změny, které se budou eventuálně nasazovat (zatím se jedná o návrh Portfolio Managera viz Dále). Služby se poté prioritizují. Jak portfolio prioritizovat? Každé nové službě, či změně se přiřadí hodnota, která bude rozhodovat o tom, které služby a změny se budou implementovat dříve, a které později. ITIL žádný rámec pro takovouto prioritizaci nenabízí, a proto musím stupnici priorit definovat sám. Je potřeba mít dostatek možných hodnot, aby bylo možné jasně určit, které služby a změny se mají implementovat dříve, nebo později. Proto myslím, že deset hodnot, tedy 1, 2 ,.., 10 je pro náš případ optimální. Službám se tedy přidělí hodnota v tomto rozsahu a to tak, že čím vyšší hodnota, tím vyšší priorita. Approve: V předchozích fázích jsme vzali veškeré služby, které bychom chtěli, analyzovali je, vybrali potřebné služby a rozdělili je do kategorií. V tomto procesu dochází k závěrečné fázi optimalizace portfolia, a to výběru a schválení služeb, které, vzhledem k omezeným zdrojům, budeme skutečně implementovat, a schválení zdrojů k tomu potřebných. Zároveň se v tomto procesu kategorizují existující služby do šesti kategorií, podle toho, jak s nimi bude dále nakládáno: • Retain (uchovat): Sem zařadíme služby, které jsou v souladu se strategií a jsou na odpovídající technické a funkční úrovni. Služby v této kategorii tedy není třeba nijak měnit. • Replace (nahradit): Do této kategorie zařadíme služby, které mají nejasnou, či neodpovídající funkčnost a nepodporují tedy dostatečně business procesy. 86

5.3. Implementace ITIL procesů • Rationalize (racionalizovat): Může se stát, že poskytovatel služeb poskytuje několik verzí stejného operačního systému několik verzí stejného softwaru, nebo poskytuje několik systémů s podobnou funkcionalitou. Do této kategorie zařadíme veškeré služby, kterých se tyto případy týkají. • Refactor (refaktorovat): Do této kategorie zařadíme služby, které splňují technická a funkční kritéria, ale mají nějaké nedostatky z hlediska procesního, či z hlediska systémových hranic. Například může jít o službu, která si autentizaci řeší sama. Tyto služby je tedy potřeba refaktorovat tak, aby obsahovali pouze hlavní funkcionalitu, ke které je služba určena. A zbytek funkcionality může řešit jiná služba (jako autentizaci do systému). • Renew (obnovit): Do této kategorie patří služby, jejichž funkcionalita je potřebná a chceme ji zachovat, ale služba sama je technicky nevyhovující. • Retire (ukončit): V této kategorii budou služby, které již nesplňují technické a funkcionální požadavky. Charter: Nyní je potřeba vše realizovat. ITIL radí nejdříve vytvořit soupis všech rozhodnutí a akcí, které bude potřeba udělat. Tyto rozhodnutí a akce budou dále srozumitelně a jednoznačně diskutovány se zákazníkem. Očekávané ceny služeb musí být zahrnuty do finančních prognóz a očekávaná pracnost služeb musí být zahrnuta do plánů zdrojů. Nově navržené služby budou předány vývojovému oddělení (dle ITILu se předají do druhé části životního cyklu – Service Design). Začneme nejprve definicí rolí dle ITILu [26], které jsou v tomto procesu důležité. Na straně zákazníka je to CIO, tedy manažer informatiky, který má dostatečné pravomoci a je součástí vrcholového managementu. Na straně dodavatele to budou následující pozice: • Business Relationship Manager (BRM) BRM je zodpovědný za identifikování potřeb zákazníka (nejedná se o sběr požadavků, za to je zodpovědná role Demand Manager definovaná níže) a zajištění pokrytí jeho potřeb odpovídajícím portfoliem služeb. Tito manažeři vytvářejí silný vztah se zákazníkem tím, že rozumí businessu zákazníka a jeho výstupům. Právě proto v procesu SPM vytváří obchodní případy pro jednotlivé služby. • Product Manager (PM) Produktoví manažeři přebírají odpovědnost za rozvoj a správu služeb během jejich životního cyklu a mají odpovědnost za produkční kapacitu, 87

5. Případová studie – implementace metodiky ITIL plánované služby (service pipeline) a ty služby, řešení a balíky, které jsou prezentovány v katalozích služeb. • Chief Sourcing Officer (CSO) CSO je specialistou pro strategii zdrojů v organizaci. • Demand Manager (DM) DM, tedy manažer požadavků, je zodpovědný za předvídání, porozumění a ovlivňování požadavků zákazníka. Tato role patří zejména do procesu Demand Management, ale v tomto procesu bude potřeba výstupů jeho práce jako vstupu do procesu. • Service Portfolio Manager Service Portfolio Manager je zodpovědný za produktové portfolio služeb pro jednotlivé zákazníky a celkově za proces Service Portfolio Management – je vlastníkem procesu. • Service Strategy Manager (SSM) SSM je zodpovědný za celkovou strategii služeb. V procesu SPM jej bude potřeba ve fázi Approve, aby odsouhlasil návrh portfolia, které Portfolio Manager navrhl. Bude jej potřeba rovněž ve fázi Analyze, kde musí určit, které z požadovaných služeb a změn jsou v souladu se strategií dodavatele a které ne (například může jít o požadavek na službu, kterou dodavatel neposkytuje a ani to nemá v plánu). • IT Financial Manager (IFM) IFM řídí finanční stránku dodavatele služeb. Vzhledem k tomu, že každá nová i pozměněná služba znamená investici, bude v procesu SPM nepostradatelnou součástí. Nyní, když máme definovány role, můžeme začít s návrhem procesu Service Portfolio Management. Ten je zobrazen na následujícím obrázku:

88

5.3. Implementace ITIL procesů Proces využívá informací ze softwaru nazvaném Service portfolio management system. Tím se dostáváme ke třetí části implementace procesu ITILu a to nástrojům pro podporu procesu. Po definování rolí a vypracování procesu se pokusím najít na trhu software, který by proces náležitě podporoval. Jako vhodného zástupce takového softwaru jsem vybral produkt od firmy Planview. Systém se jmenuje Enterprise Service Portfolio Management. Systém má veškerou funkcionalitu, kterou ukázkový poskytovatel služeb potřebuje. Má nástroje pro finanční management, optimalizaci portfolia, řízení katalogu služeb, dále má vizuální pomůcky jako dashboardy, umožňuje řízení pracovních zdrojů, podporuje řízení úrovně služeb (service level management) a v neposlední řadě má nástroje pro řízení požadavků (demand management).

5.3.2

Proces Transition Planning and Support

Cílem procesu Transition Planning and Support je naplánování projektu přechodu služeb, tedy zajistit koordinaci zdrojů pro nasazení služeb do reálného provozu při stanovených nákladech, ve stanoveném čase a při maximální možné kvalitě. Některé zdroje nazývají proces Project Management, což je dle mého názoru dosti výstižné, neboť přechod služeb se dá velice dobře plánovat jako projekt a já k procesu také budu tímto způsobem toho přistupovat. Poté, co byly služby vybrány v oddělení managementu služeb (oddělení zodpovědné za strategii služeb), navrženy a vyvinuty v oddělení vývoje, jsou nyní, ve formě Service Design Package (SDP) připraveny pro oddělení plánování a integrace. SDP (v překladu něco jako balíček zkonstruované služby) obsahuje následující informace, které vyžaduje projektový tým pro přechod služeb: • příslušné balíčky, ze kterých se skládá daná služba • specifikace služby • dokumentace, architektura, design služby • detailní postup sestavení a integrace komponent služby • způsob nasazení služby • akceptační kritéria služby Vstupem do procesu jsou: • SDP • RFC (request for change) – žádost o provedení změny, opravňuje projektového manažera využít zdrojů firmy pro nasazení dané služby. Výstupem procesu je: 89

5. Případová studie – implementace metodiky ITIL • plán pro přechod služeb • kontrola přechodu služeb a prezentační vrstva (reporting) ITIL sám neposkytuje detaily všech aspektů projektového managementu. Místo toho zdůrazňuje nejdůležitější aktivity projektování přechodu služeb a doporučuje využití některé projektové metodiky jako jsou PRINCE2, PMBoK nebo IPMA. [27] Stejně jako předchozí proces, i proces Transition Planning and Support lze rozdělit na fáze. Protože se vlastně jedná o fáze na projektu, použiji při jejich názvech projektovou terminologii. ITIL [27] tyto fáze nazývá trošku jinak, ale jejich náplní je totéž. Zahájení projektu: V této fázi projektování přechodu služby by měly být stanoveny organizační aspekty projektu a měly by být alokovány potřebné zdroje. Konkrétně by měly být zváženy a zajištěny následující aspekty: • Přínos a cíl projektu • Platné standardy (interní a externí), dohody týkající se přechodu služeb, právní, regulační a smluvní požadavky • organizace a osoby, kterých se projekt týká (stakeholders): – – – –

třetí strany, strategičtí partneři, dodavatelé zákazníci / uživatelé management a další

• politiky a praktiky firmy • využití zkušeností a znalostí z minulých projektů (zejména pro odhady) • kritéria úspěšnosti a neúspěšnosti projektu • požadavky na prostředí, prostory, organizaci a techniku u zákazníka • odhad nákladů a potřebných zdrojů a na jeho základě zajištění projektového týmu, určení rolí a organizace na projektu • zdokumentování rizik, omezení a předpokladů, které se týkají projektu • způsob kontroly projektu: – určení KPI (Key Performance Indicator), tedy ukazatelů výkonnosti projektu. Mezi základní, používané vždy, patří: ∗ odchylka od rozpočtu ∗ odchylka od časového plánu 90

5.3. Implementace ITIL procesů • reportování a komunikační plán • výstupy projektu a na jejich základě hrubý plán aktivit • zajištění financování a rozpočet V této fázi využijeme metodu logického rámce [20]. Ta umožňuje v rámci projektu definovat cíle a stanovit konkrétní aktivity k jejich řešení a současně identifikovat a analyzovat rizika, předpoklady a možné problémy. Rizika je však potřeba sledovat po celou dobu projektu a neustále je analyzovat. Proto projektový manažer bude udržovat jejich dokumentaci zvlášť. Vhodné je použít metodu RIPRAN (Risk Project Analysis), ve které se zachycuje nejenom dané riziko, ale i jeho pravděpodobnost, dopad a možné činnosti pro mitigaci daného rizika, případně reakci na riziko, pokud nastalo. Plánování projektu Při plánování přechodu služeb se naplánují jednotlivé aktivity a zdroje pro celý projekt. V SDP vytvořeném v oddělení vývoje je prvotní plán nasazení služby. Tento plán je potřeba nyní rozplánovat více do detailu. Aktivity nasazení služby by měly být rozplánovány na etapy, protože detaily nasazení ještě nemusí být známy. To znamená, že danou službu bude poskytovatel dodávat po logicky celistvých částech, kde dodání každé části je jakýsi podprojekt – etapa a postupem času se plán každé etapy zpřesňuje. Při plánování projektu nebudou tedy rozplánovány aktivity úplně do detailu, ale budou vytvořeny pracovní balíky, které si poté rozplánuje příslušný člověk, zodpovědný za daný pracovní balík. Výborně pro tento účel poslouží metoda Work Breakdown Structure (WBS) [20], což je Hierarchický rozpad cíle projektu na jednotlivé produkty a podprodukty až na úroveň jednotlivých pracovních balíků, které musí být v průběhu projektu realizovány. Když projektový manažer vytvoří WBS, může použít produkty a podprodukty vznikající při projektu jako etapy a zároveň vytvořil jednotlivé pracovní balíky. Po vypracování WBS bude vypracována síťová analýza [20], což je metoda na zobrazení logické návaznosti jednotlivých činností (pořadí, závislosti, souběžnost). Na základě vzniklého grafu určujeme kritickou cestu - tj. souslednost činností, jejichž trvání přímo ovlivňuje celkový termín projektu. Díky tomu je projektový manažer schopen odhadnout nejdřívější možný čas dokončení projektu. Aby mohla být provedena síťová analýza, musí být jednotlivým aktivitám (pracovním balíkům) přiděleny pracovní zdroje a časová náročnost. Následně projektový manažer vytvoří Ganttův diagram [20], což je jednoduše řečeno grafické znázornění průběhu činností v čase (souběžnost a návaznost). Veškeré informace, které projektový manažer pro jeho vytvoření potřebuje jsou v již vytvořeném WBS a v síťové analýze. 91

5. Případová studie – implementace metodiky ITIL Při plánování projektu jsou zajištěny následující aspekty přechodu služby: • pracovní prostředí a infrastruktura pro přechod služby • plán milníků, data dodání a předání • plán aktivit a úkolů, které se mají vykonat • pro každou etapu musí být určeny: – zdroje (pracovní i materiálové) – rozpočet – časové rozmezí • možné problémy a rizika, která se mohou naskytnout Takto vytvořený plán se nechá schválit všemi relevantními stranami (management zákazníka, klíčový uživatelé, vlastní management). Předchozí dvě fáze se provedou na počátku projektu přechodu služby. Účelem následujících dvou fází je podpořit (support) nasazování služby u zákazníka. Tyto dvě fáze tvoří podproces, který se bude opakovat po celou dobu projektu přechodu služby až do ukončení projektu. Kontrola a usměrňování projektu Cílem této fáze je monitorovat postup projektu, využívání zdrojů, usměrňovat projekt a provádět nápravné akce, když je potřeba. Projektový manažer musí mít neustálý přehled nad projektem, dalším postupem a v neposlední řadě riziky. V určitých milnících musí provést analýzu postupu projektu. To znamená zejména zjištění zda se projekt přechodu drží plánu, jaké jsou časové odchylky, či odchylky od rozpočtu. Zároveň kontroluje stav zdrojů – vytíženost zdrojů, zajištění zdrojů pro jednotlivé aktivity (některý pracovník může odejít uprostřed projektu nebo onemocnět atd.). Reportování a komunikace S předchozí fází úzce souvisí nutnost reportovat co se děje všem relevantním stakeholderům. Důležitost reportování je natolik důležitá, že jsem jej vyčlenil jako další fázi, i když se vlastně nejedná o fázi jako takovou. Aktivity spjaté s reportováním jsou prováděny ve všech fázích projektu. Jsou součástí podprocesu kontroly a usměrňování projektu, jsou součástí plánu komunikace, který projektový manažer vytvořil při zahájení projektu. Navíc se během projektu objevují nové a nové záležitosti, které je potřeba komunikovat, ať už v rámci projektového týmu, nebo se stakeholdery jako jsou manažeři, zákazník, nebo třeba i pracovníci z vývojového oddělení, je-li potřeba něco objasnit, atd. Zůstanu-li u termínu fáze, je Reportování a komunikace fází, která se prolíná všemi ostatními fázemi projektu. 92

5.3. Implementace ITIL procesů

Obrázek 5.4: Průběh komunikace na projektu

Začneme opět nejprve definicí rolí, potřebných při procesu Transition Planning and Support [27]: • Project Manager Projektový manažer je zodpovědný za naplánování projektu, zajišťování zdrojů a koordinaci projektu tak, aby byl projekt dokončen v rámci dohodnuté ceny, v dohodnutém čase a při maximální možné kvalitě. • Change Manager Change Manager je zodpovědný za kontrolu životního cyklu změn. Jeho úkolem je řídit změny tak, aby měly minimální negativní dopad na IT služby. Tato role je hlavní součástí procesu Change Management. Nasazování služby je samozřejmě dosti zásadní změna, takže bude zapojen i do procesu Transition Planning and Support. • Release Manager Release Manager je zodpovědný za plánování a kontrolu přesunu služby na testovací prostředí a poté na reálné prostředí. Po naplánování celkového přechodu služeb projektovým manažerem (Project Manager), release manager rozplánuje do detailů aktivity spojené s migrací služby na jednotlivá prostředí. Reportuje projektovému manažerovi. Naopak je nadřízeným role Test Manager a přechodně (pouze pro tento projekt) role Change Manager. • Test Manager Test Manager zajišťuje, že služba splňuje očekávání zákazníka. Je zodpovědný za otestování služby a za vedení testovacího týmu. Organizační strukturu ukazuje následující obrázek: 93

5. Případová studie – implementace metodiky ITIL

Obrázek 5.5: Organizace na projektu Výše uvedené role jsou určeny ITILem. Pro ukázkovou firmu je však potřeba přidat ještě jednu roli. • Line Manager (liniový manažer) Když chce projektový manažer nějaký pracovní zdroj, rezervuje si příslušný počet člověkohodin, resp. člověkodní příslušného liniového manažera. Ten vede tým lidí určité specializace (např. programátoři, databázový specialisté,..) a snaží se optimalizovat jejich pracovní vytížení. Projektový manažer tedy nemusí řešit vytížení jednotlivých pracovníků, pouze musí vědět kolik času bude potřebovat u jakých specializací pracovních zdrojů. Nyní následuje definice procesu Transition Planning and Support. Tento proces bude, na rozdíl od procesu Portfolio Management, rozdělen na dva podprocesy. První dvě fáze budou součástí prvního podprocesu, který jsem nazval Project Planning, třetí a čtvrtá fáze budou součástí druhého podprocesu, který jsem nazval Project Monitoring. Na následujícím obrázku je definován proces Project Planning:

94

5.3. Implementace ITIL procesů Na následujícím obrázku je definován proces Project Monitoring:

95

5. Případová studie – implementace metodiky ITIL

96

Obrázek 5.6: Project Monitoring

5.4. Metriky implementace ITIL procesů Nástroji pro řízení projektů jsou jednak aplikace klasického kancelářského balíčku, zejména tabulkový procesor jako např. Excel. A jednak Project Management System (PMS). Produktů PMS je na trhu mnoho a spousty z nich jsou velmi kvalitní. Některé jsou dokonce poskytované v cloudu. Pro potřeby procesu Transition Planning and Support jsem vybral zřejmě nejznámějšího zástupce v kategorii softwaru pro řízení projektů – Microsoft Project Professional.

5.4

Metriky implementace ITIL procesů

Než začne firma implementovat jakékoli procesy ITILu, je potřeba provést analýzu přínosů a nákladů. Až ve chvíli, kdy je evidentní, že přínosy implementace procesů převáží nad náklady, může vrcholový management firmy dát projektu zelenou. Přínosy každého implementovaného procesu je potřeba měřit pomocí určitých měřitelných ukazatelů – metrik. V případě procesu Transition Planning and Support určuje klíčové metriky ITIL sám a na implementátorovi je definovat význam a způsob měření těchto metrik. Pro proces Servis Portfolio Management však žádné konkrétní metriky neurčuje a nechává tedy definici metrik na implementátorovi procesů. Metriky pro proces Service Portfolio Management tedy musím určit a definovat sám. Bude rovněž potřeba trošku množinu metrik procesu Transition Planning and Support, vzhledem k potřebám ukázkového dodavatele služeb. Pro tento proces přidám některé metriky, které jsou potřeba navíc od množiny metrik určených ITILem. Jak bylo řečeno v kapitole o ITILu, každý proces má svého vlastníka, který je za daný proces zodpovědný a to včetně měření jeho výkonnosti. Je tedy zodpovědný za provádění měření dle definovaných metrik a za vyhodnocování výsledků. Vlastníkem procesu Service Portfolio Management je zaměstnanec, jemuž bude v rámci tohoto procesu přiřazena dříve definovaná role Service Portfolio Manager. U procesu Transition Planning and Support to však není tak jednoduché. Ač se proces týká zejména projektových manažerů, vzhledem k tomu, že jich je více, nelze zvolit jednoho jako vlastníka procesu. Tím musí tedy být někdo z jejich nadřízených. V ideálním případě přímý nadřízený, zaměstnanec plnící roli manažera projektového portfolia. U každé metriky uvádím její název, popis, způsob měření, cílový stav, reakci v případě nedosažení cílového stavu a konkrétní přínosy plynoucí z dosaženého cílového stavu metriky pro dodavatele a pro zákazníka. Důvod proč udávám i přínosy pro zákazníka je ten, že každá výhoda pro zákazníka znamená jeho větší spokojenost a vyšší loajálnost vůči dodavateli. Manažeři dodavatele by se proto měli o přínosy pro zákazníka zajímat také. Zmíněné reakce v případě nedosažení cílového stavu je potřeba uvést již nyní před samotnou implementací, neboť v případě, že nebude cílového stavu 97

5. Případová studie – implementace metodiky ITIL dosaženo, je potřeba zjistit, zda je na vinně samotný proces. Pokud ano, musí vlastník procesu učinit nápravná opatření. Pokud by se nedařilo dosáhnout požadovaného výsledku nadále i přes učiněná opatření, bude nutné navrhnout proces znovu (zodpovědnost za nedosažení výsledků bych měl já, jako navrhovatel procesu). Měření výkonnosti procesů bude probíhat tak, že příslušní pracovníci (Service Portfolio Manager, respektive Project Manager) budou zaznamenávat dané hodnoty (napsané ve způsobu měření u každé metriky) a vlastník procesu bude výsledky ve čtvrtletním intervalu vyhodnocovat a implementovat předepsanou reakci v případě, že nebylo dosaženo očekávaných hodnot (cílového stavu).

5.4.1 5.4.1.1

Metriky procesu Service Portfolio Management Poměr služeb iniciovaných dodavatelem

Popis metriky: Díky procesu bude moci ukázková firma schopna nabízet zákazníkům služby přesně na míru, v souladu se strategií jejich ICT a finančními možnostmi. Měl by tedy významně stoupnou počet služeb, které zákazníci přijali na základě návrhu dodavatelské firmy, tedy po analýze obchodních procesů zákazníka a zákazníkových potřeb. Před implementací tohoto procesu je většina služeb iniciována zákazníkem, který si o ně musí říct. Od implementace procesu by se však situace měla změnit a značnou většinu služeb by měl určit sám dodavatel, zákazník bude pouze součástí schvalovacího procesu. Způsob měření : Jak se pozná služba, která je iniciována dodavatelem? Budeme za ni považovat právě takovou službu, která byla iniciována v procesu Service Portfolio Management (tedy každá, kterou si zákazník nemusel přímo vyžádat, ale byla navržena na základě analýzy požadavků a potřeb zákazníka). Cílový stav: Cílovým stavem je, aby poměr počtu služeb iniciovaných dodavatelem dosáhl nejméně 80 Reakce v případě nedosažení cílového stavu: Nebude-li dosaženo daného procenta služeb iniciovaných dodavatelem, může to znamenat, že je chyba v procesu, ale také nemusí. Vlastník procesu, tedy Service Portfolio Manager musí zjistit, proč si zákazník musel o některé služby říci sám. To zjistí tak, že se podívá, zdali se služby, o které zákazník požádal přímo, zamítly v procesu Service Portfolio Management, či zda se vůbec do procesu nedostaly. Pokud byly služby většinově zamítnuty v procesu (tj. Business Relationship Manager je navrhl, ale služba se zamítla v průběhu procesu) navrhne nápravná opatření (nyní je nelze konkretizovat) a tyto opatření do procesu zavede. 98

5.4. Metriky implementace ITIL procesů Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem pro dodavatele je fakt, že bude díky procesu schopen lépe plánovat zdroje a investice, neboť bude služby sám navrhovat a plánovat jejich nasazení. Znamená to zejména ušetření nákladů na vývoj nových služeb a úpravy nasazených služeb. Například vytvořit novou službu stojí nemalé náklady. Díky tomu, že dodavatel sám navrhuje portfolio zákazníkovi, může zjistit, zda o danou službu budou mít zájem i další zákazníci a tedy určit zda se investice do vývoje služby vyplatí (jinak by musel buď odmítnout službu poskytnout, nebo riskovat, službu vyvinout a doufat, že si o ni řeknou ještě další zákazníci). Dá se očekávat ušetření až 30% nákladů spojených s dodávkou služeb pro zákazníky (těch nákladů, které vznikají v důsledku nemožnosti efektivně plánovat). Přínos v případě dosažení cílového stavu pro zákazníka: Díky tomu, že portfolio služeb pro zákazníky bude z většiny v rukou dodavatele, bude moci dodavatel portfolio lépe optimalizovat. Zákazník tak díky procesu bude mít vyvážený mix služeb za peníze, které si muže dovolit na IT vydat. 5.4.1.2

Průměrná rychlost reakce na požadavky

popis metriky: Zavedením procesu by se měla zvýšit rychlost reakce na požadavky zákazníka, které se týkají tvorby nových služeb, či změn ve službách nasazených. Díky zavedení tohoto opakujícího se procesu budou požadavky (shromažďované manažerem požadavků (Demand Manager)) neustále analyzovány, na základě těchto analýz budou definovány konkrétní služby (v procesu toto provádí Business Relationship Manager), o kterých se v průběhu procesu Service Portfolio Management rozhodne, jak s nimi bude dále nakládáno – buď jsou schváleny a vzniká tak nová služba v pipeline, nebo schváleny nejsou. Každopádně zákazník se bude rychleji dozvídat, které služby byly schváleny a tedy, které požadavky budou uspokojeny. Způsob měření: Změřit rychlost reakce na požadavek od zákazníka je jednoduchý úkol. Budeme počítat dobu od vyslovení požadavku (jakým způsobem požadavky dodavatel přijímá je opět na manažerovi požadavků) do odezvy, tedy, v případě mnou navrženého procesu Service Portfolio Management, do odsouhlasení portfolia CIO zákazníka. V tu chvíli již bude rozhodnuto, jestli konkrétní požadavek pokryje některá nová služba, či změna, která bude implementována. Cílový stav: Cílový stav je takový, že průměrná doba odezvy na požadavek je méně než dva týdny. Reakce v případě nedosažení cílového stavu: V případě příliš dlouhé prodlevy je nutné celý proces zrychlit. To by znamenalo, že by vlastník pro99

5. Případová studie – implementace metodiky ITIL cesu musel stanovit časové rozpětí určitých aktivit v procesu, zejména těch časově náročných. Proces samotný zkrátit nelze tak, aby nebyly porušeny pravidla ITILu a požadavky konzultanta ukázkového dodavatele. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem větší rychlosti reakce na požadavky pro dodavatele je zejména fakt, že se zkrátí celková doba dodání služeb a změn. To je velikou výhodou zejména u softwarových produktů, neboť požadavky na tyto produkty se mohou rychle měnit. Znamená to, že se dodavatel vyhne nákladům spojeným se změnou požadavků v průběhu vývoje a nasazování služeb. Přínos v případě dosažení cílového stavu pro zákazníka: Díky rychlé reakci na požadavky zákazník ví, jaké nástroje bude v budoucnu mít a může se dle toho zařídit. Pokud některé služby není dodavatel schopen dodat, alespoň odpoví rychle a umožní tak zákazníkovi obrátit se s daným požadavkem na jiného dodavatele.

5.4.2 5.4.2.1

Metriky procesu Transition Planning and Support určené ITILem [27]: Průměrná odchylka od plánovaných nákladů

Popis metriky: Smyslem metriky je měřit rozdíly mezi plánovanými a skutečnými náklady na projekty nasazovaní služeb. Způsob měření: Odchylka bude měřena tak, že se u každého projektu vezmou plánované náklady, z mnou navrženého procesu Project Planning je to ten moment, kdy jsou projektu schváleny finance a je vytvořen rozpočet. Od nich se odečtou skutečně náklady, z mnou navrženého procesu Project Monitoring jsou to náklady v momentu, kdy je projekt ukončen. Tyto hodnoty budou vyjadřovány v procentech. Cílový stav: Vzhledem k tomu, že projekty nasazování služeb většinou nepatří mezi rozsáhlé projekty, měla by být průměrná odchylka od rozpočtu maximálně 10%. Reakce v případě nedosažení cílového stavu: V tomto případě se těžko hledá nápravné opatření. Může se jednat o období, ve kterém se nedařilo projektovým manažerům odhadovat dostatečně přesně náklady. Pokud však půjde o dlouhodobý problém, bude nutné udělat změnu v samotném procesu Project Planning a zapojit do odhadování rozpočtu někoho z finančního oddělení firmy, aby prováděl důkladnější a přesnější analýzy nákladů na projekt. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem nižší odchylky od nákladů je, že bude mít dodavatel větší přehled o stavu 100

5.4. Metriky implementace ITIL procesů svých investic a že jej nečekají žádná nepříjemná překvapení. Z toho také plyne další výhoda, že bude možné odhadnout cenu služeb tak, že budou ziskové a přitom nebude potřeba je předražovat (nebudou rezervy na nečekané náklady). Přínos v případě dosažení cílového stavu pro zákazníka: Tato metrika nemá přímí dopad na zákazníka. Cena služby je většinou určena ve chvíli, kdy dojde k podpisu smlouvy o úrovni služeb a její ceně. 5.4.2.2

Průměrná odchylka od časového plánu

Popis metriky: Smyslem metriky je měřit rozdíly mezi plánovanou délkou trvání a skutečnou délkou trvání projektů nasazování služeb. Způsob měření: Odchylka bude měřena tak, že se vezme plánovaný termín ukončení projektu, z mnou navrženého procesu Project Planning je tato hodnota určena v momentě, kdy je vytvořena síťová analýza a Ganttův diagram. Od něho se odečte skutečný termín ukončení, z mnou navrženého procesu Project Monitoring je to ten moment, kdy je projekt ukončen. Tyto hodnoty budou vyjadřovány v procentech. Cílový stav: Čas převzetí je stanovený již při podpisu smlouvy se zákazníkem. V případě odchylky od časového plánu se tedy jedná o kritickou veličinu a její odhady musí být velmi přesné. Z toho důvodu musí být odchylka od časového plánu velmi malá. Při konzultaci se zástupcem ukázkového dodavatele jsme stanovili, že tato odchylka by neměla překročit 3%. Samozřejmě mnohem větším problémem je prodloužení projektu než jeho dřívější dokončení. Reakce v případě nedosažení cílového stavu: Tato metrika by neměla překročit svoji horní hranici, neboť v případě časové tísně může projektový manažer požádat o více pracovník zdrojů a pokud jsou mu k dispozici může tím zrychlit práce na projektu. To však není možné vždy. Pokud by tedy byla odchylka od časového plánu příliš vysoká, bude nutné přitlačit na projektové manažery, aby se svých plánů drželi, případně aby opatrněji odhadovali časovou náročnost. V procesu samotném žádná změna v tomto směru nepomůže. Časovou náročnost jednotlivých aktivit v procesu Project Planning pomáhají projektovému manažerovi určit i jeho podřízení na projektu, kteří mají na starost detailní rozplánování aktivit na projektu, takže lépe kvalifikovaní odborníci na odhad časové náročnosti nejsou k dispozici. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem nižší odchylky od časového plánu je zejména fakt, že bude možné lépe plánovat jednotlivé projekty nasazování služeb u zákazníků. Některé projekty totiž nelze provádět najednou (například instalace operačního systému 101

5. Případová studie – implementace metodiky ITIL na server znemožňuje instalaci aplikačního software na daný server). Bude tedy možné určit přesněji začátky plánovaných projektů, které musí čekat na dokončení jiných projektů. Přínos v případě dosažení cílového stavu pro zákazníka: Díky malé odchylce od časového plánu bude moci zákazník lépe plánovat své aktivity tak, aby nebyla kvůli projektům nasazování služeb rušena kontinuita jejich businessu. 5.4.2.3

Procento projektů dokončených v dohodnuté kvalitě (dodržena dohodnutá úroveň služeb) a rozsahu (náklady, časová odchylka)

Popis metriky: Tato metrika v podstatě měří, kolik projektů nasazení služeb je úspěšných. Způsob měření: Odchylka bude měřena tak, že se vezmou hodnoty z předchozích metrik a pokud tyto hodnoty splňují cíle svých metrik, zkontroluje se, zda jsou dodržena všechna tvrzení v dohodě o poskytovaných službách. Pokud ano, je projekt označen za úspěšný, jinak je označen za neúspěšný. Tedy za úspěšný projekt lze považovat takový, který má menší odchylku od nákladů než 10%, menší odchylku od časového plánu než 20% a zároveň musí splňovat dohodnutou úroveň služeb. Odchylka bude měřena v procentech úspěšných projektů. Cílový stav: Cílový stav metriky je minimálně 90% úspěšně dokončených projektů. Reakce v případě nedosažení cílového stavu: Pokud se nebude dařit dokončovat projekty úspěšně je potřeba nejprve zjistit, co je příčinnou. Pokud bude na vinně příliš častá odchylka od nákladů, bude se postupovat stejně jako v případě dříve zmíněné metriky – odchylka od nákladů. Bude-li na vinně příliš častá odchylka od časových odhadů projektů, bude postupovat jako v případě dříve zmíněné metriky – odchylka od časového plánu. Bude-li na vinně nižší úroveň služeb, než je dohodnutá, bude potřeba analyzovat problémovou doménu – jsou produkty špatné už když jsou předány projektovým manažerům pro nasazení k zákazníkům, nebo jsou produkty málo testovány, či nedostatečně pečlivě nasazovány u zákazníků? Je na vlastníkovi procesu, aby v takovém případě navrhl nápravná opatření a případně eskaloval problém dále příslušným osobám. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem vysokého procenta dokončených projektů je zejména redukce nákladů plynoucích z nutnosti případných úprav dodaných služeb v případě neúspěšných projektů. V neposlední řadě je to však spokojenost zákazník. 102

5.4. Metriky implementace ITIL procesů Pokud by se nedařilo dokončovat projekty nasazování služeb úspěšně, netrvalo by dlouho a zákazník by se obrátil na někoho jiného. Přínos v případě dosažení cílového stavu pro zákazníka: Zákazník se díky vysokému procentu úspěšně nasazených služeb může spolehnout, že dostane to, co očekává. Neúspěšné projekty jej mohou stát nemalé náklady, plynoucí z nemožnosti využívat službu dle plánu, anebo plynoucí z nemožnosti používat službu déle, než se očekávalo (dle důvodu selhání projektu). Vysoké procento úspěšných projektů znamená vyhnout se těmto nákladům. 5.4.2.4

Počet závažných problémů a nastalých rizik během projektu

Popis metriky: Jedním z hlavních důvodů pro implementaci procesu Service Transition and Support je zlepšit a dát větší důraz na řízení rizik. Proto je potřeba změřit jak se to právě zavedením procesu povedlo Způsob měření: Při určování způsobu měření a cílového stavu u této metriky je nutné rozdělit problémy na závažné a méně závažné. Závažný problém je takový, který má závažné dopady na projekt. To znamená, že dojde k situaci, kdy projekt není schopen pokračovat podle plánu a být dokončen při plánovaných nákladech, v plánovaném čase či při stanovené kvalitě. Měřit se bude jednoduše poměr závažných problémů ku počtu projektů (v procentech). Cílový stav: Cílovým stavem je, aby vznik závažných problémů bylo minimálně a objevovali se tedy maximálně u 5 Reakce v případě nedosažení cílového stavu: Pokud se procento nastalých závažných problémů a rizik přehoupne přes stanovenou hranici, bude potřeba se ještě více zaměřit na jejich řízení. Pokud by se negativní výsledek opakoval, bude nutné poskytnout projektovým manažerům specialistu na řízení rizik – Risk Manager. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosy plynoucí z této metriky jsou jasné – každý závažný problém stojí dodavatele spoustu nákladů, zdrojů, rozhodí se mu plány a v neposlední řadě může upadat jméno dodavatele vůči zákazníkům. Proto je potřeba se těmto stavům vyvarovat. Přínos v případě dosažení cílového stavu pro zákazníka: Nastalé riziko, či závažný problém může mít dopady i na zákazníka. Díky tomu, že rizika řídí dodavatel služeb, ušetří zákazník náklady za vlastního manažera rizik, či za podstoupené riziko. 103

5. Případová studie – implementace metodiky ITIL 5.4.2.5

Spokojenost zákazníka s plánováním projektů a komunikací

Popis metriky: Díky plánování projektů a komunikaci nasazování služeb může zákazník lépe koordinovat své aktivity tak, aby byli v souladu s těmito plány. Způsob měření: Změřit spokojenost zákazníka plynoucí z plánování projektů není jednoduchá záležitost. Pro potřeby ukázkového dodavatele služeb postačí zpětná vazba v podobě závěrečného zhodnocení projektu, který provede Projektový Manažer spolu se zástupcem zákazníka, který na projekt dohlížel ze strany zákazníka (viz proces Project Monitoring). Je potřeba si uvědomit, že se jedná o stížnosti týkající se komunikace plánu a postupu na projektu. Pokud se bude jednat o stížnosti na kvalitu, či rozsah, nápravná opatření jsou ta, která jsem napsal u dříve zmíněné metriky - Procento projektů dokončených v dohodnuté kvalitě a rozsahu a do této metriky se vůbec nepočítají. Cílový stav: Toto je typická tzv. měkká (soft) metrika, což znamená, že ji nelze určit konkrétní hodnotu. Cílem prostě je, aby byl zákazník s plánováním a komunikací spokojen. Tedy cíl není naplněn v případě, že se objeví nějaké stížnosti od zákazníka. Pak je potřeba provést relevantní nápravná opatření. Reakce v případě nedosažení cílového stavu: Pokud si zákazník bude stěžovat, že nebyl dostatečně informovaný o průběhu projektu a dalších výkonech, je za toto zodpovědný projektový manažer. Během plánování má zákazníka informovat o úvodním plánu projektu (kick-off meeting – viz proces Project Planning) a během samotného projektu má na starost průběžnou komunikaci se zákazníkem (viz proces Project Monitoring). Poznámka: zákazníkem je v kontextu této metriky myšlen každý uživatel a zaměstnanec zákazníka, kterého se daný projekt týká. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem větší spokojenosti zákazníků s plánováním a komunikací nasazování služeb je vyšší spokojenost zákazníků celkově a z toho plynoucí loajalita stávajících zákazníků a případný příliv nových zákazníků.

5.4.3 5.4.3.1

Přidané metriky procesu Transition Planning and Support: Průměrná odchylka od plánu lidských zdrojů

Popis metriky: Úkolem metriky je změřit, jaký je průměrný rozdíl mezi naplánovanými a skutečně využitými lidskými zdroji. 104

5.4. Metriky implementace ITIL procesů Způsob měření: Metrika bude měřena tak, že se u každého projektu vezme počet všech plánovaných člověkohodin (man-hour), z mnou navrženého procesu Project Planning je tato hodnota určena po schůzi manažera změn (Change Manager), manažera testů (Test Manager), manažera propouštění služeb (Release Managera) a projektového manažera (Project Manager). Od tohoto počtu se odečte skutečně spotřebovaný počet člověkohodin po ukončení projektu. Cílový stav: Stejně jako náklady, by se odchylka od plánu co se lidských zdrojů týče, vzhledem k velikosti projektů, měla udržet do 10%. Reakce v případě nedosažení cílového stavu: Pro plán lidských zdrojů platí, že se nejedná o metriku, která by měla nějaký dopad na zákazníka. To znamená, že pokud by se měl projekt například odchýlit od časového plánu, raději se sáhne do plánu lidských zdrojů a časový deficit se dožene. Znamená to, že je velmi pravděpodobné, že se nebude vždy dařit držet do požadované hodnoty. Pokud by se však jednalo o dlouhodobý problém, bude potřeba do procesu plánování projektu zapojit odborníky pro odhad potřebných pracovních zdrojů. Vzhledem k tomu, že se nejedná velké projekty, měly by postačit odhady rolí, zapojených do procesu tak, jak jsem jej navrhl. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem plynoucím z nízké odchylky od plánu lidských zdrojů je zejména fakt, že liniový manažeři (Line Managers) budou schopni lépe plánovat přidělování svých zdrojů určitým projektům. Znamená to zejména ušetření nákladů na vzniklé mezery v plánu jednotlivých pracovníků. Liniový manažeři plánují práci svým podřízeným na hodinu. Pokud budou velké odchylky od plánu zdrojů na projektech, mohou u pracovníků vzniknout volné hodiny, které jsou samozřejmě placené. 5.4.3.2

Průměrná doba naplánování projektu

Popis metriky: Po předání služby oddělení přechodu a integrace služeb, aby danou službu nasadilo u zákazníka, je na projektovém manažerovi, který tento úkol dostane na starost, aby celý tento projekt naplánoval. Díky definovanému procesu (proces Project Planning) by mělo plánování probíhat rychleji. Způsob měření: Délka plánování projektu bude měřena od momentu předání služby danému projektovému manažerovi do schválení projektu vrcholovým manažerem (viz proces Project Planning). Cílový stav: Cílovým stavem je, aby byly projekty nasazení služeb naplánovány v průměru do dvou týdnů. 105

5. Případová studie – implementace metodiky ITIL Opatření v případě nedosažení cílového stavu: Pokud by průměrná doba plánování projektů přesahovala požadovanou mez, bude nutné proces Project Planning zjednodušit. Tak jak je nyní navržen však splňuje požadavky, které vyjádřil zástupce ukázkového dodavatele, a požadavky, které uvádí na proces ITIL. Přínos v případě dosažení cílového stavu pro dodavatele: Přínosem je, že se kratší doba plánování projeví i kratší délkou trvání celého projektu. To pro dodavatele znamená efektivnější a produktivnější práci zejména projektových manažerů. Přínos v případě dosažení cílového stavu pro zákazníka: Pro zákazníka je přínosem krátké doby plánování zejména kratší doba od požadavku do nasazení služby, což pro něho znamená, zejména u kritických služeb, redukci nákladů vzniklých nemožností danou službu využívat. Z uvedených metrik vyplývají přínosy implementace daných procesů. U obou procesů je navíc potřeba připočítat do přínosů i neměřené aspekty: • zvýšená spokojenost zákazníků, což vede k lepšímu postavení dodavatele na trhu • zvýšená spokojenost zaměstnanců, což vede jednak k vyššímu výkonu a jednak ke snížení počtu výpovědí • lepší informovanost vrcholových manažerů • jednodušší nabírání nových zaměstnanců na určité pozice – např. nový projektový manažer hned ví co má dělat díky jasně definovanému procesu • přesnější dlouhodobé i krátkodobé strategické a taktické plánování

5.5

Náklady na zavedení ITIL procesů

Nyní se podíváme co implementace dvou definovaných procesů bude přibližně stát. Do ceny implementace procesů počítám pouze náklady od chvíle, kdy na projektu začne dělat konkrétní konzultant. Nezapočítávám tedy náklady na shánění dodavatele ITIL konzultací (resp. ITIL konzultanta). Náklady lze rozdělit do čtyř následujících kategorií. Každá z těchto kategorií je detailně rozepsána a následně ji, pro přehlednost, shrnuje tabulka. 106

5.5. Náklady na zavedení ITIL procesů

5.5.1

Náklady na návrh implementace procesů a potřebné SW nástroje

Zmíněné nástroje, potřebné pro implementaci procesů stojí 2 500 000 Kč za Service Portfolio Management System včetně instalace a 40 000 Kč za Project Management System včetně instalace. Dále je potřeba připočítat náklady na práci ITIL konzultanta. Já jsem strávil prací na implementaci procesů (včetně konzultací) zhruba 150 hodin (nepočítám čas potřebný k nastudování ITILu a dalších zdrojů – předpokládám, že ITIL konzultant by toto již uměl). Pokud by tedy konzultant měl plat 1500 Kč/hod náklady na jeho práci by byly 225 000 Kč. Service Portfolio Management System (včetně instalace): Project Management System (včetně instalace): Náklady na konzultanta - vytvoření procesů:

2 500 000 Kč 40 000 Kč 225 000 Kč (150 hodin práce)

Tabulka 5.1: Náklady na implementaci procesů + SW nástrojů

5.5.2

Náklady na součinnost

Kromě předchozích přímých nákladů, je rovněž potřeba počítat s náklady plynoucími z času věnovanému implementaci procesů od zaměstnanců zákazníka (v tomto případě ukázkový dodavatel). Konzultace s ním zabrali zhruba 20 hodin, což tedy představuje náklad 20 člověkohodin na konzultace. Dále při instalaci potřebných softwarových nástrojů bude rovněž potřeba spolupráce od zaměstnanců v IT oddělení v délce zhruba 30 člověkohodin (je potřeba vyhranit místo pro nástroje, integrovat tyto nástroje, atd.). Navíc bude potřeba jednoho člověka na koordinaci aktivit při zavádění, řízení projektu zavádění procesů ze strany zákazníka, domlouvání termínů školení atd., čemuž bude potřeba věnovat přibližně 50 člověkohodin. Náklady na zástupce zákazníka pro konzultace: Spolupráce od zaměstnanců IT oddělení: Koordinace nasazení procesů:

20 člh. 30 člh. 50 člh.

Tabulka 5.2: Součinnost (náklady na vlastní zdroje zákazníka): 107

5. Případová studie – implementace metodiky ITIL

5.5.3

Náklady na školení zaměstnanců

Při implementaci bude také nutné proškolit zaměstnance, kterých se procesy týkají, a vyjasnit jim postupy u jednotlivých aktivit v procesech. Znamená to udělat hromadné školení pro zaměstnance v délce zhruba 2 hodin. Ze strany potřebných zdrojů zákazníka to znamená odhadem (odhad jsme provedli s konzultantem ukázkového dodavatele dle rolí zapojených do procesů a velikosti firmy) 32 člověkohodin. Pak bude nutné projít jednotlivé aktivity v procesech s klíčovými zaměstnanci. To se týká zejména projektových manažerů, jejich nadřízeného (vlastníka procesu Transition Planning and Support) a Service Portfolio Managera. Pro ty se tedy udělá školení v délce zhruba 2 hodin (tj. 2 hodiny Service Portfolio Managera a 2 hodiny pro vlastníka procesu Transition Planning and Support a projektové manažery). Ze strany potřebných zdrojů zákazníka to znamená 2 člověkohodiny na schůzi se Service Portfolio Managerem a 8 člověkohodin na schůzi projektovými manažery a vlastníkem procesu Transition Planning and Support (při třech projektových manažerech). Ze strany nákladů na konzultanta tyto tři schůzky znamenají dalších 9000 Kč (6 hodin po 1500 Kč). Školení zaměstnanců: Školení Service Portfolio Managera: Školení projektových manažerů a vlastníka procesu Transition Planning and Support:

30 člh. 2 člh. 8 člh.

Tabulka 5.3: Náklady na školení zaměstnanců - vnitřní náklady

Náklady na konzultanta – školení zaměstnanců:

9 000 Kč (6 hodin)

Tabulka 5.4: Náklady na školení zaměstnanců - náklady na konzultanta

5.5.4

Náklady na údržbu

Po nasazení bude probíhat měření výkonnosti procesů (viz předchozí kapitola – metriky implementace ITIL procesů), na které bude vynaložena určitá práce vlastníků procesů. Ta bude periodická a bude v rozsahu zhruba 20 člověkohodin/měsíc. Je nutné také počítat s údržbou sw nástrojů v délce 4 člověkohodin/měsíc ze strany zaměstnanců IT oddělení. 108

5.5. Náklady na zavedení ITIL procesů Náklady na měření výkonnosti procesů: Údržba systémů:

20 člh./měsíc 4 člh./měsíc

Tabulka 5.5: Náklady na údržbu

5.5.4.1

Shrnutí nákladů

Takže když shrneme co implementace a nasazení dvou zmíněných procesů bude přibližně stát, dostaneme hodnoty, které ukazuje následující tabulka: Přímé náklady: Náklady na vlastní zdroje – jednorázová investice: Náklady na vlastní zdroje – údržba:

2 774 000 Kč 138 člověkohodin 24 člověkohodin/měsíc

Tabulka 5.6: Celkové náklady Jak je vidět, většinu peněžních nákladů stojí Service Portfolio Management System. Jeho použití je tedy potřeba důkladně zvážit. Potřebná data by se dala ukládat jinam, například do CMS (Content Management Systému), avšak za cenu větších nákladů na údržbu takových dat a horší prací s takovými daty. Pro využití, či nevyužití tohoto systému by bylo potřeba vytvořit zvlášť obchodní případ a spočítat přínosy využití tohoto systému. To je však již nad rámec této práce. Cílem vyčíslení nákladů mé práce je poukázat na to, za co se při takové implementaci a zavádění procesů platí, aby měl čtenář představu. Samotná čísla nejsou tolik důležitá. Hlavní je si uvědomit, co všechno je nutné počítat do nákladů. Že nejde jen o zaplacení konzultanta, nebo zakoupení SW, či jiných nástrojů. Je to především o koordinaci lidí, spolupráci a v neposlední řadě školení, aby bylo toho, co je nákladně implementováno a nasazováno, také patřičně využíváno.

5.5.5

Předání případové studie zákazníkovi

Na poslední schůzce se zástupcem ukázkového dodavatele jsem prezentoval celé řešení, diskutovali jsme nad metrikami, jejich cílovými stavy a průběhem jejich měření a diskutovali jsme nad přínosy a náklady, plynoucími z implementace dvou procesů ITILu. Konzultant, dle mých předpokladů (viz. předchozí kapitola – náklady), zmínil příliš vysoké náklady za nasazení Service Portfolio Management Systému. Konzultovali jsme, jak by šel tento systém nahradit za řešení s nižšími náklady. Alternativa, kterou popisuji v kapitole o nákladech – tedy ukládání souborů do CMS systému, by byla dle zástupce ukázkového dodavatele nevyhovující. Nakonec jsme došli k závěru, že patrně nejlepším řešením by bylo vytvořit potřebný systém vlastními silami, kdy dle odhadu 109

5. Případová studie – implementace metodiky ITIL konzultanta by se náklady vešli do půl milionu, plus náklady na vlastní pracovní zdroje. Jak ale píši v kapitole o nákladech, pro všechny tyto alternativy by bylo potřeba udělat případovou studii zvlášť. Pokud by se tedy našel způsob, jak stlačit náklady za systém, implementace mnou navržených procesů by sem, dle slov zástupce ukázkového dodavatele, určitě vyplatila.

5.6

Shrnutí průběhu implementace metodiky ITIL

Když zpětně pohlédnu na celkový průběh implementace procesů metodiky ITIL, mohu konstatovat, že jsem splnil vytyčené cíle, které se týkají obsahu práce. Nemohu tak však konstatovat co se týče časového odhadu. Na práci jsem začal pracovat na začátku července roku 2011 a očekával jsem její dokončení v lednu roku 2012. Ve skutečnosti jsem však na konci dubna 2012 teprve prezentoval zástupci ukázkového dodavatele konečnou verzi případové studie. V následujícím textu zrekapituluji průběh práce na případové studii a upozorním na problémy, kvůli kterým jsem nabral takové zpoždění oproti původnímu plánu. Když jsem se sešel se zástupcem ukázkového dodavatele poprvé, snažil jsem se pochopit fungování a procesy ukázkového dodavatele. A zde se právě ukázala první a největší chyba v mých odhadech. Myslel jsem, že vše pochopím hned napoprvé a pak už jen dodefinuji další procesy – dle ITILu. Jak se však později ukázalo, musel jsem několikrát přijít na konzultaci znovu, neboť jsem nevěděl jak firma v dané oblasti funguje. Dokonce jsem musel procesy po jejich navržení někdy předělat, neboť nevyhovovaly jiným procesům, zaběhnutým u ukázkového dodavatele. Ale to již předbíhám. Pro implementaci jsme se zástupcem dodavatele vytipovali dva procesy. Prvním byl Service Portfolio Management, popsaném v publikaci Service Strategy třetí verze ITILu. Konzultant totiž zmínil potřebu analýzy navržení procesu pro optimalizaci portfolia služeb pro jednotlivé zákazníky. Firma udržuje katalog služeb, ze kterého si zákazníci mohou vybrat služby. Každý zákazník ukázkového dodavatele má však specifické požadavky na služby a často někteří zákazníci požadují služby, které v katalogu vůbec nejsou. Tvorba nových služeb a úpravy ve službách jsou pro dodavatele velmi nákladná záležitost. Proto byl vybrán právě zmíněný proces, který má, mimo jiné, na základě analýzy požadavků zákazníka, jeho IT strategie a finančních možností za úkol vybrat služby, které zákazník skutečně využije a přitom se tyto služby vyplatí dodavateli poskytovat. Při implementaci jsem musel proces popsaný ITILem velmi ’přiohnout’, neboť ukázkový dodavatel není úplně typický zástupce externího poskytovatele IT služeb. Typický externí poskytovatel služeb sleduje a analyzuje celkový trh se službami a snaží se nabízet takové portfolio služeb, o které bude na trhu co největší zájem (tj. pro co nejvíce zákazníků). Ukázková firma je však specifická v tom, že pro každého zákazníka optimalizuje portfolio na míru. Z 110

5.6. Shrnutí průběhu implementace metodiky ITIL hlediska SPM to znamená, že bylo potřeba do procesu zanést mnohem užší spolupráci se zákazníkem při řízení portfolia nabízených služeb a vůbec fakt, že je portfolio řízeno pro každého zákazníka zvlášť. Proces, tak, jak je psaný v ITILu, totiž počítá s jedním portfoliem IT služeb, které řídí dodavatel. Ukázkový dodavatel má sice ve výsledku jedno portfolio, ale chce řídit jeho podmnožiny zvlášť pro každého zákazníka. Druhým procesem, který jsme se zástupcem ukázkového dodavatele vytipovali byl proces Transition Planning and Support, popsaný v publikaci Service Transition třetí verze ITILu. Důvodem pro výběr tohoto procesu bylo, že nasazení služeb k zákazníkům je vedeno projektovými manažery, kteří nemají společný proces při plánování a řízení projektů a pracují tedy zcela podle svého uvážení. To s sebou nese samozřejmě určité problémy. Konzultant zmínil potřebu sjednocení procesu plánování a řízení těchto projektů. Při implementaci tohoto procesu bylo opět potřeba proces uzpůsobit speciálně pro potřeby ukázkového dodavatele. Navíc jsem musel přidat jednu roli – Line Manager (liniový vedoucí). U ukázkového dodavatele je na této pozici zaměstnanec, který vede tým lidí určité specializace (např. programátoři, databázový specialisté,..) a snaží se optimalizovat jejich pracovní vytížení. Projektový manažer tedy nemusí řešit vytížení jednotlivých pracovníků, pouze musí vědět kolik času bude potřebovat u jakých specializací pracovních zdrojů a u liniových vedoucích si pak alokuje dané zdroje. Při implementaci tohoto procesu jsem dával veliký důraz na komunikaci a reportování v průběhu projektů, jednak proto, že to vyžadoval zástupce ukázkového dodavatele, a jednak proto, že já tyto aspekty považuji za velmi důležité a bohužel často zanedbávané při projektovém řízení. Jak je vidět, musel jsem oba procesy poměrně dost přizpůsobit pro ukázkového dodavatele. A to byla druhá chyba v mých odhadech. Při implementaci procesů metodiky ITIL nelze očekávat, že implementátor vezme příručku a podle ní navrhne procesy a tím skončí. Je potřeba každý krok v návrhu ověřovat, zda je v souladu s dalšími procesy, které s ním souvisí. Po implementaci těchto procesů bylo potřeba určit přínosy a náklady, které by s sebou implementace takových procesů nesla. Přínosy jsem rovnou vyjádřil v metrikách, jejichž účelem je po implementaci procesů zjistit, zda bylo daných přínosů dosaženo. Každá taková metrika má jednak svůj cílový stav, kterého chceme implementací procesů dosáhnou, a dále opatření v případě, že by daného stavu nebylo dosaženo. U každé metriky jsem určil přínosy plynoucí z dosažení cílového stavu, a to jak přímo pro ukázkového dodavatele, tak i pro jeho zákazníky, neboť spokojenější zákazníci znamenají lepší a silnější postavení na trhu. Každá metrika obsahuje také návod, jakým způsobem bude prováděno měření a zpracování dat. Za měření je vždy zodpovědný vlastník procesu, ke kterému patří daná metrika. Na závěr bylo potřeba vyčíslit celkové náklady na implementaci procesů ITILu, pokud by ji prováděl konzultant při honoráři 1500 Kč za hodinu práce. Náklady jsem rozdělil na náklady na návrh implementace procesů a potřebné 111

5. Případová studie – implementace metodiky ITIL nástroje, náklady na součinnost, náklady na školení a náklady na údržbu. Peněžní výdaje jsem uváděl v Kč, náklady na pracovní zdroje ukázkového dodavatele v člověkohodinách. Když jsem sečetl celkové náklady, zjistil jsem, že největší část peněžních nákladů tvoří nasazení Service portfolio management systému. Jeho využití jsme poté kozultovali se zástupcem ukázkového dodavatele a hledali levnější řešení. Se zástupcem jsme zběžně prošli možná další řešení, ale výběr konkrétního by bylo potřeba určit vytvořením obchodního případu pro každé zvlášť a pak porovnat nejlepší alternativu. Zástupce ukázkového dodavatele se tedy nakonec vyjádřil tak, že procesy splňují jeho očekávání, ovšem cena je příliš vysoká. Pokud by se však podařilo nalézt levnější alternativu k Service portfolio management systému, bylo by řešení přijatelné a investovat do implementace procesů by se, dle slov zástupce ukázkového dodavatele, určitě vyplatilo.

112

Část III

113

Závěr Při tvorbě této práce jsem měl tři hlavní cíle. Prvním bylo definovat a zdůraznit roli IT Governance, tedy strategické řízení podnikové informatiky, v kontextu strategického řízení podniků. Čtenář by si měl zapamatovat hlavně to, že IT Governance je, a v budoucnu stále více bude rozhodujícím faktorem v úspěšnosti firmy v boji s konkurencí. Tvorba IT strategie musí být v souladu se strategickými cíli firmy. Cílem IT Governance je právě sladit IT strategii se strategií organizace. Mezi další cíle IT Governance patří zajištění přidané hodnoty (IT Governance zvyšuje hodnotu podniku), řízení IT aktiv, řízení rizik, které se týkají IT provozu, a v neposlední řadě měření výkonnosti IT. Zejména posledně jmenovaný cíl je velmi často podceňovaný, přitom je, dá se říci, kritický, neboť právě zavedením měření výkonnosti IT se liší moderní, strategicky orientované řízení IT (tedy IT Governance) od dřívějšího, dnes již překonaného, čistě operativního pojetí řízení IT. Druhým cílem bylo se seznámit s nejrozšířenějšími standardy pro IT Governance a porovnat je. Konkrétně šlo o ITIL, CobiT a ISO 20000. Tato trojice standardů svým rozsahem pokrývá téměř celou oblast IT Governance. Každý se však na danou problematiku dívá z jiného pohledu. V práci jsem každý z těchto standardů stručně představil, aby měl čtenář představu o tom, co je obsahem každého z nich. Poněkud hlouběji jsem popsal ITIL, a to z toho důvodu, že se množiny procesů ve standardech velmi shodují a pokud bych popisoval jednotlivé procesy u každého standardu, opakoval bych často stále totéž. Standardy se totiž neliší tolik množinou procesů, jako přístupem (viz kapitola srovnání standardů). Po srovnání jsem navíc zvolil ITIL pro praktickou ukázku implementace IT procesů, takže bylo na místě seznámit čtenáře s tímto rámcem hlouběji. Ze srovnání těchto standardů by si čtenář měl odnést zejména následující fakta: CobiT slouží zejména vrcholovému managementu podniků a soustředí se na správné postupy řízení, kontroly a auditu IT a procesů, které s poskytováním IT služeb souvisí. Na procesní přístup a měření jeho kvality a výkonnosti dává CobiT veliký důraz a pro měření a určení vyspělosti daného procesu podniku používá model vyspělosti procesu (maturity model). ITIL se, na rozdíl od CobiTu, zaměřuje na řízení IT z pohledu manažerů IT oddělení podniků a jejich podřízených. ITIL je stejně jako CobiT orientován 115

Závěr procesně. Od třetí verze však upustil od striktně procesního přístupu řízení IT služeb a orientuje se více na jejich životní cyklus. ISO 20000 je norma, která je velmi inspirována ITILem a při svých doporučeních z něho vychází. Tato norma slouží zejména jako certifikační nástroj pro posouzení celkové kvality poskytování IT služeb, ať už jde o vnitropodnikové IT oddělení, nebo externího poskytovatele. Třetím cílem bylo udělat případovou studii pro aplikaci jednoho ze standardů na příkladu externího dodavatele ICT služeb telekomunikačním operátorům. Znamenalo to se na konzultacích se zástupcem ukázkového dodavatele seznámit s businessem tohoto dodavatele, tj. jak firma funguje a jaké jsou v ní procesy, jaké mají praktiky a postupy atd. Dále jsem se zástupcem dodavatele musel vytipovat procesy, které budu implementovat. Tyto procesy jsem musel analyzovat a navrhnout tak, aby byly v souladu s ITILem a zároveň zapadli do zaběhnutých praktik a postupů ukázkového dodavatele. Po přečtení mé bakalářské práce by měl čtenář rozumět roli IT Govrnance v podnikové strategii, měl by mít základní přehled o nejrozšířenějších standardech v této oblasti ITIL, CobiT a ISO 20000 a měl by chápat hlavní rozdíly mezi nimi. Díky případové studii implementace procesů ITILu by měl čtenář mít představu o tom, co taková implementace těchto standardů obnáší, jak se přibližně dělá, jak zjistit, zda má implementace procesů daného standardu skutečně slíbený přínos a jak pro to vytvořit metriky. Na konci případové studie je vyčíslení nákladů, ze které by si čtenář měl odnést za co všechno se při implementaci procesů vybraného standardu platí. Čísla samotná se mohou u různých procesů velmi lišit, princip však zůstane stejný. Pro mne samotného byla tato bakalářská práce velikým přínosem. Ještě před půl rokem jsem o tom, jak je informatika v podnicích řízena, nevěděl téměř nic. Musel jsem nastudovat něco o tvorbě podnikové strategii a o tom co je IT Governance. Nastudoval jsem si také informace o třech nejrozšířenějších standardech pro IT Governance a porovnal je, díky čemuž vím, která k čemu slouží. Při praktické ukázce implementace procesů vybraného standardu jsem si vyzkoušel co tato práce obnáší, a zjistil jsem, že nelze jen tak nakreslit proces a dle něho firmu přizpůsobit. Je to právě naopak, proces se musí přizpůsobit businessu firmy. Zkusil jsem si také vytvořit metriky, což také není jednoduchá záležitost, neboť se opět musí přizpůsobit struktuře a businessu firmy, aby měla čísla v nich smysl a průběh měření nebyl pro firmu příliš velkou zátěží. Při vyčíslování nákladů jsem si uvědomil, co všechno se do implementace procesů počítá. Že nejde pouze o to zaplatit konzultanta, který procesy navrhne a zakoupit potřebný SW, či jiné nástroje. Do nákladů je potřeba počítat i náklady na koordinaci, spolupráci ze strany zákazníka a v neposlední řadě školení, aby bylo nákladně implementovaných procesů a nasazených systému patřičně využíváno.

116

Literatura [1]

R bmcsoftware: Understanding ITIL Service Portfolio Management and the Service Catalog. Dostupné z WWW:

[2]

Gelbstein, E.; Kamal, A.: COBIT process maturity levels for Information In Security Part 2 the Solution. Dostupné z WWW:

[3]

Gála, I. L.; Doc. Ing. Jan Pour, C.; Šedivá, I. Z.: Podniková informatika, 2., přepracované a aktualizované vydání. Grada Publishing, a.s., 2009.

[4]

prof. Ing. Jiří Voříšek, C.; prof. Ing. Josef Basl, C.; Ing. Tomáš Bruckner, P.; aj.: Principy a modely řízení podnikové informatiky. Oeconomica, Vysoká škola ekonomická v Praze, 2010.

[5]

prof. Ing. Petr Doucek, C.; prof. Ing. Josef Basl, C. a. k.: Informační Management. Professional Publishing, 2010.

[6]

An Introduction To ISO 27001.

[7]

ČSN EN ISO 9001:2009 Management kvality. Dostupné z WWW:

[8]

ISO 38500 abstract. Dostupné

[9]

IT Governance. 05 2010. Dostupné

[10] Historie a vývoj IT Governance.

Dostupné

z

z

Dostupné

WWW:

WWW: z

WWW: z

WWW:

[11] Obecné důvody pro zavedení IT Governance. Dostupné z WWW: 117

Literatura [12] Metodiky a modely řízení informatiky. Dostupné z WWW: R [13] Implementace ITIL . Dostupné

z

WWW:

R [14] Charakteristiky ITIL V2. Dostupné z WWW:

[15] Comparison between ITIL V3 and ITIL V2 The Main Changes. Dostupné z WWW: [16] Keřkovský, M.: Pragmatický přístup ke strategické analýze. Dostupné z WWW: [17] Keřkovský, M.; Drdla, M.: Funkční přístup k formulaci IS/IT strategie. Dostupné z WWW: [18] Košťan, P.: Firemní strategie : plánování a realizace. Computer Press, 2002. [19] Koho by měla IT Governance zajímat.

Dostupné

z

WWW:

[20] a kolektiv, I. J. D.: Projektový management podle IPMA. Grada Publishing, a.s., 2009, 502 s. [21] Lacy, S.: Delivering value through service management. 2008. Dostupné z WWW: [22] Nováková, I. O.: Potřeba změn v řízení informatiky a její role ve firmě. IT systems, 2003. Dostupné z WWW: [23] Office), T. T. S.: ITIL: Continual Service Improvement. TSO (The Stationery Office), 2007, 233 s. [24] Office), T. T. S.: ITIL: Service Design. TSO (The Stationery Office), 2007, 346 s. [25] Office), T. T. S.: ITIL: Service Operation. TSO (The Stationery Office), 2007, 276 s. 118

Literatura [26] Office), T. T. S.: ITIL: Service Strategy. TSO (The Stationery Office), 2007, 276 s. [27] Office), T. T. S.: ITIL: Service Transition. TSO (The Stationery Office), 2007, 274 s. [28] PDCA cyklus. Dostupné z WWW: [29] ISO/IEC 20000 Essentials. FEB 2008. Dostupné z WWW: [30] Dostupné z WWW: [31] Posters & Wallpapers. Dostupné

z

WWW:

[32] of Service Pty Ltd, . T. A.: ITIL V3 Foundation Complete Certification c The Art of Service Pty Ltd, 2009, 184 s. Kit: 2009 Edition. [33] Formulace a tvorba strategie. Dostupné

z

WWW:

[34] TSO: The Official Introduction to the ITIL. TSO (The Stationery Office), 2007, 252 s. R V3. itSMF [35] Xansa, A. C.; Hanna, A.; Rudd, C.; aj.: Úvodní pfiehled ITIL Czech Republic, o.s. s laskavou pomocí firmy Hewlett-Packard, s.r.o., 2007, 58 s.

119

PŘÍLOHA

Seznam použitých zkratek IT Informační technologie ITSM IT service management

121

A

PŘÍLOHA

Obsah přiloženého CD

thesis thesis.tex..................zdrojová forma práce ve formátu LATEX thesis.pdf ................................ text práce ve formátu PDF processes SPM.bpm ....................... proces Service Portfolio Management PP.bpm.....................................proces Project Planning PM.bpm...................................proces Project Monitoring 123

B