Implementace ITIL v servisním oddělení firmy

M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

}

w A| y < 5 4 23 1 0 / -. , )+ ( %&' $ # !"

Æ

Implementace ITIL v servisním oddˇelení firmy D IPLOMOVÁ PRÁCE

Tomáš Masník

Brno, jaro 2012

Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Tomáš Masník

Vedoucí práce: RNDr. Jaroslav Ráˇcek, Ph.D. i

Podˇekování Chci podˇekovat všem, kteˇrí mˇe podporovali jak po dobu studia tak v dobˇe vzniku této práce. Velké díky patˇrí RNDr. Jaroslavu Ráˇckovi, Ph.D. za cenné rady a vedení práce, celému servisnímu týmu a Spoleˇcnosti, že mi poskytla vše, co jsem pro tuto práci potˇreboval.

ii

Shrnutí Tato práce popisuje implementaci doporuˇcení z ITIL knihovny v konkrétním servisním oddˇelení stˇrednˇe velké firmy. Nejdˇríve je však cˇ tenáˇr seznámen s obecnou problematikou servisních oddˇelení a standardizace procesu˚ v nich a následnˇe s jednotlivými cˇ ástmi ITIL. Následuje rozbor konkrétních kapitol ITIL, okomentovaný z pohledu servisního oddˇelení. Souˇcástí práce je též projektová dokumentace implementace ITIL metodik v konkrétní spoleˇcnosti.

iii

Klíˇcová slova ITIL, servisní oddˇelení, projekt, procesní rˇ ízení, standardizace.

iv

Obsah 1 2

3

4

5

6

7

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Servisní oddˇelení . . . . . . . . . . . . . . . . . . . . . . 2.1 Servisní projekt . . . . . . . . . . . . . . . . . . . . 2.2 Problémy servisních projektu˚ . . . . . . . . . . . . 2.3 Standardizace a rˇ ízení procesu˚ servisních oddˇelení ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 O knihovnˇe ITIL . . . . . . . . . . . . . . . . . . . . 3.2 Seznam cˇ ástí ITIL . . . . . . . . . . . . . . . . . . . Analýza stávajícího stavu servisního oddˇelení . . . . . 4.1 O spoleˇcnosti . . . . . . . . . . . . . . . . . . . . . 4.2 O oddˇelení . . . . . . . . . . . . . . . . . . . . . . . 4.3 Používané nástroje . . . . . . . . . . . . . . . . . . Analýza pˇrínosu ITIL . . . . . . . . . . . . . . . . . . . 5.1 Návrh služeb . . . . . . . . . . . . . . . . . . . . . 5.2 Pˇrechod služeb . . . . . . . . . . . . . . . . . . . . 5.3 Provoz služeb . . . . . . . . . . . . . . . . . . . . . 5.4 Neustálé zlepšování služeb . . . . . . . . . . . . . Projekt implementace ITIL . . . . . . . . . . . . . . . . 6.1 Rozsah projektu . . . . . . . . . . . . . . . . . . . . 6.2 Logický rámec projektu . . . . . . . . . . . . . . . ˇ 6.3 Rízení rizik . . . . . . . . . . . . . . . . . . . . . . . Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

1 2 2 3 6 9 9 9 13 13 14 20 22 22 24 33 39 41 41 41 47 49

v

1 Úvod Po úspˇešném vyvinutí aplikace ji vˇetšina firem ještˇe dlouhou dobu ladí a upravuje tak, aby odpovídala byznys požadavkum. ˚ Vzniká tak odvˇetví servisu software, které tyto úpravy provádí, reaguje na požadavky zákazníku, ˚ opravuje chyby a adaptuje systém na zmˇeny v okolním prostˇredí. Vývoj trvá pouze krátkou dobu, kdežto období podpory, kterou poskytují servisní oddˇelení, je mnohonásobnˇe delší. Aby byla podpora efektivní a výdˇeleˇcná, je potˇreba už pˇri vývoji produktu dodržovat urˇcité zásady a mít nastaveny efektivní procesy v servisním oddˇelení. Právˇe efektivitou procesu˚ napˇríˇc IT firmou se zabývá ITIL. Pomocí jeho doporuˇcení se v této práci autor pokusí nastínit konkrétní zlepšení servisních oddˇelení a hlavnˇe servisního oddˇelení Spoleˇcnosti1 .

1. Spoleˇcnost s velkým S bude v této práci oznaˇcovat konkrétní cˇ eskou firmu, pro kterou je provádˇena praktická pˇrípadová studie.

1

2 Servisní oddˇelení V této kapitole si rozebereme obecnou definici servisního oddˇelení, jeho fungování a projekty. Tato teoretická pasáž poslouží k lepšímu pochopení fungování servisního oddˇelení ve Spoleˇcnosti. Servisní oddˇelení v pojetí této práce lze definovat jako oddˇelení IT firmy, které: •

má na starost rˇ ešení tzv. servisních projektu˚ (viz definice níže)

•

má samostatný rozpoˇcet

•

provádí kontinuální podporu ruzným ˚ zákazníkum ˚

•

zastˇrešuje oddˇelení uživatelské podpory

•

provádí údržbu a profylaxi v prostˇredí zákazníka

•

má samostatný nezávislý tým a svého manažera

•

provádí zmˇeny na projektech

•

rˇ eší incidenty a problémy

•

stojí mezi zákazníkem, vývojovým týmem a dalšími dodavateli (viz Obrázek. 2.1)

2.1

Servisní projekt

Servisním projektem je zde myšlen projekt dle definice podle ISO 10006: „Projekt je jedineˇcný proces složený z posloupnosti rˇízených kontrolovaných aktivit s danými daty zaˇcátku a konce, které se provádí s cílem dosáhnout pˇredem definovaného cíle, který splnuje ˇ specifikované požadavky jako cˇ as, cena a omezení zdroju.“[Sta09] ˚ Servisním projektem se navíc myslí údržba software (software maintenance), kterou IEEE definuje takto: „Proces úpravy softwarového systému nebo komponenty po dodání s cílem opravy chyb, vylepšení výkonu nebo jiných vlastností softwaru nebo pˇrizpusobení ˚ zmˇenˇenému prostˇredí.“[Sta09] 2

ˇ 2. S ERVISNÍ ODD ELENÍ

Obrázek 2.1: Servisní oddˇelení zde pˇredstavuje cˇ ást Software maintenance. Stojí mezi uživateli na zákazníkovˇe stranˇe (Customer users), vývojovým týmem (Development team) a dalšími dodavateli (Suppliers). Pˇrevzato ze [Nas84]. Obecnˇe se servis skládá ze všech aktivit poté, co je produkt uveden do provozu. Pod pojmem softwarové údržby nebo servisu se vˇetšinou myslí jedna z tˇechto aktivit: •

oprava chyb (corrective maintenance)

•

úpravy v rámci pˇredcházení chybám (preventive maintenance)

•

pˇridávání malých vylepšení, refaktoring (perfective maintenance)

•

aktualizace softwaru podle jeho prostˇredí - operaˇcního systému, hardwaru a dalších systému, ˚ na kterých je software závislý (adaptive maintenance) [Kru01]

2.2

Problémy servisních projektu˚

Pˇri servisních projektech a údržbˇe jako takové se vyskytují specifické problémy stejnˇe tak jako problémy podobné tˇem z vývojových projektu. ˚ Rozeberme si je tedy. Složitost kódu a architektura Servis se zabývá opravou chyb a zmˇenami. Kdykoli je požadována zmˇena v softwaru, je tˇreba ponoˇrit se do zdrojových kódu˚ a zmˇenu provést. Po3


kud je složitý kód anebo architektura, oprava bude také složitá. Je zˇrejmé, že pokud programátor musí nastudovat velké množství dokumentace a samotného nesrozumitelného kódu, zabere mu to velké množství cˇ asu. Studie [Ban98], [Ban93] prokazují, že složitost kódu má na cenu údržby velký vliv (ve studiích mˇerˇ eno hlavnˇe pomocí metrik poˇctu rˇ ádku, ˚ poˇctu rˇ ádku˚ metod a velikosti modulu). ˚ Nedostatek porozumˇení Jeden ze základních úkolu˚ pˇri úpravˇe softwaru je porozumˇení, jak systém ˇ funguje. Clovˇ ek, který provádí zmˇeny, musí vˇedˇet, jak je systém používán a jak byl vyvinut. Programátoˇri ve výsledku stráví vˇetšinu cˇ asu pochopením systému, až systém chápou, teprve mohou programovat zmˇeny [Nas84]. Nedefinován proces údržby Vˇetšina organizací nemá definovány procesy a standardy pro údržbu softwaru. Je to jedna z nejzanedbanˇejších oblastí softwarového vývoje, která ve výsledku zvyšuje cˇ as a tudíž i cenu servisu. Zapojení senior managementu Je duležité, ˚ aby zkušení senior manažeˇri byli zapojeni do procesu servisu. To, že senior management nerozumí potˇrebám servisního oddˇelení, znesnadnuje ˇ servisu práci a ve výsledku tak zhoršuje vztahy se zákazníkem. Analýza dopadu (Impact analysis) Analýza dopadu na aplikaci vyžaduje komplexní prozkoumání dopadu zmˇen na existující systémy. Servisní oddˇelení musí mít pˇríslušné znalosti o struktuˇre a architektuˇre systému. ˚ Na základˇe tˇechto znalostí jsou vytváˇreny odhady nároˇcnosti pro daný zmˇenový požadavek. Cíle analýzy dopadu na aplikaci jsou: •

zjistit rozsah zmˇeny

•

mít odhad na požadované prostˇredky pro práci

•

zjistit cenu a užitnou hodnotu dané zmˇeny

•

klasifikovat komplexnost zmˇeny a komunikovat ji ostatním zúˇcastnˇeným. 4


Analýza dopadu je klíˇcová pro udržovatelnost softwaru a má pˇrímý vliv na cenu servisu. Odhad nákladu˚ na údržbu Servis je nákladná fáze v rámci životního cyklu softwaru, pro jeho správné fungování jsou odhady nákladu˚ klíˇcové. Pokud jsou špatné, vede to k nákladnˇejšímu provozu a také ke ztrátˇe duvˇ ˚ ery zákazníka. Napˇríklad Y2K chyba je považována za jednu z nejdražších chyb v historii poˇcítaˇcu. ˚ Nokia investovala do prevence a opravy této chyby 75 milionu˚ Eur . Špatné proškolení uživatelu˚ Pokud firma nasazuje novˇe vyvinutý systém a nemá pˇripraven adekvátní plán pro školení cílových uživatelu, ˚ musí se pˇripravit na jejich nespokojenost. Pokud uživatelé nevˇedí, jak mají nový nebo upravený systém správnˇe používat, mají tendenci hlásit chyby, které vlastnˇe chybami nejsou. Výsledkem je pak zvýšení ceny údržby. Závislost na externím dodavateli V dnešní dobˇe integrace a outsourcingu je témˇerˇ každý systém závislý na nˇekolika dalších. Pro správnou funkcionalitu je nutné, aby všechny systémy fungovaly. Pro poskytování kvalitních služeb by si tedy dodavatel mˇel vybudovat dobré vztahy s dalšími spoludodavateli. Zvládnutí tˇechto vztahu˚ se ukazuje jako klíˇcová souˇcást údržby softwaru. Nedostatek dokumentace Pro údržbu je nejduležitˇ ˚ ejším artefaktem softwaru jeho dokumentace. Servisní tým nemuže ˚ správnˇe chápat systém, pokud chybí zásadní cˇ ásti dokumentace. Musí znovuobjevovat architekturu, závislosti v kódu apod., což zvyšuje cenu údržby. Metriky servisu Pokud organizace monitoruje své oddˇelení údržby a podpory, je schopno zlepšit spokojenost zákazníku. ˚ Monitorovat lze mnoho aspektu, ˚ od reakˇcní doby oddˇelení uživatelské podpory, doby nedostupnosti služby až po spokojenost cˇ lenu˚ servisního týmu. Firma by také mˇela od zákazníku˚ získávat 5


data z dotazníku˚ ohlednˇe spokojenosti s produktem a cˇ inností servisního oddˇelení. Motivace servisního týmu Údržba se provádí, pokud se objeví chyba nebo selhání systému. Na personál je pak vyvíjen velký tlak plynoucí z pˇrímé spokojenosti zákazníka. Lidé servisního týmu se pak mohou cítit ohroženi. Také se stává, že je na support tým nahlíženo jako na ménˇe hodnotné zamˇestnance. Náklady spojené s údržbou mnoha projektu˚ jedním týmem V pˇrípadˇe, že firma spravuje nˇekolik (nˇekdy i mnoho) servisních projektu, ˚ má vˇetšinou speciální tým servisních profesionálu, ˚ kteˇrí tyto projekty spravují. Tito lidé však dost cˇ asto mezi tˇemito projekty pˇrechází, pracují na ruzných ˚ požadavcích z ruzných ˚ projektu. ˚ Pˇrepínání kontextu, vývojového prostˇredí apod. stojí tyto lidi cˇ as. Proto je nutné pˇrechody mezi ruznými ˚ projekty optimalizovat. Problémové komponenty Ve firmách pracují lidé ruzného ˚ zamˇerˇ ení s ruznými ˚ zkušenostmi. S ruz˚ nými komponentami pracují s ruznou ˚ efektivitou. v pˇrípadˇe, že servisní oddˇelení nepokrývá znalostmi kompletní spektrum nabízených softwarových produktu˚ a komponent rovnomˇernˇe, nˇekteré komponenty budou pro údržbu horší než jiné. Pˇredstavme si napˇríklad firmu, která se specializuje na webové aplikace, ale okrajovˇe vyvíjí i mobilní. v servisním oddˇelení ale nepracuje žádný expert na mobilní aplikace. Je tedy pravdˇepodobné, že údržba mobilních aplikací bude obecnˇe dražší než údržba webu. ˚

2.3

Standardizace a rˇízení procesu˚ servisních oddˇelení

Servisní oddˇelení je relativnˇe nezávislé na vývojovém oddˇelení. Má vlastní vedení, vlastní rozpoˇcet. Pˇresto je vˇetšina firemních procesu˚ uplatnitelná jak v servisním oddˇelení, tak i ve vývojovém. Nˇekteré procesy jsou však typické pouze pro servisní oddˇelení. Spoleˇcné procesy Procesu, ˚ které se dotýkají i ostatních oddˇelení firem, je hodnˇe. Jsou zde procesy týkající se personálního oddˇelení, cˇ istˇe vývojového oddˇelení, rˇ ízení 6


firmy apod. Pro úˇcely této práce jsou zajímavé procesy: •

rˇ ízení uvolnˇení (Release management)

•

rˇ ízení neustálého zlepšování služeb (Continual Service Improvement)

•

rˇ ízení kapacit (Capacity management)

•

rˇ ízení konfigurací (Configuration management)

•

rˇ ízení zmˇen (Change management)

V tˇechto procesech je popsáno, jak se uvolnuje ˇ a nasazuje nová verze aplikace, jak se rˇ ídí zmˇeny ve službých, jak se udržují informace o všech konfiguraˇcních položkách, jak si hlídat kapacitu dostupných (nejen) lidských zdroju˚ a jak postupnˇe neustále vylepšovat stávající portfolio služeb. Standardizace procesu˚ Cílem standardizace by mˇel být stav firmy, ve kterém se využívá nejlepších možných postupu˚ a informací k dodávání produktu˚ a služeb a který pˇrinese zvýšení efektivity a sníží poˇcet negativních dopadu. ˚ Standardy nepˇredepisují konkrétní implementace procesu, ˚ spíše jen ukazují cestu a okruhy, kterým by se firma mˇela vˇenovat, pokud se chce dále zlepšovat (a získat certifikaci o splnˇení normy). Standardy jsou z velké cˇ ásti navrženy pro správné fungování velkých organizací. Nicménˇe byznys se neustále vyvíjí a klade stále vˇetší nároky na dodavatele služeb. Proto se zvyšuje poˇcet firem, které mají tendence absolvovat nároˇcné a nákladné certifikace s cílem získat díky tomu více zajímavých klientu. ˚ Existuje pomˇernˇe velké množství standardu˚ pro vedení IT spoleˇcností. Ty nejzajímavˇejší z pohledu servisních oddˇelení si zde rozeberme. ISO 9001 Norma ISO 9001 je známý a velmi rozšíˇrený standard, který se zamˇerˇ uje na efektivní nastavení managementu organizace a kvalitu produktu˚ a služeb. Duraz ˚ je zde kladen na obchodní cíle a na splnˇení oˇcekávání zákazníku. ˚ Byznys podle tohoto standardu zjišt’uje požadavky zákazníku, ˚ rozhoduje o úspˇechu a neúspˇechu projektu a vypoˇrádává se s problémy. 7


ISO/IEC 20000 Norma ISO/IEC 20000 je první mezinárodní normou pro rˇ ízení IT služeb. Jak již bylo zmínˇeno v kapitole 3.1, vychází z britské normy BS 15000 a tedy i z ITIL. Do poskytování IT služeb zavádí principy procesního rˇ ízení, definování, mˇerˇ ení a vyhodnocování kvality služeb zákazníkum ˚ a jejich neustálé zlepšování. Pokud budeme srovnávat normu ISO/IEC 20000 s knihovnou ITIL, mu˚ žeme rˇ íct, že pˇri implementaci ISO normy je nutné využít urˇcitých cˇ ástí ITIL, nicménˇe ITIL tuto normu rozsahem pˇrevyšuje. Tedy i pokud máme implementovány certifikované procesy ISO/IEC 20000, ITIL nám nabízí další vylepšení a pˇridanou hodnotu pro zákazníka i poskytovatele. Ve srovnání s normou ISO 9001 je zamˇerˇ ena na vˇetší podniky a její implementace je nˇekolikanásobnˇe nároˇcnˇejší. Tato práce si klade za cíl zamˇerˇ ení se na stˇrední podniky, ale konkrétní Spoleˇcnost, na níž provádíme v praktické cˇ ásti pˇrípadovou studii, již tuto normu splnuje. ˇ ISO 14764 Norma ISO 14764 je zamˇerˇ ena cˇ istˇe na údržbu softwaru (software maintenance). Popisuje procesy jako pˇredání softwaru do údržby, procesy spojené s dokumentací softwaru, odhady nákladu˚ na údržbu a další. Tato norma je zamˇerˇ ena na velké firmy, které se specializují na údržbu softwaru. Vzhledem k tomu, že Spoleˇcnost, na niž se zamˇerˇ uje praktická cˇ ást práce, takové ambice ani rozsah servisního oddˇelení nemá, nebudeme se touto normou dále zabývat.

8

3 ITIL Information Technology Infractructure Library, dále jako ITIL, je soubor konceptu˚ a postupu, ˚ které umožnují ˇ lépe plánovat, využívat a zkvalitnoˇ vat využití informaˇcních technologií, a to jak ze strany dodavatelu˚ IT služeb, tak i z pohledu zákazníku. ˚ V této kapitole se budeme vˇenovat rozebrání obsahu ITIL a identifikaci jeho klíˇcových cˇ ástí pro servisní oddˇelení.

3.1

O knihovnˇe ITIL

Historicky tato sada postupu˚ a zkušeností vznikla ve Velké Británii v 80. letech 20. století. Vznikla pod záštitou bristké vlády s cílem zdokumentovat, jak se nejúspˇešnˇejší firmy postavily k rˇ ízení IT služeb. Na zaˇcátku 90. let už byla hotová série až 40 knih, která si získávala pozornost britské IT komunity. V roce 2004 byla vydána druhá verze ITIL, momentálnˇe je k dispozici už tˇretí verze – ITILv3. S touto verzí knihovny ITIL také pracuje autor této práce. Formální standard pro rˇ ízení IT služeb – The British Standard 15000 (BS 15000) byl z velké cˇ ásti postaven právˇe na postupech popsaných v ITIL. Od té doby se na svˇet dostaly i další standardy cˇ erpající z ITIL, napˇríklad celosvˇetovˇe používaný standard ISO 20000:2005.

3.2

Seznam cˇ ástí ITIL

Jádro ITIL se skládá z pˇeti publikací: •

Strategie služeb (Service Strategy)

•

Návrh služeb (Service Design)

•

Pˇrechod služeb (Service Transition)

•

Provoz služeb (Service Operation)

•

Neustálé zlepšování služeb (Continual Service Improvement)

Strategie služeb Jádrem životního cyklu služeb je Strategie služeb. Témata tohoto svazku obsahují vývoj nabídky služeb, charakteristiku typu˚ interních i externích 9

3. ITIL dodavatelu, ˚ pˇrínosu˚ služeb a portfolia služeb. Cílem této cˇ ásti je stanovit strategii, kterou bude firma uplatnovat, ˇ co se týˇce poskytování služeb. A to vˇcetnˇe nastavení kritérií úspˇechu, zhodnocení aktuálního stavu firmy a prioritizace obchodních pˇríležitostí. Servisního oddˇelení se tato kniha dotýká pouze minimálnˇe, proto se na ni v textu nebude objevovat pˇríliš mnoho odkazu. ˚

Návrh služeb Druhá kniha popisuje cˇ innosti související s návrhem služeb. Klade duraz ˚ na provázanost návrhu s požadavky byznysu. Popisuje, jaké principy a metodiky zvolit pro pˇretvoˇrení strategických cílu˚ do služeb. Krom implementace nových služeb je zde také popsána varianta úprav a vylepšení stávajících služeb tak, aby neustále poskytovaly zákazníkovi pˇridanou hodnotu. Zabývá se také kontinuálností služeb, spoluprací se standardy a dosažením požadované kvality. ˇ Tato kniha se dotýká servisních oddˇelení v kapitolách Rízení úrovnˇe sluˇ žeb (Service Level Management), Rízení kapacit (Capacity Management), ˇ Rízení kontinuity služeb (IT Service Continuity Management).

Pˇrechod služeb Service Transition neboli pˇrechod služeb popisuje fázi pˇrevodu služby z jedné fáze svého životního cyklu do další. Kniha Service Transition poskytuje rady pro rˇ ízení projektu˚ tak, aby výsledná nová cˇ i upravená služba byla co nejzpusobilejší ˚ pro pˇredání do provozu, aby pˇri pˇredání došlo k co nejménˇe chybám, pˇrerušením aktuálních služeb a projevilo se co nejménˇe rizik. Tato publikace kombinuje ruzná ˚ odvˇetví pˇres kapitoly rˇ ízení zmˇen, konfigurací, uvolnˇení a nasazení, až po rˇ ízení rizik. Jsou v ní rady pro rˇ ízení zmˇen na poskytovaných službách, zmˇen v procesech, vše v kontextu pˇredávání rˇ ízení mezi zákazníky a poskytovateli služeb. Také je zde popsán systém rˇ ízení znalostí, který je postaven nad systémy konfigurací, kapacit a známých erroru˚ 1 .

1. Pojem „známý error” se bude vyskytovat v celé práci. Zastupuje anglický ITIL pojem “known error”. z duvod ˚ u˚ snadnˇejší orientace v pojmech bude v práci použit tento cˇ eskoanglický pojem.

10

3. ITIL Procesy pˇredávání služeb Stˇežejní cˇ ást knihy se vˇenuje procesum ˚ spojeným s pˇredáváním služeb (Service Transition processes). v ní jsou obsaženy kapitoly jako Plánování pˇredání a podpora (Transition planning and support), kde jsou rady ohlednˇe sestavení aplikace, nasazení, plánování kapacit a zdroju˚ s cílem úspˇešného vylepšení služby bez dopadu na její aktuální chod. ˇ Další duležitou ˚ kapitolou je bezpochyby Rízení zmˇen (Change Management). Zde je popsán proces detekování zmˇen a jejich následné zpracování. Cílem je zlepšit efektivitu služby a celého (v našem pˇrípadˇe) servisního oddˇelení, vylepšení služeb, úprava služby tak, aby i nadále odpovídala obchodním požadavkum. ˚ ˇ Rízení konfigurací (Service asset and configuration management) se vˇenuje zaznamenávání konfigurací spravovaných služeb. Konfigurací se zde myslí všechny aplikace, záznamy, dokumentace a jejich vztahy. Cílem je podpoˇrit efektivitu rˇ ízení a odstranˇení chyb zpusobených ˚ špatným nastavením. ˇ Rízení uvolnˇení a nasazení (Release and deployment management) si klade za cíl vyjasnit procesy uvolnování ˇ nových verzí služeb a jejich nasazení tak, aby byly efektivní, dalo se na nˇe spolehnout a plánovat podle nich další navazující aktivity a aby v nich docházelo k minimu chyb. Kapitola Validace a testování služeb (Service validation and testing) rˇ eší problémy pˇri testování nových nebo upravených služeb a jejich validaci. Cíl je jednoduchý – dostat do chodu službu, která je co zaruˇcenˇe funkˇcní a odpovídá puvodním ˚ požadavkum. ˚ ˇ Nakonec Rízení znalostí (Knowledge management) obsahuje návod, jak si uchovávat a efektivnˇe pˇredávat znalosti o službách, zainteresovaných lidech z rˇ ad poskytovatelu˚ i dodavatelu, ˚ plánech i zdrojích. Cílem je zvýšení efektivity a kvality služeb tím, že lidé v oddˇelení uživatelské podpory (Service Desk - v našem pˇrípadˇe v servisním oddˇelení) jsou v každém okamžiku schopni jednoduše zjistit, kdo, jak a hlavnˇe proˇc služby využívá. Provoz služeb Kniha Provoz služeb (Service Operation) mapuje rˇ ízení každodenního provozu. Obsahuje rady, jak dosáhnout efektivity pˇri poskytování podpory, zajištˇení pˇridané hodnoty jak pro zákazníka, tak i pro poskytovatele. Jejím cílem je poradit, jak dosáhnout stability služeb i v pˇrípadˇe, že na nich dochází ke zmˇenám. Dostává se nám tak návodu, ˚ jak reagovat reaktivnˇe i proaktivnˇe a na co si v obou pˇrípadech dát pozor. 11

3. ITIL Stˇežejními cˇ ástmi pro chod servisního oddˇelení jsou z této knihy hlavnˇe ˇ Procesy provozu služeb (Service Operation processes) se svými cˇ ástmi – Ríˇ zení událostí (Event Management), incidentu˚ (Incident Management), Rízení problému˚ (Problem Management) a pˇrístupu˚ (Access Management). Všechny tyto kapitoly popisují nezbytné procesy pro správný chod oddˇelení uživatelské podpory z pohledu reakcí na ruzné ˚ události. Neustálé zlepšování služeb Poslední ze série knih ITILv3 je Neustálé zlepšování služeb (Continual Service Improvement). z ní jsou cˇ erpány informace ohlednˇe vylepšování a udržování pˇridané hodnoty pro zákazníka i dodavatele pomocí kontinuálního zlepšování návrhu, dodávání i chodu služeb. Kniha navazuje na rˇ ízení zmˇen, kvality a kapacit zmínˇené ve výše popsaných knihách. Firmy se zde mohou pouˇcit o postupných i velkých skokových vylepšeních v kvalitˇe a efektivitˇe. Celou knihou probíhá myšlenka uzavˇrené smyˇcky založená na modelu Plan-Do-Check-Act (PDCA) – tedy „plánuj, udˇelej, zkontroluj, jednej“ aneb nejdˇríve provˇerˇ it souˇcasnou výkonnost služby a naplánovat její vylepšení, následnˇe vylepšení realizovat, poté zhodnotit výsledky a opravit chyby a na základˇe tˇechto výsledku˚ rozpracovat výsledné rˇ ešení. Hlavní kapitoly zde popisují principy neustálého zlepšování služeb (Continual Service Improvement principles), procesy (Continual Service Improvement processes) jako napˇríklad co lze mˇerˇ it, jak vytváˇret reporty, otázky, které pro zlepšování klade byznys apod. Dále jsou zde kapitoly o metodách zlepšování služeb, jejich hodnocení, posuzování, testování a srovnávání. Poslední fáze zde opˇet popisuje technologie a rady pro úspˇešnou implementaci vˇcetnˇe výzev a rizik.

12

4 Analýza stávajícího stavu servisního oddˇelení V této kapitole shrneme aktuální stav Spoleˇcnosti a hlavnˇe jejího servisního oddˇelení. Rozebereme si jej z pohledu procesu, ˚ pˇredností a nedostatku. ˚ Na základˇe této kapitoly pak budeme moci v dalších kapitolách tyto nedostatky s pomocí knihovny ITIL rozebrat a navrhnout jejich vylepšení. Servisní oddˇelení ve Spoleˇcnosti splnuje ˇ vše z definice v kapitole 2. Veškeré informace v následujících cˇ ástech byly získány formou rozhovoru˚ se všemi cˇ leny servisního oddˇelení, vˇcetnˇe servisního manažera, a také z osobních zkušeností autora práce, který v dobˇe psaní sám byl jeho cˇ lenem.

4.1

O spoleˇcnosti

„Spoleˇcnost je cˇ eskou poboˇckou mezinárodní skupiny, která je jedním z nejvˇetších dodavatelu˚ ICT služeb ve stˇrední a východní Evropˇe. Samotná cˇ eská poboˇcka cˇ ítá pˇres sto zamˇestnancu˚ a specializuje se pˇredevším na vývoj profesionálních portálových aplikací na platformˇe Java EE. Spoleˇcnost má maticovou, plochou organizaˇcní strukturu a silnou projektovou kulturu. Jedna projektová kanceláˇr cˇ ítá okolo šesti projektových manažeru, ˚ kteˇrí vedou soubˇežnˇe asi deset projektu, ˚ na kterých je zamˇestnáno okolo šedesáti vývojáˇru˚ a jiných technických pracovníku. ˚ Na projektech, které jsou jak interní, tak externí povahy, je pˇriˇrazena vˇetšina zamˇestnancu˚ – cˇ asto na více projektech souˇcasnˇe, nˇekteˇrí z nich také ve více projektových rolích. Projekty se liší svým rozsahem od nˇekolikamˇesíˇcních interních projektu, ˚ pˇres rozsáhlé studie proveditelnosti až po komerˇcní projekty s rozpoˇctem v rˇ ádu miliónu˚ korun a nˇekolikaletou délkou trvání. Projekty jsou realizovány s využitím nˇekolika málo spoleˇcných platforem, nicménˇe každý projekt je technicky komplexní a obsahuje aplikace pˇrizpusobené ˚ na míru konkrétním klientum. ˚ Projekty jsou po ukonˇcení pˇredány do servisního režimu, ve kterém se o nˇe pak stará servisní oddˇelení. Spoleˇcnost je držitelem stupnˇe 4 standardu kvality organizace práce CMMI a nˇekolika ISO certifikací.” [Krk11] Autor se se Spoleˇcností seznámil v prubˇ ˚ ehu své šestimˇesíˇcní stáže v rámci Interim projektu. Pracoval zde na pozici asistenta projektového manažera. Díky této praxi mˇel autor možnost detailnˇe se seznámit s procesy ve firmˇe z pohledu managementu. Po skonˇcení praxe zde autor nastoupil na pozici Java programátora, cˇ ímž získal pˇrehled o procesech a kvalitách firmy z pohledu zamˇestnance a vývojáˇre. Ve firmˇe prošel jak vývojovým, tak servisním oddˇelením. Kombinace všech tˇechto typu˚ zkušeností vede k 13

ˇ 4. A NALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODD ELENÍ

získání komplexního pohledu na firmu.

4.2

O oddˇelení

Servisní oddˇelení ve Spoleˇcnosti má v dobˇe vzniku této práce na starost 10 projektu. ˚ Všechny projekty mají za cíl údržbu a podporu portálových aplikací, které byly ve Spoleˇcnosti vyvinuty. Témˇerˇ každý nový firemní projekt je následnˇe spravován servisním oddˇelením. Proto se toto oddˇelení neustále rozrustá. ˚ S rostoucím poˇctem lidí je tˇreba rˇ ešit ruzné ˚ dosud nepoznané problémy – rˇ ízení znalostí a zastupitelnosti, zapojení nového cˇ lena do týmu, standardizace procesu˚ apod. Oddˇelení se zabývá pouze správou softwaru. Hardware je plnˇe v režii zákazníka. Spoleˇcnost v minulosti mˇela zkušenosti se správou hardware. To se však ukázalo jako pˇríliš nákladné a Spoleˇcnost od toho upouští. Nicménˇe je možné, že správa hardwaru bude nˇekdy v budoucnu také na nˇekterém projektu po Spoleˇcnosti vyžadována. Projekty Jak již bylo zmínˇeno, servisní oddˇelení poskytuje podporu deseti aplikacím, které jsou postavené na portálech Liferay a WebSphere. Každý projekt byl vyvinut pro jiného zákazníka, jeden je klasifikován jako interní – správa vnitrofiremního intranetového portálu. Vzhledem k tomu, že se projekty velmi liší jak rozsahem, konkrétním portálem i stáˇrím, je jakákoli standardizace pomˇernˇe obtížná. Každý projekt má vlastní proces pro uvolnˇení a nasazení aplikace, pro každý z nich byla ještˇe donedávna jiná servisní smlouva (Service Level Agreement - SLA). Každý projekt, který oddˇelení pˇrebralo do své správy, byl pˇredán v jiném stavu. U nˇekterých probˇehlo pouze neformální pˇredání, kvuli ˚ jiným byl uspoˇrádán workshop, na kterém puvodní ˚ tým vývojáˇru˚ pˇredal znalosti cˇ lenum ˚ servisního oddˇelení. Servisní oddˇelení nemá nijak definován proces pˇredávání projektu˚ do správy, což je ve firmˇe vnímáno negativnˇe, hlavnˇe ze strany servisního týmu. Také není nijak pevnˇe uchopena spolupráce puvodního ˚ vývojového týmu se servisním. Neˇreší se ani zastupitelnost a odhadování pˇrípadných zmˇenových požadavku. ˚ Stejnˇe tak se do servisu nadále nezapojuje ani projektový manažer puvodního ˚ vývojového týmu. Spoleˇcnost nemá zaveden žádný jednotný monitoring systému, ˚ které spravuje. Nástroje pro sledování systému˚ se však ve Spoleˇcnosti aktuálnˇe vyvíjí. 14


Tým Aktuální tým cˇ ítá osm lidí a servisního manažera. Dohromady má tým zkušenosti ze všech klíˇcových oblastí pro servis projektu. ˚ v nˇekterých oblastech však tyto znalosti má pouze jeden cˇ lovˇek, což se ukazuje jako kritické pro rˇ ešení zastupitelnosti. Nˇekteré znalosti v týmu cˇ ásteˇcnˇe nebo úplnˇe chybí. Oddˇelení se snaží vyˇrešit otázku zastupitelnosti na všech servisních projektech. Výsledkem této snahy je zatím to, že na vˇetšinˇe projektu˚ jsou schopni provést servisní zákrok dva lidé, na nˇekterých tˇri a na dvou dokonce pouze jeden cˇ lovˇek. Nicménˇe se pˇripravují školení, aby pˇred dobou dovolených tyto palˇcivé problémy byly odstranˇeny a nedošlo náhodou k výpadku nˇekteré ze služeb. Servisních projektu˚ pˇribývá, a proto má oddˇelení tendenci rust. ˚ Se zvýšením poˇctu lidí je tˇreba více rˇ ešit výmˇenu znalostí a zkušeností a je potˇreba více práce ze strany servisního manažera. Tým je rozdˇelen na dva podtýmy. Jeden se vˇenuje projektum ˚ Spoleˇcnosti, druhý pracuje na servisních pracích pro partnera Spoleˇcnosti. Každý podtým se schází každý den, aby si jeho cˇ lenové sdˇelili, na cˇ em pracovali a na cˇ em budou pracovat následující den. Oba podtýmy se pak setkávají dvakrát týdnˇe s cílem udržení informací o aktuálním stavu oddˇelení. Všechny meetingy vede a organizuje servisní manažer. Jeho role spoˇcívá v organizaci celého týmu, správˇe duležitých ˚ projektových informací, komunikaci s ostatními týmy ve Spoleˇcnosti a hlavnˇe komunikaci se zákazníkem a správˇe financí oddˇelení. Procesy v oddˇelení Pˇrebrání projektu oddˇelením Po vyvinutí projektu vývojovým oddˇelením je tento projekt pˇredán zákazníkovi, který jej formálnˇe akceptuje. v tu chvíli vzniká servisní smlouva (Service Level Agreement - SLA) a projekt je od této chvíle spravován servisním oddˇelením. Pro správný chod jeho podpory a údržby musí být zaˇrízeno pˇredání znalostí o projektu smˇerem k servisnímu týmu. Tento proces zatím není definovaný a oddˇelení se zatím pouze snaží vytipovat podle historických dat, jak by tento proces mˇel vypadat, aby byl efektivní, cˇ asovˇe (a finanˇcnˇe) co nejménˇe nároˇcný, a zárovenˇ aby došlo k pˇrevzetí všech dule˚ žitých znalostí a artefaktu˚ nutných pro další fungování. Tento proces není pˇríliš cˇ astý, projekty Spoleˇcnost uzavírá a pˇredává do servisu maximálnˇe nˇekolikrát roˇcnˇe. Proto je tento proces zatím uchopen velmi volnˇe – nedá se totiž jednoduše postupnˇe vyvíjet a vylepšovat. Mo15


mentálnˇe ve Spoleˇcnosti vzniká kontrolní seznam nutných podmínek, které musí být splnˇeny pˇri pˇrevzetí projektu do servisu. Tento seznam se neustále vyvíjí, nicménˇe jeho použitelnost zatím nebyla ovˇerˇ ena v praxi. Servisní oddˇelení se zaˇcíná projektu vˇenovat až po fázi pˇredání. Do té doby je projekt cˇ istˇe v kompetencích vývojového oddˇelení. Servisní tým se ale chce zapojit i dˇríve, hlavnˇe ve fázi pˇredávání projektu. Tým oˇcekává, že se zlepší pˇredání znalosti o uvolnˇení a nasazení aplikace i komunikace s puvodním ˚ vývojovým týmem. O žádném dalším vstupu do projektu ze strany servisního oddˇelení tým neuvažuje. Po úspˇešném pˇredání projektu zákazníkovi bˇeží záruˇcní doba. Bˇehem ní provádí Spoleˇcnost všechny zásahy zdarma. ˇ Rízení požadavku˚ Požadavkem v životním cyklu servisního projektu myslíme libovolnou akci, která si žádá pozornost od servisního týmu nebo pouze servisního manažera. Prvním, a zárovenˇ nejvíce typickým požadavkem je incident. Incidentem se rozumí neplánovaný výpadek poskytované služby nebo nˇekteré její cˇ ásti. Na žádném projektu momentálnˇe neexistuje pasivní kontrola funkˇcnosti systému. ˚ Monitoring je ale ve fázi implementace, je tedy do budoucna potˇreba s ním poˇcítat. Incident zatím tedy muže ˚ nahlásit pouze zákazník. Hlášení probíhá formou vytvoˇrení nového tiketu v systému Atlassian JIRA. Více o tomto nástroji viz kapitola 4.3. Tento tiket je typu Customer request (zákazníkuv ˚ požadavek). Jeho životní cyklus vˇcetnˇe všech fází popisuje diagram - Obrázek 4.1. Tiket má ruzné ˚ atributy. Pro komunikaci se zákazníkem jsou nejduleži˚ tˇejší tyto: •

Viditelnost tiketu – urˇcuje, zda tiket vidí i zákazník nebo pouze servisní oddˇelení. U Customer request tiketu˚ je viditelnost „Public“ – tedy tento tiket vidí i zákazník.

•

Priorita – urˇcuje, o jak závažný problém se jedná. Priorita odpovídá závažnosti chyby podle definice v konkrétní SLA.

•

Odhad pracnosti – uvádí, na kolik hodin práce odhadují daný problém zamˇestnanci servisního oddˇelení. Na základˇe této hodnoty se zákazník dále rozhoduje, zda chce tento problém rˇ ešit nebo ne. 16


Obrázek 4.1: Workflow tiketu˚ servisní podpory

17


•

Vykázaná skuteˇcná práce – kolik hodin pracovníci ze strany servisního oddˇelení na tiketu strávili. Tato doba odpovídá tomu, kolik zákazník nakonec zaplatí.

Tikety typu incident jsou uzavˇreny okamžitˇe po vyˇrešení nebo obnovení funkcionality. Pokud je dále na problému potˇrebná nˇejaká práce, je vykázána na tzv. „implementaˇcní” tiket propojený s tiketem incidentu. Tento implementaˇcní tiket je oznaˇcen štítkem „problem“. Po uzavˇrení incidentu je nutné pˇrípadné vˇetší zmˇeny zdokumentovat na odpovídajících stránkách v systému Atlassian Confluence. Dalším typem požadavku je zmˇenový požadavek (change request). Tento požadavek je zpracován témˇerˇ stejnˇe jako incident. Zmˇeny jsou však chápány jako vícepráce, zákazník jejich implementaci tedy platí. Tento proces je vnímán servisním oddˇelením jako vydaˇrený a tým na nˇem nechce nic zásadního mˇenit. Proces také vyhovuje zákazníkum, ˚ kteˇrí jsou s ním seznámeni a používají jej. Rozdˇelování práce a rˇízení kapacit Proces pˇridˇelování práce je velmi volný. Vývojáˇri jsou sami schopni ohodnotit prioritu úkolu˚ a pˇridˇelují si tedy práci sami. v pˇrípadˇe krizových situací žádají o pomoc servisního manažera. Pokud servisní tým nemá další volné vývojáˇrské kapacity, servisní manažer žádá o uvolnˇení dalšího lidského zdroje z vývojového oddˇelení. Proces sestavení aplikace, uvolnˇení a nasazení Pˇri implementaci opravy chyby je zdrojový kód udržován v systému pro správu a verzování zdrojových kódu, ˚ konkrétnˇe v repozitáˇri Apache Subversion. Všechny pˇríspˇevky (commity) do tohoto systému musí být propojeny s tiketem v systému JIRA. Je pak dobˇre dohledatelné, které commity vedly k opravení dané chyby a naopak – která chyba byla opravena daným commitem. Až má vývojáˇr chybu opravenu, sestaví aplikaci na lokálním prostˇredí. Pokud existuje testovací prostˇredí, aplikaci tam nasadí a otestuje. Poté nechá otestovat chybu zákazníkem. Pokud chyba není opravena podle zákazníkových pˇredstav, proces se opakuje. Až je zákazník spokojen, vývojáˇr s ním domluví datum nasazení do produkˇcního prostˇredí. Spoleˇcnost na vˇetšinˇe servisních projektu˚ nemá domluveny žádné pravidelné nasazovací termíny. Nasazování probíhá dle domluvy s konkrétním zákazníkem. 18


v pˇrípadˇe malých zmˇen je zákazník vˇetšinou ochoten poˇckat s nasazením do doby, až bude potˇreba nasadit více zmˇen naráz. Pˇred nasazením je ve verzovacím systému vytvoˇren tzv. tag – uchová se pˇresná verze, která bude nasazena na produkci. Tagy jsou cˇ íslovány porˇ adovým cˇ íslem. Následnˇe je tag sestaven a nasazen do produkˇcního prostˇredí. Pro nˇekteré projekty existují v tomto procesu ruzné ˚ odchylky: •

Na nˇekterých projektech neexistuje testovací prostˇredí (nejˇcastˇeji z duvodu, ˚ že se zákazníkovi nechce platit za další „zbyteˇcné“ prostˇredí), pˇrípadnˇe se jako testovací prostˇredí používá nˇejaká ménˇe používaná cˇ ást systému. v tomto pˇrípadˇe neprobˇehne cˇ ást procesu s testováním na testovacím prostˇredí, ale oprava je rovnou nasazena do produkˇcního prostˇredí, kde ji teprve vývojáˇr, a následnˇe i zákazník, testuje.

•

Nˇekteré projekty mají proces nasazování pravidelný (tzn. existuje tzv. okénko údržby – maintenance window, ve kterém se poˇcítá s nedostupností systému). v tomto pˇrípadˇe se snaží vývojáˇr domluvit se zákazníkem tak, aby nasazení probˇehlo v tomto okénku, není to však nutné.

•

Na nˇekterých projektech se nejedná o vývoj komponent, ale o konfiguraci systému. Na tˇechto projektech neexistuje testovací prostˇredí, takže konfigurace probíhá pˇrímo na produkˇcním prostˇredí. O tomto stavu ví zákazník i vývojáˇri, je známo, že toto rˇ ešení není ideální. Bohužel zákazník nechce investovat prostˇredky do spuštˇení a udržování testovacího prostˇredí.

Kontinuita a úrovenˇ služeb Jednou roˇcnˇe se sbírá zpˇetná vazba od zákazníku˚ Spoleˇcnosti. Ta je poté analyzována a v pˇrípadˇe nespokojenosti zákazníku˚ jsou analyzovány pˇrícˇ iny této nespokojenosti. Ve firmˇe probˇehlo nedávno sjednocení forem SLA, vylepšení se také dosáhlo ve zmˇenˇe úˇctování – servisní oddˇelení momentálnˇe funguje v módu „time and material“ oproti dˇrívˇejšímu „fixed time, fixed price“. Žádné složitˇejší metriky sledovány pravidelnˇe nejsou. 19


4.3

Používané nástroje

Apache Subversion Apache Subversion (dˇríve Subversion) je systém pro správu a verzování zdrojových kódu. ˚ Nahrazuje dˇrívˇejší systém CVS. Mezi základní funkce, které Subversion poskytuje, patˇrí: •

uchovávání historie veškerých provedených zmˇen

•

centralizace správy zdrojových kódu. ˚ Kód je spravován na serveru, klientské stanice pracují s jeho lokálními kopiemi

•

umožnˇení správy kódu ruzných ˚ verzí systému

•

možnost vytváˇrení tagu˚ – tj. zafixování konkrétních verzí systému

•

a další

Nástroj Subversion je celosvˇetovˇe používán ve velkém množství firem. v nˇekterých spoleˇcnostech je již považován za pˇrekonaný a zastaralý. Nicménˇe ve Spoleˇcnosti má z historických duvod ˚ u˚ stále své místo. Zamˇestnanci s ním umí pracovat a jsou na nˇej zvyklí. Atlassian JIRA Atlassian JIRA je nástroj pro podporu rˇ ízení projektu˚ a požadavku. ˚ Nabízí flexibilní uživatelské nástroje pro rˇ ízení a sledování postupu prací v pru˚ bˇehu plnˇení úkolu. Systém lze navíc propojit s dalšími stˇežejními produkty, jako napˇr. Subversion nebo Confluence. Hlavními výhodami je široká funkcionalita, vˇcetnˇe: •

definice vlastních workflow všech tiketu˚

•

podpory projektového rˇ ízení pomocí plánování iterací, uvolnˇení aplikací apod.

•

sledování a vyhodnocování kapacit

•

sdílení komunikace v rámci týmu i se zákazníkem

•

rˇ ešení oprávnˇení (v týmu i se zákazníkem)

•

prioritizace, termínu, ˚ odhadu˚ pracnosti

•

fulltextového vyhledávání v tiketech 20


•

statistik, reportu, ˚ filtrování tiketu˚

•

projektové i osobní nástˇenky

Nástroj JIRA je používán i ve velkých softwarových firmách. Zamˇestnanci Spoleˇcnosti s ním rádi pracují, systém je navíc používán i jedním ze stˇežejních partneru˚ Spoleˇcnosti – pro vývoj produktu Liferay. Spoleˇcnost používá poslední verzi nástroje, má pro nˇej dokonce vyvinuty vlastní doplnky ˇ (napˇr. nástroj pro sdílení zdroju˚ napˇríˇc ruznými ˚ projekty). Atlassian Confluence Další z rˇ ady nástroju˚ od firmy Atlassian – Confluence – je nástroj pro sdílení dokumentu. ˚ Jedná se vlastnˇe o systém, ve kterém každý, kdo má potˇrebná práva, muže ˚ jednoduše editovat uložené dokumenty, komentovat je, sledovat jejich starší verze. Confluence je velmi dobˇre propojena se systémem JIRA. Alfresco Pro správu statických dokumentu˚ a dalších projektových artefaktu˚ se ve Spoleˇcnosti používá systém Alfresco. Systém obsahuje úložištˇe obsahu, rˇ eší oprávnˇení a verzování dokumentu. ˚

21

5 Analýza pˇrínosu ITIL V této kapitole si spojíme poznatky z pˇredchozích tˇrech kapitol. Budeme se zabývat propojením znalostí o servisních oddˇeleních obecnˇe, knihovnou ITIL a servisním oddˇelením ve Spoleˇcnosti. Výstupem této kapitoly je sada doporuˇcení, která jsou v následující kapitole zavedena do projektu Implementace ITIL ve Spoleˇcnosti. Spoleˇcnost má popsány procesy, se kterými prošla certifikací ISO 20000. Jsou velmi dobˇre zdokumentovány a víceménˇe odpovídají realitˇe. Spoleˇcnost chtˇela procesy implementovat formou „shora“ – tj. nejdˇríve definovat proces a poté se ho snažit dodržovat. Tento zpusob ˚ má výhodu v tom, že proces je dobˇre definovaný už od zaˇcátku. Nevýhodou je, že se zavádí v podstatˇe od nuly. Naproti tomu postup „zdola“, který se bude snažit prosadit autor této práce, nejdˇríve zmapuje aktuální procesy a zformalizuje je, najde v nich slabiny a postupným vylepšováním se je bude snažit odstranit. V následujících kapitolách autor práce, na základˇe pˇredchozí analýzy jak servisních oddˇelení, tak konkrétního servisního oddˇelení Spoleˇcnosti, rozebírá kapitoly ITIL z pohledu servisního oddˇelení. Snaží se o co nejpˇresnˇejší výtah informací, které jsou potˇreba pˇri rˇ ízení servisního oddˇelení. Tyto kapitoly pak mohou sloužit servisním manažerum ˚ malých až stˇrednˇe velkých servisních oddˇelení jako opˇerný bod pˇri prvotní implementaci ITIL.

5.1

Návrh služeb

Návrh služeb se zabývá všemi aspekty, které je nutno vzít v potaz pˇri návrhu nové služby. ˇ Rízení úrovnˇe služeb Cílem této kapitoly je nastavení správných vztahu˚ s byznysem a zákazníky, mˇerˇ ení a monitorování úrovnˇe poskytovaných služeb, sledování a zlepšování spokojenosti zákazníku. ˚ S tím souvisí revize a pˇrípadné pˇrenastavení SLA, kontrola plnˇení SLA, rˇ ízení stížností i pochval. Ihned po podepsání a odsouhlasení SLA je tˇreba zaˇcít monitorovat, zda jsou podmínky SLA splnovány. ˇ Je vhodné mít se zákazníkem domluvenou formu a frekvenci pravidelných reportu. ˚ S tˇemito reporty je vhodné provádˇet také revizi služeb. Pro zlepšení spokojenosti zákazníka je zásadní, aby si servisní manažer vyvinul dobré vztahy s klíˇcovými lidmi na stranˇe zákazníka. 22

ˇ 5. A NALÝZA P RÍNOSU ITIL

V servisním oddˇelení Spoleˇcnosti SLA pokrývají službu podpory aplikací. SLA jsou definované jednoznaˇcnˇe a v souladu s normou ISO 20000. Doporuˇcení autora práce: D1: Nastavit si pravidelné reporty a revize plnˇení SLA a tyto výsledky komunikovat zákazníkovi. ˇ Rízení kapacit Cílem rˇ ízení kapacit je zajistit co možná nejideálnˇejší využití zdroju, ˚ tedy neplýtvat zdroji a zárovenˇ pˇredcházet situacím, ve kterých je zdroju˚ nedostatek. Jedná se jak o lidské zdroje, tak o napˇr. hardware. Kapacitní plán je vytváˇren pomocí sady kroku: ˚ •

revize stávajícího stavu kapacit

•

vylepšení stávajících kapacit

•

zhodnocení, odsouhlasení a zdokumentování nových kapacit

•

plán nových kapacit

V této fázi je duležitá ˚ pˇredpovˇed’ zátˇeže ze strany zákazníka. Pokud napˇr. servisní tým ví, že zákazník migruje své stroje na jiný operaˇcní systém, dá se oˇcekávat zvýšený poˇcet incidentu˚ a požadavku. ˚ Procesu pˇredpovˇedi také muže ˚ pomoci sledování trendu˚ poˇctu incidentu˚ a zmˇenových požadavku. ˚ V servisním oddˇelení Spoleˇcnosti momentálnˇe žádný plán kapacit neexistuje. Vzhledem k malé velikosti servisního oddˇelení je kapitola rˇ ízení kapacit v ITIL vnímána autorem této práce jako zbyteˇcnˇe obšírná. Doporuˇcení autora práce: D2: Vytvoˇrit plán aktuálních kapacit všech zdroju. ˚ Tento plán odsouhlasit se senior managementem. D3: Nastavit proces pravidelné revize plánu a vytváˇrení nového na základˇe zmˇen, které se v daném období udály. ˇ Rízení kontinuity služeb Cílem rˇ ízení kontinuity služeb je zajištˇení pokraˇcování fungování služby v pˇrípadˇe výpadku do doby stanovené v SLA. Zamˇerˇ uje se na správu a údržbu plánu˚ obnov, vytváˇrí analýzy rizik, hodnotí zmˇeny z pohledu zotavovacích plánu˚ a vyjednává se zákazníky ohlednˇe tˇechto plánu. ˚ Plány obnov je vhodné navrhnout pro ruzné ˚ typy rizik, od výpadku proudu, pˇres chybu databáze až po pˇrípad požáru. 23


Doporuˇcení autora této práce: D4: Vytvoˇrit pro každý projekt scénáˇre obnovy.

5.2

Pˇrechod služeb

Plánování pˇredání a podpora Tato kapitola si klade za cíl plánování konkrétních zdroju˚ pro sestavení, uvolnˇení, testování a nasazení novˇe upravené služby do produkˇcního prostˇredí. Dále se soustˇredí na problémy a rizika pˇredávání s cílem doruˇcení služby v dohodnutém cˇ ase v dohodnuté kvalitˇe. v kapitole se rozebírá mimo jiné režie spojená s uvolnˇením nové verze. Tento problém si zde rozebereme ˇ více do detailu v další cˇ ásti této kapitoly - Rízení uvolnˇení a nasazení. V celé kapitole se rozebírá obecnˇe nasazování. Není zde na rozdíl od Spoleˇcnosti rozlišeno prvotní nasazení od dalšího servisního nasazení. Ve Spoleˇcnosti první nasazení provádí vývojový tým stejnˇe jako podporu v zaˇcátcích projektu. Pˇri nasazení je podle ITIL tˇreba zvážit následující (vypíchnuty pouze body týkající se Spoleˇcnosti): 1.

interní standardy – je tˇreba postupovat podle interních firemních procesu˚

2.

nasazení se mají úˇcastnit strany: (a)

tˇretí strany dodavatelu˚ a všechny zúˇcastnˇené strany

(b) zákazník a jeho uživatelé (c) 3.

poskytovatel služby (Spoleˇcnost)

pro nasazení služby je tˇreba pˇripravit: (a)

plán v souladu s interními procesy

(b) role a zodpovˇednosti (c)

znovu použít zkušenosti a nástroje pro nasazení z jiných projektu˚

(d) sdílení zdroju˚ pro dobu nasazení 4.

naplánování pˇredání znalostí

5.

výstupy z nasazení by mˇely obsahovat: (a)

plány nasazení 24


(b) plány zmˇenového a konfiguraˇcního rˇ ízení (c)

plány a dokumentace dalších uvolnˇení

(d) testovací plán a výstup z testování

6.

(e)

návod na sestavení

(f)

návod na nasazení

finanˇcní plány nasazení

Samotné nasazení má probíhat v následujících krocích: •

získání všech konfiguraˇcních položek a komponent

•

sestavení a otestování

•

testovací nasazení

•

zajištˇení pˇripravenosti podpory pro pˇrípad nezdaru

•

nasazení

•

podpora v zaˇcátcích (early life support)

•

kontrola a uzavˇrení procesu

Podle tohoto procesu probíhá ve Spoleˇcnosti pouze prvotní nasazení vývojovým týmem. Rozdíl je v tom, že se servisní tým neúˇcastní samotného nasazení, ale úˇcastní se až dalších servisních nasazení v dobˇe, kdy vývojový tým projekt pˇredal do servisu. ITIL doporuˇcuje sledování metrik (výbˇer metrik relevantních pro Spoleˇcnost): •

poˇcet nasazení, které kompletnˇe splnovaly ˇ oˇcekávání zákazníka

•

snížení poˇctu tiketu˚ souvisejících se špatnˇe naplánovaným pˇredáním projektu

•

snížení rozdílu mezi odhadovanými a skuteˇcnými náklady na nasazení

•

spokojenost týmu s procesem nasazování 25


Doporuˇcení autora této práce týkající se této kapitoly ITIL: D5 - Servisní tým by se mˇel aktivnˇe zapojit už od fáze prvního nasazení projektu. Mˇel by rˇ ešit spolu s vývojovým týmem prvotní nasazení. Vývojový a servisní tým by mˇely spolupracovat pˇri podpoˇre v rané fázi servisního projektu. D6 - Pˇri pˇrebírání do servisního oddˇelení by mˇel servisní tým kontrolovat existenci výstupu˚ z prvotního nasazení, tj. bodu˚ 5.a. až 5.f. ze seznamu v této kapitole. ˇ Rízení zmˇen ITIL zmˇenu definuje jako „pˇridání, modifikace nebo odstranˇení podporované služby nebo její komponenty a související dokumentace“[Cab05]. Zmˇeny mohou vznikat z ruzných ˚ duvod ˚ u: ˚ •

proaktivnˇe – hledání byznys výhod – snižování výdaju, ˚ zlepšování služeb

•

reaktivnˇe – rˇ ešení problému˚ a chyb, pˇrizpusobování ˚ se novým okolnostem

ˇ Rízení zmˇen si klade za cíl odstranit co nejvíce rizik se zmˇenami spojených, snížit vážnost pˇrípadných problému˚ a pˇri implementaci zmˇeny uspˇet už napoprvé. Standardizace rˇ ízení zmˇen napˇríˇc všemi servisními projekty pak má pomoci k rychlejšímu rˇ ešení zmˇen a také k jednodušší zastupitelnosti cˇ lenu˚ servisního týmu. Pˇridaná hodnota pro byznys z pohledu rˇ ízení zmˇen vzniká hlavnˇe v: •

prioritizaci a odpovídání na zmˇenové požadavky zákazníku˚

•

implementaci zmˇen pro zákazníka

•

snižování poˇctu nepovedených zmˇen a tím pádem zvyšování kvality a dostupnosti služby

•

sledování vývoje zmˇen s cílem vytipovat zmˇeny pro zlepšení byznysu

•

zvyšování produktivity zamˇestnancu˚ v dusledku ˚ snížení poˇctu rˇ ešení kritických incidentu˚

ˇ Rízení zmˇen se v servisním oddˇelení týká hlavnˇe zmˇenových požadavku˚ ze strany zákazníka. Ve Spoleˇcnosti se tak dˇeje pomocí vytvoˇrení tiketu v systému JIRA. ITIL zmˇenový požadavek definuje jako formální komunikaci, která požaduje zmˇenu jedné nebo více konfiguraˇcních položek. 26


Zmˇenové rˇ ízení také rˇ eší, jak se vyhnout neautorizovaným zmˇenám – napˇríklad situace, kdy zákazník nˇeco podstatného zmˇení, ale nijak zmˇenu nekomunikuje dodavateli. Takovéto zmˇeny dost cˇ asto vedou k nedostupnosti služby a tedy i k nespokojenosti zákazníka. Typické zmˇenové požadavky (standard changes), jak je prezentuje ITIL, dobˇre vystihují zmˇenové požadavky, jaké rˇ eší servisní tým Spoleˇcnosti. Jde o požadavky, které jsou iniciovány zákazníkem. Jde vˇetšinou o známý problém, prostˇredí je zdokumentované. Jedná se o malé zmˇeny, které nepodléhají žádnému formálnímu schvalovacímu procesu. Zmˇeny platí zákazník ze svého rozpoˇctu, pˇrípadnˇe jsou zmˇeny placeny formou paušálních víceprací v rámci SLA. Riziko zmˇen je malé. Ve Spoleˇcnosti existuje proces zmˇenového rˇ ízení. v servisním oddˇelení se jím ale rˇ ídí pouze velké zmˇeny. Ani ty ale dokonce nepodléhají formálnímu schválení ze strany Spoleˇcnosti. Vývojáˇr odhadne na základˇe svého úsudku (vˇetšinou po poradˇe s nˇekým z puvodního ˚ vývojového týmu) cˇ asovou nároˇcnost zmˇeny a po schválení zákazníkem zmˇenu implementuje. Takovéto rˇ ešení pˇrináší úsporu cˇ asu ze strany Spoleˇcnosti kvuli ˚ absenci schvalování. Nicménˇe s sebou nese riziko, že zmˇena byla špatnˇe odhadnuta nebo byl špatnˇe stanoven dopad na ostatní cˇ ásti aplikace. Zmˇeny navíc nepodléhají testovacímu procesu. Metriky, které jsou v servisním oddˇelení použitelné pro vyhodnocení zmˇenových požadavku, ˚ mohou být: •

poˇcet vytvoˇrených zmˇenových požadavku˚

•

poˇcet incidentu˚ vztahujících se ke zmˇenovým požadavkum ˚

•

poˇcet neautorizovaných zmˇen (tj. zmˇen, o kterých nebyla Spoleˇcnost informována)

•

objem práce na zmˇenových požadavcích.

Doporuˇcení autora této práce: D7 - v systému JIRA odlišit zmˇenové požadavky od incidentu. ˚ Cílem by mˇelo být lepší reportování – bude patrný rozdíl mezi zmˇenou a incidentem. Dále bude možné propojovat tikety incidentu˚ s tikety zmˇenových požadavku. ˚ D8 - Se zákazníkem komunikovat a nastavit, jak se budou rˇ ešit problémy, které zpusobí ˚ systém tˇretí strany. Ideálnˇe nastavit komunikaci i s tˇemito tˇretími stranami. D9 - Zavést povinné schvalování zmˇenových požadavku, ˚ které mají rozsah vˇetší než X, kde X bude závislé na velikosti a typu projektu. Schvalování 27


ˇ by mˇel mít na starosti cˇ lovˇek, který je uveden v puvodním ˚ procesu Rízení zmˇen ve Spoleˇcnosti. ˇ Rízení konfigurací Cílem rˇ ízení konfigurací a výstupu˚ služeb (Service asset and configuration management) je mít pod kontrolou všechny konfiguraˇcní položky (Configuration item – CI). Konfiguraˇcní položkou je podle ITIL každá komponenta, která musí být spravována procesem rˇ ízení konfigurací, aby byla zajištˇena funkˇcnost poskytované služby. Jedná se typicky o hardware, software, budovy, lidi a formální dokumenty jako procesní dokumentace, licence nebo SLA. Konfiguraˇcní položky jsou uloženy v konfiguraˇcní databázi (Configuration management database – CMDB). Tento pˇrístup má zabezpeˇcit zlepšení v organizaci, zlepšení pˇredávání znalostí, zrychlení procesu˚ a zvýšit kvalitu rˇ ešení tiketu. ˚ Konfiguraˇcní položky vznikají spolu s vývojem projektu, postupnˇe pˇribývají a provází projekt a následnˇe i servisní projekt celým jeho životním cyklem – od poˇcátku až po finální uzavˇrení projektu. Všechny projektové procesy by mˇely být integrované s CMDB, tj. napˇríklad pˇri povýšení operaˇcního systému na testovacím prostˇredí je potˇreba tuto zmˇenu reflektovat na pˇríslušné místo CMDB. Je duležité, ˚ aby CMDB byla jediné místo, kde se tyto informace uchovávají. Pokud by takovýchto databází bylo více, hrozilo by riziko, že v jedné z nich nebudou aktuální data, což by mohlo pusobit ˚ problémy. Konfiguraˇcní databáze muže ˚ sestávat z nˇekolika ruzných ˚ nástroju. ˚ Pokud je tomu tak, je nutné, aby konfiguraˇcní procesy byly nastaveny tak, aby nebyly informace duplikovány. Je vhodné monitorovat procesy spojené se zavedením CMDB. ITIL doporuˇcuje k tomuto tématu následující metriky: •

zvýšená rychlost pˇri rˇ ešení incidentu, ˚ které se týkají identifikace špatných konfiguraˇcních položek

•

dopad incidentu, ˚ které se týkají konkrétních typu˚ konfiguraˇcních položek od konkrétních dodavatelu˚

•

pomˇer licencí, které jsou používány, a koupených licencí (mˇelo by se blížit 100%)

•

ménˇe problému˚ zpusobených ˚ tím, že lidé pracují se zastaralými informacemi

•

rychlejší a kvalitnˇejší audity 28


•

snížení cˇ asu a ceny pˇri diagnóze a rˇ ešení incidentu˚ a problému˚

•

poˇcet nesrovnalostí objevených pˇri auditu

•

poˇcet problému˚ zpusobených ˚ špatným zhodnocením dopadu (impact analysis) nebo problémy s verzemi aplikací

Ve Spoleˇcnosti je momentálnˇe CMDB ve vývoji. Podle ITIL ale hrozí pˇri implementaci urˇcitá rizika. Pˇresvˇedˇcit všechny zúˇcastnˇené strany, aby CMDB vytváˇrely a udržovaly, je velkou výzvou a nemusí se pˇri implementaci podaˇrit. Pokud se sebere do CMDB pˇríliš mnoho dat, muže ˚ se stát, že se v nich pak zamˇestnanci „utopí“ a nebudou databázi chtít používat. Management ostatních oddˇelení muže ˚ být málo motivovaný CMDB udržovat. Dalším rizikem je zvolení špatné technologie. Je duležitˇ ˚ ejší mít CMDB funkˇcní než použít pˇríliš sofistikovaný nástroj, který je v praxi k niˇcemu. Je také dule˚ žitá pravidelná revize CMDB, protože pˇrípadné chyby, které dezinformace muže ˚ zpusobit, ˚ mohou stát pˇri jejich opravách velké množství prostˇredku. ˚ CMDB muže ˚ zastarávat díky tomu, že osoba, která o CMDB neví, provádí zmˇeny (typicky pˇresun hardwaru) a nereflektuje je do CMDB. Proto by mˇel vzniknout proces pulroˇ ˚ cních kontrol aktuálnosti CMDB. Doporuˇcení autora této práce: D10 - Implementovat CMDB podle aktuálnˇe nastavených pravidel. D11 - Nastavit proces pravidelných kontrol aktuálnosti CMDB. D12 - Nastavit vhodný komunikaˇcní kanál se zákazníkem a jeho pˇrípadnými dodavateli tˇretích stran, aby ve Spoleˇcnosti v CMDB byly aktuální údaje. D13 - Motivovat všechny zúˇcastnˇené strany (servisní tým, vývojový tým, ICT oddˇelení) k údržbˇe CMDB pˇri výskytu jakékoli zmˇeny. ˇ Rízení uvolnˇení a nasazení ˇ Rízení uvolnˇení klade duraz ˚ na definici a odsouhlasení nasazovacího plánu se zákazníkem a dalšími zúˇcastnˇenými stranami. Každý uvolnˇený balíˇcek musí sestávat ze vzájemnˇe kompatibilních verzí komponent, všechny balíˇcky jsou dohledatelné a v pˇrípadˇe chyby musí být nahraditelné pˇredchozí fungující verzí. Je tˇreba nastavit správný kanál pro pˇredání znalostí smˇerem k zákazníkovi, co se týˇce nových verzí balíˇcku, ˚ stejnˇe tak jako pˇredání znalostí smˇerem k servisnímu týmu. Pro byznys má rˇ ízení uvolnˇení hlavní cíl – dˇelat uvolnˇení a nasazení efektivnˇe, správnˇe a s co nejménˇe riziky. Všechny uvolnˇení aplikace by mˇely mít unikátní identifikátor, který je poté použit rˇ ízením konfigurací. Typy uvolnˇení by mˇely být pˇredem defi29


nované, aby zákazník a další zúˇcastnˇené strany mˇely v tomto ohledu reálná oˇcekávání. ITIL uvádí typický pˇríklad: •

významné uvolnˇení (major release) – obsahuje velké zmˇeny ve funkcionalitˇe. Muže ˚ obsahovat opravy narychlo opravených urgentních chyb. Je duležitˇ ˚ ejší než malé uvolnˇení.

•

malé uvolnˇení (minor release) – obsahuje malé zmˇeny

•

mimoˇrádné uvolnˇení (emergency release) – opravuje zmˇeny duležité ˚ pro byznys

ITIL doporuˇcuje tato uvolnˇení (release) mít naplánována, napˇr. významné uvolnˇení jednou za 6 mˇesícu, ˚ malé uvolnˇení jednou za mˇesíc a mimoˇrádné uvolnˇení podle potˇreby. Ve spoleˇcnosti momentálnˇe funguje uvolnˇení ve formˇe mimoˇrádného uvolnˇení – tedy servisní oddˇelení nasazuje balíˇcky obsahující malý poˇcet opravených chyb. Konkrétní vývojáˇr vždy se domlouvá se zákazníkem na dobˇe nasazení. Ve Spoleˇcnosti se vˇetšinou v servisním režimu uvolnuje ˇ jen jedna komponenta. v pˇrípadˇe, že jich je více, je tˇreba definovat, jak pro konkrétní komponentu bude uvolnˇení probíhat vˇcetnˇe nastavení správných verzí. Po nasazení je nutné aktualizovat informace v CMDB. Sestavení aplikace by mˇelo zabrat co nejménˇe cˇ asu. Pokud se sestavení pro produkˇcní (testovací) a vývojové prostˇredí liší, je nutné, aby pro každý typ prostˇredí existoval jeden pˇríkaz, kterým se aplikaˇcní balíˇcek sestaví. Pˇred nasazením nové verze aplikace je tˇreba zajistit možnost vrátit se do puvodního ˚ stavu aplikace. Proto je tˇreba pokaždé provést zálohu databáze a zajistit, že je k dispozici puvodní ˚ verze aplikace. Doporuˇcení autora práce: D14 - Zavést na všech projektech sestavování aplikace (pro každé prostˇredí) jedním pˇríkazem. D15 - Nastavit pravidelná okénka pro uvolnˇení – jejich cˇ etnost záleží na konkrétních projektech. D16 - Zavést na všech projektech v systému JIRA systém pro evidenci jednotlivých nasazení do produkˇcního prostˇredí. Incidenty a problémy zanesené v systému pak propojit s tˇemito nasazeními. v pˇrípadˇe, že bude nasazování probíhat pravidelnˇe, bude propojení velmi snadné. D17 - Sestavené aplikace by mˇely obsahovat informace o verzi a revizi ze Subversion. Každé další nasazení do produkˇcního prostˇredí by mˇelo zvyšovat verzi aktuálnˇe nasazované aplikace. 30


D18 - Pˇri nasazení balíˇcku do produkˇcního prostˇredí zajistit zálohu tohoto balíˇcku. Díky tomu bude možné znovu nasadit starší balíˇcek v pˇrípadˇe chyby. Pro databázové skripty je tˇreba krom skriptu˚ s úpravou také vytvárˇ et skripty, které danou úpravu vrátí do puvodního ˚ stavu. Tyto skripty je také nutné testovat ještˇe pˇred nasazením do produkˇcního prostˇredí. D19 - Pˇri nasazení do produkˇcního prostˇredí je tˇreba vytvoˇrit zálohu aktuálního prostˇredí. Tyto zálohy by mˇely být jednoznaˇcnˇe pojmenovány a uloženy na definované místo. Validace a testování služeb Cílem validace a testování je zajištˇení odpovídající kvality služeb a tím snížení poˇctu incidentu˚ a problému, ˚ které zákazník hlásí. Ruku v ruce s kvalitou jde i spokojenost zákazníka, protože mu projekt poskytuje vysokou pˇridanou hodnotu. Naopak pokud zákazník vidí v dodaném produktu chyby, je nespokojený a má duvod ˚ zvažovat jiného dodavatele služeb. V servisním oddˇelení Spoleˇcnosti momentálnˇe nefiguruje žádný tester. Testování probíhá na testovacích prostˇredích a provádí ho testeˇri zákazníku. ˚ Na nˇekterých projektech testovací prostˇredí není zavedeno vubec. ˚ ITIL se v této kapitole testování vˇenuje pomˇernˇe obšírnˇe. Co je duležité ˚ pro Spoleˇcnost a její servisní oddˇelení je myšlenka zavedení testování pˇred každým nasazením do produkˇcního prostˇredí. Doporuˇcení autora práce: D20 - v procesu uvolnˇení a nasazení zavést povinné otestování jak testerem ze Spoleˇcnosti, tak testery na stranˇe zákazníka s cílem zlepšit aplikaci pˇri nasazení do produkˇcního prostˇredí. Je tˇreba zvážit, od jakých objemu˚ práce se tester vyplatí. Je pravdˇepodobné, že u zmˇen malého charakteru se bude testování zbyteˇcnˇe prodražovat. ˇ Rízení znalostí Cílem rˇ ízení znalostí je zaruˇcit, že servisní tým má všechny potˇrebné informace pro výkon své práce, pˇrípadnˇe že je schopen tyto znalosti dohledat, cˇ lenové týmu jsou schopni se správnˇe rozhodovat a efektivnˇe zasahovat v pˇrípadˇe incidentu˚ a problému. ˚ Prvním krokem k uchopení rˇ ízení znalostí je analýza aktuálního stavu znalostí v rámci týmu v porovnání se znalostmi týmu, který projekt implementoval. Pokud se zde nachází velký rozdíl ve znalostech, je tˇreba zjistit jeho rozsah. Až je známo, jaké znalosti je tˇreba pˇredat, je nutné samotné pˇredání naplánovat. Typicky se jedná o formu klasických pˇrednášek a sadu 31


dokumentu. ˚ Je duležité, ˚ aby veškeré pˇredávání znalostí probíhalo se zamˇerˇ ením na skuteˇcné potˇreby servisního týmu. Tedy napˇr. pokud pˇredáváme znalosti ohlednˇe programování javascriptových komponent, je tˇreba se zamˇerˇ it na to, jak se s nimi pravdˇepodobnˇe bude setkávat servisní tým – tedy napˇr. se pˇri pˇredávání zamˇerˇ it na jejich ladˇení, upozornˇení na typické problémy apod. Pˇri pˇredávání projektu servisnímu týmu je duležité ˚ pˇredat informace o tom, jak zákazník plánuje systém používat. Servisní tým se poté bude moci rozhodovat tak, aby zákazníkovi pˇrinesl co nejvˇetší pˇridanou hodnotu. Znalosti by také mˇely být pˇredány pˇri odevzdání produktu zákazníkovi. Školení uživatelu˚ nejen pˇrinese snížení poˇctu problému˚ servisnímu oddˇelení, ale také zvýší spokojenost s vyvinutým produktem, a to jak u uživatelu, ˚ tak i u vedení. Také by mˇela vzniknout databáze kontaktu, ˚ kde budou uloženy kontakty na všechny zodpovˇedné osoby na stranˇe zákazníka. Databáze by mˇela vznikat už v dobˇe vývoje puvodního ˚ projektu a pak se v servisní fázi jen rozvíjet. Duležitou ˚ cˇ ástí rˇ ízení znalostí je správa databáze známých erroru˚ (known errors database). Pˇri pˇredání projektu zákazníkovi by mˇela vzniknout databáze známých erroru, ˚ která obsahuje problémy a jejich rˇ ešení (nebo workaroundy). Mˇerˇ itelné faktory jsou: •

poˇcet chybˇejících znalostí v rámci týmu

•

snížení cˇ asu potˇrebného k podpoˇre

•

spokojenost koncových uživatelu˚ se systémem

Doporuˇcení autora práce: D21 - Analyzovat chybˇející znalosti v týmu a následnˇe naplánovat, jak tyto znalosti budou doplnˇeny pomocí školení v rámci Spoleˇcnosti. U školení si dát pozor na cíl školení – školitelé by se mˇeli zamˇerˇ it na pˇredem pˇripravené problémy, které servisní oddˇelení nejˇcastˇeji rˇ eší. D22 - Nastavit proces pˇredávání projektu tak, aby už v nˇem vznikla databáze známých problému, ˚ kterou pak bude servisní tým rozšiˇrovat. Zárovenˇ zajistit, aby v tomto procesu bylo zahrnuto školení koncových uživatelu˚ na stranˇe zákazníka. D23 - Znalosti by mˇely být pˇredány také formou dokumentace. Tu by mˇel servisnímu týmu dodat vývojový tým. Pro jednoduchost by se servisní oddˇelení mˇelo snažit o implementaci jednoduchého vyhledávání nad všemi systémy, ve kterých se znalosti vyskytují. 32


5.3

Provoz služeb

Kniha Provoz služeb (Service Operation) popisuje, co se dˇeje a rˇ eší na úrovni uživatelské podpory, jak probíhá rˇ ízení problému˚ a incidentu˚ v každodenním životˇe služby. ˇ Rízení událostí Událost je cokoli detekovatelného nebo zjistitelného, co má vliv na rˇ ízení IT infrastruktury nebo na správný chod služeb. Události typicky vytváˇrí služba, konfiguraˇcní položka nebo monitorovací nástroj. Efektivita servisního oddˇelení výraznˇe závisí na schopnosti tyto události sbírat a reagovat ˇ na nˇe. Rízení událostí poskytuje nástroje pro rychlé zjištˇení incidentu. ˚ Muže ˚ se tak stát, že je incident odstranˇen, aniž by došlo k pˇrerušení služby. Vˇetšinou se bohužel problémy a incidenty rˇ eší reaktivnˇe a na základˇe špatných zkušeností se teprve nastavují pravidla rˇ ízení událostí. Mezi typické úlohy rˇ ízení událostí patˇrí: •

kontrola stavu nˇekteré z konfiguraˇcních položek (typicky server musí bˇežet – tedy napˇr. musí reagovat na „ping“)

•

monitorování vypršení licencí a certifikátu˚

•

bezpeˇcnost (detekce neautorizovaného pˇrístupu)

•

normální aktivita (sledování, že služba bˇeží)

Pojem rˇ ízení událostí je velmi podobný pojmu monitorování. Monitorování ˇ je širší pojem než rˇ ízení služeb. Rízení služeb se zamˇerˇ uje na generování a detekci smysluplných oznámení o stavu IT infrastruktury a služeb. Naproti tomu monitorování se zamˇerˇ uje i na sledování stavu zaˇrízení, které žádné události negeneruje. V servisním oddˇelení je tˇreba vˇedˇet o všech výjimeˇcných stavech, které se i nepˇrímo týkají podporované aplikace. v ideálním pˇrípadˇe je vhodné implementovat následující: •

upozornˇení na událost – napˇr. monitorovací nástroj kontroluje danou konfiguraˇcní položku nebo sama konfiguraˇcní položka generuje upozornˇení

•

detekce událostí – když je na událost upozornˇeno, musí být událost detekována agentem bˇežícím na tomtéž systému 33


•

filtrování událostí – cílem je rozhodnout, které události je zapotˇrebí poslat rˇ ídicímu nástroji a které ne. v nˇekterých pˇrípadech není nutné události filtrovat

•

závažnost události – nastavení, které události nesou pouze informativní zprávy, které varují pˇred blížícím se nebezpeˇcím a které reportují nˇejaký výjimeˇcný stav

•

reakce na událost – zda se událost pouze zaloguje, pošle se upozornˇení zodpovˇedným osobám nebo se založí nový incident

V prostˇredí Spoleˇcnosti je rˇ ízení událostí momentálnˇe reprezentováno událostmi na úrovni aplikace. v každé aplikaci existují aplikaˇcní logy, které obsahují informace o ruzných ˚ událostech. Jejich úrovenˇ se však projekt od projektu liší. Nejsou definována žádná pravidla týkající se logování. Spoleˇcnost také momentálnˇe nemá zaveden žádný monitorovací standard. v dobˇe vzniku této práce probíhají první pokusy o zavedení monitoringu na jednom z duležitých ˚ projektu. ˚ Metriky správného rˇ ízení událostí mohou být napˇríklad: •

poˇcet událostí podle kategorie, podle závažnosti

•

poˇcet událostí, které potˇrebovaly lidský zásah

•

poˇcet událostí, které vedly k vytvoˇrení incidentu

•

poˇcet událostí, které byly zpusobeny ˚ existujícími problémy a známými errory

•

poˇcet opakujících se událostí

•

poˇcet událostí, které zpusobily ˚ výkonnostní problémy

•

poˇcet událostí, které zpusobily ˚ problémy s dostupností

•

poˇcet událostí v porovnání s poˇctem incidentu˚

Všechny metriky lze hodnotit krom absolutního také z procentuálního hlediska. Doporuˇcení autora práce: D24 - Zavést standardy pro logování aplikací. Na základˇe zkušeností z aktuálních projektu˚ vymyslet vhodná pravidla pro logování. Tato pravidla je tˇreba komunikovat vývojovému týmu, aby nové aplikace byly vhodnˇe pˇripraveny. Implementovat systém, který bude reagovat na závažné chyby posláním události zodpovˇedným osobám do Spoleˇcnosti. 34


D25 - Zprovoznit na všech prostˇredích vhodný monitorovací nástroj a nastavit vhodné filtrování událostí. Zajistit také všude, kde to bude možné, monitorování systému˚ tˇretích stran. D26 - v procesech vývoje nových projektu˚ je nutné, aby vývojáˇri poˇcítali s budoucím napojením na monitorovací nástroje a tˇemto nástrojum ˚ vystavili potˇrebná rozhraní. ˇ Rízení incidentu˚ V ITIL terminologii je incident definován jako neplánované pˇrerušení služby nebo snížení její kvality. Chyba konfiguraˇcní položky, která zatím ale nemˇela dopad na kvalitu služby, je také definována jako incident. Proces rˇ ízení incidentu˚ zahrnuje rˇ ešení chyb, otázek a pˇripomínek uživatelu, ˚ techniku˚ nebo automaticky detekovaných chyb z monitorovacích nástroju. ˚ Cílem rˇ ízení incidentu˚ je dostat službu zpˇet do funkˇcního stavu co nejrychleji a snížit dopad na byznys, takže jde vlastnˇe o zajištˇení co nejvyšší kvality a dostupnosti služby. Doba pro vyˇrešení incidentu se liší podle jejich priority a musí být uvedena v SLA. Všechny incidenty musí být nˇekam zapsány. Ve Spoleˇcnosti je to do systému JIRA. Každý incident by mˇel mít povinné atributy. Systém JIRA s tím, jak je nastaven ve Spoleˇcnosti, poskytuje všechny tyto atributy. Jediný rozdíl proti atributum ˚ definovaným v ITIL je naléhavost (urgency), která je zde nahrazena prioritou. Každý incident má svuj ˚ stav - otevˇrený, probíhající, cˇ ekající apod. Mˇel by urˇcitˇe konˇcit obsahovat stav „uzavˇrený”. Pˇred formálním uzavˇrením je tˇreba zvážit, zdali se problém nemuže ˚ opakovat. Pokud ano, je tˇreba vytvoˇrit související tiket problému. Problémy se dále budou rozebírat v násleˇ dující cˇ ásti Rízení problému. ˚ v pˇrípadˇe, že pro opravu incidentu je tˇreba v systému nˇeco zmˇenit, je tˇreba založit zmˇenový požadavek, který následnˇe bude rˇ ízen procesem rˇ ízení zmˇen. Je také vhodné definovat pravidla, za jakých podmínek je možné incident znovu otevˇrít a kdy je tˇreba vytvorˇ it nový. ITIL navrhuje napˇr. po dobu jednoho pracovního dne možnost znovuotevˇrení incidentu, další pracovní den už je potˇreba vytvoˇrit incident nový. v každém pˇrípadˇe je vhodné mít tato pravidla nastavena pro všechny projekty stejnˇe. Ve spoleˇcnosti je momentálnˇe každý podnˇet od zákazníka (at’ už zmˇenový požadavek nebo incident) zalogován do systému JIRA jako Požadavek zákazníka (Customer request). Tento požadavek je pak zpracováván a je mu pˇridán štítek podle typu požadavku („incident“, „change request“). 35


Pro vývojáˇrské úˇcely je ke každému takovémuto tiketu vytvoˇren další související tiket typu Úkol (Task), na kterém vývojáˇr (nebo více vývojáˇru) ˚ vykazuje práci. v pˇrípadˇe, že je incident vyˇrešen, ale nebyla nalezena jeho pˇríˇcina (root cause), je tento tiket neustále otevˇren a je mu pˇridˇelen štítek „problem“. Tím se tiket dostává do rˇ ízení problému. ˚ Tento proces je ve Spoleˇcnosti velmi dobˇre uchopen a vývojáˇri, manažeˇri i zákazníci, kteˇrí do systému incidenty reportují, ho mají dobˇre zažitý. Zatím však není implementována databáze známých erroru, ˚ která by pomohla rˇ ešit bˇežné známé ˇ problémy. Její rˇ ešení spadá do následující kapitoly Rízení problému. ˚ Metrik pro rˇ ízení incidentu˚ je velké množství. Pro malá oddˇelení, jako to ve Spoleˇcnosti, jsou zajímavé tyto: •

celkový poˇcet incidentu˚

•

poˇcet incidentu˚ v ruzných ˚ stavech (otevˇrený, uzavˇrený, probíhající)

•

procentuální zastoupení incidentu˚ podle priorit

•

prumˇ ˚ erný cˇ as reakce na incident

•

prumˇ ˚ erný cˇ as uzavˇrení incidentu

•

poˇcet znovuotevˇrených incidentu˚ a jejich pomˇer k celkovému poˇctu incidentu˚

•

poˇcet nevalidních incidentu˚

Doporuˇcení autora této práce: D27 - Definovat pravidla pro znovuotevírání incidentu˚ kvuli ˚ lepšímu reportování. D28 - Nauˇcit vývojáˇre používat databázi známých erroru, ˚ až bude implementována. Pro lepší vyhledávání v rámci již rˇ ešených incidentu˚ a problému˚ zavést snadné vyhledávání jak mezi incidenty, tak mezi problémy a známými errory. ˇ Rízení problému˚ ˇ Pokud se v ITIL mluví o problémech, je rˇ eˇc o pˇríˇcinách incidentu. ˚ Rízení problému˚ se zabývá životním cyklem tˇechto problému. ˚ Jeho hlavním cílem je problémum ˚ a incidentum ˚ pˇredcházet, eliminovat opakující se incidenty a minimalizovat dopad incidentu, ˚ kterým se pˇredejít nedá. 36


ˇ Rízení problému˚ se dˇelí na dva hlavní procesy – reaktivní a proaktivní. Proaktivní se snaží problémum ˚ pˇredcházet a vyhledávat je dˇríve než se projeví formou incidentu. ˚ Reaktivní rˇ eší problémy až nastanou, vˇetšinou jako pˇríˇciny incidentu, ˚ nebo z podnˇetu monitorovacího nástroje. Každý problém musí být zanesen do databáze problému. ˚ Ve Spoleˇcnosti tuto roli zastává systém JIRA. Problémy, stejnˇe jako incidenty, musí mít povinné atributy a správnou prioritu. Pˇri rˇ ešení problému je duležité ˚ uvést, jaké akce byly pro jeho rˇ ešení provedeny. v budoucnu pˇri rˇ ešení stejného nebo podobného problému tato informace muže ˚ vést k dramatickému zrychlení. Pokud rˇ ešení problému vyžaduje zmˇenu v systému, je tˇreba vytvoˇrit pˇríslušný zmˇenový požadavek a dále se rˇ ídit procesem rˇ ízení zmˇen. Po vyˇrešení problému je tˇreba založit záznam v databázi známých erroru. ˚ Tato databáze slouží pˇri rˇ ešení incidentu˚ jako báze znalostí, která pomáhá zefektivnit opravu chyb. Také je nutné aktualizovat záznamy v CMDB. V pˇrípadˇe závažných problému˚ (tedy problému, ˚ které mají nejvyšší prioritu) je nutné pˇri zavˇrení problému ještˇe jednou zhodnotit rˇ ešení a analyzovat: •

co bylo správnˇe a špatnˇe

•

co mohlo být pˇríštˇe rˇ ešeno lépe

•

jak zabránit opakování problému

•

zdali mˇela za problém zodpovˇednost tˇretí strana a jestli je tˇreba dalšího sledování problému

Tyto informace by mˇely být souˇcástí pˇredávání znalostí servisního týmu napˇr. na pravidelných schuzkách ˚ a mˇely by se promítnout do pˇríslušné dokumentace. Nabyté znalosti z této zpˇetné analýzy by se mˇely také komunikovat zákazníkovi – tj. jak byl problém opraven a jaké byly provedeny kroky k tomu, aby se již neopakoval. Tato komunikace pomáhá zlepšit vztah se zákazníkem a jeho spokojenost. Po ukonˇcení fáze vývoje témˇerˇ žádná aplikace není bezchybná. Pravdˇepodobnˇe se ve finálním testování objevily chyby, které nebyly natolik závažné, aby je vývojový tým opravil. Tyto chyby by mˇely být zaneseny do databáze známých erroru, ˚ protože pokud se tak nestane, je pravdˇepodobné, že zákazníci budou hlásit chyby, které budou muset být objeveny a analyzovány znovu, což výraznˇe vývoj aplikace prodražuje. Ve Spoleˇcnosti jsou problémy rˇ ešeny v systému JIRA. Známé errory momentálnˇe nejsou explicitnˇe zaznamenávány. Jako databáze známých erroru˚ slouží pouze provizornˇe historie všech incidentu˚ a problému. ˚ Krom tohoto 37


nedostatku je proces rˇ ízení problému˚ ve Spoleˇcnosti funkˇcní a dobˇre zavedený. Doporuˇcení autora: D29 - Zavést databázi známých erroru. ˚ Tuto databázi pˇri vzniku servisního projektu naplnit známými errory, které odhalí akceptaˇcní testování a které nebyly v rámci vývojového projektu rˇ ešeny. D30 - Dbát na popisování rˇ ešení u problému, ˚ protože bude základem rozvíjející se databáze známých erroru. ˚ Je vhodné motivovat vývojáˇre, aby tuto databázi používali a rozšiˇrovali. D31 - Do procesu uzavírání problému˚ pˇridat fázi vytváˇrení známého erroru. Pro problémy s nejvyšší prioritou pˇridat krok zpˇetné analýzy, která bude mít výše zmínˇené výstupy. ˇ Rízení pˇrístupu˚ Cílem rˇ ízení pˇrístupu˚ je kontrolovat pˇrístupy ke službám, tedy kontrolovat, že všechny povolané osoby mají pˇríslušné pˇrístupy a oprávnˇení, a naopak nepovolané osoby pˇrístup nemají. Zárovenˇ kontrolovat zmˇeny v tˇechto oprávnˇeních, zmˇeny ve stavech zamˇestnancu˚ (pracovník, který už pro Spoleˇcnost nepracuje, nemá mít nikam pˇrístup). Pro Spoleˇcnost je zajímavé rˇ ešení pˇrístupu˚ do: •

systému˚ Spoleˇcnosti (JIRA, Confluence, Alfresco, Subversion, intranetový portál)

•

systému, ˚ které Spoleˇcnost spravuje (prostˇredí zákazníku) ˚

•

dalších systému, ˚ kam mají zamˇestnanci Spoleˇcnosti pˇrístup (typicky prostˇredí u zákazníka)

Interní systémy mají správu oprávnˇení rˇ ešenou pomocí systému rolí. Pokud zamˇestnanec pˇrechází mezi tˇemito rolemi, odpovídajícím zpusobem ˚ se mu mˇení oprávnˇení v tˇechto systémech. Prostˇredí zákazníku˚ stejnˇe jako pˇrístupy k dalším systémum ˚ jsou sepsány v CMDB. Pˇrístupové údaje a hesla jsou pˇrístupné pouze uživatelum ˚ v dané roli. Systém oprávnˇení je certifikován pro bezpeˇcnostní normu ISO 27001, která se rˇ ízením pˇrístupu˚ zabývá do detailu. Doporuˇcení autora práce pro tuto kapitolu nejsou, systém je nastaven optimálnˇe a v souladu s doporuˇceními knihovny ITIL. 38


5.4

Neustálé zlepšování služeb

Tato kapitola ITIL se vˇenuje, jak už název napovídá, procesu zlepšování služeb. Zlepšování se musí týkat hlavnˇe efektivity (efficiency, effectiveness). Klade si tyto otázky: •

Proˇc monitorujeme a mˇerˇ íme služby?

•

Kdy skonˇcíme?

•

Používá nˇekdo tato data?

•

Potˇrebujeme tyto reporty ještˇe?

Kroky, které vedou k postupnému zlepšování služeb, jsou: •

Zjistit, co bychom mˇeli mˇerˇ it – aneb na základˇe cílu˚ a strategie firmy stanovit, kam se chceme posunout.

•

Definovat, co mužeme ˚ mˇerˇ it – z pˇredchozích metrik zjistit, které jsme schopni mˇerˇ it. Pro ty, které nejsme schopni mˇerˇ it, je dobré zjistit, co nám k jejich sledování chybí a zda by se s tím nedalo nˇeco dˇelat.

•

Získat data – pro tento bod je nutné mít zavedeny odpovídající monitorovací nástroje. Monitorují se tˇri typy metrik – technologické (aplikace, její výkon, dostupnost apod.), procesní (jak je proces efektivní, zda funguje jak má) a servisní (jak služba funguje – pro tyto metriky se používají pˇredchozí dva typy metrik). Klíˇcové jsou frekvence sbˇeru metrik, nástroje (ruˇcní sbˇer, automatizovaný) a jejich validita (napˇr. pokud je poˇcet uzavˇrených incidentu˚ vˇetší než poˇcet nahlášených incidentu, ˚ pravdˇepodobnˇe máme špatná data).

•

Zpracování dat – zde probíhá konverze dat do požadovaného formátu, tj. data se zpracují do rˇ eˇci mˇerˇ itelných KPI (Key Performace Indicator).

•

Analýza dat – data se následnˇe analyzují a vyvozují se z nich napˇr. dlouhodobé trendy, kde jsou potˇreba zmˇeny, plnˇení stanovených cílu. ˚

•

Prezentace dat – výsledky analýzy jsou dále prezentovány senior managementu a byznys oddˇelení.

•

Implementace nápravných opatˇrení – použití získaných informací k vylepšení a úpravám ve službách. 39


Výsledné reporty, které budou prezentovány, je tˇreba zamˇerˇ it na konkrétní cílovou skupinu. ITIL popisuje zlepšování služeb velmi obšírnˇe. Tato kniha je zamˇerˇ ena na daleko vˇetší spoleˇcnosti s daleko vˇetším oddˇelením uživatelské podpory, servisním oddˇelením i oddˇelením podpory interních systému. ˚ Proto z této knihy lze pro Spoleˇcnost použít pomˇernˇe malé množství informací. Doporuˇcení autora práce: D32 - Vytipovat, v cˇ em je tˇreba servisní oddˇelení zlepšit. Podle tˇechto plánovaných zlepšení stanovit potˇrebné metriky i s využitím metrik popsaných v pˇredchozích kapitolách. D33 - Nastavit pravidelné sbírání metrik a jejich pravidelnou revizi. U každé metriky by mˇel být vyhodnocen její reálný pˇrínos pro servisní oddˇelení. Pokud se zmˇení strategie oddˇelení, mˇelo by se to také promítnout ve sledovaných metrikách.

40

6 Projekt implementace ITIL V této kapitole rozebereme, jak vznikal praktický projekt implementace ITIL ve Spoleˇcnosti.

6.1

Rozsah projektu

Všechna doporuˇcení autora práce byla sepsána a byla provedena jejich revize se servisním manažerem. Výstupem této schuzky ˚ byl seznam doporucˇ ení, který je vhodné implementovat v rámci projektu. Doporuˇcení, která v projektu nefigurují, byla stažena vˇetšinou z nˇekolika duvod ˚ u: ˚ •

V prubˇ ˚ ehu vývoje práce již došlo k implementaci tˇechto doporuˇcení.

•

Autorova doporuˇcení nebyla vhodná pro implementaci.

•

Doporuˇcení již byla implementována dˇríve.

Nˇekterá doporuˇcení byla ve fázi schvalování cˇ ásteˇcnˇe implementována. Tato doporuˇcení byla do projektu zahrnuta se sníženou dotací cˇ lovˇekodní.

6.2

Logický rámec projektu

Projekt je definován pomocí metody logického rámce (logical framework), která slouží k modelování, kontrole a vyhodnocení vývojových projektu˚ [Dol09]. Metoda je založena na sepsání dokumentu logického rámce, který sestává z tabulky o cˇ tyˇrech rˇ ádcích a cˇ tyˇrech sloupcích. Uspoˇrádání a význam jednotlivých sloupcu˚ tabulky a jejích rˇ ádku˚ popisuje následující tabulka. Výhodou logického rámce je možnost ovˇerˇ ení konzistence projektových zámˇeru, ˚ cílu, ˚ výstupu˚ a aktivit.

41

6. P ROJEKT IMPLEMENTACE ITIL

Sloupec

Objektivnˇe

Zdroje informací k

Vnˇejší

intervenˇcní (strom

ovˇerˇitelné

ovˇerˇení

pˇredpoklady /

cíl˚ u)

ukazatele

Zámˇer projektu

Specifikuje, jak bude

Specifikuje, kde, kdy

Specifikuje duvod ˚

mˇerˇeno splnˇení

a kým budou získány

realizace projektu, k

zámˇeru projektu (v

informace o

cˇ emu chce projekt

rovinˇe kvality,

objektivnˇe

pˇrispˇet v rámci

kvantity a cˇ asu)

ovˇerˇitelných

firemních cílu˚

rizika

ukazatelích (napˇr. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy)

Cíl projektu



Nezbytné

Specifikuje, cˇ eho

mˇerˇeno splnˇení cíle


pˇredpoklady (mimo

chceme konkrétnˇe

projektu (v rovinˇe

informace o

naši kontrolu), které

dosáhnout, pˇrímý

kvality, kvantity a

objektivnˇe

musí být dodrženy

užitek po úspˇešné

cˇ asu)

ovˇerˇitelných

pro splnˇení zámˇeru

ukazatelích (napˇr.

projektu (v pˇrípadˇe

kde a kdy budou

splnˇení cíle)

realizaci projektu

uloženy zprávy, statistiky a jiné výstupy) Výstupy projektu



Nezbytné

Specifikuje, jak

mˇerˇeno splnˇení


pˇredpoklady (mimo

chceme výsledku

výstupu˚ projektu (v

informace o


dosáhnout, konkrétní

rovinˇe kvantity a

objektivnˇe


odevzdané produkty

cˇ asu)

ovˇerˇitelných

pro splnˇení cíle

ukazatelích (napˇr.

projektu (v pˇrípadˇe

kde a kdy budou

splnˇení výstupu) ˚

nebo služby

uloženy zprávy, statistiky a jiné výstupy)

42

6. P ROJEKT IMPLEMENTACE ITIL Sloupec

Objektivnˇe

Zdroje informací k

Vnˇejší


ovˇerˇitelné

ovˇerˇení

pˇredpoklady /

cíl˚ u)

ukazatele

rizika

Aktivity projektu

Výˇcet mˇerˇitelných

ˇ Casový rámec každé

Specifikuje konkrétní

vstupu˚ nezbytných

z aktivit projektu

úkoly, které je tˇreba

pro zabezpeˇcení


splnit pro splnˇení

aktivit projektu


výstupu˚

Nezbytné pˇredpoklady (mimo

pro splnˇení cíle projektu (v pˇrípadˇe splnˇení aktivit) Pˇredbˇežné vnˇejší pˇredpoklady, které musí být naplnˇeny, aby mohla zaˇcít samotná realizace projektu

Následuje zkrácený logický rámec projektu Implementace ITIL v servisním oddˇelení. v tomto tabulkovém výpisu je zkrácena pasáž aktivit a jejich cˇ asových rámcu. ˚ Aktivity jsou shrnuty do tematických celku. ˚ v posledním sloupci jsou uvedena rizika projektu na všech úrovních. Sloupec

Objektivnˇe

Zdroje informací k

Vnˇejší


ovˇerˇitelné

ovˇerˇení

pˇredpoklady /

cíl˚ u)

ukazatele

Zámˇer projektu

O 10% ménˇe

Systém docházky,

Zvýšení efektivity

incidentu, ˚ o 10%

tiketovací systém

servisního oddˇelení

menší cˇ as potˇrebný k

JIRA

rizika

vyˇrešení jednoho incidentu Cíl projektu

- výstupy

- výstupy

- byly vybrány

Zavedení ITIL

vývojových projektu˚


vhodné cˇ ásti ITIL k

praktik v servisním

odpovídají

(dokumentace v

implementaci

oddˇelení k 1.9.2012

požadavkum ˚

Confluence)

- rozsah servisního

- servisní oddˇelení

- procesy v JIRA

oddˇelení zustává ˚ v

dodržuje procesy

- dokumentace

prubˇ ˚ ehu projektu

provádˇených procesu˚

zhruba stejný

v Confluence

43


Objektivnˇe

Zdroje informací k

Vnˇejší


ovˇerˇitelné

ovˇerˇení

pˇredpoklady /

cíl˚ u)

