Implementace ITIL v servisním oddělení firmy

Transkript

1 Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Implementace ITIL v servisním oddělení firmy DIPLOMOVÁ PRÁCE Tomáš Masník Brno, jaro 2012

2 Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Tomáš Masník Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D. i

3 Poděkování Chci poděkovat všem, kteří mě podporovali jak po dobu studia tak v době vzniku této práce. Velké díky patří RNDr. Jaroslavu Ráčkovi, Ph.D. za cenné rady a vedení práce, celému servisnímu týmu a Společnosti, že mi poskytla vše, co jsem pro tuto práci potřeboval. ii

4 Shrnutí Tato práce popisuje implementaci doporučení z ITIL knihovny v konkrétním servisním oddělení středně velké firmy. Nejdříve je však čtenář seznámen s obecnou problematikou servisních oddělení a standardizace procesů v nich a následně s jednotlivými částmi ITIL. Následuje rozbor konkrétních kapitol ITIL, okomentovaný z pohledu servisního oddělení. Součástí práce je též projektová dokumentace implementace ITIL metodik v konkrétní společnosti. iii

5 Klíčová slova ITIL, servisní oddělení, projekt, procesní řízení, standardizace. iv

6 Obsah 1 Úvod Servisní oddělení Servisní projekt Problémy servisních projektů Standardizace a řízení procesů servisních oddělení ITIL O knihovně ITIL Seznam částí ITIL Analýza stávajícího stavu servisního oddělení O společnosti O oddělení Používané nástroje Analýza přínosu ITIL Návrh služeb Přechod služeb Provoz služeb Neustálé zlepšování služeb Projekt implementace ITIL Rozsah projektu Logický rámec projektu Řízení rizik Závěr v

7 1 Úvod Po úspěšném vyvinutí aplikace ji většina firem ještě dlouhou dobu ladí a upravuje tak, aby odpovídala byznys požadavkům. Vzniká tak odvětví servisu software, které tyto úpravy provádí, reaguje na požadavky zákazníků, opravuje chyby a adaptuje systém na změny v okolním prostředí. Vývoj trvá pouze krátkou dobu, kdežto období podpory, kterou poskytují servisní oddělení, je mnohonásobně delší. Aby byla podpora efektivní a výdělečná, je potřeba už při vývoji produktu dodržovat určité zásady a mít nastaveny efektivní procesy v servisním oddělení. Právě efektivitou procesů napříč IT firmou se zabývá ITIL. Pomocí jeho doporučení se v této práci autor pokusí nastínit konkrétní zlepšení servisních oddělení a hlavně servisního oddělení Společnosti Společnost s velkým S bude v této práci označovat konkrétní českou firmu, pro kterou je prováděna praktická případová studie. 1