ukazatele

Výstupy projektu

- guidelines

- guidelines v

- dostateˇcná

- upraveny

vývojového projektu

Confluence

motivace servisního

guidelines

schváleny

- dokumentace v

oddˇelení ke zmˇenám


- schváleny úpravy

Confluence

- dostateˇcná

- upravena

dokumentace

- proces tiketu˚ v

motivace manažeru˚

odpovídající

- schváleny úpravy v

JIRA

vývojového oddˇelení

dokumentace

JIRA procesech

- prezentace ze

k prosazení dalších

- upraveny procesy v

- záznam o docházce

školení

výstupu˚ projektu˚

tiketech v JIRA

školení

rizika

- provedeno školení servisního týmu - provedeno školení PM a team leaderu˚

44


Objektivnˇe

Zdroje informací k

Vnˇejší


ovˇerˇitelné

ovˇerˇení

pˇredpoklady /

cíl˚ u)

ukazatele

Aktivity projektu - nastudování ITIL - vytipování vhodných ITIL praktik - rozplánování projektu - úprava dokumentu˚ procesu˚ - implementace metrik

rizika ˇ Casový rámec aktivit

- možnost

- nastudování ITIL – - práce autora

do ITIL

15.5.2012

- pˇrístup k ITIL

- dostatek lidských