8 2 Servisní oddělení V této kapitole si rozebereme obecnou definici servisního oddělení, jeho fungování a projekty. Tato teoretická pasáž poslouží k lepšímu pochopení fungování servisního oddělení ve Společnosti. Servisní oddělení v pojetí této práce lze definovat jako oddělení IT firmy, které: má na starost řešení tzv. servisních projektů (viz definice níže) má samostatný rozpočet provádí kontinuální podporu různým zákazníkům zastřešuje oddělení uživatelské podpory provádí údržbu a profylaxi v prostředí zákazníka má samostatný nezávislý tým a svého manažera provádí změny na projektech ř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čný proces složený z posloupnosti řízených kontrolovaných aktivit s danými daty začátku a konce, které se provádí s cílem dosáhnout předem definovaného cíle, který splňuje specifikované požadavky jako čas, cena a omezení zdrojů. [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řizpůsobení změněnému prostředí. [Sta09] 2

9 2. SERVISNÍ ODDĚLENÍ Obrázek 2.1: Servisní oddělení zde představuje část Software maintenance. Stojí mezi uživateli na zákazníkově straně (Customer users), vývojovým týmem (Development team) a dalšími dodavateli (Suppliers). Převzato ze [Nas84]. Obecně se servis skládá ze všech aktivit poté, co je produkt uveden do provozu. Pod pojmem softwarové údržby nebo servisu se většinou myslí jedna z těchto aktivit: oprava chyb (corrective maintenance) úpravy v rámci předcházení chybám (preventive maintenance) přidávání malých vylepšení, refaktoring (perfective maintenance) aktualizace softwaru podle jeho prostředí - operačního systému, hardwaru a dalších systémů, na kterých je software závislý (adaptive maintenance) [Kru01] 2.2 Problémy servisních projektů Při servisních projektech a údržbě jako takové se vyskytují specifické problémy stejně tak jako problémy podobné těm z vývojových projektů. Rozeberme si je tedy. Složitost kódu a architektura Servis se zabývá opravou chyb a změnami. Kdykoli je požadována změna v softwaru, je třeba ponořit se do zdrojových kódů a změnu provést. Po- 3

10 2. SERVISNÍ ODDĚLENÍ kud je složitý kód anebo architektura, oprava bude také složitá. Je zřejmé, že pokud programátor musí nastudovat velké množství dokumentace a samotného nesrozumitelného kódu, zabere mu to velké množství času. Studie [Ban98], [Ban93] prokazují, že složitost kódu má na cenu údržby velký vliv (ve studiích měřeno hlavně pomocí metrik počtu řádků, počtu řádků metod a velikosti modulů). Nedostatek porozumění Jeden ze základních úkolů při úpravě softwaru je porozumění, jak systém funguje. Člověk, který provádí změny, musí vědět, jak je systém používán a jak byl vyvinut. Programátoři ve výsledku stráví většinu času pochopením systému, až systém chápou, teprve mohou programovat změny [Nas84]. Nedefinován proces údržby Většina organizací nemá definovány procesy a standardy pro údržbu softwaru. Je to jedna z nejzanedbanějších oblastí softwarového vývoje, která ve výsledku zvyšuje čas a tudíž i cenu servisu. Zapojení senior managementu Je důležité, aby zkušení senior manažeři byli zapojeni do procesu servisu. To, že senior management nerozumí potřebám servisního oddělení, znesnadňuje 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ěn na existující systémy. Servisní oddělení musí mít příslušné znalosti o struktuře a architektuře systémů. Na základě těchto znalostí jsou vytvářeny odhady náročnosti pro daný změnový požadavek. Cíle analýzy dopadu na aplikaci jsou: zjistit rozsah změny mít odhad na požadované prostředky pro práci zjistit cenu a užitnou hodnotu dané změny klasifikovat komplexnost změny a komunikovat ji ostatním zúčastněným. 4

11 2. SERVISNÍ ODDĚLENÍ Analýza dopadu je klíčová pro udržovatelnost softwaru a má přímý vliv na cenu servisu. Odhad nákladů 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ákladů klíčové. Pokud jsou špatné, vede to k nákladnějšímu provozu a také ke ztrátě důvěry zákazníka. Například Y2K chyba je považována za jednu z nejdražších chyb v historii počítačů. Nokia investovala do prevence a opravy této chyby 75 milionů Eur. Špatné proškolení uživatelů Pokud firma nasazuje nově vyvinutý systém a nemá připraven adekvátní plán pro školení cílových uživatelů, musí se připravit na jejich nespokojenost. Pokud uživatelé nevědí, jak mají nový nebo upravený systém správně používat, mají tendenci hlásit chyby, které vlastně chybami nejsou. Výsledkem je pak zvýšení ceny údržby. Závislost na externím dodavateli V dnešní době integrace a outsourcingu je téměř každý systém závislý na několika 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ěl vybudovat dobré vztahy s dalšími spoludodavateli. Zvládnutí těchto vztahů se ukazuje jako klíčová součást údržby softwaru. Nedostatek dokumentace Pro údržbu je nejdůležitějším artefaktem softwaru jeho dokumentace. Servisní tým nemůže správně chápat systém, pokud chybí zásadní části dokumentace. Musí znovuobjevovat architekturu, závislosti v kódu apod., což zvyšuje cenu údržby. Metriky servisu Pokud organizace monitoruje své oddělení údržby a podpory, je schopno zlepšit spokojenost zákazníků. Monitorovat lze mnoho aspektů, od reakční doby oddělení uživatelské podpory, doby nedostupnosti služby až po spokojenost členů servisního týmu. Firma by také měla od zákazníků získávat 5

12 2. SERVISNÍ ODDĚLENÍ data z dotazníků ohledně spokojenosti s produktem a činností servisního oddělení. 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ří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ě hodnotné zaměstnance. Náklady spojené s údržbou mnoha projektů jedním týmem V případě, že firma spravuje několik (někdy i mnoho) servisních projektů, má většinou speciální tým servisních profesionálů, kteří tyto projekty spravují. Tito lidé však dost často mezi těmito projekty přechází, pracují na různých požadavcích z různých projektů. Přepínání kontextu, vývojového prostředí apod. stojí tyto lidi čas. Proto je nutné přechody mezi různými projekty optimalizovat. Problémové komponenty Ve firmách pracují lidé různého zaměření s různými zkušenostmi. S různými komponentami pracují s různou efektivitou. v případě, že servisní oddělení nepokrývá znalostmi kompletní spektrum nabízených softwarových produktů a komponent rovnoměrně, některé komponenty budou pro údržbu horší než jiné. Představme si například firmu, která se specializuje na webové aplikace, ale okrajově vyvíjí i mobilní. v servisním oddělení ale nepracuje žádný expert na mobilní aplikace. Je tedy pravděpodobné, že údržba mobilních aplikací bude obecně dražší než údržba webů. 2.3 Standardizace a řízení procesů servisních oddělení Servisní oddělení je relativně nezávislé na vývojovém oddělení. Má vlastní vedení, vlastní rozpočet. Přesto je většina firemních procesů uplatnitelná jak v servisním oddělení, tak i ve vývojovém. Některé procesy jsou však typické pouze pro servisní oddělení. Společné procesy Procesů, které se dotýkají i ostatních oddělení firem, je hodně. Jsou zde procesy týkající se personálního oddělení, čistě vývojového oddělení, řízení 6

13 firmy apod. Pro účely této práce jsou zajímavé procesy: řízení uvolnění (Release management) 2. SERVISNÍ ODDĚLENÍ řízení neustálého zlepšování služeb (Continual Service Improvement) řízení kapacit (Capacity management) řízení konfigurací (Configuration management) řízení změn (Change management) V těchto procesech je popsáno, jak se uvolňuje a nasazuje nová verze aplikace, jak se řídí změny ve službých, jak se udržují informace o všech konfiguračních položkách, jak si hlídat kapacitu dostupných (nejen) lidských zdrojů a jak postupně neustále vylepšovat stávající portfolio služeb. Standardizace procesů Cílem standardizace by měl být stav firmy, ve kterém se využívá nejlepších možných postupů a informací k dodávání produktů a služeb a který přinese zvýšení efektivity a sníží počet negativních dopadů. Standardy nepředepisují konkrétní implementace procesů, spíše jen ukazují cestu a okruhy, kterým by se firma měla věnovat, pokud se chce dále zlepšovat (a získat certifikaci o splnění normy). Standardy jsou z velké části navrženy pro správné fungování velkých organizací. Nicméně byznys se neustále vyvíjí a klade stále větší nároky na dodavatele služeb. Proto se zvyšuje počet firem, které mají tendence absolvovat náročné a nákladné certifikace s cílem získat díky tomu více zajímavých klientů. Existuje poměrně velké množství standardů pro vedení IT společností. Ty nejzajímavější z pohledu servisních oddělení si zde rozeberme. ISO 9001 Norma ISO 9001 je známý a velmi rozšířený standard, který se zaměřuje na efektivní nastavení managementu organizace a kvalitu produktů a služeb. Důraz je zde kladen na obchodní cíle a na splnění očekávání zákazníků. Byznys podle tohoto standardu zjišt uje požadavky zákazníků, rozhoduje o úspěchu a neúspěchu projektu a vypořádává se s problémy. 7

14 2. SERVISNÍ ODDĚLENÍ ISO/IEC Norma ISO/IEC je první mezinárodní normou pro řízení IT služeb. Jak již bylo zmíněno v kapitole 3.1, vychází z britské normy BS a tedy i z ITIL. Do poskytování IT služeb zavádí principy procesního řízení, definování, měření a vyhodnocování kvality služeb zákazníkům a jejich neustálé zlepšování. Pokud budeme srovnávat normu ISO/IEC s knihovnou ITIL, můžeme říct, že při implementaci ISO normy je nutné využít určitých částí ITIL, nicméně ITIL tuto normu rozsahem převyšuje. Tedy i pokud máme implementovány certifikované procesy ISO/IEC 20000, ITIL nám nabízí další vylepšení a přidanou hodnotu pro zákazníka i poskytovatele. Ve srovnání s normou ISO 9001 je zaměřena na větší podniky a její implementace je několikanásobně náročnější. Tato práce si klade za cíl zaměření se na střední podniky, ale konkrétní Společnost, na níž provádíme v praktické části případovou studii, již tuto normu splňuje. ISO Norma ISO je zaměřena čistě na údržbu softwaru (software maintenance). Popisuje procesy jako předání softwaru do údržby, procesy spojené s dokumentací softwaru, odhady nákladů na údržbu a další. Tato norma je zaměřena na velké firmy, které se specializují na údržbu softwaru. Vzhledem k tomu, že Společnost, na niž se zaměřuje praktická část práce, takové ambice ani rozsah servisního oddělení nemá, nebudeme se touto normou dále zabývat. 8

15 3 ITIL Information Technology Infractructure Library, dále jako ITIL, je soubor konceptů a postupů, které umožňují lépe plánovat, využívat a zkvalitňovat využití informačních technologií, a to jak ze strany dodavatelů IT služeb, tak i z pohledu zákazníků. V této kapitole se budeme věnovat rozebrání obsahu ITIL a identifikaci jeho klíčových částí pro servisní oddělení. 3.1 O knihovně ITIL Historicky tato sada postupů 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ěšnější firmy postavily k řízení IT služeb. Na začá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ě je k dispozici už třetí verze ITILv3. S touto verzí knihovny ITIL také pracuje autor této práce. Formální standard pro řízení IT služeb The British Standard (BS 15000) byl z velké části postaven právě na postupech popsaných v ITIL. Od té doby se na svět dostaly i další standardy čerpající z ITIL, například celosvětově používaný standard ISO 20000: Seznam částí ITIL Jádro ITIL se skládá z pěti publikací: Strategie služeb (Service Strategy) Návrh služeb (Service Design) Přechod 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 typů interních i externích 9

16 3. ITIL dodavatelů, přínosů služeb a portfolia služeb. Cílem této části je stanovit strategii, kterou bude firma uplatňovat, co se týče poskytování služeb. A to včetně nastavení kritérií úspěchu, zhodnocení aktuálního stavu firmy a prioritizace obchodních příležitostí. Servisního oddělení se tato kniha dotýká pouze minimálně, proto se na ni v textu nebude objevovat příliš mnoho odkazů. Návrh služeb Druhá kniha popisuje činnosti související s návrhem služeb. Klade důraz na provázanost návrhu s požadavky byznysu. Popisuje, jaké principy a metodiky zvolit pro přetvoření strategických cílů 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řidanou 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ělení v kapitolách Řízení úrovně služeb (Service Level Management), Řízení kapacit (Capacity Management), Řízení kontinuity služeb (IT Service Continuity Management). Přechod služeb Service Transition neboli přechod služeb popisuje fázi převodu služby z jedné fáze svého životního cyklu do další. Kniha Service Transition poskytuje rady pro řízení projektů tak, aby výsledná nová či upravená služba byla co nejzpůsobilejší pro předání do provozu, aby při předání došlo k co nejméně chybám, přerušením aktuálních služeb a projevilo se co nejméně rizik. Tato publikace kombinuje různá odvětví přes kapitoly řízení změn, konfigurací, uvolnění a nasazení, až po řízení rizik. Jsou v ní rady pro řízení změn na poskytovaných službách, změn v procesech, vše v kontextu předávání řízení mezi zákazníky a poskytovateli služeb. Také je zde popsán systém řízení znalostí, který je postaven nad systémy konfigurací, kapacit a známých errorů Pojem známý error se bude vyskytovat v celé práci. Zastupuje anglický ITIL pojem known error. z důvodů snadnější orientace v pojmech bude v práci použit tento českoanglický pojem. 10

17 3. ITIL Procesy předávání služeb Stěžejní část knihy se věnuje procesům spojeným s předáváním služeb (Service Transition processes). v ní jsou obsaženy kapitoly jako Plánování předání a podpora (Transition planning and support), kde jsou rady ohledně sestavení aplikace, nasazení, plánování kapacit a zdrojů s cílem úspěšného vylepšení služby bez dopadu na její aktuální chod. Další důležitou kapitolou je bezpochyby Řízení změn (Change Management). Zde je popsán proces detekování změn a jejich následné zpracování. Cílem je zlepšit efektivitu služby a celého (v našem případě) servisního oddělení, vylepšení služeb, úprava služby tak, aby i nadále odpovídala obchodním požadavkům. Řízení konfigurací (Service asset and configuration management) se věnuje 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řit efektivitu řízení a odstranění chyb způsobených špatným nastavením. Řízení uvolnění a nasazení (Release and deployment management) si klade za cíl vyjasnit procesy uvolňování nových verzí služeb a jejich nasazení tak, aby byly efektivní, dalo se na ně 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) řeší problémy při 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čeně funkční a odpovídá původním požadavkům. Nakonec Řízení znalostí (Knowledge management) obsahuje návod, jak si uchovávat a efektivně předávat znalosti o službách, zainteresovaných lidech z řad poskytovatelů i dodavatelů, plánech i zdrojích. Cílem je zvýšení efektivity a kvality služeb tím, že lidé v oddělení uživatelské podpory (Service Desk - v našem případě v servisním oddělení) jsou v každém okamžiku schopni jednoduše zjistit, kdo, jak a hlavně proč služby využívá. Provoz služeb Kniha Provoz služeb (Service Operation) mapuje řízení každodenního provozu. Obsahuje rady, jak dosáhnout efektivity při poskytování podpory, zajištění přidané 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řípadě, že na nich dochází ke změnám. Dostává se nám tak návodů, jak reagovat reaktivně i proaktivně a na co si v obou případech dát pozor. 11

18 3. ITIL Stěžejními částmi pro chod servisního oddělení jsou z této knihy hlavně Procesy provozu služeb (Service Operation processes) se svými částmi Řízení událostí (Event Management), incidentů (Incident Management), Řízení problémů (Problem Management) a přístupů (Access Management). Všechny tyto kapitoly popisují nezbytné procesy pro správný chod oddělení uživatelské podpory z pohledu reakcí na různé 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 čerpány informace ohledně vylepšování a udržování přidané 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 řízení změn, kvality a kapacit zmíněné ve výše popsaných knihách. Firmy se zde mohou poučit o postupných i velkých skokových vylepšeních v kvalitě a efektivitě. Celou knihou probíhá myšlenka uzavřené smyčky založená na modelu Plan-Do-Check-Act (PDCA) tedy plánuj, udělej, zkontroluj, jednej aneb nejdříve prověřit současnou výkonnost služby a naplánovat její vylepšení, následně vylepšení realizovat, poté zhodnotit výsledky a opravit chyby a na základě těchto výsledků rozpracovat výsledné ř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říklad co lze měřit, jak vytvářet 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ět popisuje technologie a rady pro úspěšnou implementaci včetně výzev a rizik. 12

19 4 Analýza stávajícího stavu servisního oddělení V této kapitole shrneme aktuální stav Společnosti a hlavně jejího servisního oddělení. Rozebereme si jej z pohledu procesů, předností a nedostatků. Na základě 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ělení ve Společnosti splňuje vše z definice v kapitole 2. Veškeré informace v následujících částech byly získány formou rozhovorů se všemi členy servisního oddělení, včetně servisního manažera, a také z osobních zkušeností autora práce, který v době psaní sám byl jeho členem. 4.1 O společnosti Společnost je českou pobočkou mezinárodní skupiny, která je jedním z největších dodavatelů ICT služeb ve střední a východní Evropě. Samotná česká pobočka čítá přes sto zaměstnanců a specializuje se především na vývoj profesionálních portálových aplikací na platformě Java EE. Společnost má maticovou, plochou organizační strukturu a silnou projektovou kulturu. Jedna projektová kancelář čítá okolo šesti projektových manažerů, kteří vedou souběžně asi deset projektů, na kterých je zaměstnáno okolo šedesáti vývojářů a jiných technických pracovníků. Na projektech, které jsou jak interní, tak externí povahy, je přiřazena většina zaměstnanců často na více projektech současně, někteří z nich také ve více projektových rolích. Projekty se liší svým rozsahem od několikaměsíčních interních projektů, přes rozsáhlé studie proveditelnosti až po komerční projekty s rozpočtem v řádu miliónů korun a několikaletou délkou trvání. Projekty jsou realizovány s využitím několika málo společných platforem, nicméně každý projekt je technicky komplexní a obsahuje aplikace přizpůsobené na míru konkrétním klientům. Projekty jsou po ukončení předány do servisního režimu, ve kterém se o ně pak stará servisní oddělení. Společnost je držitelem stupně 4 standardu kvality organizace práce CMMI a několika ISO certifikací. [Krk11] Autor se se Společností seznámil v průběhu své šestiměsíční stáže v rámci Interim projektu. Pracoval zde na pozici asistenta projektového manažera. Díky této praxi měl autor možnost detailně se seznámit s procesy ve firmě z pohledu managementu. Po skončení praxe zde autor nastoupil na pozici Java programátora, čímž získal přehled o procesech a kvalitách firmy z pohledu zaměstnance a vývojáře. Ve firmě prošel jak vývojovým, tak servisním oddělením. Kombinace všech těchto typů zkušeností vede k 13

20 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ získání komplexního pohledu na firmu. 4.2 O oddělení Servisní oddělení ve Společnosti má v době vzniku této práce na starost 10 projektů. Všechny projekty mají za cíl údržbu a podporu portálových aplikací, které byly ve Společnosti vyvinuty. Téměř každý nový firemní projekt je následně spravován servisním oddělením. Proto se toto oddělení neustále rozrůstá. S rostoucím počtem lidí je třeba řešit různé dosud nepoznané problémy řízení znalostí a zastupitelnosti, zapojení nového člena do týmu, standardizace procesů apod. Oddělení se zabývá pouze správou softwaru. Hardware je plně v režii zákazníka. Společnost v minulosti měla zkušenosti se správou hardware. To se však ukázalo jako příliš nákladné a Společnost od toho upouští. Nicméně je možné, že správa hardwaru bude někdy v budoucnu také na některém projektu po Společnosti vyžadována. Projekty Jak již bylo zmíněno, servisní oddělení 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ářím, je jakákoli standardizace poměrně obtížná. Každý projekt má vlastní proces pro uvolnění a nasazení aplikace, pro každý z nich byla ještě donedávna jiná servisní smlouva (Service Level Agreement - SLA). Každý projekt, který oddělení přebralo do své správy, byl předán v jiném stavu. U některých proběhlo pouze neformální předání, kvůli jiným byl uspořádán workshop, na kterém původní tým vývojářů předal znalosti členům servisního oddělení. Servisní oddělení nemá nijak definován proces předávání projektů do správy, což je ve firmě vnímáno negativně, hlavně ze strany servisního týmu. Také není nijak pevně uchopena spolupráce původního vývojového týmu se servisním. Neřeší se ani zastupitelnost a odhadování případných změnových požadavků. Stejně tak se do servisu nadále nezapojuje ani projektový manažer původního vývojového týmu. Společnost nemá zaveden žádný jednotný monitoring systémů, které spravuje. Nástroje pro sledování systémů se však ve Společnosti aktuálně vyvíjí. 14

21 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ Tým Aktuální tým čítá osm lidí a servisního manažera. Dohromady má tým zkušenosti ze všech klíčových oblastí pro servis projektů. v některých oblastech však tyto znalosti má pouze jeden člověk, což se ukazuje jako kritické pro řešení zastupitelnosti. Některé znalosti v týmu částečně nebo úplně chybí. Oddělení se snaží vyřešit otázku zastupitelnosti na všech servisních projektech. Výsledkem této snahy je zatím to, že na většině projektů jsou schopni provést servisní zákrok dva lidé, na některých tři a na dvou dokonce pouze jeden člověk. Nicméně se připravují školení, aby před dobou dovolených tyto palčivé problémy byly odstraněny a nedošlo náhodou k výpadku některé ze služeb. Servisních projektů přibývá, a proto má oddělení tendenci růst. Se zvýšením počtu lidí je třeba více řešit výměnu znalostí a zkušeností a je potřeba více práce ze strany servisního manažera. Tým je rozdělen na dva podtýmy. Jeden se věnuje projektům Společnosti, druhý pracuje na servisních pracích pro partnera Společnosti. Každý podtým se schází každý den, aby si jeho členové sdělili, na čem pracovali a na čem budou pracovat následující den. Oba podtýmy se pak setkávají dvakrát týdně s cílem udržení informací o aktuálním stavu oddělení. Všechny meetingy vede a organizuje servisní manažer. Jeho role spočívá v organizaci celého týmu, správě důležitých projektových informací, komunikaci s ostatními týmy ve Společnosti a hlavně komunikaci se zákazníkem a správě financí oddělení. Procesy v oddělení Přebrání projektu oddělením Po vyvinutí projektu vývojovým oddělením je tento projekt předán zákazníkovi, který jej formálně 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ělením. Pro správný chod jeho podpory a údržby musí být zařízeno předání znalostí o projektu směrem k servisnímu týmu. Tento proces zatím není definovaný a oddělení se zatím pouze snaží vytipovat podle historických dat, jak by tento proces měl vypadat, aby byl efektivní, časově (a finančně) co nejméně náročný, a zároveň aby došlo k převzetí všech důležitých znalostí a artefaktů nutných pro další fungování. Tento proces není příliš častý, projekty Společnost uzavírá a předává do servisu maximálně několikrát ročně. Proto je tento proces zatím uchopen velmi volně nedá se totiž jednoduše postupně vyvíjet a vylepšovat. Mo- 15

22 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ mentálně ve Společnosti vzniká kontrolní seznam nutných podmínek, které musí být splněny při převzetí projektu do servisu. Tento seznam se neustále vyvíjí, nicméně jeho použitelnost zatím nebyla ověřena v praxi. Servisní oddělení se začíná projektu věnovat až po fázi předání. Do té doby je projekt čistě v kompetencích vývojového oddělení. Servisní tým se ale chce zapojit i dříve, hlavně ve fázi předávání projektu. Tým očekává, že se zlepší předání znalosti o uvolnění a nasazení aplikace i komunikace s původním vývojovým týmem. O žádném dalším vstupu do projektu ze strany servisního oddělení tým neuvažuje. Po úspěšném předání projektu zákazníkovi běží záruční doba. Během ní provádí Společnost všechny zásahy zdarma. Řízení požadavků 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ároveň nejvíce typickým požadavkem je incident. Incidentem se rozumí neplánovaný výpadek poskytované služby nebo některé její části. Na žádném projektu momentálně neexistuje pasivní kontrola funkčnosti systémů. Monitoring je ale ve fázi implementace, je tedy do budoucna potřeba s ním počítat. Incident zatím tedy může nahlásit pouze zákazník. Hlášení probíhá formou vytvoření 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íkův požadavek). Jeho životní cyklus včetně všech fází popisuje diagram - Obrázek 4.1. Tiket má různé atributy. Pro komunikaci se zákazníkem jsou nejdůležitější tyto: Viditelnost tiketu určuje, zda tiket vidí i zákazník nebo pouze servisní oddělení. U Customer request tiketů je viditelnost Public tedy tento tiket vidí i zákazník. Priorita určuje, 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ěstnanci servisního oddělení. Na základě této hodnoty se zákazník dále rozhoduje, zda chce tento problém řešit nebo ne. 16

23 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ Obrázek 4.1: Workflow tiketů servisní podpory 17

24 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ Vykázaná skutečná práce kolik hodin pracovníci ze strany servisního oddělení na tiketu strávili. Tato doba odpovídá tomu, kolik zákazník nakonec zaplatí. Tikety typu incident jsou uzavřeny okamžitě po vyřešení nebo obnovení funkcionality. Pokud je dále na problému potřebná nějaká práce, je vykázána na tzv. implementační tiket propojený s tiketem incidentu. Tento implementační tiket je označen štítkem problem. Po uzavření incidentu je nutné případné větší změny zdokumentovat na odpovídajících stránkách v systému Atlassian Confluence. Dalším typem požadavku je změnový požadavek (change request). Tento požadavek je zpracován téměř stejně jako incident. Změny 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ělením jako vydařený a tým na něm nechce nic zásadního měnit. Proces také vyhovuje zákazníkům, kteří jsou s ním seznámeni a používají jej. Rozdělování práce a řízení kapacit Proces přidělování práce je velmi volný. Vývojáři jsou sami schopni ohodnotit prioritu úkolů a přidělují si tedy práci sami. v případě krizových situací žádají o pomoc servisního manažera. Pokud servisní tým nemá další volné vývojářské kapacity, servisní manažer žádá o uvolnění dalšího lidského zdroje z vývojového oddělení. Proces sestavení aplikace, uvolnění a nasazení Při implementaci opravy chyby je zdrojový kód udržován v systému pro správu a verzování zdrojových kódů, konkrétně v repozitáři Apache Subversion. Všechny příspěvky (commity) do tohoto systému musí být propojeny s tiketem v systému JIRA. Je pak dobře dohledatelné, které commity vedly k opravení dané chyby a naopak která chyba byla opravena daným commitem. Až má vývojář chybu opravenu, sestaví aplikaci na lokálním prostředí. Pokud existuje testovací prostředí, aplikaci tam nasadí a otestuje. Poté nechá otestovat chybu zákazníkem. Pokud chyba není opravena podle zákazníkových představ, proces se opakuje. Až je zákazník spokojen, vývojář s ním domluví datum nasazení do produkčního prostředí. Společnost na většině servisních projektů nemá domluveny žádné pravidelné nasazovací termíny. Nasazování probíhá dle domluvy s konkrétním zákazníkem. 18