- plán projektu –

knihovnˇe

zdroju˚ servisního

25.5.2012

- pˇrístup k aktuální

oddˇelení

- úpravy a

dokumentaci

- úˇcast servisního

implementace –

- lidské zdroje

týmu na školení

30.6.2012

servisního oddˇelení

- úˇcast PM a team

- školení servisního

- zdroje pro školení

leaderu˚ na školení

týmu – 1.7.2012

Vstupy na úrovni aktivit

dostateˇcného vhledu

- úprava požadovaného výstupu vývojového projektu - úprava aktuálnˇe spravovaných aplikací - nastavení pravidelných událostí - školení servisního týmu - školení PM a team leaderu˚ Pˇredbˇežné podmínky - souhlas servisního manažera s prací na projektu - pˇrístup k nástrojum ˚ (JIRA, Confluence)

Doporuˇcení byla rozpracována do odpovídajících implementaˇcních úkolu. ˚ Spolu se servisním týmem autor práce odhadl cˇ asovou nároˇcnost jednotli45

6. P ROJEKT IMPLEMENTACE ITIL vých úkolu. ˚ Nároˇcnost je odhadována ve cˇ lovˇekodnech (man-day = MD), viz Tabulka 6.3.

Úkol - doporuˇcení

ˇ Casová dotace