25 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ v případě malých změn je zákazník většinou ochoten počkat s nasazením do doby, až bude potřeba nasadit více změn naráz. Před nasazením je ve verzovacím systému vytvořen tzv. tag uchová se přesná verze, která bude nasazena na produkci. Tagy jsou číslovány pořadovým číslem. Následně je tag sestaven a nasazen do produkčního prostředí. Pro některé projekty existují v tomto procesu různé odchylky: Na některých projektech neexistuje testovací prostředí (nejčastěji z důvodu, že se zákazníkovi nechce platit za další zbytečné prostředí), případně se jako testovací prostředí používá nějaká méně používaná část systému. v tomto případě neproběhne část procesu s testováním na testovacím prostředí, ale oprava je rovnou nasazena do produkčního prostředí, kde ji teprve vývojář, a následně i zákazník, testuje. Některé projekty mají proces nasazování pravidelný (tzn. existuje tzv. okénko údržby maintenance window, ve kterém se počítá s nedostupností systému). v tomto případě se snaží vývojář domluvit se zákazníkem tak, aby nasazení proběhlo v tomto okénku, není to však nutné. Na některých projektech se nejedná o vývoj komponent, ale o konfiguraci systému. Na těchto projektech neexistuje testovací prostředí, takže konfigurace probíhá přímo na produkčním prostředí. O tomto stavu ví zákazník i vývojáři, je známo, že toto řešení není ideální. Bohužel zákazník nechce investovat prostředky do spuštění a udržování testovacího prostředí. Kontinuita a úroveň služeb Jednou ročně se sbírá zpětná vazba od zákazníků Společnosti. Ta je poté analyzována a v případě nespokojenosti zákazníků jsou analyzovány příčiny této nespokojenosti. Ve firmě proběhlo nedávno sjednocení forem SLA, vylepšení se také dosáhlo ve změně účtování servisní oddělení momentálně funguje v módu time and material oproti dřívějšímu fixed time, fixed price. Žádné složitější metriky sledovány pravidelně nejsou. 19

26 4.3 Používané nástroje Apache Subversion 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ Apache Subversion (dříve Subversion) je systém pro správu a verzování zdrojových kódů. Nahrazuje dřívější systém CVS. Mezi základní funkce, které Subversion poskytuje, patří: uchovávání historie veškerých provedených změn centralizace správy zdrojových kódů. Kód je spravován na serveru, klientské stanice pracují s jeho lokálními kopiemi umožnění správy kódu různých verzí systému možnost vytváření tagů tj. zafixování konkrétních verzí systému a další Nástroj Subversion je celosvětově používán ve velkém množství firem. v některých společnostech je již považován za překonaný a zastaralý. Nicméně ve Společnosti má z historických důvodů stále své místo. Zaměstnanci s ním umí pracovat a jsou na něj zvyklí. Atlassian JIRA Atlassian JIRA je nástroj pro podporu řízení projektů a požadavků. Nabízí flexibilní uživatelské nástroje pro řízení a sledování postupu prací v průběhu plnění úkolu. Systém lze navíc propojit s dalšími stěžejními produkty, jako např. Subversion nebo Confluence. Hlavními výhodami je široká funkcionalita, včetně: definice vlastních workflow všech tiketů podpory projektového řízení pomocí plánování iterací, uvolnění aplikací apod. sledování a vyhodnocování kapacit sdílení komunikace v rámci týmu i se zákazníkem řešení oprávnění (v týmu i se zákazníkem) prioritizace, termínů, odhadů pracnosti fulltextového vyhledávání v tiketech 20

27 4. ANALÝZA STÁVAJÍCÍHO STAVU SERVISNÍHO ODDĚLENÍ statistik, reportů, filtrování tiketů projektové i osobní nástěnky Nástroj JIRA je používán i ve velkých softwarových firmách. Zaměstnanci Společnosti s ním rádi pracují, systém je navíc používán i jedním ze stěžejních partnerů Společnosti pro vývoj produktu Liferay. Společnost používá poslední verzi nástroje, má pro něj dokonce vyvinuty vlastní doplňky (např. nástroj pro sdílení zdrojů napříč různými projekty). Atlassian Confluence Další z řady nástrojů od firmy Atlassian Confluence je nástroj pro sdílení dokumentů. Jedná se vlastně o systém, ve kterém každý, kdo má potřebná práva, může jednoduše editovat uložené dokumenty, komentovat je, sledovat jejich starší verze. Confluence je velmi dobře propojena se systémem JIRA. Alfresco Pro správu statických dokumentů a dalších projektových artefaktů se ve Společnosti používá systém Alfresco. Systém obsahuje úložiště obsahu, řeší oprávnění a verzování dokumentů. 21

28 5 Analýza přínosu ITIL V této kapitole si spojíme poznatky z předchozích třech kapitol. Budeme se zabývat propojením znalostí o servisních odděleních obecně, knihovnou ITIL a servisním oddělením ve Společnosti. Výstupem této kapitoly je sada doporučení, která jsou v následující kapitole zavedena do projektu Implementace ITIL ve Společnosti. Společnost má popsány procesy, se kterými prošla certifikací ISO Jsou velmi dobře zdokumentovány a víceméně odpovídají realitě. Společnost chtěla procesy implementovat formou shora tj. nejdříve definovat proces a poté se ho snažit dodržovat. Tento způsob má výhodu v tom, že proces je dobře definovaný už od začátku. Nevýhodou je, že se zavádí v podstatě od nuly. Naproti tomu postup zdola, který se bude snažit prosadit autor této práce, nejdří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ě předchozí analýzy jak servisních oddělení, tak konkrétního servisního oddělení Společnosti, rozebírá kapitoly ITIL z pohledu servisního oddělení. Snaží se o co nejpřesnější výtah informací, které jsou potřeba při řízení servisního oddělení. Tyto kapitoly pak mohou sloužit servisním manažerům malých až středně velkých servisních oddělení jako opěrný bod při 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ři návrhu nové služby. Řízení úrovně služeb Cílem této kapitoly je nastavení správných vztahů s byznysem a zákazníky, měření a monitorování úrovně poskytovaných služeb, sledování a zlepšování spokojenosti zákazníků. S tím souvisí revize a případné přenastavení SLA, kontrola plnění SLA, řízení stížností i pochval. Ihned po podepsání a odsouhlasení SLA je třeba začít monitorovat, zda jsou podmínky SLA splňovány. Je vhodné mít se zákazníkem domluvenou formu a frekvenci pravidelných reportů. S těmito reporty je vhodné provádět také revizi služeb. Pro zlepšení spokojenosti zákazníka je zásadní, aby si servisní manažer vyvinul dobré vztahy s klíčovými lidmi na straně zákazníka. 22

29 5. ANALÝZA PŘÍNOSU ITIL V servisním oddělení Společnosti SLA pokrývají službu podpory aplikací. SLA jsou definované jednoznačně a v souladu s normou ISO Doporučení autora práce: D1: Nastavit si pravidelné reporty a revize plnění SLA a tyto výsledky komunikovat zákazníkovi. Řízení kapacit Cílem řízení kapacit je zajistit co možná nejideálnější využití zdrojů, tedy neplýtvat zdroji a zároveň předcházet situacím, ve kterých je zdrojů nedostatek. Jedná se jak o lidské zdroje, tak o např. hardware. Kapacitní plán je vytvářen pomocí sady kroků: 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 důležitá předpověd zátěže ze strany zákazníka. Pokud např. servisní tým ví, že zákazník migruje své stroje na jiný operační systém, dá se očekávat zvýšený počet incidentů a požadavků. Procesu předpovědi také může pomoci sledování trendů počtu incidentů a změnových požadavků. V servisním oddělení Společnosti momentálně žádný plán kapacit neexistuje. Vzhledem k malé velikosti servisního oddělení je kapitola řízení kapacit v ITIL vnímána autorem této práce jako zbytečně obšírná. Doporučení autora práce: D2: Vytvořit plán aktuálních kapacit všech zdrojů. Tento plán odsouhlasit se senior managementem. D3: Nastavit proces pravidelné revize plánu a vytváření nového na základě změn, které se v daném období udály. Řízení kontinuity služeb Cílem řízení kontinuity služeb je zajištění pokračování fungování služby v případě výpadku do doby stanovené v SLA. Zaměřuje se na správu a údržbu plánů obnov, vytváří analýzy rizik, hodnotí změny z pohledu zotavovacích plánů a vyjednává se zákazníky ohledně těchto plánů. Plány obnov je vhodné navrhnout pro různé typy rizik, od výpadku proudu, přes chybu databáze až po případ požáru. 23

30 Doporučení autora této práce: D4: Vytvořit pro každý projekt scénáře obnovy. 5. ANALÝZA PŘÍNOSU ITIL 5.2 Přechod služeb Plánování předání a podpora Tato kapitola si klade za cíl plánování konkrétních zdrojů pro sestavení, uvolnění, testování a nasazení nově upravené služby do produkčního prostředí. Dále se soustředí na problémy a rizika předávání s cílem doručení služby v dohodnutém čase v dohodnuté kvalitě. v kapitole se rozebírá mimo jiné režie spojená s uvolněním nové verze. Tento problém si zde rozebereme více do detailu v další části této kapitoly - Řízení uvolnění a nasazení. V celé kapitole se rozebírá obecně nasazování. Není zde na rozdíl od Společnosti rozlišeno prvotní nasazení od dalšího servisního nasazení. Ve Společnosti první nasazení provádí vývojový tým stejně jako podporu v začátcích projektu. Při nasazení je podle ITIL třeba zvážit následující (vypíchnuty pouze body týkající se Společnosti): 1. interní standardy je třeba postupovat podle interních firemních procesů 2. nasazení se mají účastnit strany: (a) (b) (c) třetí strany dodavatelů a všechny zúčastněné strany zákazník a jeho uživatelé poskytovatel služby (Společnost) 3. pro nasazení služby je třeba připravit: (a) (b) (c) (d) plán v souladu s interními procesy role a zodpovědnosti znovu použít zkušenosti a nástroje pro nasazení z jiných projektů sdílení zdrojů pro dobu nasazení 4. naplánování předání znalostí 5. výstupy z nasazení by měly obsahovat: (a) plány nasazení 24

31 5. ANALÝZA PŘÍNOSU ITIL (b) (c) (d) (e) (f) plány změnového a konfiguračního řízení plány a dokumentace dalších uvolnění testovací plán a výstup z testování návod na sestavení návod na nasazení 6. finanční plány nasazení Samotné nasazení má probíhat v následujících krocích: získání všech konfiguračních položek a komponent sestavení a otestování testovací nasazení zajištění připravenosti podpory pro případ nezdaru nasazení podpora v začátcích (early life support) kontrola a uzavření procesu Podle tohoto procesu probíhá ve Společnosti pouze prvotní nasazení vývojovým týmem. Rozdíl je v tom, že se servisní tým neúčastní samotného nasazení, ale účastní se až dalších servisních nasazení v době, kdy vývojový tým projekt předal do servisu. ITIL doporučuje sledování metrik (výběr metrik relevantních pro Společnost): počet nasazení, které kompletně splňovaly očekávání zákazníka snížení počtu tiketů souvisejících se špatně naplánovaným předáním projektu snížení rozdílu mezi odhadovanými a skutečnými náklady na nasazení spokojenost týmu s procesem nasazování 25

32 5. ANALÝZA PŘÍNOSU ITIL Doporučení autora této práce týkající se této kapitoly ITIL: D5 - Servisní tým by se měl aktivně zapojit už od fáze prvního nasazení projektu. Měl by řešit spolu s vývojovým týmem prvotní nasazení. Vývojový a servisní tým by měly spolupracovat při podpoře v rané fázi servisního projektu. D6 - Při přebírání do servisního oddělení by měl servisní tým kontrolovat existenci výstupů z prvotního nasazení, tj. bodů 5.a. až 5.f. ze seznamu v této kapitole. Řízení změn ITIL změnu definuje jako přidání, modifikace nebo odstranění podporované služby nebo její komponenty a související dokumentace [Cab05]. Změny mohou vznikat z různých důvodů: proaktivně hledání byznys výhod snižování výdajů, zlepšování služeb reaktivně řešení problémů a chyb, přizpůsobování se novým okolnostem Řízení změn si klade za cíl odstranit co nejvíce rizik se změnami spojených, snížit vážnost případných problémů a při implementaci změny uspět už napoprvé. Standardizace řízení změn napříč všemi servisními projekty pak má pomoci k rychlejšímu řešení změn a také k jednodušší zastupitelnosti členů servisního týmu. Přidaná hodnota pro byznys z pohledu řízení změn vzniká hlavně v: prioritizaci a odpovídání na změnové požadavky zákazníků implementaci změn pro zákazníka snižování počtu nepovedených změn a tím pádem zvyšování kvality a dostupnosti služby sledování vývoje změn s cílem vytipovat změny pro zlepšení byznysu zvyšování produktivity zaměstnanců v důsledku snížení počtu řešení kritických incidentů Řízení změn se v servisním oddělení týká hlavně změnových požadavků ze strany zákazníka. Ve Společnosti se tak děje pomocí vytvoření tiketu v systému JIRA. ITIL změnový požadavek definuje jako formální komunikaci, která požaduje změnu jedné nebo více konfiguračních položek. 26

33 5. ANALÝZA PŘÍNOSU ITIL Změnové řízení také řeší, jak se vyhnout neautorizovaným změnám například situace, kdy zákazník něco podstatného změní, ale nijak změnu nekomunikuje dodavateli. Takovéto změny dost často vedou k nedostupnosti služby a tedy i k nespokojenosti zákazníka. Typické změnové požadavky (standard changes), jak je prezentuje ITIL, dobře vystihují změnové požadavky, jaké řeší servisní tým Společnosti. Jde o požadavky, které jsou iniciovány zákazníkem. Jde většinou o známý problém, prostředí je zdokumentované. Jedná se o malé změny, které nepodléhají žádnému formálnímu schvalovacímu procesu. Změny platí zákazník ze svého rozpočtu, případně jsou změny placeny formou paušálních víceprací v rámci SLA. Riziko změn je malé. Ve Společnosti existuje proces změnového řízení. v servisním oddělení se jím ale řídí pouze velké změny. Ani ty ale dokonce nepodléhají formálnímu schválení ze strany Společnosti. Vývojář odhadne na základě svého úsudku (většinou po poradě s někým z původního vývojového týmu) časovou náročnost změny a po schválení zákazníkem změnu implementuje. Takovéto řešení přináší úsporu času ze strany Společnosti kvůli absenci schvalování. Nicméně s sebou nese riziko, že změna byla špatně odhadnuta nebo byl špatně stanoven dopad na ostatní části aplikace. Změny navíc nepodléhají testovacímu procesu. Metriky, které jsou v servisním oddělení použitelné pro vyhodnocení změnových požadavků, mohou být: počet vytvořených změnových požadavků počet incidentů vztahujících se ke změnovým požadavkům počet neautorizovaných změn (tj. změn, o kterých nebyla Společnost informována) objem práce na změnových požadavcích. Doporučení autora této práce: D7 - v systému JIRA odlišit změnové požadavky od incidentů. Cílem by mělo být lepší reportování bude patrný rozdíl mezi změnou a incidentem. Dále bude možné propojovat tikety incidentů s tikety změnových požadavků. D8 - Se zákazníkem komunikovat a nastavit, jak se budou řešit problémy, které způsobí systém třetí strany. Ideálně nastavit komunikaci i s těmito třetími stranami. D9 - Zavést povinné schvalování změnových požadavků, které mají rozsah větší než X, kde X bude závislé na velikosti a typu projektu. Schvalování 27

34 5. ANALÝZA PŘÍNOSU ITIL by měl mít na starosti člověk, který je uveden v původním procesu Řízení změn ve Společnosti. Řízení konfigurací Cílem řízení konfigurací a výstupů služeb (Service asset and configuration management) je mít pod kontrolou všechny konfigurační položky (Configuration item CI). Konfigurační položkou je podle ITIL každá komponenta, která musí být spravována procesem řízení konfigurací, aby byla zajištěna funkčnost poskytované služby. Jedná se typicky o hardware, software, budovy, lidi a formální dokumenty jako procesní dokumentace, licence nebo SLA. Konfigurační položky jsou uloženy v konfigurační databázi (Configuration management database CMDB). Tento přístup má zabezpečit zlepšení v organizaci, zlepšení předávání znalostí, zrychlení procesů a zvýšit kvalitu řešení tiketů. Konfigurační položky vznikají spolu s vývojem projektu, postupně přibývají a provází projekt a následně i servisní projekt celým jeho životním cyklem od počátku až po finální uzavření projektu. Všechny projektové procesy by měly být integrované s CMDB, tj. například při povýšení operačního systému na testovacím prostředí je potřeba tuto změnu reflektovat na příslušné místo CMDB. Je důlež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 působit problémy. Konfigurační databáze může sestávat z několika různých nástrojů. Pokud je tomu tak, je nutné, aby konfigurační procesy byly nastaveny tak, aby nebyly informace duplikovány. Je vhodné monitorovat procesy spojené se zavedením CMDB. ITIL doporučuje k tomuto tématu následující metriky: zvýšená rychlost při řešení incidentů, které se týkají identifikace špatných konfiguračních položek dopad incidentů, které se týkají konkrétních typů konfiguračních položek od konkrétních dodavatelů poměr licencí, které jsou používány, a koupených licencí (mělo by se blížit 100%) méně problémů způsobených tím, že lidé pracují se zastaralými informacemi rychlejší a kvalitnější audity 28

35 5. ANALÝZA PŘÍNOSU ITIL snížení času a ceny při diagnóze a řešení incidentů a problémů počet nesrovnalostí objevených při auditu počet problémů způsobených špatným zhodnocením dopadu (impact analysis) nebo problémy s verzemi aplikací Ve Společnosti je momentálně CMDB ve vývoji. Podle ITIL ale hrozí při implementaci určitá rizika. Přesvědčit všechny zúčastněné strany, aby CMDB vytvářely a udržovaly, je velkou výzvou a nemusí se při implementaci podařit. Pokud se sebere do CMDB příliš mnoho dat, může se stát, že se v nich pak zaměstnanci utopí a nebudou databázi chtít používat. Management ostatních oddělení může být málo motivovaný CMDB udržovat. Dalším rizikem je zvolení špatné technologie. Je důležitější mít CMDB funkční než použít příliš sofistikovaný nástroj, který je v praxi k ničemu. Je také důležitá pravidelná revize CMDB, protože případné chyby, které dezinformace může způsobit, mohou stát při jejich opravách velké množství prostředků. CMDB může zastarávat díky tomu, že osoba, která o CMDB neví, provádí změny (typicky přesun hardwaru) a nereflektuje je do CMDB. Proto by měl vzniknout proces půlročních kontrol aktuálnosti CMDB. Doporučení autora této práce: D10 - Implementovat CMDB podle aktuálně nastavených pravidel. D11 - Nastavit proces pravidelných kontrol aktuálnosti CMDB. D12 - Nastavit vhodný komunikační kanál se zákazníkem a jeho případnými dodavateli třetích stran, aby ve Společnosti v CMDB byly aktuální údaje. D13 - Motivovat všechny zúčastněné strany (servisní tým, vývojový tým, ICT oddělení) k údržbě CMDB při výskytu jakékoli změny. Řízení uvolnění a nasazení Řízení uvolnění klade důraz na definici a odsouhlasení nasazovacího plánu se zákazníkem a dalšími zúčastněnými stranami. Každý uvolněný balíček musí sestávat ze vzájemně kompatibilních verzí komponent, všechny balíčky jsou dohledatelné a v případě chyby musí být nahraditelné předchozí fungující verzí. Je třeba nastavit správný kanál pro předání znalostí směrem k zákazníkovi, co se týče nových verzí balíčků, stejně tak jako předání znalostí směrem k servisnímu týmu. Pro byznys má řízení uvolnění hlavní cíl dělat uvolnění a nasazení efektivně, správně a s co nejméně riziky. Všechny uvolnění aplikace by měly mít unikátní identifikátor, který je poté použit řízením konfigurací. Typy uvolnění by měly být předem defi- 29