D2 D4 D5 D6 D9 D10 D11 D12 D14 D15 D16 D17 D18 D19 D20 D21 D22 D23 D24 D25 D26 D31 D33 PS1 PS2 S1 S2

1 MD 4,5 MD 0,25 MD 0,75 MD 1 MD 8 MD 1 MD 0,5 MD 6 MD 1,5 MD 0,5 MD 4 MD 6 MD 4 MD 0,5 MD 4 MD 0,5 MD 0,5 MD 3 MD 2,5 MD 0,25 MD 0,25 MD 1 MD 1 MD 1MD 2 MD 2 MD

Celkem

57,5 MD

Tabulka 6.3: Tabulka cˇ asových odhadu˚ úkolu˚ na projektu.

Jednotlivé úkoly jsou rozepsány do struktury rozpisu práce WBS (Work Breakdown Structure) na Obrázku 6.1. 46


Obrázek 6.1: WBS projektu Implementace ITIL - ve sloupci Jméno je uveden kód doporuˇcení, Trvání ukazuje, jak dlouho bude implementace trvat. v pˇrípadˇe, že úkol trvá tˇri MD, ale pracují na nˇem tˇri vývojáˇri, je zobrazena ˇ hodnota „1 den“. Vpravo je zobrazen Ganttuv ˚ diagram. Cervenˇ e je v nˇem vyznaˇcena kritická cesta. Napravo od boxu˚ jednotlivých úkolu˚ jsou role, které budou mít daný úkol na starost. SM - servisní manažer; SV1-SV3 servisní vývojáˇri; AP - autor této práce. Pro tvorbu WBS byl použit nástroj OpenProj.

6.3

ˇ Rízení rizik

Náˇcrt rizik projektu již byl proveden v pˇredchozí kapitole 6.2. Tabulka 6.3 v této kapitole prohloubí jejich rozbor a uvede, jak rizika byla nebo budou mitigována.

47


Riziko

D.

P.

Mitigace

Špatný výbˇer cˇ ástí ITIL k implementaci

M

M

Autor konzultoval výbˇer cˇ ástí s vedoucím práce a servisním týmem

Velký rust ˚ servisního oddˇelení

M

L

Žádná

Motivace servisního oddˇelení

H

M

Motivace PM vývojových projektu˚

M

H

Nedostatek lidských zdroju˚ servisního oddˇelení

H

L

Neúˇcast servisního oddˇelení na školení

H

L

Neúˇcast PM a team leaderu˚ na školení

H

L

Zmˇeny v oddˇelení budou konzultovány s týmem k oboustranné spokojenosti Zmˇeny budou konzultovány s PM ke všestranné spokojenosti S plánovanými výstupy projektu bude požádáno management o zdroje Pˇred projektem bylo se servisním manažerem dohodnuto Servisní manažer bude komunikovat nutnost tohoto školení smˇerem k PM

Tabulka 6.4: Tabulka mitigace rizik. Sloupec D. obsahuje informaci o dopadu na projekt, P. o pravdˇepodobnosti rizika. Hodnoty H, M, L odpovídají anglickým slovum ˚ High, Medium, Low (vysoký, stˇrední, nízký).