36 5. ANALÝZA PŘÍNOSU ITIL nované, aby zákazník a další zúčastněné strany měly v tomto ohledu reálná očekávání. ITIL uvádí typický příklad: významné uvolnění (major release) obsahuje velké změny ve funkcionalitě. Může obsahovat opravy narychlo opravených urgentních chyb. Je důležitější než malé uvolnění. malé uvolnění (minor release) obsahuje malé změny mimořádné uvolnění (emergency release) opravuje změny důležité pro byznys ITIL doporučuje tato uvolnění (release) mít naplánována, např. významné uvolnění jednou za 6 měsíců, malé uvolnění jednou za měsíc a mimořádné uvolnění podle potřeby. Ve společnosti momentálně funguje uvolnění ve formě mimořádného uvolnění tedy servisní oddělení nasazuje balíčky obsahující malý počet opravených chyb. Konkrétní vývojář vždy se domlouvá se zákazníkem na době nasazení. Ve Společnosti se většinou v servisním režimu uvolňuje jen jedna komponenta. v případě, že jich je více, je třeba definovat, jak pro konkrétní komponentu bude uvolnění probíhat včetně nastavení správných verzí. Po nasazení je nutné aktualizovat informace v CMDB. Sestavení aplikace by mělo zabrat co nejméně času. Pokud se sestavení pro produkční (testovací) a vývojové prostředí liší, je nutné, aby pro každý typ prostředí existoval jeden příkaz, kterým se aplikační balíček sestaví. Před nasazením nové verze aplikace je třeba zajistit možnost vrátit se do původního stavu aplikace. Proto je třeba pokaždé provést zálohu databáze a zajistit, že je k dispozici původní verze aplikace. Doporučení autora práce: D14 - Zavést na všech projektech sestavování aplikace (pro každé prostředí) jedním příkazem. D15 - Nastavit pravidelná okénka pro uvolnění jejich č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čního prostředí. Incidenty a problémy zanesené v systému pak propojit s těmito nasazeními. v případě, že bude nasazování probíhat pravidelně, bude propojení velmi snadné. D17 - Sestavené aplikace by měly obsahovat informace o verzi a revizi ze Subversion. Každé další nasazení do produkčního prostředí by mělo zvyšovat verzi aktuálně nasazované aplikace. 30

37 5. ANALÝZA PŘÍNOSU ITIL D18 - Při nasazení balíčku do produkčního prostředí zajistit zálohu tohoto balíčku. Díky tomu bude možné znovu nasadit starší balíček v případě chyby. Pro databázové skripty je třeba krom skriptů s úpravou také vytvářet skripty, které danou úpravu vrátí do původního stavu. Tyto skripty je také nutné testovat ještě před nasazením do produkčního prostředí. D19 - Při nasazení do produkčního prostředí je třeba vytvořit zálohu aktuálního prostředí. Tyto zálohy by měly být jednoznačně pojmenovány a uloženy na definované místo. Validace a testování služeb Cílem validace a testování je zajištění odpovídající kvality služeb a tím snížení počtu incidentů a problémů, které zákazník hlásí. Ruku v ruce s kvalitou jde i spokojenost zákazníka, protože mu projekt poskytuje vysokou přidanou hodnotu. Naopak pokud zákazník vidí v dodaném produktu chyby, je nespokojený a má důvod zvažovat jiného dodavatele služeb. V servisním oddělení Společnosti momentálně nefiguruje žádný tester. Testování probíhá na testovacích prostředích a provádí ho testeři zákazníků. Na některých projektech testovací prostředí není zavedeno vůbec. ITIL se v této kapitole testování věnuje poměrně obšírně. Co je důležité pro Společnost a její servisní oddělení je myšlenka zavedení testování před každým nasazením do produkčního prostředí. Doporučení autora práce: D20 - v procesu uvolnění a nasazení zavést povinné otestování jak testerem ze Společnosti, tak testery na straně zákazníka s cílem zlepšit aplikaci při nasazení do produkčního prostředí. Je třeba zvážit, od jakých objemů práce se tester vyplatí. Je pravděpodobné, že u změn malého charakteru se bude testování zbytečně prodražovat. Řízení znalostí Cílem řízení znalostí je zaručit, že servisní tým má všechny potřebné informace pro výkon své práce, případně že je schopen tyto znalosti dohledat, členové týmu jsou schopni se správně rozhodovat a efektivně zasahovat v případě incidentů a problémů. Prvním krokem k uchopení ří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řeba zjistit jeho rozsah. Až je známo, jaké znalosti je třeba předat, je nutné samotné předání naplánovat. Typicky se jedná o formu klasických přednášek a sadu 31

38 5. ANALÝZA PŘÍNOSU ITIL dokumentů. Je důležité, aby veškeré předávání znalostí probíhalo se zaměřením na skutečné potřeby servisního týmu. Tedy např. pokud předáváme znalosti ohledně programování javascriptových komponent, je třeba se zaměřit na to, jak se s nimi pravděpodobně bude setkávat servisní tým tedy např. se při předávání zaměřit na jejich ladění, upozornění na typické problémy apod. Při předávání projektu servisnímu týmu je důležité předat 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řinesl co největší přidanou hodnotu. Znalosti by také měly být předány při odevzdání produktu zákazníkovi. Školení uživatelů nejen přinese snížení počtu problémů servisnímu oddělení, ale také zvýší spokojenost s vyvinutým produktem, a to jak u uživatelů, tak i u vedení. Také by měla vzniknout databáze kontaktů, kde budou uloženy kontakty na všechny zodpovědné osoby na straně zákazníka. Databáze by měla vznikat už v době vývoje původního projektu a pak se v servisní fázi jen rozvíjet. Důležitou částí řízení znalostí je správa databáze známých errorů (known errors database). Při předání projektu zákazníkovi by měla vzniknout databáze známých errorů, která obsahuje problémy a jejich řešení (nebo workaroundy). Měřitelné faktory jsou: počet chybějících znalostí v rámci týmu snížení času potřebného k podpoře spokojenost koncových uživatelů se systémem Doporučení autora práce: D21 - Analyzovat chybějící znalosti v týmu a následně naplánovat, jak tyto znalosti budou doplněny pomocí školení v rámci Společnosti. U školení si dát pozor na cíl školení školitelé by se měli zaměřit na předem připravené problémy, které servisní oddělení nejčastěji řeší. D22 - Nastavit proces předávání projektu tak, aby už v něm vznikla databáze známých problémů, kterou pak bude servisní tým rozšiřovat. Zároveň zajistit, aby v tomto procesu bylo zahrnuto školení koncových uživatelů na straně zákazníka. D23 - Znalosti by měly být předány také formou dokumentace. Tu by měl servisnímu týmu dodat vývojový tým. Pro jednoduchost by se servisní oddělení mělo snažit o implementaci jednoduchého vyhledávání nad všemi systémy, ve kterých se znalosti vyskytují. 32

39 5. ANALÝZA PŘÍNOSU ITIL 5.3 Provoz služeb Kniha Provoz služeb (Service Operation) popisuje, co se děje a řeší na úrovni uživatelské podpory, jak probíhá řízení problémů a incidentů v každodenním životě služby. Řízení událostí Událost je cokoli detekovatelného nebo zjistitelného, co má vliv na řízení IT infrastruktury nebo na správný chod služeb. Události typicky vytváří služba, konfigurační položka nebo monitorovací nástroj. Efektivita servisního oddělení výrazně závisí na schopnosti tyto události sbírat a reagovat na ně. Řízení událostí poskytuje nástroje pro rychlé zjištění incidentů. Může se tak stát, že je incident odstraněn, aniž by došlo k přerušení služby. Většinou se bohužel problémy a incidenty řeší reaktivně a na základě špatných zkušeností se teprve nastavují pravidla řízení událostí. Mezi typické úlohy řízení událostí patří: kontrola stavu některé z konfiguračních položek (typicky server musí běžet tedy např. musí reagovat na ping ) monitorování vypršení licencí a certifikátů bezpečnost (detekce neautorizovaného přístupu) normální aktivita (sledování, že služba běží) Pojem řízení událostí je velmi podobný pojmu monitorování. Monitorování je širší pojem než řízení služeb. Řízení služeb se zaměřuje na generování a detekci smysluplných oznámení o stavu IT infrastruktury a služeb. Naproti tomu monitorování se zaměřuje i na sledování stavu zařízení, které žádné události negeneruje. V servisním oddělení je třeba vědět o všech výjimečných stavech, které se i nepřímo týkají podporované aplikace. v ideálním případě je vhodné implementovat následující: upozornění na událost např. monitorovací nástroj kontroluje danou konfigurační položku nebo sama konfigurační položka generuje upozornění detekce událostí když je na událost upozorněno, musí být událost detekována agentem běžícím na tomtéž systému 33

40 5. ANALÝZA PŘÍNOSU ITIL filtrování událostí cílem je rozhodnout, které události je zapotřebí poslat řídicímu nástroji a které ne. v některých případech není nutné události filtrovat závažnost události nastavení, které události nesou pouze informativní zprávy, které varují před blížícím se nebezpečím a které reportují nějaký výjimečný stav reakce na událost zda se událost pouze zaloguje, pošle se upozornění zodpovědným osobám nebo se založí nový incident V prostředí Společnosti je řízení událostí momentálně reprezentováno událostmi na úrovni aplikace. v každé aplikaci existují aplikační logy, které obsahují informace o různých událostech. Jejich úroveň se však projekt od projektu liší. Nejsou definována žádná pravidla týkající se logování. Společnost také momentálně nemá zaveden žádný monitorovací standard. v době vzniku této práce probíhají první pokusy o zavedení monitoringu na jednom z důležitých projektů. Metriky správného řízení událostí mohou být například: počet událostí podle kategorie, podle závažnosti počet událostí, které potřebovaly lidský zásah počet událostí, které vedly k vytvoření incidentu počet událostí, které byly způsobeny existujícími problémy a známými errory počet opakujících se událostí počet událostí, které způsobily výkonnostní problémy počet událostí, které způsobily problémy s dostupností počet událostí v porovnání s počtem incidentů Všechny metriky lze hodnotit krom absolutního také z procentuálního hlediska. Doporučení autora práce: D24 - Zavést standardy pro logování aplikací. Na základě zkušeností z aktuálních projektů vymyslet vhodná pravidla pro logování. Tato pravidla je třeba komunikovat vývojovému týmu, aby nové aplikace byly vhodně připraveny. Implementovat systém, který bude reagovat na závažné chyby posláním události zodpovědným osobám do Společnosti. 34

41 5. ANALÝZA PŘÍNOSU ITIL D25 - Zprovoznit na všech prostředích vhodný monitorovací nástroj a nastavit vhodné filtrování událostí. Zajistit také všude, kde to bude možné, monitorování systémů třetích stran. D26 - v procesech vývoje nových projektů je nutné, aby vývojáři počítali s budoucím napojením na monitorovací nástroje a těmto nástrojům vystavili potřebná rozhraní. Řízení incidentů V ITIL terminologii je incident definován jako neplánované přerušení služby nebo snížení její kvality. Chyba konfigurační položky, která zatím ale neměla dopad na kvalitu služby, je také definována jako incident. Proces řízení incidentů zahrnuje řešení chyb, otázek a připomínek uživatelů, techniků nebo automaticky detekovaných chyb z monitorovacích nástrojů. Cílem řízení incidentů je dostat službu zpět do funkčního stavu co nejrychleji a snížit dopad na byznys, takže jde vlastně o zajištění co nejvyšší kvality a dostupnosti služby. Doba pro vyřešení incidentu se liší podle jejich priority a musí být uvedena v SLA. Všechny incidenty musí být někam zapsány. Ve Společnosti je to do systému JIRA. Každý incident by měl mít povinné atributy. Systém JIRA s tím, jak je nastaven ve Společnosti, poskytuje všechny tyto atributy. Jediný rozdíl proti atributům definovaným v ITIL je naléhavost (urgency), která je zde nahrazena prioritou. Každý incident má svůj stav - otevřený, probíhající, čekající apod. Měl by určitě končit obsahovat stav uzavřený. Před formálním uzavřením je třeba zvážit, zdali se problém nemůže opakovat. Pokud ano, je třeba vytvořit související tiket problému. Problémy se dále budou rozebírat v následující části Řízení problémů. v případě, že pro opravu incidentu je třeba v systému něco změnit, je třeba založit změnový požadavek, který následně bude řízen procesem řízení změn. Je také vhodné definovat pravidla, za jakých podmínek je možné incident znovu otevřít a kdy je třeba vytvořit nový. ITIL navrhuje např. po dobu jednoho pracovního dne možnost znovuotevření incidentu, další pracovní den už je potřeba vytvořit incident nový. v každém případě je vhodné mít tato pravidla nastavena pro všechny projekty stejně. Ve společnosti je momentálně každý podnět od zákazníka (at už změnový 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řidán štítek podle typu požadavku ( incident, change request ). 35

42 5. ANALÝZA PŘÍNOSU ITIL Pro vývojářské účely je ke každému takovémuto tiketu vytvořen další související tiket typu Úkol (Task), na kterém vývojář (nebo více vývojářů) vykazuje práci. v případě, že je incident vyřešen, ale nebyla nalezena jeho příčina (root cause), je tento tiket neustále otevřen a je mu přidělen štítek problem. Tím se tiket dostává do řízení problémů. Tento proces je ve Společnosti velmi dobře uchopen a vývojáři, manažeři i zákazníci, kteří do systému incidenty reportují, ho mají dobře zažitý. Zatím však není implementována databáze známých errorů, která by pomohla řešit běžné známé problémy. Její řešení spadá do následující kapitoly Řízení problémů. Metrik pro řízení incidentů je velké množství. Pro malá oddělení, jako to ve Společnosti, jsou zajímavé tyto: celkový počet incidentů počet incidentů v různých stavech (otevřený, uzavřený, probíhající) procentuální zastoupení incidentů podle priorit průměrný čas reakce na incident průměrný čas uzavření incidentu počet znovuotevřených incidentů a jejich poměr k celkovému počtu incidentů počet nevalidních incidentů Doporučení autora této práce: D27 - Definovat pravidla pro znovuotevírání incidentů kvůli lepšímu reportování. D28 - Naučit vývojáře používat databázi známých errorů, až bude implementována. Pro lepší vyhledávání v rámci již řešených incidentů a problémů zavést snadné vyhledávání jak mezi incidenty, tak mezi problémy a známými errory. Řízení problémů Pokud se v ITIL mluví o problémech, je řeč o příčinách incidentů. Řízení problémů se zabývá životním cyklem těchto problémů. Jeho hlavním cílem je problémům a incidentům předcházet, eliminovat opakující se incidenty a minimalizovat dopad incidentů, kterým se předejít nedá. 36

43 5. ANALÝZA PŘÍNOSU ITIL Řízení problémů se dělí na dva hlavní procesy reaktivní a proaktivní. Proaktivní se snaží problémům předcházet a vyhledávat je dříve než se projeví formou incidentů. Reaktivní řeší problémy až nastanou, většinou jako příčiny incidentů, nebo z podnětu monitorovacího nástroje. Každý problém musí být zanesen do databáze problémů. Ve Společnosti tuto roli zastává systém JIRA. Problémy, stejně jako incidenty, musí mít povinné atributy a správnou prioritu. Při řešení problému je důležité uvést, jaké akce byly pro jeho řešení provedeny. v budoucnu při řešení stejného nebo podobného problému tato informace může vést k dramatickému zrychlení. Pokud řešení problému vyžaduje změnu v systému, je třeba vytvořit příslušný změnový požadavek a dále se řídit procesem řízení změn. Po vyřešení problému je třeba založit záznam v databázi známých errorů. Tato databáze slouží při řešení incidentů jako báze znalostí, která pomáhá zefektivnit opravu chyb. Také je nutné aktualizovat záznamy v CMDB. V případě závažných problémů (tedy problémů, které mají nejvyšší prioritu) je nutné při zavření problému ještě jednou zhodnotit řešení a analyzovat: co bylo správně a špatně co mohlo být příště řešeno lépe jak zabránit opakování problému zdali měla za problém zodpovědnost třetí strana a jestli je třeba dalšího sledování problému Tyto informace by měly být součástí předávání znalostí servisního týmu např. na pravidelných schůzkách a měly by se promítnout do příslušné dokumentace. Nabyté znalosti z této zpětné analýzy by se měly 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čení fáze vývoje téměř žádná aplikace není bezchybná. Pravděpodobně 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ěly být zaneseny do databáze známých errorů, protože pokud se tak nestane, je pravděpodobné, že zákazníci budou hlásit chyby, které budou muset být objeveny a analyzovány znovu, což výrazně vývoj aplikace prodražuje. Ve Společnosti jsou problémy řešeny v systému JIRA. Známé errory momentálně nejsou explicitně zaznamenávány. Jako databáze známých errorů slouží pouze provizorně historie všech incidentů a problémů. Krom tohoto 37

44 5. ANALÝZA PŘÍNOSU ITIL nedostatku je proces řízení problémů ve Společnosti funkční a dobře zavedený. Doporučení autora: D29 - Zavést databázi známých errorů. Tuto databázi při vzniku servisního projektu naplnit známými errory, které odhalí akceptační testování a které nebyly v rámci vývojového projektu řešeny. D30 - Dbát na popisování řešení u problémů, protože bude základem rozvíjející se databáze známých errorů. Je vhodné motivovat vývojáře, aby tuto databázi používali a rozšiřovali. D31 - Do procesu uzavírání problémů přidat fázi vytváření známého erroru. Pro problémy s nejvyšší prioritou přidat krok zpětné analýzy, která bude mít výše zmíněné výstupy. Řízení přístupů Cílem řízení přístupů je kontrolovat přístupy ke službám, tedy kontrolovat, že všechny povolané osoby mají příslušné přístupy a oprávnění, a naopak nepovolané osoby přístup nemají. Zároveň kontrolovat změny v těchto oprávněních, změny ve stavech zaměstnanců (pracovník, který už pro Společnost nepracuje, nemá mít nikam přístup). Pro Společnost je zajímavé řešení přístupů do: systémů Společnosti (JIRA, Confluence, Alfresco, Subversion, intranetový portál) systémů, které Společnost spravuje (prostředí zákazníků) dalších systémů, kam mají zaměstnanci Společnosti přístup (typicky prostředí u zákazníka) Interní systémy mají správu oprávnění řešenou pomocí systému rolí. Pokud zaměstnanec přechází mezi těmito rolemi, odpovídajícím způsobem se mu mění oprávnění v těchto systémech. Prostředí zákazníků stejně jako přístupy k dalším systémům jsou sepsány v CMDB. Přístupové údaje a hesla jsou přístupné pouze uživatelům v dané roli. Systém oprávnění je certifikován pro bezpečnostní normu ISO 27001, která se řízením přístupů zabývá do detailu. Doporučení autora práce pro tuto kapitolu nejsou, systém je nastaven optimálně a v souladu s doporučeními knihovny ITIL. 38

45 5. ANALÝZA PŘÍNOSU ITIL 5.4 Neustálé zlepšování služeb Tato kapitola ITIL se věnuje, jak už název napovídá, procesu zlepšování služeb. Zlepšování se musí týkat hlavně efektivity (efficiency, effectiveness). Klade si tyto otázky: Proč monitorujeme a měříme služby? Kdy skončíme? Používá někdo tato data? Potřebujeme tyto reporty ještě? Kroky, které vedou k postupnému zlepšování služeb, jsou: Zjistit, co bychom měli měřit aneb na základě cílů a strategie firmy stanovit, kam se chceme posunout. Definovat, co můžeme měřit z předchozích metrik zjistit, které jsme schopni měřit. Pro ty, které nejsme schopni měřit, je dobré zjistit, co nám k jejich sledování chybí a zda by se s tím nedalo něco dělat. Získat data pro tento bod je nutné mít zavedeny odpovídající monitorovací nástroje. Monitorují se tři 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ředchozí dva typy metrik). Klíčové jsou frekvence sběru metrik, nástroje (ruční sběr, automatizovaný) a jejich validita (např. pokud je počet uzavřených incidentů větší než počet nahlášených incidentů, pravděpodobně máme špatná data). Zpracování dat zde probíhá konverze dat do požadovaného formátu, tj. data se zpracují do řeči měřitelných KPI (Key Performace Indicator). Analýza dat data se následně analyzují a vyvozují se z nich např. dlouhodobé trendy, kde jsou potřeba změny, plnění stanovených cílů. Prezentace dat výsledky analýzy jsou dále prezentovány senior managementu a byznys oddělení. Implementace nápravných opatření použití získaných informací k vylepšení a úpravám ve službách. 39