48

7 Závˇer V práci byla rozebrána problematika servisních oddˇelení, jejich problému˚ a úskalí. Zárovenˇ byly v druhé kapitole popsány standardy, které jsou pro jejich rˇ ízení používány. v další kapitole byla popsána knihovna ITIL z pohledu servisních oddˇelení a byly vytipovány její klíˇcové cˇ ásti pro servisní ˇ oddˇelení stˇrednˇe velkých spoleˇcností. Ctvrtá kapitola popisuje Spoleˇcnost a její servisní oddˇelení. Zamˇerˇ uje se na procesy a obecnˇe místa, kde servisní tým vidí prostor ke zlepšení. Pátá, stˇežejní kapitola se vˇenuje spojení poznatku˚ z pˇredchozích kapitol. Jsou v ní rozebrány zvolené stˇežejní cˇ ásti ITIL, které jsou zajímavé z pohledu servisního oddˇelení Spoleˇcnosti. Autor v nich dává Spoleˇcnosti doporuˇcení ke zlepšení. Tato zlepšení jsou pak zahrnuta do následujícího projektu Implementace ITIL. Rozsah projektu je definován pomocí logického rámce a seznam projektových úkolu˚ je uskupen do struktury rozpisu práce (WBS). Poslední cˇ ást práce rozebírá rizika projektu vˇcetnˇe jejich mitigace. V literatuˇre je problematika servisních oddˇelení pomˇernˇe málo popsána. v této práci se autor snaží zmapovat ruzné ˚ pˇrístupy k jejich vedení a popisuje jejich obecné problémy. Pro manažery servisních oddˇelení tak tato práce pˇrináší souhrn obecných i konkrétních problému˚ a rizik, kterým je vhodné se vyhnout a pˇredcházet jim. Praktická cˇ ást mapuje ITIL metodiku na konkrétní spoleˇcnost. Spoleˇcnosti se tak dostává seznam doporuˇcení založený na analýze servisního oddˇelení. Tato doporuˇcení vedla k realizaci projektu, který zaˇcíná 1.6.2012. Praktická cˇ ást také muže ˚ sloužit jako struˇcný výtah z ITIL pro servisní manažery stˇrednˇe velkých spoleˇcností a seznam doporuˇcení pro nˇe muže ˚ být vhodnou inspirací. Teoretická cˇ ást neobsahuje srovnání nˇekolika servisních oddˇelení ruz˚ ných spoleˇcností, což by mohlo být vhodné téma navazující práce. Toto porovnání by mohlo vést k odhalení dalších slabých míst a prostoru˚ ke zlepšení ve všech zúˇcastnˇených firmách. V práci nebyly rozebrány všechny aspekty ITIL. Servisní oddˇelení je ve spoleˇcnostech provázáno témˇerˇ se všemi ostatními oddˇeleními. Rozsah práce nedovoloval autorovi zamˇerˇ it se na všechny kapitoly. Pro další vylepšení by bylo vhodné projít zde nerozebírané cˇ ásti ITIL a vybrat z nich další doporuˇcení.