46 5. ANALÝZA PŘÍNOSU ITIL Výsledné reporty, které budou prezentovány, je třeba zaměřit na konkrétní cílovou skupinu. ITIL popisuje zlepšování služeb velmi obšírně. Tato kniha je zaměřena na daleko větší společnosti s daleko větším oddělením uživatelské podpory, servisním oddělením i oddělením podpory interních systémů. Proto z této knihy lze pro Společnost použít poměrně malé množství informací. Doporučení autora práce: D32 - Vytipovat, v čem je třeba servisní oddělení zlepšit. Podle těchto plánovaných zlepšení stanovit potřebné metriky i s využitím metrik popsaných v předchozích kapitolách. D33 - Nastavit pravidelné sbírání metrik a jejich pravidelnou revizi. U každé metriky by měl být vyhodnocen její reálný přínos pro servisní oddělení. Pokud se změní strategie oddělení, mělo by se to také promítnout ve sledovaných metrikách. 40

47 6 Projekt implementace ITIL V této kapitole rozebereme, jak vznikal praktický projekt implementace ITIL ve Společnosti. 6.1 Rozsah projektu Všechna doporučení autora práce byla sepsána a byla provedena jejich revize se servisním manažerem. Výstupem této schůzky byl seznam doporučení, který je vhodné implementovat v rámci projektu. Doporučení, která v projektu nefigurují, byla stažena většinou z několika důvodů: V průběhu vývoje práce již došlo k implementaci těchto doporučení. Autorova doporučení nebyla vhodná pro implementaci. Doporučení již byla implementována dříve. Některá doporučení byla ve fázi schvalování částečně implementována. Tato doporučení byla do projektu zahrnuta se sníženou dotací člověkodní. 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 projektů [Dol09]. Metoda je založena na sepsání dokumentu logického rámce, který sestává z tabulky o čtyřech řádcích a čtyřech sloupcích. Uspořádání a význam jednotlivých sloupců tabulky a jejích řádků popisuje následující tabulka. Výhodou logického rámce je možnost ověření konzistence projektových záměrů, cílů, výstupů a aktivit. 41

48 6. PROJEKT IMPLEMENTACE ITIL Sloupec intervenční (strom cílů) Objektivně ověřitelné ukazatele Zdroje informací k ověření Vnější předpoklady / rizika Záměr projektu Specifikuje důvod realizace projektu, k čemu chce projekt přispět v rámci firemních cílů Cíl projektu Specifikuje, čeho chceme konkrétně dosáhnout, přímý užitek po úspěšné realizaci projektu Výstupy projektu Specifikuje, jak chceme výsledku dosáhnout, konkrétní odevzdané produkty nebo služby Specifikuje, jak bude měřeno splnění záměru projektu (v rovině kvality, kvantity a času) Specifikuje, jak bude měřeno splnění cíle projektu (v rovině kvality, kvantity a času) Specifikuje, jak bude měřeno splnění výstupů projektu (v rovině kvantity a času) Specifikuje, kde, kdy a kým budou získány informace o objektivně ověřitelných ukazatelích (např. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy) Specifikuje, kde, kdy a kým budou získány informace o objektivně ověřitelných ukazatelích (např. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy) Specifikuje, kde, kdy a kým budou získány informace o objektivně ověřitelných ukazatelích (např. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy) Nezbytné předpoklady (mimo naši kontrolu), které musí být dodrženy pro splnění záměru projektu (v případě splnění cíle) Nezbytné předpoklady (mimo naši kontrolu), které musí být dodrženy pro splnění cíle projektu (v případě splnění výstupů) 42

49 6. PROJEKT IMPLEMENTACE ITIL Sloupec intervenční (strom cílů) Objektivně ověřitelné ukazatele Zdroje informací k ověření Vnější předpoklady / rizika Aktivity projektu Specifikuje konkrétní úkoly, které je třeba splnit pro splnění výstupů Výčet měřitelných vstupů nezbytných pro zabezpečení aktivit projektu Časový rámec každé z aktivit projektu Nezbytné předpoklady (mimo naši kontrolu), které musí být dodrženy pro splnění cíle projektu (v případě splnění aktivit) Předběžné vnější předpoklady, které musí být naplněny, aby mohla začít samotná realizace projektu Následuje zkrácený logický rámec projektu Implementace ITIL v servisním oddělení. v tomto tabulkovém výpisu je zkrácena pasáž aktivit a jejich časových rámců. Aktivity jsou shrnuty do tematických celků. v posledním sloupci jsou uvedena rizika projektu na všech úrovních. Sloupec intervenční (strom cílů) Objektivně ověřitelné ukazatele Zdroje informací k ověření Vnější předpoklady / rizika Záměr projektu Zvýšení efektivity servisního oddělení Cíl projektu Zavedení ITIL praktik v servisním oddělení k O 10% méně incidentů, o 10% menší čas potřebný k vyřešení jednoho incidentu - výstupy vývojových projektů odpovídají požadavkům - servisní oddělení dodržuje procesy Systém docházky, tiketovací systém JIRA - výstupy vývojových projektů (dokumentace v Confluence) - procesy v JIRA - dokumentace prováděných procesů v Confluence - byly vybrány vhodné části ITIL k implementaci - rozsah servisního oddělení zůstává v průběhu projektu zhruba stejný 43

50 6. PROJEKT IMPLEMENTACE ITIL Sloupec intervenční (strom cílů) Objektivně ověřitelné ukazatele Zdroje informací k ověření Vnější předpoklady / rizika Výstupy projektu - upraveny guidelines vývojových projektů - upravena odpovídající dokumentace - upraveny procesy v tiketech v JIRA - provedeno školení servisního týmu - provedeno školení PM a team leaderů - guidelines vývojového projektu schváleny - schváleny úpravy dokumentace - schváleny úpravy v JIRA procesech - záznam o docházce školení - guidelines v Confluence - dokumentace v Confluence - proces tiketů v JIRA - prezentace ze školení - dostatečná motivace servisního oddělení ke změnám - dostatečná motivace manažerů vývojového oddělení k prosazení dalších výstupů projektů 44

51 6. PROJEKT IMPLEMENTACE ITIL Sloupec intervenční (strom cílů) Objektivně ověřitelné ukazatele Zdroje informací k ověření Vnější předpoklady / rizika Aktivity projektu - nastudování ITIL - vytipování vhodných ITIL praktik - rozplánování projektu - úprava dokumentů procesů - implementace metrik - úprava požadovaného výstupu vývojového projektu - úprava aktuálně spravovaných aplikací - nastavení pravidelných událostí - školení servisního týmu - školení PM a team leaderů Vstupy na úrovni aktivit - práce autora - přístup k ITIL knihovně - přístup k aktuální dokumentaci - lidské zdroje servisního oddělení - zdroje pro školení Časový rámec aktivit - nastudování ITIL plán projektu úpravy a implementace školení servisního týmu možnost dostatečného vhledu do ITIL - dostatek lidských zdrojů servisního oddělení - účast servisního týmu na školení - účast PM a team leaderů na školení Předběžné podmínky - souhlas servisního manažera s prací na projektu - přístup k nástrojům (JIRA, Confluence) Doporučení byla rozpracována do odpovídajících implementačních úkolů. Spolu se servisním týmem autor práce odhadl časovou náročnost jednotli- 45

52 6. PROJEKT IMPLEMENTACE ITIL vých úkolů. Náročnost je odhadována ve člověkodnech (man-day = MD), viz Tabulka 6.3. Úkol - doporučení 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 Celkem Časová dotace 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 57,5 MD Tabulka 6.3: Tabulka časových odhadů úkolů na projektu. Jednotlivé úkoly jsou rozepsány do struktury rozpisu práce WBS (Work Breakdown Structure) na Obrázku

53 6. PROJEKT IMPLEMENTACE ITIL Obrázek 6.1: WBS projektu Implementace ITIL - ve sloupci Jméno je uveden kód doporučení, Trvání ukazuje, jak dlouho bude implementace trvat. v případě, že úkol trvá tři MD, ale pracují na něm tři vývojáři, je zobrazena hodnota 1 den. Vpravo je zobrazen Ganttův diagram. Červeně je v něm vyznačena kritická cesta. Napravo od boxů jednotlivých úkolů jsou role, které budou mít daný úkol na starost. SM - servisní manažer; SV1-SV3 - servisní vývojáři; AP - autor této práce. Pro tvorbu WBS byl použit nástroj OpenProj. 6.3 Řízení rizik Náčrt rizik projektu již byl proveden v předchozí kapitole 6.2. Tabulka 6.3 v této kapitole prohloubí jejich rozbor a uvede, jak rizika byla nebo budou mitigována. 47