49

Literatura [Aal98] VAN DER AALST, W. A Survey of System Development Process Models. Albany : Center for Technology in Government University at Albany, 1998. [Atl11] ATLASSIAN. Content and Social Collaboration Software [online]. 2011 [cit. 26.5.2012]. Dostupné z http://www.atlassian.com/ software/confluence/overview [Bee03] BEECHAM S., HALL T., RAINER A. Software Process Improvement Problems in Twelve Software Companies: An Empirical Analysis. Netherlands : Kluwer Academic Publishers, 2003. [Ban93] BANKER R. D. Software complexity and maintenance costs. USA : Magazine Communications of the ACM, New York, 1993. [Ban98] BANKER R. D. et al. Software Development Practices, Software Complexity, and Software Maintenance Performance: A Field Study. USA : School of Management, University of Texas at Dallas, 1998. [Cab01] CABINET OFFICE. ITIL Continual Service Improvement 2011 Edition. Velká Británie : The Stationery Office, 2011. 260 s. ISBN 9780113313082. [Cab02] CABINET OFFICE. ITIL Service Design 2011 Edition. Velká Británie : The Stationery Office, 2011. 456 s. ISBN 978-0113313051. [Cab03] CABINET OFFICE. ITIL Service Strategy 2011 Edition. Velká Británie : The Stationery Office, 2011. 469 s. ISBN 978-0113313044. [Cab04] CABINET OFFICE. ITIL Service Operation 2011 Edition. Velká Británie : The Stationery Office, 2011. 384 s. ISBN 978-0113313075. [Cab05] CABINET OFFICE. ITIL Service Transition 2011 Edition. Velká Británie : The Stationery Office, 2011. 360 s. ISBN 978-0113313068. [Car07] CARTLIDGE, A. et al (pˇreklad HUDEC J.). Úvodní pˇrehled ITIL V3. Praha : Hewlet-Packard s.r.o., 2007. 56 s. ISBN 0-95551245-8-1. [Dol09] DOLEŽAL, J.,LACKO, B., MÁCHAL, P. et al. Projektový management podle IPMA. Praha : Grada Publishing, a.s., 2009. 512 s. ISBN 978-80-247-2848-3. 50

ˇ 7. Z ÁV ER

[Eng08] ENGLE C., BLOKDIJK G. Art of service: How to develop, implement and enforce ITIL V3’s best practices. Austrálie : Brisbane, 2008. ISBN: 978-0-9805136-6. [Hil11] HILL T. Software Maintenance and Operations Hybrid Model. USA : The University of Texas at Dallas, 2011. [Krk11] KRKOŠKA P. Alokace a rˇízení zdroju˚ napˇríˇc projekty IT spoleˇcností. ˇ Ceská republika : Masarykova univerzita Brno, 2011. [Kru01] KRUCHTEN, P. Software Maintenance Cycles with the RUP [online]. 2001. [cit. 26.5.2012]. Dostupné z: http: //vincentvanrooijen.com/container%5Cprocess% 5CSoftware%20Maintenance%20Cycles%20with%20the% 20RUP%20-%20The%20Rational%20Edge%20-%20Aug% 2001.pdf. [Lie81] LIENTZ B. P. Problems in application software maintenance. USA : ACM New York, 1981. ISSN: 0001-0782. ˇ [Mus10] MUSIL M. Implementace ISO/IEC 20000. Ceská republika : Masarykova univerzita Brno, 2010. [Nas84] NASIR, Z., ABBASI A. Z. A Framework for Software Maintenance and Support Phase. Pakistan : National University of Computer & Emerging Sciences, 1984. [Oma92] OMAN P., HAGEMEISTER J. Metrics for Assessing a Software System’s Maintainability. USA : University of Idaho, Moscow, 1992. [Sta99] STARK, G., OMAN, P., SKILLICORN, A., AMEELE, R. An Examination of the Effects of Requirements Changes on Software Maintenance Releases. USA : Austin, Journal of Software Maintenance, 1999. ˇ [Sta09] STANÍCEK, Z. Studijní materiály pˇredmˇetu PA179 - Project Manageˇ ment and Service Lifecycle. Ceská republika : Masarykova univerzita, 2009. Dostupné v IS Masarykovy Univerzity.

51

Implementace ITIL v servisním oddělení firmy

Recommend Documents